My Feedback for XRD Vrsion 1.0

[Santosh Rajan]

Let us start with the definition, and overall scope of the XRD 1.0 spec. I have many more comments on the spec, but I will restrict this post only to one aspect, because there is no point in bringing up the other issues unless we agree on what I have to say in this post.

Let me quote from the beginning of the spec.

"This document defines XRD, a simple generic format for describing resources".

Now if you read the rest of the whole specification it is all about "describing resources". There is nothing else to the whole spec other than "describing resources". ie. XRD's are about "describing resources".

Now this is true, but not the "whole truth", and i am estimating only "half the truth".

Why is the other half of the truth not here? I don't know whether it is by accident or design. Now let us get to the whole truth.

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). I will explain.

1) Bikeshed-color-blue is an entity. What should it do to become a "Resource"? It must make itself available to John Panzer. Right! this bikeshed becomes a Resource only when it is "available" to someone or something.

2) Bikeshed-color-red is my bikeshed. Can we put these two bikesheds (resources) into the same XRD? No we CANNOT. Because both these bikesheds have made themselves available to two different people with two different XRD's.

That means the current definition of the XRD does not give the whole story and we need a more truthful definition. Here is the new definition.

 

"This document defines XRD, a simple generic format for describing a set of resources that is available to a given entity".

Now we can take this concept of the "set of resources" that have made themselves available to a "given entity", a little further.

Now it is not very difficult to understand that this "given entity",  is your "given identifier", or "Subject" or "rdf:about". (I am assuming people reading this are technically inclined).

So we can clearly see that, just like a Resource is meaningless without defining what it is available for, the whole "XRD 1.0 is spec is meaningless, without defining or explaining what an XRD is about".

In other words the XRD spec needs to clearly specify "what an XRD is about?", "What is, the resources in the XRD, making itself available to?"

Now let me preempt the arguments these guys are going to put up against this post.

1) We don't understand what you are saying!

2) This is wrong.

3) This is beyond the Scope.

If you want to argue this, you better come up with something better than (1) (2) (3) above. Just in case you did not understand anything, please ask, I will explain. And don't ask anything irrelevent to this post. (Dont I know you guys by now?).

--
http://hi.im/santosh

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Peter Williams]

I don't like the change as it builds the subject (and thus subject to object relations) into the format.

We know by design, that this is reserved for profiles - so there can be lots of ways of doing it.

Could the spec say that? Perhaps.

But there is a more important element. Them and us. We and them. You guys vs the collective rest.

At iiw, them and us was omni present: manifesting in social conduct.

Shib/oasis folks were repeatedly snarky about openid design style. (real engineers don't eat porc, type of line).

Traditional liberty folks folks saw iiw as but a brainstorming forum where use cases might be discovered and then taken back into other forms where the profssionals congregate in expert groups. (reminded me of the iso vs ietf putdowns of the 1990 period, where conceited phone companies projected the opinion that only they could build public data/packet networks and telematic apps.)

govt folks and their personal services contractors were trying to split the vommnity into insets and outsiders where access to govt secrets (like 1 + 1 = 0) is restricted to the indoctrinated folks who can be trusted to do the right thing. (this reminded me of the very early cissp program, which was about installing a trustworthy group of people into influence positions in ISPs and asps - almost as Covert protectors of the public good.)

the infocard hosted-in-cloud lot were dismissive of client cert selectors to the point of making me want to find out what they are so afraid of. Perhaps, with a modern era-jumping manoevre and twist, the foaf+ssl folks reinvent it. (this reminded me of x509s own story, left for dead in ietf pem/IPSec/gssapi in 1993, and resurrected by Netscape/verisign/entrust "startups" in 1994.)
 
then there was the kantara trust framework folks imputing that anything less than full NSA 1980s program  for red/black seperated, mac cultered, covert chanel obsessed, b3 formalized, comsec custodian operated regime. ... Can not meet the public "true" needs. (this reminded me of pem community debates, that legitimized low assurance, in an cold war era where those properly indoctrinated had to "by all means necessary" induce the rest of the world into the high assurance mantra, lest nostrodamus be proved right)

and then there is santosh, validly tapping into the sentiment that openid is failing to be inclusive somehow, leading to the you-guys type rhetoric.

This week at the gartner i&a summit, ciso types get to ponder the same topics from the market analytics point of view of all this. When has a technology spent enough times being dumbed down over enough years from university lab to commodity software so it reaches that breakout point, so startup millionares get rich, employees get fed, their kids get educated to do better than their parents and in the next 20 years another half billion Indian/Chinese folks will leave the land and come on stream as engineers and scientists and writers with even Yet more opinions.

Peter the pleb.

(I'm pseudo-pissed that verisign was not presenting itself properly at iiw, as a leader and bold executor of programs. It's done well I suppose to continue to exist for 15 years in silicon valley culture, but honestly!...where is the vision, where is the mindshare, ... Hopefully they are not relying on some version of the them and us prattle.)  

Santosh Rajan wrote:

Let us start with the definition, and overall scope of the XRD 1.0 spec. I
have many more comments on the spec, but I will restrict this post only to
one aspect, because there is no point in bringing up the other issues unless
we agree on what I have to say in this post.

Let me quote from the beginning of the spec.
"This document defines XRD, a simple generic format for describing
resources".

Now if you read the rest of the whole specification it is all about
"describing resources". There is nothing else to the whole spec other than
"describing resources". ie. XRD's are about "describing resources".

Now this is true, but not the "whole truth", and i am estimating only "half
the truth".

Why is the other half of the truth not here? I don't know whether it is by
accident or design. Now let us get to the whole truth.

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).
I will explain.
1) Bikeshed-color-blue is an entity. What should it do to become a
"Resource"? It must make itself available to John Panzer. Right! this
bikeshed becomes a Resource only when it is "available" to someone or
something.
2) Bikeshed-color-red is my bikeshed. Can we put these two bikesheds
(resources) into the same XRD? No we CANNOT. Because both these bikesheds
have made themselves available to two different people with two different
XRD's.

That means the current definition of the XRD does not give the whole story
and we need a more truthful definition. Here is the new definition.

"This document defines XRD, a simple generic format for describing a set of
resources that is available to a given entity".

Now we can take this concept of the "set of resources" that have made
themselves available to a "given entity", a little further.

Now it is not very difficult to understand that this "given entity",  is
your "given identifier", or "Subject" or "rdf:about". (I am assuming people
reading this are technically inclined).

So we can clearly see that, just like a Resource is meaningless without
defining what it is available for, the whole "XRD 1.0 is spec is
meaningless, without defining or explaining what an XRD is about".

In other words the XRD spec needs to clearly specify "what an XRD is
about?", "What is, the resources in the XRD, making itself available to?"

Now let me preempt the arguments these guys are going to put up against this
post.
1) We don't understand what you are saying!
2) This is wrong.
3) This is beyond the Scope.

If you want to argue this, you better come up with something better than (1)
(2) (3) above. Just in case you did not understand anything, please ask, I
will explain. And don't ask anything irrelevent to this post. (Dont I know
you guys by now?).
--
http://hi.im/santosh

_______________________________________________
general mailing list
[e-mail]
http://lists.openid.net/mailman/listinfo/openid-general


-----

Santosh Rajan
http://santrajan.blogspot.com 

[Eran Hammer-Lahav]

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@...]
> 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
_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Kemp-5]

Hi Eran,

On Nov 8, 2009, at 4:13 PM, Eran Hammer-Lahav wrote:

[...]

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

It can't be done by defining specific meaning for the known values  
(ie. list them in the XRD specification) and allowing extension by  
"other specifications"?

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

Can you explain that? I don't see that having an enumerated attribute  
here is more complex than two differently-named elements.

> 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 mentioned, I think that every XRD has a (logical) subject,  
regardless of whether it has a Subject (ie. the XML element).

>
> As for host-meta, it is defined as a document about a host or list  
> of hosts (as defined by RFC 3986).

Is a host, or a list of hosts not also the subject of an XRD document?  
A host, a list of hosts and a document about a host or hosts can all  
be defined as resources in the HTTP sense (or something more abstract  
if you wish).

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

And as mentioned, that is a fine pragmatic solution if you are not  
able to create an XRD Subject XML element that meets the needs of the  
various communities who wish to extend XRD. It doesn't change the fact  
that every XRD has a logical subject, even if the subject is called a  
Host.

Regards,

- johnk

>
> EHL
> _______________________________________________
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Santosh Rajan]

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

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Eran Hammer-Lahav]

> -----Original Message-----
> From: John Kemp [mailto:john@...]
> Sent: Monday, November 09, 2009 4:43 AM
> To: Eran Hammer-Lahav
> Cc: Santosh Rajan; xri-comment@...; general@...
> Subject: Re: [OpenID] [xri-comment] My Feedback for XRD Vrsion 1.0
>
> Hi Eran,
>
> On Nov 8, 2009, at 4:13 PM, Eran Hammer-Lahav wrote:
>
> [...]
>
> > 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.
>
> It can't be done by defining specific meaning for the known values
> (ie. list them in the XRD specification) and allowing extension by
> "other specifications"?

Unless the 'type' attribute value is a URI, no. Any short-name-based solution should come with a registry to avoid name collision. But the whole design is just unattractive. There is really no difference at all between a client encountering an unknown attribute value and an unknown element. But the advantage of the second approach is that it prevents the client from making bad assumptions about the value of the subject (given an unknown type). It also reduces confusion when two identical subject are used to mean completely different things solely based on their type attribute.

After over a year of debate, the XRI TC has failed to come up with a single use case for non-URI subjects other than host-meta. I would gladly open this discussion again, but not without compelling use cases. Extensibility (beyond what is currently supported) that is not anchored in practical needs is a poor design choice. It is the schema version of astronaut architecture...

> > 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.
>
> Can you explain that? I don't see that having an enumerated attribute
> here is more complex than two differently-named elements.

Someone has to manage this enum. Another lesson learned from host-meta (which is the only use case we found for non-URI subjects), is that since XRD was designed with URI-identified resources in mind (and a single one at that), changing the subject of an XRD to be anything else will likely require making other adjustments to the meaning and processing rules of the XRD. For example, the context URI/resource of links, the meaning or applicability of the <Alias> element, the meaning of templates, etc.

I thing putting a small hurdle on the path to extending XRD to describe things other than a resource identified by a URI is a good thing. It will force protocol developers to think about the problem, to try and find an appropriate URI for their subject, consider how it will impact existing trust profiles based on the <Subject> element (which are going to depend on its URI structure and meaning), and figure out what the rest of the document means (semantically) in such cases. It will also force them to consider whether breaking compatibility with the Web Linking framework is acceptable (being unable to link from HTML or ATOM to the subject of the XRD because it is not URI-reference-able). This is exactly the thinking process that led us to come up with the acct URI.

> > 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 mentioned, I think that every XRD has a (logical) subject,
> regardless of whether it has a Subject (ie. the XML element).

As simple as I personally find this set of specifications, it is already non-trivial for many people. By providing a well-defined, in-document, and restrictive <Subject> element, XRD makes it less likely for bad things to happen. Since trust is a big reason for having a <Subject> in an XRD, I would strongly oppose a protocol that overrides or gives additional meaning to the subject of an XRD (outside its declared <Subject>) based on the context in which it was obtained. It is one thing to differentiate the trust level of an XRD based on how it was obtained, but a whole other thing to make it be *about* something else.

The <Subject> element design does not preclude *any* of the approaches proposed. It simply provides a limited but extremely useful tool for what we determined to be the most compelling and likely use case.

> >
> > As for host-meta, it is defined as a document about a host or list
> > of hosts (as defined by RFC 3986).
>
> Is a host, or a list of hosts not also the subject of an XRD document?
> A host, a list of hosts and a document about a host or hosts can all
> be defined as resources in the HTTP sense (or something more abstract
> if you wish).

But this subject behaves fundamentally differently from a URI-identified resource. Links are applied differently. For example, host-meta defines the semantic meaning of a <Link> with <URI> to be about the host (the entity controlling the namespace), and <Link> with <URITemplate> to be about individual resources within the namespace. XRD does not provide such a distinction because it defaults to describing a single resource identified by a URI.

Host-meta does some (smart, I hope) things to make XRD work for its needs. For example, it allows multiple <hm:Host> elements which would not work if we found a magical way to use <Subject>. Host-meta needs to support multiple hosts in a single document due to (very) common deployment restrictions. If we make <Subject> more generic for non-URI subjects, we will need to also allow multiple <Subject> elements. At this point you will have a poorly defined element with no real interoperability value. It will become (literally), an empty shell.

> > 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.
>
> And as mentioned, that is a fine pragmatic solution if you are not
> able to create an XRD Subject XML element that meets the needs of the
> various communities who wish to extend XRD. It doesn't change the fact
> that every XRD has a logical subject, even if the subject is called a
> Host.

Please name those communities and provide details about their use cases.

The XRI TC has spent the last year throwing furniture off the deck, with the determination to keep XRD as simple as possible while focusing on real use cases. We are happy to reconsider every aspect of our design, but *only* if it is based on actual use cases, not some theoretical what-if scenarios. I don't want to point finger at other specs who failed to follow this rule and ended up with a bloated spec no one really uses.

EHL

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Kemp-5]

Hi Eran,

On Nov 9, 2009, at 12:02 PM, Eran Hammer-Lahav wrote:

[...]

>
>
>> ---
>> It can't be done by defining specific meaning for the known values
>> (ie. list them in the XRD specification) and allowing extension by
>> "other specifications"?
>
> Unless the 'type' attribute value is a URI, no. Any short-name-based  
> solution should come with a registry to avoid name collision.

My point is that the registry is simply in the specification. Either  
new short names appear in future versions, or they are URIs whose  
meaning is determined by the URI owner. I've read that same idea  
somewhere before (link header framework maybe?) but it was also used  
in SAML (authentication method/context for example). Registries have a  
long and honorable... well, checkered, history ;)

> But the whole design is just unattractive.

I could say the same thing about a design that requires two  
differently-named elements specified by two different groups, but I  
don't think that would be helpful.

> There is really no difference at all between a client encountering  
> an unknown attribute value and an unknown element. But the advantage  
> of the second approach is that it prevents the client from making  
> bad assumptions about the value of the subject (given an unknown  
> type).

The client definitely needs to know what to do when it encounters a  
subject. And to know when it cannot do anything about the appearance  
of a particular subject.

> It also reduces confusion when two identical subject are used to  
> mean completely different things solely based on their type attribute.

A single host, a list of hosts, and the XRI subject are all considered  
the subject of the XRD. I believe that the subject of the XRD is the  
entity about which the XRD contains related resource information. In  
other words, "subject" has semantics in XRD.

>
> After over a year of debate, the XRI TC has failed to come up with a  
> single use case for non-URI subjects other than host-meta.

Yes, but the point I am making is that an XRD has a subject,  
logically. And it is simply the representation of the Subject XML  
element that prevents someone using a non-URI-identified subject.  
Personally, I think it is fine that a subject might be represented by  
something other than a URI, but I can see the other side of the  
argument too. Pragmatically-speaking, it is hard to decide how to make  
URIs to point to things that don't fit nicely in the HTTP model.

> I would gladly open this discussion again, but not without  
> compelling use cases. Extensibility (beyond what is currently  
> supported) that is not anchored in practical needs is a poor design  
> choice. It is the schema version of astronaut architecture...

Sure if you say so. And I can't tell you of exciting new use-cases  
that need that. Your solution is pragmatic for the needs of host-meta.

But it is certainly the case that I think it would be bad design to  
simply let Subject be optional and then have someone else come along  
and put a new element in the schema simply because their Subject is  
called Host (or Slartibartfast, or whatever), but still has the  
semantics that it is the "subject of the resource links contained in  
the XRD".

I don't think that it is "astronaut architecture" to suggest that if  
you logically always have a subject of an XRD document that the  
Subject XML element should always appear. It just seems like common  
sense.

[...]

>>> As for host-meta, it is defined as a document about a host or list
>>> of hosts (as defined by RFC 3986).
>>
>> Is a host, or a list of hosts not also the subject of an XRD  
>> document?
>> A host, a list of hosts and a document about a host or hosts can all
>> be defined as resources in the HTTP sense (or something more abstract
>> if you wish).
>
> But this subject behaves fundamentally differently from a URI-
> identified resource. Links are applied differently. For example,  
> host-meta defines the semantic meaning of a <Link> with <URI> to be  
> about the host (the entity controlling the namespace), and <Link>  
> with <URITemplate> to be about individual resources within the  
> namespace. XRD does not provide such a distinction because it  
> defaults to describing a single resource identified by a URI.

A "single resource" can be about anything. A "single resource" could  
be "a group of hosts". A URI _identifies_ a resource. It may or may  
not also produce a representation of that resource. The resource is  
singular but may describe a plurality.

>
> Host-meta does some (smart, I hope) things to make XRD work for its  
> needs. For example, it allows multiple <hm:Host> elements which  
> would not work if we found a magical way to use <Subject>. Host-meta  
> needs to support multiple hosts in a single document due to (very)  
> common deployment restrictions. If we make <Subject> more generic  
> for non-URI subjects, we will need to also allow multiple <Subject>  
> elements. At this point you will have a poorly defined element with  
> no real interoperability value. It will become (literally), an empty  
> shell.

I think you would need to decide whether the XRD was linked to a  
subject and the subject could be a group. Or that an XRD is about a  
group of subjects, where the group has at least one element. Do you  
see the distinction?

>
>>> 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.
>>
>> And as mentioned, that is a fine pragmatic solution if you are not
>> able to create an XRD Subject XML element that meets the needs of the
>> various communities who wish to extend XRD. It doesn't change the  
>> fact
>> that every XRD has a logical subject, even if the subject is called a
>> Host.
>
> Please name those communities and provide details about their use  
> cases.

I can't, and I don't claim to represent any community in this  
discussion.

I could note, however, that were someone to write a (imaginary)  
"generic" XRD processor, they certainly might hope that they could  
check for the subject of the XRD in only one XML element and not two  
(or more).

But basically, you'll have to decide whether you believe my argument  
that an XRD ALWAYS has a subject, even if the subject is called  
"host", based on the merits of the argument alone. You'd then need to  
decide whether it is worth some extra work to correctly represent the  
semantics of XRD in the schema and specification.

>
> The XRI TC has spent the last year throwing furniture off the deck,  
> with the determination to keep XRD as simple as possible while  
> focusing on real use cases. We are happy to reconsider every aspect  
> of our design, but *only* if it is based on actual use cases, not  
> some theoretical what-if scenarios. I don't want to point finger at  
> other specs who failed to follow this rule and ended up with a  
> bloated spec no one really uses.

I don't have any what-if scenarios for you.

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.

I do see a pragmatic issue about how the subject of an XRD is  
represented in the XRD document itself.

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

- johnk

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Eran Hammer-Lahav]

> -----Original Message-----
> From: John Kemp [mailto:john@...]
> 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@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Bradley-9]

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

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@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Kemp-5]

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@...]
>>> 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@...
>> http://lists.openid.net/mailman/listinfo/openid-general
>

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Manger, James H]

Some parts of this message have been removed. Learn more about Nabble's security policy.

How about putting <hm:Host> inside <Subject>?

 

When there is a single URI identifying the resource described by the XRD use:

  <Subject><URI> http://example.com/thingA</URI></Subject>

 

When the XRD describes a host use:

  <Subject><hm:Host>example.com</hm:Host>

                      <hm:Host>www.example.com</hm:Host></Subject>

 

When the XRD does not specify an identity for the resource(s) it describes use:

  <Subject/>

 

 

1.       <Subject> can be mandatory (which some want).

2.       A <URI> child element is already used in <Link> elements so it “fits” with the specs style.

3.       An empty <Subject> element unambiguously says “no identify here for the resource this metadata describes — use something else”.

4.       Other specs (eg host-meta) can define their own elements to identify the subject, using their own XML namespaces instead of a new registry.

5.       An application can tell when it doesn’t understand how the subject is being identified — there will be unrecognized elements in <Subject>.

 

Point 5 prevents an application (that understands XRD but not, say, host-meta) misinterpreting an XRD that has an unrecognized element providing a role similar to the absent <Subject>.

 

James Manger

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Santosh Rajan]

I think the whole problem is with the definition of the XRD, as I have suggested in the original post. 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@...> 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@...]
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@...
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

--
http://hi.im/santosh

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Kemp-5]

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

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Santosh Rajan]

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.

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.

So there are no more use cases of XRD's that do not require a <Subject> element. 

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

On Tue, Nov 10, 2009 at 7:24 PM, John Kemp <john@...> 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@...> 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@...]
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@...
http://lists.openid.net/mailman/listinfo/openid-general


_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general



--
http://hi.im/santosh

--
http://hi.im/santosh

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[John Kemp-5]

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

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Eran Hammer-Lahav]

This is all pretty accurate except for the characterization of "two camps".

<Nothing New From Here On>

Both designs, XRD and host-meta, come from a largely overlapping group of people. Host-meta was originally proposed as a text-based document. At some point it became clear that there was value in reusing the XRD schema and so we started looking at how it would be applied to this particular edge case. We were able to solve the questions of link subjects for URI and URITemplate, but then got to the issue of Subject.

For the past year (I am not exaggerating), this topic was continuously discussed on the XRI list and weekly calls. I have raised the question to the IETF Apps area with little success, the W3C Tag with similar results, and other communities such as WebFinger (which is heavily depended on host-meta). We came to the following conclusions:

1. There is no existing URI scheme suitable to describe a 'host' (dns, tag, etc.).
2. A significant number of people rejected the Semantic Web ideas of well-known HTTP URI prefix or using a #fragment to denote a special meaning.
3. A significant number of people rejected the idea of using a URN for both style reasons and because URNs should not include an authority.

The conclusion was that there was no URI available *winning rough consensus*.

Back to XRD, we looked at how we could express a non-URI subject. Note that at the time, host-meta was defined as single scheme/authority scope. This has changed since to encompass an entire host (as in the entity controlling the host namespace per 3986). We tried:

<Subject match="prefix">http://example.com</Subject>

<SubjectSet>
        <Authority>example.com:80</Authority>
        <Scheme>http https</Scheme>
</SubjectSet>

<Subject type="host>example.com</Subject>

<hm:Subject>example.com</hm:Subject>

<Subject hm:type="host-meta">example.com</Subject>

We looked at POWDER which has a 30+ page specification of how to address similar use cases (http://www.w3.org/TR/powder-grouping/). We considered URI templates in subjects. I even proposed using an invalid URI scheme since a strict reading of the anyURI schema rule doesn't require a *registered* scheme, only proper format:

<Subject>host:example.com</Subject>

The 'match' attribute got the most traction of the bunch, but then started to "leak" into other area of the schema. We came to the conclusion that Alias will also have to support the same mechanism because it should be able to express the same set of identifiers expressed by Subject. Then when it came to trust profiles, we used to have a Subject element as a child of Link (to express the expected subject of the linked XRD, a concept that was since removed from the spec due to lack of use cases). That meant it too would have to be changed.

We found ourselves changing a lot more than just making Subject a bit more inclusive, and all that for a single use case which had a simpler (and in my view cleaner) solution: extend the schema to define a new host-meta subject.

This decision was further justified when host-meta was changed to accommodate a list of hosts. To make Subject work for that, we need an even more expanded format (space delimited values, child elements, or changes to the element cardinality).

XRD and its predecessors, XRDS and XRDS-Simple were always about a "resource identified by a URI". This definition has not changed in 5 years. While the simplicity of the new XRD format, and its alignment with web linking makes it more appealing and generally useful, it is important to remember what it is designed for.

We have gone through a thorough discussion and came to the conclusion that we simply don't have consensus to change the current (and historical via <CanonicalID>) definition of the <Subject> element. No one is fully satisfied with this status quo, but nevertheless, it *is* something we all agree on and find useful for every single use case but one (host-meta).

At this point, the only reason to open this discussion are new ideas, not new opinions. I certainly appreciate the view some take that this is more than a bikeshedding discussion about the *syntax*. However, this debate has to end for us to move forward and I have heard nothing new to suggest we are more likely to resolve it now than we were the past year.

All I have left to offer is for us to move forward with the solution as currently presented. As we gain more implementation experience across a wider set of protocols and communities, we can come back and revisit.

EHL

Side note: To be honest, the only reason why I was willing to spend more time on this (again) is my respect to John Kemp who has articulated some good ideas about the topic. They were not new to the XRI TC but new in the wider context and deserved to be addressed. Wearing my XRD editor and architect hat, I consider this matter closed.

> -----Original Message-----
> From: openid-general-bounces@... [mailto:openid-general-
> bounces@...] On Behalf Of John Kemp
> Sent: Tuesday, November 10, 2009 7:18 AM
> To: Santosh Rajan
> Cc: general General; xri-comment@...
> Subject: Re: [OpenID] [xri-comment] My Feedback for XRD Vrsion 1.0
>
> 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@...> 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@...> 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@...]
> > 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@...
> > http://lists.openid.net/mailman/listinfo/openid-general
> >
> >
> > _______________________________________________
> > general mailing list
> > general@...
> > http://lists.openid.net/mailman/listinfo/openid-general
> >
> >
> >
> > --
> > http://hi.im/santosh
> >
> >
> >
> >
> >
> >
> > --
> > http://hi.im/santosh
> >
> >
>
> _______________________________________________
> general mailing list
> general@...
> http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Santosh Rajan]

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@...> 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@...> 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@...> 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@...]
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@...
http://lists.openid.net/mailman/listinfo/openid-general


_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general



--
http://hi.im/santosh






--
http://hi.im/santosh

--
http://hi.im/santosh

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Peter Williams]

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


--
http://hi.im/santosh

_______________________________________________
general mailing list
[e-mail]
http://lists.openid.net/mailman/listinfo/openid-general


-----

Santosh Rajan
http://santrajan.blogspot.com 

[Eran Hammer-Lahav]

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@... [mailto:openid-general-
> bounces@...] On Behalf Of Peter Williams
> Sent: Thursday, November 12, 2009 3:57 PM
> To: general@...
> 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@...> 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@...> 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@...> 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@...]
> >>> 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@...
> >>> http://lists.openid.net/mailman/listinfo/openid-general
> >>>
> >>>
> >>> _______________________________________________
> >>> general mailing list
> >>> general@...
> >>> http://lists.openid.net/mailman/listinfo/openid-general
> >>>
> >>>
> >>>
> >>> --
> >>> http://hi.im/santosh
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> http://hi.im/santosh
> >>>
> >>>
> >>>
> >>
> >
> >
> > --
> > http://hi.im/santosh
> >
> > _______________________________________________
> > general mailing list
> > general@...
> > 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@...
> http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Peter Williams]

The summary of the subject issue was a high class act. Noone else in 2-3
weeks of discussion had even been able to properly characterize the
techno-politics of the issue at hand. You did so, getting to the heart of
the matter. It disclosed an insider's view of the political process that has
been going on for a year, and discussed that process in positive terms:
trying to make various camps content with a format that can satisfy various
conflicting needs (when profiled). Punting to profile and extension models
is a long standing political out, which brings with it its own issues during
adoption.

I'm not sure anyone could care about an adopting-user's perspective, but I'd
be content now if the IETF I-D showcased how the tradeoffs on subject
"really work" -- by including a signed XRD example, for the host-meta
profile specifically. Then we can see if the tradeoffs over identity models
for resources hold up for enough interesting cases; and we will have a
worked example of subject being used (since its apparently mandatory in
signed XRD).

Let not forget reality. Most implementers implement from the worked examples
of the spec, and view the code as finished when it works fine with the lead
implementation in the commonest flows. Most implementers are NOT software
engineers and do not build  or use complete type libraries that capture all
the tradeoffs, and handle all the edge cases.

Let's see if all the careful compromises and hedges over the difficult
issues of uri identifiers in the subject field hold up, when subject is used
in signed XRD. If you showcase it in signed host-meta and it makes it
through to the RFC, you'll have silenced at least one old (rather ignorant)
cynic.


-----Original Message-----
From: Eran Hammer-Lahav [mailto:eran@...]
Sent: Thursday, November 12, 2009 8:33 PM
To: Peter Williams
Cc: general@...
Subject: RE: [OpenID] [xri-comment] My Feedback for XRD Vrsion 1.0

Mr. Williams,

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



_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general