Subject: draft-ietf-httpbis-encryption-encoding-08, "6.1. Normative References"

From: Julian Reschke <[email-masked]>
Date: Sat, 11 Mar 2017 18:42:46 +0100

<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-encryption-encoding-08.html#rfc.section.6.1>:

> 6.1. Normative References
> ...
> [RFC7515]
>     Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS)”, RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.

As far as I can tell, the reference RFC7515 can be moved to informative; 
it's only needed to define base64url for examples.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Mar 2017 11:10:50 +1100

> it's only needed to define base64url for examples.

Ack, done in the editor's copy.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 16 Mar 2017 01:43:26 +1300

On 13/03/2017 1:10 p.m., Martin Thomson wrote:
> On 12 March 2017 at 04:42, Julian Reschke wrote:

If that is the only reason, why not use *actual* base64url as defined in
RFC 4648?

The statement "Base64url encoding is defined in Section 2 of [RFC7515]."
is a lie anyway. RFC 7515 simply adds some JSON-centric restrictions to
the RFC 4648 definition. Which do not seem particularly relevant to HTTP
headers.

That would move the reference to RFC 4648 and get one step further away
from JSON abominations. People are free to use the JSON sub-set on what
they send - that sis valid base64url, so long as they accept and discard
the '=' padding from those who dont use JSON encoders.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Mar 2017 06:53:09 +1100

> If that is the only reason, why not use *actual* base64url as defined in

The reason to use 7515 is that 4648 doesn't use that name, but
otherwise I'm ambivalent.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Mar 2017 21:38:10 +0100

<https://tools.ietf.org/html/rfc4648#section-5>:

>    This encoding may be referred to as "base64url".  This encoding
>    should not be regarded as the same as the "base64" encoding and
>    should not be referred to as only "base64".  Unless clarified
>    otherwise, "base64" refers to the base 64 in the previous section.

Best regards, Julian