[OpenID] host-meta and "acct:"

Fri Nov 6 17:42:35 UTC 2009

We have one compelling use case already where the existing <Subject> doesn't
work: host-meta is "about" a host, and there is no URI scheme to represent
Hosts (see IIW notes at
https://docs.google.com/a/johnpanzer.com/Doc?docid=0AZojn6fzr_tFZGRqNjhzcXZfOWY1cXA3emY5&hl=enfor
alternatives considered). The simplest thing that anyone can come up
with for this use case that doesn't run into tripwires or pitfalls is a
separate element, <hm:Host>, that contains a hostname.

Of course this element is only going to be recognized by host-meta-aware
processors.  And that's fine, because this is only valid for host-meta.  But
if XRD were required to have <Subject>, host-meta would be required to
define some "dummy" Subject to stick in there and it would be stupid.

Now multiply this by N, where N is the number of things that may want to
leverage XRD.  I believe the least bad solution is to leave the XML
<Subject> element optional, while making it clear that there _is_ a
conceptual subject for every XRD.

(I really wish we had left atom:id as a SHOULD instead of a MUST in Atom.
 We immediately turned around and discovered a use case where a required
atom:id causes problems and confusion -- creating new Atom entries via
POST.)

On Fri, Nov 6, 2009 at 8:12 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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
>
>
>
>
> _______________________________________________
> 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/3b67f656/attachment.htm>