OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] URIMap element (was: XRD trusted discovery workflow)





On 12/15/08 3:38 PM, "Dirk Balfanz" <balfanz@google.com> wrote:

>
>
> On Mon, Dec 15, 2008 at 3:18 PM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>>
>> On 12/15/08 3:08 PM, "Dirk Balfanz" <balfanz@google.com> wrote:
>>
>>> Ok, I think we're in violent agreement over this, then.
>>
>> Which I do not understand what it is.
>
> That site-meta is for the site, which is different from the root resource, how
> OpenID discovery for directed vs. claimed id should work, etc.

OpenID has a history of using technologies outside the mainstream of their
semantic meanings... The way it uses the Accept header is one example. It is
designed to work under most circumstances and that design objective
constantly compromises its architecture purity. This is not criticism, but a
statement of fact. I am not saying this is necessarily bad.

How OpenID will use /site-meta and XRD is a separate discussion, and while I
understand it is the most important use case for you, it is not the most
important use case for me. I am designing a generic discovery protocol.
OpenID and XRI will then go and use it as they see fit. All I can offer you
are the architectural guidelines and semantic meanings *I* had when
designing it.

The benefit of my approach is that once you understand it, it becomes very
clear on how applications should use this framework. The confusion around
which document should delegate and map what goes away once you follow these
guidelines.

/site-meta has two meanings, one syntactically and one semantically. The
syntactic one means it is a registry of links to other documents relevant
(or of some relationship) to the site, where "site" means the domain name
(whatever that means to you). It is a hack around the problem of
known-locations, giving you one known-location to list all your other such
documents. So syntactically it is a list of links.

Semantically, /site-meta describes links between the "site", an abstract
concept, to other resources. /site-meta has no relation to the HTTP root
resource at that domain (i.e. http://domain/). It is not a replacement or an
extension of the HTTP header provided by a GET / request on the domain. It
is about a "site".

Now, even the proposal authors (Mark and I) do not fully agree on the
meaning of "site" as an abstract concept. Mark tend to think it means "web
site" as in the service offering resources over the HTTP protocol (which
implies /site-meta has no place or authority to describe mapping for mailto
URIs). I define "site" as anything linked to the domain authority (a
/domain-meta if you will), which is served over HTTP but is not limited to
http URIs.

Either way, the /site-meta spec is not likely to directly resolve this
difference of opinions. Link headers on the root resource have a very clear
semantic meaning in HTTP (the root resource has no special meaning in HTTP
to imply some authority over the entire domain) to be resource specific (and
the new Link spec makes that pretty clear). The same cannot be said about
/site-meta which leads me to believe an identical interpretation is
incorrect as it will create a duplication.

>>> The questions, though, remain (independent of applications such as OpenID):
>>>
>>> (1) Is there going to be a resource map/Link-Template equivalent in XRD?
>>
>> Yes. <Link> elements will be allowed to include <URI> elements and
>> <TemplateURI> elements. So a <TemplateURI> could be used as a resource map,
>> but that meaning is very much application specific. There is no such thing
>> as a generic URI map. The map must always have a very clear semantic
>> meaning. In /site-meta, when used with rel="describedby", it offers a way to
>> go from the R-URI to the D-URI. Any other rel and the meaning is undefined.
>
> So this would be ok:
>
> <Link>
>   <Rel>http://openid.net/signon</Rel>
>   <TemplateURI>http://example.com/openid?user={URI}</TemplateURI>
> </Link>
>
> I assume this is ok, too (trying to understand what "there is no such thing as
> a generic URI map" means):
>
> <Link>
>   <Rel>describedby</Rel>
>   <TemplateURI>http://example.com/xrd?uri={URI}</TemplateURI>
> </Link>

As presented above, there isn't enough information to say if they are valid
and what they mean.

An XRD describes a resource. If the above fragments are from an XRD about
the "site" (that is, a link from /site-meta with rel="describedby"), then
they have the same semantic and syntactic meanings as if there were present
in the /site-meta document itself.

Simply put, they provide links between the "site" and some other resources
(constructed using a template), with a typed relationship.

BUT, if these fragments are present in an XRD for a resource identified with
a URI, such as http://example.com/resource/1, they are undefined. The first
is undefined, because there is no clear meaning to 'uri' in the template.
What is missing is a clear definition of the relationship type
http://openid.net/signon and what is its semantic meaning in relation to the
resource described by this document.

In the same context, the second seems to suggest that there are other
descriptors available for *this resource* (described by the XRD), but again,
it does not define the meaning of 'uri' in the template. The use of
'describedby' in a document which by itself has a 'describedby' reverse link
to the resource is confusing at best.

> It would be nice to have the latter, too, even though it's something that can
> be expressed easily in /site-meta. The reason it would be nice to have is that
> in a XRD, it can be signed.


Either way, I assume you meant to use these examples in an XRD describing a
"site", in which case they mean the same as the equivalent values in
/site-meta. Ideally, both XRD and /site-meta will support signatures.

EHL



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]