OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Proposal to drop the URN namespace


After having cooked on this proposal since the discussion with Gabe, I
want to add that I am in favor of it for all the reasons Gabe mentions.
Let me amplify on a few points:

1) Given that the strawman syntax is already "unified", i.e., it
proposes a syntax that allows for either persistent or reassignable
identifiers to be expressed within any segment of an XRI path, it should
be a straightforward task to specify the algorithm by which an XRI that
consists of only persistent segments (and thus *could* be expressed as a
formal URN) can in fact be translated into a formal URN. And as Gabe
points out, we can do that at any time.

2) Since the unified syntax must support both persistent and
reassignable identifiers at every segment, so must the resolution
mechanism, so it too is a superset of what is needed for URN resolution
anyway.

3) What Gabe describes in b) below is in fact what I believe is the most
common practice: persistent identifiers are used within the local
namespace of a domain name or directory name which may or may not be
persistent, and therefore the full URI cannot be a formal URN. The
numeric strings following domain names in the URIs of almost any large
website are good examples. If this is the 80/20 use case for persistent
identifiers, it should be the primary one we are designing for.

=Drummond 


-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Friday, May 09, 2003 5:18 PM
To: 'xri@lists.oasis-open.org'
Subject: [xri] Proposal to drop the URN namespace

TCers-
        Drummond and I have discussed the possibility of dropping the
TC's effort to define (formally) a URN namespace. The motivations for
such a proposal are:

a) the formalities of the URN syntax require some complications to a
syntax that is common across a URI scheme and a URN
namespace. Specifically, the URN syntax doc (RFC 2141) says that /
SHOULD NOT be part of a URN namespace, and suggest the use of : as a
delimiter. This of course is the opposite of the URI syntax
suggestions/requirements (which is a deliberate design decision, I
believe).

b) There is a vision of a syntax where parts of the identifier can be
"persistent" paths and some are "reassignable" paths. But this would
mean that URNs could only have the "persistent" parts. This might
constrain the frequency of XRI URNs.

c) Another successful identifier scheme which is aiming for producing
persistent identifiers has chosen not to pursue a URN scheme - Handle
(though not sure for what reasons). There is precedent for creating a
URI scheme that has persistence implications and semantics.

d) My sense is that achieving formal IETF approval of a URN scheme in
requires a greater effort than that for achieving formal approacl of a
new URI scheme. While this is not neccesarily a stated goal of the TC,
I believe it is certainly something the TC (or members thereof) should
attempt if we are in fact defining a new URN namespace. Thus, we
should consider the benefit of creating a URN namespace with against
the cost of convincing experts that the XRI URN scheme is really a URN
scheme that meets the semantics described in the various RFCs.

e) I think it will be easier to define one syntax, with one resolution
scheme.

f) We can always go back and define a URN syntax and resolution scheme
later if it becomes obvious that they are in fact needed.

So really, the proposal is to:

1) remove discussion about URNs in the motivation/requirements
document and the specs.

2) not move forward on the syntax which is specific to URNs (e.g. BNFs)

3) not move forward on the resolution which is specific to URNs

Thoughts?

At this point, this is just a discussion proposal. I'd like to hear if
anyone feels strongly about this one way or the other.

        -Gabe



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]