Re: [Geopriv] WGLC on Revised Civic Draft

Henning Schulzrinne <hgs@cs.columbia.edu> Wed, 12 July 2006 18:34 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jXq-0007nY-PX; Wed, 12 Jul 2006 14:34:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jX3-00079C-M6 for geopriv@ietf.org; Wed, 12 Jul 2006 14:33:57 -0400
Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jJk-0000m6-Vr for geopriv@ietf.org; Wed, 12 Jul 2006 14:20:15 -0400
Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6CIK2vc015598 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 12 Jul 2006 14:20:03 -0400 (EDT)
In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF137516E@AHQEX1.andrew.com>
References: <E51D5B15BFDEFD448F90BDD17D41CFF137516E@AHQEX1.andrew.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <D1382B37-265E-4488-A05C-347982B21632@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Geopriv] WGLC on Revised Civic Draft
Date: Wed, 12 Jul 2006 14:20:02 -0400
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
X-Mailer: Apple Mail (2.752.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: Geopriv WG <geopriv@ietf.org>, Andrew Newton <andy@hxr.us>
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Errors-To: geopriv-bounces@ietf.org

> ... As described in [dhcp-civil], addresses are sometimes made up from
> components in different languages.  This format is intended to be used
> to be used in a single context, with either a single language, or a
> consistent set of languages.  To that end, the mapping from the
> [dhcp-civil] format is performed by first taking all unduplicated
> elements based on the mapping in [dhcp-civil] or this document.  Where
> elements are duplicated with different languages, a preferred  
> language -
> that might be based on the locale settings - is used to select a  
> value.
> In the absence of any language preference, the first element is
> selected.
>

I'm not sure whose locale one would use here. You generally don't  
know the locale of the PSAP, to pick up one example. Being in  
Montreal, would you choose the French or the English version when  
sending a request to some Canadian outfit?

>
> ... This field is used in preference to the "A6" element, which is, in
> the definition for A-fields some countries in [RFC4119], used for the
> street name.  See Section 3.2 (New Thoroughfare Elements).
>

I would simply state the A6 should only be used for road if the DHCP- 
civic element contains that element.


>> * "for a country subdivision SHOULD be used."
>>
>> Again, no guidance is given when this might not be done. Why not  
>> MUST?
>
> This was included for backward compatibility reasons.  DHCP-civil and
> 4119 are a little quiet on the exact format for A1 contents.  And  
> there
> is the concern that, maybe, not all nations have provided ISO with  
> their
> subdivision information.  Maybe I can think of some non-2119  
> language to
> use here instead, since I have begun to get an appreciation for not
> using those capitalized words.

I would have no problems with stating that countries that all  
countries that have ISO subdivisions MUST use the subdivision  
information; obviously, those that don't, can't. Clearly, if every  
implementor does what they feel like, we lose interoperability, so a  
SHOULD seems particularly inappropriate here.



>
> I will note that the similarity is entirely intentional.  Or, would  
> you
> prefer that I just make reference to your descriptions and omit these
> altogether?	
>

I would suggest one of two things (and I don't have strong opinions  
on which one is better):

- Repeat text, make sure it's exactly the same, and note that fact.  
(Since the RFC editor may tweak the DHCP-civil language, you would  
have to re-check the equality after DHCP-civil emerges as an RFC.)  
Has the advantage of making the document more self-contained.

- Reference DHCP-civil text and only add material.

Having text which is almost, but not completely, identical and where  
this isn't obvious to the reader seems like a not-so-good option.

Henning



_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv