[OpenID] host-meta and "acct:"

[John Bradley]

I could give Shade another +1.

I do think that he is clearly articulating the perspective of a  
majority of people who donate there time to create specs like XRD.

Some have said that our attempt to make XRDS too specific to the  
requirements of XRI caused it to fork into XRDS-Simple.

We are trying to learn from our past, along with the people who forked  
XRD for legitimate reasons to accommodate there use case.

We are attempting to produce a spec that can accommodate new things  
like WebFinger without causing a fork in XRD every time  someone comes  
up with a new idea they want to try out.

Profiles of XRD  will live or die based on there community adoption.

Profiles of XRD are free to make Subject required.  Profiles of XRD  
can define there own namespaces and extend XRD as they like.

You can make formal comments through the OASIS feedback process if you  
have a problem with that.

We will consider all feedback before XRD is finalized.

Regards
John Bradley
On 2009-11-06, at 7:19 AM, Santosh Rajan wrote:

> Hehe Shade, you are not going to get a "+1" for this one. Somebody  
> did give you one for an earlier post!
>
> On Fri, Nov 6, 2009 at 8:40 PM, SitG Admin <sysadmin at shadowsinthegarden.com 
> > wrote:
> 3) XRD with <Host> instead of <Subject>
>
> Hypothetical, but plausible, scenario:
>
> A developer realizes they need to indicate something different from  
> Subject, but that they may need Subject later on. To avoid that  
> future conflict (where they would find themselves forced to declare  
> ActualSubject instead of just using Subject!), they use Host  
> instead. Communicating this to the 3rd parties they deal with, and  
> getting them to modify their own code to interop, is up to the  
> developer :)
>
>
> 4) Someone might come along and decide lets have <Title> instead of  
> <Subject>
>
> They won't get to make a unilateral decision, though. If they can't  
> present compelling reasons why anyone ought to switch from using  
> Subject to using Title, they'll probably be ignored ;)
>
>
> 5) Anyone can have anything else instead of <Subject>
>
> If they want to, sure. How effective it is may depend on how many  
> others they can get to accomodate their approach - and it may depend  
> on how many others *don't*. Remember that security through obscurity  
> actually *works*, in some cases; if they have an undocumented,  
> hexadeximal-encoded, (weakly) encrypted Subject line labeled as  
> another field, 99% of 3rd parties (having no reason to even  
> *attempt* to figure out what Subject line IF ANY there is) will not  
> pursue that any further.
>
>
> Is this your idea of future compatibility?
> Why is it so difficult for people to see that this whole thing is  
> leading to a mess?
>
> We're blinded by this whole idea of "majority consensus".
>
> When you think that the majority's interests are in the actual  
> *usefulness* of each spec, as defined by how many 3rd parties can be  
> persuaded to practice the same methods (it's all about  
> interoperability), your self-interest becomes self-limiting (it's  
> all about enlightened self-interest): you don't want to exert too  
> MUCH influence, making something perfect for YOU, because then it'll  
> be too much trouble for everyone *else* (the Way of D'Shai is all  
> about *balance*). The more accepting you can be of those who are  
> different from you (it's all about tolerance), the more likely you  
> are to receive cooperation instead of competition (Microsoft called  
> this "Embrace and Extend"; pay it forward).
>
> -Shade
>
>
>
> -- 
> http://hi.im/santosh
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091106/2236bd2a/attachment-0001.htm>
-------------- 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/20091106/2236bd2a/attachment-0001.bin>