Re: Processing errata for RFC 4648

[Julian Reschke <[e-mail]>]

Am 03.01.2026 um 17:41 schrieb Simon Josefsson:
> Julian Reschke <julian.reschke=[e-mail]> writes:
> 
>> Am 10.10.2025 um 14:45 schrieb Carsten Bormann:
>>> On Oct 10, 2025, at 14:42, Julian Reschke <julian.reschke=[e-mail]> wrote:
>>>>
>>>> Guten Tag.
>>>>
>>>> While looking at a Base64 implementation in our software, I realized that RFC 4848 is important, widely implemented, but still is just a "proposed" standard.
>>>>
>>>> It has four errata (https://www.rfc-editor.org/errata/rfc4648) of which only one has not been verified.
>>> ...
>>
>> In the meantime there are two.
>>
>> https://www.rfc-editor.org/errata/rfc4648 - padding in base32. I
>> believe this one should be rejected (alternatively, if I'm wrong on
>> this, we'd need to fix the equivalent text for base64 as well).
> 
> Are you talking about https://www.rfc-editor.org/errata/eid4889 ?

Oops. Yes.

> If so I agree it should be rejected, I already analyzed it here:
> 
> https://mailarchive.ietf.org/arch/msg/ietf/EZyaQ_dJgemHXu1iq4E4BdPmmFk/
> 
> Getting someone to take action on errata reviews seems challenging.  Is
> there any working process to make that happen?

It's indeed a bit of a challenge, as this is cross area, thus without an 
obvious venue.

I saw suggestions to involve the ART area or gendispatch 
(https://datatracker.ietf.org/wg/gendispatch/about/) We probably should 
move over to one of these venues with a summary of what we think should 
happen. That doesn't prevent progress on
ietf-base-encoding of course (fwiw, should be named 
draft-josefsson-something).

With respect to the first erratum: you have analyzed this in October and 
there was no disagreement. In this case, you could just inform the RFC 
Editor about the outcome (I've put them on cc: already).


>> https://www.rfc-editor.org/errata/eid8669 - this one is correct (FWIW,
>> I just stumbled over this when re-reading RFC 4648). That said, this
>> is a a case of "Held For Update".
> 
> Yes -- although we should make sure to harmonize the wording for base32
> and base64 here, and if consider if it is worth avoid duplicating it.

Agreed; some refactoring would be good. But it absolutely should not be 
mixed with other changes.

Best regards, Julian