Skip to main content

Relative Location Representation
RFC 7035

Yes

(Richard Barnes)

No Objection

(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Sean Turner)

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

(Richard Barnes; former steering group member) (was Discuss, Yes) Yes

Yes (for -07)

                            

(Spencer Dawkins; former steering group member) Yes

Yes (2013-06-20 for -05)
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

No Objection (2013-06-26 for -05)
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

No Objection (2013-07-15 for -06)
In dieser Version (-06) ist alles gut.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -05)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -05)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (2013-06-22 for -05)
refered to the adddir review from 4/17 no objection.

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -05)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -05)

                            

(Sean Turner; former steering group member) No Objection

No Objection (for -05)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2013-08-16 for -07)
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

No Objection (2013-06-24 for -05)
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

No Objection (2013-06-26 for -05)
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?