DOI and the non-IETF tree

The authors of a rejected URI draft on DOIs were asked to comment to this
list on non-IETF URI trees. I was the the lead author on that draft. 
  
DOIs (Digital Object Identifiers) are in widespread and growing use by
publishers and other high value content providers (http://www.doi.org).  A
draft "The "doi" URI Scheme for the Digital Object Identifier (DOI)" by
Paskin, Neylon, Hammond, and Sun was submitted as an informative RFC to set
out its relation to existing IETF architecture.  The latest version of was
rejected by the IESG in the following note: 

"This document proposes a top-level URI scheme, doi, and contains details
about the usage of this identifier in a community of use centered on the
International DOI Foundation. After receiving this draft from the RFC
Editor, the IESG requested that the URI be reviewed by the team at
uri-review@ietf.org to see if it fit within the guidelines established  
by RFC 2717/BCP35. Though the authors and reviewers have had a productive
discussion of the draft, the IESG has concluded that this draft does not
meet the requirements of RFC 2717, section 3.2.

The IESG notes, however, that the original intention of those crafting  
RFC 2717 was to set up registration trees outside the IETF tree, in order to
enable registrations by those whose community of use lay largely outside
the context of IETF standards. After a long pause in the development of
those registration procedures, the responsible AD has asked Larry  
Masinter to take on editorship of a proposed set of procedures for these
registrations. The IESG encourages the draft's authors to work with him  
on those guidelines and, when they are complete, to register the doi scheme
in the non-IETF tree that they will set up."

We were puzzled by the statement that our submission is deemed to be in a
"community of use ...outside the context of IETF standards" since any use of
a DOI is through an internet transaction and is open to any internet user.
The RFC Editor advised us to request that the IESG clarify with examples the
meaning of this phrase.  

Additionally we were recommended to follow up the non-IETF tree
recommendation with Larry Masinter, and were pointed to
http://larry.masinter.net/vndurl.txt which proposes two non-IETF URI trees
vnd- and prs-, to be used  for the following:   "In the development of new
products, vendors often have the need to use URIs to identify and locate
resources in a manner that is NOT seen by end users, is not widely
distributed, or for some other reason does not justify the effort to
register a scheme name from the IETF tree."   That proposal that a non-IETF
identifier should be so restricted is not appropriate to DOIs, which are
seen by end users and which are widely distributed in a large open
community.

The users of DOIs wish to see DOIs described in an RFC that will be useful
to those internet users encountering them, in addition to the existing DOI
documentation.  Neither the suggestion that DOIs are outside the context of
IETF standards nor the proposed non-IETF tree approach as currently
formulated seem to deal adequately with the requirements of the DOI
community. The need for the DOI has come out of the content industries,
building on earlier cross-industry collaborative efforts from a wide range
of organisations which have their own business requirements for digital
identifiers.  Among those requirements are (1) the need for publicly
identified entities to have specified attributes which are able to
interoperate semantically with existing metadata schemes, and (2) the
ability to manage ownership as just another attribute at the individual ID
level.   

A previous discussion of the draft on this list
(<https://www1.ietf.org/mail-archive/working-groups/uri-review/current/thrd2
.html>) covered a lot of ground, but the main argument in that discussion
was that there was no engineering detail in the draft, such as
specifications sufficient to build a client that could do anything useful
with a doi, etc.   This was deliberate, though there is, in fact, quite a
lot of engineering under the surface: e.g. while the bulk of DOI resolutions
are currently done through proxy servers sitting in front of the underlying
resolution and storage system, (the 10 millionth assigned DOI, for example,
can be resolved as http://dx.doi.org/10.1007/s00348-003-0647-4) there are
related services that can be associated with each DOI in ways that could be
discovered and used directly and efficiently by client software.

We will expand on and specify this in a future further draft, and solicit
comments on this list, within the next few weeks.  

Norman Paskin
International DOI Foundation

Received on Tuesday, 2 September 2003 10:08:05 UTC