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