The problem is centered on the definition of a client. If it is a service specific implementation which is merely using OAuth for access, there isn't any interop requirements other than making sure the client and server are compatible. But if the client is a general purpose OAuth library or generic client (e.g. CURL), then the MTI becomes critical for any real interop.
I don't have a strong prefernece here, but we should clearly define the client characteristics in this discussion since an OAuth client isn't usually similar to an HTTP client in its interop reality. I am not sure how to craft this language into spec form, but we might want to list such a MTI requirement in terms of a 'client designed to work across multiuple providers such as a general purpose library'. EHL ________________________________________ From: Stephen Farrell [stephen.farr...@cs.tcd.ie] Sent: Wednesday, November 02, 2011 1:45 PM To: John Bradley Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 So perhaps this is the interesting point of difference. On 11/02/2011 08:37 PM, John Bradley wrote: > It is up to the server to decide what formats it will support. With IETF protocols, its IETF consensus that decides this in almost all cases that affect interop and it is therefore not up to the specific server deployment admin what the server code will support. I think this case affects interop. and should be treated as for any other IETF protocol. Am I wrong? S _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
