О документе
Рабочая группа сети K. Holtman
Запрос комментариев: 2506 TUE
BCP: 31 A. Mutz
Категория: Лучшая современная практика Hewlett-Packard
T. Hardie
Equinix
Март 1999
Процедура регистрации тегов характеристик медиа
1 Введение
Недавние Интернет-приложения, такие как Всемирная паутина, объединяют
большое разнообразие форматов данных, клиентских и серверных
платформ, а также сообществ. Это создало потребность в описаниях
характеристик медиа и механизмах согласования, чтобы идентифицировать
и привести форму информации в соответствие с возможностями и
предпочтениями вовлечённых сторон.
Расширяемые механизмы идентификации характеристик медиа и
согласования требуют общего словаря, чтобы однозначно идентифицировать
характеристики медиа. Определяются процесс регистрации и орган для
характеристик медиа с целью совместного использования этого словаря
между взаимодействующими сторонами. Кроме того, определяется дерево
URI, позволяющее совместно использовать определения характеристик
медиа без регистрации.
Этот документ определяет процедуру регистрации, использующую Internet
Assigned Numbers Authority (IANA) в качестве центрального реестра
словаря характеристик медиа.
В этом документе термины ДОЛЖЕН (MUST), НЕ ДОЛЖЕН (MUST NOT), СЛЕДУЕТ
(SHOULD), НЕ СЛЕДУЕТ (SHOULD NOT) и МОЖЕТ (MAY) используются в
соответствии с порядком употребления, описанным в [8].
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) быть зарегистрированы в этом реестре, если они могут
применяться за пределами их текущей области.
Пространство имён тегов характеристик медиа не привязано к
конкретному транспортному протоколу или механизму обмена
возможностями. Однако реестр ограничен тегами характеристик,
выражающими возможность или предпочтение, относящиеся к тому, как
представляется содержимое. Теги характеристик, относящиеся к другим
осям согласования, не подходят для этого реестра. Механизмы обмена
возможностями, разумеется, могут использоваться для выражения
разнообразных возможностей или предпочтений.
2.2 Синтаксис тега характеристики медиа
Тег характеристики медиа — это строка, состоящая из одного или более
следующих символов US-ASCII: прописных букв, строчных букв, цифр,
двоеточия (":"), косой черты ("/"), точки ("."), процента ("%") и
дефиса ("-"). Теги характеристик нечувствительны к регистру. Точки
понимаются как потенциально обозначающие иерархию; характеристика
может быть подтипизирована описанием её как tree.feature.subfeature
и указанием этого при регистрации. Теги следует начинать с
алфавитного символа.
В ABNF [6] это может быть представлено так:
Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" )
Регистрантам следует позаботиться о том, чтобы не создавать теги,
которые могут конфликтовать с созданием новых деревьев регистрации;
в общем случае это означает избегать тегов, начинающихся с
алфавитного символа, за которым следует точка. Текущие деревья
регистрации описаны ниже, в разделе 3.
2.3 Значения тегов характеристик медиа
Реестр первоначально будет поддерживать использование следующих
типов данных в качестве значений тегов:
- знаковые целые числа
- рациональные числа
- токены с отношением равенства
- токены с определённым отношением порядка
- строки со стандартным отношением равенства (октет за октетом)
- строки с определённым отношением равенства и/или сравнения
"Токен" здесь означает тип данных token, определённый в [7], который
можно кратко представить так:
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 не требуется.
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], который соответствует ограничениям на
символы, указанным в этом
документа. Автор 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".
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),
| укажите диапазон.
|
| Идентификаторы альтернативных результатов также могут быть
| описаны ссылкой на другой реестр 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
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.
[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
8 Полное заявление об авторском праве
Copyright (C) The Internet Society (1999). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, которые комментируют или иным образом поясняют его либо содействуют его реализации, могут подготавливаться, копироваться, публиковаться и распространяться полностью или частично без каких-либо ограничений при условии, что приведённое выше уведомление об авторском праве и настоящий абзац включаются во все такие копии и производные работы. Однако сам этот документ не может изменяться каким бы то ни было образом, например путём удаления уведомления об авторском праве или ссылок на Internet Society либо другие интернет-организации, за исключением случаев, необходимых для разработки интернет-стандартов, когда должны соблюдаться процедуры в отношении авторских прав, определённые процессом разработки интернет-стандартов, или когда это требуется для его перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society, её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях "AS IS", И THE INTERNET SOCIETY И THE INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИЕ-ЛИБО ПРАВА, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.