Your point about "an address may be sufficient for one purpose and useless for another" is certainly true.
Real world example, valid at least in the USA, is that the address for parcel delivery (e.g. UPS, FedEx, Pizza Hut) and emergency services may well be invalid for postal delivery (e.g. Post Office box with an entirely different post code)
Geoff
On 4/7/10 11:48 PM, Henning Schulzrinne wrote:
Agreed. In addition, the element generating the content may not be fully aware of these conventions, so it is difficult for the origin to know in many cases whether an address is complete, exists, sufficient, etc. Plus, an address may be sufficient for one purpose (e.g., for some routing purposes, you may not need the house number or apartment number) and useless for another (mail delivery pretty much requires a house number, and maybe even an apartment number and postal code). Henning On Jul 5, 2010, at 2:37 AM, Thomson, Martin wrote:This problem is not just limited to these conventions for thoroughfares. The interpretation of many parts of a civic address rely on the context provided by other elements. The solution is really simple. Don't omit useful stuff. A postal worker that receives a letter addressed to "1600 (absent) Avenue" is well-justified if she decides that she is not going to deliver the letter [1]. If you want to ensure that the letter gets delivered, you put the rest of the address in. No different here. Any system of constraints is likely to fail internationally. Making house number relative to the thoroughfare is not possible. There is the thoroughfare branching we encountered, which would complicate it. The perfectly logical numbering system employed by the Japanese for house numbering, which is relative to the block [1], would make it even more difficult to codify. --Martin [1] No allowances made for overly zealous posties who know that there is only one 1600 on an Avenue in the city and deliver the letter anyway. [2] http://en.wikipedia.org/wiki/House_numbering#Japan_and_Korea-----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, 5 July 2010 8:23 AM To: thompson@ieee.org Cc: geopriv@ietf.org Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post- 00.txt While I do want to change the basic way the PIDF schema is defined, enforcing a restriction in the schema seems like a poor choice. I am loth to define a null road name; that's a big change to the way PIDF works; if you don't have an element, you don't include it, rather than include it with a null value. I'll ask around the PIDF cognoscenti to see what they think. Brian On Jul 4, 2010, at 3:45 PM, Geoff Thompson wrote:Brian- It seems lik a bad idea to let perfectly good assumptions (like a MP or a house number "needs" a road name) get screwed up by unusual exception as you have noted. Why not, instead, just charge ahead but allow a special value of road name ("NULL" ?) that notes that in this case it is known that a road name does not exist? The entered value should probably be differentiated from that which would be provided if the value of road name were "unknown". GeoffMessage: 2 Date: Sat, 3 Jul 2010 16:53:18 -0400 From: Brian Rosen<br@brianrosen.net> Subject: Re: [Geopriv] Fwd: I-D Action:draft-george-geopriv-lamp-post-00.txt To: Carl Reed<creed@opengeospatial.org> Cc: geopriv@ietf.org Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" I am a co-author on this draft, and the milepost addition to thelamppost original was motivated by the NENA requirement to have a milepost. I agree that the MP nearly always needs a road name. So does ahousenumber. The current documents don't have requirements like that, primarily because we keep finding odd cases that don't meet what we thought was a simple rule. Brian_______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv_______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv
