Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)
RFC 5139

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

(Jari Arkko) Yes

(Cullen Jennings) Yes

(Jon Peterson) Yes

Comment (2007-11-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Nit in 3.2

   For example, both "West Alice Parade, Section 3" and "Bob Street"
   could both be interested by a "Carol Lane". 

I assume "interested" should be "intersected".

Nit in 3.6

   This
   ensures that the following fragments are considered equivalent by XML
   processors:

   <A4>North Wollongong</A4>

   <A1>North
     Wollongong</A1>

   <A1>
     North   Wollongong
     </A1>

Perhaps the first <A4> element should be an <A1> if these three fragments are indeed to be considered equivalent.

(Dan Romascanu) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Sam Hartman) No Objection

(Russ Housley) No Objection

(Chris Newman) (was Discuss) No Objection

Comment (2007-12-04)
No email
send info
Now that we resolved that language tags with script subtags are valid
in xml:lang, the remaining issue is just a missing reference, and I
don't want to hold a discuss position over a missing reference, but
still believe it should be fixed.  Here is a suggested fix:

---
Section 3.5
OLD:
   The "script" field defined in [RFC4776] is omitted in favour of using
   the "xml:lang" attribute.
NEW:
   The "script" field defined in [RFC4776] is omitted in favour of using
   the "xml:lang" attribute with a value that includes a script
   subtag [RFC4646].

Section 8.1
NEW:
   [RFC4646]           Phillips, A. and M. Davis, "Tags for Identifying
                       Languages", BCP 47, RFC 4646, September 2006.
---

--old comment, feel free to ignore:
I am dubious there is any significant value gained by structuring
civic location as anything other than 3-4 lines of UTF-8 text plus,
perhaps, the country code and the other properties common in Internet
commerce.  I suspect any users or operators who enter information will
do so as 3-4 lines of text and any structure will be heuristically parsed
in practice, meaning the fields will occasionally contain erroneous data.

I'm also concerned that the algorithm to display these structured
addresses in a human readable form is non-trivial in the international
scope and software is likely to get that wrong in practice.

(Tim Polk) (was No Record, Discuss) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection