This issue was raised (without
resolution or even near-consensus guidance) in the MARF WG at IETF78. Here’s
some reference material (1 and 2 below) and an additional question (3 below).
There is a document
describing this issue. While it is no-longer up-to-date in that the
SpamRep MIME structure has been changed to promote OMA/IETF convergence, it
The current Open
Mobile Alliance (OMA) SpamRep MIME structures are described in Section 5 of the
draft SpamRep specification available at: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Permanent_documents/OMA-TS-SpamRep-V1_0-20100913-D.zip
. The two most important structures are the single report “Simple
SpamRep Message” and the multi-report “Complex SpamRep Message,”
SpamRep Document (XML, application/vnd.oma.spamrep+xml)
Human Readable text (e.g., “OMA Spam Report: Spam received
Human Readable text (e.g.,
“This is a collection of OMA Spam Reports”)
An issue not
raised in Murry’s message is whether and how to promote spam reports that
are readable by both RFC5965 and SpamRep servers. One possibility is to
allow the second part of the multipart/report to be a multipart/alternative MIME
part. This multipart/alternative might contain two or more MIME parts,
including both OMA-defined application/vnd.oma.spamrep+xml and
RFC5965-defined message/feedback-report MIME parts. To comply with the letter
(yet perhaps not the spirit) of RFC3462, an outer(most) MIME type would need to
be ‘multipart/report, report-type=alternative’. What is the
group’s reaction to this?
owner-ietf-822 <at> mail.imc.org [mailto:owner-ietf-822 <at> mail.imc.org] On Behalf
Of Murray S. Kucherawy
Sent: Tuesday, September 21, 2010 10:53 PM
To: ietf-822 <at> imc.org
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
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.