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

[Ned Freed <[e-mail]>]

> On 28/Jul/11 00:55, [e-mail] wrote:
> > Multipart/report is, or should be, a very general construct used to report
> > pretty much anything relating to messages or perhaps even more general MIME
> > content.
> >
> > The restriction that generated DSNs and MDNs (two specific types of report)
> > need to be placed at the top-level is what's needed here. Nothing more.

> IMHO "generated" is not very clear here.  I roughly understand it as
> referring to the act of issuing a report, automatically or not.

> BTW, ARF reports, as currently used, probably have to be at top level
> as well.

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

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

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

> > [moved] We should not attempt to guess at possible future uses of
> > the report framework. This sort of anticipatory restriction is what
> > gets us into trouble with great regularity, and we need to stop
> > doing it.

> In general, I agree.  But here we are introducing a split, or
> categorization, to distinguish "active", "generated", or "top-level"
> from other kinds of report transmission.  How can we do so without
> affecting future report types as well?

Well, the obvious thing is to say that all report types need to specify
the contexts in which they can appear and what they mean in those contexts.

> >>> I'm puzzled about the "and gateways" part.  Is it correct?
> >
> > Yes. A proper gateway to X.400, for example, will turn a top-level DSN into an
> > X.400 delivery report and vice versa. (It would nice if the same applied to
> > MDNs and X.400 read receipts, but the semantics are so dissimilar that
> > conversion is infeasible.)

> I'm not familiar with X.400,

Consider yourself fortunate in that regard.

> but this turns out to be a clarifying
> element.  Top-level reports may be converted.  In pseudo-code

>   if (/^Content-Type: *multipart\/report.*report-type=([:value:]+)/ih)
>   // assume h stands for header only, and :value: catches token or
>   // quoted-string appropriately
>   {
>     switch ($1)
>     {
>       case "delivery-status":
>       // convert
>       // ...
>     }
>   }

Yep, that look about right. It also has to be outermost level because in X.400
a delivery report is not, properly speaking, a message, so you cannot include
other message-ish stuff in it.

> The task of preserving gateway functionality allows to define the
> behavior without shredding much more light on the semantics of
> "top-level" vs. "wrapped".

> >>> Question: in case an ARF processor forwards an abuse (mis)report to
> >>> the original author, is it correct to keep multipart/report as the top
> >>> Content-Type?

> I'm sorry I badly expressed this point.  Consider that the original
> author probably has a copy of the reported message in her "Sent"
> folder.  In this particular case, an agent could do some meaningful
> work with reports.  Would it make sense to send the report as
> "active", so as to trigger any agent that may process it?

I don't see why not, but then again I'm not entirely clear on all the ins
and outs of ARF usage.

				Ned