Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-minutes-97aug.txt

Text File | 1997-10-10 | 8KB | 173 lines

                   Minutes of the URN Working Group
                        39th IETF Munich Germany
                          August 7, 1997

Session Chair:  Leslie Daigle
Minutes: Dirk-Willem van Gulik



Leslie: Agenda: A number of documents (outstanding ID's plus those currently
prepared by Patrik/Renato on the namespace ID) and their open issues are to be
discussed. Plus there is a request honoured for a short presentation/
discussion of CNRI's Handle System.


o Documents on the table

Currently the intent is for two informational and one experimental RFC to be
produced. The URI-Resolution services document is to go into the experimental
track and the two background documents (about the architecture and
the "IETF" URN namespace) are to have an informational status.

Within these documents a number of open issues are identified; with the
details and process for handling of new URN name spaces requests as
the main issue. It is emphazised that the IANA part is to be a largely
mechanical process; i.e firm, technical rules, and no interpretation.

Ted Hardie adds that user friendly name spaces are not to be an issue;
although Karen Sollins adds that retrofitted legecy namespaces might be
relatively friendly. The pitfalls are well known; and grim tales of the
tld-wars and their free for all/first-come-first-serve procedure are
related.

It is pointed out that IANA currently assigns names based on procedures
described in informational RFC's; i.e. such a document does not need
to be a full blown standards track document.

So in short; the proposed/to-be-created namespace procedural document
needs to distinguish between:

    - ietf-based standarized namespaces and
    - experimental/private namespaces (which are registered to
      avoid collisions and permit global use as desired)
with:

    - assigned names/numbers for non-standardized name space
    - _technical_ guidelines for namespaces of all descriptions
    - need mechanical rules for registration

Within this framework Patrik Faltstrom (who works on this with Renato
Iannella) points out in a short presentation that:

    - Vanity names and numbers are a problem.

    - A Namespace is to be defined as something which
        has an authority on the names.

     - Each name space then propably has a number of (well
      defined and specific) related services for registration
      and resolution of the urns.

    - The hard part is to determine for a given name space

        who can be responsible

        stability. what happens when the organization goes away

        is a resolution service also authoritative

    This last point of patrik's raises a discussion (largely based on
    examples from the RFC space; created by Ryan Moats but under the
    flag of the IANA, with questions like: is the entity creating
    the name space (or the entity authoritative on the name space)
    also responsible for resolution? and/or automatically authoritative
    for the resolution? Where does the authority begin and end?

The above presentation is cut short; Leslie's summary; there are two
levels, with different roles and functions (standards-track and
experimental/private). Dirk/Karen interrupt and add that one cannot impose all
that much; some names might never (fully) resolve or not even resolve
authoritatively; privacy, quality, approval, issues etc. Patrik/Dirk focus on
the fact that the approval is only into one direction; i.e. there can be
competitive resolution services for the same name space; for example ISBN
resoution currently offered by various third parties; even though the first
party is not offering such a service. This translates into a requirement for
the name space creation document where the above mechanics must lead to a rule
for a particular name space with regards to the relation between the
naming authority, the name and its resolution in, possibly, both
directions. Ted/Leslie state that (most) namespaces will not allow
for authoritative resolution without explicit consent/cooperation from
the naming authority. This, and the one-way direction argument,
seem to be understood as an important part of any namespace by most
participants. This leads to the name space ownership issues; with
related issues such as can one believe someone who claims to be
authoritative on a resolution; which claims should one believe (and if
self-asserted claims are valid). The tendency seems to be to
firmly split authority for assignment and resoution. However there seems to
a strong voice to insist on at least one registry and one resolution
service for a acceptable name space. This resolution service
might not be authoritative though. Also one should not try to
avoid/solve the problem of having many names for one object.

Patrik wants to focus on just the requirements for registering
the namespace without any reference to resolution; Michael Mealling/Leslie
and Keith counter/add requirments instead for the actual
registered namespace (and resolution); such as multiple resolvers,
conflicts between resolvers, authoritative resolvers. And do
most certainly want to consider issues with grandfathering in schemes.

As a sideline; what to do with existing legacy schemes, such as ISBN,
and more particular who can claim to be the 'owner' of them. A
concrete example is Ryan; can he register the 'rfc' space; or does
he need the explicit consent of the IANA/IAB/IESG or Jon Postel. If
he needs such a consent, is a self-claimed one good enough  as the
(legal) mechanics to verify are daunting/not realistic according
to some. Some people translate this into an extra requirment for
the name space registration procedure to allow for many to many
relations in both registration and resolution of the actual URNs
for what are essentially the same objects.

This leads to the question 'what' one gets when one asks for a name
space; just a prefix; or also responsibility and the duty to assign
and manage the space it self and/or the duty to assign (or perhaps
even manage) the resolver assignment and/or authoritative resolvers.

The consensus seems to that a namespace is limited to just a prefix,
responsibility to manage the name space and the responsibility to
manage (authoritative??) resolver assignment. The latter might translate
into a requirement for the document; the scope of a name space, and
what a name can be resolved into under auspices of the naming
authority should be clear from the outset. (Though third parties
might provide aditional resolution services).

It is stressd that the authority who assigns the identifiers is not
nessesarily the owner of the space. The first is easy to identify,
the latter is often not.

It is debated wether publishing the name assignment and/or resolution
mechanics in an RFC is a usefull requirment or pre-requisite for creating
a name space (and perhaps use the RFC number as the name space identifier).

It is countered that the assignment/structure of a name space might be
far away from the resolution mechanics; and syntaxes can be too opaque
to make such documents realistic. But in general it seems that any
reasonable hurdle on the road to obtaining a namespace is welcomed.

The issue of sub delegation and the specification of any mechanics
in the namespace establishing document is brought to attention.

Michael/(?) conclude that we need more experience; and waiting to
see how the RFC space develops might be worth the wait. Although the
URL prefixes offer an example on how not to do things as it does
not work well according to Keith.

Michael points out that he, or his employer (NSI) do NOT OWN the urn.net domain
or any database of NSI attached to it.

Handle Presentation

Sam Sun from CNRI is given some time to present the Handle system; see
http://www.hanlde.net.  Handles look like they might make a fine URN
namespace.

Discussion does escalate into the usual discussion on the syntax
limitations of URN's imposed by the URI specification. Sam is referred
to the archive of the URN discussion list for previous iterations
of the syntax issues.  Our dear area director cuts this short and advises
those who have issue with the URI spec to discuss that in the appropriate
places; the URN work is to be done within the URI contraints.