Re: [Technical Errata Reported] RFC2633 (5019)

It is the name that the author chose to use in the ASN.1.  If it was a typo, then it would have been changed in the subsequent update to the RFC.

Russ


> On May 14, 2017, at 1:44 PM, Josh Soref <[email protected]> wrote:
> 
> It isn't an abbreviation, other tokens are clearly longer such as signingCertificate and smimeEncryptCerts. It's likely that the errata applies to multiple RFCs.
> 
> On May 14, 2017 1:15 PM, "Russ Housley" <[email protected] <mailto:[email protected]>> wrote:
> I believe that this errata should be rejected.  The author used an abbreviation, and the same spelling is used in RFC 3851.
> 
> Russ
> 
> 
> > On May 14, 2017, at 12:35 PM, RFC Errata System <[email protected] <mailto:[email protected]>> wrote:
> >
> > The following errata report has been submitted for RFC2633,
> > "S/MIME Version 3 Message Specification".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5019 <http://www.rfc-editor.org/errata/eid5019>
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Josh Soref <[email protected] <mailto:[email protected]>>
> >
> > 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.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > 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
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/smime <https://www.ietf.org/mailman/listinfo/smime>
>

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime