Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 14:00:57 +0100

The IESG wrote:

> consider the following document:
> - 'Location Types Registry '
>    <draft-ietf-geopriv-location-types-registry-03.txt>
> as a Proposed Standard

I'm lost with the purpose of this document.  Does 'water'
cover WC, bathroom, bathtube ?  What is a "criminal mental
institution" ?  Can "an entity" be on a 'cycle' 'outdoors'
in the 'street' simultaneously, and if yes, how do we know
that 'water' 'airplane' 'cycle' is somewhat strange ?

If all that is relevant somewhere for indiscreet devices,
shouldn't there be an enumeration of the IANA registered
locations ?

Will the next IANA registry be a complete dictionary, and
will it by definition include the location registry ?

Is it a good idea to have dictionaries on standards track ?
Is it acceptable to have no "I18N considerations" in the
proposed "location" standard ?

The dummy "security considerations" might be incomplete, if
locations could be used for say search and rescue purposes.

                        Bye, Frank

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

---

From: Joe Abley <[email-masked]>
Date: Tue, 17 Jan 2006 08:43:53 -0500

On 17-Jan-2006, at 08:00, Frank Ellermann wrote:

> I'm lost with the purpose of this document.

It seems from a quick glance through it that draft-ietf-simple- 
rpid-08 gives context.

The initial list of locations seems entirely arbitrary, and most of  
the definitions seem woolly and imprecise. Maybe the arbitrariness is  
intentional, though, and maybe the quality of definitions doesn't  
matter. I don't know enough about the goals of the underlying effort  
to comment.

There are some spelling mistakes. That's about as far as my informed  
commentary on this draft goes :-)

Joe

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jan 2006 09:00:46 -0500

> the definitions seem woolly and imprecise. Maybe the arbitrariness  
> is intentional, though, and maybe the quality of definitions  
> doesn't matter. I don't know enough about the goals of the  
> underlying effort to comment.

More precise definitions are always helpful, but I don't think it is  
necessary to have a complete catalogue of all possible types of  
locations suitable for an insurance company policy. The goal is that  
if there's a location, that if two people are asked to pick the  
closest label, they'll likely agree and they'll likely find something  
that matches. Clearly, this can be pushed to precision beyond need.  
For example, I doubt that we need to identify median strips on roads  
separately.

>
> There are some spelling mistakes. That's about as far as my  
> informed commentary on this draft goes :-)
>
>
> Joe
>

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 15:06:47 +0100

Joe Abley wrote:

> It seems from a quick glance through it that
> draft-ietf-simple-rpid-08 gives context.

ACK, thanks for info.  So now I'm _anxiously_ awaiting an
Internet standard for IANA registered moods...

  <xs:element name="afraid"
    type="empty"/>
  <xs:element name="amazed"
    type="empty"/>
  <xs:element name="angry"
    type="empty"/>
  <xs:element name="annoyed"
    type="empty"/>
  <xs:element name="anxious"
    type="empty" />

...yes, can do.  It also offers 'grumpy' and 'sarcastic'.  Bye

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 17 Jan 2006 18:31:24 +0100

At last!
you start understanding what multimode means in languages. I am 
sorry, but in approving RFC 3066 bis, i.e. declaring itself and the 
IETF authoritative, this is exactly the RFC 3935 responsibility the 
IETF has accepted.
jfc

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Jan 2006 17:57:54 -0500

I have only had a brief look at this document but I'd like to second
some of the concerns raised so far.

1) If locations can be registered on a fcfs basis we can expect
   receivers to see locations that they are unfamiliar with.  As such,
   we need to do better about internationalization for locations.  It
   is not good enough to treat locations as identifiers that are not
   displayed to a user if receivers are often going to run into
   locations.

2) Many of the definitions seem arbitrary.  club vs bar vs cafe vs
   restaurant as an example.

3) The fact that some entries describe holonym relations without any
   defined structure to deal with this is at least concerning.

--Sam

---

From: Andrew Newton <[email-masked]>
Date: Tue, 17 Jan 2006 18:30:08 -0500

>    displayed to a user if receivers are often going to run into

Not that I fully understand your concern, but would you want expert  
review of new additions?

>    restaurant as an example.

Do you have a suggestion about how this can be less arbitrary?

>    defined structure to deal with this is at least concerning.

Maybe this can be remedied with some guidelines as to what  
constitutes a reasonable entry.  I'm not sure if that is possible,  
but it certainly seems like "car" would be a useful entry as opposed  
to "seat" which would both be valid if somebody were riding in a seat  
in a car.

-andy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Jan 2006 01:27:53 +0100

JFC (Jefsey) Morfin wrote:
 
> you start understanding what multimode means in languages.

Maybe I understand "abuse IANA as cheap dictionary for a random
list of locations".  But the list of smileys has some technical
potential, devices could output them as icons, audio, localized
text, or as traditional ASCII art.  For that the list of moods
could give the ASCII art, that's the most limited and shortest
form, plus a corresponding English word as explanation useable
directly in localized text output for "en".

I18N for ASCII art smileys might be tricky, maybe that depends
on the script.  At least BiDi is no issue.  Attempts to smuggle
smileys into Unicode as characters are probably futile, but an
RfC could do.  With the option to create an official registry
of smileys later.  Funny, but not necessarily nonsense.

> I am sorry, but in approving RFC 3066 bis, i.e. declaring
> itself and the IETF authoritative, this is exactly the RFC
> 3935 responsibility the IETF has accepted.

Well, you know what "bis" stands for, you know the now three
ISO sources for this registry, you know the executive summary
"3066 + scripts, for certain charsets and languages and other
situations where that's not obvious or irrelevant", you know
where to find draft-lilly-content-script, and you know that
3066 didn't guarantee stable tags.

That's not exactly the same situation as starting a "location
dictionary" hosted by IANA with a proposed Internet standard.

                           Bye, Frank

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Jan 2006 20:40:07 -0500

>>>>> "Andrew" == Andrew Newton <[email-masked]> writes:

    Andrew> On Jan 17, 2006, at 5:57 PM, Sam Hartman wrote:

    >> I have only had a brief look at this document but I'd like to
    >> second some of the concerns raised so far.
    >> 
    >> receivers to see locations that they are unfamiliar with.  As
    >> such, we need to do better about internationalization for
    >> locations.  It is not good enough to treat locations as
    >> identifiers that are not displayed to a user if receivers are
    >> often going to run into locations.

    Andrew> Not that I fully understand your concern, but would you
    Andrew> want expert review of new additions?

So, I'me a receiver.  I receieve a location that I'm unfamiliar with.
How do I render it in my native locale?

I'm not sure expert review would help with this.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jan 2006 21:06:50 -0500

> How do I render it in my native locale?

I don't think there is any way to accomplish this in general. You  
have two unpleasant choices:
- render the token as-is, hoping that it makes sense to the recipient;
- automatically translate the token, risking that the translation  
will be nonsensical.

This is no different than for any other token meant to be rendered to  
humans.

In RPID, where this is more relevant than in the Registry draft,  
there is a free-text field with the usual XML 'lang' attribute, which  
can be used to describe the location in internationalized text.  
However, in many systems, this is not particularly helpful. As an  
example, in presence, if your watchers are from many different  
language communities, the publisher likely can't pick a language that  
all watchers will understand. Thus, the use of tokens.

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 17 Jan 2006 20:49:52 -0800 (PST)

On Mon, 16 Jan 2006, The IESG wrote:
> The IESG has received a request from the Geographic Location/Privacy WG to 
>    <draft-ietf-geopriv-location-types-registry-03.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-01-30.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-registry-03.txt

What I would like to know is how a document that creates a registry can be
considered for Proposed Standard, as opposed to BCP.  A Proposed Standard is
supposed to be something that can be advanced on the standards track.  How on
Earth does one have multiple interoperable genetically unrelated
implementations of a registry?

//cmh

P.S.  Yes I know we do this all the time but that does not mean that it
makes sense!

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 18 Jan 2006 08:30:56 +0100

I oppose approval of this document as-is.

Four reasons:

1) FCFS is inappropriate
2) The document gives inadequate context for use
3) The document gives inadequate procedures
4) The definition of "automobile" is wrong

Further explanation:

1) FCFS: This token registry will have value chiefly when the recipient of 
such a token has a complete list of tokens available to him, and can 
perform adequate localization. Thus, value is maximized if the churn of the 
registry is slow. With FCFS, one risks a number of trends that could 
jeopardize this (consider registering, in addition to "cafe", "McDonalds", 
"Wendy's", "Burger King", "Jack-in-the-box", "7-eleven"... or in addition 
to "school", registering "university", "middle school", "gymnasium", 
"hochschule", "kindergarten", "vocational-training-institution"....)

I consider "expert review", with a list of criteria that includes "names a 
type of place not described by any existing token", to be a more 
appropriate mechanism.

If we think unlimited growth is a problem, someone needs to be able to say 
"no"; if we don't think unlimited growth is a problem, we need to say so.

2) Inadequate context for use:

The document does not make reference to RPID, except in "acknowledgement". 
Thus, it has to be interpreted as stand-alone, and must contain its own 
guidance. RPID states:

   The <place-type> element describes the type of place the person is
   currently at.  This offers the watcher an indication what kind of
   communication is likely to be appropriate.

The XML definiton says:

     <xs:element name="place-type">
       <xs:annotation>
         <xs:documentation>
           Describes the type of place the person is currently at.
         </xs:documentation>
       </xs:annotation>
       <xs:complexType>
         <xs:sequence>
           <xs:element name="note" type="Note_t" minOccurs="0"/>
           <xs:choice>
             <xs:element name="aircraft" type="empty" />

and while I'm not an XML expert, it seems to say that
<place-type><automobile/><road/></place-type> is a legal construct.
I don't know if it's possible to say whether or not 
<place-type><automobile/><road/></place-type> is different from 
<place-type><road/></automobile></place-type>.

These things guide the usage of place-types in RPID, but cannot be found 
from the registry document.

This document SHOULD give guidance for usage, saying at least:

- whether it's intended that several of these values can be used together
- whether it's intended that a sequence of location types gives a 
progressively more precise set of terms (in which case internationalizing 
the last type you understand is appropriate) or names an intersection of 
the classes (in which case you would have to internationalize all of them).
- whether having a text string alongside it (the "note" above) is a 
recommended practice.

It MAY be appropriate to say something about field of use, like RPID does 
("what types of communication is appropriate" would lead one to distinguish 
between "driving a car" and "passenger in a car", while one could imagine 
that other usages might want to distinguish between "expensive restaurant" 
and "cheap restaurant").

3) Inadequate procedures:

It's a fact of life that any registry will need updating. This document 
describes registration, but no updates. It needs to say:

- Who's authorized to update a registration (FCFS, Expert approval, 
original registrant, not at all)

- Guidelines for updates (anything-goes, refinements only, redefinitions 
with expert approval only)

- Whether registrations can be deleted or not

- Whether there is a mechanism for marking entries as "deprecated, use this 
other term"

4) Self explanatory:

   automobile:

      The entity is in a railroad car.

Nit: The terms show signs of having been alphabetized at one time. They are 
no longer alphabetized - "residence" is in a place in the list that would 
have been appropriate for "home".

--On mandag, januar 16, 2006 21:33:45 -0500 The IESG 
<[email-masked]> wrote:

> The IESG has received a request from the Geographic Location/Privacy WG
> to  consider the following document:
>
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-reg
> istry-0 3.txt
>
>
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Jan 2006 09:49:11 -0500

Thanks for your comments. I generally agree with your feedback and we'll 
revise the document accordingly.

Harald Tveit Alvestrand wrote:
> 1) FCFS: This token registry will have value chiefly when the recipient 
> of such a token has a complete list of tokens available to him, and can 
> perform adequate localization. Thus, value is maximized if the churn of 
> the registry is slow. With FCFS, one risks a number of trends that could 
> jeopardize this (consider registering, in addition to "cafe", 
> "McDonalds", "Wendy's", "Burger King", "Jack-in-the-box", "7-eleven"... 
> or in addition to "school", registering "university", "middle school", 
> "gymnasium", "hochschule", "kindergarten", 
> "vocational-training-institution"....)
> 
> I consider "expert review", with a list of criteria that includes "names 
> a type of place not described by any existing token", to be a more 
> appropriate mechanism.
> 
> If we think unlimited growth is a problem, someone needs to be able to 
> say "no"; if we don't think unlimited growth is a problem, we need to 
> say so.
> 
> The document does not make reference to RPID, except in 
> "acknowledgement". Thus, it has to be interpreted as stand-alone, and 
> must contain its own guidance. RPID states:
> 
> progressively more precise set of terms (in which case 
> internationalizing the last type you understand is appropriate) or names 
> an intersection of the classes (in which case you would have to 
> internationalize all of them).
> It MAY be appropriate to say something about field of use, like RPID 
> does ("what types of communication is appropriate" would lead one to 
> distinguish between "driving a car" and "passenger in a car", while one 
> could imagine that other usages might want to distinguish between 
> "expensive restaurant" and "cheap restaurant").
> 
> - Whether there is a mechanism for marking entries as "deprecated, use 
> this other term"
> 
> 
> 4) Self explanatory:
> 
>   automobile:
> 
> Nit: The terms show signs of having been alphabetized at one time. They 
> are no longer alphabetized - "residence" is in a place in the list that 
> would have been appropriate for "home".
> 
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 18 Jan 2006 18:08:15 -0500

> 3) The document gives inadequate procedures

Agree.

> 4) The definition of "automobile" is wrong

Eh.  It's a protocol constant; they can define it however they want.
As long as they let me register 'wyoming' to mean the entity is in a 
fictional location.

-- Jeff

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Jan 2006 22:49:27 -0500

Some additional comments on closer reading and a general comment:

This registry intentionally (if you look at the RPID document) is not  
meant to directly extend the RPID schema. I suppose that one could  
add that any location types added automatically become XML elements  
in the urn:ietf:params:xml:ns:pidf:rpid namespace. I don't know if  
that's appropriate. I think it's appropriate (and necessary to add)  
that any registrations must be legal XML element names.

> "acknowledgement". Thus, it has to be interpreted as stand-alone,  
> and must contain its own guidance. RPID states:
>
>
>
> These things guide the usage of place-types in RPID, but cannot be  
> found from the registry document.
>

Since usage will strongly depend on the context and since this  
registry is not limited to RPID, I think this would belong into RPID  
(or other documents), not the registry.

> - whether it's intended that several of these values can be used  

I'd assume yes, in general, but defining that seems to be the role of  
the protocol using these elements, not a registry.

I think of the registry like a dictionary. A dictionary does not  
define which words you can use together.

> internationalizing the last type you understand is appropriate) or  
> names an intersection of the classes (in which case you would have  
> to internationalize all of them).

There is no implication of hierarchy. In general, this seems  
difficult to achieve since not all location types are hierarchical.  
For example, an airport might contain a bank or a shopping-area, but  
that does not make either a subcategory of an airport.

I also don't understand the need for I18N, since these are tokens  
that would be translated by a local application, not rendered to users.

> - whether having a text string alongside it (the "note" above) is a  

That's again an RPID issue. Not every protocol using these tokens  
will have notes.

>
> It MAY be appropriate to say something about field of use, like  
> RPID does ("what types of communication is appropriate" would lead  
> one to distinguish between "driving a car" and "passenger in a  
> car", while one could imagine that other usages might want to  
> distinguish between "expensive restaurant" and "cheap restaurant").

We are not trying to define a service location protocol that  
describes numerical properties of locations. I don't know how to rule  
this out by legal wording; presumably the expert reviewer can make  
common-sense judgement.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Jan 2006 07:44:11 +0000

A different question:

Henning Schulzrinne wrote:
> meant to directly extend the RPID schema. I suppose that one could add 
> that any location types added automatically become XML elements in the 
> urn:ietf:params:xml:ns:pidf:rpid namespace. I don't know if that's 
> appropriate. 

Doesn't this make it hard/impossible to check if an RPID
document is schema-valid? (I mean keeping some element
names in a list that's not a schema.)

Perhaps that's not important for this application though.

Stephen.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Jan 2006 07:58:46 -0500

Yes, unfortunately it does. Extending element sets seems to be rather  
tedious in the current XML tool set. Either you have the new elements  
extend the old namespace, yielding the problem you mention, or each  
new element (location type, here) gets a new namespace, yielding a  
namespace list a mile long if there are lots of extensions.

>> This registry intentionally (if you look at the RPID document) is  
>> not meant to directly extend the RPID schema. I suppose that one  
>> could add that any location types added automatically become XML  
>> elements in the urn:ietf:params:xml:ns:pidf:rpid namespace. I  
>> don't know if that's appropriate.
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 19 Jan 2006 14:15:17 +0100

[taking out the iesg from CC list, but leaving WG and ietf list in]

> Since usage will strongly depend on the context and since this  registry
> is not limited to RPID, I think this would belong into RPID  (or other
> documents), not the registry.

Sigh.... I guess we disagree on principles here pretty strongly.

I think that in order for a vocabulary like this to be useful, it has to 
fit its purpose. A vocabulary that is made to fit multiple purposes will in 
the end fit neither - for one recent example, see the discussion between 
the "mail folks" and the "RTP folks" over the proper registration and 
meaning of MIME content-types.

You're defining the vocabulary now, and have the chance for establishing a 
reasonable context. Once it's being used for two purposes with conflicting 
requirements, it's too late to fix it.

> I think of the registry like a dictionary. A dictionary does not  define
> which words you can use together.

Yes, it does. By implication, a dictionary is for a language, and a 
language is (among other things) a set of rules on how to put the words 
together - and it VERY strongly implies that in order to understand a 
word's meaning, you have to look at its context.

But it's easy to forget about the enormous amount of baggage we have when 
considering a concept like "word", and that there's so little baggage 
attached to a label type like this one.

> There is no implication of hierarchy. In general, this seems  difficult
> to achieve since not all location types are hierarchical.  For example,
> an airport might contain a bank or a shopping-area, but  that does not
> make either a subcategory of an airport.

Good - then say so!

> I also don't understand the need for I18N, since these are tokens  that
> would be translated by a local application, not rendered to users.

My mistake - this should have been "localize".

To illustrate: In the flat case, "restroom, cafe, airport" could be 
localized as "Toalett, <ukjent sted>, Flyplass" in Norwegian if the 
application doesn't know the translation of "cafe"; in the hierarchical 
case, one could imagine "McDonalds, cafe, eating-place, public building, 
indoors" - it would be OK to localize that as "Spisested" if "cafe" isn't 
known.

> That's again an RPID issue. Not every protocol using these tokens  will
> have notes.

There's no second protocol at the moment, so you have the chance to provide 
guidance...

> We are not trying to define a service location protocol that  describes
> numerical properties of locations. I don't know how to rule  this out by
> legal wording; presumably the expert reviewer can make  common-sense
> judgement.

Legal wording isn't what I'm looking for. Hints to the reviewer about what 
the WG considers "common sense" would be helpful.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 19 Jan 2006 16:11:52 +0100

Hi! Harald,
We fully agree on this. But I see you are fighting here the same 
difficulty I fight against you for languages. They propose words in 
their language context as you propose languages tags in your 
internationalised context. They do the same layer violation as you 
do. The only solution to this is to conceptualise and to universalise 
the concept. ISO 11179. You define a concept, give it a unique ID 
(building a referent) and as many names as you need which name the 
concept, not its version in a given context. However I agree 
JTC1/SG32/W2 has not yet addressed the multilingual and the networked 
aspects. But IETF have clumsily approached it with IDNA and very well 
with the DNS.

The problem is that the whole process has to be "multiterative". When 
you consider your "internationalization", the concept named in 
English is to be adapted into the locale culture which tries to 
understand your concept the same way as you do (this is monologue). 
This is workable but gives leadership (and economical, cultural, 
political, technical advantages to the American end). Better you have 
a true dialog where the American concepts includes the other end's 
concepts. Unicode very partly does that for texts items.

"multinationalisation" calls for the concept to be equally understood 
(what does "understand" mean?) the same way between every cultures 
(every ends are equal). Either because the concept is truly 
universal. Or because you built all the cross-national in-between 
extended services to permit a polylogual relation. This means that 
when an American end says "kitchen", the French end will receive 
"American style Kitchen" (our kithens are not _built_ the same way 
and do not include the same set of things).

I take a very common example. Many languages have the same term for 
blue and green and only consider them as different shades. Recent 
studies shown that people of different languages describe the 
different variations of blue/green the same way with the right eye 
(left brain) but differently with the left eye (right brain), 
depending on the language.

A friend of mine works on dictionary about kids: the way kids 
understand the same thing around the world. Example: "bring me some 
water" implies many different things to do if the kid lives in a 
flat, in a farm, in a desert, in the USA, in Bangladesh, etc. and the 
water may be very different.

Welcome in multinationalisation and DRS preparatory work. BTW IAB 
will say if this is an IETF matter or not.
jfc

At 14:15 19/01/2006, Harald Tveit Alvestrand wrote:
>I think that in order for a vocabulary like this to be useful, it 
>has to fit its purpose. A vocabulary that is made to fit multiple 
>purposes will in the end fit neither - for one recent example, see 
>the discussion between the "mail folks" and the "RTP folks" over the 
>proper registration and meaning of MIME content-types.
>
>You're defining the vocabulary now, and have the chance for 
>establishing a reasonable context. Once it's being used for two 
>purposes with conflicting requirements, it's too late to fix it.
>
>>
>language is (among other things) a set of rules on how to put the 
>words together - and it VERY strongly implies that in order to 
>understand a word's meaning, you have to look at its context.
>
>But it's easy to forget about the enormous amount of baggage we have 
>when considering a concept like "word", and that there's so little 
>baggage attached to a label type like this one.
>
>application doesn't know the translation of "cafe"; in the 
>hierarchical case, one could imagine "McDonalds, cafe, eating-place, 
>public building, indoors" - it would be OK to localize that as 
>"Spisested" if "cafe" isn't known.
>
>>
>There's no second protocol at the moment, so you have the chance to 
>provide guidance...
>
>>>
>Legal wording isn't what I'm looking for. Hints to the reviewer 
>about what the WG considers "common sense" would be helpful.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Jan 2006 15:56:21 -0500

> fit its purpose. A vocabulary that is made to fit multiple purposes will 
> in the end fit neither - for one recent example, see the discussion 
> between the "mail folks" and the "RTP folks" over the proper 
> registration and meaning of MIME content-types.

I can't prove or disprove that statement, unfortunately. We won't know 
whether the location types will be useful until somebody uses them. I 
suspect that "real" GIS applications will need a far more specialized 
vocabulary, but it turns out that, for example, a proposal for crime 
scene labeling more or less fits into the proposed registered list. (We 
found this out after creating the list.)

Currently, there are two potential customers: RPID and AAA.

> word's meaning, you have to look at its context.

Dictionaries I know generally define the word by itself. Indeed, many of 
the definitions in the document are very close to (English) dictionary 
definitions.

> indoors" - it would be OK to localize that as "Spisested" if "cafe" 
> isn't known.

We'll note in the draft that there is no implied hierarchy, except where 
noted. (For example, 'restaurant' is an umbrella term that includes 
'cafe' and 'bar'.)

> There's no second protocol at the moment, so you have the chance to 

Yes: AAA 
(http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt)

> Legal wording isn't what I'm looking for. Hints to the reviewer about 
> what the WG considers "common sense" would be helpful.

To better understand what you have in mind, can you give an example? 
There are some obvious things, like:

- not specific to a country
- not a specific company or organization
- well-defined
- widely recognized

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 19 Jan 2006 22:56:53 +0100

> (http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt)

Right - the wording there is an argument in favour of centralizing guidance 
(it has none).....

> - not a specific company or organization

That's good guidelines for a reviewer. It would allow him to reject both 
"McDonalds" (company) and "Lavvo" (Sami tent, not widely recognized), but 
would probably accept "open ocean" and "river" (if it was used in a context 
about where a boat is, these might make sense).

I'd say "not specific to a country or language".
Go for it.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 19 Jan 2006 17:20:57 -0500

> the definitions in the document are very close to (English) dictionary

Dictionaries define a word, including specifying one or more parts of 
speech, which are the places in the language syntax where the word can be 
used.  And, as already noted, dictionaries are not abstract lists of words; 
they are tied to specific languages.  For some languages, they provide 
additional information affecting the syntax surrounding the word.

Good dictionaries also provide examples of real-world usage.  In fact, 
according its website, the OED normally requires several examples of use 
before a word will be included, and it is these examples which are used to 
determine the word's definition.

Note that the process is considerably different for protocol parameters, 
where we first decide exactly what we want to be able to say, and then 
assign a protocol parameter which means that.  Then, the parameter is not 
in any natural language, but in the "language" of whatever wire protocol 
uses it -- that is why we can name protocol parameters in English without 
needing to worry about how to "localize" -- the meaning is 
language-independent.  Of course, non-English-speaking implementors would 
probably appreciate translations of the definitions, just as they would 
appreciate translations of the protocol specs.  But the presence or absence 
of such translations won't change whether a correct implementation works, 
or which other implementations it interoperates with, or even which users 
can use the software (the last _does_ depend on localization of whatever 
user interface the software has, but that's an implementation issue, not a 
protocol design issue).

If you're going to define a value intended for consumption by humans, 
rather than by software, then it should probably be free-form, rather than 
subject to a registry, and then you do have to worry about 
internationalization and language tagging.  What you don't need in this 
case is a registry for the contents of the field.

Now, one solution to the problem (and a widely adopted one) is to replace 
the free-form field with a parameter which only _looks_ free-form, but 
actually has well-defined values, allowing them to be localized.  That 
would be a legitimate reason for creating a registry such as the one 
described by this document, but then the document would need to describe 
the issue and how the registry is meant to be used to solve it.

In any case, whether you are writing a dictionary, a protocol parameter 
registry, or a message catalog, it is necessary to specify a domain of 
applicability, which the document under discussion fails to do.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Jan 2006 18:25:34 -0500

>>>>> "Henning" == Henning Schulzrinne <[email-masked]> writes:

    >> "acknowledgement". Thus, it has to be interpreted as
    >> stand-alone, and must contain its own guidance. RPID states:
    >> 
    >> 
    >> 
    >> These things guide the usage of place-types in RPID, but cannot
    >> be found from the registry document.
    >> 

    Henning> Since usage will strongly depend on the context and since
    Henning> this registry is not limited to RPID, I think this would
    Henning> belong into RPID (or other documents), not the registry.

    >> - whether it's intended that several of these values can be

    Henning> I'd assume yes, in general, but defining that seems to be
    Henning> the role of the protocol using these elements, not a
    Henning> registry.

    Henning> I think of the registry like a dictionary. A dictionary
    Henning> does not define which words you can use together.

Here I think is the crux of the problem.  The IETF and IANA should not
be in the business of creating dictionaries.

The document under discussion creates a named set of place
descriptions.

There is no guidance given on how this information should be used, why
you would want this registry or what constraints should be placed on
it.

That's a big problem.  First, there are likely to be concerns that
matter to almost all uses of the registry.  It's desirable to require
using applications to consider these concerns and probably even to
describe how they handle the concerns.

Another reason not giving guidance is problematic has to do with
different assumptions about how the registry is used.  Some
applications may assume that there will be a small number of entries
in the registry.  That's fine until someone comes along and say
registers all the different major food chains with presence in more
than one country.

One application may assume that location is single valued; another may
have multi-valued location.  These applications will expect different
things from the registry.

Even when we've tried to have guidance for registries we've run into
problems.  Witness the recent debate about whether RTP and MIME should
use the same media type registry.

As such, with my AD hat off, I do not support publication of an RFC
that establishes a dictionary for place names I would probably support
publication of an RFC that established a well-coped place name
registry for some purpose.  I'd want to limit the size of the registry
for localization reasons.

--Sam

---

From: John Schnizlein <[email-masked]>
Date: Thu, 19 Jan 2006 15:06:19 -0500

On Jan 19, 2006, at 10:11 AM, JFC (Jefsey) Morfin wrote:
> ...
> (every ends are equal). Either because the concept is truly universal. 
> Or because you built all the cross-national in-between extended 
> services to permit a polylogual relation. This means that when an 
> American end says "kitchen", the French end will receive "American 
> style Kitchen" (our kithens are not _built_ the same way and do not 
> include the same set of things).

Interesting.  Do French kitchens not include a coffee-maker, stove, 
oven, sink, refrigerator and counters?  What do they have, besides 
fewer chemicals on/in their food, that American kitchens do not?

> blue and green and only consider them as different shades.

Blue and green are different hues.  Different shades are the same hue 
but different concentration, for example navy blue compared to royal 
blue.  http://en.wikipedia.org/wiki/Color_theory

Please provide a reference for languages that use the same term for 
blue and green.  I would be surprised because these colors have 
different receptors in the human eye.  
http://en.wikipedia.org/wiki/Cone_cell

> Recent studies shown that people of different languages describe the 

Please provide references for these studies.  The "right eye (left 
brain)" description is revolutionary, since the function of the optic 
chiasm was hypothesized by Newton in 1704 and demonstrated by by Ramon 
y Cajal in 1899.  http://en.wikipedia.org/wiki/Optic_chiasm

John