Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard

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

--On onsdag, januar 18, 2006 22:49:27 -0500 Henning Schulzrinne 
<[email protected]> wrote:

> Some additional comments on closer reading and a general comment:

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

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.

>
>> This document SHOULD give guidance for usage, saying at least:
>>
>> - whether it's intended that several of these values can be used
>> together
>
> 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.

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.

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

>
>> - whether having a text string alongside it (the "note" above) is a
>> recommended practice.
>
> 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...

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

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


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