RE: Boeing XRI Use Cases

David,

Let me second John's thank you for such detailed input. I know you brought
this up once before in your message to this list on June 6 [1], in which you
provided a reference to your paper [2] that describes how URIs in new
schemes can be represented as HTTP URIs.

In looking back at that thread, it appears that it diverged quickly to
another subject before anyone pointed out what John did in his response
below, namely that after the TAG originally provided that same feedback to
the XRI TC in 2005, the TC responded by adding a major new portion of XRI
Resolution 2.0 specifying an HTTP(S) form of XRIs (which we called an HXRI)
together with a distributed proxy resolution protocol based on HTTP & HTTPS
(see Section 11 of [3]). That form of resolution proved to be very popular,
and subsequent revisions based on implementation feedback were one reason
completion of XRI Resolution 2.0 took an additional two years after the
completion of XRI Syntax 2.0 [4].

John's question is a good one: if it would satisfy the TAG's concerns if the
XRI TC specified that HXRIs are the form in which XRIs should be used on the
Web, that's a subject we should explore in earnest.

Best,

=Drummond (http://xri.net/=drummond.reed)  

[1] http://lists.w3.org/Archives/Public/www-tag/2008Jun/0041.html 
[2] http://dbooth.org/2006/urn2http/
[3] http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html
[4]
http://docs.oasis-open.org/xri/xri-syntax/2.0/specs/cs01/xri-syntax-V2.0-cs.
html 

> -----Original Message-----
> From: John Bradley [mailto:john.bradley@wingaa.com]
> Sent: Friday, July 11, 2008 5:23 PM
> To: Booth, David (HP Software - Boston)
> Cc: Schleiff, Marty; Ray Denenberg, Library of Congress; www-tag@w3.org
> Subject: Re: Boeing XRI Use Cases
> 
> David,
> 
> Thanks for the thoughtful input.
> 
> There are actually separate specs for XRI syntax and resolution.
> This is common with OASIS specs.
> 
> http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-
> cs.html
> http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/xri-
> resolution-V2.0-cs-01.html
> 
> I suspect that you may not have read the resolution spec.
> 
> I would point you to Section 11 of the resolution spec that in large
> measure deals with your suggestion.
> 
> The proxy service allows a xri in normal form to be used as a URL.
> 
> As an example =jbradley works as a openID via XRI resolution or at non
> openID 2.0 RP's as https://xri.net/=jbradley
> 
> This work was done after the TAG's original comments to XRI 1.0
> several years ago.
> We did listen and attempt to incorporate feedback as we are doing now .
> 
> I don't know if there is something special about perl.org that makes
> it more likely to continue running a proxy resolver than the current
> operators of the XRI Global Registry Service.
> 
> NeuStar http://www.neustar.biz/ the current operator is accredited by
> ICAN to operate .biz, .name and others as well as the North American
> NPAC for local phone number portability.
> 
> If there is some other arrangement for the proxy resolvers operation
> that would make people more comfortable then we should open that
> discussion,  though strictly speaking registry operations are outside
> of the scope of the XRI-TC, as they similarly are with the W3C.
> 
> If we:
> 1.  Use http://xri.net/=some-xri  as the scheme for URLs through a
> proxy resolver.
> 2.  Use =some-xri as the normal form for native resolution
> 3.  Stop using xri://=some-xri as a IRI
> 
> Would this be satisfactory to remove the TAGs objections?
> 
> I will excerpt from the TAG minutes
> http://www.w3.org/2001/tag/2008/07/10-minutes
> 
> > <Ashok> TimBl: Who is the design authority?
> >
> > <ht_wylie> ... it's a social problem -- they don't trust, or want to
> > work with, ICANN and the rest of the authority structure
> >
> > <Ashok> ask them is it that it cannot be done technically or socially
> >
> > <ht_wylie> ... This kind of group wants to be _socially_ independent
> > of ICANN and so on
> >
> > <Ashok> do you want to be independent of ICANN
> >
> > stuart: Have you seen latest decision from ICANN, re TLDs for sale?
> >
> > <timbl> yes
> >
> > <DanC> impact of lots more top level domains on the Web? Dan
> > Connolly (Thursday, 26 June) http://lists.w3.org/Archives/Public/www-
> tag/2008Jun/0113.html
> >
> > danc: XRIs are showing up in oauth namespace declarations;
> > namespaces are specified as URIs; that would imply that XRIs have to
> > be URIs.
> >
> > <DanC> (I tried to say IRI; but since IRIs and URIs share a scheme
> > registry.)
> >
> > <Ashok> but XRI not registered as URI scheme
> >
> > ht: If an XRI URI scheme is applied for, then it will have to meet
> > the bar for new URI schemes
> > ... What can we do to help meet our obligations here?
> >
> 
> While I enjoy the characterization of us,  I have a hard time thinking
> of any OASIS TC as being particularly anti "authority structure".  I
> may have that framed:)
> 
> If the W3C has some attachment to ICANN that makes it a superior
> administrator of namespaces, I for one would be interested in hearing
> that.
> 
> In our call with the TAG last week I got the impression that wasn't
> the significant issue.  If it is a significant issue it could be
> addressed.
> 
> I am the person who didn't register the xri: scheme with  iana.  So
> Ashok is correct XRI isn't a registered scheme.
> The advice we were given by OASIS staff was that it would be better to
> register after the XRI 2.0 vote.
> So I didn't put in the provisional registration.  My Bad.
> 
> We are given to believe part of that bar Henry is referring to, for
> new URI schemes is having a ratified spec.  The TC decided to move
> forward with the OASIS vote before applying to iana.
> 
> Ironically one of  the reasons some people voted against the spec was
> that the scheme wasn't registered.
> An unintentional Catch 22.
> 
> If registering the scheme were the root issue it could be easily dealt
> with if we knew the criteria for the bar that is referred to.  We
> believe that the xri: scheme proposed in XRI 2.0 meets the
> requirements of RFC4395 and RFC3986.
> 
> We believe that XRI also holds true to the principles set forth in
> http://www.w3.org/DesignIssues/Axioms.html
> 
> If the TAG or others believe that there are technical issues that need
> to be addressed in the XRI 2.0 specs to make them conferment with the
> relevant RFCs then we should establish a process to make the required
> changes for the next draft of the XRI spec.
> 
> I believe, and please correct me if I am wrong in my belief from last
> weeks call that the TAG position is, (I am paraphrasing now):
> 1. There should be no new URI schemes registered.
> 2. The http scheme should be the only namespace, to prevent
> fragmentation.
> 
> I ask simply is this the bar we must meet?
> 
> Our goal in making a IRI/URI form of a XRI was to fit in to the
> existing structure rather than to usurp it.
> 
> If the W3C is happy with XRI as long as it isn't a URI scheme and is
> mapped through the HXRI mechanism only, we could certainly do that.
> 
> I think that would reduce compatibility and interoperability, not
> increase it.  Perhaps the TAG sees something the XRI-TC doesn't in
> this respect.
> 
> I want to give you a quote by TBL from the Axioms of Web Architecture,
> and a question.
> "URI space does not have to be the only universal space"
> 
> My question is, is this still the position of the W3C?
> 
> I look forward to working with the TAG members on this question.
> 
> Regards
> John Bradley
> OASIS IDTRUST-SC
> =jbradley
> 
> 
> On 11-Jul-08, at 2:00 PM, Booth, David (HP Software - Boston) wrote:
> 
> >
> > Marty,
> >
> > I think XRIs have a major adoption problem.  Their special
> > properties are only useful to the extent that machines can recognize
> > them and invoke their special semantics.  And people are not jumping
> > all over themselves to implement new URI schemes in their software.
> >
> > On the other hand, HTTP is ubiquitous.  This is why I believe you
> > will have significantly greater success piggybacking the XRI ideas
> > on top of HTTP URIs, rather than inventing an new URI scheme.
> >
> > I see that the XRI 2.0 spec already defines lossless transformations
> > to and from IRIs (and hence URIs):
> > http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-
> cs.html#_Converting_XRIs_to_URIs
> > http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-
> cs.html#_Toc117301857
> > so presumably an absolute XRI reference and its corresponding
> > absolute URI reference could be considered semantically equivalent.
> > I notice that such a URI reference always starts with the string
> > "xri:", so presumably that string is how XRI-aware software would
> > recognize that the URI is a URI-encoded XRI, and interpret its
> > meaning as defined in the XRI spec.  Surely there is nothing magic
> > about that particular string: if the XRI spec had instead decided on
> > some other arbitrary URI-conformant string such as "fribblejam:",
> > and written the specs accordingly, XRIs would work just as well.
> >
> > Suppose the OASIS XRI technical committee (TC) were to decide to
> > make XRIs more web friendly and lower the barrier to their adoption
> > by writing a second "HTTP-XRI" spec that bases XRI's on http URIs
> > roughly as follows.
> >
> > 1. The new HTTP-XRI spec is written to require the string
> > "http://purl.org/xri/" at the beginning of an HTTP XRI, instead of
> > starting with "xri:".  Aside from this simple syntactic difference,
> > the structure and semantics are defined to be *exactly* the same as
> > for an existing URI-encoded XRI.  (Okay, I will admit that some
> > additional %-escaping might be needed also -- I haven't checked the
> > syntax rules in enough detail to know -- but surely that is a
> > technical detail that could be worked out, and does not
> > significantly affect the point of this example.)
> >
> > 2. The TC registers the http://purl.org/xri/ subspace of purl.org's
> > URI space and sets up a corresponding partial redirect so that when
> > a HTTP XRI such as
> http://purl.org/xri/@boeing.com/(@example%2Fabc%252Fd%2Fef)
> >  is dereferenced in a browser, some useful information is returned,
> > perhaps along the lines of:
> >
> >        - General marketing info about HTTP-XRIs, what they mean, how
> > great they are and how to adopt them;
> >
> >        - Specific info about
> http://purl.org/xri/@boeing.com/(@example%2Fabc%252Fd%2Fef)
> > , perhaps by forwarding the request to a boeing.com server; and/or
> >
> >        - Pointers to HTTP-XRI plug-ins or toolkits, to help
> > bootstrap the adoption of XRI-aware software.
> >
> > Some observations:
> >
> > - HTTP-XRI-aware software would merely look for "http://http-xri.org?xri
> > :" at the beginning of a URI instead of looking for "xri:", and
> > thereafter apply the *exact* same processing as it would for URI-
> > encoded XRIs, since HTTP XRIs would have the *exact* same semantics.
> >
> > - Non-HTTP-XRI-aware software would not know about the special
> > semantics of these URIs (just as non-XRI-aware software would not
> > know about the special semantics of XRIs), so it would not be any
> > worse off than for the XRI case.  However, the software *might*
> > still be able to retrieve useful information by dereferencing the
> > URI that it could present to the user, which could not be done in
> > the XRI case.
> >
> > - Software that is only *partially* XRI-aware might not have the
> > ability to do XRI resolution -- HTTP resolution is ubiquitous, but
> > XRI resolution clearly is not -- *but* it may still know a little
> > about XRIs and may still be able to make use of some of the
> > information returned by dereferencing the HTTP XRI, which also could
> > not be done for the XRI case.
> >
> > In other words, for the most part, HTTP-XRIs would have virtually
> > the same benefits as existing XRIs, plus they would have additional
> > advantages:
> >
> > - they would be more web friendly (following good web architectural
> > principles of not creating new URI schemes); and
> >
> > - being potentially dereferenceable with HTTP, they could have a
> > significantly lower barrier to adoption as compared with existing
> > XRIs.
> >
> > Of course, as with anything, there is a down side:
> >
> > - The URIs would be a little longer.
> >
> > - A person looking at an HTTP XRI who is not familiar with XRIs may
> > not immediately realize that it has special XRI semantics.  But
> > being potentially dereferenceable, HTTP XRIs could give them an easy
> > way to find out.
> >
> > - Dereferencing by non-XRI-aware software would depend on the
> > stability of purl.org, and there is no absolute guarantee that
> > purl.org will continue to exist and be supported years from now.  On
> > the other hand, there is no guarantee that XRI resolution software
> > will continue to be supported years from now either.  And if I were
> > deciding where to place my bet, I'd say it is *substantially* more
> > likely that purl.org will continue to be supported years from now
> > than that XRI resolution software will continue to be supported, but
> > of course others may think differently.
> >
> > My question: what would you think of the pros/cons of such an
> > approach?
> >
> >
> >
> > David Booth, Ph.D.
> > HP Software
> > +1 617 629 8881 office  |  dbooth@hp.com
> > http://www.hp.com/go/software
> >
> > Statements made herein represent the views of the author and do not
> > necessarily represent the official views of HP unless explicitly so
> > stated.
> >
> >
> >> -----Original Message-----
> >> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]
> >> On Behalf Of Schleiff, Marty
> >> Sent: Friday, July 04, 2008 3:10 AM
> >> To: Ray Denenberg, Library of Congress
> >> Cc: www-tag@w3.org
> >> Subject: RE: Boeing XRI Use Cases
> >>
> >>
> >> Hi Ray (& All),
> >>
> >> I apologize that this response is so much longer than your question.
> >>
> >> ** Examples for Fully Qualified Identifiers: **
> >>
> >> At Boeing my employee number (which we call a BEMSID) is 27256. We've
> >> registered "boeing" in the XRI "@" namespace.
> >> "@boeing*bemsid*27256" is
> >> a Boeing minted XRI representing me. We have an inventory management
> >> system (which we call "CIIM") in which computing device IDs
> >> are managed.
> >> We could have a device ID with a value of 27256 (we don't
> >> currently, but
> >> the potential exists). "@boeing*ciim*27256" would be a Boeing
> >> minted XRI
> >> representing that device. We have an application registry in which
> >> alpha-numeric identifiers are associated with applications.
> >> At one point
> >> we had a registered application called 27256.
> >> "@boeing*applications*27256" is a Boeing minted XRI representing that
> >> application. As we now routinely authenticate & authorize breathing
> >> users, web service applications, and devices to access networked
> >> resources, we need to differentiate between 27256 the breathing user,
> >> 27256 the device, and 27256 the application.
> >>
> >> ** Examples for Identifier Types in Directories: **
> >>
> >> Note that this use case is something we hope to be able to do in the
> >> future; today we're still forced to use different attribute
> >> types in our
> >> directory. The string value "cn=27256,ou=people,o=boeing,c=us" is
> >> obviously not equal to "CN=27256;   OU=People, o=BOEING; c=US". But
> >> if
> >> those two values are distinguishedName (DN) string
> >> representations, then
> >> they are considered equal. Although not yet defined, for purposes of
> >> this example, let's assume that XRI metadata has been extended so
> >> that
> >> "$dn" represents an identifier type of distinguishedName. Our
> >> directory
> >> (after being enhanced to support XRI metadata) could
> >> recognize that the
> >> following two XRIs are equivalent:
> >>
> >>   $dn*(cn%3D27256,ou%3Dpeople,o%3Dboeing,c%3Dus)
> >>
> >>   $dn*(CN%3D27256;%20%20%20OU%3DPeople,%20o%3DBOEING;%20c%3DUS)
> >>
> >> Note that URI syntax, and therefore XRI syntax, requires percent
> >> encoding for spaces, slashes, and certain other characters
> >> appearing in
> >> an XRI cross reference(the part between the parentheses), yielding
> >> complex looking identifiers. However, identifiers expressed within
> >> XRI
> >> cross references are probably most useful to infrastructure
> >> applications, and would tend to be hidden from end users.
> >>
> >> Assuming XRI metadata has been further extended so that "$openid"
> >> represents an identifier type of OpenID and "$handle" represents an
> >> identifier type of Handle, then our directory could know the
> >> appropriate
> >> matching rules to use for identifiers like the following:
> >>
> >>   $openid*(http%3A%2F%2Fmls.signon.com)
> >>
> >>   $handle*(123%2F4567)
> >>
> >> ** Why suggested alternatives (http:) are inadequate: **
> >>
> >> I recognize that mechanisms described in
> >> http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 could be used by
> >> minters to manifest characteristics of identifiers and claims about
> >> identifiers (like matching rules, sorting rules, persistence, one-
> >> time
> >> pseudonym, resolution protocols, presence of check digits). Mentioned
> >> mechanisms include use of naming conventions (mentioned in section
> >> 2.1
> >> and 2.6), use of the query component (mentioned in section
> >> 2.5), use of
> >> response headers (mentioned in section 2.6), and naming authority
> >> imposed constraints (mentioned in section 2.6). Are there
> >> others that I
> >> missed?
> >>
> >> I frown on the response headers mechanism. If for some reason
> >> resolution
> >> of an http: URI fails (network problems, site down for maintenance,
> >> or
> >> the URL is intended as a simple identifier with no corresponding web
> >> page) then no response headers are returned. I much prefer identifier
> >> metadata (not resource metadata) to be inherent in the identifier.
> >>
> >> I agree with the TAG finding on The Use of Metadata in URIs (see
> >> http://www.w3.org/2001/tag/doc/metaDataInURI-31.html). Section 2.1
> >> states "Web software MUST NOT depend on the correctness of metadata
> >> inferred from a URI, except when the encoding of such metadata is
> >> documented by applicable standards and specifications." So to rely on
> >> metadata inferred by naming conventions, a naming authority's
> >> use of the
> >> query component of http: URIs under its control, or a naming
> >> authority
> >> imposed constraint, such conventions and constraints need to be
> >> documented in standards, specifications, Web and Internet RFCs and
> >> Recommendations, documentation provided by the URI assignment
> >> authority,
> >> or some such place.
> >>
> >> When you (or your software) encounters a URI like
> >> "http://mls.signon.com" how do you (or your software) know
> >> where to find
> >> the documented constraints and/or conventions? Can you tell
> >> that it's an
> >> OpenID and therefore has certain characteristics and behaviors? How
> >> would you (or your software) even ask signon.com where they keep
> >> their
> >> documented conventions and constraints. If you (or your software)
> >> actually succeeded in finding signon.com's documentation, how
> >> would your
> >> software make sense of it? Can you (or your software)
> >> recognize whether
> >> or not "http://mls.signon.com" is persistent or reassignable? Even if
> >> the identifier included some metadata (e.g.,
> >> http://mls.persistent.example.com), would you (or your software)
> >> recognize it as meaningful metadata?
> >>
> >> I think the fourth Conclusion in section 3 of The Use of Metadata in
> >> URIs does a pretty good job of explaining why naming conventions and
> >> constraints imposed by naming authorities are not adequate for the
> >> representation of metadata in URIs: "People and software using URIs
> >> assigned outside of their own authority should make as few
> >> inferences as
> >> possible about a resource based on its URI. The more dependencies a
> >> piece of software has on particular constraints and
> >> inferences, the more
> >> fragile it becomes to change and the lower its generic utility."
> >> XRI's
> >> use of syntactic metadata (not inferred metadata) is useful
> >> both within
> >> and beyond the scope of a particular naming authority, which is a
> >> compelling justification for XRI.
> >>
> >> Thanks for your interest,
> >>
> >> Marty.Schleiff@boeing.com; CISSP
> >> Associate Technical Fellow - Cyber Identity Specialist
> >> Information Security - Technical Controls
> >> (206) 679-5933
> >>
> >> -----Original Message-----
> >> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> >> Sent: Thursday, July 03, 2008 8:19 AM
> >> To: Schleiff, Marty
> >> Cc: www-tag@w3.org
> >> Subject: Re: Boeing XRI Use Cases
> >>
> >> Marty -
> >>
> >> I appreciate the effort that went into this.
> >>
> >> Probably the biggest roadblock preventing me from coming to terms
> >> with
> >> XRIs is the lack of concrete, comprehensible, and meaningful
> >> examples.
> >> (By "meaningful", I mean examples that illustrate why suggested
> >> alternatives are not adequate.)
> >>
> >> I wonder if you could add examples for (at least) these two sections
> >> (and perhaps more substantial examples for the other four sections):
> >> - Fully Qualified Identifiers
> >> - Identifier Types in Directories
> >>
> >> Thanks.
> >>
> >> --Ray
> >> ----- Original Message -----
> >> From: "Schleiff, Marty" <marty.schleiff@boeing.com>
> >> To: <www-tag@w3.org>
> >> Sent: Tuesday, July 01, 2008 5:55 PM
> >> Subject: Boeing XRI Use Cases
> >>
> >>
> >>
> >> Hi All,
> >>
> >> Ann Bassetti (Boeing's AC Rep at W3C) and I (a Boeing
> >> participant on the
> >> OASIS XRI TC) agreed it would be helpful to make Boeing use cases for
> >> XRI available for public discussion. Hopefully these use
> >> cases, together
> >> with ensuing discussions, will help resolve differences
> >> between the TAG
> >> and the XRI TC in their opinions about XRI. The use cases can
> >> be seen at
> >> http://wiki.oasis-open.org/xri/BoeingXriUseCases.
> >>
> >> Marty.Schleiff@boeing.com; CISSP
> >> Associate Technical Fellow - Cyber Identity Specialist
> >> Information Security - Technical Controls
> >> (206) 679-5933
> >>
> >>
> >>
> >>
> >

Received on Monday, 14 July 2008 00:30:07 UTC