Subject: [Geopriv] WGLC on Revised Civic Draft

From: Andrew Newton <[email-masked]>
Date: Wed, 12 Jul 2006 10:00:23 -0400

All,

This is an announcement for a GEOPRIV working group last call on  
"Revised Civic Location Format for PIDF-LO" (draft-ietf-geopriv- 
revised-civic-lo-02.txt).

Here is a link to the document:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-revised-civic- 
lo-02.txt

Please send all comments, concerns, and considerations to this list  
no later than 2 August 2006.

-andy, as GEOPRIV co-chair

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2006 10:24:41 -0400

* SHOULD  in Section 3.5: No guidance is given when this  
recommendation is to be violated. Is there ever a reason not to do  
that? (The main issue is the mapping of DHCP-civil to PIDF-LO. Some  
additional guidance or a pointer to guidance would be helpful, as a  
mixed-language DHCP-civil element would effectively have to be  
expanded into multiple PIDF-LO civicAddress elements, with the common  
information replicated across all such elements.)

* "In most countries, this field should be used in preference to the  
"A6"
       element, which was previously used for street information."

Is this a SHOULD? Is there a reason not to do this is general?  
(Again, the only reason I can think of is translation from DHCP- 
civil. Or should an A6 in DHCP-civil be transformed into a Primary  
Road Name?)

* "for a country subdivision SHOULD be used."

Again, no guidance is given when this might not be done. Why not MUST?

* may [be] used to describe a civic location.

* I-D.ietf-geopriv-location-types-registry  --> update to RFC reference

One basic concern is that the text replicates text which is in dhcp- 
civil. I haven't done a careful word-by-word comparison, but it would  
be useful to indicate whether the authors intend this to be word-by- 
word the same or whether we expect the text descriptions to diverge.  
We can still make minor tweaks in AUTH48 for dhcp-civil, but major  
changes are unlikely to be well-received. The text in revised-civic  
should probably indicate whether the text similarity is intentional  
or coincidence.

On Jul 12, 2006, at 10:00 AM, Andrew Newton wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-revised- 
> civic-lo-02.txt
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 Jul 2006 10:46:19 -0500

Thanks for the comments Henning.  You have offered no suggestions, but
it looks like most of these can be addressed relatively easily.  I'll
make my suggestions inline.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 13 July 2006 12:25 AM
> To: Andrew Newton
> Cc: Geopriv WG
> Subject: Re: [Geopriv] WGLC on Revised Civic Draft
> 

As I have learnt, SHOULDs do require this additional information, which
you have exactly right.  As you highlight in DHCP-civi[lc] there are
times when an address needs to be specified in two languages.  This is
why the SHOULD exists.  However, this is a good comment; I will replace
this with the following text, which makes the usage much clearer:

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

> civil. Or should an A6 in DHCP-civil be transformed into a Primary

What do you suggest?  The mapping from DHCP-civil to this form is going
to be direct; there is no way I want to suggest that A6 -> RD or any
other combination of strange mappings.  I think that I will change the
description to:

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

> 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-D.ietf-geopriv-location-types-registry  --> update to RFC
reference

Easy fix, will do.

> should probably indicate whether the text similarity is intentional

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?	 

Cheers,
Martin
 
> > -andy, as GEOPRIV co-chair

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2006 14:20:02 -0400

> In the absence of any language preference, the first element is

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?

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

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

> prefer that I just make reference to your descriptions and omit these

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 Jul 2006 13:40:24 -0500

Inline...

> Sent: Thursday, 13 July 2006 4:20 AM
> To: Thomson, Martin
> Cc: Andrew Newton; Geopriv WG

Presumably, you either have a preference and you can act on that, or, if
you are forced to make a choice without this knowledge, the provider of
the information can order the information in a way that ensures that you
get the information that they know works.

> civic element contains that element.

This is now merely a note that points out that A6 MIGHT contain road
information - it doesn't recommend copying or any special action.  I
don't think that there is a need for any extra DHCP -> XML transcoding
info.

> SHOULD seems particularly inappropriate here.

OK.

> this isn't obvious to the reader seems like a not-so-good option.

I'll take this one and see where my text differs.  If there are extra
points that are in the text in this document, I will make sure that
those are noted appropriately.  Consider the section cut - and I assume
that this comment only related to the description of the new elements.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2006 14:45:59 -0400

> get the information that they know works.

I have a strong dislike for magic configuration. In my opinion,  
either the party generating PIDF-LO from DHCP generates all language  
permutations so that the recipient can choose or there has to be a  
deterministic algorithm that makes that choice. I assume we agree  
that we don't want people to get involved in making this decision for  
each message or INVITE or NOTIFY, so I don't see how the text you  
wrote gives sufficient guidance "in a way that ensures that you get  
the information that they know works".

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 Jul 2006 14:01:28 -0500

I want one PIDF-LO or one tuple to be the result of this operation.
Maybe I need to add more information on this point, because language is
the only point where this gets sticky.

I have made my suggestion, which I think works: either have a specific
language preference (c.f. RFC 2616 Accept-Language header), or you don't
care and you pick the first.  The alternative that I can think of is a
little too messy for my liking, that is (ok, thinking out aloud on
this):
 - find all the languages in the document - assign a number to each.
 - For each element, take the language that has the lowest number
assigned to it.
 - Cycle through N times with different numbers assigned to each; create
N tuples

Is there a better way to select?  Can you propose an alternative that
doesn't result in combinatorial hell?

> Sent: Thursday, 13 July 2006 4:46 AM
> To: Thomson, Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2006 16:19:48 -0400

In practice, the number of languages in any DHCP civic object is  
likely to be small, probably on the order of 2-3. The most extreme  
example I can think of is Japan, where you might have two different  
writing systems and an "English" (latinized) version. Since each  
address generally consumes no more than 50-60 characters, the  
overhead of sending all permutations is low, particularly since in  
most cases of the sort I mention, all elements would be different in  
each language.

I think we have generally taken the tack that we want to make as much  
information available to the call taker or other location recipient  
as we have, without trying to guess what they might need or not.

Thus, I think a reasonable recommendation is to

(1) send one language version (only English, say) if you have an  
Accept-Language in SIP or the equivalent elsewhere (which you  
generally won't have for the first INVITE)

(2) send multiple civicAddress objects (if that's possible) or  
multiple PIDF-LO (multipart) otherwise

This is safe, in that it prevent information loss, and deterministic  
in that we can at least predict what systems will actually do.

Henning