Re: [xri] XRD trusted discovery workflow

[Breno de Medeiros <breno@google.com>]

On Thu, Dec 11, 2008 at 10:33 AM, David Fuelling
<david.fuelling@cordance.net> wrote:
> On Thu, Dec 11, 2008 at 8:05 AM, Dirk Balfanz <balfanz@google.com> wrote:
>>
>> 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).

If the <Service> tag is included, and the document specifies how to
change URI to URL when performing XRD discovery, that should work and
I can see the benefits for the larger picture. Leaving unspecified how
to use URI/ResourceMaps to resolve XRDs, or deferring to a (possible)
future spec is not acceptable because it does not provide a complete
picture of XRD resolution. I understand you mean the former.

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



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)