Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3937

A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)

Pages: 9
Informational

Top   ToC   RFC3937 - Page 1
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.
Top   ToC   RFC3937 - Page 2

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.
Top   ToC   RFC3937 - Page 3

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}?
Top   ToC   RFC3937 - Page 4
      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.
Top   ToC   RFC3937 - Page 5
      "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.
Top   ToC   RFC3937 - Page 6

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.
Top   ToC   RFC3937 - Page 7
   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.
Top   ToC   RFC3937 - Page 8

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
Top   ToC   RFC3937 - Page 9
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.