Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
RFC 6848

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

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-10-22 for -09)
No email
send info
123 Colorado Boulevard is a real address
123A Main Street is likely a real address, there are enough 123Main Streets that one may well have and "A"

Shouldn't we be using example addresses?

I looked for, but did not see an identifier for a house with no number. Such houses exist:
Wentwood House, Upper Clapton Rd, London, Greater London E5 9BY, UK
High Farm, Farrar Lane Leeds LS16 7AQ
to take two random examples from Google.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-10-25 for -09)
No email
send info
I have no objection to the publication of this document.

I think the Security Considerations section would benefit from a direct
reference to RFC 3694 (rather than relying on the cascaded reference
though RFC 5139 and RFC 4119). In partcular, the addition of new
extensions makes the protection of location information by a user a more
complex matter and sections 4.3.1 and 5.1 of RFC 3694 could be called 
out. Essentially, inventors of new extensions need to told to make very
clear how naive users of geopriv systems will be able to protect their
LI.

I agree with Stewart's Comments.

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-12-05)
No email
send info
Version -10 fixes up my discuss points. Thanks!

- 3.2: I assume the length field includes the two spaces
so the description below should say "Length is the number of... 
plus 2" or similar. I think you might still usefully clarify that.

(Brian Haberman) No Objection

(Russ Housley) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2012-10-17 for -09)
No email
send info
Updated for version -09:

Version -08 addresses my DISCUSS points.
Version -09 addresses my non-blocking comments.

Thanks very much for considering my comments and making changes

Leaving one for amusement value:

-- Section 5.1 --
Excellent ASCII-art lamp post you got there.

(Pete Resnick) No Objection

Comment (2012-10-25 for -09)
No email
send info
3.2

Using space as a separator means that local name can have no spaces in it. Is that guaranteed by XML? Is there a reason not to use a leading length byte for each of the elements? Easier to parse.

   The content of a CAtype (after the CAtype code and length) is UTF-8
   encoded Unicode text [RFC3629].

So the URL must be US-ASCII. Probably best to say that. The local name also has some limitations I suppose. Saying the whole thing is UTF-8 is not helpful.

   This conversion only works for elements that have textual content and
   an optional "xml:lang" attribute.

I don't understand why this is the case.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection