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

[Eran Hammer-Lahav <eran@hueniverse.com>]

> -----Original Message-----
> From: John Kemp [mailto:john@jkemp.net]
> Sent: Monday, November 09, 2009 4:43 AM
> To: Eran Hammer-Lahav
> Cc: Santosh Rajan; xri-comment@lists.oasis-open.org; general@openid.net
> Subject: Re: [OpenID] [xri-comment] My Feedback for XRD Vrsion 1.0
> 
> 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"?

Unless the 'type' attribute value is a URI, no. Any short-name-based solution should come with a registry to avoid name collision. But the whole design is just unattractive. 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). It also reduces confusion when two identical subject are used to mean completely different things solely based on their type attribute.

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

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

Someone has to manage this enum. Another lesson learned from host-meta (which is the only use case we found for non-URI subjects), is that since XRD was designed with URI-identified resources in mind (and a single one at that), changing the subject of an XRD to be anything else will likely require making other adjustments to the meaning and processing rules of the XRD. For example, the context URI/resource of links, the meaning or applicability of the <Alias> element, the meaning of templates, etc.

I thing putting a small hurdle on the path to extending XRD to describe things other than a resource identified by a URI is a good thing. It will force protocol developers to think about the problem, to try and find an appropriate URI for their subject, consider how it will impact existing trust profiles based on the <Subject> element (which are going to depend on its URI structure and meaning), and figure out what the rest of the document means (semantically) in such cases. It will also force them to consider whether breaking compatibility with the Web Linking framework is acceptable (being unable to link from HTML or ATOM to the subject of the XRD because it is not URI-reference-able). This is exactly the thinking process that led us to come up with the acct URI.

> > 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 simple as I personally find this set of specifications, it is already non-trivial for many people. By providing a well-defined, in-document, and restrictive <Subject> element, XRD makes it less likely for bad things to happen. Since trust is a big reason for having a <Subject> in an XRD, I would strongly oppose a protocol that overrides or gives additional meaning to the subject of an XRD (outside its declared <Subject>) based on the context in which it was obtained. It is one thing to differentiate the trust level of an XRD based on how it was obtained, but a whole other thing to make it be *about* something else.

The <Subject> element design does not preclude *any* of the approaches proposed. It simply provides a limited but extremely useful tool for what we determined to be the most compelling and likely use case.

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

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.

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

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.

EHL