Re: [Emailcore] WGLC: draft-ietf-emailcore-rfc5322bis-03

[Alexey Melnikov <[e-mail]>]

Hi Todd,

(As a participant).

On 06/05/2022 15:32, Todd Herr wrote:
> On Fri, Apr 29, 2022 at 6:36 AM Alexey Melnikov 
> <[e-mail]> wrote:
>
>     Dear EMAILCORE participants,
>
>     This message starts 4 weeks WGLC call on
>     draft-ietf-emailcore-rfc5322bis-03 (Internet Message Format), that
>     would
>     end on May 27th 2022. Please send your comments, as well as
>     statement of
>     support (or not) for progressing this document in a reply to this
>     email
>     message, or in exceptional cases directly to EMAILCORE chairs
>     <[e-mail]>
>
>
> As a participant...
>
> I reviewed the text and have only the following minor comments/nits:
>
>   * Consistency of the definition of the term "MIME documents/MIME
>     document series"
>       o In Section 1.1, the “MIME document series” is defined as RFCs
>         2045, 2046, and 2049;
>       o In Section 2.1, the "MIME document series" is those three plus
>         RFC 2047 and BCP 13.
>       o In Section 2.3, “the MIME documents” are RFCs 2045, 2046, 2049
>         and BCP 13.
>
When I saw this I thought different RFCs were listed depending on 
context. But I agree that these should be checked for relevancy.
>
>   * Section 3.4, second paragraph - “A mailbox receives mail. It is a
>     conceptual entity that does not necessarily pertain to file
>     storage. For example, some sites may choose to print mail on a
>     printer and deliver the output to the addressee's desk.” Do we
>     still think this is true? Perhaps a more timely example would be
>     better, or just strike the last sentence entirely?
>
I think the example demonstrates what is meant by "not a file storage", 
which I like. I think such systems still exist.

Can you suggest a better example?

>   * Section 3.6.5 - Nitpick: ‘The "Subject:" field is the most common
>     and contains a shortstring identifying the topic of the message.’
>     Not all subjects necessarily meet the arbitrary definition of
>     “short”. Perhaps replace “short” with “character” or “text”?
>   * Section 3.6.8 - “Fields may appear in messages that are otherwise
>     unspecified in this document.” It would be more appropriate to
>     write this as “Fields that are otherwise unspecified in this
>     document may appear in messages.” I think, because the document,
>     particularly this section, is specifying fields, not messages.
>
Good point and I like your suggested clarification.
>
>   * Section 5, Security Considerations. The thoughts here are
>     certainly valid, but the text makes lots of references to risks to
>     terminals and terminal emulators, and even I at my advanced age
>     have but a foggy recollection of using such things. Can/should the
>     language be updated to reference equipment that is much more
>     likely to be used by current and future readers of this document?
>
I have noticed this text, but decided that it is not worth changing, 
because it is still correct. And there are certainly implementations 
like "pine" that would care about terminal emulators. So personally I 
would not delete this text.

Best Regards,

Alexey