- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 18 Jul 2012 21:43:22 +0200
- 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 UTC