OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Aligning XRD with Link (Header/Element)


We might be able to find out for the proxy resolver at xri.net.  I think it will be mostly xrds+xml.

We cant tell for things that are running there own resolver libs.  openid4java and others resolve xri directly with out the proxy.

Depending on how many changes there are we may need  a separate authority service for the new format.

That way a resolver could ask a XRI authority server for ether a new or old format.  
In XRI 2.0 it just makes a query for the next subsegment which is almost always an XRD unless lookahead resolution is used for multiple segments in a single query.

To keep them separate for URLs the new XRD spec will need to not support the Yadis discovery mechanisms.

John B.
On 26-Nov-08, at 6:30 PM, Eran Hammer-Lahav wrote:

Is there a way to find out how many direct resolver requests for xrd+xml are received vs. xrds+xml?

EHL


On 11/26/08 5:57 PM, "Drummond Reed" <drummond.reed@cordance.net> wrote:

+1. The migration path is a little more challenging for XRI authorities
since they are asked directly for either XRD or XRDS documents today, and
those calls won't change. However it should be manageable and is ultimately
in everyone's best interest.

=Drummond

> -----Original Message-----
> From: Breno de Medeiros [mailto:breno@google.com]
> Sent: Wednesday, November 26, 2008 5:08 PM
> To: John Bradley
> Cc: David Recordon; Brian Eaton; Nika Jones; OASIS XRI TC; David Orchard;
> Michael Jones
> Subject: Re: [xri] Aligning XRD with Link (Header/Element)
>
> If the new XRD format is discovered at /site-meta and through Link
> (either HTTP headers or html) and the old is discovered through
> X-XRDS-Location and <meta> tags then it is possible to let them
> co-exist for a while. I do not think OPs would mind hosting these two
> files if there was a commitment to deprecate and eventually drop Yadis
> from the OpenID spec.
>
> At this point, large OPs like Yahoo! and Google cannot (note that I am
> not saying will not, I am saying that they cannot afford to) be fully
> Yadis-compliant. So a path to eventually drop Yadis would be welcome.
> My guess is that there will be a good incentive to add support to the
> new XRD-style discovery in new libraries because as soon as it is
> available, the number of use cases that cannot be supported via Yadis
> will grow fast.
>
> On Tue, Nov 25, 2008 at 4:52 PM, John Bradley <jbradley@mac.com> wrote:
> > David,
> >
> > I agree that we should move to support XRD in 2.1.  However even if it
> > doesn't make it into the 2.1 spec XRD needs to take into account that
> OP's
> > are going to have to support both for some period of time if oAuth
> discovery
> > and other things start using the new format.
> >
> > I would like to find a way that the the New XRD can still be parsed by
> old
> > software like existing openID libraries at least to find the openID
> service.
> >   I have a hard time imagining that OP's are going to maintain two
> separate
> > XRD/S documents for each user.
> >
> >
> > If all someone needed to do was wrap a XRD in a XRDS to make the current
> > services parsable by Yadis that would make me happy.  That is something
> that
> > a OP could programatically do.
> >
> > Yes as has been discussed openID 2.1 might perform XRD discovery and
> then
> > Yadis.  Remember XRD itself will not have anything to say about openID
> > specific rel links in the HTML if meta-data discovery fails.
> >
> > I can't see getting rid of Yadis, but it may become a profile of XRD
> over
> > time.  It will always need to cover the openID specific things.
> >
> > Our current discovery and what ever we migrate too are going to have to
> > coexist for some time.
> >
> > John B.
> >
> > On 25-Nov-08, at 1:48 PM, David Recordon wrote:
> >
> >> We should be working to include XRD in 2.1, it is in the scope for the
> >> working group, but realistically if XRD either takes much longer than
> the
> >> rest of the 2.1 scope or is too divergent than it might slip until a
> later
> >> version or something.
> >>
> >> On Tue, Nov 25, 2008 at 1:45 PM, Breno de Medeiros <breno@google.com>
> >> wrote:
> >> Well, if we can't include XRD in the scope for OpenID 2.1, then we
> >> should consider setting up another WG to look at XRD. Otherwise, XRD
> >> discovery will happen without a coherent voice from the OpenID
> >> community.
> >>
> >> On Tue, Nov 25, 2008 at 1:40 PM, David Recordon <recordond@gmail.com>
> >> wrote:
> >> > Yes, I need to spend some time on getting the OpenID 2.1 WG up and
> >> > running.
> >> > That said, if this work isn't done in time (or so different that it
> >> > doesn't
> >> > make sense to us) then we'll most likely not include it for 2.1.
> >> >
> >> > On Tue, Nov 25, 2008 at 1:34 PM, Breno de Medeiros <breno@google.com>
> >> > wrote:
> >> >>
> >> >> Yes, we need the IPR for the OpenID 2.1 working group in place (and
> >> >> covering the use of XRD for discovery) to make sure that we can
> >> >> harmonize these two efforts.
> >> >>
> >> >> On Tue, Nov 25, 2008 at 1:30 PM, Brian Eaton <beaton@google.com>
> wrote:
> >> >> > On Tue, Nov 25, 2008 at 12:57 PM, John Bradley <jbradley@mac.com>
> >> >> > wrote:
> >> >> >> Adoption is huge when you consider that this also impacts the
> >> >> >> existing
> >> >> >> base
> >> >> >> of URI openIDs as well.
> >> >> >> Telling openID providers that every user will have to have an old
> >> >> >> style
> >> >> >> XRDS
> >> >> >> and a new style XRD as separate documents is going to be a hard
> >> >> >> sell.
> >> >> >> This may be the best time but we need to keep in mind that real
> >> >> >> people
> >> >> >> are
> >> >> >> using this now and we need to transition them in some plausible
> way.
> >> >> >
> >> >> > I agree, we need a transition plan.  Tying the XRD syntax change
> to
> >> >> > OpenID 2.1 might work.
> >> >> >
> >> >> > ------------------------------------------------------------------
> ---
> >> >> > To unsubscribe from this mail list, you must leave the OASIS TC
> that
> >> >> > generates this mail.  Follow this link to all your TCs in OASIS
> at:
> >> >> >
> >> >> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> --Breno
> >> >>
> >> >> +1 (650) 214-1007 desk
> >> >> +1 (408) 212-0135 (Grand Central)
> >> >> MTV-41-3 : 383-A
> >> >> PST (GMT-8) / PDT(GMT-7)
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> --Breno
> >>
> >> +1 (650) 214-1007 desk
> >> +1 (408) 212-0135 (Grand Central)
> >> MTV-41-3 : 383-A
> >> PST (GMT-8) / PDT(GMT-7)
> >>
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]