Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt

From: Geoff Thompson <[email-masked]>
Date: Sun, 04 Jul 2010 12:45:13 -0700

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".

Geoff
> Message: 2
> Date: Sat, 3 Jul 2010 16:53:18 -0400
> From: Brian Rosen<[email-masked]>
> Subject: Re: [Geopriv] Fwd: I-D
> 	Action:draft-george-geopriv-lamp-post-00.txt
> To: Carl Reed<[email-masked]>
> Cc: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
> 	DelSp="yes"
>
> I am a co-author on this draft, and the milepost addition to the lamp
> post original was motivated by the NENA requirement to have a milepost.
>
> I agree that the MP nearly always needs a road name.  So does a house
> number.  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

---

From: Brian Rosen <[email-masked]>
Date: Sun, 4 Jul 2010 18:23:06 -0400

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".
>
> Geoff
>> Message: 2

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 5 Jul 2010 14:37:41 +0800

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian Rosen
> Sent: Monday, 5 July 2010 8:23 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-
> 00.txt
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Jul 2010 02:48:32 -0400

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

---

From: Geoff Thompson <[email-masked]>
Date: Mon, 05 Jul 2010 11:27:40 -0700

Brian-

It seems to me that this is somewhat different than "if you don't have 
an element, you don't include it".
The cases you cite are more "we do have the element, the known name is 
an empty value".
     (that being significantly different from "unknown" or unsupplied 
for an unknown reason)

It seems simpler to change the syntax than to do something like what the 
US Feds did a number of years ago.  That was to decree that (in order to 
qualify for federal money for local rescue squads) every house in your 
area had to have a street address with both a registered street name 
(beit a private or public street) and a monotonic "house" number.  No 
surprise, that imposed a significant real world implementation burden 
with lots of hangover.

I look forward to the feedback from the cognoscenti

Geoff

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Jul 2010 14:36:52 -0400

I admit that I fail to see the practical difference for software. You can obviously already specify an empty field if you really insist, but there are two cases:

- the recipient needs the information - being told that we know it to be empty isn't too helpful, since that's not a legal value

- the recipient doesn't need the information - whether this is <foo/> or just omitted makes no difference.

We should strive to keep things simple - special cases that are likely to be done wrong in practice don't seem to help here.

Henning

On Jul 5, 2010, at 2:27 PM, Geoff Thompson wrote:

> Brian-
> 
> It seems to me that this is somewhat different than "if you don't have an element, you don't include it".
> The cases you cite are more "we do have the element, the known name is an empty value".
>    (that being significantly different from "unknown" or unsupplied for an unknown reason)
> 
> It seems simpler to change the syntax than to do something like what the US Feds did a number of years ago.  That was to decree that (in order to qualify for federal money for local rescue squads) every house in your area had to have a street address with both a registered street name (beit a private or public street) and a monotonic "house" number.  No surprise, that imposed a significant real world implementation burden with lots of hangover.
> 
>> 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.
>> 
>>> 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".
>>> 
>>> Geoff
>>>> Message: 2

---

From: Geoff Thompson <[email-masked]>
Date: Mon, 05 Jul 2010 11:51:59 -0700

Henning-
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:
>>>>> I am a co-author on this draft, and the milepost addition to the
>>>>>            
>>> lamp
>>>        
>>>>> I agree that the MP nearly always needs a road name.  So does a
>>>>>            
>>> house
>>>