RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise

["Brian Rosen" <br at brianrosen.net>]

Well of course the choice bit on this is:
> In short, I don't see a need for going postal.
with which I totally agree.

I think we make way too much out of postal beyond what we have (PCN).

One more piece of info:
Post Office Boxes are around in various forms in various countries.  In the
U.S., it used to be common to use them for rural addressing of mail.  That
has largely disappeared.  Locations get street addresses, and they get them
because 9-1-1 requires them, and the post office goes along with the
addressing authorities.  It's not completely gone, because there are still
some areas of the country that don't have "E9-1-1", where the "E" is the
part that has automatic location showing up with the call.  Where E9-1-1 is
implemented, every actual house/farm/store/factory/... location which gets
mail has a street address.

Post Office Boxes still exist in the U.S. as mailing destinations where the
box is actually in the post office.  The thing is, that's not a location as
Geopriv would define it.

So, please, let's get rid of postalCivic and jurisdictionalCivic as protocol
elements.  It sometimes helps to explain the issues (for example, in
ecrit-framework), but we don't need protocol mechanisms beyond PCN to
represent location for the U.S.  I would not claim to speak for other
countries, but so far, we don't have any conflicting information from other
countries.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> Sent: Thursday, September 13, 2007 10:15 PM
> To: Stark, Barbara
> Cc: GEOPRIV
> Subject: Re: [Geopriv] "Postal" and "Jurisdicational" civic locations -
> reprise
> 
> The usage of 'postal' has caused a fair amount of confusion, since it
> tends to conflate several different things:
> 
> (1) a street address, possibly with a different postal community name
> (PCN), which we already have in PIDF;
> 
> (2) special street-like addresses, such as rural carrier routes, that
> are only used for postal delivery and are meaningless to anybody else;
> 
> (3) post office boxes
> 
> (4) short addresses that only contain, say, organization name, city
> and zip code, such as those used for the Internal Revenue Service in
> the United States (example: IRS, Fresno, CA 93888-0002)
> 
> Our definition of 'civic' has always only included (1), as only that
> form satisfies the pizza delivery test. If you can't get pizza
> delivered to it, it's beyond our scope. If it weren't so long and
> unwieldy, we'd say a "(common) civic address as used by the postal
> service".
> 
> Brian has asked this before and the only interesting case that we are
> concerned about is whether there are multiple interesting forms of
> (1) that we need to distinguish, i.e., that are not just internal
> aliases of each other. (Aliases can occur, for example, if a street
> is renamed and the old name is still accepted for postal delivery.)
> So far, the conclusion seems to be 'no'.
> 
> Fortunately, we don't have to solve this problem now. If a new
> address-like place naming form is discovered somewhere, we can add it
> later, once we actually understand it and can name it.
> 
> In many cases, we'll only need to add information elements, as long
> as each (1) civic address has a single defined value. For example, if
> we wanted to add a carrier route indication, we can just add a
> corresponding label, since each house/apartment is on exactly one
> route. Clearly, for PO boxes, there is no such direct equivalence.
> 
> In short, I don't see a need for going postal.
> 
> Henning
> 
> On Sep 13, 2007, at 7:51 PM, Stark, Barbara wrote:
> 
> > The reason for wanting a postal address would likely be because the
> > device user wants to have something mailed or delivered. If this is
> > true, then the goal of a "postal" request should be to get the
> > location where mail and packages should be sent, and not
> > necessarily the actual location where the device is. These
> > locations may be the same or they may be different, as Jerome and
> > Guy described.
> >
> > On the other hand, if we insist that postal formulations must still
> > describe the actual physical location and not necessarily a mailing
> > address, then I don't see what compelling use there is for such a
> > distinction.
> >
> > If people want the mailing address, I can see the potential use,
> > but I don't care whether we do that or not. On the other hand, if
> > people want a postal-only formulation of a physical location, which
> > may or may not be useful for shipping packages and sending mail,
> > then I don't get it.
> >
> > As a potential LIS implementer, I don't really see the need for the
> > complexity of having separate street names stored for various
> > locations, for the special cases where they differ. Which means, I
> > wouldn't plan on it. Let someone use a street-name mapping
> > function. Besides, the location data we have in our database has 9-
> > digit zip in most cases. It's real easy to do a reverse lookup to
> > get the official postal street name, given a 9-digit zip code.
> >
> > So let me ask -- is "postal" supposed to be the address where
> > people at the current location get mail? If it can't be used to
> > send mail, then where's the value in providing a LO with only the
> > postal fields in it?
> > Barbara
> >
> > From: Winterbottom, James [mailto:James.Winterbottom at andrew.com]
> > Sent: Thursday, September 13, 2007 4:39 PM
> > To: Stark, Barbara; Marc Berryman; Mary Barnes; geopriv at ietf.org
> > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic
> > locations - reprise
> >
> > Hi Barbara,
> >
> >
> >
> > I am a little confused by this response.
> >
> >
> >
> > Expressing the civic location types in the PIDF-LO is one issue.
> >
> > Being able to request just a jurisdictional civic, or just a postal
> > civic using HELD is a different issue.
> >
> >
> >
> > I don't think issue one is really resolved, but I also don't think
> > that it has any direct bearing on issues 2.
> >
> >
> >
> > Your last sentence makes me think that you see some benefit in
> > leaving jurisdictionalCivic and postalCivic in HELD. Is that right?
> >
> >
> >
> > Cheers
> >
> > James
> >
> >
> >
> >
> >
> > From: Stark, Barbara [mailto:bs7652 at att.com]
> > Sent: Friday, 14 September 2007 3:51 AM
> > To: Marc Berryman; Mary Barnes; geopriv at ietf.org
> > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic
> > locations - reprise
> >
> >
> >
> > The impression I was left with, was that it was possible to
> > describe a particular physical civic location with a single PIDF-
> > LO. Within that LO there may be jurisdictional and postal fields.
> > These are already defined in the PIDF-LO docs. The street address
> > (and possibly the jurisdictional community name) may have several
> > (not just 2) "correct" ways to express it, but it should be
> > possible to translate from one to another, so only one needs to be
> > kept in the LIS.
> >
> >
> >
> > What appeared to be touched on, but never really discussed, was
> > whether there needed to be the ability to say "I would like to have
> > the mailing address for where I am." As Guy and Jerome mentioned,
> > the location of the mailbox does not necessarily coincide with the
> > physical location of the device making the request.
> >
> >
> >
> > So, I don't see value in separate jurisdictional and postal
> > requests to describe a single physical location, because both
> > should be expressible within a single PIDF-LO. There MAY be value
> > in being able to request the mailing address for a physical location.
> >
> > Barbara
> >
> >
> >
> > From: Marc Berryman [mailto:MBerryman at 911.org]
> > Sent: Thursday, September 13, 2007 12:08 PM
> > To: Mary Barnes; geopriv at ietf.org
> > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic
> > locations - reprise
> >
> > Mary,
> >
> >  I do not think that Jurisdiction and Postal need to be the same,
> > often they are not the same, since postal rarely follows the same
> > "boundaries" as jurisdictional. Since they may, or may not, be the
> > same is the reason they are both included. You can not assume they
> > are the same.
> >
> >
> >
> > Marc B
> >
> >
> >
> > Marc Berryman, ENP
> > Geographic Information Systems
> > Greater Harris County 9-1-1 Emergency Network
> > Houston, Texas      (713) 407-2254
> > mberryman at 911.org
> >
> > From: Mary Barnes [mailto:mary.barnes at nortel.com]
> > Sent: Thursday, September 13, 2007 11:02 AM
> > To: geopriv at ietf.org
> > Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations -
> > reprise
> >
> >
> >
> > Hi all,
> >
> > This thread never seemed to conclude with clear consensus as to
> > whether folks see a need for both these specific location types
> > rather than being able to use a common "civic" locationType.     I
> > went back through the threads and the majority of the responses
> > indicated that both of the values should be the same (with Canada
> > being the exception?).   Since the thread did diverge somewhat
> > (into how conversions etc. are done), I would like to do a quick
> > query to see if folks are okay with removing those two values from
> > the locationType in the HELD draft?
> >
> > And, just to be precise, we're proposing changing locationType from
> > a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic,
> > locationURI} to a set of
> >
> > {any, civic, geodetic, locationURI}.
> >
> > Regards,
> > Mary
> > Editor HELD
> >
> >
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > --------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> > ----------------------------------------------------------------------
> > --------------------------
> > [mf2]
> > *****
> >
> > The information transmitted is intended only for the person or
> > entity to which it is addressed and may contain confidential,
> > proprietary, and/or privileged material. Any review,
> > retransmission, dissemination or other use of, or taking of any
> > action in reliance upon this information by persons or entities
> > other than the intended recipient is prohibited. If you received
> > this in error, please contact the sender and delete the material
> > from all computers. GA621
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv at ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv



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