OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]