[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Re:xri: registration with IETF/IANA?
|
Sorry, I should have copied this list when
I replied. Dave From: Dave McAlpin 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. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]