draft-ietf-urn-rfc2611bis-01.txt   draft-ietf-urn-rfc2611bis-02.txt 
Internet-Draft L. Daigle Internet-Draft L. Daigle
URN WG Thinking Cat Enterprises URN WG Thinking Cat Enterprises
Expires August 11, 2001 D. van Gulik Expires September 1, 2001 D. van Gulik
Category: Best Current Practice WebWeaving Category: Best Current Practice WebWeaving
draft-ietf-urn-rfc2611bis-01.txt R. Iannella draft-ietf-urn-rfc2611bis-02.txt R. Iannella
IPR Systems IPR Systems
P. Faltstrom P. Faltstrom
Cisco Cisco
February 11, 2001 March 1, 2001
URN Namespace Definition Mechanisms URN Namespace Definition Mechanisms
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 4, line 34 skipping to change at page 4, line 34
uphold the general principles of a well-managed URN namespace -- uphold the general principles of a well-managed URN namespace --
providing persistent, unique identification of resources. Informal providing persistent, unique identification of resources. Informal
and formal namespaces (described below) differ in the NID assignment. and formal namespaces (described below) differ in the NID assignment.
IANA will assign an alphanumeric NID to registered informal IANA will assign an alphanumeric NID to registered informal
namespaces, per the process outlined in Section 4.0. namespaces, per the process outlined in Section 4.0.
3.3 Formal Namespaces 3.3 Formal Namespaces
A formal namespace may be requested, and IETF review sought, in cases A formal namespace may be requested, and IETF review sought, in cases
where the publication of the NID proposal and the underlying where the publication of the NID proposal and the underlying
namespace will provide benefit to an open and broad base of the namespace will provide benefit to some subset of users on the
Internet community. That is, as in any open standards outcome, Internet. That is, a formal NID proposal, if accepted, must be
publication of the NID proposal would allow persons not immediately functional on and with the global Internet, not limited to users in
associated with the proposer to work with the identifiers, or communities or networks not connected to the Internet. For example, a
otherwise better carry out their own activities than if the NID NID is requested that is meant for naming of physics research. If
publication had not been made. Benefits are expected to be in the that NID request required that the user use a propietary network or
form of open accessibility, interoperability, etc. service that was not at all open to the general Internet user then it
would make a poor request for a formal NID. The intent is that, while
the community of those who may actively use the names assigned within
that NID may be small (but no less important), the potential use of
names within that NID is open to any user on the Internet.
It is expected that Formal NIDs may be applied to namespaces where It is expected that Formal NIDs may be applied to namespaces where
some aspects are not fully open. For example, a namespace may make some aspects are not fully open. For example, a namespace may make
use of an externally managed (proprietary) registry (as, e.g., ISBN use of an privately managed (proprietary) registry (as, e.g., ISBN
does), for assignment of URNs in the namespace, but it may still does), for assignment of URNs in the namespace, but it may still
provide broad community benefit if the services associated have provide benefit to some Internet users if the services associated
openly-published access protocols. have openly-published access protocols.
In addition to the basic registration information defined in the In addition to the basic registration information defined in the
registration template (in Appendix A), a formal namespace request registration template (in Appendix A), a formal namespace request
must be accompanied by documented considerations of the need for a must be accompanied by documented considerations of the need for a
new namespace and the community benefit of formally establishing the new namespace and the community benefit of formally establishing the
proposed URN namespace. proposed URN namespace.
Additionally, since the goal of URNs is to provide persistent Additionally, since the goal of URNs is to provide persistent
identification, some consideration as to the longevity and identification, some consideration as to the longevity and
maintainability of the namespace must be given. The URN WG discussed maintainability of the namespace must be given. The URN WG discussed
skipping to change at page 8, line 22 skipping to change at page 8, line 24
- URN resolution/delegation - URN resolution/delegation
- type of resources to be identified - type of resources to be identified
- type of services to be supported - type of services to be supported
NOTE: It is expected that more than one namespace may serve the same NOTE: It is expected that more than one namespace may serve the same
"functional" purpose; the intent of the "Namespace Considerations" "functional" purpose; the intent of the "Namespace Considerations"
section is to provide a record of the proposer's "due diligence" in section is to provide a record of the proposer's "due diligence" in
exploring existing possibilities, for the IESG's consideration. exploring existing possibilities, for the IESG's consideration.
The RFC must also include a "Community Considerations" section, which The RFC must also include a "Community Considerations" section, which
indicates the dimensions upon which the proposer expects the Internet indicates the dimensions upon which the proposer expects its
community to be able to benefit by publication of this namespace. community to be able to benefit by publication of this namespace as
Potential considerations include: well as how a general Internet user will be able to use the space if
they care to do so. Potential considerations include:
- open assignment and use of identifiers within the namespace - open assignment and use of identifiers within the namespace
- open operation of resolution servers for the namespace - open operation of resolution servers for the namespace
(server) (server)
- creation of software that can meaningfully resolve and - creation of software that can meaningfully resolve and
access services for the namespace (client) access services for the namespace (client)
The RFC must include an "IANA Considerations" section, indicating
that the document includes a URN NID registration that is to be
entered into the IANA registry of URN NIDs.
A particular NID string is requested, and is assigned by IETF A particular NID string is requested, and is assigned by IETF
consensus (as defined in [RFC2434]), with the additional constraints consensus (as defined in [RFC2434]), with the additional constraints
that the NID string must that the NID string must
- not be an already-registered NID - not be an already-registered NID
- not start with "x-" (see Type I above) - not start with "x-" (see Type I above)
- not start with "urn-" (see Type II above) - not start with "urn-" (see Type II above)
- not start with "XY-", where XY is any combination of 2 - not start with "XY-", where XY is any combination of 2
ASCII letters (see NOTE, below) ASCII letters (see NOTE, below)
- be more than 2 letters long - be more than 2 letters long
skipping to change at page 9, line 24 skipping to change at page 9, line 31
the danger of "spoofing" and providing mis-information. Information the danger of "spoofing" and providing mis-information. Information
in these declarations should be taken as advisory. in these declarations should be taken as advisory.
6.0 IANA Considerations 6.0 IANA Considerations
This document outlines the processes for registering URN namespaces, This document outlines the processes for registering URN namespaces,
and has implications for the IANA in terms of registries to be and has implications for the IANA in terms of registries to be
maintained. In all cases, the IANA should assign the appropriate NID maintained. In all cases, the IANA should assign the appropriate NID
(informal or formal), as described above, once an IESG-designated (informal or formal), as described above, once an IESG-designated
expert has confirmed that the requisite registration process steps expert has confirmed that the requisite registration process steps
have been completed. have been completed. This document replaces the processes outlined
in [RFC2611].
7.0 References 7.0 References
[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange
formats - Information interchange - Representation of formats - Information interchange - Representation of
dates and times" dates and times"
[RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing
Bibliographic Identifiers as Uniform Resource Names", RFC Bibliographic Identifiers as Uniform Resource Names", RFC
2288, February 1998. 2288, February 1998.
skipping to change at page 11, line 21 skipping to change at page 11, line 26
- entities seeking to provide URN resolvers for a namespace (if - entities seeking to provide URN resolvers for a namespace (if
applicable) applicable)
This is particularly important for communities evaluating the This is particularly important for communities evaluating the
possibility of using a portion of an existing URN namespace rather possibility of using a portion of an existing URN namespace rather
than creating their own. than creating their own.
Information in the template is as follows: Information in the template is as follows:
Namespace ID: Namespace ID:
Assigned by IANA. In some contexts, a particular one may be Assigned by IANA. In the case of a Formal NID registration,
requested (see below). a particular NID string may be requested.
Registration Information: Registration Information:
This is information to identify the particular version of This is information to identify the particular version of
registration information: registration information:
- registration version number: starting with 1, incrementing by 1 - registration version number: starting with 1, incrementing by 1
with each new version with each new version
- registration date: date submitted to the IANA, using the format - registration date: date submitted to the IANA, using the format
YYYY-MM-DD YYYY-MM-DD
 End of changes. 10 change blocks. 
19 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/