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

["Chasen, Les" <les.chasen@neustar.biz>]

> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Thursday, September 22, 2005 4:38 PM
> To: Schleiff, Marty; Drummond Reed; xri@lists.oasis-open.org
> Subject: RE: [xri] Update to Metadata Issue #1: Add $t Tag for
Identifier
> Metadata
> 
> 
> > 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
> > within XRI
> > with a $t. That way, software will be able to recognize it as
> > an XRI and
> > invoke their XRI processor which will know how to deal with
> > it.
> 
> Well, in any case, even if it were a mailto: URI, it would be a
> *cross-reference* to a mailto: URI, and an XRI processor could
> definitely have rules that are specific to each URI type appearing in
a
> cross reference. That is, just because there is a well-defined
operation
> for using mailto: URIs (ie SMTP), this doesn't mean that an XRI
> processor can't be instructed to do something else with a mailto: URI
> *when it appears in a cross-reference*.
> 
> You can *always* do xri://(mailto:gwachob@wachob.com) or
> xri://@sfgiants*fans*(mailto:gwachob@wachob.com)
> 
> In either case, the mailto URI can be treated as an XRI subsegment or
a
> mailto: URI - there's no real need to make it
> $t*mailto*gwachob@wachob.com (which would be illegal I think, given
the
> @ in the middle of a subsegment that isn't a cross-reference).


[Chasen, Les] 
Just one comment, It probably should not be the resovler (XRI Resolution
client) that is determining what to do with a URI.  It just knows how to
lookup and find the XRID.  It is some other service that determines how
to process a URI.  

NOTE:  I am not making any judgment on whether this should be a tag or
not ... just pointing out where I think functional applications/services
belong.

> 
> > 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?
> 
> You may be dreaming, but I don't see why such a mechanism couldn't
also
> apply to xrefs containing particular URI types (ie a rule each for
> mailto xrefs, http xrefs, etc)
[Chasen, Les] 
Same comment as above.  The resolver should not be doing anything here.
It is the specific service application that knows what to do with any
specific piece of meta data.  For example, it is an xri aware email
engine that is taking the mailto tag and determining what to do.  The
email engine makes a resolution request via a resolver to look up the
needed data.
> 
> 	-Gabe
> 
> 
> 
> ---------------------------------------------------------------------
> 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