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

Fri Nov 13 04:32:37 UTC 2009

Mr. Williams,

Not sure what I have done to you to deserve such comments.

I have not responded to Santosh emails in the past because that's generally what happens when someone starts a conversation by calling me an idiot. I was also not a member of the OpenID list until this week. As I already made clear, I responded to his questions about the XRD design simply because it is required by the OASIS process. It wasn't anything he has done other than to send a polite (that time) question to the xri-comments list. On this list I enjoyed my recent exchange with John Kemp which was intelligent and polite. I like discussing these topics and I am always looking to engage in conversations about my designs and views.

I thought it might be useful to join the OpenID list this week and give it another try, especially to help people on this list better understand the rationale behind LRDD, host-meta, and XRD. However, with comments like this, it is clearly not a professional environment worthy of my time and effort.

Of the people working on related technologies, I am one of the most open and accessible. I also enjoy an employer that gives me absolute freedom and lack of conflict or agenda in my work. Everything I work on has been done in the open, on well-known public mailing lists, with direct collaboration with the IETF URI, HTTP, and APPs groups, OASIS XRI TC (who also have done nothing to deserve your disrespectful comments), and the W3C TAG.

If you are frustrated with lack of information or understanding of the specifications I author, or find their quality insufficient (as you have expressed recently), the courteous and honorable thing to do is to contact me and express that in a polite and productive way. But instead, you chose to act like a muppet [1].

Congrats! You have convinced me, yet again, to unsubscribe from this list. Maybe the OpenID board should consider enforcing some basic rules of civility and professionalism on this list.

EHL

[1] http://en.wikipedia.org/wiki/Statler_and_Waldorf

> -----Original Message-----
> From: openid-general-bounces at lists.openid.net [mailto:openid-general-
> bounces at lists.openid.net] On Behalf Of Peter Williams
> Sent: Thursday, November 12, 2009 3:57 PM
> To: general at openid.net
> Subject: Re: [OpenID] [xri-comment] My Feedback for XRD Vrsion 1.0
>
>
> Well done santosh. You are a wild card, but one worth betting on.
>
> We finally got to a summary at least of the "subject" issue, from Eran.
> We
> dont have to flounder around looking for the issues that MIGHT
> characterise
> those bald format and host-meta profiles spec - which are entirely
> devoid of
> design rationale.
>
> The funny thing is that while Eran is in my opinion completely
> untrustworthy
> when making his case in writing, in person I found him quite engaging,
> convincing and highly trustworthy as a software engineer. If you stress
> him
> enough, he can and will make a summary case though (as you eventually
> elicited).
>
> Im going to now elicit alternative summary on the year's debate,
> particularly from the W3C folks. Im not sure they will be in accord on
> either the presentation of the tradeoff history or the validity of the
> tradeoffs being proposed. That communities work on a "native" foaf+ssl
> relying party model based simply on SSL client certs and embedded
> webids
> (which needs no extension of the basic http scheme identifier model or
> the
> classical RDF semantic model) perhaps shows what else we in the
> ADOPTION
> community should be thinking about when it comes to endpoint
> offloading,
> attribute and role representation, discovery, name resolvers, and
> identifier
> semantics for an SSO world in general
>
>
>
>
>
>
>
>
>
>
>
> Santosh Rajan wrote:
> >
> > 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
> >
> > _______________________________________________
> > general mailing list
> > general at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-general
> >
> >
> > -----
> >
> > Santosh Rajan
> > http://santrajan.blogspot.com
> >
>
> --
> View this message in context: http://old.nabble.com/My-Feedback-for-
> XRD-Vrsion-1.0-tp26254440p26328514.html
> Sent from the OpenID - General mailing list archive at Nabble.com.
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general