[OpenID] host-meta and "acct:"

Santosh Rajan santrajan at gmail.com
Fri Nov 6 15:54:08 UTC 2009


Hey John,
I was just kidding Shade about the "+1". You can give any no of +1's to
Shade and I couldn't agree with you more. I know you guys are working hard
on this,and I have great respect for the work you are doing.
It is just that I have a strong feeling that something has gone wrong
somewhere. Things just don't look right to me. Especially when it comes to
the "Subject" Element.
Looking a the whole thing positively, it is better that these kinds of
arguments happen at this stage (draft stage) than after the 1.0 release. I
am sure you will agree with me on this.
Thanks
Santosh


On Fri, Nov 6, 2009 at 9:11 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

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


-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091106/aff5d581/attachment.htm>


More information about the general mailing list