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).
1. There is a document at
http://www.ietf.org/proceedings/78/slides/marf-0.pdf 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 provides
background.
2. 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-SpamRe
p/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," illustrated below.
SpamRep Document (XML, application/vnd.oma.spamrep+xml)
or ...
[Optional: Spam Content]
Human Readable text (e.g., "OMA Spam Report: Spam received by
+12062187967")
multipart/mixed
...
Human Readable text (e.g., "This is a collection of OMA Spam Reports")
3. 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?
Regards,
Alex Bobotek
From: owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Murray S. Kucherawy
Sent: Tuesday, September 21, 2010 10:53 PM
To: ietf-822(_at_)imc(_dot_)org
Subject: multipart/report
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