Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt

[Alessandro Vesely <[e-mail]>]

On 29/Jul/11 00:41, Ned Freed wrote:
>>> In fact the best way to handle this would be to put the restriction into the
>>> DSN and MDN specifications that build on the multipart/report framework, and
>>> say something like, "Uses of the multipart/report container format MAY restrict
>>> the contexts in which a particular report type can appear."
> 
>> Does that mean top-level implies "active"?
> 
> You know, I was thinking about that as well. It's clear than active DSNs and
> MDNs have to be top-level but that doesn't mean the converse is necessarily
> true.

Plus: it would allow an ABNF-like definition of "active",
minus: inactive messages would then have to be wrapped.

> Operationally at least, I think the answer is something along the lines of,
> "it's active if it correlates with a message you sent, otherwise not". 

+1, it clarifies what reporting is all about, linking the active
status with the destination address (and is quite complaisant to data
protection principles in this respect.)  Let me try to reword the
first paragraph of Section 3:

   The multipart/report MIME media type is a general "family" or
   "container" type for electronic mail reports of any kind.  A mail
   report presents an account of events occurred to another mail
   message, which is called the original message, returned message, or
   reported message.  A report message, i.e. a message carrying a mail
   report, is considered "active" when it is destined to an entity
   who actively contributed to the sending of the original message,
   including authors, relays, gateways, delivery agents, and link
   operators.  Mail processing programs can benefit of using a single
   media type for all kinds of reports, and detect active reports
   correlated with sent messages.

> I'm not sure if this warrants mention in the spec or not.

Nor I.  It may ease the wording of the top-level requirement, though.

jm2c