RFCs für Content-Type-Header?

Question

Ich habe @rfc 2231 und 2183 geschaut. Umgang mit einer mehrteiligen/verwandten MIME-Nutzlast.

Ich versuche zu entschlüsseln, wenn das Folgende syntaktisch korrekt ist, speziell das "Start" -Attribut für den ersten Inhaltstyp, aber ich konnte den richtigen RFC nicht finden.

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 

Einige Hintergrundinformationen für Neugierige. application/vnd.oma.drm. * dateitypen ist nur ein Wrapper um ein Payload-Objekt (mp3, jpg usw.), das zellularen Geräten mitteilt, dass die umhüllte Datei als geschützte Nutzlast zu betrachten ist und nicht erlaubt, dass sie weitergeleitet oder übertragen wird das Telefon sowieso. Wenn nicht für vertragliche Verpflichtungen, würde ich nur den Wrapper abreißen, die Nutzlast senden und glücklich sein, aber das ist zu einfach und wahrscheinlich illegal.

Answer 1

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

3,2. Der Startparameter

Der start Parameter, falls angegeben, ist der content-ID des zusammengesetzten Objekts "root". Wenn nicht vorhanden, ist der "root" der erste Körperteil in der Multipart/Related-Entity. Der "root" ist das Element, das die Anwendungen zuerst verarbeiten.