[OpenID] [xri-comment] My Feedback for XRD Vrsion 1.0

[John Kemp]

Hi Eran,

On Nov 8, 2009, at 4:13 PM, Eran Hammer-Lahav wrote:

[...]

> When faced with this limitation, some people have suggested to make  
> <Subject> a string instead of a URI. While this will solve the URI  
> limitation, it will introduce an interoperability challenge. URIs  
> provide a clearly namespaces resource-identifier-space. If the  
> subject can be any string, we need to figure out what that string  
> means. This can be done using:
>
> 1. Another property such as <Subject type="uri"> or <Subject  
> type="host"> which will then require establishing a registry for  
> type values.

It can't be done by defining specific meaning for the known values  
(ie. list them in the XRD specification) and allowing extension by  
"other specifications"?

> This offers no real benefits over simply defining other elements for  
> other subject types but it does increase the document complexity for  
> the common case.

Can you explain that? I don't see that having an enumerated attribute  
here is more complex than two differently-named elements.

> 2. The context in which an XRD is found. While valid, it takes away  
> from the usefulness of XRD, by making it unable to self-describe  
> what it is about. If the method through which an XRD is obtained  
> defines its meaning (and that is likely to be the case in some  
> protocols), a self-contained XRD is unable to assert its own scope.  
> It also poses trust challenge because it is usually a bad idea to  
> sign a document which doesn't explicitly includes its purpose or  
> scope.
>
> After considering all the options, we decided to define a single  
> <Subject> element with well defined meaning and semantics. We think  
> it will be useful in most use cases, and when not, protocols are  
> free to replace it with something else, either internally or  
> externally.

As mentioned, I think that every XRD has a (logical) subject,  
regardless of whether it has a Subject (ie. the XML element).

>
> As for host-meta, it is defined as a document about a host or list  
> of hosts (as defined by RFC 3986).

Is a host, or a list of hosts not also the subject of an XRD document?  
A host, a list of hosts and a document about a host or hosts can all  
be defined as resources in the HTTP sense (or something more abstract  
if you wish).

> At this time, there is no URI available to define such an abstract  
> resource, and even if there was, host-meta needs to define multiple  
> hosts for deployment reasons (example.com redirects to  
> www.example.com). This too was discussed for a long time. We  
> considered using DNS URIs (but they identify a DNS *record* not what  
> the record means), URNs (which are not really appropriate for URIs  
> with some form of authority, or an appealing choice for many web  
> developers), a new URI scheme for host: (not likely to win community  
> support), a well-known URI prefix (such as http://host-meta.net/http://example.com 
> ), the URI of the host-meta document itself (which would present a  
> paradox), and a few other ideas. There is simply no appropriate URI  
> to describe what host-meta is about.
>
> We decided that the host-meta use case was not sufficient to change  
> the XRD spec. Instead, host-meta defines its own <Host> element.

And as mentioned, that is a fine pragmatic solution if you are not  
able to create an XRD Subject XML element that meets the needs of the  
various communities who wish to extend XRD. It doesn't change the fact  
that every XRD has a logical subject, even if the subject is called a  
Host.

Regards,

- johnk

>
> EHL
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general