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

Tue Nov 10 15:17:48 UTC 2009

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 at 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 at 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 at 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 at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
> -- 
> http://hi.im/santosh
>
>
>
>
>
>
> -- 
> http://hi.im/santosh
>
>