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

["Wachob, Gabe" <gwachob@visa.com>]

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

	-Gabe