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

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

This is all pretty accurate except for the characterization of "two camps".

<Nothing New From Here On>

Both designs, XRD and host-meta, come from a largely overlapping group of people. Host-meta was originally proposed as a text-based document. At some point it became clear that there was value in reusing the XRD schema and so we started looking at how it would be applied to this particular edge case. We were able to solve the questions of link subjects for URI and URITemplate, but then got to the issue of Subject.

For the past year (I am not exaggerating), this topic was continuously discussed on the XRI list and weekly calls. I have raised the question to the IETF Apps area with little success, the W3C Tag with similar results, and other communities such as WebFinger (which is heavily depended on host-meta). We came to the following conclusions:

1. There is no existing URI scheme suitable to describe a 'host' (dns, tag, etc.).
2. A significant number of people rejected the Semantic Web ideas of well-known HTTP URI prefix or using a #fragment to denote a special meaning.
3. A significant number of people rejected the idea of using a URN for both style reasons and because URNs should not include an authority.

The conclusion was that there was no URI available *winning rough consensus*.

Back to XRD, we looked at how we could express a non-URI subject. Note that at the time, host-meta was defined as single scheme/authority scope. This has changed since to encompass an entire host (as in the entity controlling the host namespace per 3986). We tried:

<Subject match="prefix">http://example.com</Subject>

<SubjectSet>
        <Authority>example.com:80</Authority>
        <Scheme>http https</Scheme>
</SubjectSet>

<Subject type="host>example.com</Subject>

<hm:Subject>example.com</hm:Subject>

<Subject hm:type="host-meta">example.com</Subject>

We looked at POWDER which has a 30+ page specification of how to address similar use cases (http://www.w3.org/TR/powder-grouping/). We considered URI templates in subjects. I even proposed using an invalid URI scheme since a strict reading of the anyURI schema rule doesn't require a *registered* scheme, only proper format:

<Subject>host:example.com</Subject>

The 'match' attribute got the most traction of the bunch, but then started to "leak" into other area of the schema. We came to the conclusion that Alias will also have to support the same mechanism because it should be able to express the same set of identifiers expressed by Subject. Then when it came to trust profiles, we used to have a Subject element as a child of Link (to express the expected subject of the linked XRD, a concept that was since removed from the spec due to lack of use cases). That meant it too would have to be changed.

We found ourselves changing a lot more than just making Subject a bit more inclusive, and all that for a single use case which had a simpler (and in my view cleaner) solution: extend the schema to define a new host-meta subject.

This decision was further justified when host-meta was changed to accommodate a list of hosts. To make Subject work for that, we need an even more expanded format (space delimited values, child elements, or changes to the element cardinality).

XRD and its predecessors, XRDS and XRDS-Simple were always about a "resource identified by a URI". This definition has not changed in 5 years. While the simplicity of the new XRD format, and its alignment with web linking makes it more appealing and generally useful, it is important to remember what it is designed for.

We have gone through a thorough discussion and came to the conclusion that we simply don't have consensus to change the current (and historical via <CanonicalID>) definition of the <Subject> element. No one is fully satisfied with this status quo, but nevertheless, it *is* something we all agree on and find useful for every single use case but one (host-meta).

At this point, the only reason to open this discussion are new ideas, not new opinions. I certainly appreciate the view some take that this is more than a bikeshedding discussion about the *syntax*. However, this debate has to end for us to move forward and I have heard nothing new to suggest we are more likely to resolve it now than we were the past year.

All I have left to offer is for us to move forward with the solution as currently presented. As we gain more implementation experience across a wider set of protocols and communities, we can come back and revisit.

EHL

Side note: To be honest, the only reason why I was willing to spend more time on this (again) is my respect to John Kemp who has articulated some good ideas about the topic. They were not new to the XRI TC but new in the wider context and deserved to be addressed. Wearing my XRD editor and architect hat, I consider this matter closed.


> -----Original Message-----
> From: openid-general-bounces@lists.openid.net [mailto:openid-general-
> bounces@lists.openid.net] On Behalf Of John Kemp
> Sent: Tuesday, November 10, 2009 7:18 AM
> To: Santosh Rajan
> Cc: general General; xri-comment@lists.oasis-open.org
> Subject: Re: [OpenID] [xri-comment] My Feedback for XRD Vrsion 1.0
>
> On Nov 10, 2009, at 9:25 AM, Santosh Rajan wrote:
>
> > Hi John,
> > Well in this thread, I was getting to exactly what you were talking
> > about. The "optionality of the Subject XML".
> >
> > I have already said that Resource's are "aggregation's of Resources".
> >
> > Now it so happen's that the argument for "optional Subject" is based
> > on the "supposed fact" that the host-meta cannot have a Subject.
>
> Sorry, but I understood that even Eran agrees that host-meta XRDs have
> a subject - it's called "host". Of course, I don't wish to put words
> in his mouth, so I hope he'll correct me if he thinks otherwise.
>
> >
> > What I have proven here is that the
> > "host-meta is an aggregation of all the resources available on the
> > same domain (ie Resources that happen to have the same domain as the
> > host-meta in their URI's). So the host-meta is no different from any
> > other XRD which has a <Subject>.
> >
> > So the host-meta MUST have a <Subject> element like any other XRD.
>
> I agree with you on that.
>
> >
> > So there are no more use cases of XRD's that do not require a
> > <Subject> element.
>
> Again, I agree that as far as I can tell there are no use-cases of XRD
> where the document shouldn't list the subject of the XRD.
>
> >
> > And hence the <Subject> of an XRD cannot be optional any more.
> > Either it has to be mandatory or at least "RECOMMENDED".
> >
> > Now if the Subject is "RECOMMENDED" instead of "MUST" (which is what
> > I want), you still need to provide a "Valid" reason why the Subject
> > cannot be there.
>
> The argument that I have been making is that there is a pragmatic
> reason for making the Subject XML element optional. The argument is
> that
>
> i) the XRI folks want the Subject XML element to allow only URI
> identifiers.
> ii) The host-meta folks would prefer NOT to get into defining a new
> URI scheme or using HTTP URIs in some way to point to "hosts".
>
> I understand that there are good arguments from both sides as to why
> they don't want to budge on this issue, even though I personally see
> that it is likely that all XRDs have a logical subject even if that
> subject is called host (or something else).
>
> > The arguments given by Eran are NOT "valid enough". In fact, at
> > best, he has given some technical mumbo jumbo to support his case,
> > which could hardly be construed as "valid enough" for a
> > "RECOMMENDATION".
>
> Well I'm sorry to disagree here, but I think the arguments on either
> side for doing what they want to do are pretty reasonable. There is a
> pragmatic compromise in order to make both sets of use-cases
> reasonably easy to satisfy.
>
> There are (at least) two potential solutions to making Subject
> required:
>
> i) Even host-like things *could* be identified by URIs (HTTP or
> otherwise) even if doing so is not well-understood or particularly
> easy.
> ii) Subject could allow things other than URIs in the base case, and
> restrict to anyURI in a profile.
>
> As far as I understand it, neither side is currently willing to
> compromise. That doesn't invalidate anyone's arguments however.
>
> I think it would help if we remembered that there are real people
> trying to do interesting and difficult work here - being polite and
> not ridiculing each others' arguments seems like a good first step.
>
> - johnk
>
> >
> > On Tue, Nov 10, 2009 at 7:24 PM, John Kemp <john@jkemp.net> wrote:
> > Hi Santosh,
> >
> >
> > On Nov 9, 2009, at 10:53 PM, Santosh Rajan wrote:
> >
> > I think the whole problem is with the definition of the XRD, as I
> > have suggested in the original post.
> >
> > Well, that might be a problem, but it is not what I have been asking
> > about in this thread. As far as I'm aware, I'm specifically talking
> > about the optionality of the Subject XML element and ways of
> > representing the subject of an XRD document, and I'd prefer that in
> > that thread, we restrict discussion to that topic, just to keep the
> > discussion threads understandable.
> >
> > Cheers,
> >
> > - johnk
> >
> >
> > We need to see the XRD not not as "describing a resource", but as an
> > "aggregator of a set of resources". I will rewrite the definition of
> > an XRD.
> >
> > "An XRD aggregates a set of related resources into a given Resource".
> >
> > Note that we are talking of two types of Resource's here.
> > 1) The "given Resource", the one the XRD is describing.
> > 2) The Resource's pointed to by the Link elements. These are
> > Resources which make up the "given Resource".
> >
> > The important point to note here is that this is an aggregation of
> > "Resource's" NOT aggregation of "Links".
> >
> > Now if we agree that the host-meta is an aggregation of all
> > Resources with URI's that share the same domain name, then the host-
> > meta defaults to a single Resource identified by a URI. In other
> > word's the host-meta is same as any other XRD.
> >
> > On Tue, Nov 10, 2009 at 7:20 AM, John Kemp <john@jkemp.net> wrote:
> > On Nov 9, 2009, at 8:23 PM, John Bradley wrote:
> >
> > John,
> >
> > I am having a hard time with your argument that http: URI are not
> > sufficient for naming resources.
> >
> > I didn't say that.
> >
> > I simply said that using a string for the base type would make
> > things easier.
> >
> >
> >
> > I would recommend you read the TAG findings on XRI and XRDS.
> > http://www.w3.org/2001/tag/doc/URNsAndRegistries-50
> >
> > I will for the sake of argument agree with Roy Fielding that http:
> > URI can be used as names for any and all resources.   That is
> > distinct from them being used as locators for all resources.
> >
> > I fail to see a compelling argument for allowing strings in XRD
> > subjects and creating a registry of subject types. (been there it
> > didn't go well)
> >
> > Please don't take us down that road again.
> >
> > A XRD Subject, is a NAME it is not a Locator.
> >
> > I understand, really.
> >
> >
> >  Constraining Subject to a absolute anyURI is not unreasonable in my
> > opinion.   Subject can name information and non information
> resources.
> >
> > It's not necessarily unreasonable to me either, but it does put the
> > host-meta spec. into being forced to deal with URI scheme hell to
> > meet the use-case.
> >
> >
> >
> > Subject is not always required because it could be specified in some
> > other way by the protocol using the XRD.  Profiles of XRD are free
> > to make it required.
> >
> > Regardless of how the Subject is specified, it could be referenced
> > in the document too. And if it exists, what is the reason _not_ to
> > link to it in the document?
> >
> >
> >
> > If a XRD is retrieved via HTTP the protocol retrieving it may choose
> > to infer the subject (Name) is the Locator (URL).
> >
> > This is an XML doc if someone outside of the XRI-TC thinks they need
> > extension elements to describe the Scope of the XRD that is up to
> > them.  They define a namespace and have at it.
> >
> > Would it make you happy if host-meta had a subject ie:
> > <Subject>http:/google.com/#host-metta</Subject>
> >
> > as well as the <hm:Host> elements to describe scope for the
> templates.
> >
> > Even if <Subject is not used for anything in the host-meta spec?
> >
> > Given the history you will not convince the XRI-TC to define Subject
> > to be something other than a URI.
> >
> > Yes, that seems apparent. And it seems that host-meta will not get
> > into the URI scheme hot water. I can't say I blame either group.
> >
> > Regardless of my opinion, it seems that if neither side will change
> > their collective minds, we're left with the status quo, and we'll
> > have to settle on it as the least-bad alternative.
> >
> > - johnk
> >
> >
> >  That we didn't restrict it to http: URI will probably get us into
> > hot water in some places.
> >
> >
> > Regards
> > John Bradley
> >
> >
> > On 2009-11-09, at 8:35 PM, Eran Hammer-Lahav wrote:
> >
> >
> >
> > -----Original Message-----
> > From: John Kemp [mailto:john@jkemp.net]
> > Sent: Monday, November 09, 2009 2:14 PM
> >
> > 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.
> >
> > We agree on that. The question is only whether it is useful to
> > define an element generic enough to support the wide range of
> > potential subjects and still enable interoperability.
> >
> > I do see a pragmatic issue about how the subject of an XRD is
> > represented in the XRD document itself.
> >
> > What I am trying to convey is that from my perspective, the use case
> > supported by the current <Subject> design is by far more likely than
> > any other use case, and is the primary driver in developing XRD. I
> > am reluctant to design an element without better requirements or use
> > cases.
> >
> > 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 think that's what we have done. We just don't agree on how this
> > extensibility should be provided.
> >
> > 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.
> >
> > If anything I wrote came off as ridiculing your views please accept
> > my apology. I have meant no disrespect. My request for use cases
> > wasn't made as criticism, but an actual request for use cases.
> >
> > - johnk
> >
> > _______________________________________________
> > general mailing list
> > general@lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-general
> >
> >
> > _______________________________________________
> > general mailing list
> > general@lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-general
> >
> >
> >
> > --
> > http://hi.im/santosh
> >
> >
> >
> >
> >
> >
> > --
> > http://hi.im/santosh
> >
> >
>
> _______________________________________________
> general mailing list
> general@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general