Re: Is RFC5322 a 'protocol'?

On 1/6/2014 2:30 PM, Dave Crocker wrote:
> On 1/6/2014 11:11 AM, Rolf E. Sonneveld wrote:
>> Can you elaborate on why you think the Originator fields qualify as
>> protocol and other fields (like the paragraph on "Destination Address
>> Fields") would not? Assuming for the moment that your 'definition' of
>> protocol is correct, I fail to see why Originator fields would qualify
>> as 'protocol'.
>
>       3.6.2. Originator Fields
>       ...
>       The originator fields also provide the information required when
>       replying to a message. When the "Reply-To:" field is present, it
>     indicates the address(es) to which the author of the message suggests
>     that replies be sent.  In the absence of the "Reply-To:" field,
>     replies SHOULD by default be sent to the mailbox(es) specified in the
>     "From:" field unless otherwise specified by the person composing the
>     reply.
>
> That looks like a protocol directive, to me.


Sure.

I have always considered RFC xx22 as both a "format" and "protocol" 
for RFCxx22-based mail communications, in the same way we had other 
past mail networks each with their own format and protocol for mail 
communications.

<side_note>
BTW, just noticed this. As a side note/nit, the above protocol design 
semantic:

         .... to which the author of the message suggests
         that replies be sent.

Would not 100% reflect how this Reply-To: is used with different mail 
agents, not just the MUA but a MLS (Mail List Server).  It probably 
should of been more general without saying it was the author's 
suggestion.  It could of been a mail list distribution or some mail 
bot notification having a special reply-to field.

      The originator fields also provide the information required when
      replying to a message. When the "Reply-To:" field is present, it
      indicates the address(es) to where replies SHOULD be sent.  .....
</side_note>

This is all part of the "protocol description" each header should have 
otherwise interop problems occur or multiple agents can't communicate. 
  As you might recall,  RFC 822 had a requirements for the following 
fields:

    A.3.1.  Minimum required:

    Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
    From:     [email protected]   or   From:     [email protected]
    Bcc:                                To:       [email protected]

       Note that the "Bcc" field may be empty, while the  "To"  field
       is required to have at least one address.


RFC 2822/5322 relaxed it to just the Date: and From: fields:

    3.6 Field Definitions

    ...

    The only required header fields are the origination date field and
    the originator address field(s).  All other header fields are
    syntactically optional.  More information is contained in the table
    following this definition.


SMTP receivers can handle this with strict RFC 822 or more relaxed RFC 
2822 options in deployments.  Some may even fill in the To: based on 
the 5321.RCPT TO: input. In fact, since the *22 documents say what is 
required, some receivers may even detect a invalid header and 
automatically create required fields rather than reject/bounce the 
message.

      5322.Date:    <----- 5321 session timestamp
      5322.From:    <----- 5321.MAIL FROM:
      5322.To:      <----- 5321.RCPT TO (when StrictRFC822.To field 
required is enabled)



-- 
HLS


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