[OpenID] host-meta and "acct:"
Nat
sakimura at gmail.com
Sat Nov 7 13:57:57 UTC 2009
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</Subject>
>
>
> On Fri, Nov 6, 2009 at 11:58 PM, John Kemp <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
> 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
>
>
>
> 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
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
> _______________________________________________
> 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/20091107/18233be1/attachment-0001.htm>
More information about the general
mailing list