[OpenID] Open Challenge to webfinger and XRD

home_pw home_pw at msn.com
Sat Oct 24 01:36:01 UTC 2009 

Trying to post via nabble. Here goes...

---------------


For about a month, after 2 years of trying, I believed I understood XRD (and
XRDS and even the YADIS profile) as described in the XRI v2 Resolution spec.
I almost understood how some XRD fields became controlled variables - those
defined formally in the openid spec.

It was all comprehensible as the identifier model and the resolver for the
identifiers were specified clearly in XRI v2 draft spec. There was even a
comprehsible trusted resolution process with a clear validity model. Now,
after this thread, I'm back to not understanding XRD (v1.0) - as Im no
longer able to relate to a formal logical basis (or its notion of validity).
Obvious stuff about generic formats from OASIS (XRD) vs some profile of the
generic format from IETF (e.g. host meta) is perfectly clear.

So, its time for me to go back to the bottom of the class (again). Perhaps
it will be easier when the identifier spec is published.

What is evident to me is that to be endorsed by W3C TAG, XRD will need
(without reference to any identifer spec) to be in alignment with the spirit
of the semantic web - which has both an identifier and resource model (and
of course a metadata model) of its own. It took me a year, but I do now
understand the application of the rdf metadata model to the notions
addressed in the foaf world.

As it happens, Henry Story and I were discussing webids, resources, HTTP
retreival of bytes, foaf documents (and Persons described in a foaf
document). It was in the context of discussing foaf+ssl in relation to the
semweb. It concerned the way in which SSL client certs bearing URIs might be
presented  to https servers in order to "refer to" or "identity" or "locate"
foaf files claiming to be Documents ... whose elements can describe, define,
and even geospatially locate things other than bytestreams (given the only
thing GET using HTTP can actually retrieve is a bytestream).  

One can hopefully see in his writing the distinctions being made between
documents, the url of an actually retrievable resource (i.e. the document),
semantically defined constructs such as a Person, and descriptor(s) of
particular Persons. I suspect the metamodel used in the XRD spec will need
to align very clearly with this metamodel.

Here is a part of what he wrote, stating things really clearly. Its simple,
its intuitive, and I dont have to work hard dealing with too much
abstraction.

"you have a foaf file with an https:// url. Let us say the url of this
resource is

	https://williams.me/peter/card

that is the url of a Document. It is something one can do an HTTP GET on. It
is something that contains a number of characters,...

  You on the other hand are a Person, a physical thing that can move and has
a spatiotemporal position. So we need an URI to identify you rather than
someone else. This is where the hash url come in. Your WebId then is

	https://williams.me/peter/card#p

Up till now URL were always URLs of documents. What the semantic web enables
us to do is now have URLs of things too. Btw, you only know what the above
url refers to by dereferencing the document that describes it. Once that is
done, you could find that the #p refers to a subsection of the document."



What I hearing from John B's explaination  is that in a given SEP/link with
<Rel>X</Rel>, X might be Person. If there are multiple <Rel> elements in
multiple Links within a particular XRD document (once retrieved), then each
LINK can be identifed (by URL fragment). As with foaf, the URL for a
particular Link MIGHT (or might not) also locate the XRD "document" itself -
from which one can can now determine that a #fragment refers to an SEP of
Rel = X. Only at that point does one know that the URI
http://url.com/peter#fragment refers to a link of rel type X.

Now what I hoping is that "#fragment" tag of the URI maps onto the subject
element within a given Link/SEP element. 

Presumably, if the XRD (vs any of its link) has a TYPE of X, where X =>
host-meta as defined in some profile standard, one can now infer that the
document conforms to the IETF host-meta profile of the XRD format. In this
case, only certain Reltypes of Links shall be present (when conforming to
the profile).


John Bradley-9 wrote:
> 
> The <Type> element can tell a application if the XRD is a site meta  
> XRD or some other sort of XRD.
> 
> If LRDD wants to have two different XRD with the same subject, and  
> differentiate between them via the Type elements they can.
> 
> If they want to add a fragment to one of the URI to make the subjects  
> different they can do that.
> They can use a different URI scheme,  if they like.   I am not buying  
> the argument that URI are not adequate for naming things.    We have  
> already been around that block.
> 
> Adding a attribute to Subject that largely duplicates <Type> seems  
> confusing.
> 
> Allowing strings in Subject seems unnecessary.
> 
> If people have a strong reason for allowing strings rather than  
> absolute URI they should provide that feedback to the XRI-TC.
> 
> John B.
> On 2009-10-20, at 12:12 PM, Santosh Rajan wrote:
> 
>>
>> The application looking for a resource already knows wether it is  
>> looking for
>> an "information resource" or "non information resource". The  
>> application
>> already knows what it is looking for in an XRD. The idea of trying to
>> differentiate this XRD is moot under the circumstances. Unless of  
>> cource you
>> can show a use case where an application does NOT know what it is  
>> looking
>> for in an XRD.
>>
>>
>> John Kemp-5 wrote:
>>>
>>> Hi John,
>>>
>>> On Oct 20, 2009, at 10:26 AM, John Bradley wrote:
>>>
>>>> John,
>>>>
>>>> There is a use case where someone wants to treat the URI that was
>>>> used to retrieve the XRD from as the subject.
>>>
>>> The subject of the XRD is the URI of the XRD document about the  
>>> subject?
>>>
>>>>
>>>> This is how openID currently deals with this in XRDS by ignoring the
>>>> subject.
>>>
>>> Hmmm.
>>>
>>>>
>>>> I personally think that this is not an optimum trust model.  However
>>>> there are people who want to preserve the option.
>>>
>>> As I suggested to Drummond, instead of leaving out the subject, can't
>>> we say, in XRD/XSD terms, that the Subject is implicit in YYYY (where
>>> YYYY is some other identifier)?
>>>
>>>>
>>>> It is up to LRDD or other specs that use XRD to decide if they want
>>>> to require a explicit subject.
>>>>
>>>> XRI 3.0 resolution will likely require it.
>>>>
>>>> The URL http://example.com that is web content and the organization
>>>> example.com
>>>> are different things they should simply have different names.   If
>>>> you want to argue in favour of using things other than http: URI to
>>>> name things I wish you luck.
>>>
>>> There is a long history of using simple string names maintained in a
>>> registry. I'm not necessarily arguing in favour of that, but simply
>>> saying that whatever people want to do is at least possible, and has
>>> been done before.
>>>
>>>>
>>>> The TAG actively campaigned against the adoption of XRI 2.0 because
>>>> we didn't require subject to be a http: URI.
>>>>
>>>> The <Type> element or elements declare properties the Subject.
>>>>
>>>> So LRDD can and probably should define a Type for the host-meta XRD.
>>>>
>>>> Allowing Subject to be a string for everyone that doesn't want to
>>>> use a URI for some reason is not particularly persuasive.
>>>
>>> The point is that by allowing extension you aren't saying anything
>>> about how XRI will use XRD, you are simply allowing others (who are
>>> not doing XRI) to meet their own use-case, which might be satisfied
>>> better by using a string Subject than making them define a whole new
>>> concept, or forcing them to use a URI, which may, or may not be
>>> appropriate or necessary.
>>>
>>>>
>>>> The XRI -TC is attempting to be good web citizens.  If you have a
>>>> position that runs counter to those previously expressed by the TAG,
>>>> we would welcome feedback through the OASIS process.
>>>
>>> As mentioned, I am not representing the TAG in this discussion, and
>>> frankly, I'd rather not opine at all on what kind of URI is used to
>>> define a DNS Host. I'd rather leave that to those who wish to define
>>> and identify those entities in the context of XRD. I'm suggesting  
>>> that
>>> XRD provide an appropriate extension point - since Dirk already
>>> suggested a string Subject (calling it Host) it would seem to me that
>>> this would be a reasonable thing to allow - LRDD can say <Subject
>>> type="dns-host">example.com</Subject>. That would seem to solve their
>>> issue, without compromising the XRD idea of subject, and without
>>> saying anything on the question of information resources vs. non-
>>> information resources (and I would suggest it would be wise to try to
>>> avoid that question).
>>>
>>> - johnk
>>>
>>>>
>>>> This is the current draft.
>>>> http://www.oasis-open.org/committees/download.php/34724/xrd-1.0-wd09.html
>>>>
>>>> Regards
>>>> John Bradley
>>>>
>>>> On 2009-10-20, at 9:11 AM, John Kemp wrote:
>>>>
>>>>> On Oct 19, 2009, at 9:50 PM, John Bradley wrote:
>>>>>
>>>>>> John
>>>>>>
>>>>>> I think the goal is to be able to attach XRD meta-data to any http
>>>>>> information-resource.
>>>>>>
>>>>>> It presents a problem if you attempt to overload a single URI to
>>>>>> describe both a information and non-information resource.
>>>>>
>>>>> As noted below, there are TWO things that need to be identified -
>>>>> the "subject" of the XRD (which can be anything named with a URI as
>>>>> you say), and a "DNS host" (which is identified, perhaps among
>>>>> other things, by an IP address or a DNS name which maps to an IP
>>>>> address). XRD itself is concerned with only one of those things.
>>>>>
>>>>>>
>>>>>> My advice to LRDD has been to simply pick a different URI for what
>>>>>> is essentially a non-information resource.    They can add a
>>>>>> fragment or a number of other things.   303 redirects don't work
>>>>>> as well for this use case.
>>>>>>
>>>>>> My guess is if we were to ask some on the TAG ,  we would get the
>>>>>> advice not to get hung up on implied semantics of the URI when
>>>>>> using it as a name. There is no clear reason that http://
>>>>>> example.com is a better than http://example.com/#host-meta as a
>>>>>> name for something that is a organizational concept rather than a
>>>>>> serialisable representation.
>>>>>>
>>>>>> I think LRDD will eventually do something reasonable.
>>>>>>
>>>>>> However the XRI-TC has yet to be convinced that encouraging people
>>>>>> to name two different things with the same name is a good idea.
>>>>>
>>>>> I agree that you (or someone) is naming TWO things - an XRD, and a
>>>>> "DNS host" and that you (or someone) should define the relationship
>>>>> between the two concepts. If there is no suitable identifier type
>>>>> for a DNS host, one could indeed be chosen.
>>>>>
>>>>>>
>>>>>> If you have ideas on the proper W3C friendly way to name the
>>>>>> subject of the meta-data for all the protocols relating to a DNS
>>>>>> name,  I am quite interested in your opinion.
>>>>>
>>>>> There is a large amount of data out there regarding different ways
>>>>> of naming things, both with URIs and without. I don't think that my
>>>>> opinion is any more helpful than anyone else's on this subject, but
>>>>> I would say this about XRD, and how it appears to disallow certain
>>>>> extensions in this area that might be helpful:
>>>>>
>>>>> i) The Subject element seems to be of xsd:type anyURI, which
>>>>> disallows someone from creating their own "registry" of (string)
>>>>> names, for example, and/or defining subjects as simple string
>>>>> values (as proposed below by Dirk I think). It would be possible
>>>>> within the rules of XSD/RelaxNG to define a more open content model
>>>>> - start with a string, and then define a restriction to anyURI for
>>>>> that kind of XRD usage, but allow extensions by others to either
>>>>> restrict the open type more, or use it as-is.
>>>>> ii) There seems no extension currently possible on the Subject
>>>>> element that would allow the creator of the XRD to indicate the
>>>>> "type" of the Subject and thus make the relationship known that  
>>>>> way.
>>>>>
>>>>> FWIW, SAML 2.0 does a nice job of allowing extensions such as the
>>>>> above.
>>>>>
>>>>> I find it odd that an XRD could really have no Subject, but again,
>>>>> I don't know the use-case for that, or whether this is simply done
>>>>> to allow someone to create Subjects which aren't named with URIs
>>>>> (in which case, I would suggest allowing XSD extensions might be a
>>>>> better path).
>>>>>
>>>>>>
>>>>>> I personally believe that URI fragments in XRD <Subjects> are the
>>>>>> best way to create XRD meta-data for non-information resources.
>>>>>> It maintains consistency with other sem-web protocols like POWDER.
>>>>>>
>>>>>> One could argue that an openID identifier for me is also properly
>>>>>> a non-information resource and should be http://thread-safe.net/#1234
>>>>>> to indicate that the subject of the meta-data is the person and
>>>>>> not the web page.
>>>>>>
>>>>>> That however is a different topic.  I have never gotten very far
>>>>>> arguing against overloading URI.
>>>>>
>>>>> As mentioned, I don't know enough to offer a very informed opinion,
>>>>> but I do agree that there are two things being named here, so you
>>>>> need two URIs (or one URI and something else) and to define the
>>>>> relationship between the two things.
>>>>>
>>>>> Regards,
>>>>>
>>>>> - johnk
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> John B.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2009-10-19, at 9:45 PM, John Kemp wrote:
>>>>>>
>>>>>>> Hey John,
>>>>>>>
>>>>>>> On Oct 19, 2009, at 8:26 PM, John Bradley wrote:
>>>>>>>
>>>>>>>> Hi John,
>>>>>>>>
>>>>>>>> An XRD can describe anything that can be named with a URI.
>>>>>>>>
>>>>>>>> The issue of trying to name everything with a http: URI is a
>>>>>>>> religious one.
>>>>>>>>
>>>>>>>> If you look at the W3C TAG AWW (http Range 14) there are a
>>>>>>>> number of options for naming non information resources with
>>>>>>>> http: URI.
>>>>>>>>
>>>>>>>> People flagrantly violate AWW all the time,  Yadis discovery is
>>>>>>>> a clear violation etc.
>>>>>>>>
>>>>>>>> It is not the XRI-TC's job to play URI police.
>>>>>>>
>>>>>>> Indeed, and in the interests of full disclosure, I will note that
>>>>>>> I am a member of the W3C TAG, and am well-aware of the "religious
>>>>>>> issues" around the use of HTTP URIs. I am not representing the
>>>>>>> TAG in this discussion, FWIW.
>>>>>>>
>>>>>>>>
>>>>>>>> LRDD can use any URI scheme or other valid mechanism to create a
>>>>>>>> unique http: URI for a host they like.
>>>>>>>>
>>>>>>>> I don't know that it is necessarily the processor that needs to
>>>>>>>> change it's processing rules but rather the conundrum of trying
>>>>>>>> to name two quite different subjects with the same URI.
>>>>>>>>
>>>>>>>> This is interesting, but it may be a more profitable discussion
>>>>>>>> on the LRDD list.
>>>>>>>>
>>>>>>>> I agree with your points, but the XRI-TC opted not add a special
>>>>>>>> attribute to subject.
>>>>>>>>
>>>>>>>> If people feel strongly that it is required, there is a public
>>>>>>>> comment period coming up on XRD.
>>>>>>>
>>>>>>> I would respectfully suggest that people look at a way of saying
>>>>>>> that an "XRD Subject" is also a "DNS host", without resorting to
>>>>>>> modifying the URI which identifies the XRD subject (or the
>>>>>>> identifier for the DNS host). Look at this as a problem in
>>>>>>> defining equivalence between two concepts which each have their
>>>>>>> own identifier.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> - johnk
>>>>>>>
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> John B.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2009-10-19, at 9:05 PM, John Kemp wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> On Oct 19, 2009, at 7:06 PM, John Bradley wrote:
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> LRDD is looking for a way to indicate that the XRD applies to
>>>>>>>>>> the DNS host as a whole rather than the URI. (For email, xmpp
>>>>>>>>>> etc)
>>>>>>>>>
>>>>>>>>> As I understand it, XRD describes the concept of a subject for
>>>>>>>>> the XRD document containing that subject identifier, and says
>>>>>>>>> that subjects are identified by URIs.
>>>>>>>>>
>>>>>>>>> As an identifier, a URI may be used to identify anything you
>>>>>>>>> want.
>>>>>>>>>
>>>>>>>>> In some cases (maybe a lot of them ;) the URI-as-identifier is
>>>>>>>>> also a URI-as-location-of-a-document. It would be easy for XRD
>>>>>>>>> to say that the subject URI MUST mean the URI at which the XRD
>>>>>>>>> document was found. But I believe it doesn't say that.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You could make all http:// URL with no path "Special" but that
>>>>>>>>>> stops people from using XRD to describe the URL itself.  At
>>>>>>>>>> least in the openID case that would not work for many people.
>>>>>>>>>
>>>>>>>>> A URI can identify anything, and in many cases, you can't tell
>>>>>>>>> what it identifies merely by looking at it - particularly when
>>>>>>>>> the URI is of the HTTP variety. In general, it is a bad idea to
>>>>>>>>> try.
>>>>>>>>>
>>>>>>>>> If the use-case is simply to allow an XRD (LRDD?) processor to
>>>>>>>>> know that the subject URI is one that indicates the XRD is for
>>>>>>>>> a "DNS host" (warning: I don't know what the use-case actually
>>>>>>>>> is), the XRD <Subject> could presumably be extended (with an
>>>>>>>>> "anyAttribute") to say exactly that, and additionally say that
>>>>>>>>> a <Subject type='host'/> URI MUST have no path component (or
>>>>>>>>> that if there is a path component, it must be ignored by the
>>>>>>>>> processor if the subject type is 'host'). If the Subject "host"
>>>>>>>>> might not be a valid URI, you'd need to relax the anyURI
>>>>>>>>> restriction on Subject to allow that.
>>>>>>>>>
>>>>>>>>> - johnk
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> John Bradley
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2009-10-19, at 7:43 PM, Santosh Rajan wrote:
>>>>>>>>>>
>>>>>>>>>>> What is the difference between "describing meta data of root
>>>>>>>>>>> http resource" and "describing meta data of the host" from a
>>>>>>>>>>> DNS point of view? None. They are the same. It can be
>>>>>>>>>>> described by a URI. "http://example.com".
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Oct 20, 2009 at 3:50 AM, Dirk Balfanz
>>>>>>>>>>> <balfanz at google.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>> XRD prescribes an (optional) Subject element, which is a URI.
>>>>>>>>>>> The URI in the Subject element is the URI of the resource
>>>>>>>>>>> that is described by this XRD.
>>>>>>>>>>>
>>>>>>>>>>> So,
>>>>>>>>>>>
>>>>>>>>>>> <Subject>http://example.com</Subject> // describes meta data
>>>>>>>>>>> of root http resource in example.com
>>>>>>>>>>> <Subject>http://example.com/</Subject> // describes meta data
>>>>>>>>>>> of root http resource in example.com
>>>>>>>>>>>
>>>>>>>>>>> which leaves us with the question of how to say "this
>>>>>>>>>>> document describes meta-data data for the host example.com".
>>>>>>>>>>> The current thinking for host-meta is to say something like
>>>>>>>>>>>
>>>>>>>>>>> <Host>example.com</Host> // describes meta-data of host
>>>>>>>>>>> example.com
>>>>>>>>>>>
>>>>>>>>>>> where the Host element is a string, not a URI. For some
>>>>>>>>>>> background, see
>>>>>>>>>>> http://lists.oasis-open.org/archives/xri/200908/msg00127.html
>>>>>>>>>>> and responses.
>>>>>>>>>>>
>>>>>>>>>>> Regarding civility: all-caps is not very polite. calling
>>>>>>>>>>> people idiots is not very polite (well, I guess you merely
>>>>>>>>>>> implied it). using lots of exclamation marks is not very
>>>>>>>>>>> polite.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Dirk.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Oct 19, 2009 at 3:00 PM, Santosh Rajan
>>>>>>>>>>> <santrajan at gmail.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>> Hi John,
>>>>>>>>>>> Let me get this strait here. I am unable to participate in
>>>>>>>>>>> the OASIS discussions because I haven't figured the process
>>>>>>>>>>> yet. And in any case all this has a bearing on OpenID, (it is
>>>>>>>>>>> the no 1 use case).
>>>>>>>>>>> What you are saying is
>>>>>>>>>>> 1) The host-meta will (MUST) have a <Subject> Element which
>>>>>>>>>>> will be the domain URL of the host. There will be no <Host>
>>>>>>>>>>> element instead.
>>>>>>>>>>> 2) (This is not something you have said explicitly) . All
>>>>>>>>>>> XRD's including host-meta "MUST" have "1" <Subject> element
>>>>>>>>>>> as an immediate child element of the XRD Root whose value is
>>>>>>>>>>> a URI describing the subject of the XRD.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Oct 20, 2009 at 3:04 AM, John Bradley <ve7jtb at ve7jtb.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>> Santosh,
>>>>>>>>>>>
>>>>>>>>>>> That was a thread on the use of signing elements in <Link>
>>>>>>>>>>> elements.
>>>>>>>>>>>
>>>>>>>>>>> Dirk's use of <Host> in his example XRD is not valid XRD
>>>>>>>>>>> syntax.
>>>>>>>>>>>
>>>>>>>>>>> It wasn't commented on because it was not the topic of the
>>>>>>>>>>> email thread.
>>>>>>>>>>>
>>>>>>>>>>> If you have comments on the XRD spec.
>>>>>>>>>>>
>>>>>>>>>>> http://www.oasis-open.org/committees/download.php/34724/xrd-1.0-wd09.html
>>>>>>>>>>>
>>>>>>>>>>> You are welcome to submit them through the formal process.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> John Bradley
>>>>>>>>>>>
>>>>>>>>>>> On 2009-10-19, at 5:51 PM, Santosh Rajan wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi John,
>>>>>>>>>>> The last time I saw an example of an XRD host-meta is here on
>>>>>>>>>>> 15th Oct here
>>>>>>>>>>> http://lists.oasis-open.org/archives/xri/200910/msg00055.html
>>>>>>>>>>>
>>>>>>>>>>> It has a <Host> instead of <Subject>. If you are saying that
>>>>>>>>>>> it is not part
>>>>>>>>>>> of the XRD spec and it is part of the host-meta spec, it
>>>>>>>>>>> still doesnt change
>>>>>>>>>>> my argument. As an end-user of the the discovery mechanism
>>>>>>>>>>> the effect is
>>>>>>>>>>> still the same for me.
>>>>>>>>>>>
>>>>>>>>>>> You say you have a hard time following me! Isn't it a case of
>>>>>>>>>>> the pot
>>>>>>>>>>> calling the kettle black? How many people are going to follow
>>>>>>>>>>> what you have
>>>>>>>>>>> said bellow. I will only quote one sentence you have written
>>>>>>>>>>> and ignore the
>>>>>>>>>>> rest.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> "The Subject of a XRD is the <Subject> of the XRD there can
>>>>>>>>>>> be 0 or 1
>>>>>>>>>>> in an XRD."
>>>>>>>>>>>
>>>>>>>>>>> That is exactly what you said. Now tell me how can there be a
>>>>>>>>>>> "0" <Subject>
>>>>>>>>>>> for an XRD. What meaning does an XRD have with "0" <Subject>?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> John Bradley-9 wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Santosh,
>>>>>>>>>>>
>>>>>>>>>>> I am having a hard time following your point.
>>>>>>>>>>>
>>>>>>>>>>> This is the current draft of the XRD spec.
>>>>>>>>>>> http://www.oasis-open.org/committees/download.php/34724/xrd-1.0-wd09.html
>>>>>>>>>>>
>>>>>>>>>>> There is no <Host>  element in the spec.
>>>>>>>>>>>
>>>>>>>>>>> The Subject of a XRD is the <Subject> of the XRD there can be
>>>>>>>>>>> 0 or 1
>>>>>>>>>>> in an XRD.
>>>>>>>>>>>
>>>>>>>>>>> HostMeta is a spec that uses the OASIS XRD spec.
>>>>>>>>>>>
>>>>>>>>>>> I know that they want to have what is essentially an abstract
>>>>>>>>>>> Subject.
>>>>>>>>>>>
>>>>>>>>>>> ie one that is about the host and not the URI.
>>>>>>>>>>>
>>>>>>>>>>> This is a URL problem and not an XRI one.
>>>>>>>>>>>
>>>>>>>>>>> Any number of wars have been fought over how to represent  
>>>>>>>>>>> non-
>>>>>>>>>>> information resources with URI.
>>>>>>>>>>>
>>>>>>>>>>> We did give the group working on host-meta as a itef spec
>>>>>>>>>>> some options
>>>>>>>>>>> on how they might do that.
>>>>>>>>>>>
>>>>>>>>>>> Using the DNS scheme or a URI fragment are all
>>>>>>>>>>> possibilities.  I don't
>>>>>>>>>>> know if they have come to a conclusion.   Whatever they
>>>>>>>>>>> decide someone
>>>>>>>>>>> will be unhappy if history is anything to go by on this  
>>>>>>>>>>> topic.
>>>>>>>>>>>
>>>>>>>>>>> There is a public review period for XRD coming up and a
>>>>>>>>>>> process for
>>>>>>>>>>> you to make formal submissions if you want to have input but
>>>>>>>>>>> not join
>>>>>>>>>>> the TC.
>>>>>>>>>>>
>>>>>>>>>>> John B.
>>>>>>>>>>>
>>>>>>>>>>> On 2009-10-19, at 3:27 PM, Santosh Rajan wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is an Open Challenge i am sending to the webfinger, XRD
>>>>>>>>>>> forums.
>>>>>>>>>>> These
>>>>>>>>>>> guys really think I am an Idiot. "Maybe I am". "BUT I AM NOT
>>>>>>>>>>> GOING
>>>>>>>>>>> DOWN
>>>>>>>>>>> WITHOUT A FIGHT".
>>>>>>>>>>>
>>>>>>>>>>> Really, I really don't know. Let us hear the arguments they
>>>>>>>>>>> give.
>>>>>>>>>>> Maybe i am
>>>>>>>>>>> a brainless stupid, that is why i feel all of them are
>>>>>>>>>>> hollow. But
>>>>>>>>>>> let them
>>>>>>>>>>> prove I am stupid. "IF THEY CAN", IF they can, we will hand
>>>>>>>>>>> it to
>>>>>>>>>>> them, "THE
>>>>>>>>>>> IDENTITY OSCAR".
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi All,I know you guys don't like to hear from me. I have
>>>>>>>>>>> been told
>>>>>>>>>>> so much.
>>>>>>>>>>> By your moderators. That people on this forum are not "Happy"
>>>>>>>>>>> to
>>>>>>>>>>> hear from
>>>>>>>>>>> me.
>>>>>>>>>>> Like it or "NOT" you are going to hear from me. I am not sure
>>>>>>>>>>> if
>>>>>>>>>>> this post
>>>>>>>>>>> of mine will be allowed to be published. But let us see.
>>>>>>>>>>> I have so many grouses with "XRD" and today I am going to
>>>>>>>>>>> start with
>>>>>>>>>>> my
>>>>>>>>>>> first grouse. Since WebFinger by definition is going to
>>>>>>>>>>> follow XRD,
>>>>>>>>>>> don't
>>>>>>>>>>> argue with me about webfinger. Lets talk about XRD to start
>>>>>>>>>>> with me.
>>>>>>>>>>> I am throwing a challenge to all the XRD guys. Prove to me
>>>>>>>>>>> that the
>>>>>>>>>>> <Subject> of an XRD host-meta document has to be <Host>
>>>>>>>>>>> instead of
>>>>>>>>>>> <Subject>. If you "smart" guys can prove this to me, I will
>>>>>>>>>>> agree
>>>>>>>>>>> that "I am
>>>>>>>>>>> a complete Idiot". If "NOT" all of you web fingerer's and
>>>>>>>>>>> XRD's are
>>>>>>>>>>> Idiots!!!!
>>>>>>>>>>>
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>> Santosh Rajan
>>>>>>>>>>> http://santrajan.blogspot.com http://santrajan.blogspot.com
>>>>>>>>>>> -- 
>>>>>>>>>>> View this message in context:
>>>>>>>>>>> http://www.nabble.com/Open-Challenge-to-webfinger-and-XRD-tp25963216p25963216.html
>>>>>>>>>>> Sent from the OpenID - General mailing list archive at
>>>>>>>>>>> Nabble.com
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> general mailing list
>>>>>>>>>>> general at lists.openid.net
>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> general mailing list
>>>>>>>>>>> general at lists.openid.net
>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>> Santosh Rajan
>>>>>>>>>>> http://santrajan.blogspot.com http://santrajan.blogspot.com
>>>>>>>>>>> -- 
>>>>>>>>>>> View this message in context:
>>>>>>>>>>> http://www.nabble.com/Open-Challenge-to-webfinger-and-XRD-tp25963216p25965303.html
>>>>>>>>>>>
>>>>>>>>>>> Sent from the OpenID - General mailing list archive at
>>>>>>>>>>> Nabble.com
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> general mailing list
>>>>>>>>>>> general at lists.openid.net
>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> http://hi.im/santosh
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> general mailing list
>>>>>>>>>>> general at lists.openid.net
>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> http://hi.im/santosh
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> general mailing list
>>>>>>>>>> general at lists.openid.net
>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>
>>
>> -----
>>
>> Santosh Rajan
>> http://santrajan.blogspot.com http://santrajan.blogspot.com
>> -- 
>> View this message in context:
>> http://www.nabble.com/Open-Challenge-to-webfinger-and-XRD-tp25963216p25976926.html
>> Sent from the OpenID - General mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> general mailing list
>> general at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-general
> 
> 
>  
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
> 
> 

-- 
View this message in context: http://www.nabble.com/Open-Challenge-to-webfinger-and-XRD-tp25963216p26035412.html
Sent from the OpenID - General mailing list archive at Nabble.com.

More information about the general mailing list