[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Identifier Type
Mike, Great discussion. You mention, "It seems to me that there are still unstated requirements wrt this issue." I didn't know whether you were including the requirements I added yesterday to the proposal page at: http://wiki.oasis-open.org/xri/Xri2Cd02/MetaData/I1IdentifierTypeSection I hadn't seen Marty's message when I wrote these, and I was trying to capture some of the "unstated" requirements that I've understood from the discussions I've part of with him and NAC folks. The ones I listed were: 1) To have a uniform, interoperable representation in XRI of different types of identifiers commonly used in enterprise systems. 2) For this uniform representation to facilitate matching in enterprise directory systems and other applications that need XRI equivalence checking (see http://wiki.oasis-open.org/xri/Xri2Cd02/SynTax/I1DirectoryAttribute Syntax Issue #1: Directory Attribute Appendix]). 3) For this uniform representation to explicitly include the identifier type metadata so applications can take advantage of this metadata, for example to do a type-specific forms of local resolution or determine equivalent identifiers of other types. 4) For this uniform representation to be able to be independent of any specific authority that may assign identifiers of this type. 5) For this uniform representation to be able to be expressed in the context of any authority that assigns or accepts cross-references to identifiers of this type. 6) For this uniform representation to be able to be expressed in any other context which may accept an XRI cross-reference. I think it's the last four requirements that highlight the need for an explicit XRI "type" metadata namespace. As an example of #3, for instance, if the type metadata is in the XRI itself, then an XRI client could be programmed to know explicitly which XRID Service type to select if it sees an identifier "tagged" as a certain type. To use Marty's OID example, if an XRI client was given the following three XRIs... xri://@example*authority/1.42.174.50 xri://@example*authority/($t/oid/1.42.174.50) xri://@example*authority/($t/ip/1.42.174.50) ...once the client had resolved the authority segment and obtained an XRID, from the first XRI, it would have no way of telling if the path portion is an OID or an IP address. However from the second and third, the XRI client could know exactly what to do for local resolution (if it was configured for those instructions). (NOTE TO ANYONE READING THIS MESSAGE OUT OF CONTEXT: Neither "$t" nor the tags "$t/oid" or "$t/ip" exist yet! This is still only a hypothetical example of the direction we might decide to take.) =Drummond -----Original Message----- From: Lindelsee, Mike [mailto:mlindels@visa.com] Sent: Thursday, September 15, 2005 3:51 PM To: xri@lists.oasis-open.org Subject: FW: [xri] Identifier Type Marty, It is great to have another person engaged in the discussion. As far as I can tell, you haven't expressed any requirements that we didn't already take into account when designing syntax and resolution as described in XRI 2.0 cd01. I'll give a short explanation of why the current committee draft meets those requirements and would be happy to further discuss this in an email thread (or call) with anyone interested. The syntax of XRIs allows them to readily express hierarchy, be globally unique, and express the authority used for both resolution and local access. The current architecture doesn't explicitly express type (i.e., have type embedded in the identifier), but does support a variety of local access services that allow identifiers to be resolved using the correct "type" for a particular application. This is *exactly* the reason we specified local access as part of resolution (e.g., an XRID could contain a service element for those "types" that the identifier could be resolved as). Re your third point, XRI does support authority namespaces that don't imply specific authorities for resolution (e.g., "+"). Although I would guess that identifiers should probably still be segmented in a unique namespace. Imagine the confusion if a new set of identifiers were created that had overlap an existing set of identifiers. Without the higher level segregation, it wouldn't be possible to distinguish one from the other. It seems to me that there are still unstated requirements wrt this issue. Perhaps discussing use cases or scenarios that use these identifiers would help the rest of us (maybe that's just me ;)) fully understand what is intended/needed. Mike >-----Original Message----- >From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] >Sent: Thursday, September 15, 2005 12:08 AM >To: xri@lists.oasis-open.org >Subject: [xri] Identifier Type > >Hi All, > >Drummond documented some requirements for Identifier Types on the wiki >at: >http://wiki.oasis-open.org/xri/Xri2Cd02/MetaData/I1IdentifierTy peSection >. I'd like to add a couple thoughts to that topic. > >I can't actually remember if it was in a NAC working group, or in a >collaborative working group between NAC, Open Group, and DMTF, that the >following point was made (although concensus may not have been >reached). > >To be fully qualified, and identifier must have at least 3 parts: > > 1) some expression of authority or namespace > - This could be hierarchical > - This makes it possible to attain global uniqueness > - This gives an indication of _where_ to go for resolution > > 2) some expression of type > - This gives an idication of _how_ to do resolution (some types of >identifiers may have their own inherent mechanisms for expressing >authority and non-XRI mechanisms for doing resolution - e.g., Open >Group's concept of UUID pair where one UUID represents the principal, >and the other represents the issuing authority) > - This gives an indication how equivalence checking should be done >(numeric comparison may yield different results than string comparison >or distinguishedName comparison) > - This gives and indication of characteristics that an identifier >might have that may be of value to an application that encounters the >identifier (e.g., if the identifier includes a check digit, or some >fancy crypto features, the application may benefit from recognizing the >presence of the features and exercising them) > > 3) the naked identifier > - Recognize that some types of identifiers include the notion of >authority or namespace, so the XRI notion of authority may not be >needed. > - Recognize that some types of identifiers may be generated by an >algorithm that guarantees statistical uniqueness (e.g., Host Identity >Tag) instead of being issued by an authority. The XRI notion of >authority may not be needed for uniqueness; however, it might still add >value for purposes of resolution. > >Imagine that an application encounters this identifier: "1.42.174.50". >Should the application try to ping that IP, or try to resolve it as if >it's an OID, or treat it as a serial number, or what? Earlier >some of us >discussed the feasibility of having different namespaces to >indicate the >type of identifier; however, that just didn't seem wholesome >to me -- it >seems to overload the notion of namespace. Finally Drummond suggested >that this would be better handled with metadata in the $ namespace. To >me, the $ metadata suggestion does seem wholesome. However, >you have all >been working with XRI much longer than me, and it may not seem >wholesome >to you (in which case I hope you can provide an even better idea). > >Thx, > >Marty.Schleiff@boeing.com; CISSP >Associate Technical Fellow - Cyber Identity Specialist >Computing Security Infrastructure >(425) 957-5667 > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all >your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]