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

From: "James Winterbottom" <[email-masked]>
Date: Fri, 21 Jan 2005 08:19:07 +1100

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

-----Original Message-----
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

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

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"
addressLink
<Notes:///85256D01005DDBFE/DABA975B9FB113EB852564B5001283EA/3E8FA843311AFEBC
85256F8E00055C4A> 	

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

[snip] 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Jan 2005 17:23:43 -0500

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:
>     *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]>, "'Ted Hardie'"
>             <[email-masked]>, "Brian Rosen" <[email-masked]>,
>             "'Henning Schulzrinne'" <[email-masked]>
>                     Subject:        RE: [Geopriv] Your Postal Address vs
>             your "real" addressLink
>             <Notes:///85256D01005DDBFE/DABA975B9FB113EB852564B5001283EA/3E8FA843311AFEBC85256F8E00055C4A>
> 
> 
> 
>             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]>*
>             From: [email-masked]
>             [mailto:[email-masked]] On Behalf
>             Of Brian Rosen
> ------------------------------------------------------------------------
>