[OpenID] host-meta and "acct:"

Sat Oct 31 21:45:57 UTC 2009

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