[OpenID] Open Challenge to webfinger and XRD
John Bradley
ve7jtb at ve7jtb.com
Sat Oct 24 12:10:14 UTC 2009
Peter,
The thread was in the context of Subject not Link.
My point was that XRD Subjects can reference URL that are about things
that can be retrieved via GET as byte streams (Information Resources)
and things that cant like people (non information resources)
I think
That using a URI as a subject is not an undue burden.
I suppose that you could add fragments to URI in Link elements.
However there is nothing special in XRD about processing fragments.
If a protocol using XRD wanted to make use of fragments to
differentiate between elements in a linked XRD, FOAF, or other RDF
document there is nothing to stop them.
XRD is a replacement for what people thought of as the XRDS document.
XRI and XRDS-Simple had quite different ways of processing XRDS
documents.
We are hoping that those processing differences will be minimized
between LRDD/WebFinger's use of XRD and XRI's use of XRD.
The Link model in XRD is quite different from the Service model in
XRDS, so it will take some time for everyone to come up to speed.
XRD is not part of openID yet, it is not even part of a official
proposal to be part of openID yet.
In fact there is no currently chartered WG for that.
Yes there will be.
When openID discovery is being worked on again XRD 1.0 and WebFinger,
XRI, and whatever spec Santosh develops can all be considered. That
isn't likely to happen overnight.
We are working on a XRI 3.0 spec that will use XRD 1.0, you are
welcome to join OASIS and contribute to that work if you can abide by
the IPR policy . Webfinger at IETF is also open to participation.
I don't know what IPR regime Santosh will be working under.
Regards
John Bradley
On 2009-10-23, at 10:36 PM, home_pw wrote:
>
> 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.
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091024/7888c840/attachment-0001.bin>
More information about the general
mailing list