I'm doing some work with the OMA in the area of spam reporting. They have
developed an XML message format for reporting spam from a mobile handset.
Because SMS and MMS (and even IM) have different structure than email, they
went with something more extensible than what we currently do with DSNs. I'm
helping that group try to converge with what we do in the email world,
especially with what the MARF working group is producing (e.g., ARF, specified
by recently-published RFC5965). The first thing is to register the MIME type
they've created, and so I've crafted a template for that.
The next thing we'd like to achieve is to be able to specify multiple spam
reports in a single message, regardless of transport (they currently use HTTP
POST, but there's no reason SMTP couldn't be used). The most obvious thing to
do would be to use a multipart/mixed MIME message, and then include their MIME
type in each of "n" parts. However, this is different than what was done with
ARF, which used multipart/report. The advantage to using multipart/report,
which stipulates that it must be the outermost MIME type, is that you know
right away that you're processing a report rather than having to parse part way
into the MIME tree to figure that out. (According to Tony Hansen, that's why
this rule was put in place.) But although multipart/report is the most obvious
construct for doing this, it doesn't lend itself to multi-report messages. So
to get these to converge, we have to be a little creative or be very creative
(in the "create a lot of documents" sense).
We could do a message/digest, each sub-part of which is message/rfc822 and the
MIME type within that is multipart/report. One could argue that this approach
conforms to the multipart/report rules by having that be the outermost MIME
part of each constituent message in the aggregate message, but that might be
hard to defend given the spirit of that rule.
There's also a stipulation that the MIME subtype of the second part in a
multipart/report message must be equal to the report-type of the outermost
part, with no other constraints. Thus to keep multipart/report at the
outermost MIME but allow multi-message reports, we could comply by using
"multipart/report; report-type=mixed" as the outermost MIME type and then use
"multipart/mixed" inside. But this also sure feels hack-ish.
So what would be more palatable to this community? Could multipart/report be
updated to accommodate this use case? Should we register
multipart/multi-report that relaxes some of the existing restrictions without
changing the existing media type?
Feedback/guidance is welcome.
-MSK