Subject: [ietf-822] Is RFC5322 a 'protocol'?

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Jan 2014 08:28:19 -0800

New year.  New time for abstract queries...

In spite of its title, I believe the *22 series of documents might 
qualify as a protocol, rather than "merely" as an object format 
specification.

The difference I see between a format and a protocol is that the latter 
specifies actions to take.

 From RFC 5322's basic specification, the parts of the document that can 
be argued to specify protocol is, therefore:

      Originator fields (From:/Sender:/Reply-to:)

Possibly also: <return>.

I suspect some of the additional fields that have been specified in 
separate documents similarly contain directions about actions to be taken.

Thoughts?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 06 Jan 2014 20:11:50 +0100

> New year.  New time for abstract queries...

Do you mean with this that you have been waiting until 2014 would start, 
before sending these questions? ;-)

> The difference I see between a format and a protocol is that the 
> latter specifies actions to take.
>
> From RFC 5322's basic specification, the parts of the document that 
> can be argued to specify protocol is, therefore:
>

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'.

And what is the problem that corresponds to this solution?

/rolf

---

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Jan 2014 11:30:35 -0800

> protocol is correct, I fail to see why Originator fields would qualify

      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.

> And what is the problem that corresponds to this solution?

Who to send replies to is a long-established issue.  In fact, Reply-to 
was probably the most innovative part of RFC 733.

d/

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 Jan 2014 18:20:21 -0500

> qualify as a protocol, rather than "merely" as an object format 

Ok.   But I'm curious - why does it matter?   It's not like these terms 
are used consistently or with precision, anyway.  And somehow email has 
managed to work reasonably well (except for spam and spam 
countermeasures) for well over 30 years without this being a settled 
question.

To me the biggest "protocol" part that is associated with *22 has to do 
with how an envelope is derived from a composed message.

Reply processing is of course another bit of "protocol".

Keith

---

From: Hector Santos <[email-masked]>
Date: Tue, 07 Jan 2014 14:08:41 -0500

> 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-masked]   or   From:     [email-masked]
    Bcc:                                To:       [email-masked]

       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