Thanks for your comments. I generally agree with your feedback and we'll
revise the document accordingly.
Harald Tveit Alvestrand wrote:
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@xxxxxxxx> 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@xxxxxxxx or ietf@xxxxxxxx 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf