Subject: AW: AW: [Geopriv] WGLC ondraft-ietf-geopriv-location-types-registry-03.txt

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 17 Aug 2005 13:40:16 +0200

hi john, 

please find my comments below:

> On Aug 17, 2005, at 3:49 AM, Tschofenig, Hannes wrote:
> >>
> >> Von: [email-masked] [mailto:[email-masked]] Im 
> >> Auftrag von John Schnizlein
> >>
> >> Shouldn't the purpose of this location-types-registry be 
> included in
> >> the document?
> >
> > i thought that the following sentence said already everything:
> >
> > "This document creates a registry for location types.  "
> >
> > if you have a better text please let us know.
> 
> The cited text states the purpose of the document, not the purpose of 
> the registry.
> It seems that a simple statement of why this registry is 
> needed should 
> be in the document.

there are different place types (e.g., 'bus', 'airplane', etc.). the
document lists a number of them. 
there might be a need to add new place types in the future (very
likely). 
one possible way to support this functionality is to create a registry
and to describe how new values are added.

> 
> >>  In particular, what is the relationship between this and
> >> the statement in draft-ietf-geopriv-dhcp-civil-06 that "Thus, this
> >> draft establishes an IANA registry for civic location data 
> fields. "?
> >>
> >> Pending clarification of the above, it seems premature to press
> >>
> >> forward with WG last call on an IANA registry of this sort 
> when there
> >>  is a DISCUSS in the IESG review of 
> draft-ietf-geopriv-dhcp-civil-06
> >> questioning this sort of structured addresses:
> >>   "Since these addresses are mostly intended for human use 
> (emergency
> >>    workers) who know the local context, why not have a 
> completely non
> >>    predescribed field for an adress? This also solves the 
> problem for
> >>    other useful info as: 'room: 1:123', or cubicle 450D.
> >>    In addition, many addresses especially in rural areas 
> are not only
> >>    non-standard, they also can describe a rather large 
> area where the
> >>    user needs a human readable field to make it somewhat 
> more clear to
> >>    where to find the user, for example, when entering the 
> farm, look
> >>    for the building with the red roof."
> >> Wouldn't it be better to resolve the substantive question 
> of the iESG
> >> first?
> >
> > i don't see the location-types-registry being dependent on the 
> > dhcp-civic draft.
> 
> While no dependency is intended, I would hope that it is 
> clear that the 
> same question applies.

i am not sure what the problem is. 

> 
> >> Since these types are all English words, what provision is made for
> >> other languages?
> >
> > there was no plan from our side to translate these terms into many 
> > different languages.
> 
> I suspect that an English-only registration of terms would be 
> a problem 
> for the global Internet.
what is your suggestion? 

ciao
hannes

> John

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 17 Aug 2005 08:43:22 -0400

I suspect John makes a valid point about the language of location types. 
  I see two possibilities:

1) There is a precedent for requiring a universal knowledge of English: 
air traffic control.  However, the reason for the requirement in this 
case is that everyone in a community (all pilots within hearing as well 
as the ground staff) must understand each other.  This is hardly the 
case here.

2) More realistically, register codes with their meaning rather than 
words from the English language.  The rendering of these codes into the 
language of the PSAP becomes a matter of the local human interface.

Tom Taylor

---

From: Andrew Newton <[email-masked]>
Date: Wed, 17 Aug 2005 09:55:10 -0400

On Aug 17, 2005, at 8:43 AM, Tom-PT Taylor wrote:

> 2) More realistically, register codes with their meaning rather  
> than words from the English language.  The rendering of these codes  
> into the language of the PSAP becomes a matter of the local human  
> interface.

Out of curiosity, should we change all the element names in PIDF-LO  
to numbers as well?  Should we change all the RFC 2822 headers to  
numbers as well?

To a computer, there is no difference between localizing the number  
"123" into "aeropuerto" and localizing the name "airport" to  
"aeropuerto".  The only reason to use numbers is for the sake of  
compactness.  However, names are beneficial when diagnosing  
problems.  As an engineer, which is more readily meaningful to you:  
"738213" or "watercraft"?  The reason the names are in English is  
simply because of tradition.  I'm perfectly fine with Henning and  
Hannes, both German speakers, using their native language for this  
registry. "Flughafen" is still more meaningful to me than any number.

-andy

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 17 Aug 2005 10:57:53 -0400

The difference between element names and the location types is that the 
latter are intended to be content, and displayable content at that. 
(You emphasize the debugging possibilities, though I don't see the value 
to a Chinese engineer.)  That said, I agree that an user interface could 
as easily render "airport" as "1" into "aeropuerto".  I'm just 
uncomfortable with forcing English onto people at the content as opposed 
to the specification level.

Andrew Newton wrote:
>> words from the English language.  The rendering of these codes  into 
>> the language of the PSAP becomes a matter of the local human  interface.
> 
> 
> Out of curiosity, should we change all the element names in PIDF-LO  to 
> numbers as well?  Should we change all the RFC 2822 headers to  numbers 
> as well?
> 
> compactness.  However, names are beneficial when diagnosing  problems.  
> As an engineer, which is more readily meaningful to you:  "738213" or 
> "watercraft"?  The reason the names are in English is  simply because of 
> tradition.  I'm perfectly fine with Henning and  Hannes, both German 
> speakers, using their native language for this  registry. "Flughafen" is 
> still more meaningful to me than any number.
> 
> -andy
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 17 Aug 2005 11:17:17 -0400

On Aug 17, 2005, at 10:57 AM, Tom-PT Taylor wrote:

> The difference between element names and the location types is that  
> the latter are intended to be content, and displayable content at  
> that.

Localization issues occur with content in other contexts (number  
formats, date formats, etc...) and so there is no reason to assume  
that localization will not be possible in this case.

> (You emphasize the debugging possibilities, though I don't see the  
> value to a Chinese engineer.)

True.  But the trade-off is that one method is of no value to  
everybody, while the other method is of value to some people though  
not all people.

>   That said, I agree that an user interface could as easily render  
> "airport" as "1" into "aeropuerto".

> I'm just uncomfortable with forcing English onto people at the  
> content as opposed to the specification level.

Just because something is technically content (such as in XML) does  
not mean that it cannot be part of a specification.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Aug 2005 21:54:21 -0400

Tom-PT Taylor wrote:
> latter are intended to be content, and displayable content at that. (You 
> emphasize the debugging possibilities, though I don't see the value to a 
> Chinese engineer.)  That said, I agree that an user interface could as 
> easily render "airport" as "1" into "aeropuerto".  I'm just 

There are really three languages:

(1) specification (RFC)
(2) user-visible output, subject to I18N
(3) protocol values

Since this is used within RADIUS, DIAMETER and similar applications, I 
think this is closest to (3), where we have traditionally relied on 
English values. There might be unique location types that are only 
available in Finland, for example, and thus best represented in Finnish, 
but this seems a bit of a stretch. Maybe a simple reference to RFC 3536 
and/or 2277 is sufficient here.

Henning