💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc3937.txt captured on 2021-11-30 at 20:18:30.
-=-=-=-=-=-=-
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]