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