From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3937.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc3937.txt (limited to 'doc/rfc/rfc3937.txt') diff --git a/doc/rfc/rfc3937.txt b/doc/rfc/rfc3937.txt new file mode 100644 index 0000000..77d31da --- /dev/null +++ b/doc/rfc/rfc3937.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group M. Steidl +Request for Comments: 3937 IPTC +Category: Informational October 2004 + + + A Uniform Resource Name (URN) Namespace for + the International Press Telecommunications Council (IPTC) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes a URN (Uniform Resource Name) namespace for + identifying persistent resources published by the International Press + Telecommunications Council (IPTC). These resources include XML Data + Type Definition files (DTD), XML Schema, Namespaces in XML, XSL + stylesheets, other XML based document and documents of other data + formats like PDF documents, Microsoft Office documents and others. + + + + + + + + + + + + + + + + + + + + + + + + + +Steidl Informational [Page 1] + +RFC 3937 URN Namespace for IPTC October 2004 + + +Table of Contents + + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. IANA URN Specification Template . . . . . . . . . . . . . . . 3 + 2.1. Namespace ID. . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Registration Information. . . . . . . . . . . . . . . . 3 + 2.3. Declaration of syntactic structure. . . . . . . . . . . 3 + 2.4. Relevant ancillary documentation. . . . . . . . . . . . 5 + 2.5. Identifier uniqueness considerations. . . . . . . . . . 5 + 2.6. Identifier persistence considerations . . . . . . . . . 5 + 2.7. Process of identifier assignment. . . . . . . . . . . . 5 + 2.8. Process for identifier resolution . . . . . . . . . . . 5 + 2.9. Rules for Lexical Equivalence . . . . . . . . . . . . . 5 + 2.10. Conformance with URN Syntax . . . . . . . . . . . . . . 5 + 2.11. Validation mechanism. . . . . . . . . . . . . . . . . . 5 + 2.12. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Namespace Considerations and Community Considerations . . . . 6 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Normative References. . . . . . . . . . . . . . . . . . 7 + 7.2. Informative References. . . . . . . . . . . . . . . . . 7 + Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 8 + Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 9 + +1. Introduction + + The International Press Telecommunications Council (IPTC) is a non- + profit consortium of the world's major news agencies and news + industry vendors. It develops and maintains technical standards for + the news business that are used by virtually every major news + organization in the world. IPTC was established in 1965. + + Since the 1990's IPTC's standardization work is based on open + standards like first SGML, then the XML [W3CXML] family of standards, + MIME, Unicode, and so on. + + As some of these standards require identification of resources IPTC + was looking for a technology for globally unique, persistent and + location-independent identifiers and decided to implement URNs as + described in "URN Syntax" [RFC2141] for this reason. + + This namespace specification is for a formal namespace. + + + + + + + +Steidl Informational [Page 2] + +RFC 3937 URN Namespace for IPTC October 2004 + + +2. IANA URN Specification Template + +2.1. Namespace ID + + "iptc" requested. + +2.2. Registration Information + + Registration Version Number: 1 + Registration Date: 2003-11-11 + + Declared registrant of the namespace: + + Registering organization: + International Press Telecommunications Council IPTC + Royal Albert House + Sheet Street + Windsor, Berkshire SL4 1BE + www.iptc.org + + Designated contact person: + Michael Steidl + Managing Director + mdirector@iptc.org + +2.3. Declaration of syntactic structure + + All URNs assigned by IPTC will have a Namespace Specific String (NSS) + of the following hierarchical structure: + + At the top of the hierarchy are three branches: + - "std" + - "std-draft" + - "workdoc" + + The "std" branch hierarchy: + + The "std" branch URNs will be assigned to IPTC resources + used for specifying and explaining any aspect of an IPTC + standard. + + The NSS in the "std" branch will have this general structure: + + urn:iptc:std:{std-name}:{std-version}:{res-group} + {:res-name}?{:res-version}? + + + + + + +Steidl Informational [Page 3] + +RFC 3937 URN Namespace for IPTC October 2004 + + + where + "std-name" is a unique identifier for an IPTC standard. + "std-version" reflects the version of this standard. The value + 'current' will be assigned to point at resources of the + current version of a standard. + "res-group": this field will take only three values: + "spec" for all resources specifying a standard, + "doc" for all resources used for additional documentation of + and to support the use of a standard. + "xmlns" for defining an XML namespace [W3CXMLNS]. + "res-name" is an identifier for a tangible resource; the name + should describe the content or the use of the resource. Since not + all resources are tangible this value is optional. + "res-version" reflects the version of this resource as long as it + takes a physical format - like e.g., a file. Since not all + resources are of a physical kind this value is optional. + + The "std-draft" branch hierarchy: + + The "std-draft" branch URNs will be assigned to IPTC resources + used for specifying and explaining any aspect of an IPTC standard + while being in draft status, that is at a time when the resource + is not formally approved by the IPTC Standards body. + + The NSS in the "std" branch will have this general structure: + + urn:iptc:std-draft:{std-name}:{std-version}:{res-group} + {:res-name}?{:res-version}? + + The substructure of "urn:iptc:std-draft" is identical to that of + "urn:iptc:std", find all explanations there. + + The "workdoc" branch hierarchy: + + The "workdoc" branch URNs will be assigned to IPTC resources not + directly related to IPTC standards but to the work of IPTC. + + The NSS in the "doc" branch will have this general structure: + + urn:iptc:workdoc:{group-id}:{doc-id}:{doc-version}{:doc-descr}? + + where + "group-id" is a unique identifier for working groups and working + areas of IPTC and constitutes a document group. + "doc-id" is a unique identifier for a document within a document + group. + + + + + +Steidl Informational [Page 4] + +RFC 3937 URN Namespace for IPTC October 2004 + + + "doc-version" reflects the version of this work document. + "doc-descr" is an optional concise description of the document + content. + +2.4. Relevant ancillary documentation + + None + +2.5. Identifier uniqueness considerations + + Identifier uniqueness will be enforced by the Managing Director of + IPTC who will assign unique identifiers to all resources identified + by a URN. + +2.6. Identifier persistence considerations + + IPTC is committed to maintaining the accessibility and persistence of + all resources that are identified by an IPTC URN. + +2.7. Process of identifier assignment + + Assignment is limited to the owner of this namespace and its + authorities. + +2.8. Process for identifier resolution + + IPTC will develop an appropriate mechanism that maps all assigned + URNs to Uniform Resource Locators (URL), specifically to enable web + based resolution of URNs. + +2.9. Rules for Lexical Equivalence + + No special considerations, the rules for lexical equivalence of RFC + 2141 apply. + +2.10. Conformance with URN Syntax + + No special considerations. + +2.11. Validation mechanism + + None specified. IPTC will develop a mechanism for resolving URNs to + URLs (see 2.8), this mechanism will also show whether a URN is valid. + +2.12. Scope + + Global. + + + + +Steidl Informational [Page 5] + +RFC 3937 URN Namespace for IPTC October 2004 + + +3. Examples + + The following examples are representative for IPTC URNs, but may not + refer to actual resources. + + urn:iptc:std:NewsML:1.1:spec:DTD:1 + DTD version 1 to specify the IPTC standard "NewsML", version 1.1 + + urn:iptc:std-draft:NITF:3.5:spec:xml-schema:2 + Second draft XML Schema for the IPTC standard "NITF", version 3.5 + + urn:iptc:std:SportsML:1.0:xmlns + URN to identify an XML namespace for the IPTC standard "SportsML", + version 1.0. No "res-name" and "res-version" since an XML + namespace is of no physical format. + + urn:iptc:std:NewsML:1.1:doc:news-agency-guidelines:1.2 + Supporting document named "news-agency-guidelines", version 1, + revision 2, based on the IPTC standard "NewsML" version 1.1. + + urn:iptc:workdoc:NMA:0315:1:srs-terms + Work document of IPTC's News Metadata Working Party (NMA), version + 1, holding terms of the Subject Reference System + +4. Namespace Considerations and Community Considerations + + The IPTC acknowledged already the use of URNs during the development + of its XML based standard "NewsML". This standard implements the use + of URNs as unique identifiers for news items as described in "URN + Namespace for NewsML resources" [RFC3085]. + + While developing additional XML based standards as siblings to + NewsML, IPTC soon got aware that URNs have to be assigned to + resources that fall beyond the scope of the NewsML namespace. For + this reason IPTC developed a new and very general hierarchical + namespace structure to cover the needs of the currently developed + standards as well as future standards and to be able to assign URNs + to resources emanating from them. + + In addition to resources relating directly to its standards, IPTC + also produces and publishes other documents relevant to the news + business. As those resources are used by many organizations outside + the IPTC membership and therefore could not be considered as internal + documents IPTC decided to add a branch to the URN hierarchy to be + assigned to these resources. + + + + + + +Steidl Informational [Page 6] + +RFC 3937 URN Namespace for IPTC October 2004 + + + IPTC maintains global activities and its standards as well as + resources based on them are used world wide. Since one focus of the + activities of IPTC is on global exchange of news any system for + unique identification of resources has to be considered under global + aspects. + + For this reason IPTC considers the introduction of a URN namespace + for its resources as proper action to maintain globally unique, + persistent and location-independent identifiers based on open + standards. + +5. Security Considerations + + There are no additional security considerations other than those + normally associated with the use and resolution of URNs in general. + +6. IANA Considerations + + This document includes a URN Namespace registration that conforms to + the "Uniform Resources Names (URN) Namespace Definition Mechanism" + [RFC3406] and has been entered into the IANA registry for URN NIDs. + +7. References + +7.1. Normative References + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, + "Uniform Resource Names (URN) Namespace Definition + Mechanisms", BCP 66, RFC 3406, October 2002. + +7.2. Informative References + + [W3CXML] W3C, XML WG, "Extensible Markup Language (XML) 1.0" (Third + Edition), February 2004, . + + [W3CXMLNS] W3C, Namespaces WG, "Namespaces in XML", January 1999, + . + + [RFC3085] Coates, A., Allen, D. and D. Rivers-Moore, "URN Namespace + for NewsML Resources", RFC 3085, March 2001. + + + + + + + + + +Steidl Informational [Page 7] + +RFC 3937 URN Namespace for IPTC October 2004 + + +Author's Address + + Michael Steidl + IPTC (International Press Telecommunications Council) + Royal Albert House + Sheet Street + Windsor SL4 1BE + United Kingdom + + Phone: +44 (1753) 705 051 + EMail: mdirector@iptc.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Steidl Informational [Page 8] + +RFC 3937 URN Namespace for IPTC October 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Steidl Informational [Page 9] + -- cgit v1.2.3