home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_u_z
/
draft-ietf-urn-nid-req-00.txt
< prev
next >
Wrap
Text File
|
1997-03-27
|
7KB
|
218 lines
INTERNET DRAFT Renato Iannella
draft-ietf-urn-nid-req-01.txt DSTC Pty Ltd
25 March, 1997 Patrik Faltstrom
Tele2/Swipnet
Namespace Identifier Requirements for URN Services
Status of this Memo
===================
This document is an Internet-Draft. 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.'
To learn the current status of any Internet-Draft, please check
the `1id-abstracts.txt' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
This draft expires 25 September, 1997.
Abstract:
=========
Services that offer to resolve Uniform Resource Names implicitly
require that they support a persistent and reliable service for an
indeterminate length of time. This draft outlines the requirements for
any such service that wishes to participate as a Namespace Identifier.
Introduction:
=============
The Uniform Resource Name (URN) Working Group has defined mechanisms
for both the syntax [4] and resolution of URNs [1,2]. An framework
for URN discovery systems has also been outlined [3]. This draft
discusses and recommends the requirements for entities that wish
to act as Namespace Identifiers (NIDs) within the URN system.
The URN syntax includes the NID which acts as the scoping
indicator for the URN. The NID indicates which Namespace
the URN belongs to and gives hints to the underlying resolution
service.
Consider the following example URNs:
urn:znet:metadata.net:dc
urn:buns:555555:annual-report
urn:hoptus:priv:555-ABCD
The NIDs in these cases, "znet", "buns", and "hoptus" all
act as top-level namespaces, and hence, must meet certain
guidelines to ensure meeting all the URN requirements [5].
In particular:
- Global Scope and Uniqueness
- Persistence
- Independence
- Resolution
Requirements:
=============
Given the four categories above, the requirements for each our
now outlined.
Global Scope and Uniqueness.
- The NID must be registered with IANA to ensure uniqueness and
demonstrating that it meets the requirements listed in this
document.
- A simple and limited character set should be imposed to
support global access (as described in [4]).
- Rules on how the Namespace Specific String are allocated
must be documented.
- Definitions of terms like "equal" and "different" for resources
must be published.
Persistence
- The NID service providers must show that they intend to
support the service for an indefinite period of time.
- Support facilities must be described and how the service
intends to operate, including "disaster recovery"-like
operations.
- Demonstrated experience in managing an established namespace
system is essential.
- One URN should never be reused for a different resource (where
"different" is defined as in previous paragraph by the namespace).
The URN should be persistent for all times, even though the
resource goes away.
Independence
- The NID service providers must also show any relationship
(both technical and administrative) that may impede on the
provision of the URN service.
- However, multi-party participation in the NID service is
an advantage.
Resolution
- The NID service providers must produce an RFC
describing the technical characteristics of the URN
resolution service, including security considerations.
- The NID service providers may elect not to have the
resolution service publically available.
Example:
=======
(1) urn:buns:555555:annual-report
This URN, in the namespace called "buns" is referring to the
document named annual-report, in postscript format.
At a later stage, that resource is replaced by a text version, which
lacks the pictures, but that is ok, because the namespace has decided
that postscript format documents and text documents are considered the
same even though the figures doesn't exist in the textual version.
In the third stage, the report is removed, and replaced with a report
for a different year. This new report gets a new URN because it is
considered being a different document.
The old URN is never reused.
(2) urn:foo:bar:current-weather
urn:foo:bar:weather/19970325
These are two URNs referring at one stage to the same resource, i.e.
on the 25th of March 1997. On the 26th of March 1997,
urn:foo:bar:current-weather is referring to the same resource as
urn:foo:bar:weather/19970326.
Conclusion:
===========
This draft has outlined the requirements for providers of
NID services for URN systems. The objective is to maintain
a high persistence rate for URN services, and these requirements
are aimed at ensuring a high level of service stability.
References:
===========
[1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
February, 1997.
[2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
draft-ietf-urn-http-conv-01.txt, February 1997
[3] Karen R Sollins, "Requirements and a Framework for URN Resolution
Systems", draft-ietf-urn-req-frame-00.txt, November 1996
[4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997.
[5] Karen R Sollins & Larry Masinter, "Functional Requirements for
Uniform Resource Names", RFC1737, December 1994
Security Considerations
=======================
It is a requirement that it in the definitions of a namespace are
included sections on security covering for example:
+ Spoofing of servers
+ Verification of responses
Because a namespace can decide that a resolution service is not
publically available, it is possible to use firewall installations and
other traffic limiting constructions to diconnect the namespace from
the global Internet.
Author Contact Information:
===========================
Renato Iannella
DSTC Pty Ltd
Gehrmann Labs, The Uni of Queensland
AUSTRALIA, 4072
voice: +61 7 3365 4310
fax: +61 7 3365 4311
email: renato@dstc.edu.au
Patrik Faltstrom
Tele2/Swipnet
Borgarfjordsgatan 16
P.O. Box 62
S-164 94 Kista
SWEDEN
voice: +46-5626 4000
fax: +46-5626 4200
email: paf@swip.net