summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3937.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3937.txt')
-rw-r--r--doc/rfc/rfc3937.txt507
1 files changed, 507 insertions, 0 deletions
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, <http://www.w3.org/TR/REC-xml>.
+
+ [W3CXMLNS] W3C, Namespaces WG, "Namespaces in XML", January 1999,
+ <http://www.w3.org/TR/REC-xml-names>.
+
+ [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]
+