Re: Boeing XRI Use Cases

David,

In the existing spec there are a number of forms. this may have  
required additional clarification as it split across the syntax and  
resolution specs.

Let me try and summaries:
1. Native Form "step 0" of the transform ladder  It is defined as an  
XRI reference represented in the context of a computer application or  
in other media (print, audio, etc.)

2. XRI-Normal Form  "step 1"  The steps required to transform an XRI  
reference in native form to XRI-normal form are:
	
If the representation of the XRI reference in native form is not yet  
digitized, or if it is digitized but does not use an encoding based on  
the Unicode Character Set (UCS), it MUST be converted to a sequence of  
characters from the UCS. The UTF-8 encoding is  
RECOMMENDED.Programatically this is typically a check to discover the  
character encoding of the identifier, followed by a library called to  
convert from any non-UCS-based encoding to a UCS-based encoding.
	
If any information present in Native Form would be lost in the  
conversion to a sequence of UCS character, this information MAY be  
encoded as identifier metadata in the form of cross-references from  
the XRI $ Dictionary. For example, a $l (language) cross-reference may  
be inserted to indicate the glyph of a Kanji character. Note that this  
metadata becomes part of the formal XRI and thus is significant for  
comparison in all XRI forms. This step will also typically be a  
library call, although one needed only in applications that deal with  
XRIs subject to this type of ambiguity.
	
This sequence of UCS characters MUST be normalized according to NFKC  
as defined in the Unicode specifications (UTR15). This is typically a  
library call to an NFKC normalization library.
	• The authority segment of the XRI MUST be normalized to lowercase,  
unless it overriden by $ces or other $ metadata specifying case.
	• The target values of $ip, $dns, and $uri authority segments MUST be  
normalized as specified in the XRI $ Dictionary.
	• All unnecessary percent-encoding MUST be removed, and all remaining  
percent encoding MUST use uppercase A through F for hex digits.
	• All /./ and /../ segments MUST be removed.
	• All XRIs used as encapsulated references MUST be in XRI-normal  
form, i.e., an xri:// prefix MUST be removed.

3. XRI-UTF8 Form.  This is a subset of XRI-normal form for use in  
directory and database applications which require UTF-8 encoding. The  
only additional requirement is that the UCS encoding be UTF-8.

4. IRI-Normal Form "step 2" IRI-normal form is required for full  
compatability with the IRI specification (RFC 3987). The steps for  
transformation of an XRI reference into IRI-normal form are currently  
defined in section 2.3.1 of XRI Syntax 2.0.

Note that this transformation is not idempotent (i.e., it may yield a  
different result if applied more than once), so it is very important  
that implementers not apply this transformation more than once to  
avoid changing the semantics of the identifier.
	• Percent-encode all percent “%” characters as “%25” across the  
entire XRI reference.
	• Percent-encode all number sign “#” characters that appear within a  
cross-reference as “%23”.
	• Percent-encode all question mark “?” characters that appear within  
a cross-reference as “%3F”.
	• Percent-encode all slash “/” characters that appear within a cross- 
reference as “%2F”.

5. IRI-UTF-8 Form This is a subset of IRI-normal form for use in  
directory and database applications which require and IRI and UTF-8  
encoding. The only additional requirement is that the UCS encoding be  
UTF-8.

6. URI-Normal Form "step 3" URI-normal form is required for full  
compatability with the URI specification (RFC 3986). The rules for  
transformation of a valid IRI into a valid URI are defined by section  
3.1 of RFC 3987. The steps required to transform an XRI reference to  
URI-normal form are:
	• If the XRI reference is not in IRI-UTF-8 form, first transform it  
into IRI-UTF-8 form.
	• Percent-encode the UTF-8 octets.

7. HXRI Form "step 4"  HXRI (HTTP XRI) form is URI-normal form with  
the "xri://" prefix replaced by an XRI proxy resolver prefix so the  
XRI is expressed as a valid HTTP(S) URI.
	• If the XRI reference is not in URI-normal form, first transform it  
into URI-normal form.
	• Remove the "xri://" prefix.
	• Add a valid HXRI proxy resolver prefix.

It is clear that HXRI was intended to be used with any proxy resolver  
there is no real special encoding of the URL at the moment.
There is a best practice to name proxy resolvers starting with https://xri 
.

This would need to be addressed.

To your question of is a string prefixed with xri: a URI?

The answer from above is that it like any IRI may be in IRI form or  
URI form.

In places like XML the URI-Normal form should be used for compatibility.
I will add that the http: scheme IRI's have exactly the same issue and  
should not be used in namespace declarations.

I personally think all XML namespace declarations should be http:  
URLs.  Using XRIs for namespace declarations is unnecessary at best.
That may not win me a lot of friends but I think its true.

The IRI-Normal form exists and is currently the way international  
identifiers are represented in openID.
I am working on getting support for http: scheme IRIs.

So David,  I will ask the question if it were clear that only the URI- 
Normal form could be used for namespace declarations,  and we  
recommend that http: URLs should always be preferred in declarations  
over XRI.   Would this change your position on the xri: scheme.

Mind you I am not trying to change your opinion.  I am just trying to  
get to the root of the issue.

Regards
John Bradley
OASIS IDTRUST-SC
=jbradley


On 14-Jul-08, at 10:19 PM, David Orchard wrote:

> Mark,
>
> Part of the issue is the confusion as to whether strings prefixed  
> with xri: is a new URI scheme or not.  A variety of people and XRI  
> documents have said that xri: prefixed strings are NOT URIs because  
> such xri: strings are not valid URI strings, hence the need for the  
> XRI to URI mapping.  My interpretation, perhaps wrong, is that a new  
> string identifier format was being proposed that was NOT a URI.   
> There is quite some documentation to support this, such as the  
> material that specifies that a URI prefixed by xri: may be  
> interpreted as an XRI in the presence of an XRI base declaration(not  
> sure quite the terminology used) and? the absence of a URI base  
> declaration such as xml:base.  Which means every XML processor needs  
> to be preceeded by an XRI processor for the correct processing of  
> any xri: strings.
>
> Cheers,
> Dave
>
> On Mon, Jul 14, 2008 at 10:04 PM, Mark Baker <distobj@acm.org> wrote:
>
> Hi John,
>
> I suspect you're asking a lot of questions here to the TAG, rather
> than specifically to myself, so forgive me for just responding to
> those questions that I feel I'm in a position to respond to.
>
> On 7/15/08, John Bradley <john.bradley@wingaa.com> wrote:
> > Hi Mark,
> >
> > If we were to proceed with David's recommendation to remove the  
> xri: scheme
> > from the spec and use the HXRI form for web compatibility through  
> a proxy,
> > then we would need some way for XRI aware applications to  
> recognize what the
> > actual protocol of a http scheme URL is.   We are open to finding  
> the
> > optimal way to achieve this.
> >
> > We had been operating under the impression that the scheme of a  
> URI was
> > designed to do that.
> > This we are told is outdated information.
>
> No, you were correct to use a new URI scheme.
>
> Just because new URI schemes are more often than not a bad idea,
> doesn't mean one should standardize a way to replace URI-scheme
> functionality elsewhere in the syntax of a URI.
>
> IMO, the advice you've been given to avoid new URI schemes should have
> been rephrased to make it clearer where the problem was.  The advice
> should have been to try and solve the problems that XRIs are intended
> to solve using http URIs (without additional license ala HXRIs).
>
> > I ask, are all protocols and transports that are requested to use  
> the http
> > scheme going to be subjected to the same level of scrutiny?
>
> Absolutely.  The bar is pretty high over on uri-review, where we
> regularly have to educate folks about the value of reusing existing
> schemes such as http.
>
> > Just for my clarification, is your position that, if XRI can be  
> shown to
> > meet certain standards of utility it should register the xri:  
> scheme? This
> > will allow the authority segment of the http scheme to remain  
> opaque.
>
> Yes.
>
> Mark.
> --
> Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
> Coactus; Web-inspired integration strategies  http://www.coactus.com
>
>