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

Mon Nov 9 15:02:35 UTC 2009

It is interesting that you have a lot to speak about the <Subject> element
in this post. About 400 words. While the XRD 1.0 spec devotes only 22 words
for the <Subject>.

Just another crazy observation of mine.

On Mon, Nov 9, 2009 at 2:43 AM, Eran Hammer-Lahav <eran at hueniverse.com>wrote:

> First, it is not anyone's fault (other than your own) that your posts,
> across multiple lists, are a bucket full of crazy. I am not referring to
> your technical arguments, no matter how incoherent and incorrect, but to the
> rants and curses aimed at anyone who either doesn't understand or doesn't
> agree with your posts. It also didn't help that some of the people who
> answered your rants on the OpenID list had no understanding of XRD (or what
> you were saying). If it wasn't so counterproductive, it would make a
> hysterical off-off-broadway satire about the art of creating standards.
>
> Second, I am only responding to this latest installment because it is time
> to put an end to it, and because the OASIS process requires that all
> comments be addressed (we don't have to agree with them, but we cannot
> ignore them).
>
> You would probably find it useful to read this:
>
> http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality
>
> > -----Original Message-----
> > From: Santosh Rajan [mailto:santrajan at gmail.com]
> > Sent: Sunday, November 08, 2009 6:52 AM
>
> > What makes a Resource a "Resource"? Or what makes any "thing" or an
> "entity" a Resource?
> > It is the "availability" of the Resource to something else (another
> entity).
>
> You don't get to make up your very own web architecture and terminology. If
> you are going to use terms like 'resource', 'entity', 'available', you
> better use normative references to define what they mean, because your prose
> leaves me scratching my head. But even using the English meaning of these
> terms, this is patently false. XRD uses the common web architecture
> definition of a resource, and fully subscribes to the following text in RFC
> 3986:
>
>      This specification does not limit the scope of what might be a
>      resource; rather, the term "resource" is used in a general sense
>      for whatever might be identified by a URI.  Familiar examples
>      include an electronic document, an image, a source of information
>      with a consistent purpose (e.g., "today's weather report for Los
>      Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a
>      collection of other resources.  A resource is not necessarily
>      accessible via the Internet; e.g., human beings, corporations, and
>      bound books in a library can also be resources.  Likewise,
>      abstract concepts can be resources, such as the operators and
>      operands of a mathematical equation, the types of a relationship
>      (e.g., "parent" or "employee"), or numeric values (e.g., zero,
>      one, and infinity).
>
> XRD was intentionally designed to describe a single resource because that
> is the common use case driving its development. To support this use case,
> XRD provides the <Subject> element which requires an absolute URI value. An
> XRD with a <Subject> means it is a descriptor for the resource identified by
> that URI. And contrary to the common misunderstanding, <Alias> elements do
> not extend the scope of an XRD but merely provide other URIs the *subject*
> resource may be known as. In other words, <Subject> describes the single URI
> the XRD is about, while <Alias> describe the resource identified by
> <Subject>. They are fundamentally different elements.
>
> For example (using names instead of URIs to make a point):
>
> <XRD>
>        <Subject>Joe</Subject>
>        <Alias>Joseph</Subject>
> </XRD>
>
> Means: "This XRD is about Joe, who is also known as Joseph". It DOES NOT
> mean: "This XRD is about Joe, but also about Joseph".
>
> The TC was also aware that this view (of a single URI subject) might be too
> limited in other cases (such as host-meta). However, we opted not to define
> a mechanism to support other such subjects (other descriptor specifications
> such as POWDER made a different choice) because of lack of strong use cases.
> For this reason, we defined <Subject> as optional because we designed it to
> accommodate a very specific design. This is not a matter of opinion but
> definition. An XRD with a <Subject> element is defined as describing a
> single, URI-identified resource.
>
> This wasn't done on a whim but after a year-long discussion (all publically
> documented in the XRI TC archives). At some point we included a 'match'
> attribute on the <Subject> element to allow defining a pattern for a set of
> resources. Based on the TC own mantra of only including features with strong
> use cases, and based on feedback received from other communities, we decided
> to drop this feature.
>
> If you want to use XRD to describe something other than "A single resource
> identified by a URI", you are free to extend the schema and define some
> other mechanism to describe what your XRD is about. We provided <Subject> to
> cover what we consider to be the most common use case. YMMV.
>
> When faced with this limitation, some people have suggested to make
> <Subject> a string instead of a URI. While this will solve the URI
> limitation, it will introduce an interoperability challenge. URIs provide a
> clearly namespaces resource-identifier-space. If the subject can be any
> string, we need to figure out what that string means. This can be done
> using:
>
> 1. Another property such as <Subject type="uri"> or <Subject type="host">
> which will then require establishing a registry for type values. This offers
> no real benefits over simply defining other elements for other subject types
> but it does increase the document complexity for the common case.
> 2. The context in which an XRD is found. While valid, it takes away from
> the usefulness of XRD, by making it unable to self-describe what it is
> about. If the method through which an XRD is obtained defines its meaning
> (and that is likely to be the case in some protocols), a self-contained XRD
> is unable to assert its own scope. It also poses trust challenge because it
> is usually a bad idea to sign a document which doesn't explicitly includes
> its purpose or scope.
>
> After considering all the options, we decided to define a single <Subject>
> element with well defined meaning and semantics. We think it will be useful
> in most use cases, and when not, protocols are free to replace it with
> something else, either internally or externally.
>
> As for host-meta, it is defined as a document about a host or list of hosts
> (as defined by RFC 3986). At this time, there is no URI available to define
> such an abstract resource, and even if there was, host-meta needs to define
> multiple hosts for deployment reasons (example.com redirects to
> www.example.com). This too was discussed for a long time. We considered
> using DNS URIs (but they identify a DNS *record* not what the record means),
> URNs (which are not really appropriate for URIs with some form of authority,
> or an appealing choice for many web developers), a new URI scheme for host:
> (not likely to win community support), a well-known URI prefix (such as
> http://host-meta.net/http://example.com), the URI of the host-meta
> document itself (which would present a paradox), and a few other ideas.
> There is simply no appropriate URI to describe what host-meta is about.
>
> We decided that the host-meta use case was not sufficient to change the XRD
> spec. Instead, host-meta defines its own <Host> element.
>
> EHL
>

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