views:

99

answers:

1

I've looked @ rfc 2231 and 2183. Dealing with a multipart/related mime payload.

I'm trying to decypher if the following is syntactically correct, specifically the "start" attribute for the first Content-Type, but I haven't been able to find the correct RFC.

Content-Type: multipart/related; boundary="=_34e1b39f5c290f66360ff510d4c38da4";  type="application/smil"; start="<cid:eaec2c30d892902b14044d57dbb6ff85>"



--=_34e1b39f5c290f66360ff510d4c38da4
Content-ID: <eaec2c30d892902b14044d57dbb6ff85>
Content-Type:  application/vnd.oma.drm.message; boundary=ihvdxymhvdhobklkqbcn;
 name="IrishJi2.dm";
Content-Disposition: attachment;
 filename="IrishJi2.dm";

--ihvdxymhvdhobklkqbcn
Content-Type: audio/mpeg
Content-Transfer-Encoding: binary

Some background information for the curious. application/vnd.oma.drm.* file types is just a wrapper around a payload item (mp3,jpg, etc) that tells cellular devices the wrapped file is to be considered protected payload and not to allow it to be forwarded or transfered off the phone in anyway. If not for contractual obligations I'd just rip the wrapper off, send the payload on, and be happy, but that is too easy and probably illegal.

+2  A: 

From RFC 2387 (The MIME Multipart/Related Content-type):

3.2. The Start Parameter

The start parameter, if given, is the content-ID of the compound object's "root". If not present the "root" is the first body part in the Multipart/Related entity. The "root" is the element the applications processes first.

Daniel LeCheminant

related questions