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

From: [email-masked]
Date: Tue, 1 Feb 2005 12:31:42 -0500

Hi again,
Personally, I believe option (2) is both quick-and-easy and a long term 
solution.  Just my 0.02, since I have not been involved in this list until 
relatively recently.
-- Peter

Andrew Newton <[email-masked]>
01.02.05 12:04

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

On Feb 1, 2005, at 11:55 AM, [email-masked] 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.

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

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

---

From: [email-masked]
Date: Tue, 1 Feb 2005 14:05:21 -0500

Hi Henning,

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

Don't really agree with you there, or at least I do not see it 
as significantly easier since looking at a tag and skipping until 
you see one you want is extremely simple anyway.

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

The issue of repeating information would be easily handled in option 
(2), simply by defining the rules a bit more clearly.  If there is no 
leading jusrisdictional or postal tag, then the information is 
considered to be common to both.  Lets remember that is the 95% case. 

I would want to avoid 'inheritance' or other higher order concepts here. 
Let's keep it really simple, until we find some big reason not to be. 

-- Peter

Henning Schulzrinne <[email-masked]>
01.02.05 13:12

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

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