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
<iesg-secretary(_at_)ietf(_dot_)org> wrote:
The IESG has received a request from the Geographic Location/Privacy WG
to consider the following document:
- 'Location Types Registry '
<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
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by
2006-01-30.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-reg
istry-0 3.txt
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf