--On Friday, July 15, 2011 14:37 -0700 Ned Freed
<[email protected]> wrote:
>> 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.
>...
> 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?
>...
> 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.
You are stating a restriction on DSNs and MSNs, not
multipart/report. That is probably an important distinction;
see below.
> 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.
>...
> 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.
I think that is the key, so let's take it a step further. We
imposed a number of restrictions when the MIME spec was
developed. As you said, they were well-intentioned. Some were
to avoid cases or processing overhead that people were concerned
about, others to avoid various types of complexity. EAI's need
to establish message/global and make it work by doing away with
the nested encoding restriction notwithstanding, it would really
be good to not do these piecemeal.
Suggestion: someone with the motivation to make more of these go
away and the time to invest some effort should go through the
MIME specs and try to identify all of those restrictions. Make
a list and make recommendations for each one as to whether the
restriction still seems to be justified based on what we've
learned in nearly 20 years. With that list in hand, maybe we
can have a focused review discussion and get out a document that
updates the base MIME specification (and anything else
necessary) to sweep away whichever of these don't make sense and
to reaffirm any of those that are left. It would be a serious
bit of housecleaning, but I think it would be worth the effort.
I imagine Ned already has a list, but a fresh set of eyes
producing one and then comparing it it his would give many of us
confidence that we are on the right track.
Murray, since you brought this up and have generated one draft
already, it seems to me that you are a half-step from
volunteering. But maybe someone else would like to either do
the job or help.
best,
john
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
