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

I agree with Brian.
Nadine

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
Of Brian Rosen
Sent: Tuesday, January 18, 2005 7:25 PM
To: 'Henning Schulzrinne'; peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; 'Ted Hardie'
Subject: RE: [Geopriv] Your Postal Address vs your "real" address

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

Brian

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Henning Schulzrinne
> Sent: Tuesday, January 18, 2005 6:49 PM
> To: peter_blatherwick@mitel.com
> Cc: 'GEOPRIV WG'; 'Ted Hardie'
> Subject: Re: [Geopriv] Your Postal Address vs your "real" address
>
> 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
>
> peter_blatherwick@mitel.com wrote:
> >
> > 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 <hgs@cs.columbia.edu>*
> > Sent by: geopriv-bounces@ietf.org
> >
> > 17.01.05 17:10
> >
> >
> > To: Brian Rosen <br@brianrosen.net>
> > cc: 'Ted Hardie' <hardie@qualcomm.com>, 'GEOPRIV WG'
> > <geopriv@ietf.org>
> > 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:hardie@qualcomm.com]
> > >>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:hardie@qualcomm.com]
> > >>>> 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
> > >>>> >Geopriv@ietf.org
> > >>>> >https://www1.ietf.org/mailman/listinfo/geopriv
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>_______________________________________________
> > >>>Geopriv mailing list
> > >>>Geopriv@ietf.org
> > >>>https://www1.ietf.org/mailman/listinfo/geopriv
> > >>
> > >>
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 18 Jan 2005 19:55:03 -0500