Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
n 25-Sep-06, at 6:43 PM, Brad Fitzpatrick wrote: > > Whereas changing message formats is a lot more verbose of a change > when it > comes to describing old vs. new specs. ok > > Anyway ... yeah, moving forward ... is anybody working on a test > suite? I thought that was LJ? ;-)

Re: Backwards compatibility

2006-09-25 Thread Brad Fitzpatrick
On Mon, 25 Sep 2006, Dick Hardt wrote: > Given there is so little difference between 1.1 and 2.0, and one of > them being support for extensions, I am confused > why you would not just support 2.0. You can do extensions with 1.1 too. It's just not really described well enough. But let me make i

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
On 25-Sep-06, at 5:41 PM, Brad Fitzpatrick wrote: > On Mon, 25 Sep 2006, Dick Hardt wrote: > >> So you would not support inames, > > LiveJournal would not. > >> Yadis, > > We already do! And will continue to improve that as spec changes. > >> nonces, > > Already do, via the Net::OpenID::* module

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
On 25-Sep-06, at 5:31 PM, Brad Fitzpatrick wrote: > On Mon, 25 Sep 2006, Dick Hardt wrote: > >> If this is the case (David Fuelling's summary) then backwards >> compatibility of the spec is not needed. If backwards compatibility >> is required, then the 2.0 spec ca

Re: Backwards compatibility

2006-09-25 Thread Brad Fitzpatrick
On Mon, 25 Sep 2006, Dick Hardt wrote: > So you would not support inames, LiveJournal would not. > Yadis, We already do! And will continue to improve that as spec changes. > nonces, Already do, via the Net::OpenID::* modules, which do it for me, in OpenID 1.x. > IdP-driven identifier select

Re: Backwards compatibility

2006-09-25 Thread Brad Fitzpatrick
On Mon, 25 Sep 2006, Dick Hardt wrote: > If this is the case (David Fuelling's summary) then backwards > compatibility of the spec is not needed. If backwards compatibility > is required, then the 2.0 spec can just say that 1.1 must also be > supported. > > Although the s

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
If this is the case (David Fuelling's summary) then backwards compatibility of the spec is not needed. If backwards compatibility is required, then the 2.0 spec can just say that 1.1 must also be supported. Although the spec may require systems to be backwards compatible, I would

RE: Backwards compatibility

2006-09-25 Thread Recordon, David
sages. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling Sent: Sunday, September 24, 2006 3:58 PM To: 'Josh Hoyt' Cc: specs@openid.net Subject: RE: Backwards compatibility Josh, Just a point of clarification -- As worded, yo

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
On 25-Sep-06, at 11:37 AM, Johannes Ernst wrote: > > On Sep 25, 2006, at 11:05, Dick Hardt wrote: > >> >> On 25-Sep-06, at 10:59 AM, Johannes Ernst wrote: >> >>> > I don't understand why we should make it hard (impossible?) to > use OpenID authentication with verbs other than POST. >>>

Re: Backwards compatibility

2006-09-25 Thread Johannes Ernst
On Sep 25, 2006, at 11:05, Dick Hardt wrote: On 25-Sep-06, at 10:59 AM, Johannes Ernst wrote: I don't understand why we should make it hard (impossible?) to use OpenID authentication with verbs other than POST. How would you propose OpenID use the other verbs? If there a mechanism to

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
On 25-Sep-06, at 10:59 AM, Johannes Ernst wrote: > >>> I don't understand why we should make it hard (impossible?) to >>> use OpenID authentication with verbs other than POST. >> >> How would you propose OpenID use the other verbs? > > If there a mechanism to authenticate an HTTP GET request (

Re: Backwards compatibility

2006-09-25 Thread Johannes Ernst
I don't understand why we should make it hard (impossible?) to use OpenID authentication with verbs other than POST. How would you propose OpenID use the other verbs? If there a mechanism to authenticate an HTTP GET request (as OpenID 1.1 provides, of course), use the exact same mechanis

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
>> I am not sure what advantage there is to using other verbs. Would >> you elaborate on the advantages? > > I'm not sure I understand this question. Are you asking why > standard HTTP has verbs other than POST? Or why things WebDav > increased the list further? no, I know why they have the

Re: Backwards compatibility

2006-09-25 Thread Johannes Ernst
On Sep 25, 2006, at 2:20, Dick Hardt wrote: On 21-Sep-06, at 11:15 PM, Johannes Ernst wrote: Just one specific question: On Sep 21, 2006, at 17:22, Dick Hardt wrote: Also, I thought OpenID 2.0 was moving to POST instead of GET, so that will likely cause some incompatibilities. I heard t

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
This >> means that in 2.0 we need to both continue making the conscious >> effort >> to only change what is required, as well as to mark things which have >> been deprecated though are still required in implementations for >> backwards compatibility. While I agree t

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
means that in 2.0 we need to both continue making the conscious effort > to only change what is required, as well as to mark things which have > been deprecated though are still required in implementations for > backwards compatibility. While I agree that the number of deployments >

Re: Backwards compatibility

2006-09-25 Thread Dick Hardt
On 21-Sep-06, at 11:15 PM, Johannes Ernst wrote: > Just one specific question: > > On Sep 21, 2006, at 17:22, Dick Hardt wrote: > >> Also, I thought OpenID 2.0 was moving to POST instead of GET, so that >> will likely cause some incompatibilities. > > I heard this before somewhere, but so far I c

RE: Backwards compatibility

2006-09-24 Thread David Fuelling
> To: specs@openid.net > Subject: Backwards compatibility > > When making and evaluating proposals, there have been many references > to backwards compatibility. I'm not sure that everyone has the same > idea what it means to be backwards compatible. > > There are at

RE: Backwards compatibility

2006-09-22 Thread Brad Fitzpatrick
ly read 1.1 and not 2.0. This > means that in 2.0 we need to both continue making the conscious effort > to only change what is required, as well as to mark things which have > been deprecated though are still required in implementations for > backwards compatibility. While I agree that

RE: Backwards compatibility

2006-09-22 Thread Recordon, David
to both continue making the conscious effort to only change what is required, as well as to mark things which have been deprecated though are still required in implementations for backwards compatibility. While I agree that the number of deployments is relatively small, we should do everything

Re: Backwards compatibility

2006-09-21 Thread Johannes Ernst
Just one specific question: On Sep 21, 2006, at 17:22, Dick Hardt wrote: Also, I thought OpenID 2.0 was moving to POST instead of GET, so that will likely cause some incompatibilities. I heard this before somewhere, but so far I could not discern the reasoning for it, nor who actually propo

Re: Backwards compatibility

2006-09-21 Thread Dick Hardt
that supports OpenID Authentication 1.1 and 2.0. > > Is my assumption correct? > > And if so, how do others answer Josh's question? > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Josh Hoy

RE: Backwards compatibility

2006-09-20 Thread Drummond Reed
20, 2006 1:31 PM To: specs@openid.net Subject: Backwards compatibility When making and evaluating proposals, there have been many references to backwards compatibility. I'm not sure that everyone has the same idea what it means to be backwards compatible. There are at least two meanings that

Backwards compatibility

2006-09-20 Thread Josh Hoyt
When making and evaluating proposals, there have been many references to backwards compatibility. I'm not sure that everyone has the same idea what it means to be backwards compatible. There are at least two meanings that I can see: 1. Messages that are valid OpenID 2.0 messages are also