> --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.
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 mesage, should be required to be at top level.
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.
> > 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.
One problem is going to be that many if not most of the issues here lie in the
media type space, and that's not a MIME-only party any more.
In facy we should probably look over the media types registration draft
revision that's out now and see if there are any restrictions there that need
to go.
> 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.
Agreed.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
