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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
Of James Winterbottom
Sent: Wednesday, January 19, 2005 6:05 PM
To: peter_blatherwick@mitel.com
Cc: 'GEOPRIV WG'; geopriv-bounces@ietf.org
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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
Of peter_blatherwick@mitel.com
Sent: Thursday, 20 January 2005 9:07 AM
To: Abbott, Nadine B.; 'Ted Hardie'; Brian Rosen; 'Henning Schulzrinne'
Cc: 'GEOPRIV WG'; geopriv-bounces@ietf.org
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." <nabbott@telcordia.com>, "'Ted
Hardie'" <hardie@qualcomm.com>, "Brian Rosen" <br@brianrosen.net>, "'Henning
Schulzrinne'" <hgs@cs.columbia.edu>
        cc: "'GEOPRIV WG'" <geopriv@ietf.org>,
geopriv-bounces@ietf.org
        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." <nabbott@telcordia.com>
Sent by: geopriv-bounces@ietf.org

18.01.05 19:55

        
        To: "'GEOPRIV WG'" <geopriv@ietf.org>
        cc:
        Subject: 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

[snip]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 20 Jan 2005 08:41:59 -0500