Re: [Technical Errata Reported] RFC2633 (5019)

Hi Josh,

AD for the successor group here (and hence one of the two ADs
jointly responsible for processing this errata).

1. I don't actually think that the responses to you have been offensive.

2. I agree that "encryp" is an odd abbreviation, but then so is "pref",
which
I think you'll agree is an abbreviation, not a typo. So, I don't think this
is
a clear error, and the argument Russ offers that it isn't seems persuasive.

3. As Jim says, this has no impact on the protocol, and the specific
change you are suggesting would actually break the ASN.1 module.
No doubt we could use a comment, but given the opinions expressed
here, I don't believe that that's necessary.

Finally, I would note that even if I agreed with you that this in fact was
an error, the correct processing would be "hold for document update",
as indicated in point 5 of the processing guidelines
https://www.ietf.org/iesg/statement/errata-processing.html

-Ekr






On Sun, May 14, 2017 at 1:42 PM, Josh Soref <[email protected]> wrote:

> Ok. Let's say that I'm new to IETF process. The feedback provided so far
> is offensive.
>
> Please suggest the proper way to annotate that there is an error in a
> number of the documents hosted by IETF.
>
> Clearly someone successfully ridiculed IETF once such that future
> standards appropriately included "[sic]" wherever "referer" is used. It
> shouldn't be hard to suggest to a submitter the correct way to do that
> today, decades later.
>
> On May 14, 2017 4:35 PM, "Jim Schaad" <[email protected]> wrote:
>
>> The name chosen has absolutely no change of what is one the wire.   That
>> means that this is at best editorial and is definitely not technical.
>>
>>
>>
>> This is only going to affect those people who decide to use autogenerated
>> constant names from the ASN.1 file.  The suggested change would make for an
>> invalid ASN.1 file so it not correct.  Changing this name at this point
>> would be a hassle for any one doing auto generation and highlighting that
>> this is not, in some sense, a word does not affect the standard in any way.
>>
>>
>>
>> This should be rejected.
>>
>>
>>
>> Jim
>>
>>
>>
>>
>>
>> *From:* smime [mailto:[email protected]] *On Behalf Of *Russ Housley
>> *Sent:* Sunday, May 14, 2017 10:55 AM
>> *To:* Josh Soref <[email protected]>
>> *Cc:* Kathleen Moriarty <[email protected]>; Paul Hoffman
>> <[email protected]>; Eric Rescorla <[email protected]>; IETF SMIME <
>> [email protected]>
>> *Subject:* Re: [smime] [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]> 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]> 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
>> >
>> > --------------------------------------
>> > Type: Technical
>> > Reported by: Josh Soref <[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]
>> > https://www.ietf.org/mailman/listinfo/smime
>>
>>
>>
>

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