[OpenID] host-meta and "acct:"

Sat Nov 7 14:11:32 UTC 2009

If it is wrong then what is right? Or what is an XRD?

On Sat, Nov 7, 2009 at 7:27 PM, Nat <sakimura at gmail.com> wrote:

> This definition is plainly wrong. You can create a profile of XRD like that
> for your application/use cases though.
>
> =nat at San Francisco via iPhone
>
> On 2009/11/07, at 5:23, Santosh Rajan <santrajan at gmail.com> wrote:
>
> The problem is that there is no clear definition of what an XRD is.
>
> My definition for a XRD; A XML Resource Descriptor that can resolved by a
> URI.
>
> The <Subject> of the XRD is the URI used to resolve it. This is consistent
> with all the use cases I have seen so far. It also makes sense for a URI
> Identifier to resolve to its descriptor.
>
> If we agree on the two definitions above then it is clear that the
> <Subject> of the host-meta is the URI used to resolve it. eg.
> <Subject> <http://example.com/.well-known/host-meta>
> http://example.com/.well-known/host-meta</Subject>
>
>
> On Fri, Nov 6, 2009 at 11:58 PM, John Kemp < <john at jkemp.net>
> john at jkemp.net> wrote:
>
>> On Nov 6, 2009, at 9:42 AM, John Panzer wrote:
>>
>>  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=en>
>>> https://docs.google.com/a/johnpanzer.com/Doc?docid=0AZojn6fzr_tFZGRqNjhzcXZfOWY1cXA3emY5&hl=en for
>>> 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.
>>>
>>
>> Indeed, and that is a solution to the problem of how to represent a non
>> (or not easily)-URI-addressable thing in an element which accepts only URIs.
>>
>> One alternative solution would be to:
>>
>> i) Allow both URI and non-URI content in the Subject XML element (define
>> Subject to be a string, and then restrict it in various profiles of XRD)
>> ii) Allow the Subject element to carry a semantic hint to those profiling
>> XRD as to which type of Subject is 'meant' by the content of the element.
>>
>> Another solution would be to accept that the URI in the Subject is ONLY an
>> identifier, and not a locator (of the Subject resource itself anyway). A
>> strong hint there would be to use URNs (such as tag: [1]) instead of HTTP
>> URIs. Such URIs can define their own resolution mechanisms, independent of
>> the naming scheme.
>>
>> Don't get me wrong, I think having an optional Subject is a pragmatic
>> solution. I just think it de-values XRD itself to suggest that an optional
>> Subject is an appropriate extension point, since (I suspect) the concept of
>> Subject is shared by all users of XRD whether or not the element itself
>> appears in the document.
>>
>> - johnk
>>
>> [1] <http://www.faqs.org/rfcs/rfc4151.html>
>> http://www.faqs.org/rfcs/rfc4151.html
>>
>>
>>
>>> 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>
>>> 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>
>>>> 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>
>>>>> 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>http://hi.im/santosh
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> general mailing list
>>>>>  <general at lists.openid.net>general at lists.openid.net
>>>>>  <http://lists.openid.net/mailman/listinfo/openid-general>
>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  <http://hi.im/santosh>http://hi.im/santosh
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>>  <general at lists.openid.net>general at lists.openid.net
>>>  <http://lists.openid.net/mailman/listinfo/openid-general>
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>>  <general at lists.openid.net>general at lists.openid.net
>>>  <http://lists.openid.net/mailman/listinfo/openid-general>
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>
>> _______________________________________________
>> general mailing list
>>  <general at lists.openid.net>general at lists.openid.net
>>  <http://lists.openid.net/mailman/listinfo/openid-general>
>> http://lists.openid.net/mailman/listinfo/openid-general
>>
>
>
>
> --
> <http://hi.im/santosh>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/20091107/31455e42/attachment.htm>