> This seems to be a good time to introduce this question since YAM is talking
> about updating its charter.
> The MARF working group has a requirement to be able to produce messages that
> contain abuse reports. It currently uses multipart/report to do this.
> However, multipart/report has a limitation that it has to be the outermost
> media type in a message.
> This prevents MARF from being compatible with another
> system that can contain multiple reports per message.
> I introduced this topic some months ago on apps-discuss, and a draft that is
> almost verbatim the same as RFC3462 minus the above limitation. I remember
> Keith dissenting and Ned supporting, on the grounds that the limitation hasn't
> served any useful purpose. The topic died off after that, but I'd like to
> reintroduce it.
With all due respect to Keith, this sort of blanket restriction is nothing
short of absurd. As you point out, it prevents re-use of multipart/report in
environments where reports have no need to be top-level and in fact need to be
able to be able to be gathered together. It doesn't even make sense for DSNs
and MDNs - suppose you want to forward one of these with a cover note to a
support team for analysis?
In fact we're lucky that essentially every client out there has summarily
ignored this requirement, because the absolute last thing we want it for
clients to screw around with the content of reports in any way, even minor
stuff like changing the subtype of the multipart. It's already hard enough to
get users to provide information needed to diagnose their problems; we really
don't need any more cooks stirring this particular pot.
To the extent there should be any sort of restriction on multipart/report, it
should be on initial DSN and MDN generation. In those cases it makes perfect
sense to say they have to be at the top-level and relays shouldn't mess with
that. But once the DSN or MDN is delivered, it's just another hunk of data. And
as for other uses of multipart/report, well, we imposed a lot of
well-intentioned restrictions like this in the MIME effort, and pretty much
without exception they've all proved to be bad ideas in the medium to long
term.
> We could try to do this from within MARF but it seems to me that modifying a
> general-purpose email RFC in a working group with a specific application is
> probably a little sketchy. It really belongs either in here or in APPSAWG,
> subject of course to whatever YAM's charter allows.
> So, can/should YAM take it as a work item?
While I agree that this should be dealt with, I don't have an opinion
regarding venue, mostly because I confess to not really understanding
the purpose of either YAM or APPSAWG (the latter I only became aware of
recently) at this point. I do note that EAI is removing a much more
significant restrition (another one that was well-intentioned but
ultimately wrongminded) on encodings of subtypes of message, and this
is being done directly in the EAI WG.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
