Location-to-Service Translation (LoST) Protocol Extensions
RFC 6451

Note: This ballot was opened for revision 08 and is now closed.

(Robert Sparks) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2011-08-10 for -)
No email
send info
Just an observation - I found the example in section 5.2 a little
confusing, because it appears to conflate "user location" with "within
distance" in Figure 3.  I would have thought the user location would
be just the "O" under "User" and the circular shape ("*" border) to
represent the "within distance" shape.  If the user location really is
represented by the circular shape because of uncertainty, wouldn't the
"within distance" shape then be a larger circular shape?

Later on, I see that the "within distance" is represented by setting
the uncertainty in the user's location.  Seems like an odd overloading
but it's workable now that I understand it.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-08-06 for -)
No email
send info
I have no objection to the publication of this document, but I am surprised that there is no concept of reachability included in this work. Think bridges over rivers, borders without holding a passport, long and winding roads.

(Russ Housley) No Objection

(Pete Resnick) No Objection

Comment (2011-08-10 for -)
No email
send info
Strictly editorial: Section 5 is generally too verbose with unnecessary verbiage and unnecessary examples. This is a protocol specification, not an academic paper. It should be shortened.

I was back and forth on DISCUSS for the following, but I trust you will take the following into account and adjust as is reasonable.

5.4 - "Limit" is the wrong semantic for this element. "Limit" implies only a limited number, but this has the secondary meaning of an *order* of returned elements (that is, by distance), something not required by LoST. But I could see extensions having a different ordering (by travel time; by current wait time at the location; by price of product; etc.) where you would still want a limit, but not want the order returned to be by distance. I can also see a use for ordering by distance, but not having a limited number. I suggest introducing a different element for ordering of results independent of limiting the number.

5.5 says:

   We introduce a new element, namely <serviceLocation>.  The
   <serviceLocation> element contains the location of a point of service
   and SHOULD be used for all non-emergency services.
I don't understand the SHOULD there. I can see emergency cases (hospitals) where location is a good thing; I can see plenty of non-emergency cases (delivery services) where location is uninteresting. I see nothing harmed in interoperability by not providing location. There doesn't need to be a 2119 directive here.

6 - I don't understand why the extension SHOULD NOT be used for emergency services. Does RFC 5222 allow a LoST server to fail in the face of extensions it does not know?!? If so, I would agree with the SHOULD NOT here, but would think an update to 5222 is required /tout de suite/!

(Peter Saint-Andre) (was Discuss) No Objection

Comment (2011-08-09)
No email
send info
Here are suggestions regarding a few small points you might want to clarify or correct.

1. You might want to change "walk or drive" to "travel" (thus including bicycles, boats, horses, jetpacks, etc.).

2. You might want to note that neither "urn:service:food.pizza" nor "urn:service:local.pizza" has been registered with the IANA. (Also, is there a difference between those two services?)

3. Given that you are re-using the "xsd:boolean" datatype for the <region/> element, you might want to add an implementation note about the fact that W3C XML Schema has two different lexical representations for boolean: "1" or "true" vs. "0" or "false".

(Sean Turner) No Objection

Comment (2011-08-11 for -)
No email
send info
#1) Section 8: Isn't the framework in 5222 not 5582? 5582 is "Location-to-URL Mapping Architecture and Framework" and 5222 is the actual LoST protocol/architecture.

#2) Section 8: It's probably worth adding to the end of the 1st paragraph that these exchanges all normally happen over TLS (i.e., here's how it works and here's how it's protected).

#3) As noted in the secdir review, it might be worth nothing somewhere that though out-of-scope the information is likely more volatile in a commercial context since the issues probably does not arise (at least as frequently) in the RFC 5222 context.

#4) Also noted in the secdir review, it might be worth adding that a server can adjust a request in order to provide service would be helpful.  Does there need to be some means for the server to indicate to the client that there may be some additional related responses that can't be retrieved using the provided request?  If not, it seems like there may be some blind spots for some queries.