RE: [xri] Proposed accounting for public comments on XRI Syntax 2.0

["Wachob, Gabe" <gwachob@visa.com>]

Drummond-
	I'd say less about the details of persistent identification and
simply point out that there are other requirements, when taken in
combination, that aren't neccesarily satisfied by HTTP URIs. There will
*always* be an argument that everything can be done with HTTP URIs - and
that's probably true if you consider requirements in isolation. The
point is the combination of things that we want to do with XRIs. 

	For me, it's the fact that I don't want DNS resolution of HTTP
URIs - if someone came up with an alternate HTTP URI authority syntax
that could be resolved differently, then I'd be happy. And that's almost
what we've done. 

	-Gabe	

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Sunday, November 13, 2005 12:09 AM
> To: xri@lists.oasis-open.org
> Subject: [xri] Proposed accounting for public comments on XRI 
> Syntax 2.0
> 
> Following is a first draft of the proposed accounting for 
> public comments on
> XRI Syntax 2.0 as required by section 3.4(g) of the OASIS TC process.
> 
> XRI TC members, please read this over and send ANY feedback 
> to the list
> prior to noon Pacific time on Monday. Gabe and I will then 
> prepare the final
> draft.
> 
> ***** PROPOSED ACCOUNTING FOR PUBLIC COMMENTS - FIRST DRAFT ******
> 
> Mary:
> 
> Per section 3.4(g) of the OASIS TC process
> (http://www.oasis-open.org/committees/process.php#3.4), 
> following is an
> accounting for the public comments received on the XRI Syntax 2.0
> specification during the following review periods:
> 
> 1) XRI Syntax 2.0 Committee Draft 01 had a 30-day public 
> review starting
> March 15, 2005, with a 17-day extension starting April 13, 
> 2005, ending
> April 30, 2005.
> (http://lists.oasis-open.org/archives/tc-announce/200503/msg00
> 005.html). 
> 
> 2) XRI Syntax 2.0 Committee Draft 02 had a 15-day public 
> review starting 18
> October 2005, ending 2 November 2005.
> (http://lists.oasis-open.org/archives/tc-announce/200504/msg00
> 004.html).
> 
> 
> The following comments were received during the first public 
> review period
> on XRI Syntax 2.0 Committee Draft 01 (note that this public 
> review period
> also included XRI Resolution 2.0 Committee Draft 01 and XRI 
> Metadata 2.0
> Committee Draft 01.)
> 
> #1) Jerome Jump, Epok
> http://lists.oasis-open.org/archives/xri-comment/200503/msg00000.html 
> 
> #2) Dan Connolly, W3C
> http://lists.oasis-open.org/archives/xri-comment/200504/msg00000.html
> 
> #3) W3C Technical Architecture Group (TAG)
> http://lists.oasis-open.org/archives/xri-comment/200504/msg00003.html
> http://lists.oasis-open.org/archives/xri-comment/200505/msg00000.html 
> 
> #4) Mark Baker, Coactus
> http://lists.oasis-open.org/archives/xri-comment/200504/msg00004.html
> 
> One comment was received during the second public review period on XRI
> Syntax 2.0 Committee Draft 02:
> 
> #5) Norm Walsh, Sun
> http://lists.oasis-open.org/archives/xri-comment/200510/msg00000.html
> 
> 
> XRI TC RESPONSE
> 
> Comment #1 from Jerome Jump of Epok was relative to the XRI 
> Resolution 2.0
> specification, which is a not at this time being submitted 
> for consideration
> as an OASIS Standard. Mr. Jump pointed out a minor errata and 
> suggested
> alternative formatting of the XML examples in the 
> specification. Both of
> these have been incorporated in a subsequent working draft of 
> XRI Resolution
> 2.0.
> 
> Comment #2 from Dan Connolly of the W3C made the suggestion 
> that the OASIS
> XRI TC should register "xri:" as a URI scheme with the IETF as part of
> preparing for wide deployment. Technically the XRI Syntax 2.0 
> specification
> creates a new identifier that has a defined transformation into an IRI
> normal form and a URI normal form. The XRI TC does intend to 
> pursue IETF
> registration of the xri: scheme for XRIs in IRI and URI 
> normal form once XRI
> Syntax 2.0 reaches OASIS Standard status.
> 
> Comments #3 from the W3C TAG was subsequently referenced by 
> comment #5 from
> Norm Walsh and is discussed below.
> 
> Comment #4 from Mark Baker was a very brief statement arguing 
> against the
> deployment of any new abstract identifier scheme and favored 
> reuse of the
> HTTP URI scheme.
> 
> The W3C TAG's comments focused almost exclusively on the use 
> of XRIs to
> solve the problem of persistent identification. They felt 
> that the ways in
> which XRIs solve this problem using an additional layer of 
> indirection can
> also be achieved using HTTP URIs, and that the costs of 
> deploying the XRI
> scheme for persistent identification would not be overcome by 
> its benefits.
> 
> The TAG summarized their comments as follows:
> 
> "The recommendations that we have documented in Architecture 
> of the World
> Wide Web, Volume One state that "A specification SHOULD reuse an
> existing URI scheme (rather than create a new one) when it provides
> the desired properties of identifiers and their relation to
> resources." [2] In this case, a properly managed and supported use of
> the existing http scheme, based on the excellent analysis in your
> documents, does have the desired properties and can provide the same
> functionality without the loss of interoperability which would
> accompany a new scheme."
> 
> [2] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-scheme
> 
> The XRI was chartered in January 2003 because, after 
> considerable research,
> its organizers concluded that no URI scheme, including the 
> HTTP and URN
> schemes, provided "the desired properties of identifiers and 
> their relation
> to resources" when the desired properties were those of 
> uniform abstract
> identification, i.e., a consistent way of identifying 
> resources independent
> of domain, location, application, and interaction method.
> 
> In particular, the HTTP URI scheme did not (and could not) 
> fulfill this
> requirement because the vast majority of identifiers produced 
> using this
> scheme: a) are concrete identifiers (identifiers tied to a particular
> domain, directory, application, or device), and b) have (by 
> definition) a
> specific method of interaction (HTTP). As further evidence, 
> one reason the
> URN scheme (the closest thing to a URI scheme for abstract 
> identification)
> was developed at the IETF was because the HTTP URI scheme did 
> not include
> syntax for uniform persistent identification of resources.
> 
> More importantly, however, persistence is only one 
> requirement of uniform
> abstract identifiers (and in fact one that does not apply in many use
> cases.) Six additional categories of requirements were 
> enumerated in the XRI
> TC requirements document.
> 
> http://www.oasis-open.org/committees/download.php/2523/xri-req
> uirements-and-
> glossary-v1.0.doc 
> 
> Two of the most important are:
> 
> 1) Uniform cross-context identification. This is the 
> requirement to be able
> to share identifiers across hierarchies (multiple domains and 
> applications)
> with uniform interpretation (a directory concept known as 
> polyarchy.) XRI
> Syntax 2.0 provides a specific construct -- cross-references 
> -- for this
> purpose. Cross-reference syntax is particularly useful with identifier
> metadata; so useful that the XRI TC publishes an entire 
> specification (XRI
> Metadata 2.0) for the purpose of establishing uniform metadata for
> expressing the language, date, and version of an identifier. 
> 
> http://www.oasis-open.org/committees/download.php/11854/xri-me
> tadata-V2.0-cd
> -01.pdf
> 
> Furthermore, since the public review of XRI Syntax 2.0 
> Committee Draft 01 in
> March, new participants have joined the XRI TC expressly to 
> develop metadata
> for expressing the type of an identifier. This new form of 
> metadata can help
> solve longstanding interoperability problems when legacy 
> identifiers of a
> specific type (OIDs, UIDs, distinguished names, usernames, 
> etc.) need to be
> federated across enterprises.
> 
> http://lists.oasis-open.org/archives/xri/200509/msg00048.html
> http://lists.oasis-open.org/archives/xri/200509/msg00108.html 
> (see topic #3)
> 
> 2) Uniform federation. The generic URI syntax and the HTTP URI scheme
> support delegation syntax only in the authority segment, and 
> then only for
> IP addresses and DNS names. XRI Syntax 2.0 provides uniform federation
> syntax for both persistent and reassignable identifiers at 
> any level of
> hierarchy. This capability is particular useful in 
> conjunction with XRI
> cross-reference syntax, as it enables identifier authorities 
> at all levels
> of hierarchy to delegate identifiers using shared "dictionaries".
> 
> As stated in the XRI TC's charter and requirements document, 
> the goal of the
> XRI TC was to create a single uniform identifier syntax that 
> met these and
> four other categories of requirements. Such a syntax could 
> lead to the same
> widespread benefits from a uniform abstract identifiers that the Web
> currently enjoys from URIs and IRIs as uniform concrete 
> identifiers. We
> believe XRI Syntax 2.0 fulfills these requirements and recommend its
> advancement to an OASIS Standard.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>