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

[John Bradley]

John,

I am having a hard time with your argument that http: URI are not  
sufficient for naming resources.

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.  Constraining Subject to  
a absolute anyURI is not unreasonable in my opinion.   Subject can  
name information and non information resources.

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091109/278bc095/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091109/278bc095/attachment-0001.bin>