Subject: Re: [Geopriv] Your Postal Address vs your "real" address

From: [email-masked]
Date: Tue, 18 Jan 2005 10:56:37 -0500

Hi all,

Sorry to barge, since I have not been following this very closely until 
recently.  Please excuse my ignorance if I am going over old discussion or 
breaking some ground rules...

I would have a problem with ".. rely on some of the free-form fields ...", 
since the words "rely" and "free-form" do not mix well for 2 reasons: 1) 
it could be non-deterministic which specific fields were being used for 
what, hence difficult to parse and map reliably; 2) "free form" means just 
that -- the exact form is not predictable/reliable.  I believe it would be 
better to use a strict approach to crack this issue due to the unfortunate 
implications of getting it wrong.  (Would not want to send the fire truck 
to Mars, would we ;-)

It looks to me there is at least a risk of overloading of more than just 
the community name, so a general approach should be sought to apply to all 
CAtypes ... or choose not to solve the issue at all, just state CAtype is 
the legal address. 

As yet another suggestion, how about using a flag in the CAtype itself, 
say most significant bit, to indicate legal address part (0) vs postal 
(1).  Postal would be used only if they are different, ie the assumption 
would be that legal and postal addr are identical in the 99% case. 
Advantages would be it could apply to any or all of the other CAtypes, and 
would require only very minimal format change, not a replication of many 
CAtypes.  One issue is CAtype 128 is already allocated as "script" -- 
presumably this could simply be re-assigned (say to 64).  Also CAtype 255 
is reserved, but presumably could be moved to 127.  If we found a need for 
yet another flag type beyond legal or postal, then we'd be in trouble 
again...   Before others complain, yes I would also agree it would not be 
very pretty (full octet fields are more pleasing).  I expect this has been 
considered before.  However, could it be a quick and practical solution?

Other similar alternatives would be encoding similar flags into the What 
field (don't personally favor, since we could not encode both legal and 
postal at the same time), or add an octet field for "address class" say 
immediately before CAvalue (seems rather wasteful for a 1% case).

Cheers,
Peter Blatherwick

Henning Schulzrinne <[email-masked]>
Sent by: [email-masked]
17.01.05 17:10

        To:     Brian Rosen <[email-masked]>
        cc:     'Ted Hardie' <[email-masked]>, 'GEOPRIV WG' <[email-masked]>
        Subject:        Re: [Geopriv] Your Postal Address vs your "real" address

Another remark: I think with any address, being governed by history, 
customs and often designed in simpler times, we'll find exceptions and 
special cases that affect a relatively small fraction of users. One 
approach is not to try to solve the last fraction of problems in a 
structured way and rely on some of the free-form fields, for example LMK 
(CAtype=21) for "aliases" such as Ted's.

Brian Rosen wrote:
> Wow.
> 
> I can tell you that the 9-1-1 folks would have taken the postal address 
with
> the actual (MSAG or legal) community name as the address, although they
> don't really check out detail very much; they really go by what the 
service
> address listed in the telephone company records.  Of course, you care,
> because when the dispatcher reads out the address reported to the 
ambulance
> or fire department, you would like them to know where to go.
> 
> When a community first establishes so called "E911", "E" for "Enhanced" 
they
> get the municipalities to assign real street names, and the post office 
to
> assign unique street numbers, which is subsequently used by both the 
9-1-1
> system and the post office (albeit with potentially different community
> names), but they don't often back annotate the legal records with those
> addresses. 
> 
> I wouldn't really object to another entire address, although for the
> purposes of location in a DHCP query (or PIDF-LO), I think we get all 
the
> bang we need for the two MCN buck.  Your mileage may vary.
> 
> Brian
> 
> 
>>-----Original Message-----
>>From: Ted Hardie [mailto:[email-masked]]
>>Sent: Monday, January 17, 2005 3:24 PM
>>To: Brian Rosen; 'GEOPRIV WG'
>>Subject: RE: [Geopriv] Your Postal Address vs your "real" address
>>
>>At 2:35 PM -0500 1/17/05, Brian Rosen wrote:
>>
>>>Ted
>>>
>>>For the U.S., it's acceptable to just have the extra CAType.
>>
>>I am not sure that this is the case.  In a previous real estate
>>foray, I bought a house in the unincorporated section of a county.
>>The postal address was Number 1st Street Name, 1st Nearby Town, State,
>>ZIP.
>>The legal address was (Same Number) 2nd Street Name,
>>Unincorporated County Name, State, ZIP.  The  1st street name in case 
one
>>derived from a *different nearby town*, through which one had to
>>drive to reach the house; it did not exist at all in the legal delimits
>>of the 1st town.  The 2nd street did exist in the nearby town, but was
>>blocked
>>by a railroad track.  The upshot was that the tax payments
>>referenced one address, the postal mail had a different address
>>(including a different street name), and that ordering a taxi
>>or a pizza involved an explanation.   I am not sure what the
>>NENA standard would have said the MSAG was for that addresses.  Since 
the
>>emergency services are contracted to the town in the postal
>>address, the question isn't as simply as it might appear, since
>>there are lots of other unincorporated bits to that county and those
>>bits have other arrangements.
>>
>>The upshot of this is that I personally don't think adding a single 
CAType
>>will handle the wildness in the real world.  In the case of a real
>>human, the answer was to know both addresses and have both
>>ready, tagged, for when they were needed.  If we are going to head
>>down this road, I personally think that sort of mechanism might be more
>>effective.  That would mark a whole address as "postal" or
>>"emergency services" or something else.  But starting that discussion
>>at this point in the development of this document seems likely
>>to delay things in some problematic ways.
>>
>>What are other opinions on the CAType idea vs. other ways forward?
>>
>>(refrain:  Just ted's personal opinion),
>>                                               regards,
>>                                                               Ted
>>
>>
>>
>>>In NENA requirements, the State, Pre/Post directionals and suffix must
>>>follow USPS recommendations.  NENA standards carry both a "postal"
>>
>>community
>>
>>>name and an "MSAG" (i.e. legal) community name.  The post office always
>>
>>uses
>>
>>>the postal community name, and never needs, or wants, the legal one.
>>>
>>>The text you are citing would have the reported address be the legal
>>>address.  That would be satisfactory for emergency routing, but would
>>
>>make
>>
>>>the mechanism not very useful for most other purposes.  Almost all
>>>commercial services run off of postal addresses.  Even the emergency
>>
>>folks
>>
>>>really want both, because they ask you verbally for your address, and 
you
>>>almost always report your postal address when asked.  The call routing
>>
>>MUST
>>
>>>be on the legal community name, so if you have to pick one, the legal 
is
>>
>>the
>>
>>>right one.
>>>
>>>If I was only concerned with emergency services, then I would be okay
>>
>>with
>>
>>>the text as it stands.  As an IETF standard, we probably want both 
legal
>>
>>and
>>
>>>postal MCNs, and even the emergency folks usually want both.
>>>
>>>Brian
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ted Hardie [mailto:[email-masked]]
>>>> Sent: Monday, January 17, 2005 2:12 PM
>>>> To: Brian Rosen; 'GEOPRIV WG'
>>>> Subject: Re: [Geopriv] Your Postal Address vs your "real" address
>>>>
>>>> Brian,
>>>>             I don't understand this proposal.   Are you proposing
>>>> a CAType like:  legalTown, parallel to A3?  Or are you proposing
>>>> a full parallel structure, so that variations in the Postal
>>>> Address vs. Legal Address can occur at multiple levels?
>>>>
>>>> I also wonder if you are not reading too much into this:
>>>>
>>>>   US (United States): The mapping to NENA designations is shown in
>>>>        parentheses.  A1=state (STA), using the the two-letter state
>>
>>and
>>
>>>>        possession abbreviations recommended by the United States
>>
>>Postal
>>
>>>>        Service Publication 28 [15], Appendix B; A2=county (CNA);
>>
>>A3=civic
>>
>>>>        community name (city or town) (MCN); A6=street (STN).  A4 and
>>
>>A5
>>
>>>>        are not used.  The civic community name (MCN) reflects the
>>>
>>> >        political boundaries.  These may differ from postal delivery
>>>
>>>>        assignments for historical or practical reasons.
>>>>
>>>> Are you assuming that because Postal Service Publication
>>
>>recommendations
>>
>>>> are used that the civic community name chosen must be the one
>>>> that postal delivery would use?  I read the last sentence to mean
>>>> that they need not be, and that they could be the MCN most
>>>> appropriate for delivery of services, including emergency services.
>>>>                                             regards,
>>>>                                                             ted 
Hardie
>>>>
>>>>
>>>>
>>>> At 11:58 AM -0500 1/17/05, Brian Rosen wrote:
>>>> >In some areas, the Post Office, for historical, bureaucratic, and
>>
>>other
>>
>>>> >reasons, sometimes decides that your address for postal reasons is
>>
>>not
>>
>>>> the
>>>> >same as your actual, legal, address.
>>>> >
>>>> >In the U.S., the common difference is the "Municipality" name
>>>> (City/Town).
>>>> >My address is one of those.  My postal address is in Mars, PA.
>>
>>However,
>>
>>>> I
>>>> >actually live in Pine Township.  There turns out not to be a post
>>
>>office
>>
>>>> >called "Pine"; the residents of Pine Township may be served by the
>>
>>post
>>
>>>> >office in Wexford, Gibsonia or Mars.  There really is a Mars, PA, 
but
>>
>>it
>>
>>>> is
>>>> >located in the adjacent county.  There used to be a Gibsonia and a
>>>> Wexford,
>>>> >but they are now just part of Pine Township.
>>>> >
>>>> >While in most cases, if you need my address, you want my postal
>>
>>address,
>>
>>>> >there are several cases where that is incorrect, and can cause
>>>> significant
>>>> >problems.  One is emergency services.  Since Mars is in Butler
>>
>>County,
>>
>>>> and
>>>> >Pine is in Allegheny County, if you route an emergency call based on
>>
>>the
>>
>>>> >Mars address, you will send the call to the wrong place.  Also, if
>>
>>you
>>
>>>> >wanted to determine, for example, the appropriate library, or a
>>
>>polling
>>
>>>> >place, or any other of the myriad issues that are related to your
>>
>>legal
>>
>>>> >place of residence (or business), then you really want the actual
>>>> address.
>>>> >
>>>> >So, while for maybe 97% of the time postal address is correct, you
>>>> sometimes
>>>> >need the legal address.
>>>> >
>>>> >Neither PIDF-LO nor the civic DHCP option deals with this.
>>>> >
>>>> >I would like to specifically request that we allow another "CAType"
>>
>>in
>>
>>>> the
>>>> >DHCP civic option.  We'll deal with the PIDF-LO later.
>>>> >
>>>> >Brian
>>>> >
>>>> >
>>>> >
>>>> >_______________________________________________
>>>> >Geopriv mailing list
>>>> >[email-masked]
>>>> >https://www1.ietf.org/mailman/listinfo/geopriv
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Geopriv mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/geopriv
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Jan 2005 18:48:37 -0500

My general perception is that complexity in Internet standards follows

c = 1/(1 - x)

where x is the fraction of cases handled, i.e., this goes to infinity as 
one tries to handle all cases.

Since the 'what' field is currently describing the nature of the object 
placed (DHCP server, client, etc.), I'm guessing you're talking about a 
creating a different field. I think there are at least three plausible 
approaches, in increasing complexity:

(1) Assume that only the community name differs between jurisdictional 
and postal addresses (and deal with odd street situations by LMK 
indication) and add a postal community name. Given that the emergency 
services community has found this sufficient in four versions of systems 
designed since the 1970s, there is some indication that this is "good 
enough".

(2) Add a "shift" code, similar to the current language code, that 
indicates that subsequent CAtypes indicate the legal or postal (or 
possibly other) address types. You'd have something like

A1=NJ
A2=Bergen
A3=legaltown
A6=legalstreet
[postal]
A3=postaltown
A6=postalstreet

With the assumption that jurisdictional is the default.

(3) Add an enclosing label that groups all postal or jurisdictional 
fields, as in

[postal A1, A2, ...}
[jurisdictional A1, A2, ...}

where the [postal ...] indication would be a TLV that indicates the 
total length of all subtended TLVs.

I'm agnostic on choosing one. (3) is cleanest, but more of a change and 
marginally less efficient.

To avoid further delay, I'd like any quick input where people strongly 
favor one or the other.

Henning

[email-masked] wrote:
> recently.  Please excuse my ignorance if I am going over old discussion 
> or breaking some ground rules...
> 
> I would have a problem with ".. rely on some of the free-form fields 
> ...", since the words "rely" and "free-form" do not mix well for 2 
> reasons: 1) it could be non-deterministic which specific fields were 
> being used for what, hence difficult to parse and map reliably; 2) "free 
> form" means just that -- the exact form is not predictable/reliable.  I 
> believe it would be better to use a strict approach to crack this issue 
> due to the unfortunate implications of getting it wrong.  (Would not 
> want to send the fire truck to Mars, would we ;-)
> 
> the community name, so a general approach should be sought to apply to 
> all CAtypes ... or choose not to solve the issue at all, just state 
> CAtype is the legal address.
> 
>  Advantages would be it could apply to any or all of the other CAtypes, 
> and would require only very minimal format change, not a replication of 
> many CAtypes.  One issue is CAtype 128 is already allocated as "script" 
> -- presumably this could simply be re-assigned (say to 64).  Also CAtype 
> 255 is reserved, but presumably could be moved to 127.  If we found a 
> need for yet another flag type beyond legal or postal, then we'd be in 
> trouble again...   Before others complain, yes I would also agree it 
> would not be very pretty (full octet fields are more pleasing).  I 
> expect this has been considered before.  However, could it be a quick 
> and practical solution?
> 
> 	*Henning Schulzrinne <[email-masked]>*
>  > I can tell you that the 9-1-1 folks would have taken the postal 
> address with
>  > When a community first establishes so called "E911", "E" for 
> "Enhanced" they
>  > get the municipalities to assign real street names, and the post 
> office to
>  > purposes of location in a DHCP query (or PIDF-LO), I think we get all the
>  >>Unincorporated County Name, State, ZIP.  The  1st street name in case one
>  >>NENA standard would have said the MSAG was for that addresses.  Since the
>  >>>really want both, because they ask you verbally for your address, 
> and you
>  >>>be on the legal community name, so if you have to pick one, the legal is
>  >>
>  >>the
>  >>
>  >>>right one.
>  >>>
>  >>>the text as it stands.  As an IETF standard, we probably want both legal
>  >>
>  >>and
>  >>
>  ted Hardie
>  >>>> >office in Wexford, Gibsonia or Mars.  There really is a Mars, PA, but
>  >>
>  >>it
>  >>
>  >>>> is

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Jan 2005 19:24:39 -0500

I like (1), then (3).  I think (1) is enough.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Henning Schulzrinne
> Sent: Tuesday, January 18, 2005 6:49 PM
> To: [email-masked]
> Cc: 'GEOPRIV WG'; 'Ted Hardie'

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Jan 2005 16:42:57 -0800

Speaking personally, I think (3) is likely to handle later surprises
better than (1).  If we do (1) now, and know that we may have later
revisions, we may get (3) then.

I think (2) is not really a good approach.
			regards,
				Ted Hardie