Re: [smime] [Errata Held for Document Update] RFC2633 (5019)

I agree it would be useful to highlight. But this is an ASN.1 code fragment
and I am not sure it will parse with the comment there.

On Mon, Mar 19, 2018 at 6:52 AM, RFC Errata System <
rfc-editor@rfc-editor.org> wrote:

> The following errata report has been held for document update
> for RFC2633, "S/MIME Version 3 Message Specification".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5019
>
> --------------------------------------
> Status: Held for Document Update
> Type: Editorial
>
> Reported by: Josh Soref <jsoref@gmail.com>
> Date Reported: 2017-05-14
> Held by: Kathleen Moriarty (IESG)
>
> Section: 5
>
> Original Text
> -------------
> id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
>
>
> Corrected Text
> --------------
> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::= {id-aa 11}
>
> Notes
> -----
> encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945)
> referer [sic] before it, this is now part of the API.
>
> This error should be highlighted (as rfc2068 does for referer [sic]) so
> that people are aware that the natural spelling doesn't apply.
>
> If it's possible for a revised RFC to be published suggesting the correct
> spelling w/ a way for clients/servers to handle the old spelling, that
> would be nice, but based on precedent, that seems unlikely.
>
> ---
> As AD, this discussion needs to be continued and possibly with a different
> draft.  As such, I am marking this as hold for document update and listing
> it as editorial so that there are no n the wire changes at this time with
> this errata.
> ----
> There was quite a bit of on list discussion that should be reviewed for
> any future changes.
>
> One summary from the discussion:
> he mailing list participants are copied on these errata to get their
> opinion in order to inform the AD how to dispose of the errata.  Most folks
> are just making their opinions known.
>
> 1) The next thing that folks look at is whether it’s technical or not.
> Debate ensues, but generally technical errata are those that affect
> interoperability.  This one I don’t think does because there are no changes
> to the bits on the wire.
>
> 2) And, well folks want to get lots of changes, but the change has to run
> through the consensus process (back to mailing list input).
>
> So to the import bit:
>
> As I see it, there are two ways to get the note incorporated:
>
> 1. Write a draft that adds the note; this seems a bit heavy weight for
> what you are trying to do.
>
> 2. Apply the note to the latest RFC/draft that obsoletes RFC 2633; I guess
> you went for upstream, but generally the IETF applies changes to the
> latest/greatest RFC/draft.  That obsoletes chain is: RFC 3851 obsoleted RFC
> 2633, RFC 3851 was obsoleted by RFC 5751, and draft-ietf-lamps-rfc5751-bis
> is about to obsolete RFC 5751.  Luckily, draft-ietf-lamps-rfc5751-bis isn’t
> yet an RFC so there’s an option to have the note added there.
>
> Any objections to adding a note in draft-ietf-lamps-rfc5751-bis along the
> same lines as the note for receipentKeyId?
>
> --------------------------------------
> RFC2633 (draft-ietf-smime-msg-08)
> --------------------------------------
> Title               : S/MIME Version 3 Message Specification
> Publication Date    : June 1999
> Author(s)           : B. Ramsdell, Ed.
> Category            : PROPOSED STANDARD
> Source              : S/MIME Mail Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> smime mailing list
> smime@ietf.org
> https://www.ietf.org/mailman/listinfo/smime
>