Media Feature Tag Registration Procedure
RFC 2506 определяет процедуру регистрации тегов характеристик медиа в центральном реестре IANA. Эти теги описывают отдельные возможности медиа либо свойства ресурса, связанные с возможностями или предпочтениями представления содержимого, и образуют общий словарь для механизмов идентификации и согласования характеристик. Документ задаёт синтаксис тегов, допустимые типы значений, правила регистрации и деревья регистрации IETF, global и URI. Для регистрации предусмотрен шаблон, включающий сведения об интероперабельности, безопасности и приватности.
Рабочая группа сети K. Holtman
Запрос комментариев: 2506 TUE
BCP: 31 A. Mutz
Категория: Лучшая современная практика Hewlett-Packard
T. Hardie
Equinix
Март 1999
Процедура регистрации тегов характеристик медиа
Статус этого меморандума
Этот документ определяет Лучшую современную практику Интернета для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (1999). Все права защищены.
АННОТАЦИЯ
Недавние Интернет-приложения, такие как Всемирная паутина, объединяют
большое разнообразие форматов данных, клиентских и серверных
платформ, а также сообществ. Это создало потребность в описаниях
характеристик медиа и механизмах согласования, чтобы идентифицировать
и привести форму информации в соответствие с возможностями и
предпочтениями вовлечённых сторон.
Расширяемые механизмы идентификации характеристик медиа и
согласования требуют общего словаря, чтобы однозначно идентифицировать
характеристики медиа. Определяются процесс регистрации и орган для
характеристик медиа с целью совместного использования этого словаря
между взаимодействующими сторонами. Кроме того, определяется дерево
URI, позволяющее совместно использовать определения характеристик
медиа без регистрации.
Этот документ определяет процедуру регистрации, использующую Internet
Assigned Numbers Authority (IANA) в качестве центрального реестра
словаря характеристик медиа.
Просьба направлять комментарии рабочей группе CONNEG по адресу <ietf-
medfree@imc.org>. Обсуждения рабочей группы архивируются по адресу
<URL: http://www.imc.org/ietf-medfree/>.
Holtman, et. al. Best Current Practice [Страница 1]
RFC 2506 Процедура регистрации тегов характеристик медиа Март 1999
СОДЕРЖАНИЕ
1 Введение .................................................... 2
2 Определения тегов характеристик медиа ....................... 3
2.1 Назначение тега характеристики медиа ..................... 3
2.2 Синтаксис тега характеристики медиа ...................... 4
2.3 Значения тегов характеристик медиа ...................... 4
2.4 Идентификаторы ASN.1 для тегов характеристик медиа ...... 5
3 Регистрация тегов характеристик медиа ...................... 5
3.1 Деревья регистрации ..................................... 6
3.1.1 Дерево IETF ........................................... 6
3.1.2 Глобальное дерево ..................................... 6
3.1.3 Дерево URI ............................................ 6
3.1.4 Дополнительные деревья регистрации .................... 7
3.2 Местонахождение списка зарегистрированных тегов характеристик медиа 7
3.3 Процедуры IANA по регистрации тегов характеристик медиа . 7
3.4 Шаблон регистрации ...................................... 7
4 Вопросы безопасности ....................................... 10
5 Благодарности ............................................... 10
6 Ссылки ...................................................... 10
7 Адреса авторов .............................................. 11
8 Полное заявление об авторских правах ........................ 12
1 Введение
Недавние Интернет-приложения, такие как Всемирная паутина, объединяют
большое разнообразие форматов данных, клиентских и серверных
платформ, а также сообществ. Это создало потребность в описаниях
характеристик медиа и механизмах согласования, чтобы идентифицировать
и привести форму информации в соответствие с возможностями и
предпочтениями вовлечённых сторон.
Расширяемые механизмы идентификации характеристик медиа и
согласования требуют общего словаря, чтобы однозначно идентифицировать
характеристики медиа. Определяются процесс регистрации и орган для
характеристик медиа с целью совместного использования этого словаря
между взаимодействующими сторонами. Кроме того, определяется дерево
URI, позволяющее совместно использовать определения характеристик
медиа без регистрации.
Этот документ определяет процедуру регистрации, использующую Internet
Assigned Numbers Authority (IANA) в качестве центрального реестра
словаря характеристик медиа.
В этом документе термины ДОЛЖЕН (MUST), НЕ ДОЛЖЕН (MUST NOT), СЛЕДУЕТ
(SHOULD), НЕ СЛЕДУЕТ (SHOULD NOT) и МОЖЕТ (MAY) используются в
соответствии с порядком употребления, описанным в [8].
Holtman, et. al. Best Current Practice [Страница 2]
RFC 2506 Процедура регистрации тегов характеристик медиа Март 1999
2 Определения тегов характеристик медиа
2.1 Назначение тега характеристики медиа
Теги характеристик медиа представляют отдельные и простые
характеристики, относящиеся к возможностям медиа или свойствам,
связанным с ресурсом, к которому они применяются. Примеры таких
характеристик:
* глубина цвета экрана, на котором что-либо должно отображаться
* тип бумаги, доступной в принтере
* поддержка характеристики `floating 5 dimensional tables'
* шрифты, доступные получателю
* возможность отображать графическое содержимое
Каждый тег характеристики медиа идентифицирует одну характеристику.
Значения, связанные с конкретным тегом, должны использовать тип
данных, определённый для этого тега. Список разрешённых типов данных
представлен ниже, в разделе 2.3.
Примеры тегов характеристик медиа со значениями:
* ширина дисплея в пикселях на сантиметр, представленная целым
числовым значением.
* шрифт, доступный получателю, выбранный из перечисляемого списка.
* версия протокола, состоящая из целых чисел "i.j.k", определённая
либо как значение в перечисляемом списке, либо с определённым
отображением, делающим значение изоморфным подмножеству целых чисел
(например, i*100 + j*10 +k, при допущении j<=9 и k<=9).
Дополнительные примеры тегов характеристик медиа подробно определены
в другом месте [4].
Коллекции характеристик могут составляться с использованием ряда
отдельных тегов характеристик [2]. Составление коллекций
характеристик описано в другом месте [2]. Примеры коллекций
характеристик, требующих нескольких тегов характеристик медиа:
* набор всех шрифтов, используемых документом
* ширина и высота дисплея
* сочетание глубины цвета и разрешения, которое может поддерживать дисплей
Этот реестр предполагает наличие реестра типов медиа MIME, и типы
медиа MIME НЕ ДОЛЖНЫ (MUST NOT) повторно регистрироваться как теги
характеристик медиа. Теги характеристик медиа, которые в настоящее
время используются отдельными протоколами или приложениями, МОГУТ
(MAY) быть зарегистрированы в этом реестре, если они могут
применяться за пределами их текущей области.
Holtman, et. al. Best Current Practice [Страница 3]
RFC 2506 Процедура регистрации тегов характеристик медиа Март 1999
Пространство имён тегов характеристик медиа не привязано к
конкретному транспортному протоколу или механизму обмена
возможностями. Однако реестр ограничен тегами характеристик,
выражающими возможность или предпочтение, относящиеся к тому, как
представляется содержимое. Теги характеристик, относящиеся к другим
осям согласования, не подходят для этого реестра. Механизмы обмена
возможностями, разумеется, могут использоваться для выражения
разнообразных возможностей или предпочтений.
2.2 Синтаксис тега характеристики медиа
Тег характеристики медиа — это строка, состоящая из одного или более
следующих символов US-ASCII: прописных букв, строчных букв, цифр,
двоеточия (":"), косой черты ("/"), точки ("."), процента ("%") и
дефиса ("-"). Теги характеристик нечувствительны к регистру. Точки
понимаются как потенциально обозначающие иерархию; характеристика
может быть подтипизирована описанием её как tree.feature.subfeature
и указанием этого при регистрации. Теги следует начинать с
алфавитного символа.
В ABNF [6] это может быть представлено так:
Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" )
Регистрантам следует позаботиться о том, чтобы не создавать теги,
которые могут конфликтовать с созданием новых деревьев регистрации;
в общем случае это означает избегать тегов, начинающихся с
алфавитного символа, за которым следует точка. Текущие деревья
регистрации описаны ниже, в разделе 3.
2.3 Значения тегов характеристик медиа
Реестр первоначально будет поддерживать использование следующих
типов данных в качестве значений тегов:
- знаковые целые числа
- рациональные числа
- токены с отношением равенства
- токены с определённым отношением порядка
- строки со стандартным отношением равенства (октет за октетом)
- строки с определённым отношением равенства и/или сравнения
"Токен" здесь означает тип данных token, определённый в [7], который
можно кратко представить так:
Holtman, et. al. Best Current Practice [Страница 4]
RFC 2506 Процедура регистрации тегов характеристик медиа Март 1999
token = 1*<any CHAR except CTLs or tspecials>
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT
Во время регистрации каждый тег должен быть связан с одним типом
данных. Если этот тип данных подразумевает определённое сравнение или
порядок, регистрант должен определить порядок или сравнение. Для
упорядоченных токенов это может быть сделано полным перечислением
токенов и их порядка или ссылкой на механизм упорядочения. Для
определённых сравнений должно быть предоставлено полное описание
правил сравнения либо включено по ссылке.
Теги характеристик медиа, относящиеся к пространственным или
временным характеристикам, должны регистрироваться с единственной
канонической единицей измерения. Настоятельно предпочтительно, чтобы
единицы измерения были в системе SI; если текущая практика определила
единицы в других системах (таких как пиксели на дюйм), должен быть
предоставлен метод преобразования в единицы SI. Методы преобразования
должны включать определённую практику округления.
2.4 Идентификаторы ASN.1 для тегов характеристик медиа
Некоторые протоколы используют идентификаторы ASN.1 вместо
человекочитаемых представлений для обмена возможностями. Чтобы
позволить обеим системам взаимодействовать, регистранты могут
предоставить идентификатор ASN.1 или попросить IANA назначить
идентификатор ASN.1 во время регистрации. Эти идентификаторы не
требуются для регистрации, но могут помочь тем, кто создаёт шлюзы или
другие межпротокольные системы. Обратите внимание, что идентификаторы
ASN.1, назначенные IANA, будут рассматриваться как токены, а не как
элементы, из которых могут создаваться или выводиться субделегируемые
идентификаторы.
3 Регистрация тегов характеристик медиа
Теги характеристик медиа могут регистрироваться в нескольких
различных деревьях регистрации с различными требованиями, как
обсуждается ниже. Словарь для этих требований взят из [5]. В общем
случае предложение о регистрации тега характеристики распространяется
и рассматривается способом, соответствующим задействованному дереву.
Затем тег характеристики регистрируется, если предложение принято.
Рассмотрение тега характеристики в дереве URI не требуется.
Holtman, et. al. Best Current Practice [Страница 5]
RFC 2506 Процедура регистрации тегов характеристик медиа Март 1999
3.1 Деревья регистрации
Следующие подразделы определяют «деревья» регистрации, различаемые
использованием фасетных имён (например, имён вида
"tree.feature-name").
3.1.1 Дерево IETF
Дерево IETF предназначено для тегов характеристик медиа, представляющих
общий интерес для Интернет-сообщества, и предложения для этих тегов
должны соответствовать политикам "IETF Consensus", описанным в [5].
Регистрация в дереве IETF требует одобрения IESG и публикации
спецификации тега характеристики в качестве RFC. Представления для
регистрации тега характеристики в дереве IETF могут исходить из любой
WG IETF или как индивидуальное представление в IESG.
Теги характеристик в дереве IETF обычно имеют имена, которые явно не
фасетированы, то есть не содержат символов точки (".", full stop).
3.1.2 Глобальное дерево
Теги в глобальном дереве будут отличаться начальной фасетой "g.".
Организация может предложить либо обозначение, указывающее на
характеристику (например, "g.blinktags"), либо фасетное обозначение,
включающее имя организации (например, "g.organization.blinktags").
Организации, зарегистрировавшие типы медиа в дереве поставщиков MIME,
должны использовать то же имя организации для тегов характеристик
медиа, если они предлагают фасетное обозначение. Принятие
предложенного обозначения остаётся на усмотрение IANA. Если IANA
считает, что обозначение нуждается в уточнении, она может запросить
новое предложение у предлагающей организации или иным образом
координировать разработку подходящего обозначения.
Регистрации тегов характеристик в глобальном дереве должны
соответствовать политикам "Expert Review", описанным в [5]. В этом
случае назначенный эксперт области рассмотрит предложенный тег,
консультируясь с участниками связанного списка рассылки. Регистрация
в глобальном дереве может быть предложена любым, кому необходимо
обеспечить обмен информацией о конкретной возможности или
предпочтении.
3.1.3 Дерево URI
Тег характеристики может быть определён как URI с использованием
ограниченного набора символов, определённого выше. Теги характеристик
в дереве URI идентифицируются начальной фасетой "u.". За начальной
фасетой u. следует URI [9], который соответствует ограничениям на
символы, указанным в этом
Holtman, et. al. Best Current Practice [Страница 6]
RFC 2506 Процедура регистрации тегов характеристик медиа Март 1999
документа. Автор URI считается органом регистрации в отношении характеристик, определённых и описанных содержимым URI. Для целей настоящего документа эти теги считаются незарегистрированными.
3.1.4 Дополнительные деревья регистрации
Время от времени и по мере необходимости для сообщества IANA может, по рекомендации и с согласия IESG, создавать новые деревья регистрации верхнего уровня. Эти деревья могут создаваться для внешней регистрации и управления, осуществляемых, например, известными постоянными организациями, такими как научные общества для типов характеристик носителей, специфичных для охватываемых ими наук. Создание этих новых деревьев будет объявляться посредством публикации RFC, одобренной IESG.
3.2 Местонахождение списка зарегистрированных тегов характеристик
Регистрации тегов характеристик будут размещаться в каталоге анонимного FTP: "ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/", а все зарегистрированные теги характеристик будут перечисляться в периодически выпускаемом RFC "Assigned Numbers" [в настоящее время STD 2, RFC-1700]. Описание тега характеристики и другие вспомогательные материалы также могут публиковаться как информационный RFC посредством отправки их по адресу "rfc-editor@rfc-editor.org".
3.3 Процедуры IANA для регистрации тегов характеристик
IANA будет регистрировать теги характеристик в дереве IETF только в ответ на сообщение от IESG, гласящее, что данная регистрация одобрена.
Глобальные теги будут регистрироваться IANA после проверки назначенным экспертом. Эта проверка служит для обеспечения соответствия тега техническим требованиям данной спецификации.
3.4 Шаблон регистрации
To: media-feature-tags@apps.ietf.org (Media feature tags mailing list)
Subject: Registration of media feature tag XXXX
| Инструкции предваряются символом `|'. Некоторые поля необязательны.
Media feature tag name:
ASN.1 identifier associated with feature tag: [optional]
| Чтобы IANA назначила идентификатор ASN.1,
| используйте здесь значение "New assignment by IANA".
Holtman, et. al. Best Current Practice [Page 7]
RFC 2506 Media Feature Tag Registration Procedure March 1999
Summary of the media feature indicated by this feature tag:
| Включите краткое описание или резюме (не длиннее 4 строк).
| Примеры:
| `Use of the xyzzy feature is indicated by ...'
| `Support of color display is indicated by ...'
| `Number of colors in a palette which can be defined ...'
Values appropriate for use with this feature tag:
[ ] 1. Характеристика является булевой и может иметь значения
TRUE или FALSE. Значение TRUE указывает на доступную
возможность. Значение FALSE указывает, что возможность
недоступна.
| Если вы хотите указать две взаимоисключающие возможности,
| которые нельзя выразить как наличие или отсутствие
| возможности, используйте список из двух токенов, а не
| булево значение.
[ ] 2. Характеристика имеет связанное с ней числовое значение или значение из перечисления.
Для случая 2: укажите тип данных значения:
[ ] 2a. Целое число со знаком
[ ] 2b. Рациональное число
[ ] 2c. Токен (отношение равенства)
[ ] 2d. Токен (упорядоченный)
[ ] 2e. Строка (отношение равенства)
[ ] 2f. Строка (определённое сравнение)
|ВАЖНО: можно выбрать только один из указанных выше типов данных.
(Только для случая 2.) Подробное описание смысла значения характеристики, а также формата и смысла значений тега характеристики для альтернативных результатов.
| Если вы выбрали 2d, необходимо предоставить механизм упорядочивания
| либо полное и упорядоченное перечисление возможных значений. Если вы
| выбрали 2f, необходимо предоставить определение сравнения.
| Определения посредством включённой ссылки должны ссылаться на стабильные
| и легкодоступные спецификации:
|
| Если число альтернативных результатов невелико, вы можете
| перечислить идентификаторы различных результатов и описать
| их смысл.
|
| Если существует ограниченный полезный числовой диапазон результата (2b, 2c),
Holtman, et. al. Best Current Practice [Page 8]
RFC 2506 Media Feature Tag Registration Procedure March 1999
| укажите диапазон.
|
| Идентификаторы альтернативных результатов также могут быть
| описаны ссылкой на другой реестр IANA, например
| на размеры бумаги, перечисленные в Printer MIB.
Тег характеристики предназначен преимущественно для использования в следующих
приложениях, протоколах, службах или механизмах согласования:
[optional]
| Для приложений также укажите номер первой версии,
| в которой будет использоваться тег, если это применимо.
Examples of typical use: [optional]
Related standards or documents: [optional]
Considerations particular to use in individual applications,
protocols, services, or negotiation mechanisms: [optional]
Interoperability considerations: [optional]
Security considerations:
Privacy concerns, related to exposure of personal information:
Denial of service concerns related to consequences of specifying
incorrect values:
Other:
Additional information: [optional]
Keywords: [optional]
Related feature tags: [optional]
Related media types or data formats: [optional]
Related markup tags: [optional]
Name(s) & email address(es) of person(s) to contact for
further information:
Intended usage:
| one of COMMON, LIMITED USE or OBSOLETE
Holtman, et. al. Best Current Practice [Page 9]
RFC 2506 Media Feature Tag Registration Procedure March 1999
Author/Change controller:
Requested IANA publication delay: [optional]
| Задержка может быть запрошена только для окончательного размещения в глобальном
| дереве или дереве IETF и не более чем на два месяца. Организациям,
| запрашивающим регистрацию с задержкой публикации, следует учитывать,
| что это задерживает только официальную публикацию тега
| и не препятствует распространению сведений о нём
| участниками соответствующего списка рассылки.
Other information: [optional]
| Здесь может быть добавлена любая иная информация, которую автор считает
| интересной.
4 Соображения безопасности
Механизмы согласования раскрывают информацию об одной стороне другим сторонам. Это может вызывать опасения в отношении приватности и может позволить злоумышленной стороне точнее предполагать наличие конкретных уязвимостей безопасности.
5 Благодарности
Детали процедуры регистрации в этом документе были непосредственно адаптированы из [1]. Значительная часть текста раздела 3 была непосредственно скопирована из этого источника.
Идея создания словаря областей характеристик носителей, поддерживаемого в центральном открытом реестре, возникла в ходе обсуждений расширяемых механизмов согласования [3] в рабочей группе IETF HTTP.
Авторы благодарят Larry Masinter, Graham Klyne, Al Gilman, Dan Wing, Jacob Palme и Martin Duerst за их вклад в обсуждения регистрации тегов характеристик носителей.
6 Ссылки
[1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", BCP 13,
RFC 2048, November 1996.
[2] Klyne, G., "An algebra for describing media feature sets", Work
in Progress.
[3] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
HTTP. RFC 2295, March 1998.
Holtman, et. al. Best Current Practice [Page 10]
RFC 2506 Media Feature Tag Registration Procedure March 1999
[4] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features
for Display, Print, and Fax", RFC 2534, March 1999.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Crocker, D., Ed., "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997.
[7] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T. Berners-
Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January
1997.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC
1630, June 1994.
7 Адреса авторов
Koen Holtman
Technische Universiteit Eindhoven
Postbus 513
Kamer HG 6.57
5600 MB Eindhoven
The Netherlands
EMail: koen@win.tue.nl
Andrew H. Mutz
Hewlett-Packard Company
11000 Wolfe Rd. 42UO
Cupertino CA 95014 USA
Fax +1 408 447 4439
EMail: andy_mutz@hp.com
Ted Hardie
Equinix
901 Marshall Street
Redwood City, CA 94063 USA
EMail: hardie@equinix.com
Holtman, et. al. Best Current Practice [Page 11]
RFC 2506 Media Feature Tag Registration Procedure March 1999
8 Полное заявление об авторском праве
Copyright (C) The Internet Society (1999). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, которые комментируют или иным образом поясняют его либо содействуют его реализации, могут подготавливаться, копироваться, публиковаться и распространяться полностью или частично без каких-либо ограничений при условии, что приведённое выше уведомление об авторском праве и настоящий абзац включаются во все такие копии и производные работы. Однако сам этот документ не может изменяться каким бы то ни было образом, например путём удаления уведомления об авторском праве или ссылок на Internet Society либо другие интернет-организации, за исключением случаев, необходимых для разработки интернет-стандартов, когда должны соблюдаться процедуры в отношении авторских прав, определённые процессом разработки интернет-стандартов, или когда это требуется для его перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society, её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях "AS IS", И THE INTERNET SOCIETY И THE INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИЕ-ЛИБО ПРАВА, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Holtman, et. al. Best Current Practice [Page 12]
Network Working Group K. Holtman
Request for Comments: 2506 TUE
BCP: 31 A. Mutz
Category: Best Current Practice Hewlett-Packard
T. Hardie
Equinix
March 1999
Media Feature Tag Registration Procedure
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
ABSTRACT
Recent Internet applications, such as the World Wide Web, tie
together a great diversity in data formats, client and server
platforms, and communities. This has created a need for media
feature descriptions and negotiation mechanisms in order to identify
and reconcile the form of information to the capabilities and
preferences of the parties involved.
Extensible media feature identification and negotiation mechanisms
require a common vocabulary in order to positively identify media
features. A registration process and authority for media features is
defined with the intent of sharing this vocabulary between
communicating parties. In addition, a URI tree is defined to enable
sharing of media feature definitions without registration.
This document defines a registration procedure which uses the
Internet Assigned Numbers Authority (IANA) as a central registry for
the media feature vocabulary.
Please send comments to the CONNEG working group at <ietf-
medfree@imc.org>. Discussions of the working group are archived at
<URL: http://www.imc.org/ietf-medfree/>.
Holtman, et. al. Best Current Practice [Page 1]
RFC 2506 Media Feature Tag Registration Procedure March 1999
TABLE OF CONTENTS
1 Introduction ................................................. 2
2 Media feature tag definitions ................................ 3
2.1 Media feature tag purpose ................................. 3
2.2 Media feature tag syntax .................................. 4
2.3 Media feature tag values .................................. 4
2.4 ASN.1 identifiers for media feature tags ................. 5
3 Media feature tag registration ............................... 5
3.1 Registration trees ........................................ 6
3.1.1 IETF tree ............................................... 6
3.1.2 Global tree ............................................. 6
3.1.3 URL tree ................................................ 6
3.1.4 Additional registration trees ........................... 7
3.2 Location of registered media feature tag list ............. 7
3.3 IANA procedures for registering media feature tags ........ 7
3.4 Registration template ..................................... 7
4 Security Considerations ...................................... 10
5 Acknowledgments .............................................. 10
6 References ................................................... 10
7 Authors' Addresses ........................................... 11
8 Full Copyright Statement ..................................... 12
1 Introduction
Recent Internet applications, such as the World Wide Web, tie
together a great diversity in data formats, client and server
platforms, and communities. This has created a need for media
feature descriptions and negotiation mechanisms in order to identify
and reconcile the form of information to the capabilities and
preferences of the parties involved.
Extensible media feature identification and negotiation mechanisms
require a common vocabulary in order to positively identify media
features. A registration process and authority for media features is
defined with the intent of sharing this vocabulary between
communicating parties. In addition, a URI tree is defined to enable
sharing of media feature definitions without registration.
This document defines a registration procedure which uses the
Internet Assigned Numbers Authority (IANA) as a central registry for
the media feature vocabulary.
This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT and
MAY according to usage described in [8].
Holtman, et. al. Best Current Practice [Page 2]
RFC 2506 Media Feature Tag Registration Procedure March 1999
2 Media feature tag definitions
2.1 Media feature tag purpose
Media feature tags represent individual and simple characteristics
related to media capabilities or properties associated with the
resource to which they are applied. Examples of such features are:
* the color depth of the screen on which something is to be displayed
* the type of paper available in a printer
* the support of the `floating 5 dimensional tables' feature
* the fonts which are available to the recipient
* the capability to display graphical content
Each media feature tag identifies a single characteristic. Values
associated with a specific tag must use the data type defined for
that tag. The list of allowed data types is presented below, in
section 2.3.
Examples of media feature tags with values are:
* the width of a display in pixels per centimeter represented as an
integer value.
* a font available to a recipient, selected from an enumerated list.
* the version of a protocol composed of integers "i.j.k", defined as
either a value in an enumerated list or with a defined mapping to
make the value isomorphic to a subset of integers (e.g. i*100 + j*10
+k, assuming j<=9 and k<=9).
Further examples of media feature tags are defined in detail
elsewhere [4].
Feature collections may be composed using a number of individual
feature tags [2]. Composition of feature collections is described
elsewhere [2]. Examples of feature collections requiring multiple
media feature tags are:
* the set of all fonts used by a document
* the width and height of a display
* the combination of color depth and resolution a display can support
This registry presumes the availability of the MIME media type
registry, and MIME media types MUST NOT be re-registered as media
feature tags. Media feature tags which are currently in use by
individual protocols or applications MAY be registered with this
registry if they might be applied outside of their current domain.
Holtman, et. al. Best Current Practice [Page 3]
RFC 2506 Media Feature Tag Registration Procedure March 1999
The media feature tag namespace is not bound to a particular
transport protocol or capability exchange mechanism. The registry is
limited, however, to feature tags which express a capability or
preference related to how content is presented. Feature tags related
to other axes of negotiation are not appropriate for this registry.
Capability exchange mechanisms may, of course, be used to express a
variety of capabilities or preferences.
2.2 Media feature tag syntax
A media feature tag is a string consisting of one or more of the
following US-ASCII characters: uppercase letters, lowercase letters,
digits, colon (":"), slash ("/"), dot (".") percent ("%"), and dash
("-"). Feature tags are case-insensitive. Dots are understood to
potentially imply hierarchy; a feature can be subtyped by describing
it as tree.feature.subfeature and by indicating this in the
registration. Tags should begin with an alphabetic character.
In ABNF [6], this may be represented as:
Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" )
Registrants should take care to avoid creating tags which might
conflict with the creation of new registration trees; in general this
means avoiding tags which begin with an alphabetic character followed
by a dot. The current registration trees are described in section 3
below.
2.3 Media feature tag values
The registry will initially support the use of the following data
types as tag values:
- signed integers
- rational numbers
- tokens, with equality relationship
- tokens, with defined ordering relationship
- strings, with standard (octet-by-octet) equality relationship
- strings, with defined equality and/or comparison relationship
"Token" here means the token data type as defined by [7], which may
be summarized as:
Holtman, et. al. Best Current Practice [Page 4]
RFC 2506 Media Feature Tag Registration Procedure March 1999
token = 1*<any CHAR except CTLs or tspecials>
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT
At the time of registration, each tag must be associated with a
single data type. If that data type implies a defined comparison or
an ordering, the registrant must define the ordering or comparison.
For ordered tokens, this may be by full enumeration of the tokens and
their order or by reference to an ordering mechanism. For defined
comparisons, a full description of the rules for comparison must be
provided or included by reference.
Media feature tags related to spatial or temporal characteristics
must be registered with a single canonical unit. It is strongly
preferred that units be in the SI system; where current practice has
defined units in other systems (such as pixels per inch), a
conversion method to SI units must be provided. Conversion methods
should include a defined rounding practice.
2.4 ASN.1 identifiers for media feature tags
Certain protocols use ASN.1 identifiers rather than human-readable
representations for capability exchange. In order to allow both
systems to interoperate, registrants may provide an ASN.1 identifier
or ask that IANA assign an ASN.1 identifier during registration.
These identifiers are not required for registration, but may provide
assistance to those building gateways or other cross-protocol
systems. Note that ASN.1 identifiers assigned by IANA will be
treated as tokens, not as elements from which sub-delegated
identifiers may be created or derived.
3 Media feature tag registration
Media feature tags can be registered in several different
registration trees, with different requirements as discussed below.
The vocabulary for these requirements is taken from [5]. In general,
a feature tag registration proposal is circulated and reviewed in a
fashion appropriate to the tree involved. The feature tag is then
registered if the proposal is accepted.
Review of a feature tag in the URI tree is not required.
Holtman, et. al. Best Current Practice [Page 5]
RFC 2506 Media Feature Tag Registration Procedure March 1999
3.1 Registration trees
The following subsections define registration "trees", distinguished
by the use of faceted names (e.g., names of the form "tree.feature-
name").
3.1.1 IETF tree
The IETF tree is intended for media feature tags of general interest
to the Internet Community, and proposals for these tags must meet the
"IETF Consensus" policies described in [5].
Registration in the IETF tree requires approval by the IESG and
publication of the feature tag specification as an RFC. Submissions
for feature tag registration in the IETF tree can originate in any WG
of the IETF or as an individual submission to the IESG.
Feature tags in the IETF tree normally have names that are not
explicitly faceted, i.e., do not contain period (".", full stop)
characters.
3.1.2 Global tree
Tags in the global tree will be distinguished by the leading facet
"g.". An organization may propose either a designation indicative of
the feature, (e.g., "g.blinktags") or a faceted designation including
the organization name (e.g., "g.organization.blinktags").
Organizations which have registered media types under the MIME vendor
tree should use the same organizational name for media feature tags
if they propose a faceted designation. The acceptance of the proposed
designation is at the discretion of the IANA. If the IANA believes
that a designation needs clarification it may request a new proposal
from the proposing organization or otherwise coordinate the
development of an appropriate designation.
Registrations of feature tags in the global tree must meet the
"Expert Review" policies described in [5]. In this case, a
designated area expert will review the proposed tag, consulting with
the members of a related mailing list. A registration may be
proposed for the global tree by anyone who has the need to allow for
communication on a particular capability or preference.
3.1.3 URI tree
A feature tag may be defined as a URI using the restricted character
set defined above. Feature tags in the URI tree are identified by the
leading facet "u.". The leading facet u. is followed by a URI [9]
which conforms to the character limitations specified in this
Holtman, et. al. Best Current Practice [Page 6]
RFC 2506 Media Feature Tag Registration Procedure March 1999
document. The author of the URI is assumed to be registration
authority regarding features defined and described by the content of
the URI. These tags are considered unregistered for the purpose of
this document.
3.1.4 Additional registration trees
From time to time and as required by the community, the IANA may,
with the advice and consent of the IESG, create new top-level
registration trees. These trees may be created for external
registration and management by (for example) well-known permanent
bodies, such as scientific societies for media feature types specific
to the sciences they cover. Establishment of these new trees will be
announced through RFC publication approved by the IESG.
3.2 Location of registered feature tag list
Feature tag registrations will be posted in the anonymous FTP
directory: "ftp://ftp.isi.edu/in-notes/iana/assignments/media-
feature-tags/" and all registered feature tags will be listed in the
periodically issued "Assigned Numbers" RFC [currently STD 2, RFC-
1700]. The feature tag description and other supporting material may
also be published as an Informational RFC by sending it to "rfc-
editor@rfc-editor.org".
3.3 IANA procedures for registering feature tags
The IANA will only register feature tags in the IETF tree in response
to a communication from the IESG stating that a given registration
has been approved.
Global tags will be registered by the IANA after review by a
designated expert. That review will serve to ensure that the tag
meets the technical requirements of this specification.
3.4 Registration template
To: media-feature-tags@apps.ietf.org (Media feature tags mailing list)
Subject: Registration of media feature tag XXXX
| Instructions are preceded by `|'. Some fields are optional.
Media feature tag name:
ASN.1 identifier associated with feature tag: [optional]
| To have IANA assign an ASN.1 identifier,
| use the value "New assignment by IANA" here.
Holtman, et. al. Best Current Practice [Page 7]
RFC 2506 Media Feature Tag Registration Procedure March 1999
Summary of the media feature indicated by this feature tag:
| Include a short (no longer than 4 lines) description or summary
| Examples:
| `Use of the xyzzy feature is indicated by ...'
| `Support of color display is indicated by ...'
| `Number of colors in a palette which can be defined ...'
Values appropriate for use with this feature tag:
[ ] 1. The feature tag is Boolean and may have values of
TRUE or FALSE. A value of TRUE indicates an available
capability. A value of FALSE indicates the capability
is not available.
| If you wish to indicate two mutually exclusive possibilities
| that cannot be expressed as the availability or lack of a
| capability, use a two-token list, rather than a Boolean value.
[ ] 2. The feature has an associated numeric or enumerated value.
For case 2: Indicate the data type of the value:
[ ] 2a. Signed Integer
[ ] 2b. Rational number
[ ] 2c. Token (equality relationship)
[ ] 2d. Token (ordered)
[ ] 2e. String (equality relationship)
[ ] 2f. String (defined comparison)
|IMPORTANT: You may only chose one of the above data types.
(Only for case 2) Detailed description of the feature value meaning,
and of the format and meaning of the feature tag values for the
alternative results.
| If you have selected 2d you must provide the ordering mechanism
| or a full and ordered enumeration of possible values. If you
| have selected 2f, you must provide a definition of the comparison.
| Definitions by included reference must be to stable and readily
| available specifications:
|
| If the number of alternative results is small, you may
| enumerate the identifiers of the different results and describe
| their meaning.
|
| If there is a limited useful numeric range of result (2b, 2c),
Holtman, et. al. Best Current Practice [Page 8]
RFC 2506 Media Feature Tag Registration Procedure March 1999
| indicate the range.
|
| The identifiers of the alternative results could also be
| described by referring to another IANA registry, for example
| the paper sizes enumerated by the Printer MIB.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
[optional]
| For applications, also specify the number of the first version
| which will use the tag, if applicable.
Examples of typical use: [optional]
Related standards or documents: [optional]
Considerations particular to use in individual applications,
protocols, services, or negotiation mechanisms: [optional]
Interoperability considerations: [optional]
Security considerations:
Privacy concerns, related to exposure of personal information:
Denial of service concerns related to consequences of specifying
incorrect values:
Other:
Additional information: [optional]
Keywords: [optional]
Related feature tags: [optional]
Related media types or data formats: [optional]
Related markup tags: [optional]
Name(s) & email address(es) of person(s) to contact for
further information:
Intended usage:
| one of COMMON, LIMITED USE or OBSOLETE
Holtman, et. al. Best Current Practice [Page 9]
RFC 2506 Media Feature Tag Registration Procedure March 1999
Author/Change controller:
Requested IANA publication delay: [optional]
| A delay may only be requested for final placement in the global
| or IETF trees, with a maximum of two months. Organizations
| requesting a registration with a publication delay should note
| that this delays only the official publication of the tag
| and does not prevent information on it from being disseminated
| by the members of the relevant mailing list.
Other information: [optional]
| Any other information that the author deems interesting may be
| added here.
4 Security Considerations
Negotiation mechanisms reveal information about one party to other
parties. This may raise privacy concerns, and may allow a malicious
party to make better guesses about the presence of specific security
holes.
5 Acknowledgments
The details of the registration procedure in this document were
directly adapted from [1]. Much of the text in section 3 was
directly copied from this source.
The idea of creating a vocabulary of areas of media features,
maintained in a central open registry, is due to discussions on
extensible negotiation mechanisms [3] in the IETF HTTP working group.
The authors wish to thank Larry Masinter, Graham Klyne, Al Gilman,
Dan Wing, Jacob Palme, and Martin Duerst for their contributions to
discussions about media feature tag registration.
6 References
[1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", BCP 13,
RFC 2048, November 1996.
[2] Klyne, G., "An algebra for describing media feature sets", Work
in Progress.
[3] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
HTTP. RFC 2295, March 1998.
Holtman, et. al. Best Current Practice [Page 10]
RFC 2506 Media Feature Tag Registration Procedure March 1999
[4] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features
for Display, Print, and Fax", RFC 2534, March 1999.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Crocker, D., Ed., "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997.
[7] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T. Berners-
Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January
1997.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC
1630, June 1994.
7 Authors' Addresses
Koen Holtman
Technische Universiteit Eindhoven
Postbus 513
Kamer HG 6.57
5600 MB Eindhoven
The Netherlands
EMail: koen@win.tue.nl
Andrew H. Mutz
Hewlett-Packard Company
11000 Wolfe Rd. 42UO
Cupertino CA 95014 USA
Fax +1 408 447 4439
EMail: andy_mutz@hp.com
Ted Hardie
Equinix
901 Marshall Street
Redwood City, CA 94063 USA
EMail: hardie@equinix.com
Holtman, et. al. Best Current Practice [Page 11]
RFC 2506 Media Feature Tag Registration Procedure March 1999
8 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Holtman, et. al. Best Current Practice [Page 12]