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

Wed Nov 11 07:43:16 UTC 2009

Hi John,
Yes I agree with your views given. Also I can see that you have a good
compromise solution to the problem.
Regards
Santosh

On Tue, Nov 10, 2009 at 8:47 PM, John Kemp <john at jkemp.net> wrote:

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

-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091111/1c9b44a9/attachment-0001.htm>