| < draft-best-urn-oasis-01.txt | draft-best-urn-oasis-02.txt > | |||
|---|---|---|---|---|
| A new Request for Comments is now available in online RFC libraries. | ||||
| Network Working Group K. Best | RFC 3121 | |||
| Internet-Draft OASIS, Inc. | ||||
| Expires: August 6, 2001 N. Walsh | ||||
| Sun Microsystems, Inc. | ||||
| February 5, 2001 | ||||
| A URN Namespace for OASIS | ||||
| oasis | ||||
| draft-best-urn-oasis-01.txt | ||||
| Status of this Memo | ||||
| This document is an Internet-Draft and is in full conformance with | ||||
| all provisions of Section 10 of RFC2026. | ||||
| Internet-Drafts are working documents of the Internet Engineering | ||||
| Task Force (IETF), its areas, and its working groups. Note that | ||||
| other groups may also distribute working documents as | ||||
| Internet-Drafts. | ||||
| Internet-Drafts are draft documents valid for a maximum of six | ||||
| months and may be updated, replaced, or obsoleted by other documents | ||||
| at any time. It is inappropriate to use Internet-Drafts as reference | ||||
| material or to cite them other than as "work in progress." | ||||
| The list of current Internet-Drafts can be accessed at | ||||
| http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
| The list of Internet-Draft Shadow Directories can be accessed at | ||||
| http://www.ietf.org/shadow.html. | ||||
| This Internet-Draft will expire on August 6, 2001. | ||||
| Copyright Notice | ||||
| Copyright (C) The Internet Society (2001). All Rights Reserved. | ||||
| Abstract | ||||
| This document describes a URN namespace that is engineered by the | ||||
| Organization for the Advancement of Structured Information Standards | ||||
| (OASIS) for naming persistent resources published by OASIS (such as | ||||
| OASIS Standards, XML Document Type Definitions, XML Schemas, | ||||
| Namespaces, Stylesheets, and other documents). | ||||
| 1. Introduction | ||||
| The Organization for the Advancement of Structured Information | ||||
| Standards (OASIS) produces many kinds of documents: specifications, | ||||
| working drafts, technical resolutions, schemas, stylesheets, etc. | ||||
| OASIS wishes to provide global, distributed, persistent, | ||||
| location-independent names for these resources. | ||||
| The Extensible Markup Language (XML) requires that all resources | ||||
| provide a system identifier, which must be a URI, in addition to an | ||||
| optional public identifier (which provides an alternate mechanism | ||||
| for constructing identifiers) and many evolving specifications | ||||
| require authors to identify documents by URI alone (XML Namespaces, | ||||
| XML Schema, XSLT, etc.). | ||||
| Motivated by these observations, OASIS would like to assign URNs to | ||||
| some resources in order to retain unique, permanent | ||||
| location-independent names for them. | ||||
| This namespace specification is for a formal namespace. | ||||
| 2. Specification Template | ||||
| Namespace ID: | ||||
| "oasis" requested. | ||||
| Registration Information: | ||||
| Registration Version Number: 2 | ||||
| Registration Date: 2001-02-05 | ||||
| Declared registrant of the namespace: | ||||
| OASIS | ||||
| Karl Best | ||||
| Declaration of structure: | ||||
| The Namespace Specific String (NSS) of all URNs assigned by | ||||
| OASIS will have the following hierarchical structure: | ||||
| There are two branches at the top of the hierarchy: "names" | ||||
| and "member". | ||||
| The Names Hierarchy | ||||
| The NSS in the names hierarchy begins with a document class | ||||
| identifier. There are three classes of identifiers: | ||||
| "specification", "tc", and "technical". | ||||
| Specifications | ||||
| The "specification" hierarchy is for OASIS Specifications. The | ||||
| general structure of the NSS in the specification hierarchy | ||||
| has the form: | ||||
| urn:oasis:names:specification:{specification-id} | ||||
| :{type}{:subtype}?:{document-id} | ||||
| where "specification-id" is a unique identifier for the | ||||
| specification, "type" identifies the document type (document, | ||||
| schema, stylesheet, entity, xmlns, etc.), the optional | ||||
| "subtype" provides additional information about the document | ||||
| type (for example, stylesheet or schema language), and | ||||
| "document-id" is a unique identifier for the document. | ||||
| The Director of Technical Operations at OASIS assigns document | ||||
| types, subtypes, and all unique identifiers. | ||||
| Technical Committee Work Products | ||||
| The "tc" hierarchy is for work products of OASIS Technical | ||||
| Committees. The general structure of the NSS in the tc | ||||
| hierarchy has the form: | ||||
| urn:oasis:names:tc:{tc-id}:{type}{:subtype}?:{document-id} | ||||
| where "tc-id" is a unique identifier for the Technical | ||||
| Committee, and the remaining fields are assigned as per the | ||||
| specification hierarchy. | ||||
| Technical Papers | ||||
| The "technical" hierarchy identifies legacy documents | ||||
| (Technical Notes, Resolutions, Memoranda, and Research | ||||
| Papers). The general structure of the NSS in the "technical" | ||||
| hierarchies has the form: | ||||
| urn:oasis:names:technical:{document-type} | ||||
| :{document-id}:{amendment-id} | ||||
| The document type is one of the following: "note", | ||||
| "resolution", "memorandum", or "researchpaper". | ||||
| The document and amendment identifiers are derived from the | ||||
| legacy system for naming these documents. The document | ||||
| identifier consists of a two digit year and a sequential | ||||
| number, the amendment identifier is the year of the amendment. | ||||
| The Members Hierarchy | ||||
| The NSS in the members hiearchy begins with a unique member | ||||
| identifier assigned by OASIS. The string following the member | ||||
| identifier is opaque. For example: | ||||
| urn:oasis:member:A00024:x | ||||
| The member identifiers will be assigned by The Director of | ||||
| Technical Operations at OASIS. The opaque string is defined by | ||||
| the owner of the branch that begins with | ||||
| "urn:oasis:member:{member-id}:". | ||||
| Relevant ancillary documentation: | ||||
| None | ||||
| Identifier uniqueness considerations: | ||||
| Identifier uniqueness will be enforced by the Director of | ||||
| Technical Operations who assigns unique identifiers to all | ||||
| documents identified by URN. | ||||
| Identifier persistence considerations: | ||||
| OASIS is committed to maintaining the accessability and | ||||
| persistence of all the resources that are assigned URNs. | ||||
| Process of identifier assignment: | ||||
| Assignment is limited to the owner and those authorities that | ||||
| are specifically designated by the owner. OASIS will assign | ||||
| portions of its namespace (specifically, those under the | ||||
| members hierarchy) for assignment by other parties. | ||||
| Process of identifier resolution: | ||||
| The owner will distribute catalogs (OASIS TR9401 Catalogs) | ||||
| that map the assigned URNs to resource identifiers (e.g., | ||||
| URLs). A more interactive, online resolution system will also | ||||
| be deployed in the near future. | ||||
| The owner will authorize additional resolution services as | ||||
| appropriate. | ||||
| Rules for Lexical Equivalence: | ||||
| URNs are lexically equivalent if they are lexically identical. | ||||
| Conformance with URN Syntax: | ||||
| No special considerations. | ||||
| Validation mechanism: | ||||
| None specified. The owner will publish OASIS TR9401 Catalogs. | ||||
| The presence of a URN in a catalog indicates that it is valid. | ||||
| Scope: | ||||
| Global | ||||
| 3. Examples | ||||
| The following examples are not guaranteed to be real. They are | ||||
| listed for pedagogical reasons only. | ||||
| urn:oasis:names:specification:docbook:dtd:xml:4.1.2 | ||||
| urn:oasis:names:tc:docbook:dtd:xml:docbook:5.0b1 | ||||
| urn:oasis:names:technical:memo:9502:1995 | ||||
| urn:oasis:member:A00024:x | ||||
| 4. Security Considerations | ||||
| There are no additional security considerations other than those | ||||
| normally associated with the use and resolution of URNs in general. | ||||
| References | ||||
| [1] Goldfarb, C. F., "ISO (International Organization for | ||||
| Standardization) ISO 8879:1986(E) Information Processing -- | ||||
| Text and Office Systems -- Standard Generalized Markup Language | ||||
| (SGML)", 1986. | ||||
| [2] W3C, XML WG, "Extensible Markup Language (XML) 1.0", February | ||||
| 1998, | ||||
| <http://www.w3.org/TR/REC-xml>. | ||||
| [3] W3C, Namespaces WG, "Namespaces in XML", January 1999, | ||||
| <http://www.w3.org/TR/REC-xml-names>. | ||||
| [4] OASIS, Entity Mgmt. TC, "Entity Management: OASIS Technical | ||||
| Resolution 9401:1997 (Amendment 2 to TR 9401)", January 1994, | ||||
| <http://www.oasis-open.org/html/a401.htm>. | ||||
| [5] Moats, R., "URN Syntax", RFC 2141, May 1997. | ||||
| [6] Mealling, M. and R. Daniel, "URI Resolution Services Necessary | ||||
| for URN Resolution", RFC 2483, January 1999. | ||||
| Authors' Addresses | ||||
| Karl Best | ||||
| OASIS, Inc. | ||||
| P.O. Box 455 | ||||
| Billerica, MA 01821 | ||||
| US | ||||
| EMail: karl.best@oasis-open.org | Title: A URN Namespace for OASIS | |||
| Author(s): K. Best, N. Walsh | ||||
| Status: Informational | ||||
| Date: June 2001 | ||||
| Mailbox: karl.best@oasis-open.org, | ||||
| Norman.Walsh@East.Sun.COM | ||||
| Pages: 7 | ||||
| Characters: 11074 | ||||
| Updates/Obsoletes/SeeAlso: None | ||||
| Norman Walsh | I-D Tag: draft-best-urn-oasis-02.txt | |||
| Sun Microsystems, Inc. | ||||
| One Network Drive | ||||
| MS UBUR02-201 | ||||
| Burlington, MA 01803-0902 | ||||
| US | ||||
| EMail: Norman.Walsh@East.Sun.COM | URL: ftp://ftp.rfc-editor.org/in-notes/rfc3121.txt | |||
| Full Copyright Statement | This document describes a URN (Uniform Resource Name) namespace that | |||
| is engineered by the Organization for the Advancement of Structured | ||||
| Information Standards (OASIS) for naming persistent resources | ||||
| published by OASIS (such as OASIS Standards, XML (Extensible Markup | ||||
| Language) Document Type Definitions, XML Schemas, Namespaces, | ||||
| Stylesheets, and other documents). | ||||
| Copyright (C) The Internet Society (2001). All Rights Reserved. | This memo provides information for the Internet community. It does | |||
| not specify an Internet standard of any kind. Distribution of this | ||||
| memo is unlimited. | ||||
| This document and translations of it may be copied and furnished to | This announcement is sent to the IETF list and the RFC-DIST list. | |||
| others, and derivative works that comment on or otherwise explain it | Requests to be added to or deleted from the IETF distribution list | |||
| or assist in its implementation may be prepared, copied, published | should be sent to IETF-REQUEST@IETF.ORG. Requests to be | |||
| and distributed, in whole or in part, without restriction of any | added to or deleted from the RFC-DIST distribution list should | |||
| kind, provided that the above copyright notice and this paragraph | be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. | |||
| 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 | Details on obtaining RFCs via FTP or EMAIL may be obtained by sending | |||
| revoked by the Internet Society or its successors or assigns. | an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body | |||
| help: ways_to_get_rfcs. For example: | ||||
| This document and the information contained herein is provided on an | To: rfc-info@RFC-EDITOR.ORG | |||
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | Subject: getting rfcs | |||
| 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. | ||||
| Acknowledgement | help: ways_to_get_rfcs | |||
| Funding for the RFC editor function is currently provided by the | Requests for special distribution should be addressed to either the | |||
| Internet Society. | author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless | |||
| specifically noted otherwise on the RFC itself, all RFCs are for | ||||
| unlimited distribution.echo | ||||
| Submissions for Requests for Comments should be sent to | ||||
| RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC | ||||
| Authors, for further information. | ||||
| End of changes. 12 change blocks. | ||||
| 285 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||