I added: Parameters sent without a value MUST be treated as if they were omitted from the request.
This should cover it. EHL From: Andrew Arnott [mailto:[email protected]] Sent: Tuesday, June 15, 2010 9:49 AM To: Eran Hammer-Lahav Cc: OAuth WG ([email protected]) Subject: Re: [OAUTH-WG] Clarification on whether arguments can contain empty values Thanks, Eran. I can live with that. Do you think it would be a good idea to state in the spec that parameter values may be empty? For instance for this one: expires_in OPTIONAL. The duration in seconds of the access token lifetime if an access token is included. Maybe I'm taking it to literally, but I read this to include "if the parameter is present, its value WILL be an integer". But if somewhere in the spec it said "all optional parameters may be present but empty", then that defeats by incorrect interpretation. Again, I can live with an email from you, but it might help other implementors who come along next year to get it right the first time if they're reminded in the spec that parameter values may be empty. At least it would have helped me a few years ago in the OpenID spec. :) -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Tue, Jun 15, 2010 at 9:43 AM, Eran Hammer-Lahav <[email protected]<mailto:[email protected]>> wrote: The best way to address this is to write more resilient servers. Servers should accept empty optional parameters. EHL From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Andrew Arnott Sent: Tuesday, June 15, 2010 6:56 AM To: OAuth WG ([email protected]<mailto:[email protected]>) Subject: [OAUTH-WG] Clarification on whether arguments can contain empty values Can we get some clarification into the spec as to whether optional parameters can be present but empty? Particularly parameters such as tokens that obviously cannot be meaningful when having an empty value. This was a muddy issue in the OpenID spec, where some implementations would include empty parameters rather than just omitting them, breaking other implementations that would expect that if the parameter is present it ought to have a meaningful value. My own vote: parameters must have valid values (non-empty) if they are present, unless they are opaque strings (like client state) that the remote party doesn't have to do anything but imitate back anyway. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
