[OpenID] host-meta and "acct:"

Sun Nov 1 14:24:27 UTC 2009

Hehe Peter, another worm out of the XRD can. Why does XRD 1.0 need to define
a xml:id for XRD, given that it is the root element of the XRD, there can
only be one?
ROTFL if anyone has forgotten this acronym, it is "Rolling ON The Floor
Laughing".

On Sun, Nov 1, 2009 at 3:15 AM, Peter Williams <home_pw at msn.com> wrote:

>
> Im tempted to say that the xml:id they used (in the abandoned initiative) a
> relic of the days when folks were still thinking about simplifing a
> sequence
> of XRDs, and the file recovered might need the locator to point out a
> particular one of several i the file (by denoting the xml:id on the XRD
> level element.)
>
> Be interesting to see if LRDD or webfinger has a non HTTP locator concept
> (based on that kind of xpointer-like URI). presumably it would only point
> to
> such as a "see also other XRD" location, rather than point out a
> sub-element
> (such as a particular link). This could retain from the XRI days something
> of what used to be attached to the old ref (vs redirect) signal - and be
> used to the same management/authority transfer issues.
>
>
>
> Peter Williams wrote:
> >
> > I compared the work product you referenced with
> > http://xrds-simple.net/core/1.0/ (an abandoned work).
> >
> > Just note the sheer difference in writing style! While staying within the
> > scope of the IETF work item, the I-D will ideally go back to the mixed
> > description/specification style of the pro-genitor work.
> >
> > Once one becomes a formal WG chair, it's tempting to be so concise and
> > embue such logical correctness into English terms while specification
> > writing that it ends up sounding like one of those immortal OSI standards
> > from CCITT/ISO - written in a technical language that only 3 people in
> the
> > world could speak natively. And they all sat on the committee.
> >
> > The earlier work I cited does address an issue I dont understand - once
> > cast into current XRD 1.0 and host-meta terms. See
> > http://xrds-simple.net/core/1.0/#go_fetch (last paragraph). The topic is
> > refering to elements of an XRD, given the locator url and its fragments.
> >
> > The problem I had initially with your criticism, if you recall, had
> > ignorant ol' me focussing on the XRD.Link.Subject (vs XRD.Subject). I
> > wanted the URI (with fragment) to refer to a particular link element, in
> > order that the metadata in the link acted as descriptor for that (naming)
> > URI. This seemed to align XRD and openid identifiers with semweb. This
> > would allow us all to observe only 1 religion about names and addresses.
> >
> > In the abandoned work, fragments on (I think) "returned" locators in such
> > as the HTTP Response X-XRDS-Locator URI (or a meta's http-equiv content
> > value) could have fragments, which might have pointed to a particular
> > element link within the XRD, once retrieved. The fragments had seemingly
> > special relationship to the xml:id value (an XML construct) on the link
> > element rather than the link.subject (an XRD construct) in the link
> > markup.
> >
> > For my part, I now struggle on that topic with the current proposal: what
> > concepts got dropped or recast in new form? Things start to swirl.
> >
> > Was the XRDS-Locator different to a 301, 302 or 303, in some subtle way?
> > Was there some inner subtlety about using xml:id (given its relationship
> > to DOM3 trees)? Was there a hookup with issues of xml dsig signing (and
> > its default resolvers)? Did the whole issue just disappear? if so, why
> and
> > what cost?
> >
> > Some of this context is what the IETF I-D needs to bring back, rather
> than
> > be so parsimonious and doctrinal about domains are XRi-like authorities,
> > authorities in URI schemes are an embodiment of XRI-like authorities,
> > domains and domain-names have a mystical relationships to authority
> > fields scheme (and thence to the authorites governing an RDF graph
> > node)..... cocnepts that only the higher initiates in the identity gang
> > can comprehend.
> >
> >
> >
> >
> >
> >
> >
> > http://xrds-simple.net/core/1.0/
> >
> >
> >
> >
> >
> > Santosh Rajan wrote:
> >>
> >> http://www.ietf.org/id/draft-hammer-hostmeta-01.txt
> >>
> >> If you have read the spec above, you will wonder where did the "acct:"
> >> scheme come from. It came from webfinger. The host-meta spec has been
> >> work in progress for a while now. Its predecessor was the "site-meta"
> >> spec. The idea of webfinger came later, in may 2009,and the idea of
> >> "acct:" about two months back. Given that webfinger is to follow
> >> host-meta, the question is "How come host-meta is following
> >> webfinger?".
> >>
> >> Think about it. There is an obvious attempt to legitimize the "acct:"
> >> scheme here. That is not a bad idea. I like it actually. Consider
> >> this. If I type "acct:santrajan at gmail.com <acct%3Asantrajan at gmail.com>
> >> <acct%3Asantrajan at gmail.com <acct%253Asantrajan at gmail.com>>" into my
> browser location bar, my browser
> >> would retrieve my XRD. Now this is an extreme example. But I hope you
> >> get the idea. If not please ask me.
> >>
> >> Unfortunately I have a problem with this idea, even though I like it,
> >> this is not the way to do it. The problem is that if you want to
> >> legitimize "acct:" you need to be a software engineer contortionist.
> >> You need to "Reject" Subject from the host-meta, and you need to add
> >> "Scope" into the host-meta.
> >>
> >> My contention is that if you really want to this, (and I like the
> >> idea), let us get all the DNS, w3c folk on board and do it. Doing it
> >> via the "backdoor" is going to cause more harm to the "identity
> >> movement" than good.
> >>
> >>
> >> --
> >> http://hi.im/santosh
> >>
> >> _______________________________________________
> >> general mailing list
> >> general at lists.openid.net
> >> http://lists.openid.net/mailman/listinfo/openid-general
> >>
> >>
> >> -----
> >>
> >> Santosh Rajan
> >> http://santrajan.blogspot.com
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/host-meta-and-%22acct%3A%22-tp26079872p26146197.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091101/689cd4c9/attachment-0001.htm>