RFC 2616 contains this restriction for the contents of TEXT fields:
Words of *TEXT MAY contain characters from character sets other than
ISO-8859-1 [22] only when encoded according to the rules of
RFC 2047 [14].
Therefore, I believe that for the elements using TEXT, the encoding must be
specified as ISO-8859-1, since they are not always used in contexts where MIME
encoding rules can be specified.
Yes, I believe you're correct that "URI" should be "URI-reference".
I'll make both of these changes.
Thanks,
-- Mike
-----Original Message-----
From: Julian Reschke [mailto:[email protected]]
Sent: Saturday, June 02, 2012 10:55 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review
On 2012-06-02 10:10, Mike Jones wrote:
> Dear working group,
>
> It turns out that writing an ABNF for the Core spec pointed out that
> the syntax of a number of the OAuth protocol elements had not been
> previously defined. (Thanks, Sean, for having us do this!) I took a
> stab at specifying appropriate ABNF values for each of the protocol
> elements, but I would request that the working group actively review
> the choices in my proposed draft.
>
> For instance, I chose to use the same syntax definitions for username
> and password and client_id and client_secret as HTTP Basic used for
> userid and password. Other choices were possible, such as perhaps
> limiting client_id and possibly username values to use "unreserved"
> characters, rather than allowing all characters other than ":" (as
> HTTP Basic did with userid).
>
> Please particularly review the syntax definitions for these elements,
> as I had to make choices that went beyond the current specs to provide
> unambiguous syntax definitions:
>
> client_id
>
> client_secret
>
> state
>
> code
>
> access_token
>
> username
>
> password
>
> refresh_token
>
> The full proposed ABNF section follows.
>
> -- Mike
>
> Appendix A. Augmented Backus-Naur Form (ABNF) Syntax
>
> This section provides Augmented Backus-Naur Form (ABNF) syntax
>
> descriptions for the elements defined in this specification using the
>
> notation of [RFC5234]. Elements are presented in the order first
>
> defined.
>
> Some of the definitions that follow use the "unreserved" and "URI"
>
> definitions from [RFC3986], which are:
>
> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
>
> URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>
> Some of the definitions that follow use the "b64token" syntax below,
>
> which matches the "b64token" syntax defined by HTTP/1.1, Part 7
>
> [I-D.ietf-httpbis-p7-auth]:
>
> b64token = 1*( ALPHA / DIGIT /
>
> "-" / "." / "_" / "~" / "+" / "/" ) *"="
>
> A.1. "client_id" Syntax
>
> The "client_id" element is defined in Section 2.3.1:
>
> client-id = *<TEXT excluding ":">
>
> (This matches the "userid" definition in the HTTP Basic
>
> Authentication Scheme [RFC2617].)
TEXT is defined in RFC 2616 as
TEXT = <any OCTET except CTLs,
but including LWS>
and
OCTET = <any 8-bit sequence of data>
So what character encoding do you use? Possible answers are "it depends",
"ISO-8859-1", and "UTF-8".
The same comment applies to everything else using TEXT..
> A.6. "redirect_uri" Syntax
>
> The "redirect_uri" element is defined in Section 4.1.1,
>
> Section 4.1.3, and Section 4.2.1:
>
> redirect-uri = URI
Are you sure that this is not a URI-reference???
> ...
Best regards, Julian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
