On 19/Jul/11 17:20, Ned Freed wrote:
>> You are stating a restriction on DSNs and MSNs, not
>> multipart/report.  That is probably an important distinction;
>> see below.
> 
> It's actually a little narrower than that - I'm saying that an "active"
> DSN or MDN, that is, one sent to actually report on the status or
> disposition of a message, should be required to be at top level.

I agree that it is somewhat simpler to deal with a traditional DSNs,
and that list managers may choke if presented with a container of many
of them.  Ditto for applications that expect an abuse report.
Is this the only reason to retain the top-level requirement?

Anyway, it is difficult to define "active", because the definition of
DSN seems to be confusing:

RFC 3461:
 A DSN is transmitted as a MIME message with a top-level content-type
 of multipart/report (as defined in RFC 3464).

RFC 3464:
 A DSN is a MIME message with a top-level content-type of
 multipart/report (defined in RFC 3461).

By substitution, I obtain the circular definition:

 A DSN is transmitted as a DSN.

If the  3461 definition had specified "active DSN", it would have yielded

 An active DSN is transmitted as a DSN.

which may make more sense.  But we probably want to say

 An active DSN is transmitted as a top-level DSN.

The wording looks much better for MDN, which is different from the
MIME type used to transmit it:

RFC 3462:
 When used to send a report, the Multipart/Report content-type must
 be the top-level MIME content type for any report message.

RFC 3798:
 A message disposition notification is a MIME message with a top-level
 content-type of multipart/report (defined in [RFC-REPORT]).  When
 multipart/report content is used to transmit an MDN:

> But there should be no such restriction on, say, forwarding a DSN or MDN  I
> have received to someone else. Indeed, I would actually like to require such
> things NOT be sent at top level.

+1, so it is clear they are related to some other sender.
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam

Reply via email to