RE: [xri] Update to Metadata Issue #1: Add $t Tag for Identifier Metadata

["Schleiff, Marty" <marty.schleiff@boeing.com>]

I want to say that I appreciate Drummond speaking up for me. I'm still
working on coming up to speed and have a long way to go before I can say
things like he does (if ever).

I do have a tweak to Drummond's & Dave's common language - common schema
analogy. I do think of XRI as the common language, but I think a common
schema would be more along the lines of the NAC XRI Usage Profile we're
working on in a NAC working group. It's true that XRI is very feature
rich, most of the things I've described that NAC wants to do can already
be expressed with existing XRI capabilities. E.g., the idea of local
scope can be done with "xri://<authority>/<local scope identifier>" and
mailto can be done with the existing mailto URI scheme. However, some of
the reasons NAC wants to define a usage profile is to introduce a
consistent approach to do lots of things, and to invest some cogent
thought up front so other companies don't have to spend months just
trying to figure out how they should represent their internal
identifiers within XRI. $t would allow a consistent approach to do
various things that would otherwise be done with multiple different
approaches. 

This really hit home to me during some of our NAC calls where we're just
trying to figure out what the NAC recommendation should look like -
there are so many options, that it's hard to figure out your favorite
approach. I'm including some examples from NAC conversations; I'm not
asking for your input; rather just showing how involved the discussions
get. Note that as we've been having the discussions we've been trying to
capture the consideration factors that make us prefer one variant over
another. Right now variant 5 seems to be the NAC's leading candidate.

1.	xri://[<authority>/]($<type>/<identifier>)
1a.	This variant has fallen out of favor. Rather than define
identifier types directly in the metadata spec, we prefer to define a
new kind of metadata (to be represented by a new $t metadata tag) under
which the individual identifier types will be defined.
2.	xri://[<authority>/]($t/<type>/<identifier>)
2a.	This variant is not preferred because although it it
syntactically valid XRI, the cross reference within the parenthesis
(itself a valid XRI) may not be globally unique - two companies might
use the same <identifier> value within the "Local Scope" type to
represent different subjects.
3.	xri://[<authority>/]($t/<type>)/<identifier>
3a.	The cross reference within the parenthesis is globally unique.
3b.	If there is no <authority> required for uniqueness and
resolution, the ($t/<type>) immediately follows the two slashes and
becomes the <authority>. This has implications for resolution.
3c.	E.g., xri://($t/hip)/tfdee2978d9278deg
3d.	Moving the cross reference into the <authority> section would
allow the slash(es) after the cross reference to be replaces by * or !,
e.g., "xri://($t/hip)* tfdee2978d9278deg". This would allow the rest of
the identifier to be significant for XRI resolution. Our initial
reaction is that although syntactically valid, it would not be practical
for a global authority like ($t/hip) to be able to produce an XRID
recognizing every locally assigned identifier.
3e.	Downcast into a URI: xri://($t%2Fhip)/tfdee2978d9278deg   
4.	xri://[<authority>]/($t/<type>)/<identifier>
4a.	The cross reference within the parenthesis is globally unique.
4b.	If there is no <authority> required for uniqueness and
resolution, the ($t/<type>) follows three slashes, there is no
<authority>, and ($t/<type>) is not relevant to XRI resolution (it's in
the path instead of authority segment).
4c.	E.g., xri:///($t/hip)/tfdee2978d9278deg
4d.	Dave points out that this is not valid XRI authority; however it
is still a valid XRI.
4e.	Drummond thinks there are advantages to having the authority
explicit instead of absent. So he does not prefer this one.
5.	xri://[<authority>/]($t*<type>)/<identifier>
5a.	Dave points out that it is syntactically valid to use splat
instead of slash after the $t. 
5b.	Looking at the XDI model, slash represents a drop down below the
black line and splat represents a delegation on the same level.
5c.	Thesis: looking way ahead to when a resolver needs to look at
the type descriptor language, it might be easier for the resolver to
deal with a delegation at the same level.
5d.	Downcast into a URI is the same as XRI:
xri://($t*hip)/tfdee2978d9278deg

How does ($t*<type>) differ from ($t/<type>) in regard to the
declaration of new types? Does a slash provide more control because the
type is "under" the control of $t? With each approach, how would $t make
sure only valid/sanctioned/documented types are supported? How would an
application recognize the "validity" of a type value? Or, is it more
advisable to let anyone define a type without any control exerted by $t?




Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(425) 957-5667

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Thursday, September 22, 2005 5:13 PM
To: 'Wachob, Gabe'; xri@lists.oasis-open.org
Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for
Identifier Metadata

Gabe, answers marked ### inline below. I tried to work in Marty's
questions/observations as well. See especially the end, where I tried to
respond to your Summary Note as well as to Marty's comments.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Thursday, September 22, 2005 12:09 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for
Identifier Metadata

Drummond-

I have feedback/questions about these requirements (lines starting with
>>>):


1) To have a uniform, interoperable representation in XRI of different
types of identifiers which do not have URI schemes yet are commonly used
in enterprise systems. 

>>> Great requirement. Stated exactly as I would have. See my note after
the >>> feedback.

2) For this uniform representation to facilitate matching in enterprise
directory systems and other applications that need XRI equivalence
checking (see  Syntax Issue #1: Directory Attribute Appendix). 

>>> Fine. Makes sense.

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. 

>>> I think that the specific use cases need to be listed, or at least
criteria for determining if a use case is in or out of scope for this
change proposal. I don't really understand what "take advantage of this
metadata" is. 

### Was Marty's message sufficient for this? ###

4) For this uniform representation to be able to be independent of any
specific authority that may assign identifiers of this type. 

>>> But aren't we saying that these representations are ultimately
rooted in $t, which is defined by the metadata spec, which is *us*? Its
really that the identifier doesn't need to resolve (outside a cross
reference) to any authority, right? We are talking about identifiers for
which there is no central registration (and no uniform resolution
mechanism) (at least not one that is done through XRI). Isn't that the
real requirement here? 

### Yes. I may not have worded this well. What I meant was not that the
*type* declaration was independent of any authority (as you say, it
would be dependent on us, or the delegated authority for the $t spec),
and therefore could be used by all authorities that 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. 

>>> Is it really about xrefs? Isn't the real requirement that the
identifier be usable in a subsegment - and that using xref is just a
choice of how to address the requirement? 

### Yes. Again, it was just my choice of words (I'm waaaay too close to
XRI syntax, obviously.) ###

6) For this uniform representation to be able to be expressed in any
other context which may accept an XRI cross-reference. 

>>> Same as #5.. Is this a real requirement?

### Agreed -- it could be rolled in #5. ###

7) If identifier type metadata is best managed in a separate namespace,
for management of this namespace to be handled independently of the
Metadata specification and provide mechanisms for third party
registrations. 

>>> Really, this just saying that the list of types is managed
independently of the metadata specification, right? 

### Right, although I was trying to capture the suggestion in several
threads that the delegated spec could specify other mechanisms for
registration of $t identifiers. ###

SUMMARY NOTE:

In general, I still think that we haven't described the use case for
this proposal very well. I think the use case is best though of as being
"having a way to use external identifier schemes where those external
identifier schemes don't have a URI scheme defined" - because if they
*do* have a URI scheme defined, (e.g. mailto), we *shouldn't* be using
$t... The line of thinking (tell me if I'm wrong) is "well, we need more
identifier schemes that work with XRI, but since other folks haven't
gone through the process of formally defining a URI scheme for these
other identifiers, we'll come along and present an alternate
XRI-specific mechanism for embedding those identifiers in an XRI"... 

Right?

### While I fully understand this interpretation, there's more too it
than that. What the work that Dave and I have been doing with Marty and
Boeing and NAC has revealed to me is that URI syntax is not nearly as
rich as XRI syntax in being able to provide a description of an
identifier. With URI syntax, as best I know, you have only one option: a
scheme name (and the accompanying scheme spec). XRI syntax provides a
way to "reuse" this by encapsulating a URI that uses this scheme name so
that you can use it as a cross-reference in an XRI.

With XRI syntax, however, you can create a "native XRI identifier" for
an identifier type. This native XRI identifier has some advantages.
First, it's extensible in ways that a URI scheme isn't. For example, if
we were to define "$t*oid" for OIDs, an organization Foo that only
allows OIDs of a certain type could extend this to become
"$t*oid*(@foo)". The meaning that the identifier being described was an
OID would not be lost, but be constrained the way @foo desired (in their
own context.)

The second advantage is the one Marty's been raising. To my knowledge,
URI scheme names are not resolvable (not by any protocol I know of.) XRI
GCS characters, by contrast, can be resolvable. Marty's particularly
interested in the potential for a resolvable $t dictionary because it
could provide a long-term solution to the problem of identifier
interoperability among directory vendors. Rather than having to add
support for specific hard-coded identifier types, they could move
towards supporting a $t dictionary.
(Again, the scope of that work does NOT fall in Metadata 2.0 and may not
even be in the scope of a $t spec. That's future stuff.) 

I only bring it up because I'm slowly becoming convinced that XRI does
not just provide backwards compatability with existing identifiers
expressed in URI schemes, but a richer way to describe/use any type of
identifier at the XRI level. This includes new types of identifiers that
may have special privacy, security, or crypto characteristics. That's
why a $t spec is making more and more sense to me.

Another way to put the "big picture" use case for $t is this. If: a)
company's like Boeing and consortia like NAC want to be able to adopt
XRI as a standard "identifier representation language" that helps them
solve the problem of identifier interoperability within and between
enterprises, and
b) if one of the requirements of such a language is that they be able to
express a standard dictionary of identifier types, then they need to be
able to express all identifiers they need to deal with consistently in
that dictionary format.

So from the standpoint of that use case, it might not matter if there is
an existing URI scheme for an identifier type. That's not the "language"
they need to standardize on. They need a common way to express (and
combine, and
compare) all these identifier types, and for that they need to express
them all in a common way.

The analogy that DaveM has used several times is that if this were XML
and it was a data interoperability problem, what would be needed is
agreement not just to use XML, but a common set of schemas. Instead what
we have here is an identifier interoperabilty problem, the common
"language" is XRI, and the common "schema" (dictionary) needed for
interoperability of a number of existing (and future) identifier types
is the $t spec.

I hope that perspective helps.

=Drummond 


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