[OpenID] host-meta and "acct:"
John Bradley
ve7jtb at ve7jtb.com
Fri Nov 6 16:12:59 UTC 2009
Santosh,
It is too bad that you couldn't make IIW. I suspect we could have
made better progress on understanding in person rather than iterating
on the list.
Yes it is better to air these issues before specs are finalized.
At least in OASIS that is why all of the TC work is done in public
and we have strict rules about public review periods and and answering
all formal feedback before a spec can go to a final vote of all the
OASIS members.
I am personally trying to devote more time to the IETF specs like
WebFinger and LARDD that are profiling XRD so that I can better
understand there reasons for wanting to use elements other than Subject.
While I am currently of the opinion that Subject should not be
required in the XRD spec, that shouldn't be taken that I don't have
strong opinions about what happens in the profiles.
They are however different discussions, and I need to be mindful of
what hat I am wearing in what discussion.
Regards
John Bradley
On 2009-11-06, at 7:54 AM, Santosh Rajan wrote:
> 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/f164b5c1/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/f164b5c1/attachment-0001.bin>
More information about the general
mailing list