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

From: "Abbott, Nadine B." <[email-masked]>
Date: Tue, 18 Jan 2005 19:55:03 -0500

I agree with Brian.
Nadine

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Tuesday, January 18, 2005 7:25 PM
To: 'Henning Schulzrinne'; [email-masked]
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: [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'
> 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
> 
> [email-masked] 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 <[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
> 

_______________________________________________
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: [email-masked]
Date: Wed, 19 Jan 2005 17:06:57 -0500

Resending ... with sniggage.  Previous send stuck waiting moderator due to 
size limit. 
-- Peter

Peter Blatherwick
19.01.05 15:38

        To:     "Abbott, Nadine B." <[email-masked]>, "'Ted Hardie'" 
<[email-masked]>, "Brian Rosen" <[email-masked]>, "'Henning 
Schulzrinne'" <[email-masked]>
        cc:     "'GEOPRIV WG'" <[email-masked]>, [email-masked]
        Subject:        RE: [Geopriv] Your Postal Address vs your "real" address

Hi all, walking through the alternatives out loud, 

I am inclined to agree that we *could* go with (1), however that is 
admittedly driven by its expediency, not as a clean solution.  See it as 
an odd approach to have an exception CAtype, and a risk of having to 
create a bunch more in future and/or work-around with free-form fields 
(which I disagree with). 

I kinda like (2), since it would add a new "delimiter" CAtype, and not 
need to add overhead except in those 1% cases.  Seems pretty clean and 
clear, more or less in line with Language and Script CAtype, extensible 
should we ever find further similar needs, looks fairly easily added to 
spec in an non-controversial way. 

I don't fully understand what (3) is proposing -- unclear exactly how the 
encapsulation would work.  However, not keen to add overhead to all for a 
1% issue.  Also introduces most change, hence would be more likely to need 
a bunch of work, back to the list for comment, more last call, yadda 
yadda...

Conclusion:  Overall, I prefer (2), assuming it would not cause a large 
delay in getting the RFC out there.  (1) would be the backup plan.   Sorry 
to not agree precisely with anyone so far...

BTW, the proposal I sent earlier was to add a flag into CAtype, indicating 
legal vs postal, not to modify or extend the What field (although that 
could be a similar option, not preferred for reason spelled out).  I take 
it a ground rule is to use full octet size fields, ie no bit flags?!   If 
not, still see it as option (4).

Cheers,
Peter

"Abbott, Nadine B." <[email-masked]>
Sent by: [email-masked]
18.01.05 19:55

        To:     "'GEOPRIV WG'" <[email-masked]>
        cc: 
        Subject:        RE: [Geopriv] Your Postal Address vs your "real" address

I agree with Brian.
Nadine

-----Original Message-----

Brian

> > "address class" say immediately before CAvalue (seems rather 

[snip]

---

From: "Abbott, Nadine B." <[email-masked]>
Date: Thu, 20 Jan 2005 08:41:59 -0500

James,
 
Maybe I didn't understand completely, but I didn't see anything in option 1
that would preclude sending both postal and jurisdictional communities, if
desired?
 
Nadine

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James Winterbottom
Sent: Wednesday, January 19, 2005 6:05 PM
To: [email-masked]
Cc: 'GEOPRIV WG'; [email-masked]
Subject: RE: [Geopriv] Your Postal Address vs your "real" address

Peter,
 
The CAType is all very well for the client, but once this information gets
assimilated into a PIDF-LO object, and it gets sent to someone, how do they
know how to interpret the information as legal or postal since they are not
privy to what was included in the CAType. What the information represents
needs to be included in the data object itself, not only in the
deterministic protocol. Options 2 and 3 imply that there is a need for both
jurisdictional and postal to be sent at the same time which I am not sure is
necessary. Given this I am inclined to agree with Brian and Nadine.
 
Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, 20 January 2005 9:07 AM
To: Abbott, Nadine B.; 'Ted Hardie'; Brian Rosen; 'Henning Schulzrinne'
Cc: 'GEOPRIV WG'; [email-masked]
Subject: RE: [Geopriv] Your Postal Address vs your "real" address

	Peter Blatherwick 

19.01.05 15:38 

        To:        "Abbott, Nadine B." <[email-masked]>, "'Ted
Hardie'" <[email-masked]>, "Brian Rosen" <[email-masked]>, "'Henning
Schulzrinne'" <[email-masked]> 
        cc:        "'GEOPRIV WG'" <[email-masked]>,
[email-masked] 
        Subject:        RE: [Geopriv] Your Postal Address vs your "real"
addressLink
<Notes:///85256D01005DDBFE/DABA975B9FB113EB852564B5001283EA/3E8FA843311AFEBC
85256F8E00055C4A> 	

I am inclined to agree that we *could* go with (1), however that is
admittedly driven by its expediency, not as a clean solution.  See it as an
odd approach to have an exception CAtype, and a risk of having to create a
bunch more in future and/or work-around with free-form fields (which I
disagree with).   

I kinda like (2), since it would add a new "delimiter" CAtype, and not need
to add overhead except in those 1% cases.  Seems pretty clean and clear,
more or less in line with Language and Script CAtype, extensible should we
ever find further similar needs, looks fairly easily added to spec in an
non-controversial way. 

I don't fully understand what (3) is proposing -- unclear exactly how the
encapsulation would work.  However, not keen to add overhead to all for a 1%
issue.  Also introduces most change, hence would be more likely to need a
bunch of work, back to the list for comment, more last call, yadda yadda... 

BTW, the proposal I sent earlier was to add a flag into CAtype, indicating
legal vs postal, not to modify or extend the What field (although that could
be a similar option, not preferred for reason spelled out).  I take it a
ground rule is to use full octet size fields, ie no bit flags?!   If not,
still see it as option (4). 

Cheers, 
Peter 

18.01.05 19:55 

        To:        "'GEOPRIV WG'" <[email-masked]> 
        cc:         
        Subject:        RE: [Geopriv] Your Postal Address vs your "real"
address	

I agree with Brian.
Nadine

-----Original Message-----

Brian

[snip]

---

From: "James Winterbottom" <[email-masked]>
Date: Fri, 21 Jan 2005 09:29:55 +1100

Hi Henning,

By insufficient fields I did mean the PIDF-LO and not the CAtypes, thanks
for the clarification.

So an alternative to simply bunging all of the fields into the one LO, might
be to include a sub parameter in the location request to indicate if you
want Postal or jurisdictional address.

Cheers
James

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, 21 January 2005 9:24 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: Abbott, Nadine B.; 'GEOPRIV WG'
Subject: Re: [Geopriv] Your Postal Address vs your "real" address

I'm not sure what you mean by "insufficient fields", but there are 
plenty (256) CAtypes available, of which we're only using fewer than 30. 
I do agree that the translation into PIDF-LO is an issue to be 
considered, but given the different structures, they'll always look a 
bit different. For example, it is possible that a particular application 
will only include the jurisdictional address, not the postal one, 
ignoring any postal-address related fields conveyed by DHCP. In a 
separate conversation, we're discussing that there are likely to be 
multiple location objects, labeled by Content-Disposition, which would 
indicate the object (home, current) and type (jurisdictional, postal) of 
address.

James Winterbottom wrote:
> Nadine,
>  
> Depending on how different these two things turn out to be, there may 
> be
> insufficient fields to accommodate sending both in option 1.
>  
> Cheers
> James
> 
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Abbott, Nadine B.
>     *Sent:* Friday, 21 January 2005 12:42 AM
>     *To:* 'GEOPRIV WG'
>     *Subject:* RE: [Geopriv] Your Postal Address vs your "real" 
> address
> 
>     James,
>      
>     Maybe I didn't understand completely, but I didn't see anything in
>     option 1 that would preclude sending both postal and jurisdictional
>     communities, if desired?
>      
>     Nadine
> 
>         *From:* [email-masked]
>         [mailto:[email-masked]] *On Behalf Of *James
Winterbottom
>         *Sent:* Wednesday, January 19, 2005 6:05 PM
>         *To:* [email-masked]
>         *Cc:* 'GEOPRIV WG'; [email-masked]
>         *Subject:* RE: [Geopriv] Your Postal Address vs your "real" 
> address
> 
>         Peter,
>          
>         The CAType is all very well for the client, but once this
>         information gets assimilated into a PIDF-LO object, and it gets
>         sent to someone, how do they know how to interpret the
>         information as legal or postal since they are not privy to what
>         was included in the CAType. What the information represents
>         deterministic protocol. Options 2 and 3 imply that there is a
>         need for both jurisdictional and postal to be sent at the same
>         time which I am not sure is necessary. Given this I am inclined
>         to agree with Brian and Nadine.
>          
>         Cheers
>         James
>          
> 
>             *From:* [email-masked]
>             [mailto:[email-masked]] *On Behalf Of
>             [email-masked]
>             *Sent:* Thursday, 20 January 2005 9:07 AM
>             *To:* Abbott, Nadine B.; 'Ted Hardie'; Brian Rosen; 'Henning
>             Schulzrinne'
>             *Cc:* 'GEOPRIV WG'; [email-masked]
>             *Subject:* RE: [Geopriv] Your Postal Address vs your "real"
>             address
> 
> 
>             Resending ... with sniggage.  Previous send stuck waiting
>             moderator due to size limit.
>             -- Peter
> 
> 
> 
> 
>             	*Peter Blatherwick*
> 
>             19.01.05 15:38
> 
>             	
>                     To:        "Abbott, Nadine B."
>             <[email-masked]>, "Brian Rosen" <[email-masked]>,
>             "'Henning Schulzrinne'" <[email-masked]>
>                     Subject:        RE: [Geopriv] Your Postal Address vs
>             your "real" addressLink
>             
> <Notes:///85256D01005DDBFE/DABA975B9FB113EB852564B5001283EA/3E8FA84331
> 1AFEBC85256F8E00055C4A>
> 
> 
> 
>             I am inclined to agree that we *could* go with (1), however
>             that is admittedly driven by its expediency, not as a clean
>             solution.  See it as an odd approach to have an exception
>             CAtype, and a risk of having to create a bunch more in
>             future and/or work-around with free-form fields (which I
>             disagree with).
> 
>             I kinda like (2), since it would add a new "delimiter"
>             CAtype, and not need to add overhead except in those 1%
>             cases.  Seems pretty clean and clear, more or less in line
>             with Language and Script CAtype, extensible should we ever
>             find further similar needs, looks fairly easily added to
>             I don't fully understand what (3) is proposing -- unclear
>             exactly how the encapsulation would work.  However, not keen
>             to add overhead to all for a 1% issue.  Also introduces most
>             change, hence would be more likely to need a bunch of work,
>             back to the list for comment, more last call, yadda 
> yadda...
> 
>             Conclusion:  Overall, I prefer (2), assuming it would not
>             cause a large delay in getting the RFC out there.  (1) would
>             be the backup plan.   Sorry to not agree precisely with
>             anyone so far...
> 
>             BTW, the proposal I sent earlier was to add a flag into
>             CAtype, indicating legal vs postal, not to modify or extend
>             the What field (although that could be a similar option, not
>             preferred for reason spelled out).  I take it a ground rule
>             is to use full octet size fields, ie no bit flags?!   If
>             	*"Abbott, Nadine B." <[email-masked]>*
>             From: [email-masked]
>             [mailto:[email-masked]] On Behalf
>             Of Brian Rosen
> ----------------------------------------------------------------------
> --
>