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: 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]