Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)
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' **)
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
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.