RFC для заголовка типа контента? - PullRequest
Новая
       9

RFC для заголовка типа контента?

0 голосов
/ 17 марта 2009

Я посмотрел @ rfc 2231 и 2183 . Работа с составной / связанной панелью MIME.

Я пытаюсь расшифровать, если следующее синтаксически правильно, в частности атрибут "start" для первого Content-Type, но я не смог найти правильный 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

Некоторая справочная информация для любопытных. Типы файлов application / vnd.oma.drm. * - это просто обертка вокруг элемента полезной нагрузки (mp3, jpg и т. д.), которая сообщает сотовым устройствам, что обернутый файл следует считать защищенной полезной нагрузкой, и не позволяет пересылать или передавать его. телефон в любом случае. Если бы не контрактные обязательства, я бы просто оторвал упаковку, отправил полезную нагрузку и был бы счастлив, но это слишком просто и, вероятно, незаконно.

1 Ответ

2 голосов
/ 17 марта 2009

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

3,2. Начальный параметр

Параметр start, если он задан, является content-ID корневого элемента составного объекта. Если нет, «корень» - это первая часть тела в Multipart / Related entity. «Корень» - это элемент, который приложения сначала обрабатывают.

...