Backwards compatibility

Recordon, David drecordon at verisign.com
Fri Sep 22 18:01:51 UTC 2006


Like Josh, I believe it is important to maintain number 1.

My intention would be that someone could read OpenID Authentication 2.0,
never having read 1.1, implement a library, and have it work with an
implementation from someone who has only 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 the number of deployments
is relatively small, we should do everything possible to maintain
compatibility with them.

--David 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Josh Hoyt
Sent: Wednesday, September 20, 2006 1:31 PM
To: specs at 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 I can see:

1. Messages that are valid OpenID 2.0 messages are also valid OpenID
1.1 messages

2. It is possible for implementations to differentiate between OpenID
1.1 and 2.0 and to construct appropriate messages. In essence, it's a
different protocol.

I've been focused on maintaining (1). How do you see it?

Josh
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs




More information about the specs mailing list