RFC 6838 | Спецификации типа носителя и процедуры регистрации

Аннотация

Этот документ определяет процедуры для спецификации и регистрации «медиа типов» для использования в HTTP, MIME и других интернет-протоколах.

Скачать оригинальный документ на английском языке RFC 6838 PDF

 

Оглавление

1. Введение
1.1. Историческая справка
1.2. Соглашения, используемые в этом документе
2. Предварительные условия регистрации типа носителя
3. Деревья регистрации и названия подтипов
3.1. Дерево Стандартов
3.2. Дерево Продавца
3.3. Личное или Тщеславие Дерево
3.4. Незарегистрированный х. дерево
3.5. Дополнительные регистрационные деревья
4. Требования к регистрации
4.1. Требование функциональности
4.2. Требования к именованию
4.2.1. Медиа Типы Текстов
4.2.2. Медиа Типы Изображений
4.2.3. Медиа Типы Аудио
4.2.4. Медиа Типы Видео
4.2.5. Медиа Типы Приложений
4.2.6. Медиа Типы Составных частей и Сообщений
4.2.7. Дополнительные типы верхнего уровня
4.2.8. Суффиксы имен структурированных синтаксисов
4.2.9. Устаревшие псевдонимы
4.3. Требования к параметрам
4.4. Каноникализация и требования к формату
4.5. Рекомендации по обмену
4.6. Требования безопасности
4.7. Требования, специфичные для Медиа типов XML
4.8. Требования к кодировке
4.9. Использование и внедрение не требует
4.10. Требования к публикации
4.11. Требования к идентификатору фрагмента
4.12. Дополнительная информация
5. Процедура регистрации Медиа типа
5.1. Предварительный обзор сообщества
5.2. Отправить запрос в IANA
5.2.1. Предварительная регистрация
5.3. Обзор и одобрение
5.4. Комментарии к регистрации Медиа типов
5.5. Процедуры изменения
5.6. Шаблон регистрации
6. Процедуры регистрации структурированного синтаксического суффикса
6.1. Процедуры изменения
6.2. Шаблон регистрации суффикса структурированного синтаксиса
7. Вопросы безопасности
8. Соображения IANA
9. Благодарности
10. Ссылки
10.1. Нормативные ссылки
10.2. Информационные ссылки
Приложение А. Устаревшие Медиа типы
Приложение B. Изменения с RFC 4288
Адреса Авторов

 

1. Введение

Последние интернет-протоколы были тщательно разработаны, чтобы быть легко расширяемыми в определенных областях. В частности, многие протоколы, включая, помимо прочего, HTTP [RFC2616 #] и MIME [RFC2045 #], способны переносить произвольно помеченный контент.

Механизм, используемый для маркировки такого содержимого, представляет собой тип носителя, состоящий из типа верхнего уровня и подтипа, который далее структурируется в деревья. При желании типы носителей могут определять сопутствующие данные, известные как параметры.

Для этих меток необходим процесс регистрации, чтобы набор таких значений определялся достаточно упорядоченно, четко и публично.

В этом документе определяются критерии регистрации типов мультимедиа и определяются процедуры, которые должны использоваться для регистрации типов мультимедиа (раздел 5), а также структурированные суффиксы типов мультимедиа (раздел 6) в центральном реестре Управления по присвоению номеров в Интернете (IANA).

Расположение реестра типов носителей, управляемого этими процедурами:

http://www.iana.org/assignments/media-types/

1.1. Историческая справка

Процесс регистрации типов мультимедиа изначально был определен для регистрации типов мультимедиа для использования в контексте асинхронной почтовой интернет-среды. В этой почтовой среде необходимо ограничить число возможных типов мультимедиа, чтобы повысить вероятность взаимодействия, когда возможности удаленной почтовой системы неизвестны. Поскольку типы носителей используются в новых средах, в которых распространение типов носителей не является препятствием для взаимодействия, первоначальная процедура оказалась чрезмерно ограничительной и должна была быть обобщена. Первоначально это было сделано в [RFC2048 #], но определенная там процедура все еще была частью набора документов MIME. Спецификация типа носителя и процедура регистрации теперь являются отдельным документом, чтобы прояснить, что он не зависит от MIME.

Может быть желательно ограничить использование типов мультимедиа конкретными средами или запретить их использование в других средах. Эта спецификация систематически включает такие ограничения в регистрации типов носителей. См. Раздел 4.9 для дополнительного обсуждения.

1.2. Соглашения, используемые в этом документе

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

В этой спецификации используется нотация расширенной формы Бэкуса-Наура (ABNF) [RFC5234 #], включая основные правила, определенные в Приложении B этого документа.

 

2. Предварительные условия регистрации типа носителя

Регистрация нового типа или типа носителя начинается с составления заявки на регистрацию. Регистрация может происходить в нескольких разных деревьях регистрации, которые имеют разные требования, как описано ниже. Как правило, новое предложение о регистрации распространяется и рассматривается таким образом, который соответствует древовидной структуре. Тип носителя затем регистрируется, если предложение приемлемо. В следующих разделах описываются требования и процедуры, используемые для каждого из различных деревьев регистрации.

 

3. Деревья регистрации и названия подтипов

Чтобы повысить эффективность и гибкость процесса регистрации, могут быть зарегистрированы различные структуры имен подтипов для удовлетворения различных естественных требований, например, для подтипа, который будет рекомендован для широкой поддержки и реализации интернет-сообществом, или подтипа который используется для перемещения файлов, связанных с патентованным (proprietary) программным обеспечением. Следующие подразделы определяют регистрационные «деревья», которые различаются использованием граненых имен, например, имен подтипов, которые начинаются с префикса «tree.». Обратите внимание, что некоторые типы носителей, определенные до этого документа, не соответствуют соглашениям об именах, описанным ниже. См. Приложение А для их обсуждения.

 

3.1. Дерево Стандартов

Дерево стандартов предназначено для типов, представляющих общий интерес для интернет-сообщества. Регистрации в дереве стандартов ДОЛЖНЫ быть:

1. в случае регистраций, связанных со спецификациями IETF, утвержденных непосредственно IESG,
2. зарегистрирован признанной организацией, связанной со стандартами, с использованием политики регистрации IANA «Требуется спецификация» [RFC5226 #] (что подразумевает экспертизу).

Первая процедура используется для регистрации в документах IETF Consensus, или в редких случаях, когда регистрация дедушкина (см. Приложение A) и/или иная неполная регистрация в интересах интернет-сообщества. Предложение о регистрации ДОЛЖНО быть опубликовано как RFC. Когда RFC регистрации находится в потоке IETF, у него должен быть Консенсус IETF, который может быть достигнут со статусом Отслеживания Стандартов, BCP, Информационного или Экспериментального. Регистрация, опубликованная не в IETF RFC-потоках, также разрешена и требует одобрения IESG. Регистрация может быть либо в отдельном RFC «только для регистрации», либо включена в более общую спецификацию какого-либо рода.

Во втором случае IESG принимает единовременное решение о том, представляет ли заявитель регистрации признанную организацию, связанную со стандартами; после этого рецензент типов носителей (назначенный эксперт или группа назначенных экспертов) выполняет проверку экспертов, как указано в этом документе. Последующие представления из того же источника не включают IESG. Формат ДОЛЖЕН быть описан формальной спецификацией стандартов, подготовленной представленной организацией, связанной со стандартами.

Типы мультимедиа в дереве стандартов НЕ ДОЛЖНЫ иметь граненые имена, если только они не используются в процессе, описанном в Приложении А.

Предполагается, что «владельцем» типа носителя, зарегистрированного в дереве стандартов, является сама организация, связанная со стандартами. Модификация или изменение спецификации использует тот же уровень обработки (например, регистрация, представленная на отслеживании стандартов, может быть пересмотрена в другом RFC отслеживания стандартов, но не может быть пересмотрена в информационном RFC), необходимая для начальной регистрации.

Регистрации дерева стандартов от признанных организаций, связанных со стандартами, передаются непосредственно в IANA, где они проходят экспертизу [RFC5226 #] до утверждения. В этом случае эксперт-рецензент (ы), помимо прочего, обеспечит, чтобы требуемая спецификация обеспечивала адекватную документацию.

 

3.2. Дерево Продавца

Дерево поставщиков используется для типов носителей, связанных с общедоступными продуктами. «Поставщик» (Vendor) и «производитель» (Producer) в этом контексте толкуются очень широко и считаются эквивалентными. Обратите внимание, что отраслевые консорциумы, а также некоммерческие организации, которые не могут быть признаны признанными организациями, связанными со стандартами, могут вполне соответствующим образом регистрировать типы носителей в дереве поставщиков.

Регистрация может быть размещена в дереве поставщиков любым, кому необходимо обмениваться файлами, связанными с каким-либо продуктом или набором продуктов. Тем не менее, регистрация должным образом принадлежит поставщику или организации, производящей программное обеспечение, которое использует тип регистрируемого, и этот поставщик или организация может в любое время принять решение утвердить право собственности на регистрацию, выполненную третьей стороной, чтобы исправить или обновить ее. См. Раздел 5.5 для получения дополнительной информации.

Когда третье лицо регистрирует тип от имени другого лица, оба объекта ДОЛЖНЫ быть отмечены в поле Change Controller при регистрации. Одним из возможных форматов для этого будет «Foo, от имени Bar» (Foo, on behalf of Bar).

Регистрации дерева поставщиков будут отличаться по ведущему фасету «vnd.» Это может сопровождаться по усмотрению владельца регистрации либо именем подтипа носителя от известного производителя (например, «vnd.mudpie»), либо одобренным IANA обозначением имени производителя, за которым следует носитель тип или обозначение продукта (например, vnd.bigcompany.funnypictures).

Хотя публичное раскрытие и проверка типов носителей, которые должны быть зарегистрированы в дереве поставщиков, не требуются, рекомендуется использовать список рассылки media-types@iana.org для проверки, чтобы улучшить качество этих спецификаций. Регистрации в дереве поставщиков могут быть отправлены непосредственно в IANA, где они будут проходить экспертизу [RFC5226 #] до утверждения.

 

3.3. Личное или Тщеславие Дерево

Регистрация для типов носителей, созданных экспериментально или в составе продуктов, которые не распространяются на коммерческой основе, может быть зарегистрирована в дереве личных данных или тщеславии. Регистрации различаются по ведущему аспекту «prs.».

Владельцем «личных» (personal) регистраций и связанных с ними спецификаций является физическое или юридическое лицо, осуществляющее регистрацию, или лицо, которому передана ответственность, как описано ниже.

Хотя публичное раскрытие и просмотр типов носителей, которые должны быть зарегистрированы в личном дереве, не требуются, рекомендуется использовать список рассылки media-types@iana.org (см. Раздел 5.1) для проверки, чтобы улучшить качество этих спецификаций. Регистрации в персональном дереве могут быть отправлены непосредственно в IANA, где они будут проходить экспертизу [RFC5226 #] до утверждения.

 

3.4. Незарегистрированный «х.» дерево

Имена подтипов с «х». в качестве первого аспекта могут использоваться типы, предназначенные исключительно для использования в частных, локальных средах. Типы в этом дереве не могут быть зарегистрированы и предназначены для использования только при активном согласии сторон, обменивающихся ими.

Тем не менее, с упрощенными процедурами регистрации, описанными выше для поставщиков и личных деревьев, редко, если вообще необходимо, использовать незарегистрированные типы. Поэтому использование типов в «х». Дерево сильно не рекомендуется.

Обратите внимание, что типы с именами, начинающимися с «x-», больше не считаются членами этого дерева (см. [RFC6648 #]). Также обратите внимание, что если обычно полезный и широко развернутый тип неправильно заканчивается префиксом «x-», он МОЖЕТ быть зарегистрирован с использованием своего текущего имени в альтернативном дереве, следуя процедуре, определенной в Приложении A.

 

3.5. Дополнительные регистрационные деревья

Время от времени и в соответствии с требованиями сообщества могут быть созданы новые деревья регистрации верхнего уровня с помощью действия IETF Standards. Предполагается, что эти деревья могут быть созданы для внешней регистрации и управления известными постоянными организациями; например, научные общества могут регистрировать типы СМИ, относящиеся к тем наукам, которые они освещают. В целом качество рассмотрения спецификаций для одного из этих дополнительных деревьев регистрации, как ожидается, будет эквивалентно регистрации в дереве стандартов признанной организацией, связанной со стандартами. Когда IETF проводит такой анализ, ему необходимо учитывать больший опыт запрашивающей организации в отношении предметного типа носителя.

 

4. Требования к регистрации

Ожидается, что все регистрации типов носителей будут соответствовать различным требованиям, изложенным в следующих разделах. Обратите внимание, что специфика требований иногда варьируется в зависимости от дерева регистрации, опять же, как подробно описано в следующих разделах.

4.1. Требование функциональности

Типы носителей ДОЛЖНЫ функционировать как фактические форматы носителей. Регистрация вещей, которые лучше рассматривать как кодировку передачи, как кодировку или как набор отдельных объектов другого типа, не допускается. Например, хотя существуют приложения для декодирования кодирования передачи base64 [RFC2045 #], base64 нельзя зарегистрировать как тип носителя.

Это требование применяется независимо от дерева регистрации.

4.2. Требования к именованию

Всем зарегистрированным типам мультимедиа ДОЛЖНЫ быть присвоены имена типов и подтипов верхнего уровня. Комбинация этих имен служит для уникальной идентификации типа носителя, а фасет имени подтипа (или его отсутствие) идентифицирует дерево регистрации. И имена типов и подтипов верхнего уровня нечувствительны к регистру.

Имена типов и подтипов ДОЛЖНЫ соответствовать следующему ABNF:

type-name = restricted-name
subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Символы перед первой точкой всегда указывают имя фасета
restricted-name-chars =/ "+" ; Символы после последнего плюса всегда указывают суффикс структурированного синтаксиса

Обратите внимание, что этот синтаксис является несколько более ограничительным, чем тот, который разрешен ABNF в Разделе 5.1 [RFC2045 #] или Разделе 4.2 [RFC4288 #]. Также обратите внимание, что хотя этот синтаксис допускает имена длиной до 127 символов, ограничения реализации могут сделать такие длинные имена проблематичными. По этой причине <type-name> и <subtype-name> ДОЛЖНЫ быть ограничены 64 символами.

Хотя синтаксис имени относится к «.» как эквивалент любого другого символа, символов перед любым начальным символом «.» всегда указывайте фасет регистрации. Обратите внимание, что это означает, что в стандартных безлимитных регистрациях нельзя использовать точки в имени подтипа.

Точно так же, последний «+» в имени подтипа вводит суффикс спецификатора структурированного синтаксиса. Требования к суффиксам структурированного синтаксиса указаны в разделе 4.2.8.

Хотя данному типу мультимедиа можно назначить дополнительные имена, использование разных имен для идентификации одного и того же типа мультимедиа не рекомендуется.

Эти требования применяются независимо от дерева регистрации.

Выбор типа верхнего уровня ДОЛЖЕН учитывать природу используемого типа носителя. Новые подтипы типов верхнего уровня ДОЛЖНЫ соответствовать ограничениям типа верхнего уровня, если таковые имеются. В следующих разделах описывается каждый из начального набора типов верхнего уровня и связанные с ним ограничения. Кроме того, различные протоколы, включая, помимо прочего, HTTP и MIME, МОГУТ накладывать дополнительные ограничения на типы носителей, которые они могут транспортировать. (См. [RFC2046 #] для получения дополнительной информации об ограничениях, налагаемых MIME.)

4.2.1. Медиа Типы Текстов

Тип «text» верхнего уровня предназначен для отправки материала, который имеет преимущественно текстовую форму.

Многие подтипы текста, в частности, включая подтип «text/plain», который является общим подтипом для простого текста, определенного в [RFC2046 #], определяют параметр «charset». Если параметр «charset» определен для конкретного подтипа текста, он ДОЛЖЕН использоваться для указания имени набора символов, определенного в соответствии с процедурами, изложенными в [RFC2978 #].

Как указано в [RFC6657 #], параметр «charset» НЕ СЛЕДУЕТ указывать, когда информация о charset транспортируется внутри полезной нагрузки (например, как в «text/xml»).

Если указан параметр «charset», он ДОЛЖЕН быть обязательным параметром, исключая варианты указания значения по умолчанию. Если есть веская причина, по которой параметр является необязательным, несмотря на этот совет, каждый подтип МОЖЕТ указывать свое собственное значение по умолчанию или, альтернативно, он МОЖЕТ указывать, что значение по умолчанию отсутствует. Наконец, кодировку «UTF-8» [RFC3629 #] СЛЕДУЕТ выбрать по умолчанию. См. [RFC6657 #] для получения дополнительной информации об использовании параметров «charset» в сочетании с подтипами текста.

Независимо от того, какой подход выбран, все новые регистрации «text/*» ДОЛЖНЫ четко указывать, как определяется кодировка; полагаться на стандарт US-ASCII, определенный в Разделе 4.1.2 [RFC2046 #], больше не разрешается. Если необходим пояснительный текст, его СЛЕДУЕТ разместить в разделе дополнительной информации регистрации.

Обычный текст не предусматривает и не разрешает команды форматирования, спецификации атрибутов шрифта, инструкции по обработке, директивы интерпретации или разметку содержимого. Обычный текст рассматривается просто как линейная последовательность символов, возможно прерываемая разрывом строки или разрывом страницы. Обычный текст МОЖЕТ разрешать размещение нескольких символов в одной и той же позиции в тексте. Обычный текст в таких сценариях, как арабский и иврит, также может включать средства, позволяющие произвольно смешивать сегменты текста с разными направлениями письма.

Помимо простого текста, существует много форматов для представления того, что может быть известно как «расширенный текст» (rich text). Интересной характеристикой многих таких представлений является то, что они в некоторой степени читаемы даже без программного обеспечения, которое их интерпретирует. На самом высоком уровне полезно отличать их от таких нечитаемых данных, как изображения, аудио или текст, представленные в нечитаемой форме. При отсутствии соответствующего программного обеспечения для интерпретации целесообразно представлять пользователю подтипы «text», в то время как это нецелесообразно делать с большинством нетекстовых данных. Такие отформатированные текстовые данные могут быть представлены с использованием подтипов «текст».

4.2.2. Медиа Типы Изображений

Тип верхнего уровня «image» означает, что в контенте указано одно или несколько отдельных изображений. Подтип называет определенный формат изображения.

4.2.3. Медиа Типы Аудио

Тип верхнего уровня «audio» указывает, что контент содержит аудиоданные. Подтип именует конкретный аудиоформат.

4.2.4. Медиа Типы Видео

Тип верхнего уровня «video» указывает, что контент определяет изображение с изменяющимся во времени изображением, возможно, с цветом и согласованным звуком. Термин «видео» используется в его наиболее общем смысле, а не в отношении какой-либо конкретной технологии или формата, и не предназначен для исключения подтипов, таких как компактные анимированные рисунки.

Следует отметить, что, хотя в целом смешивание нескольких видов мультимедиа в одном теле не рекомендуется [RFC2046 #], признается, что многие форматы видео включают в себя представление для синхронизированного аудио и / или текста, и это явно разрешено для подтипов «video».

4.2.5. Медиа Типы Приложений

Тип верхнего уровня «application» должен использоваться для дискретных данных, которые не соответствуют ни одному из имен других типов, и, в частности, для данных, обрабатываемых прикладной программой какого-либо типа. Это информация, которая должна быть обработана приложением, прежде чем оно будет доступно для просмотра или использования пользователем. Ожидаемое использование имени типа «приложение» включает, но не ограничивается передачей файлов, электронными таблицами, презентациями, данными планирования и языками для «активного» (вычислительного) материала. (Последнее, в частности, может создавать проблемы безопасности, которые должны понимать разработчики. Регистрация типа носителя «application/postscript» в [RFC2046 #] предоставляет хороший пример того, как справиться с этими проблемами.)

Например, планировщик собрания может определить стандартное представление для информации о предлагаемых датах собрания. Интеллектуальный пользовательский агент использует эту информацию для ведения диалога с пользователем, а затем может отправлять дополнительные материалы на основе этого диалога. В более общем плане было разработано несколько «активных» языков, на которых программы на соответствующем специализированном языке переносятся в удаленное местоположение и автоматически запускаются в среде получателя. Такие приложения могут быть определены как подтипы типа верхнего уровня «application».

Подтип «приложение» часто будет либо именем, либо частью имени приложения, для которого предназначены данные. Это не означает, однако, что любое имя прикладной программы может просто использоваться свободно как подтип «application»; подтип должен быть зарегистрирован.

4.2.6. Медиа Типы Составных частей и Сообщений

«Multipart» и «message» являются составными типами; то есть они обеспечивают средство инкапсуляции нуля или более объектов, каждый из которых имеет отдельный тип носителя.

Все подтипы multipart и сообщения ДОЛЖНЫ соответствовать правилам синтаксиса и другим требованиям, указанным в [RFC2046 #] и дополненным Разделом 3.5 [RFC6532 #].

4.2.7. Дополнительные типы верхнего уровня

В некоторых случаях новый тип мультимедиа может не соответствовать ни одному из определенных на данный момент имен типов верхнего уровня. Ожидается, что такие случаи будут довольно редкими. Однако, если такой случай действительно возникает, новое имя типа может быть определено, чтобы приспособить его. Определение нового имени типа верхнего уровня ДОЛЖНО быть выполнено через RFC «Трек стандартов»; Никакой другой механизм не может быть использован для определения дополнительных имен типов.

4.2.8. Суффиксы имен структурированных синтаксисов

XML в MIME [RFC3023 #] определил первое такое дополнение к определению типа носителя, чтобы дополнительно указать базовую структуру этого типа носителя. Цитировать:

В этом документе также стандартизировано соглашение (с использованием суффикса ’+ xml’) для именования типов мультимедиа … когда эти типы мультимедиа представляют объекты XML MIME (многоцелевые расширения почты Интернета).

То есть он указал суффикс (в этом случае «+ xml»), который будет добавлен к имени базового подтипа.

С тех пор, как это было опубликовано, возникла де-факто практика использования этого соглашения о суффиксах для других хорошо известных синтаксисов структурирования. В частности, типы носителей были зарегистрированы с суффиксами, такими как «+ der», «+ fastinfoset» и «+ json». Эта спецификация формализует эту практику и устанавливает реестр для суффиксов имен структурированных типов.

Основное правило для регистрации суффикса имени структурированного типа заключается в том, что он должен быть описан с помощью легкодоступного описания, предпочтительно в документе, опубликованном установленной организацией, связанной со стандартами, и для которого есть ссылка, которая может использоваться в нормативных ссылках. раздел RFC.

Типы мультимедиа, использующие именованный структурированный синтаксис, ДОЛЖНЫ использовать соответствующий зарегистрированный «+ суффикс» для этого структурированного синтаксиса при регистрации. Точно так же типам носителей НЕ ДОЛЖНЫ быть присвоены имена, содержащие суффиксы для структурированных синтаксисов, которые они фактически не используют. Конструкции «+ суффикс» для пока еще не зарегистрированных структурированных синтаксисов НЕ ДОЛЖНЫ использоваться, учитывая возможность конфликтов с будущими определениями суффиксов.

4.2.9. Устаревшие псевдонимы

В некоторых случаях один тип носителя может широко использоваться до регистрации под несколькими именами. В таких случаях предпочтительное имя ДОЛЖНО быть выбрано для типа носителя, и приложения ДОЛЖНЫ использовать это, чтобы соответствовать регистрации типа. Тем не менее, список устаревших псевдонимов, по которым тип известен, МОЖЕТ быть представлен в качестве дополнительной информации, чтобы помочь приложениям в правильной обработке типа носителя.

 

4.3. Требования к параметрам

Типы мультимедиа МОГУТ выбрать использование одного или нескольких параметров типа мультимедиа, или некоторые параметры могут быть автоматически доступны для типа мультимедиа в силу того, что они являются подтипом типа контента, который определяет набор параметров, применимых к любому из его подтипов. В любом случае имена, значения и значения любых параметров ДОЛЖНЫ быть полностью определены, когда тип носителя зарегистрирован в дереве стандартов, и ДОЛЖНЫ быть указаны максимально полно, когда типы носителей зарегистрированы в поставщике или в личных деревьях.

Имена параметров имеют синтаксис в качестве имен и значений медиа-типов:

parameter-name = restricted-name

Обратите внимание, что этот синтаксис несколько более ограничен, чем тот, который разрешен ABNF в [RFC2045 #] и изменен в [RFC2231 #].

Имена параметров нечувствительны к регистру и не имеют никакого значения в порядке их появления. Ошибка в том, что определенный параметр указывается более одного раза.

Не определен синтаксис для значений параметров. Следовательно, регистрации ДОЛЖНЫ указывать синтаксис значения параметра. Кроме того, некоторые транспорты накладывают ограничения на синтаксис значения параметра, поэтому необходимо соблюдать осторожность, чтобы ограничить использование потенциально проблемных синтаксисов; например, чистые двоичные параметры, хотя и разрешены в некоторых протоколах, лучше избегать.

Обратите внимание, что протокол может накладывать дополнительные ограничения на синтаксис значения параметра в зависимости от того, как он выбирает представление параметров. И MIME [RFC2045 #] [RFC2231 #], и HTTP [RFC2045 #] [RFC5987 #] допускают двоичные параметры, а также значения параметров, выраженные в определенной кодировке, но другие протоколы могут быть менее гибкими.

Новые параметры НЕ СЛЕДУЕТ определять как способ введения новых функциональных возможностей в типы, зарегистрированные в дереве стандартов, хотя МОГУТ быть добавлены новые параметры для передачи дополнительной информации, которая в противном случае не изменяет существующие функциональные возможности. Примером этого может быть параметр «редакция» (revision), указывающий уровень редакции внешней спецификации, такой как JPEG. Подобное поведение рекомендуется для типов носителей, зарегистрированных в поставщике или личных деревьях, но не обязательно.

Изменения параметров (включая введение новых) управляются так же, как и другие изменения типа носителя; см. раздел 5.5.

4.4. Каноникализация и требования к формату

Все зарегистрированные типы мультимедиа ДОЛЖНЫ использовать один канонический формат данных независимо от дерева регистрации.

Постоянная и общедоступная спецификация формата для типа носителя ДОЛЖНА существовать для всех типов, зарегистрированных в дереве стандартов. Эта спецификация ДОЛЖНА предоставлять достаточно подробностей, чтобы была возможна совместимость между независимыми реализациями, использующими тип медиа. На эту спецификацию ДОЛЖНЫ быть как минимум ссылки, если она фактически не включена в само предложение о регистрации типа носителя.

Спецификации формата и особенности обработки могут быть или не быть общедоступными для типов мультимедиа, зарегистрированных в поставщике и личных деревьях. Такие регистрации явно разрешают ограничивать информацию в регистрации, с которой программное обеспечение и версия производят или обрабатывают такие типы носителей. Таким образом, ссылки или включение спецификаций формата в регистрации приветствуются, но не обязательны. Тем не менее, обратите внимание, что общедоступная значимая спецификация будет часто иметь значение между простым зарезервированным именем, чтобы не было конфликтов с другими видами использования, и наличием потенциала для других реализаций типа носителя и полезного взаимодействия с ними.

Некоторые типы носителей предполагают использование запатентованной технологии. Регистрация типов носителей с запатентованной технологией специально разрешена. Однако ограничения, установленные в BCP 79 [RFC3979 #] и BCP 78 [RFC5378 #] в отношении использования запатентованной технологии в протоколах IETF Track Standards, должны соблюдаться, когда спецификация типа носителя является частью протокола Standards Track. Кроме того, другие связанные со стандартами организации, использующие дерево стандартов, могут иметь свои собственные правила в отношении интеллектуальной собственности, которые должны соблюдаться при их регистрации.

Раскрытие информации о правах на интеллектуальную собственность (IPR) для регистрации в поставщике и личных деревьях приветствуется, но не требуется.

 

4.5. Рекомендации по обмену

В идеале типы носителей должны быть определены, чтобы они могли взаимодействовать с максимально возможным количеством систем и приложений. Однако некоторые типы носителей неизбежно будут иметь проблемы с взаимодействием на разных платформах. Проблемы с различными версиями, порядком байтов и особенностями обработки шлюза могут и будут возникать.

Универсальная совместимость типов мультимедиа не требуется, но известные проблемы взаимодействия ДОЛЖНЫ быть идентифицированы, когда это возможно. Публикация медиа-типа не требует исчерпывающего анализа функциональной совместимости, и раздел, посвященный вопросам функциональной совместимости, подлежит дальнейшей оценке.

Рекомендации в этом подразделе применяются независимо от дерева регистрации.

 

4.6. Требования безопасности

Анализ проблем безопасности ДОЛЖЕН быть сделан для всех типов, зарегистрированных в дереве стандартов. Подобный анализ для типов носителей, зарегистрированных в поставщике или личных деревьях, рекомендуется, но не обязателен. Однако независимо от того, какой анализ безопасности был или не был выполнен, все описания проблем безопасности ДОЛЖНЫ быть максимально точными, независимо от дерева регистрации. В частности, в соображениях безопасности НЕ ДОЛЖНО указываться, что «с этим типом проблем не связано». Соображения безопасности для типов в поставщике или в личном дереве МОГУТ сказать, что «проблемы безопасности, связанные с этим типом, не были оценены».

Абсолютно не требуется, чтобы типы мультимедиа, зарегистрированные в любом дереве, были безопасными или полностью свободными от рисков. Тем не менее, все известные угрозы безопасности ДОЛЖНЫ быть идентифицированы при регистрации типа носителя, опять же, независимо от дерева регистрации.

Раздел соображений безопасности всех регистраций подлежит постоянной оценке и изменению и, в частности, МОЖЕТ быть расширен за счет использования механизма «комментариев к типам мультимедиа», описанного в разделе 5.4 ниже.

Вот некоторые из проблем, которые необходимо изучить и описать в анализе безопасности типа носителя:

• Сложные типы носителей могут включать положения для директив, которые инициируют действия с файлами получателя или другими ресурсами. Во многих случаях инициаторам предоставляется возможность произвольно указывать произвольные действия, которые затем могут иметь разрушительные последствия. См. Регистрацию типа носителя application/postscript в [RFC2046 #] для примера таких директив и того, как их можно описать при регистрации типа носителя.
• Любой анализ безопасности ДОЛЖЕН указывать, используют ли они такой «активный контент»; если они это сделают, они ДОЛЖНЫ указать, какие шаги были предприняты или ДОЛЖНЫ быть предприняты приложениями мультимедийного типа, чтобы защитить пользователей мультимедийного типа от вреда.
• Сложные типы носителей могут включать положения о директивах, которые инициируют действия, которые, хотя и не наносят прямого ущерба получателю, могут привести к раскрытию информации, которая либо облегчает последующую атаку, либо каким-либо образом нарушает конфиденциальность получателя. Опять же, регистрация типа носителя application/postscript иллюстрирует, как такие директивы могут обрабатываться.
• Тип носителя, который использует сжатие, может предоставить возможность для отправки небольшого объема данных, который, когда он получен и оценен, значительно расширяется, чтобы потреблять все ресурсы получателя. Все типы носителей ДОЛЖНЫ указать, используют ли они сжатие или нет; если они это сделают, им СЛЕДУЕТ обсудить, какие шаги необходимо предпринять, чтобы избежать таких атак.
• Тип носителя может быть нацелен на приложения, которые требуют какой-либо гарантии безопасности, но сами не обеспечивают необходимые механизмы безопасности. Например, тип носителя может быть определен для хранения конфиденциальной медицинской информации, которая, в свою очередь, требует внешних служб конфиденциальности и защиты целостности, или которая предназначена для использования только в безопасной среде. Типы ДОЛЖНЫ всегда документировать, нуждаются ли они в таких услугах из соображений безопасности.

 

4.7. Требования, специфичные для Медиа типов XML

Существует ряд дополнительных требований, специфичных для регистрации типов носителей XML. Эти требования указаны в [RFC3023 #].

 

4.8. Требования к кодировке

Некоторые виды транспорта накладывают ограничения на тип данных, которые они могут переносить. Например, интернет-почта традиционно была ограничена 7-битным текстом US-ASCII. Схемы кодирования часто используются для обхода таких транспортных ограничений.

Поэтому полезно отметить, из какого рода данных может состоять тип носителя в процессе его регистрации. Для этой цели предусмотрено поле «Вопросы кодирования». Возможные значения этого поля:

• 7bit: содержимое типа мультимедиа состоит исключительно из 7-битного текста CRLFdelimited US-ASCII.
• 8bit: Содержимое мультимедийного типа состоит исключительно из 8-битного текста CRLFdelimited.
• binary: содержимое состоит из неограниченной последовательности октетов.
• framed: контент состоит из серии кадров или пакетов без внутренних кадров или индикаторов выравнивания. Дополнительная внеполосная информация необходима для правильной интерпретации данных, включая, но не ограничиваясь, знание границ между последовательными кадрами и знание транспортного механизма. Обратите внимание, что типы мультимедиа такого типа не могут просто храниться в файле или передаваться в виде простого потока октетов; поэтому такие типы носителей не подходят для использования во многих традиционных протоколах. Обычно используемый транспорт с кодированным кадром — это транспортный протокол реального времени, RTP. Дополнительные правила для кодированных кадров, определенных для транспорта с использованием RTP, приведены в [RFC4855 #].

Дополнительные ограничения для 7-битного и 8-битного текста приведены в разделе 4.1.1 [RFC2046 #].

 

4.9. Использование и внедрение не требует

В асинхронной почтовой среде, где информация о возможностях удаленного почтового агента часто недоступна отправителю, максимальная совместимость достигается за счет ограничения используемых типов носителей теми «общими» форматами, которые, как ожидается, будут широко реализованы. Это утверждалось в прошлом как причина для ограничения количества возможных типов носителей и привело к процессу регистрации со значительным препятствием и задержкой для тех, кто регистрирует типы носителей.

Однако необходимость в «общих» типах мультимедиа не требует ограничения регистрации новых типов мультимедиа. Если для определенного приложения рекомендуется ограниченный набор типов носителей, это должно быть подтверждено отдельным заявлением о применимости, специфичным для приложения и / или среды.

Следовательно, универсальная поддержка и реализация медиа-типа НЕ являются требованием для регистрации. Однако, если тип носителя явно предназначен для ограниченного использования, это ДОЛЖНО быть отмечено при его регистрации. Для этого предусмотрено поле «Ограничения на использование». (Restrictions on Usage)

 

4.10. Требования к публикации

Типы носителей, зарегистрированные в дереве стандартов самой IETF, ДОЛЖНЫ быть опубликованы как RFC. Публикация RFC регистрации поставщиков и персональных носителей разрешена, но не обязательна. Во всех случаях IANA сохраняет копии всех регистраций типов носителей и «публикует» их как часть самого дерева регистрации типов носителей.

Как указывалось ранее, регистрации в дереве стандартов для типов носителей, определенных в документах, подготовленных другими организациями, связанными со стандартами, ДОЛЖНЫ быть описаны в официальной спецификации стандартов, подготовленной этой организацией. Кроме того, любое авторское право на шаблон регистрации ДОЛЖНО позволять IANA копировать его в реестр IANA.

Кроме регистраций IETF в дереве стандартов, регистрация типа носителя не подразумевает одобрения, одобрения или рекомендации IANA или IETF или даже подтверждения того, что спецификация адекватна. Чтобы стать стандартом IETF, протокол или объект данных должны пройти процесс стандартов IETF. Хотя это и дает дополнительные гарантии, когда это уместно, это слишком сложный и слишком длительный процесс для удобной регистрации типов носителей.

Дерево стандартов существует для типов носителей, которые требуют существенной проверки и одобрения в признанной организации, связанной со стандартами. Поставщик и личные деревья существуют для тех типов носителей, которые не требуют такого процесса. Ожидается, что заявления о применимости для конкретных приложений будут время от времени публиковаться в IETF, рекомендуя реализацию и поддержку типов носителей, которые оказались особенно полезными в этих контекстах.

Как обсуждалось выше, для регистрации типа верхнего уровня требуется действие по стандартизации в IETF и, следовательно, публикация RFC на дорожке стандартов.

4.11. Требования к идентификатору фрагмента

При регистрации типов мультимедиа можно указать, как приложения должны интерпретировать идентификаторы фрагментов (указанные в разделе 3.5 [RFC3986 #]), связанные с типом мультимедиа.

Типы медиа рекомендуется использовать схемы идентификаторов фрагментов, которые используются с семантически подобными типами медиа. В частности, типы мультимедиа, которые используют именованный структурированный синтаксис с зарегистрированным «+ суффиксом», ДОЛЖНЫ следовать любым правилам идентификатора фрагмента, указанным при регистрации суффикса структурированного синтаксиса.

4.12. Дополнительная информация

Различные виды дополнительной информации ДОЛЖНЫ быть включены в спецификацию типа носителя, если она доступна:

• o Магическое число (а) (длина, значения октетов). Магические числа представляют собой последовательности байтов, которые всегда присутствуют в заданном месте в файле и, таким образом, могут использоваться для идентификации объектов как принадлежащих данному типу носителя.
• o Расширение имени файла обычно используется на одной или нескольких платформах, чтобы указать, что какой-то файл содержит данный тип носителя.
• o Код (ы) типа файлов Mac OS (4 октета), используемые для маркировки файлов, содержащих данный тип носителя. Некоторое обсуждение кодов типов файлов Macintosh и их назначения можно найти в [MacOSFileTypes].

В случае регистрации в дереве стандартов эта дополнительная информация МОЖЕТ быть предоставлена в формальной спецификации формата носителя. Предполагается, что это будет сделано путем включения формы регистрации типа носителя IANA в саму спецификацию формата.

 

5. Процедура регистрации Медиа типа

Процедура регистрации типа носителя не является формальным процессом стандартизации, а скорее административной процедурой, предназначенной для того, чтобы позволить комментарии сообщества и проверку здравомыслия без чрезмерной задержки.

Обычные процессы IETF должны соблюдаться для всех регистраций IETF в дереве стандартов. Публикация интернет-проекта является необходимым первым шагом, за которым следует публикация в списке media-types@iana.org, как описано ниже.

5.1. Предварительный обзор сообщества

Уведомление о возможной регистрации типа носителя в дереве стандартов ДОЛЖНО быть отправлено в список рассылки media-types@iana.org для ознакомления. Этот список рассылки был создан с целью рассмотрения предлагаемых носителей и типов доступа. Регистрации в других деревьях МОГУТ также быть отправлены в список для просмотра; делать это ДОПОЛНИТЕЛЬНО, но настоятельно рекомендуется.

Целью публичной публикации в этом списке является получение комментариев и отзывов о выборе имени типа / подтипа, однозначности ссылок в отношении версий и информации о внешнем профилировании, а также проверка любых вопросов совместимости или безопасности. Заявитель может подать пересмотренное предложение о регистрации или отказаться от регистрации полностью и в любое время.

5.2. Отправить запрос в IANA

Типы носителей, зарегистрированные в дереве стандартов самой IETF, ДОЛЖНЫ быть рассмотрены и утверждены IESG как часть нормального процесса стандартизации. Регистрации дерева стандартов признанными организациями, связанными со стандартами, а также регистрации в поставщике и личных деревьях передаются непосредственно в IANA, если иное не было принято в рамках соглашения о взаимодействии. В любом случае настоятельно рекомендуется размещать регистрацию в списке media-types@iana.org для ознакомления до подачи заявки.

Заявки на регистрацию можно отправлять на iana@iana.org. Веб-форма для регистрации заявок также доступна:

http://www.iana.org/form/media-types

5.2.1. Предварительная регистрация

Процессы стандартизации часто занимают значительное время. Чтобы упростить создание прототипов и тестирование, часто полезно назначать идентификаторы, включая, но не ограничиваясь, типы носителей, в начале процесса. Таким образом, идентификаторы, используемые во время разработки стандартов, могут оставаться неизменными после завершения процесса, и реализации и документация не должны обновляться.

Соответственно, предоставляется предварительный процесс регистрации для поддержки раннего назначения имен типов мультимедиа в дереве стандартов. Предварительная регистрация МОЖЕТ быть представлена ​​в IANA для стандартных трех типов. Единственными обязательными полями в таких регистрациях являются название типа носителя и контактная информация (включая название организации, связанное со стандартами).

После получения предварительной регистрации IANA проверит имя и контактную информацию, а затем опубликует регистрацию в отдельном общедоступном предварительном списке регистрации.

Предварительные регистрации МОГУТ быть обновлены или отменены в любое время. Когда регистрация отменена, тип носителя больше не регистрируется ни в каком смысле; впоследствии оно может быть зарегистрировано так же, как любое другое неназначенное имя типа носителя.

5.3. Обзор и одобрение

За исключением предварительной регистрации в дереве стандартов, регистрации, представленные в IANA, будут переданы рецензенту типов носителей. Рецензент типов носителей, который назначается Директором (ями) Области Приложений IETF, проверит регистрацию, чтобы убедиться, что она соответствует требованиям, изложенным в этом документе. Регистрации, которые не соответствуют этим требованиям, будут возвращены отправителю для проверки.

Решения, принятые рецензентом типов носителей, могут быть обжалованы в IESG с использованием процедуры, указанной в разделе 6.5.4 [RFC2026 #].

После того как регистрация типа носителя прошла проверку, IANA зарегистрирует тип носителя и сделает регистрацию типа носителя доступной для сообщества.

В случае регистрации дерева стандартов от других организаций, связанных со стандартами, IANA также проверит, является ли податель фактически признанной организацией, связанной со стандартами. Если податель в настоящее время не признан таковым, IESG будет предложено подтвердить свой статус. Признание от IESG ДОЛЖНО быть получено до того, как регистрация дерева стандартов может быть продолжена.

 

5.4. Комментарии к регистрации Медиа типов

Комментарии к зарегистрированным типам носителей могут быть отправлены членами сообщества в IANA по адресу iana@iana.org. Эти комментарии будут рассмотрены рецензентом типов медиа, а затем будут переданы «владельцу» (owner) типа медиа, если это возможно. Авторы комментариев могут потребовать, чтобы их комментарии были прикреплены к самой регистрации типа носителя; Если IANA, после консультации с проверяющим тип медиа, одобрит комментарий, он будет доступен вместе с регистрацией типов.

 

5.5. Процедуры изменения

Как только тип носителя был опубликован IANA, владелец может запросить изменение его определения. Описания различных деревьев регистрации выше обозначают «владельцев» каждого типа регистрации. Для обработки запроса на изменение используется та же процедура, что и для исходного запроса на регистрацию.

Регистрации медиа-типов не могут быть удалены; типы носителей, которые больше не считаются подходящими для использования, могут быть объявлены OBSOLETE путем изменения их поля «предполагаемого использования» (intended use); такие типы носителей будут четко обозначены в списках, опубликованных IANA.

Значительные изменения в определении типа носителя следует запрашивать только в случае серьезных пропусков или ошибок в опубликованной спецификации. Когда требуется проверка, запрос на изменение может быть отклонен, если он делает объекты, которые были действительными в соответствии с предыдущим определением, недействительными в соответствии с новым определением.

Владелец типа носителя может передать ответственность другому лицу или агентству, сообщив об этом в IANA; это можно сделать без обсуждения или обзора.

IESG может перенести ответственность за тип носителя. Наиболее распространенным случаем этого будет включение изменений, которые могут быть внесены в типы, в которых автор регистрации умер, вышел из контакта или не может внести изменения, важные для сообщества.

 

5.6. Шаблон регистрации

Введите имя:
Название подтипа:
Обязательные параметры:
Необязательные параметры:
Вопросы кодирования:
Соображения безопасности:
Соображения совместимости:
Опубликованная спецификация:
Приложения, которые используют этот тип носителя:
Особенности идентификатора фрагмента:
Дополнительная информация:
Устаревшие псевдонимы для этого типа:
Магическое число (а):
Расширение файла (ов):

Код (ы) типов файлов для Macintosh:
Персона и адрес электронной почты для связи для получения дополнительной информации:
Предполагаемое использование:
(Один из ОБЩЕГО, ОГРАНИЧЕННОГО ИСПОЛЬЗОВАНИЯ или ОБЗОР.)
Ограничения на использование:
(Любые ограничения относительно того, где может использоваться тип носителя, приведены здесь.)
Автор:
Сменить контроллер:
Предварительная регистрация? (только дерево стандартов):

(Любая другая информация, которую автор считает интересной, может быть добавлена ниже этой строки.)

«N/A», написанное именно таким образом, может использоваться в любой области, если необходимо подчеркнуть тот факт, что оно не применяется или что вопрос не был опущен случайно. Не используйте «нет» или другие слова, которые могут быть ошибочно приняты за ответ.

Типы носителей с ограниченным использованием также должны указывать в списке приложений, является ли этот список исчерпывающим.

6. Процедуры регистрации структурированного синтаксического суффикса

Кто-то, желающий определить имя «+ суффикс» для структурированного синтаксиса для использования с новой регистрацией типа носителя, ДОЛЖЕН:

1. Проверьте реестр IANA суффиксов имен типов носителей, чтобы увидеть, есть ли уже запись для этого четко определенного структурированного синтаксиса.
2. Если для их суффиксной схемы нет записи, заполните шаблон (указанный в разделе 6.2) и включите его в регистрацию типа носителя. Шаблон может содержаться в интернет-проекте, отдельно или как часть какой-либо другой спецификации протокола. Шаблон также может быть представлен в какой-либо другой форме (как часть другого документа или как отдельный документ), но его содержание будет рассматриваться как «Вклад IETF» в соответствии с рекомендациями BCP 78 [RFC5378 #].
3. Отправьте копию шаблона или указатель на содержащийся документ (с конкретной ссылкой на раздел с шаблоном) в список рассылки media-types@iana.org, запросив рецензию. Это может сочетаться с запросом на проверку регистрации типа носителя. Предоставьте разумное время для обсуждения и комментариев.
4. Ответьте, чтобы рассмотреть комментарии и внести изменения в предлагаемую регистрацию по мере необходимости, чтобы привести ее в соответствие с руководящими принципами, приведенными в этом документе.
5. Отправьте (возможно, обновленный) шаблон регистрации (или указатель на содержащий его документ) в IANA по адресу iana@iana.org.

После получения запроса регистрации структурированного синтаксиса суффикса,

1. IANA проверяет представление на полноту; если разделы отсутствуют или цитаты не верны, IANA отклоняет запрос на регистрацию.
2. IANA проверяет текущий реестр на предмет записи с таким же именем; если такой реестр существует, IANA отклоняет запрос на регистрацию.
3. IANA запрашивает экспертизу запроса на регистрацию в соответствии с соответствующими рекомендациями.
4. Назначенный эксперт может при необходимости запросить дополнительную проверку или обсуждение.
5. Если экспертная проверка рекомендует регистрацию, IANA добавляет регистрацию в соответствующий реестр.

Исходная спецификация содержимого реестра [RFC6839] содержит примеры регистрации суффиксов структурированного синтаксиса.

6.1. Процедуры изменения

Регистрации могут обновляться в каждом реестре тем же механизмом, который требуется для первоначальной регистрации. В тех случаях, когда первоначальное определение схемы содержится в документе, утвержденном IESG, обновление спецификации также требует одобрения IESG.

6.2. Шаблон регистрации суффикса структурированного синтаксиса

Этот шаблон описывает поля, которые должны быть предоставлены в запросе регистрации суффикса структурированного синтаксиса:

Название (Name)

Полное имя четко определенного структурированного синтаксиса.

+ суффикс (+suffix)

Суффикс используется для указания соответствия синтаксису.

Ссылки (References)

Включите полные цитаты для всех спецификаций, необходимых для понимания структурированного синтаксиса.

Вопросы кодирования (Encoding considerations)

Общее руководство относительно соображений кодирования для любого типа, использующего этот синтаксис, должно быть дано здесь. Здесь применяются те же требования к соображениям кодирования медиа-типов, которые приведены в разделе 4.8.

Соображения совместимости (Interoperability considerations)

Любые вопросы, касающиеся совместимого использования типов, использующих этот структурированный синтаксис, должны быть приведены здесь. Примерами могут быть наличие несовместимых версий синтаксиса, проблемы, связанные с объединением определенных кодировок с синтаксисом, или несовместимость с другими типами или протоколами.

Особенности идентификатора фрагмента (Fragment identifier considerations)

Общая обработка идентификаторов фрагментов для любого типа, использующего этот синтаксис, должна быть описана здесь.

Соображения безопасности (Security considerations)

Здесь должны быть указаны соображения безопасности, общие для типов мультимедиа, использующих этот структурированный синтаксис. Здесь применимы те же требования к соображениям безопасности типов носителей, которые приведены в разделе 4.6, за исключением того, что для регистрации суффиксов недоступна опция не оценки соображений безопасности.

Контакт (Contact)

Лицо (включая контактную информацию), чтобы связаться для получения дополнительной информации.

Автор / Смена контроллера. (Author/Change controller.)

Лицо (включая контактную информацию), уполномоченное изменить этот суффикс регистрации.

7. Вопросы безопасности

Требования безопасности для регистрации типов носителей и суффиксов типов носителей обсуждаются в разделе 4.6.

8. Соображения IANA

Цель этого документа — определить реестры IANA для типов носителей и структурных суффиксов синтаксиса, а также процедуры для управления этими реестрами. Кроме того, этот документ требует от IANA вести список организаций, связанных со стандартами, для которых IESG утвердил регистрации типов носителей в дереве стандартов.

Существующий реестр типов носителей был расширен, чтобы включить раздел для предварительной регистрации. В дереве стандартов допускаются только регистрации в дереве стандартов и только по запросу организации из списка организаций, связанных со стандартами IANA. См. Раздел 5.2.1 для получения дополнительной информации о предварительной регистрации.

IANA также добавила следующую заметку вверху временного реестра:

Этот реестр, в отличие от некоторых других предварительных реестров IANA, предназначен только для временного использования. Записи в этом реестре либо завершаются и перемещаются в основной реестр типов носителей, либо удаляются и удаляются. Записи в этом реестре предназначены для использования только в целях разработки и тестирования.

Реестр суффиксов имени структурированного синтаксиса был создан следующим образом:

• Это имя реестра «Структурный суффикс синтаксиса».
• Процесс регистрации указан в разделе 6.
• Информация, необходимая для записи в реестре, а также формат записи указаны в разделе 6.2.
• Первоначальный контент реестра указан в [RFC6839 #].

Записи в реестрах как типов носителей, так и структурированных суффиксов будут помечены IANA как исходной датой регистрации, так и датой последнего обновления записи. Регистрации, сделанные до реализации данной спецификации, могут при необходимости помечаться как таковые, а не с конкретной датой.

Поскольку регистрационные записи могут обновляться несколько раз, IANA также будет вести историю изменений каждой регистрации таким образом, чтобы можно было определить состояние регистрации в любой момент времени.

Наконец, в соответствии с этим документом IANA создала новый адрес электронной почты media-types@iana.org для списка проверки типов носителей, который заменяет адрес ietf-types@iana.org, указанный в [RFC 4288 #]. ietf-types @ iana .org был сохранен как псевдоним.

9. Благодарности

Нынешние авторы хотели бы признать свою задолженность покойному доктору Джону Постелу, чья общая модель процедур регистрации в IANA и конкретные материалы сформировали предшественников этого документа [RFC2048 #] [RFC4288 #]. Мы надеемся, что нынешняя версия является той, с которой он согласился бы, но, поскольку невозможно проверить это соглашение, мы с сожалением удалили его имя в качестве соавтора.

Рэнди Буш, Фрэнсис Дюпон, Бьерн Хёрманн, Барри Лейба, Мюррей Кучерови, Алексей Мельников, С. Мунесами, Марк Ноттингем, Том Петч, Питер Сен-Андре и Джени Теннисон предоставили много полезных рецензий и комментариев.

10. Ссылки

10.1. Нормативные ссылки

[RFC2045] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.

[RFC2046] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types», RFC 2046, November 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2978] Freed, N. and J. Postel, «IANA Charset Registration Procedures», BCP 19, RFC 2978, October 2000.

[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, «XML Media Types», RFC 3023, January 2001.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC3979] Bradner, S., «Intellectual Property Rights in IETF Technology», BCP 79, RFC 3979, March 2005.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC4855] Casner, S., «Media Type Registration of RTP Payload Formats», RFC 4855, February 2007.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC5378] Bradner, S. and J. Contreras, «Rights Contributors Provide to the IETF Trust», BCP 78, RFC 5378, November 2008.

[RFC6532] Yang, A., Steele, S., and N. Freed, «Internationalized Email Headers», RFC 6532, February 2012.

[RFC6657] Melnikov, A. and J. Reschke, «Update to MIME regarding «charset» Parameter Handling in Textual Media Types», RFC 6657, July 2012.

[RFC6839] Hansen, T. and A. Melnikov, «Additional Media Type Structured Syntax Suffixes», RFC 6839, January 2013.

10.2. Информационные ссылки

[MacOSFileTypes] Apple Computer, Inc., «Mac OS: File Type and Creator Codes, and File Formats», Apple Knowledge Base Article 55381, June 1993, <http://www.info.apple.com/kbnum/n55381>.

[RFC2026] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, October 1996.

[RFC2048] Freed, N., Klensin, J., and J. Postel, «Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures», BCP 13, RFC 2048, November 1996.

[RFC2231] Freed, N. and K. Moore, «MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations», RFC 2231, November 1997.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC4288] Freed, N. and J. Klensin, «Media Type Specifications and Registration Procedures», BCP 13, RFC 4288, December 2005.

[RFC5987] Reschke, J., «Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters», RFC 5987, August 2010.

[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, «Deprecating the «X-» Prefix and Similar Constructs in Application Protocols», BCP 178, RFC 6648, June 2012.

Приложение А. Устаревшие Медиа типы

Некоторым типам носителей с неименованными именами подтипов, зарегистрированным до 1996 года, в случае регистрации в соответствии с руководящими принципами, приведенными в этом документе, будет присвоено имя с огранкой и они будут размещены либо в дереве поставщиков, либо в личных деревьях. Перерегистрация этих типов для отражения соответствующих деревьев рекомендуется, но не обязательна. Принципы владения и контроля изменений, изложенные в этом документе, применяются к этим типам, как если бы они были зарегистрированы в деревьях, описанных выше.

Время от времени могут также возникать случаи, когда тип носителя с неименованным именем подтипа широко используется без регистрации. (Обратите внимание, что это включает в себя имена подтипов, начинающиеся с префикса «x-».) Если возможно, такой тип носителя СЛЕДУЕТ перерегистрировать с правильным именем граненого подтипа, возможно, используя устаревший псевдоним для идентификации исходного имени (см. Раздел 4.2.9). ). Однако, если это невозможно, тип может, при условии одобрения как рецензентом типов носителей, так и IESG, быть зарегистрирован в соответствующем дереве с его безликим именем.

Приложение B. Изменения с RFC 4288

o Суффиксы, указывающие на использование определенного структурированного синтаксиса, теперь полностью определены и определен процесс регистрации суффикса.

o В настоящее время разрешена регистрация широко распространенных незарегистрированных имен незарегистрированных типов в поставщике или личных деревьях при условии одобрения рецензентом типов носителей и IESG.

o Процесс регистрации в дереве стандартов был пересмотрен с целью включения экспертизы и обобщен для рассмотрения случаев, подобных типам носителей, в потоковых документах, отличных от IETF.

o В шаблон регистрации было добавлено поле для идентификаторов фрагментов и добавлены краткие указания для указания идентификаторов фрагментов.

o Требования спецификации для регистраций личного дерева были изменены, чтобы быть такими же, как и для дерева поставщиков. Текст был изменен, чтобы поощрять (но не требовать) наличие спецификации.

o Процесс определения дополнительных деревьев был разъяснен, чтобы заявить, что требуется действие по стандартам IETF.

o Широко развернутые типы с именами «x-» теперь могут быть зарегистрированы как исключения в дереве поставщиков.

o Требования к изменениям в регистрациях были ослаблены, поэтому незначительные изменения легче сделать.

o Процесс регистрации был полностью реструктурирован, так что за исключением сгенерированных IETF типов в дереве стандартов все запросы обрабатываются IANA, а не IESG.

o Предварительная регистрация была добавлена ​​для раннего присвоения типов в дереве стандартов.

o В текст документа было внесено множество редакционных изменений, чтобы сделать описанные требования и процессы более понятными и легкими для понимания.

o Добавлена ​​возможность указывать список устаревших псевдонимов для типа носителя.

o Типы с именами, начинающимися с «x-», больше не считаются членами незарегистрированного «x». дерево. Как и в случае с любым другим типом, были добавлены специальные процедуры, позволяющие регистрировать такие типы в соответствующем дереве.

o Изменения в типе, зарегистрированном третьей стороной, теперь могут вносить назначенный контроллер изменений, даже если это не поставщик или организация, создавшая тип. Тем не менее, поставщик или организация может в любое время подтвердить право собственности и изменить тип контроллера.

o Теперь для типов носителей с ограниченным использованием требуется указать, является ли приведенный список приложений, использующих этот тип носителей, исчерпывающим.

o ABNF для имен типов носителей был дополнительно ограничен требованием, чтобы имена начинались с буквенно-цифрового символа.

o Просмотр списка рассылки больше не требуется до регистрации типов носителей. Кроме того, адрес, связанный со списком рассылки для проверки типов носителей, был изменен на media-types@iana.org.

o Правила для «text/*» типов носителей были обновлены, чтобы отразить изменения, указанные в [RFC6657 #].

Адреса авторов

Ned Freed
Oracle
800 Royal Oaks
Monrovia, CA 91016-6347
USA
EMail: ned+ietf@mrochek.com

John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
EMail: john+ietf@jck.com

Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA
EMail: tony+mtsuffix@maillennium.att.com