- From: Schleiff, Marty <marty.schleiff@boeing.com>
- Date: Fri, 4 Jul 2008 00:10:03 -0700
- To: "Ray Denenberg, Library of Congress" <rden@loc.gov>
- Cc: <www-tag@w3.org>
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