Re: [apps-discuss] Draft for trace fields registry

[S Moonesamy <[e-mail]>]

Hi John,
At 18:10 17-01-2012, John Levine wrote:
>I wrote a draft to add a trace column to the existing header field
>registry.  This is mostly about the registry; SM's draft (which I
>didn't know he was writing) is more about what trace fields are.

Yes.  I wrote about Trace fields in response to the latest 
discussions on this list.  draft-moonesamy-mail-trace-fields-00 
provides some background information about Trace fields, hence the 
reference to RFC 4871 (obsolete).   BTW, I already know about the 
invalid RFC822 reference.  The draft does not mention the registry 
part as you mentioned that you might work on that.

I only covered mail-related specifications mentioning Trace fields up 
to "VBR-Info" as they are related to the DKIM work.  RFC 5598 is not 
mentioned as it uses RFC 2505 (antispam) to reference "trace information".

I don't feel strongly about the question of Trace fields.  I'll 
comment on draft-levine-trace-header-registry-00 as we looked at the 
topic from different viewpoints.  Section 3.6 of RFC 5322 discusses 
about "trace header field" and has a requirement for not reordering 
them and a recommendation for keeping them in blocks (see issues in 
Section 6 of draft-moonesamy-mail-trace-fields-00).  Section 3.1 of 
draft-levine-trace-header-registry-00 keeps the requirement and drops 
the recommendation.  Such a change would generate some on-list discussion.

My preference is to use "trace information" to discuss about 
documenting the progress of a message through the e-mail system 
(second paragraph of Section 3.1 of your draft).  Section 3.6 of RFC 
5322 mentions that:

   "the trace header fields and resent header fields MUST NOT be reordered"

I'll defer to the editor of RFC 5322 as to what exactly is a Trace 
field as it is not clear given the text quoted above and what's in 
Section 3.6.7.

As a reply to Ned's question, I am ok with combining the two drafts 
if John thinks that the material is appropriate for the topic he is tackling.

Regards,
S. Moonesamy