W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: p7: rename b64token (to token68) to avoid misunderstandings

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 18 Jul 2012 09:39:57 +0200
Message-ID: <5006684D.9020502@gmx.de>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 2012-07-18 09:27, Manger, James H wrote:
> 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

Sounds good to me; if this reduces potential confusion we should to that.

Best regards, Julian
Received on Wednesday, 18 July 2012 07:40:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 07:40:34 GMT