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

+1, very good direction.

Additional comment:
Its use in -p7 is only for legacy direct tokens for challenge and credentials.
If there is a good-sounding name suggesting its legaciness or its specific
use case, it seems better for me than name based on 68 possible characters.

# I imagined "legacy-raw-auth-token", but it's not sounding good :-(

2012/7/18 Manger, James H <James.H.Manger@team.telstra.com>:
> 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



-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Wednesday, 18 July 2012 19:50:37 UTC