Forwarded message 2
Thanks for the feedback Dan. Responses are inline.
Dave
> -----Original Message-----
> From: comment-form@oasis-open.org [mailto:comment-form@oasis-open.org]
> Sent: Tuesday, April 26, 2005 9:20 PM
> To: xri-comment@lists.oasis-open.org
> Subject: [xri-comment] Public Comment
> Comment from: connolly@w3.org
> Name: Dan Connolly
> Title: IETF Liaison
> Organization: W3C
> Regarding Specification: XRI
> tried to send this earlier; can't find it in the archive, so trying
> agin via this form...
> From: Dan Connolly <connolly@w3.org>
> Date: April 22, 2005 3:51:44 PM EDT
> To: xri-comment@lists.oasis-open.org
> Subject: xri: registration with IETF/IANA?
> "The purpose of this committee is to define a URI-compatible
> identifier scheme and resolution protocol that meets these requirements."
> -- http://www.oasis-open.org/committees/xri/charter.php
> The next sentence is confusing...
> "The XRI scheme will be a superset of the URI scheme defined by RFC
> 2396 and RFC 2396bis."
> Does that mean that every URI is also an XRI? Or that xri: is designed
> to be a new URI scheme?
No. "Superset" was an unfortunate choice there. We now tend to talk
about XRIs as "URI-compatible" (see my response below for more
information).
It's worth pointing out, though, that XRI borrows heavily from generic
URI syntax, and consequently most URIs with a DNS authority component
can be converted to an XRI by replacing the scheme name with "xri". This
must be done carefully, however, because XRI defines semantics for many
of the characters in RFC3986's [1] sub-delims production. RFC3986 says
these characters "are protected from normalization and are therefore
safe to be used by scheme-specific and producer-specific algorithms for
delimiting data subcomponents within a URI." If either a scheme or a
producer uses characters from RFC3986's sub-delims production as
delimiters and these characters have a defined meaning in XRI, special
consideration is required when converting to an XRI. There are also
certain unusual forms of URIs that are not legal as XRIs - a URI with an
empty first segment in the path, for example, or an explicitly null user
in the authority, like http://@www.example.com
<http://@www.example.com/> . These are uncommon in practice, but must be
considered when mapping an existing URI into an XRI.
> xri: is not registered...
> http://www.iana.org/assignments/uri-schemes
> The process for making a new URI scheme is "IETF consensus action"
> i.e. the normal IETF process, starting with Internet Drafts and such.
> I don't see any proposals for xri in Internet Drafts nor relevant
> mailing lists.
> I think IETF registration should get started, at least in the form of
> an Internet Draft, before the OASIS membership is asked to endorse
> XRIs and before they're deployed at any scale.
We could definitely use some advice here. XRI in its native form can't
be a URI scheme because it allows syntax that doesn't meet the
requirements of RFC3986. Section 2.3.1 of the XRI syntax spec [2]
defines an algorithm to map XRIs into a form, called URI-normal form,
that satisfies the syntax and processing rules defined by RFC3986. XRIs
mapped to URI-normal form can thus be used in contexts that expect a
URI. Like IRIs mapped to URIs following the algorithms in RFC3987 [3],
an XRI in URI-normal form can be a little hard to read because of
percent-encoded characters.
We've discussed the possibility of defining a URI scheme for XRIs in
URI-normal form. The danger, of course, is that having two normative
specs for the same identifier could easily produce an ambiguous or
inconsistent definition. The current draft of 2717bis-2718bis,
"Guidelines and Registration Procedures for new URI Schemes" [4], makes
it much easier for schemes defined outside the IETF to be formally
registered. This may ultimately provide a path that minimizes the
overlap between XRIs defined in URI-normal form and those defined in
XRI-normal form.
Input from the TAG on this issue would be very much appreciated.
> Oh... I see a launch has already happened...
> "Identity Commons commenced its early registration program for i-names
> on October, 25th 2004"
> -- http://www.idcommons.net/
> and I see a press release
> http://idcommons.net/press/iname-launch-2004-10-25.html
> ... though I don't see technical details of how xri: names are
> actually used.
This is a vendor specific application, developed and deployed before the
spec was standardized. While we appreciate the early adoption, the TC
has no obligation to lock down the spec to support i-names.
References
[1] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifier (URI): Generic Syntax", http://www.ietf.org/rfc/rfc3986.txt,
STD 66, RFC 3986, January 2005.
[2] D. Reed, D. McAlpin, "Extensible Resource Identifier (XRI) Syntax
V2.0",
http://docs.oasis-open.org/xri/xri/V2.0/xri-syntax-V2.0-cd-01.pdf, March
2005.
[3] M. Duerst, M. Suignard, "Internationalized Resource Identifiers
(IRIs)", http://www.ietf.org/rfc/rfc3987.txt, RFC 3987, January 2005.
[4] T. Hansen, T. Hardie, L. Massinter, "Guidelines and Registration
Procedures for new URI Schemes",
http://larry.masinter.net/draft-hansen-2717bis-2718bis-uri-guidelines-03
.html, Work-in-progress, February 20, 2005.