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

#376 rename b64token for clarity, was: p7: rename b64token (to token68) to avoid misunderstandings

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 18 Jul 2012 21:43:22 +0200
Message-ID: <500711DA.4050805@gmx.de>
To: Amos Jeffries <squid3@treenet.co.nz>
CC: ietf-http-wg@w3.org
On 2012-07-18 11:14, Amos Jeffries wrote:
> On 18/07/2012 7:39 p.m., Julian Reschke wrote:
>> 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
>>
>>
>
>
> +1 from me too.
>
> AYJ

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1815>
Received on Wednesday, 18 July 2012 19:43:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 19:43:58 GMT