RFC3688 The IETF XML Registry

Опубликовано 02.01.2004 автором Nikolai Malykh 
Network Working Group                                        M. Mealling
Request for Comments: 3688                                VeriSign, Inc.
BCP: 81                                                     January 2004
Category: Best Current Practice

The IETF XML Registry

Реестр IETF XML

PDF

Статус документа

Этот документ служит для обмена опытом (Internet Best Current Practice) в сообществе Internet и является приглашением к дискуссии в целях развития и совершенствования. Документ можно распространять без ограничений.

Авторские права

Copyright (C) The Internet Society (2004). All Rights Reserved.

Fyyjnfwbz

А этом документе описан поддерживаемый IANA реестр для стандартов IETF, которые используют связанные с XML1 элементы, такие как пространство имен (Namespace), объявления типа документа (DTD2), схемы (Schema), и схемы RDF3.

1. Введение

За несколько недавних лет язык XML [W3C.REC-xml] стал широко применяться для разметки данных. Уже имеется несколько рабочих групп IETF, которые разработали стандарты, определяющие типы документов XML (DTD), пространства имен XML [W3C.REC-xml-names] и схемы XML [W3C.REC-xmlschema-1]. Каждая из этих технологий применяет унифицированные идентификаторы ресурсов (URI4) [RFC2396] и другие стандартизованные идентификаторы для указания различных компонент.

Например, хотя в некоторых стандартах применялась практика использования определений типов документов (DTD) с целью отказа от использования идентификаторов PUBLIC в пользу «общеизвестных» идентификаторов SYSTEM, оказалось, что попытка стандартизации идентификаторов SYSTEM связана с множеством проблем. В результате несколько стандартов IETF просто создали нетранслируемые URI для того лишь, чтобы не преобразовывать DTD для некого заданного документа XML.

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

  • публичное представление документа;

  • URI для элементов, если идентификатор представлен при регистрации;

  • реестр публичных идентификаторов (Public Identifier) как URI.

Если при регистрации не был запрошен идентификатор URI, агентство IANA будет назначать имя ресурса (URN5) в соответствии с [RFC3553].

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14, RFC 2119 [RFC2119].

3. Регистрируемые документы

3.1. Назначенные/зарегистрированные URI

Для всех элементов (кроме идентификаторов PUBLIC) этого реестра при регистрации будет требоваться URI. Если заявитель хочет получить URI, будет выделяться имя URN в форме urn:ietf:params:xml:<class>:<id>, где <class> указывает тип регистрируемого документа (см. ниже). Уникальное значение <id> генерируется IANA на основе любых мер, которые IANA сочтет необходимыми для обеспечения уникальности и постоянства. Отметим, что для назначения URN этого типа регистрируемый элемент должен получить согласие IETF. По сети, это означает документирование в RFC. Шаблон регистрации URN в соответствии с RFC 3553 [RFC3553] представлен в разделе 6.

IANA также будет поддерживать файловый сервер, доступный по меньшей мере по протоколам HTTP и FTP, где будут содержаться все зарегистрированные элементы в неком пространстве с открытым доступом так же, как для всех зарегистрированных IANA, элементов, доступных по ссылке http://www.iana.org/assignments/. Хотя выбор структуры каталога остается за IANA, предполагается, что файлы будут организованы по значениям <class> с использованием <id> в качестве имени.

Разработчикам не следует полагаться в программах на доступность или статичность этой структуры данных. Явно отмечались попытки некоторых программных средств напрямую загружать DTD, схемы и т. п. Разработчикам следует понимать, что они делают и не следует указывать сетевые ресурсы IANA в качестве «репозитория для загрузки схем». По этой причине IANA не регистрирует и не предоставляет идентификаторов SYSTEM.

3.2. Регистрируемые классы

Ниже приведен список элементов XML, регистрируемых IANA.

publicid

Документ XML, содержащий объявление DOCTYPE или другую внешнюю ссылку, может указать такую ссылку идентификатором PUBLIC или SYSTEM. Идентификаторы SYSTEM содержат зависимую от системы информацию, которая позволяет менеджеру объектов XML найти файл, место в памяти или указатель в файле, где можно найти объект. Следует отметить, что системный идентификатор может быть вызовом программы, контролирующей доступ к указанному объекту. Таким образом, эти идентификаторы не являются регистрируемыми элементами. Во многих случаях идентификаторы SYSTEM являются также URI. Однако в таких случаях URI применяется только для определяемой системой информации. Когда идентификатор PUBLIC является URI, идентификатор SYSTEM может содержать то же значение URI, но такой подход не рекомендуется без осознания побочных эффектов и понимания того, что они не принесут неприемлемого вреда.

Идентификатор PUBLIC является именем, которому следует быть значимым среди систем и разных пользовательских сред. Обычно это имя, с которым связан зарегистрированный владелец, так что общедоступные идентификаторы гарантированно являются уникальными и два объекта не будут иметь одинаковых публичных идентификаторов. На практике идентификаторы PUBLIC обычно являются FPI6 [ISO.8879.1986], но это не обязательно. Как сказано в [RFC3151]:

“Любая строка, содержащая только символы общедоступного идентификатора (определен в Выпуске 13 Extensible Markup Language (XML) 1.0, второго издания) является допустимым публичным идентификатором.”

Поэтому идентификаторы PUBLIC могут быть URN при использовании символов, соответствующих ограничениям. Таким образом, идентификаторы, зарегистрированные с DTD являются идентификаторами PUBLIC. Единственным ограничением является набор разрешенных символов. Если заявитель не предоставляет его, IANA будет назначать одну из форм urn:ietf:params:xml:pi:<id>. Заявителям рекомендуется прочесть RFC 3151 [RFC3151], где даны рекомендации по созданию URN, которые могут быть также FPI.

ns

Пространства имен XML [W3C.REC-xml-names] указываются идентификаторами URI и не имеют машинно-анализируемого представления. Таким образом, зарегистрированный документ будет либо спецификацией, либо ссылкой на нее. Если заявитель не представляет URI, агентство IANA будет назначать имя URN в форме urn:ietf:params:xml:ns:<id>, которое будет именем пространства имен XML.

schema

Схемы XML [W3C.REC-xmlschema-1] также указываются URI, но их содержимое пригодно для машинного анализа. Зарегистрированные IANA документы будут файлами XML Schema. Выделенное IANA значение URN может применяться в качестве URI для схемы и имеет форму urn:ietf:params:xml:schema:<id>.

rdfschema

Формат описания ресурса (RDF7) [W3C.CR-rdf-schema] представляет собой сериализацию XML для связного графа, основанного на модели данных, используемой для представления метаданных. RDF использует схемы, которые выражают элементы связей между URI. Эти элементы указываются идентификаторами URI. Выделенное IANA значение URN может служить для идентификации URI и имеет форму urn:ietf:params:xml:rdfschema:<id>.

4. Регистрируемые процедуры

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

URI

Идентификатор URI или PUBLIC, указывающий компонент XML. Если заявитель хочет получить значение URI от IANA, следует указать «please assign» (выделите пожалуйста).

Registrant Contact

Человек или организации для контактов по вопросам регистрации. В идеале это имя и постоянные контактные данные (физические и сетевые). Для разрабатываемых IETF стандартов запрашивающей стороной будет IESG.

XML

Точный код XML для хранения в реестре. Если начало и конец файла не очевидны, в документе следует использовать текст BEGIN в начале файла и END для маркировки конца файла. IANA будет помещать весь текст между этими маркерами (за исключением перевода страниц и форматирования RFC, добавленного редактором RFC) в файл репозитория.

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

Поддерживаемая IANA информация будет полномочной и может подвергаться атакам. В некоторых случаях, таких как XML Schema и DTD, поддерживаемые IANA данные могут напрямую передаваться на вход программы. Поэтому от IANA требуется особая осторожность в соблюдении безопасности для столь важного хранилища информации Internet.

Кроме этого не возникает каких-либо проблем безопасности в дополнение к известным для реестров IANA.

6. Взаимодействие с IANA

Этот документ пытается создать довольно большой реестр, за который будет отвечать агентство IANA (по указанию IESG). Общий объем работы по поддержке такого реестра достаточно велик, а правила и процедуры, связанные с процессами одобрения публикаций, не являются тривиальными. Реестр работает по принципу естественной очередности (First Come First Served), но требует спецификаций (процедура Specification Required). Когда IETF обретет опыт работы с реестром, правила могут быть изменены.

В RFC 3553 [RFC3553] указано, что любой новый реестр, требующий имени, будет назначаться под пространством имен urn:ietf:params и должен задавать структуру этого пространства в форме шаблона. IANA создает и поддерживает это новое субпространство, как показано ниже.

   Registry-name: xml
   Specification: This document contains the registry specification.
      The namespace is organized with one sub-namespace which is the
      <id>.
   Repository: To be assigned according to the guidelines found above.
   Index value: The class name

7. Нормативные документы

[ISO.8879.1986] International Organization for Standardization, “Information processing – Text and office systems – Standard generalized markup language (SGML)”, ISO Standard 8879, 1986.

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

[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 23968, August 1998.

[RFC3151] Walsh, N., Cowan, J. and P. Grosso, “A URN Namespace for Public Identifiers”, RFC 3151, August 2001.

[RFC3553] Mealling, M., Masinter, L., Hardie, T. and G. Klyne, “An IETF URN Sub-namespace for Registered Protocol Parameters”, BCP 73, RFC 3553, June 2003.

[W3C.CR-rdf-schema] Brickley, D. and R. Guha, “Resource Description Framework (RDF) Schema Specification 1.0”, W3C CR-rdf-schema, March 2000, <http://www.w3.org/TR/2000/CR-rdf-schema-20000327>.

[W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C. And E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed)”, W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.

[W3C.REC-xml-names] Bray, T., Hollander, D. and A. Layman, “Namespaces in XML”, W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.

[W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, “XML Schema Part 1: Structures”, W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.

8. Заявление прав интеллектуальной собственности

IETF не занимает какой-либо позиции в отношении действительности или объёма каких-либо прав интеллектуальной собственности или иных прав, которые могут быть заявлены как относящиеся к реализации или применению технологии, описанной в этом документе, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах, связанных со стандартами, можно найти в BCP-11. Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить в IETF Secretariat.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Эту информацию следует направлять исполнительному директоу IETF (Executive Director).

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

Michael Mealling

VeriSign, Inc.

Mountain View, CA

USA

EMail: michael@verisignlabs.com

URI: http://www.research.verisignlabs.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

10. Полное заявление авторских прав

Copyright (C) The Internet Society (2004). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Extensible Markup Language – расширенный язык разметки.

2Document Type Declaration.

3Resource Description Framework – модель описания ресурсов.

4Uniform Resource Identifier.

5Uniform Resource Name – унифицированное имя ресурса.

6Formal Public Identifier – формальный общедоступный идентификатор.

7Resource Description Format.

8Заменен RFC 3986. Прим. перев.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.