Subject: Re: [urn] Focus of the discussion

From: Alfred Hönes <[email-masked]>
Date: Thu, 6 May 2010 20:20:06 +0200 (MESZ)

Keith,
thanks again for your feedback.

> I am strongly of the opinion that the WG MUST be constrained from
> attempting to change the intent of the original URN specifications; or
> for that matter the specifications themselves except as necessary to
> clarify, correct errata, and reconcile apparent differences with other
> standards.

Are there indications in the first draft charter or in the initial
2141bis draft that have lead you to the conclusion somebody seriously
wanted to try to change URN fundamentals?
If you feel so, please tell us the details so that these can be adjusted.

> History suggests that discussions about naming are very contentious.
> They seem to bring people out of the woodwork who want this kind of name
> to serve whatever purpose they hope to serve, whether or not that is the
> intent behind that kind of name.  We had that problem with the original
> URN discussions.  We also had that problem with discussions around
> "human friendly names" and similar ideas.  To some degree we've even had
> that problems with discussions of URLs, and there is a long history of
> contention on use of DNS names.

The origin of this effort stems from custodians of cultural legacy, most
of them working directly for national libraries, and a few supporting
folks, including me -- in a role you might circumscribe as an inofficial
liaison to the IETF.  Some people contemporarily regard such folks as
overly conservative; but at least, they are not renowned as followers
of apparently short-lived hypes.
So far, I did not see any indication in the messages from PersID
that a fundamental shift in paradigm would even be considered.

The goal clearly is a revised set of documents compatible with
existing standards and matching the requirements of an evolving
distributed, international, URN resolution system for unambiguous
specifications, lying the foundation for interoperable implementations
of resolution services, and for future improved namespace definitions
that support these goals.
I hoped that would be clear from the submitted text.

>
> The battle for control of URNs needs to not be revisited.   Those
> decisions have already been made, and they were hard fought.  People who
> want URNs to be something significantly different than they were
> originally specified to be need to go elsewhere, or start from scratch
> to convince the community that a new kind of name is needed.  This is
> especially important to preserve the persistence qualities of URNs.

In a recent contribution to this list, it has been clarified that,
basically, URNs are the URIs of the 'urn' URI scheme -- nothing more
and nothing less -- and that each URI scheme has its specific set of
rules beyond the general rules in the URI standard.
The fact that this needed to be stated seems to be a dedicated,
a-posteriori justification for having (for the first time!) a formal
specification for the 'urn' URI scheme in the 2141bis draft, as you
can find instantiated in the -00 version.
Of course, the details of the draft are subject to WG discussion,
(but comments are welcome as well before WG formation); however,
the primary goal now is discussing, and eventually arriving at
consensus for, a WG charter.

>
> This needs to be made very clear in the group's charter, and right now
> there's not even a hint of that.
>
> Keith

Again: Do you see a hint to the contrary?  Where?

The proposed draft charter lists major goals.
Changing more fundamental things is not even mentioned there.
IMO, it is implied by the intent and practice of WG charters that
details are to be worked out in the WG, but that the WG is not
endowed to leave the grounds of what is written in the charter.

Where do you derive from the idea that this text would task the
proposed WG with tackling such work?  We are used to specify in the
charter the working plan of a WG, and not what the WG is _not_
planning -- otherwise we would quickly arrive at unreadable charters
of unbounded size.  When a WG wants to go beyond its charter, the
rules require re-chartering.  We currently are defining the tasks of
the WG; the first cut has been posted, and it does specify detailed
goals.

So once again (and this is directed to all readers of this list!),
please quote text parts you do not concur with or that you would like
to be amended, and supply text proposals for additions and/or changes,
if you believe they should be applied.
On the other hand, please feel free to state explicit support of the
current text or parts of it.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Keith Moore <[email-masked]>
Date: Thu, 06 May 2010 14:35:38 -0400

Alfred,

You are missing my point.  It doesn't matter that the charter doesn't
say anything about changing URN fundamentals.  Nor does it matter that
the people who are pushing for this WG aren't interested in changing URN
fundamentals.  Once an IETF working group is formed, anyone can
participate in it, and the chair is bound to honor group consensus. 
Unless the charter expressly forbids changing URN fundamentals, it's
going to be impossible to keep the discussion on target for the group's
intended scope.  (Even with a "big stick" in the charter, it's likely to
be difficult.) 

Furthermore, IESG has sometimes had difficulty pushing back on groups
that exceed their mandate, unless the output of the group is clearly
outside of the bounds of the charter.

The best time to fight scope creep is before the group is actually
chartered.

Keith

---

From: Juha Hakala <[email-masked]>
Date: Mon, 17 May 2010 09:23:33 +0300

Hello all,

Within the PersID project, nobody has an intention to change URN 
fundamentals. Therefore it should be easy to add a statement in the 
charter that no such changes will be done, in addition to formulating in 
more details the work that will actually be done.

One of our aims is to strengthen the status of URN-related RFCs. The 
current RFCs are informational or experimental, and as such they are not 
exactly carved in stone from IETF's point of view. However, they form a 
very useful basis for our work (and some of the RFCs took a lot of work 
to finish).

 From my point of view, the changes needed can be grouped in two 
categories: modernisation of namespace registrations and the check & 
strengthening of the base URN standards.

1. Namespaces

While most URN namespace registrations are no doubt OK, there are at 
least three that should be revised:

A. ISBN (International Standard Book Number): A new version of the ISBN 
standard was approved in 2007. Changes to the standard were non-trivial, 
and a thorough revision of RFC 3187 was needed. The version 00 of the 
RFC 3187bis has already been released. The staff of the ISBN 
International Centre has been informed about the revision and they have 
approved it.

B. ISSN (International Standard Serial Name) underwent a thorough 
revision a few years ago. The new version of the standard (2007) 
introduces ISSN-L (linking ISSN) which makes it necessary to rethink the 
way in which URN:ISSNs are resolved and update RFC 3044 accordingly. It 
is our intention to do this work in co-operation with the ISSN 
International Centre.

C. NBN (National Bibliography Number) namespace was registered (as RFC 
3188) before the national libraries or other users were actually using 
URN system. Now that millions of URN:NBNs have been assigned mainly to 
resources the national libraries have stored in their digital archives, 
it is time to check that the RFC accurately catches the ways in which 
URN:NBNs are assigned and resolved.

Please note that each namespace (identifier system) has its own rules as 
regards the nature of objects that can be identified. This rules may be 
quite rigid or very liberal. While the original scope of the URN 
developers was networked digital objects, there are several namespaces - 
including ISBN and ISSN - that cover a lot of digital objects, but also 
a lot of non-digital objects, in which case the URN can resolve to for 
instance the bibliographical description of the resource, and/or a 
service via which the resource can be ordered via Inter-library loan or 
digitized.

2. Check and strengthening of URN base standards

I am not a technical expert; my past & current practical work with URNs 
is related to namespace registration requests. (As an aside, given my 
appointment as the IETF - ISO TC 46 liaison officer it is possible that 
I'll be involved with more namespace registrations for ISO identifiers 
in the future.) With this caveat, my understanding of the practical 
implications of the working group's efforts is that they do not 
invalidate any past URN assigned, but allow more diversity in the future.

For example, from the character set point of view RFC 2141bis is both 
more liberal and more solid than the current RFC 2141, since the former 
builds upon RFC 3986, the latter on URL specification which was still 
only "work in progress". As an aside, in Finland there was an attempt to 
establish RFC 2141 as the national standard back in 2003-2004, but this 
effort failed due to the (according the external expert we used) 
outdated character set RFC 2141 allows in NID & NSS. With RFC 2141bis 
there should not be such a problem.

One issue that may be discussed in this list and elsewhere is the role & 
technical implementation of (DNS-based) resolver discovery services. The 
fact that no widely implemented RDS exist has not been missed the 
proponents of other persistent identifier systems (see 
http://www.doi.org/factsheets/DOIIdentifierSpecs.html). The relevant 
critical portion of the text was in 2010-05-17:

> URN architecture assumes a DNS-based Resolution Discovery Service (RDS) to find the service appropriate to the given URN scheme. However no such widely deployed RDS schemes currently exist: browsers cannot action URN strings without some additional programming in the form of a "plug-in". These carry no guarantee of ready interoperability with other deployments, which may require a different plug-in for each implementation and may use conflicting data approaches.

I have asked Norman Paskin to update this text with a short explanation 
(supplied by me) how URNs currently work in practice, in order to avoid 
an impression that there is a fundamental technical limitation in how 
the URNs work. I have no problems leaving all RDS-related RFCs in place, 
but it might be a good idea to describe somewhere how URNs are expressed 
as HTTP URIs and resolved, and the ways in which the project PersID will 
make the URN resolvers of the partners aware of each other & enable 
resolution data (URN - URL mappings) exchange between them.

Best regards,

Juha

Keith Moore wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Director of IT Development

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678