RFC3688 The IETF XML Registry

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 Practices) в сообществе Internet и является приглашением к дискуссии в целях развития и совершенствования. Документ можно распространять без ограничений.

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

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

Тезисы

А этом документе описан поддерживаемый 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. Заявление прав интеллектуальной собственности

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF’s procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

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

Michael Mealling

VeriSign, Inc.

Mountain View, CA

USA

EMail: michael@verisignlabs.com

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


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2004). 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 assignees.

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.

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

Финансирование функций 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. Прим. перев.