- From: Manger, James H <James.H.Manger@team.telstra.com>
- Date: Wed, 18 Jul 2012 17:27:51 +1000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
HTTPbis part 7 (Authentication) introduces a new piece of ABNF labelled "b64token" [http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-20#section-2.1]. It is also referenced/repeated in the OAuth2 Bearer draft spec. The new ABNF is necessary and explained quite clearly in the spec. However, the "b64token" label has already led at least a handful of people to mistakenly assume it always holds a base64-encoding. The examples in the OAuth2 Bearer spec were even changed so they were not base64-encodings to try to minimise the misunderstanding, but others have still made the mistaken assumption.
How about renaming the ABNF production to "token68"?
This label reflects the fact that it supports an alphabet of 68 characters (plus equal signs at the end).
The new text in part 7 would become:
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
The "token68" syntax allows the 66 unreserved URI characters
([RFC3986]), plus a few others, so that it can hold a base64,
base64url (URL and filename safe alphabet), base32, or base16 (hex)
encoding, with or without padding, but excluding whitespace
([RFC4648]).
--
James Manger
Received on Wednesday, 18 July 2012 07:28:26 UTC