Re: [apps-discuss] possibleTrace fields registry

[Dave CROCKER <[e-mail]>]

On 1/17/2012 9:33 AM, Murray S. Kucherawy wrote:
>> This has been an interesting exercise. I had not previously noticed
>> that RFC5321 and RFC5322 have conflicting definitions of 'trace'.
>> RFC5321 equates it only to Received.  RFC5322 uses it to describe a
>> class of fields.
>
> I don't see this as being a conflict.  RFC5322 defines a trace field in general terms, and RFC5321 discusses one specific instance of a trace field, namely Received, as being the only one SMTP itself cares about.  It doesn't mean there aren't others, but an MTA doesn't do anything special with them (i.e., doesn't add any new ones).


Except that that's not what RFC5321 says.  Your interpretation actually requires 
some linguistic creativity.  RFC5321 does not note a larger concept, with 
Received being an instance.  It simply uses the one term to refer to the one 
header field.  (IMO, RFCs 821 and 822 created the problem of redundant and 
sometimes divergent definitions, though I hadn't noticed this one before.)

So I think that what you've really done is suggest a simple and reasonable fix, 
requiring only a small amount of wording change to RFC 5321.

When <trace> was a loosely-used term, the disparity didn't matter much.  But 
since there is talk of formalizing the construct further, we should be careful 
about the details and not relay on assumptions about interpretation of 
specification text.  Note, for example, the view that /any/ trace field can be 
repeated...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net