Re: [xri] XRD trusted discovery workflow

I think a URI needs a <Service> context - it seems to me a resource map doesn't.

The current proposal on the wiki says that a resource map is inside a service element of type "e-mail to URL translation". We could make that more generic, and call it "URI to URI translation", at which point it's saying the same thing as URIMap. To me it seems that the following three examples all mean the same thing:

Ok, so just to be clear on definitions.

A URIMap is something used to map a URI to a URL (?)
A ResourceMap is sort of like a URIMap, except any old resource can be mapped into the URL (?).

Personally, I prefer to call these things "templates", since that's more descriptive, IMHO. There is (was?) a URITemplate spec (though I think it's expired) and EAUT uses the term "EAUT Template", which is basically a URITemplate (from the URITemplate spec), but restricted to only one wildcard replacement field, that being "username".

If my definitions above are accurate, I don't really see a distinction between URIMap and ResourceMap, except to say that a URIMap *is a* ResourceMap.

I agree with Brian on this one -- in order to use a URITemplate (or URIMap/ResourceMap) effectively, each <Service> needs its own URITemplate since mapping is always service-context dependent (see more below on this) -- e.g., EAUT maps one way, XRD's map another way, etc.

[ my proposal: ]
<XRD>
<URIMap>http://target.com/uri={URI}</URIMap>
</XRD>

I like the spirit of what you're trying to do -- it essentially creates a generic mapping scheme for any kind of URI (e.g., the URI 'mailto:beth@example.com' would be mapped to "http://target.com/uri=mailto:beth@example.com", and the uri "urn:isan:0000-0000-9E59-0000-O-0000-0000-2" would map to "http://target.com/uri=urn:isan:0000-0000-9E59-0000-O-0000-0000-2".

If something like this were to be implemented, I would suggest to still put it into a <Service> tag, and furthermore, to create its own specification outside of XRD (something like Generic URI Dereference Spec). Why? Because websites may not always want to dereference a URI into a URL using the method you're proposing. They may prefer to use EAUT or some other protocol instead. By providing differing <Services> in XRD, with different ways to dereference a particular URI, I think we'll provide the most flexibility to the whole Internet. Also, keep in mind that a single derefernecing method for all URI's might "step on the toes", as it were, of existing URI dereferencing schemes. For example, given a URI "ftp://fileserver.net", should this be dereferenced as "ftp://fileserver.net", or should it be referenced as "http://fileserver.net/uri=ftp.fileserver.net" (assuming an XRD exists as 'fileserver.net')? Again, one more reason a "Generic URI to URL" methodology should belong in its own specification.

Just to be clear, I think you're idea is an interesting one -- but it's perhaps too ambitious for this spec. I think we should stick to URL bootstrapping for discovery, and leave the method of changing from a URI to a URL up to external specifications (Though I'm completely willing to hear arguments against this line of thinking).

[ what's currently on the wiki (well, almost): ]

<XRD>
  <Service>
  <Type>http://specs.xri.org/uri-to-uri-translation</Type>
  <URIMap>http://target.com/uri={URI}</URIMap>

  </Service>
</XRD>

[ what's in EAUT (well, almost; see below): ]
<XRD>
  <Service>
  <Type>http://specs.xri.org/uri-to-uri-translation</Type>

  <URI>http://target.com/uri={URI}</URI>
  </Service>
</XRD>

This isn't fully accurate. EAUT allows two different service types. A more valid EAUT example(s) would be as follows:

[URI Template to map all emails in this domain]
<Service xmlns="xri://$xrd*($v*2.0)">

  <Type>http://specs.eaut.org/1.0/template</Type>
  <URI>https://%7Busername%7D.example.com/</URI>
</Service>


[Mapping Service to allow per-user mapping of email addresses]
<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.eaut.org/1.0/mapping</Type>

  <URI>https://example.com/eaut_mapping/</URI>
</Service>

If you agree that these all mean the same thing, then the first one seems the easiest.

With EAUT, there are actually two <xrd:Type> possibilities inside of the <Service> element. First is a "template" type, which with a corresponding URITemplate URI can be used to transform the email address to a URL directly. The other <xrd:Type> is a "mapping" type, which allows the domain controller to delegate to a mapping service, thereby allowing individual users to specify (via that mapping service) which URL their email address should map to.

Yeah I'm not quite sure how these two types map onto what's shaping up on the wiki. Maybe one way to look at it is that we're here trying to figure out how to discover meta-data for an arbitrary URI (including mailto: URIs), while EAUT tries to transform a mailto: URI into an http: URI. What we're doing here (and what the three examples above all do) is closer to performing an EAUT transform (either by template _or_ mapping), and then finding out where the meta-data for the resulting HTTP URI is, but in one step.

Now I don't know whether equivalence with EAUT is something to strive for here...

If we are going to address email addresses in the Discovery Bootstrapping, then I think we should consider EAUT (or something like it) over trying to define what should happen with a simple mailto:schemed URI. Web-servers don't "do" anything with a mailto: schemed URI. Some other mechanism is necessary to translate these URI's/email addresses into URL's, and that something probably needs to be more than just taking the "domain.tld" from an email address and trying to do discovery on that URL.

With all that said, however, are we really going to define URL mappings for every URI scheme in the XRD spec? I doubt it. Just thinking out loud, but should we consider calling email addresses out of scope here? Why not let other specs figure out how to turn various URI schemes into URL's (like mailto:), and concentrate on the "URL Discovery Bootstrapping" part.

I would like us to come up with something that works with arbitrary URI schemes, because I would like to get the email use case to work. I don't think we necessarily need to call out every possible URI scheme in the spec. Something like URIMap would work fine, and isn't restricted to mailto: URIs, the mention of mailto: on the wiki is just an illustrative example.

Not sure if this last part (coming up with something that works with arbitrary URI schemes) is ideal -- see my comments above for some rationale, not to mention that it would drastically increase the complexity of XRD, while at the same time making it fairly restrictive.

xri message