< draft-ietf-urn-ietf-01.txt   draft-ietf-urn-ietf-02.txt >
Internet-Draft Ryan Moats Internet-Draft Ryan Moats
draft-ietf-urn-ietf-01.txt AT&T draft-ietf-urn-ietf-02.txt AT&T
Expires in six months June 1997 Expires in six months July 1997
A URN Namespace for IETF Documents A URN Namespace for IETF Documents
Filename: draft-ietf-urn-ietf-01.txt Filename: draft-ietf-urn-ietf-02.txt
Status of This Memo Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
skipping to change at page 1, line 32 skipping to change at page 1, line 32
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet- the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
A system for Uniform Resource Names (URNs) must be capable of A system for Uniform Resource Names (URNs) must be capable of
supporting new naming systems. As an example of the sort of supporting new naming systems. As an example of how a new namespace
information that needs to be supplied when proposing new namepsaces, may be proposed, this document presents a naming system based on the
this document presents a naming system based on the RFC family of RFC family of documents (RFCs, STDs, and FYIs) developed by the IETF
documents (RFCs, STDs, and FYIs) developed by the IETF and published and published by the RFC editor and the minutes of working groups
by the RFC editor and the minutes of working groups (WG) and birds of (WG) and birds of a feather (BOF) meetings that occur during IETF
a feather (BOF) meetings that occur during IETF conferences. This conferences. This namespace can be supported within the URN
namespace can be supported within the URN framework and the currently framework and the currently proposed syntax for URNs.
proposed syntax for URNs.
1. Namespace Syntax 1. Namespace Syntax
Consistent with the URN syntax specification [1], each namespace must Consistent with the URN syntax specification [1], each namespace must
specify syntax related information that is specific to that specify syntax related information that is specific to that
namespace. This section covers these specifications. namespace. This section covers these specifications.
1.1. Namespace Identifier (NID) 1.1. Namespace Identifier (NID)
The namespace identifier for this namespace is "ietf". The namespace identifier for this namespace is "ietf".
skipping to change at page 2, line 36 skipping to change at page 2, line 36
in the RFC family. As new document series are added to the IETF in the RFC family. As new document series are added to the IETF
family by the IESG (or its successor), this ABNF specification will family by the IESG (or its successor), this ABNF specification will
need to be updated. Any system intended to resolve names for this need to be updated. Any system intended to resolve names for this
namespace should be written with the awareness that a new document namespace should be written with the awareness that a new document
series may be introduced at any time. series may be introduced at any time.
The ABNF specification for "wgbofname" is based on the current and The ABNF specification for "wgbofname" is based on the current and
past abbreviations for working groups and BOFs in the IETF. If a past abbreviations for working groups and BOFs in the IETF. If a
working group or BOF is created that used characters outside the working group or BOF is created that used characters outside the
range of this ABNF specification, this specification will need to be range of this ABNF specification, this specification will need to be
update. Any system intended to resolve names for this namespace updated. Any system intended to resolve names for this namespace
should be written with the awareness that this could occur at any should be written with the awareness that this could occur at any
time. time.
1.3. Additional Reserved Characters
1.3. Assignment of URNs in this Namespace
URNs are assigned in the namespace in two ways. The first is when a
new RFC, FYI or STD is passed by the IESG and published by the RFC
Editor. This new document will have a new series number and will
therefore define a new URN. The document mappings maintained by the
RFC Editor (the index files "rfc-index.txt", "fyi-index.txt", "std-
index.txt") are defined to be the definitive statement of the
assignment of RFC Family URNs in this namespace.
The second way a URN is assigned is when a working group or birds of
a feather files meeting minutes as part of an IETF conference. The
list of minutes maintained by the IETF for each working group and
conference in the subtree pointed at by the URL ftp://ietf.org/ietf/
is considered the definitive assignment of URNs for working group or
birds of a feather minutes.
1.4. Additional Reserved Characters
No characters in addition to those specified in [1] are reserved by No characters in addition to those specified in [1] are reserved by
this namespace. this namespace.
1.4. Additional Lexical Equivalence Relations 1.5. Additional Lexical Equivalence Relations
Note that the entire URN is case-insensitive, because of the Note that the entire URN is case-insensitive, because of the
definition of the NSS. definition of the NSS.
1.5. Functional Equivalence Relations 1.6. Functional Equivalence Relations
Rules for equivalence in this namespace are embedded in the document Rules for equivalence in this namespace are embedded in the document
mappings maintained by the RFC Editor (the index files "rfc- mappings maintained by the RFC Editor (the index files "rfc-
index.txt", "fyi-index.txt", "std-index.txt"). A resource is index.txt", "fyi-index.txt", "std-index.txt"). A resource is
equivalent to the set of resources implied by the "(Also...)" equivalent to the set of resources implied by the "(Also...)"
construct in these mappings. As an example, the URN construct in these mappings. As an example, the URN
"urn:ietf:rfc:1661" is equivalent to th URN "urn:ietf:std:51" because "urn:ietf:rfc:1661" is equivalent to th URN "urn:ietf:std:51" because
the "rfc-index.txt" map shows that RFC 1661 is also STD 51. However, the "rfc-index.txt" map shows that RFC 1661 is also STD 51. However,
the URN "urn:ietf:std:51" is equivalent to the SET of URNs the URN "urn:ietf:std:51" is equivalent to the SET of URNs
"urn:ietf:rfc:1661" and "urn:ietf:rfc:1662" since the "std-index.txt" "urn:ietf:rfc:1661" and "urn:ietf:rfc:1662" since the "std-index.txt"
shows that STD 51 is also RFC 1661 and RFC 1662. Therefore, a shows that STD 51 is also RFC 1661 and RFC 1662. Therefore, a
resolver receiving a N2R request for "urn:ietf:std:51" MUST return resolver receiving a N2R request for "urn:ietf:std:51" MUST return
either STD 51 or BOTH RFC 1661 and RFC 1662. either STD 51 or BOTH RFC 1661 and RFC 1662.
2. Security Considerations 2. Comments
Readers will notice that this namespace does not include internet
drafts. While these documents are published by the internet drafts
editor, they were excluded because they do not provide persistent
resources to refer to (all internet drafts expire after six months).
This is as opposed to the RFC family of documents which never expire
(an RFC may be obsoleted or superceded but the actual RFC document
itself does not expire).
3. Security Considerations
Because this namespace defines no additional reserved characters, it Because this namespace defines no additional reserved characters, it
does not add any security considerations beyond those inherent from does not add any security considerations beyond those inherent from
the existence of the reserved characters from [1]. Further, the the existence of the reserved characters from [1]. Further, the
definition of the NSS above does not use any of the reserved definition of the NSS above does not use any of the reserved
characters from [1], which means that resolvers for this namespace characters from [1], which means that resolvers for this namespace
may be considered "secure" in the sense that any escaping of may be considered "secure" in the sense that any escaping of
characters in the NSS MUST result in the resolver indicating that the characters in the NSS MUST result in the resolver indicating that the
URN has incorrect syntax. URN has incorrect syntax.
3. Acknowledgments 4. Acknowledgments
Thanks to various members of the URN working group for comments on Thanks to various members of the URN working group for comments on
earlier drafts of this document. The work described in this document earlier drafts of this document. The work described in this document
is partially supported by the National Science Foundation, is partially supported by the National Science Foundation,
Cooperative Agreement NCR-9218179. Cooperative Agreement NCR-9218179.
4. References 4. References
Request For Comments (RFC) and Internet Draft documents are available Request For Comments (RFC) and Internet Draft documents are available
from <URL:ftp://ftp.internic.net> and numerous mirror sites. from <URL:ftp://ftp.internic.net> and numerous mirror sites.
skipping to change at page 4, line 4 skipping to change at page 4, line 31
Specifications: ABNF," Internet Draft (work in pro- Specifications: ABNF," Internet Draft (work in pro-
gress), January 1997. gress), January 1997.
5. Author's Address 5. Author's Address
Ryan Moats Ryan Moats
AT&T AT&T
15621 Drexel Circle 15621 Drexel Circle
Omaha, NE 68135-2358 Omaha, NE 68135-2358
USA USA
Phone: +1 402 894-9456 Phone: +1 402 894-9456
EMail: jayhawk@att.com EMail: jayhawk@att.com
This Internet Draft expires December 31, 1997. This Internet Draft expires January 31, 1998.
 End of changes. 11 change blocks. 
17 lines changed or deleted 45 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/