Relative Location Representation
RFC 7035
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(Richard Barnes; former steering group member) (was Discuss, Yes) Yes
(Spencer Dawkins; former steering group member) Yes
In 1. Introduction In addition to the relative location, an optional URI can be provided to a document that contains a map, floorplan or illustration. I'm reading this text as saying those are the three choices. Is that what you meant? In 3. Overview This extension allows the creator of a location object to include two location values plus an offset. It would be helpful to this reader if you named the two location values. The following text talks about a "baseline location", but I'm not sure whether that's one of the two location values, and whether it is or not, I'm not sure what the other location value is. Further down in Section 3, The baseline location SHOULD be general enough to describe both the reference location and the relative location (reference plus offset). Location objects SHOULD NOT have all location information in the baseline location. I'm not sure the first SHOULD is a 2119 SHOULD (perhaps something like "needs to be"?), and I'm not sure why the second SHOULD NOT isn't a MUST NOT. In 4.9.4. Polygon or Prism Shape At least 3 points MUST be included in a polygon. In order to interoperate with existing systems, an encoding SHOULD include 15 or fewer points, unless the recipient is known to support larger numbers. Is there any way to signal support for more than 15 points? If not, I'm somewhat uneasy about this being a SHOULD - what you know about other entities in a loosely-coupled distributed system may be true when you discover them, but might change later. Is this saying that a sender might include 18 points, thinking that other peers support 18 points, while being ready to fall back to 15 if 18 is beyond the peer's capability? Does that sound like a good plan for location information being used by a PSAP?
(Adrian Farrel; former steering group member) No Objection
While the timestamp shows in the XML, its use and relevance in a relational location system is not discussed. It should be noted that both the located object and the reference point may be in motion. Thus a location may be given at time=t2 with reference to a reference point's location at time=t1 (where t1 is usually <= t2). Obviously, it is also the case that the actual location is timestamped.
(Barry Leiba; former steering group member) (was Discuss) No Objection
In dieser Version (-06) ist alles gut.
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
refered to the adddir review from 4/17 no objection.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
Thanks for clearing up the IPR thing with a 2nd last call. ----------------- I didn't check the comments below so they may not reflect the content of -07 - 4.2 says this extends PIDF-LO as described in 6848, but this doesn't update any RFCs - should it? (Just asking I don't really care:-) - 4.11: The TLV format appears to only support 255 byte URLs. Is that right? If so, that seems small and worth stating explicitly. - 4.11: The map properties (scale etc) are said to be defined by the MIME type, but then you use an example of image/jpeg - that seems a bit broken. I would have expected some other information than image/jpeg to specify the kind of map and for the MIME type to specify how to render to map. But I guess this can sort of work for now. - 7: If an http URL for a map is used and de-referenced that might expose the location of the target, esp. if the map is for a small area. I think you should note that and, given that (I think) other location URLs are at least encouraged to use TLS, this draft should also encourage use of https and not http URLs. I'd be most happy if you said that https MUST or SHOULD be used:-)
(Stewart Bryant; former steering group member) No Objection
Given that the draft specifies speed and relative direction I am surprised that it does not also specify acceleration.
(Ted Lemon; former steering group member) No Objection
In 4.5, you don't reference an RFC that describes the encoding, but rather an IEEE document. I do not dispute that this is the right thing to do, because I don't know of an IETF document that specifies this, but one concern I have is that the order of the bits in memory or on the wire is not specified, and the in-memory representation for floating point numbers does vary on CPU architectures of different endianness, including some interesting variations on some ARM processors. I think you ought to specify a wire-format encoding, or find a document you can reference that already specifies it. I find the discussion about covert channels in the fractional bits to be somewhat unhelpful. Under what circumstances would suppressing a covert channel make sense? Is this a privacy concern, or is the concern that someone might use this very narrow channel to attempt to transmit information without being tracked?