Re: DOI and the non-IETF tree

Hi Michael,

We have discussed registering the "urn:hdl:" namespace several times both
here at CNRI and at the ietf meetings. It is especially intended for the
application at the Library of Congress. The consensus is that we are going
to work on it, and it's merely a matter of time. I, for one, had some
deadline to catch and have to work tonight. Won't know when I would find the
time to work on the urn draft. Maybe the ietf meeting:-)?.

This said, we do have several issues that need to be addressed before we
register any URN namespace. I was planning to discuss them with you when I
find the time to work on the urn draft, but it seems this is a good time to
make them clear (especially since you mentioned me in your email):

1) The Handle System is a secured global name service for digital objects
(different from DNS which is for network address translation). There may be
many applications of the handle system. Each of them may register its own
URI/URN namespace (the same is true for DNS, as evidenced in
"telnet:<dns-name>" and "ftp:<dns-name>" URL schemes). Before we register
"urn:hdl:", we have to make sure that we won't be denied from registering
the "hdl:" URI scheme. The later may be used for some totally different
applications. We have discussed this issue at the IETF meeting, but I was
told that this may not be allowed by IESG. Could someone clarify this issue
here?

2) Registering "urn:hdl:" has nothing to do with "doi:" URI. These are two
different kinds of applications. The former is for a specific application
(for LOC) that want to use "urn:hdl:" as a pure namespace. The later is a
much more complicated application. "doi:" URIs are intended to reference
actionable DOI identifiers and its services. It may have parameters and
query components (or even segments) involved in its syntax. Do we know if
any of these is applicable to URN (syntax)? If they do, what about
persistency? RFC2141 doesn't have the answer for this.

3) Personally I think URN is an excellent concept. But I can't understand
the usefulness in enforcing the "urn:" prefix. From user's point of view,
what exactly we can gain by using "urn:doi:" that we cannot by using "doi:"
URI? Consider that "doi:" is already used in journal paper reference, will
it justify the effort to make the transition? I think this will help DOI
community in making a better decision.

4) We understand that URN doesn't mandate any bootstrapping mechanism like
DDDS. Then what is the mechanism for RDS? If we allow different mechanisms
to be used, how do we guarantee the integrity of it?

5) From engineering point of view, when we design a system, we want to have
it based on something that really works. DOI is a working system that is
currently in use. It has to define its namespace on something that's working
or is surely going to work. For URN to be acceptable, there are still work
need to be done, before we can convince people that it's really going to
work. There are many IETF standards that doesn't end up working. Can we say
with confidence that (when) URN is going to work? For example, do we have an
estimate as to when Microsoft will recognize the "urn:" scheme? What will be
the RDS mechanism that they use?


Again, I hope that you won't think I'm against the URN work. Instead, I
think it has the potential to be useful. But given the current circumstance,
I am not convinced yet that URN is suitable for DOI (and I'm not the one
making the decision for that). I hope that, by sharing my doubts with you
here, we can all get a better understanding of the situation and help people
make a better decision.


Best regards,
Sam


----- Original Message -----
From: "Michael Mealling" michael@neonym.net
To: "Larry Lannom" <llannom@cnri.reston.va.us>
Cc: "Daniel R. Tobias" <dan@tobias.name>; <uri@w3.org>
Sent: Friday, September 12, 2003 5:58 PM
Subject: Re: DOI and the non-IETF tree


>
> On Fri, 2003-09-12 at 16:56, Larry Lannom wrote:
> > I don't want to take up too much list space with this, but I do feel
> > that I have to respond to a few points:
> >
> > o I wonder if I'm being confused with someone else. I joined CNRI in
> > the fall of 1996 and my knowledge of the development of URN is all
> > second hand and not particularly detailed.
>
> Looking back at my history some of the original discussions in '94 were
> with Bill Arms. But I visited CNRI once and had numerous discussions at
> IETF meetings where we discussed all of this with you and Sam. One of
> the topics that I thought we had cleared up was that the DDDS method of
> resolution is not, has never been, and will never be a required method
> of resolution for URNs. Specifically, RFC 2141 never mentions any
> particular resolution mechanism and indeed never mentions any
> requirement that there ever be one.
>
> > o DOI and handle are not synonymous. The DOI per se does come out of
> > the handle system namespace and the default resolution mechanism is the
> > handle system, but DOI has its own set of requirements, metadata rules,
> > etc. and if it wished could at some point use some other resolution
> > mechanisms. The reverse is also true -- there are applications of the
> > handle system other than DOI. The most recent notable effort is the
> > DSpace project out of MIT/HP.
>
> In that case, 'urn:doi' makes so much exact perfect sense that it
> requires extremely tortuous logic to come up with any objections at all.
>
> > o I can't speak for others, but I am not being disingenuous. I can
> > assure you that the DOI community and the various handle system users
> > are not alone in wondering which way to go with the various url/urn/uri
> > questions. In terms of the handle system, we are on what we consider to
> > be a logical path and in front of any kind of IETF id registration is
> > the complete specification of the system itself in the form of
> > informational RFCs. You may have received different impressions over
> > the years from other people at CNRI, but any course changes were due to
> > our own indecision, not to any grand Machiavelian schemes.
>
> Many of us were promised, on several occasions, by both Sam and yourself
> that a URN registration document would be forthcoming. Each time you had
> objections you were shown that those objections were incorrect and that
> indeed, a URN namespace would be the best slot for DOIs. With the
> exception of that age old "http is the only scheme anyone ever needs"
> issue, there has always been consensus that DOIs (actually, anything
> that uses the Handle namespace) should have always been a URN namespace.
> Indeed URNs were designed specifically for handles from the very
> beginning.
>
> I've reviewed all of the objections raised by CNRI and the Foundation
> and invariably they're either wrong or they take a mild suggestion found
> in the RFC 2141 document and turn it into some uber-MUST. In my
> experience when someone interprets documents in such a tortuous and
> illogical manner it usually means there are other motivations. I would
> like to be proven wrong but so far I haven't....
>
> We could put this entire thread and issue to bed with one simple
> document that would probably take less than a month to run through the
> process. What is so damning about a URN namespace that is forcing you
> guys to postpone incorporating DOIs and Handles into the infrastructure?
> What could be worth this much typing?
>
> -MM
>

Received on Friday, 12 September 2003 23:45:03 UTC