Subject: [Geopriv] Next steps for the 'Location Types Registry' draft

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sat, 3 Sep 2005 16:02:45 +0200

hi all, 

as part of the wglc for the location types registry draft we received
feedback regarding the usage of english for the different location
types. i could not see a consensus with respect to this issue and i
would like to see suggestions on how to move forward.  

ciao
hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 03 Sep 2005 10:22:53 -0400

It is sometimes difficult to reach consensus on a mailing list, as 
peetering out of a discussion can either indicate that the proponent of 
a particular solution or approach has been convinced by the arguments of 
other solutions or that he or she has simply given up.

There seem to be two somewhat separate issues:

(1) Should the current initial registry use english words or some other 
token, such as a number.

(2) Should the registry restrict future registrations to being 
(American) English words.

I thought there was a recognition that

- the token registered are not usually made directly visible to end 
users (*);

- thus, they are protocol tokens that are, by consensus of the IETF 
reflected in relevant RFCs, not subject to I18N, no different from, say, 
the RPID XML element names or HTTP protocol header names.

- numeric identifiers could be used, but would offer no significant 
advantages, but rather decrease readability and complicate debugging. 
After all, we don't use numeric header names or random letter strings in 
SMTP or HTTP, either. We have always assumed that implementors of IETF 
standards understand English - otherwise, they'd have difficulty 
programming in any known programming language except maybe APL or 
reading the RFC to begin with.

This seems to argue for leaving (1) as is.

For issue (2): I don't think registries of tokens and namespaces have 
typically specified the language to be used for future registrations. 
This would be handled as part of the normal review process specified for 
the registry. It seems likely that such a review would reject names 
designating the same location just in a different language and may 
consider whether the use of non-English names is likely to further 
interoperability. Given the lack of precedent and the low likelihood of 
having to deal with this issue in practice, it seems easiest just to 
punt here and not call out that facet of the registration review. 
Otherwise, we might have to get into whether the FCC-certified "dirty" 
words are allowable and who knows what other issues.

(*) Even English language user interfaces may, for example, replace 
hyphens by space or translate single-word names into more descriptive 
phrases.

Is this is a reasonable summary?

Henning

---

From: Andrew Newton <[email-masked]>
Date: Sat, 3 Sep 2005 11:44:30 -0400

On Sep 3, 2005, at 10:02 AM, Tschofenig, Hannes wrote:

> i could not see a consensus with respect to this issue and i

Putting my co-chair hat on here:

I did not see consensus around changing this draft to use numeric  
values nor to address the issue of the tokens being considered  
anything other than protocol elements (and thus not subject to  
additional I18N considerations).

This draft will progress to the IESG using its current technical form.

To accommodate the addition of the 'other' and 'unknown' place types  
to be placed in this draft now rather than being placed in the IANA  
registry separately, working group last call will be extended one  
additional week until 10 September 2005 in order for participants to  
voice any objections to these two new place types.

-andy

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 03 Sep 2005 13:31:37 -0400

I withdraw my intervention on the topic.  I forgot that the content will 
be embedded in English-like XML headers, and it's all of a piece.