Subject: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt

From: "John Levine" <[email-masked]>
Date: 22 Jan 2012 22:02:29 -0000

As promised, I smooshed S.M.'s draft and mine together, so here's one that has
both his narrative text and my registry additions.

R's,
John

PS: This is unrelated to Murray's draft, which I think is an entirely reasonable
application of a new Received: clause.

--------------------------------------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Mail Header Trace Fields
	Author(s)       : Taughannock Networks
                          S. Moonesamy
	Filename        : draft-levine-trace-header-registry-01.txt
	Pages           : 6
	Date            : 2012-01-22

   SMTP mail software adds trace fields to messages as they pass through
   the mail system.  This memo provides background information about
   trace fields in mail standards.  It discusses the use of trace fields
   in mail-related specifications.  It updates the definition of trace
   header fields, and adds trace field information to the relevant
   registries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levine-trace-header-registry-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-levine-trace-header-registry-01.txt

---

From: John Leslie <[email-masked]>
Date: Mon, 23 Jan 2012 08:19:53 -0500

> http://www.ietf.org/internet-drafts/draft-levine-trace-header-registry-01.txt

   Nice work!

   But I stumbled over the difference (if any) between RFC2119 SHOULD and
lower-case "should".

   I expect at least one IESG member would also stumble. I advise clarifying
if possible.

   DKIM-Signature's "should" is quoting RFC6376, where it is a "SHOULD",
unless I misunderstand.

   For Authentication-Results, RFC5451 does indeed use lower-case "should"
for "be treated as a Trace field," but it uses upper-case "SHOULD" for
"be added at the top of the message" -- I think folks tend to think of
both of these as RFC2119 "SHOULD".

   For VBR-Info, RFC5518 uses "SHOULD".

   For Auto-Submitted, RFC5436 AFAICT uses "MUST", not "SHOULD" or "should".

   My take on this is that we'd do best to replace those five "should" with
"SHOULD".

   The remaining "should" in Section 4, I'd simply remove.

--
John Leslie <[email-masked]>

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Jan 2012 07:28:58 -0800

Hi John,

Thanks for the feedback.

>    I expect at least one IESG member would also stumble. I advise clarifying

Would the argument that Section 3.1 mentions that "Further 
restrictions may be defined for Trace fields  by the specifications 
that provide for their use" convince you?

>    My take on this is that we'd do best to replace those five "should" with

That can be read as updating the requirements in those 
specifications.  Section 3.2 could be moved to an appendix.  The 
following paragraph, adapted from RFC 6125, could be used:

   This informative section is to delineate the history of thinking about
   Trace fields in mail-related specifications.  It gathers together
   the text from various RFCs (the key words [RFC 2119] have been modified
   as this document does not indicate requirement levels for those RFCs).

>    The remaining "should" in Section 4, I'd simply remove.

Ok.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2012 08:48:27 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Leslie
> Sent: Monday, January 23, 2012 5:20 AM
> To: John Levine
> Cc: [email-masked]
> Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt
> 

I wish someone had caught that when I was getting that one published, but yes, both are supposed to be SHOULDs in the RFC2119 sense.

In order to avoid having this document mired in the "should" vs. "SHOULD" discussion, the authors here might want to consider just listing the drafts that ask for trace field status rather than making direct citations.

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2012 17:14:17 -0000

>In order to avoid having this document mired in the "should" vs. "SHOULD" discussion, the
>authors here might want to consider just listing the drafts that ask for trace field status
>rather than making direct citations.

SM suggested adding a note saying that the section is quoting text
from existing RFCs, and any 2119 words in this section mean whatever
they meant in the original RFCs.  Seems reasonable to me.

R's,
John

---

From: John Leslie <[email-masked]>
Date: Mon, 23 Jan 2012 15:26:34 -0500

S Moonesamy <[email-masked]> wrote:
> 
> That can be read as updating the requirements in those specifications.

   Making the "should" lower-case doesn't fix that problem.

> Section 3.2 could be moved to an appendix.

   I don't think that's necessary, though it wouldn't bother me, I think
it helps to have the body introduce these "new" trace headers.

   We could remove these "shoulds" just like I proposed for Section 4...

> The following paragraph, adapted from RFC 6125, could be used:
> 

   I don't like that text, especially the part claiming to quote, but
modifying.

   Many folks believe that a lower-case "should" is still a RFC2119
keyword -- it's better not to open that argument.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Jan 2012 13:06:57 -0800

Hi John,
>    Making the "should" lower-case doesn't fix that problem.

See below.

>    We could remove these "shoulds" just like I proposed for Section 4...

[snip]

>keyword -- it's better not to open that argument.

Suggested text for Section 3.2:

   This informative section is to delineate the history of thinking about
   Trace fields in mail-related specifications.

   [RFC4408] defines the "Received-SPF:" header field as a Trace field
   and specifies that it is added above all other "Received-SPF:"
   header fields.

   [RFC6376] specifies that the "DKIM-Signature:" header field is
   treated as a Trace field and that it is not be reordered.  It
   mentions that the header field is prepended to the message.
   DomainKeys Identified Mail (DKIM) relies on maintaining the ordering
   of header fields as a change of any "DKIM signed" header field can
   invalidate the DKIM signature.

   [RFC5451] defines an "Authentication-Results:" header field.  It
   mentions that the field is to be treated as a Trace field to get an
   idea of how far away authentication checks, such as DKIM and Sender
   Policy Framework [RFC4408] were done.

   [RFC5518] defines a "VBR-Info:" header field and mentions that a
   message can contain multiple occurrences of these header fields.  The
   document relies on the terminology in [RFC5322] to say that the "VBR-
   Info:" header field is a "trace header field".  It also specifies
   that the header fields is be added at the top of the header
   fields.

   [RFC5436] defines an "Auto-Submitted:" header to be added to
   notification messages generated by Sieve filtering rules.  Section
   2.7.1 says "The "Auto-Submitted:" header field is considered a Trace
   field, similar to "Received:" header fields (see [RFC5321])."

For Section 4:

   The recommendation that trace header fields is to be kept in
   blocks is not always followed.  Some implementations add any new
   header field at the top of the message block without determining
   whether it is a Trace field.

BTW, see the discussion paragraph in Section 1.  If anyone has an 
opinion about that, please send comments.

Regards,
S. Moonesamy

---

From: John Leslie <[email-masked]>
Date: Fri, 27 Jan 2012 10:10:27 -0500

>   whether it is a Trace field.

   Works for me.

---

From: Ned Freed <[email-masked]>
Date: Sat, 28 Jan 2012 19:13:03 -0800 (PST)

> both his narrative text and my registry additions.

Looks good to me!

				Ned

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss