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

[John Kemp]

Hi Eran,

On Nov 9, 2009, at 12:02 PM, Eran Hammer-Lahav wrote:

[...]

>
>
>> ---
>> 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"?
>
> Unless the 'type' attribute value is a URI, no. Any short-name-based  
> solution should come with a registry to avoid name collision.

My point is that the registry is simply in the specification. Either  
new short names appear in future versions, or they are URIs whose  
meaning is determined by the URI owner. I've read that same idea  
somewhere before (link header framework maybe?) but it was also used  
in SAML (authentication method/context for example). Registries have a  
long and honorable... well, checkered, history ;)

> But the whole design is just unattractive.

I could say the same thing about a design that requires two  
differently-named elements specified by two different groups, but I  
don't think that would be helpful.

> There is really no difference at all between a client encountering  
> an unknown attribute value and an unknown element. But the advantage  
> of the second approach is that it prevents the client from making  
> bad assumptions about the value of the subject (given an unknown  
> type).

The client definitely needs to know what to do when it encounters a  
subject. And to know when it cannot do anything about the appearance  
of a particular subject.

> It also reduces confusion when two identical subject are used to  
> mean completely different things solely based on their type attribute.

A single host, a list of hosts, and the XRI subject are all considered  
the subject of the XRD. I believe that the subject of the XRD is the  
entity about which the XRD contains related resource information. In  
other words, "subject" has semantics in XRD.

>
> After over a year of debate, the XRI TC has failed to come up with a  
> single use case for non-URI subjects other than host-meta.

Yes, but the point I am making is that an XRD has a subject,  
logically. And it is simply the representation of the Subject XML  
element that prevents someone using a non-URI-identified subject.  
Personally, I think it is fine that a subject might be represented by  
something other than a URI, but I can see the other side of the  
argument too. Pragmatically-speaking, it is hard to decide how to make  
URIs to point to things that don't fit nicely in the HTTP model.

> I would gladly open this discussion again, but not without  
> compelling use cases. Extensibility (beyond what is currently  
> supported) that is not anchored in practical needs is a poor design  
> choice. It is the schema version of astronaut architecture...

Sure if you say so. And I can't tell you of exciting new use-cases  
that need that. Your solution is pragmatic for the needs of host-meta.

But it is certainly the case that I think it would be bad design to  
simply let Subject be optional and then have someone else come along  
and put a new element in the schema simply because their Subject is  
called Host (or Slartibartfast, or whatever), but still has the  
semantics that it is the "subject of the resource links contained in  
the XRD".

I don't think that it is "astronaut architecture" to suggest that if  
you logically always have a subject of an XRD document that the  
Subject XML element should always appear. It just seems like common  
sense.

[...]

>>> 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).
>
> But this subject behaves fundamentally differently from a URI- 
> identified resource. Links are applied differently. For example,  
> host-meta defines the semantic meaning of a <Link> with <URI> to be  
> about the host (the entity controlling the namespace), and <Link>  
> with <URITemplate> to be about individual resources within the  
> namespace. XRD does not provide such a distinction because it  
> defaults to describing a single resource identified by a URI.

A "single resource" can be about anything. A "single resource" could  
be "a group of hosts". A URI _identifies_ a resource. It may or may  
not also produce a representation of that resource. The resource is  
singular but may describe a plurality.

>
> Host-meta does some (smart, I hope) things to make XRD work for its  
> needs. For example, it allows multiple <hm:Host> elements which  
> would not work if we found a magical way to use <Subject>. Host-meta  
> needs to support multiple hosts in a single document due to (very)  
> common deployment restrictions. If we make <Subject> more generic  
> for non-URI subjects, we will need to also allow multiple <Subject>  
> elements. At this point you will have a poorly defined element with  
> no real interoperability value. It will become (literally), an empty  
> shell.

I think you would need to decide whether the XRD was linked to a  
subject and the subject could be a group. Or that an XRD is about a  
group of subjects, where the group has at least one element. Do you  
see the distinction?

>
>>> 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.
>
> Please name those communities and provide details about their use  
> cases.

I can't, and I don't claim to represent any community in this  
discussion.

I could note, however, that were someone to write a (imaginary)  
"generic" XRD processor, they certainly might hope that they could  
check for the subject of the XRD in only one XML element and not two  
(or more).

But basically, you'll have to decide whether you believe my argument  
that an XRD ALWAYS has a subject, even if the subject is called  
"host", based on the merits of the argument alone. You'd then need to  
decide whether it is worth some extra work to correctly represent the  
semantics of XRD in the schema and specification.

>
> The XRI TC has spent the last year throwing furniture off the deck,  
> with the determination to keep XRD as simple as possible while  
> focusing on real use cases. We are happy to reconsider every aspect  
> of our design, but *only* if it is based on actual use cases, not  
> some theoretical what-if scenarios. I don't want to point finger at  
> other specs who failed to follow this rule and ended up with a  
> bloated spec no one really uses.

I don't have any what-if scenarios for you.

I believe that an XRD always has a subject. So far, I have seen no  
argument to the contrary, and the use-cases discussed all seem to have  
a subject, even when it is called host.

I do see a pragmatic issue about how the subject of an XRD is  
represented in the XRD document itself.

I agree that this issue is tough to solve, but I think providing  
common subject-related semantics at the XRD level with a measure of  
extensibility in the right direction is simply good design.

I don't have any particular investment in XRD at all, so you are  
certainly free to evaluate (hopefully without further unwarranted  
ridicule) my arguments and decide not to pursue any changes.

- johnk