[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
<hgs(_at_)cs(_dot_)columbia(_dot_)edu> 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf