The Base16, Base32, and Base64 Data Encodings
RFC 4648

Note: This ballot was opened for revision 04 and is now closed.

(Lisa Dusseault) Yes

(Ted Hardie) Yes

Comment (2006-05-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The author has agreed with Russ's point.  An RFC Editor note adding a reference to the LGPL is
pending other review, to see if other RFC Editor notes/revisions are needed.

(Cullen Jennings) (was No Record, Yes) Yes

Comment (2006-05-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I made several comments on this draft in IETF LC and I was pleased (and frankly, surprised) to see they were all addressed very nicely. Thank you.

(Jari Arkko) (was Discuss, No Objection, Discuss) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

(Lars Eggert) No Objection

(Bill Fenner) No Objection

Comment (2006-05-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Is it wise to have a character from the "reserved" [sub-delims] production
in the "URL safe" base64 alphabet (=)?  The only remaining "unreserved"
characters are ~ (already addressed) and ".", which could have its own
problems wrt "filename-safe".

[I ask because I saw a brief discussion go by from two people discussing
base64-encoded data in URLs and they were explicitly talking about
needing to percent-encode the "=" and they decided to instead discard
the padding and make the padding implicit.  RFC 1738 does imply that
"=" has to be encoded unless it's being used for a scheme-specific
purpose; RFC 3986 is more clear on this point but helper libraries
etc. are likely to be based on the older document.]

(Sam Hartman) (was Discuss) No Objection

Comment (2006-05-09)
No email
send info
It seems that when padding is required, that multiple encodings are
possible.  For example, if the input is only one octet for a base 64
encoding, then all six bits of the first symbol are used, but only the
first two bits of the next symbol are used.  Many decoders would
presumably work with this case.  One consequence of this is that there
is not a canonical encoding.  That is, multiple base64 inputs decode
to the same value.  That's significant from a security standpoint.
I'd appreciate it if this document could mandate encoders produce a
canonical encoding (even if it cannot mandate decoders reject
non-canonical encodings) and discuss the security implications.

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(Magnus Westerlund) No Objection