On 2012-06-05 00:10, Mike Jones wrote:
The main point of my message was to point out that the working group has
not discussed the syntax for some the elements identified. I’m glad that
it now is.
Actually, the draft already contains or implies syntax restrictions for
more fields than you listed, Eran. Let me tackle each field individually
and provide rationale for the choice made and solicit working group
input on those where I believe there are open issues.
We already had syntax restrictions in place for *error*,
*error_description*, *error_uri*, *scope*, and *response_type* so I
won’t discuss those further.
The spec already included a syntax for *token_type*, and the ABNF
doesn’t deviate from it. The *grant_type* element is logically the same
kind of object as token_type, so it makes sense to use the same syntax.
I don’t see a case for having *expires_in* contain anything but 1*DIGIT,
so I don’t see that as being controversial.
For *redirect_uri*, since it is a URI, I believe that URI-reference
makes sense.
For *username* and *password*, the spec mandates that they be used with
HTTP Basic, thus implicitly restricting their legal values. (Per my
earlier response to Julian, RFC 2616 effectively limits these characters
to be the ISO-8859-1 characters other than control characters but
including LWS characters.) HTTP Basic further restricts the username
field to not contain a colon (‘:’). In short, I believe that the OAuth
core already implicitly contains the specified character set restrictions.
RFC 2617 is very vague on this, and implementations disagree.
Since *client_id* and *client_secret* are parallel to username and
password, it would be inconsistent to use different character set
restrictions for them. (On the other hand, Brian Campbell referenced a
case where a client_id might be a URL, in which case colon would be
required. That seems like a reasonable usage, so the syntax restriction
on client_id probably needs to be relaxed. WG thoughts on the correct
syntax? Should it just be TEXT?)
No, please forget about TEXT. It's gone from HTTP-
If you define new protocol elements, either restrict them to US-ASCII,
or find a way to encode all of Unicode. Restricting to ISO-8859-1 is a
non-starter.
Best regards, Julian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
