[no subject]

Perhaps some relatively detailed use cases would help everyone to
understand the functionality that is needed.  At the very least, it
would help me to understand the tie between specifying semantics within
XRIs and resolution of those (or parts of those) XRIs.

> - Or, if an application encounters an XRI including something like
>($t*dn), the application could know that it might have to first do some
>normalization on the DN values before doing a string comparison (or
>whatever the comparison rules are).=20
> - Or, if an application encounters an XRI including something like
>($t*otps), the application will know that the identifier is a one time
>pseudonymn so it shouldn't bother establishing a local profile for that
>identifier, because it will never be used again.=20
> - Or, if an application encounters an XRI including something like
>($t*IP), the application will know it represents an IP address that it
>might be able to ping rather than an OID.
>

These examples seem like the tip of an iceberg to me.  Who are the
participants in the use of these XRIs (e.g., who creates, manages, uses
them) and what are they used for (e.g., pure identification, resolution,
a key in a data store somewhere)?  Are the XRIs used "whole" (e.g.,
xri://@foo*($t*IP*10.0.0.1)) or "in part" (e.g., $t*IP*10.0.0.1).  If
they are resolvable (in XRI terms), what is returned in XRIDs for these
identifiers.

I realize I'm crossing the boundry from requirements and use cases into
architecture and design, but I'm hoping my questions show why the
proposal doesn't seem like an obvious solution to me.  It seems like
unstated problems are trying to be solved.  I want to make sure that we
solve issues related to identification and resolution using XRIs in an
architecturally consistent way.

>Regarding #4: I'm not sure I understand this one either. I think it
>means any issuer if identifiers could issue them with any identifier
>type. I don't think it means anyone can define a new identifier type
>under $t. Am I close?
>
>Regarding SUMMARY NOTE: If I think of it from the perspective of an XRI
>resolver, I think it would be better to express even a mailto=20
>within XRI
>with a $t. That way, software will be able to recognize it as=20
>an XRI and
>invoke their XRI processor which will know how to deal with=20
>it. I may be
>dreaming, but it seems that way down the road we could define an XRI
>type definition language that we use to describe the caracteristics of
>each identifier type. Then the XRI resolver wouldn't even have to
>understand what is meant by ($t*mailto); instead it could just lookup
>the characteristics of mailto and process it accordingly. Such XRI
>resolver applications would not need to be enhanced whenever new
>identifier types are introduced; they'd only require modification when
>the type description language changes. Am I dreaming too large?

This sounds very much like local access to me.  While local access
doesn't specify the details of different resolution types, it is the
hook we built into XRI resolution for just that purpose.  While you are
definitely not dreaming too large, I'm not sure that what you are
proposing is in scope for the 2.0 release.  As with all of the other
proposals though, I think we should discuss the requirements and use
cases.

Mike