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 Friday, 4 July 2008 07:10:51 UTC