# Critical Comparison of URN Proposals

Mark Madsen (msm@ansa.co.uk)
Thu, 13 Jul 95 17:33:34 BST

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ronald E. Daniel: "Re: yet another revision of the charter"
- Previous message: Roy Fielding: "Re: yet another revision of the charter"
- Next in thread: Daniel LaLiberte: "Re: Critical Comparison of URN Proposals"
- Maybe reply: Daniel LaLiberte: "Re: Critical Comparison of URN Proposals"

    From: Mark Madsen <msm@ansa.co.uk>

    Message-Id: <9507131633.AA02155@euclid.ansa.co.uk>

    Subject: Critical Comparison of URN Proposals

    To: uri@bunyip.com

    Date: Thu, 13 Jul 95 17:33:34 BST

The attached is the preliminary version of a critique of the existing
URN proposals. I wrote it in the hope that it would form the basis of
a discussion of those proposals in a top-down fashion.

    --
    Mark Madsen: <msm@ansa.co.uk> <URL:http://www.ansa.co.uk/Staff/msm.html>
    Information Services Framework, The ANSA Project, APM Ltd., Castle Park,
    Cambridge CB3 0RD, U.K.  <URL:http://www.ansa.co.uk/>;  <apm@ansa.co.uk>
    Voice: +44-1223-568934; Reception: +44-1223-515010; Fax: +44-1223-359779

    -------------------------------slice here-------------------------------
    IETF URI Working Group                                 Mark Madsen
    Internet-Draft                                             APM Ltd
    draft-ietf-uri-urn-madsen-critique-00.txt
    Expires: 18 January 1996                               13 July 1995

               A Critique of Existing URN Proposals

    Abstract

    This document criticises existing URN (Uniform Resource Name)
    proposals in the light of generality, extensibility, and general
    futureproofing.  The idea is to draw upon the best characteristics of
    the existing proposals so as to converge on an acceptably functional
    and nonrestrictive draft specification for both URN syntax and
    resolution schemes.

    1. Introduction

    The URI (Uniform Resource identifier) Working Group is currently
    stalled on the issue of how to implement URNs.  There is no shortage
    of proposals, but no single proposal has been perfected, and all
    contain shortcomings which have prevented them gaining widespread
    support from the members of the working group.

    The aim of this document is to criticise the existing proposals in a
    constructive manner, so as to draw out their positive qualities, and
    then to develop a modular scheme for combining these best components
    into new URN schemes.

    Some specific architectural considerations are derived and discussed
    in the following section.

    2. General Issues

    Requirements on URNs are discussed in [S&M].  These may be divided
    into requirements on URNs themselves (global scope, location
    independence, global uniqueness, and persistence), requirements on URN
    schemes (scalability, legacy support, extensibility, independence of
    naming authorities, resolvability), and requirements on URN encodings
    (single encoding, simple comparison, transcribability,
    transportability, parsability).

    To these requirements could be added the necessity not to make any URN
    scheme into a straitjacket for future Internet development.
    Fulfillment of this requirement will clearly only be possible if the
    issues relating to URN construction are separated from those relating
    to resolution of URNs into other classes of Uniform Resources.

    The next few sections discuss the existing proposals and documents in
    the light of the considerations derived in this section.

    3. Critiques of URN Proposals

    The proposals are treated in chronological order.

    3.1 The Path URN Scheme

    This is described in internet draft draft-ietf-uri-urn-path-00.txt
    "The Path URN Specification" by Daniel LaLiberte and Michael Shapiro.

    The path scheme is based on the idea of an hierarchical name space,
    with naming authorities being responsible for specified subtrees of
    the name space.  The problem with this, as with any other hierarchical
    scheme, is that of management of the levels near the root.  Experience
    with DNS (Domain Naming Scheme) shows that this can be a serious
    problem when weaknesses in the distribution of structure ar exposed by
    use (as is presently the case with the .com subhierarchy).  Since
    there are expected always to be many more resources in the Internet
    than machines, the management problems can be expected to be severe.
    Management issues are not addressed in the path scheme proposal.

    The reason for the hierarchy built into the path scheme is that it
    builds in the association between (sets of) naming authorities and
    resolution services.  URN resolution is therefore an in-principle
    terminating process, which is a positive point in favour of the
    scheme.  In practice, failures will isolate entire subtrees of the
    hierarchy from resolution.  DNS service failures are typically
    softened by the practice of maintaining caches of all lookups: this
    will not work as well for URN resolution because the Internet-wide
    rate of creation and alteration of resources can reasonably be
    expected to be many orders of magnitude greater than the addition of
    new IP addresses.

    A stronger criticism of the path scheme is that the hierarchical
    process of resolution ties each resource's URN to a particular
    resolution service in perpetuity.  Furthermore, the worst-case
    scenario for resolution of a URN could involve as many resolution
    services as there are components in the path of the URN under this
    scheme.

    Tying URN construction and assignation to resolution in any way is a
    stringent limit on the freedom of future Internet engineering to
    exploit new technologies.  At the time of writing, trading technology
    is becoming widespread.  Future traders could be badly hindered by
    being constrained to resolve URNs in a path hierarchy.  This is not to
    say that hierarchical schemes cannot or should not be built: in fact,
    they may work better than any other type in certain circumstances and
    for certain purposes.  However, it is easy to impose an hierarchical
    resolution structure on a general namespace, so long as that namespace
    is not itself tied to some other restrictive resolution scheme.

    Many of the criticisms that apply to this scheme can be equally well
    applied to some of the others discussed below.

    3.2 The x-dns-2 Scheme

    This is described in internet draft draft-ietf-uri-urn-x-dns-2-00.txt
    "x-dns-2 URN Scheme" by Paul Hoffman and Ron Daniel.

    This scheme is subject to the same criticism as the path scheme about
    the way that the syntax incorporates the resolution service in the URN
    itself.  However, this scheme will coexist reasonably well with other
    schemes, because it encodes the "x-dns-2" scheme name in the URN as
    well.  However, this means that resolvers unfamiliar with this scheme
    convention may have difficulty in resolving such a URN.

    Resolution in this scheme is handled by doing a standard DNS lookup to
    find the resolution authority, and requesting direct resolution of the
    URN from them.  Whether DNS can scale to cope with the number of
    resolution requests that could conceivably be generated in such a
    scenario seems doubtfuul.  This also exposes the fact that the scheme,
    like the path scheme, relies on the naming authority and resolution
    service being closely linked, an assumption which is unlikely to
    remain true in the long term, as commercial and specialised resolution
    services are set up.

    A more serious criticism is that the scheme is tightly constrained in
    two ways.  One is that it relies on being able to use HTTP headers.
    This is a weakness, since one of the ways currently being considered
    for improving HTTP's slowness is to change the ways in which headers
    are dealt with.  Similarly, the scheme uses the HTTP status-line for
    tracking resolution success and failure.  Thus the scheme is seen to
    be too closely tied to HTTP to have a long lifetime [Madsen95].

    3.3 The Handle Scheme

    This is described in internet draft draft-ietf-uri-urn-handles-00.txt
    "The Handle System" by William Harms and David Ely.

    The handle scheme shares many characteristics with the aformentioned
    URN schemes.  There is a namesapce hierarchy, in which there are extra
    features, such as the ability for naming authorities to create
    subsidiary naming authorities.  There is a global handle server, which
    is distributed, and local handle servers, which gives a more flexible
    model of how resolution may proceed.  However, these servers are again
    both naming authorities and resolution services, with all the
    limitations that implies.

    The handle syntax itself seems too complicated for naming, and
    sepcifies that the handles carry along with them sets of typed
    structured information, and corresponding administrative information.
    This is restrictive, and collides badly with the URI-WG's attempt to
    provide a functionally clean repository for resource metadata in the
    framework of URC schemes.

    The proposal also considers such issues as handle administration tols,
    access to services through firewalls, and cacheing of handles.  While
    important, these issues are orthogonal to the construction of naming
    scheme frameworks, and should be left to other documents.

    3.4 The OCLC Scheme

    This is slightly different from the preceding documents and is
    described in internet draft draft-ietf-uri-urn-resolution-01.txt "URN
    Services" by Keith Shafer, Eric Miller, Vincent Tkac and Stuart Weibel.

    This scheme is the most flexible of those proposed.  It allows for the
    existence of different naming authorities with different authority
    levels, and for different resolution services.  It does provide for
    the "author" of a resource to specify the resolution service to be
    used for a given URN.  This is a drawback in two ways, firstly that it
    restricts the freedom to generate new resolution services, and
    secondly it leaves old URNs high and dry when the author-specified
    resolution service overloads/fails/explodes.  It is also probably a
    bad idea to assume that with each resource there can be associated an
    author that is a single coherent entity.

    It is interesting and useful that this proposal recommends a
    resolution-request syntax, but it is important that this should be
    seen only as a baseline, since different resolution services will
    almost certainly wish to offer differentiating syntaxes and resolution
    criteria.  The proposed URN sysntax itself consists simply of the
    naming authority name paired with the opaque string assigned to the
    resource by that authority.  This means that the naming authority can
    still be queried for validation of a URN, but that it is not in
    general expected to provide the resolution service itself.

    Another advantage of decoupling naming and resolution as seen in this
    scheme is that for small URN collections issued by single naming
    authorities, the optimisation of having those naming authorities offer
    their own resolution service is simply arranged: other resolution
    services simply each maintain a table of known naming authrities,
    marking each according to whether they perform resolution or not.

    4. Summary and Conclusions

    None of the existing proposals is entirely satisfactory.  The most
    promising framework from the point of view of extensibility and
    future-proofness would be one constructed on the basis of the OCLC
    scheme.  it is recommended that this be implemented and tested, along
    with implementation specifications for the other schemes to show how
    they compare mutually when built on top of this basic framework.

    The result of following this recommendation will be a framework within
    which multiple URN schemes can coexist, each offering their own
    particular advantages in a given situation, while allowing naming
    authorities to issue URNs appropriately.

    5. Security Considerations

    This document does not raise any security considerations beyond those
    normally associated with URN storage and resolution.  Note, however,
    that any URN scheme intended to allow secure resolution must provide
    for encryption of transmitted URN data.  This point has been
    emphasised by Mark Fisher in a sequence of messages to the URI-WG
    mailing list.

    6. Acknowledgements

    The author is grateful to Andrew Herbert, Rob van der Linden, Nigel
    Edwards and Owen Rees for discussions relating to the management and
    resolution of URNs.  Thanks also go to those authors who have written
    the internet drafts discussed in this document.

    7. References

    [Madsen95] Mark Madsen, "Decoupling the URL Scheme from the Transport
    Protocol", June 1995.
    <URL:http://www.ansa.co.uk/phase3-activities/decoupling.html>

    [S&M] Karen Sollins and Larry Masinter, "Functional Requirements for
    Uniform Resource Names", RFC 1737, December 1994.

    8. Author's Address

    Mark Madsen <msm@ansa.co.uk>
    Information Services Framework Group
    Architecture Projects Management Ltd
    Poseidon House, Castle Park
    Cambridge CB3 0RD, UK

    Telephone +44-1223-568934
    Facsimile +44-1223-359779

- Next message: Ronald E. Daniel: "Re: yet another revision of the charter"
- Previous message: Roy Fielding: "Re: yet another revision of the charter"
- Next in thread: Daniel LaLiberte: "Re: Critical Comparison of URN Proposals"
- Maybe reply: Daniel LaLiberte: "Re: Critical Comparison of URN Proposals"