Subject: Re: [Geopriv] call for consensus on postal address issue for dhcp-civil

From: [email-masked]
Date: Tue, 1 Feb 2005 11:55:01 -0500

Hmmm....  I had not responded since I was already active with opinion on 
the related threads. 

I do not think "no change" is an option, since thee are known cases where 
we need to distinguish jurisdictional from postal address (unless we were 
to rule one or the other out of scope).  My opinion:

Prefer option (2),  Add a "Shift" code CAtype, similar to the current 
language code, that indicates that subsequent CAtypes give the 
jurisdictional or postal.  Jurisdictional is the default.  This seems 
simple, extensible, and complete.

Second choice would be option (1), Add a postal community name CAtype 
only.  Covers the big known issue, but seems a bit of an odd-ball, would 
not cover any other case, and not as readily extensible to other similar 
needs.  I can live with it. 

Third choice would be option (3), Add an enclosing/encapsulating label 
that groups all postal or jurisdictional fields.  Seems more complex, more 
likely to extend the last call period and/or go back to further list 
discussion, does not appear to solve more than option 2 other than 
prettiness.

Cheers, 
Peter Blatherwick

Andrew Newton <[email-masked]>
Sent by: [email-masked]
01.02.05 10:54

        To:     GEOPRIV WG <[email-masked]>
        cc: 
        Subject:        Re: [Geopriv] call for consensus on postal address issue for    dhcp-civil

Given the total lack of discussion on this topic, is it reasonable to 
conclude that no changes are needed?  Is this also true for the 
common-policy draft?

-andy

_______________________________________________
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: Andrew Newton <[email-masked]>
Date: Tue, 1 Feb 2005 12:04:09 -0500

> simple, extensible, and complete.

And somehow I had missed this when I formulated my email last week 
though it is in the archives.

I don't think this group has come to consensus on this issue, so 
perhaps we ought to raise the discussion up a notch and evaluate which 
we value more: a quick and easy fix or a long-term solution.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 01 Feb 2005 13:12:43 -0500

I suspect all solutions work in some sense or another and there is 
probably no truly scientific way to pick one, as this hinges on 
anticipated future extensions and use cases. All approaches allow adding 
new types of data in a backward-compatible manner.

One of the issues discussed earlier was the ability to describe more 
complicated specifications, such as cross streets ("intersection of Elm 
and Main"). I suspect that (3) is the most future-proof of the approaches.

Purely from a client implementation standpoint, I find the encapsulation 
solution to be easiest. If I don't care about a particular address type, 
I just skip that block. (It's not quite that simple since we will need 
some notion of inheritance since we don't want to repeat the same 
information shared between different address formats. That is a problem 
shared by both the shift-code (2) and encapsulation (3) solution.)

However, from a server perspective, it's roughly the inverse. With 
existing DHCP servers, putting in (1) is easiest, even if you just have 
the ability to encode a new parameter as hex, a common approach. 
Encoding the encapsulation solution in hex seems very error-prone.

The simplest approach is yet another one, namely dedicating some bits of 
each tag to labeling the item as postal vs. jurisdictional.

(4) Tag each item with two bits of type and six bits of content. This 
allows four different types of addresses and allows any part of the 
address to be jurisdictional or postal (or two other designations). 64 
address label types are likely to be plenty unless people want to start 
encoding the paint color of the house and the brand of car parked in the 
driveway.

[email-masked] wrote:
> I do not think "no change" is an option, since thee are known cases 
> where we need to distinguish jurisdictional from postal address (unless 
> we were to rule one or the other out of scope).  My opinion:
> 
> that groups all postal or jurisdictional fields.  Seems more complex, 
> more likely to extend the last call period and/or go back to further 
> list discussion, does not appear to solve more than option 2 other than 
> prettiness.
> 
> Cheers,
> Peter Blatherwick
> 
> 
> 
> 
> 
> 	*Andrew Newton <[email-masked]>*
> ------------------------------------------------------------------------
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 1 Feb 2005 10:27:01 -0800

At 12:04 PM -0500 2/1/05, Andrew Newton wrote:
>>Prefer option (2),  Add a "Shift" code CAtype, similar to the 
>>current language code, that indicates that subsequent CAtypes give 
>>the jurisdictional or postal.  Jurisdictional is the default.  This 
>>seems simple, extensible, and complete.
>
>perhaps we ought to raise the discussion up a notch and evaluate 
>which we value more: a quick and easy fix or a long-term solution.

I ranked Henning's (3) above his (1) largely because I feel it can handle
a broader range of problems, should more than this narrow issue emerge.
If we go with "quick", I can certainly live with (1), but I suspect it means
we will revisit this later.
			regards,
				Ted

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 02 Feb 2005 12:22:23 -0600

>>simple, extensible, and complete.

Sorry Peter - but I do not like the "shift" approach. I prefer option #1, 
and clearly (to me) doing nothing is not an option either)

>And somehow I had missed this when I formulated my email last week though 
>it is in the archives.
>
>I don't think this group has come to consensus on this issue, so perhaps 
>we ought to raise the discussion up a notch and evaluate which we value 
>more: a quick and easy fix or a long-term solution.
>
>-andy
>
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented