W3C home > Mailing lists > Public > www-tag@w3.org > July 2008

Re: Boeing XRI Use Cases

From: Felix Sasaki <fsasaki@w3.org>
Date: Thu, 17 Jul 2008 19:41:12 +0900
Message-ID: <487F21C8.9060609@w3.org>
To: John Bradley <john.bradley@wingaa.com>
CC: "Henry S. Thompson" <ht@inf.ed.ac.uk>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, www-tag@w3.org

Hello John,


John Bradley さんは書きました:
> I want to rase a question to the group in general.
>
> The XRI-TC has defined 7 forms for the representation of XRI, and the 
> transformations between them.
>
> I reviewed them in response to a question by David Orchard on this 
> thread July 14.
>
> Three of those forms involve using the xri: scheme indicator at the 
> start.
>
> Thee forms one scheme? How can the be?
>
> I think this question is causing some of the push back.
>
> People are concerned that strings that have a valid scheme prepended 
> are not valid URIs.
>
> This is true, however this situation is NOT the invention of the 
> XRI-TC, nor is it unique to XRI.
>
> The XRI-TC followed RFC 3987 to allow internationalized forms of XRIs.

I personally think that this is the right approach (without judging XRIs 
in general).

>
> XRI has two IRI forms:
> 1. IRI-Normal This allows UTF-16 Though UTF-8 is recommended
> 2. IRI-UTF8 A more restrictive form allowing only UTF-8
>
> The one difference between a http: IRI and a xri: IRI is that XRI 
> specifies the more restrictive NFKC Normalization across the entire 
> string, Where http uses two separate normalization's PUNyCODE for the 
> Authority segment and NFC for the path, and don't ask about the query 
> string:)
>
> XRI has one and only one URI form. The transforms to and from this 
> form are clearly defined.
> This is the form that is uses anyplace a URI is required. A IRI is NOT 
> a URI, it would be WRONG to use a IRI in an XML document for 
> name-spacing.
>
> The XML specs are clear and unambiguous use a URI.
>
> XRI clearly differentiates between the two things.
>
> I am currently getting surprising push back on defining IRIs for use 
> with openID. With ICANN's recent decisions on DNS http: IRIs are coming.
>
> If we had something other than a URI scheme to identify a IRI that 
> might address some of the issues.
>
> I am tempted to ask if people are opposed to IRI RFC3987 in some way? 
> However that would probably be impolitic.
>
> Yes there are many open question regarding XRI's fundamental right to 
> exist.
>
> However is there an issue around our use of IRI that is going unspoken?
>
> If there was no IRI form would anyone think that having a xri: scheme 
> was a more reasonable thing.

I don't see any issues and, seeing no responses to your question in this 
thread I think others agree silently with that.

> I don't want to dismiss the opinion expressed on this thread that 
> having a scheme is the appropriate way to represent a protocol other 
> than http being used for a URI.
>
> I think there are three major options at this point:
> 1. Use a URI scheme to indicate that a string is an XRI, Plus HXRI for 
> backwards compatibility with browsers and click behavior.
> 2. HXRI with special coding in the authority segment
> 3. HXRI with special encoding in the Path.
>
> I suppose there is a fourth possibility which is only using xri: on 
> the URI form and not having an IRI form.
>
> I suppose we could always define a http: IRI form?
>
> So I would appreciate your thoughts on how IRI plays into this 
> discussion on XRI.

IMO IRIs are unrelated to the main topic of this discussion.

Felix

>
> Best Regards
> John Bradley
> OASIS IDTRUST-SC
> http://xri.net/=jbradley
>
>
>
>
>
>
>
Received on Thursday, 17 July 2008 10:42:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:23 UTC