Subject: Re: [urn] A first cut at the Draft Charter for the proposed URNbis WG

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 May 2010 16:22:55 -0600

Hi Alfred,

Here is some feedback on the proposed charter. My apologies for the delay.

In general, RFC 5434 will give you plenty of good ideas about
formulating a charter. It is especially important to clearly define the
problem statement.

On 4/27/10 11:05 AM, Alfred � wrote:
> Folks,
> Based on work done by Juha Hakala in February, I have updated
> and amended the Draft Charter and hereby bring it to the urn list
> for discussion.   Comments welcome!
> 
> Kind regards,
>   Alfred H�nes.
> 
> 
> ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
> 
> Uniform Resource Names, Revised (URNbis) -- Draft Proposed WG Charter
> ========================================
> 
> Last Modified:  2010-04-26 [AH]
> 
> Chair(s):
>   o   Juha Hakala  <[email-masked]>
>   o   N.N.

The chairs will be chosen by the Area Directors. I agree that Juha is a
good candidate, but please leave this blank for now.

> Applications Area Director(s):
>   o   Alexey Melnikov  <[email-masked]>
>   o   Peter Saint-Andre  <[email-masked]>
> 
> Applications Area Advisor:
>   o   Peter Saint-Andre  <[email-masked]>

We don't yet know if which AD will be the advisor, so please leave this
blank.

> Mailing Lists:
>   General Discussion: [email-masked]
>   To Subscribe: https://www.ietf.org/mailman/listinfo/urn
>   Archive: http://www.ietf.org/mail-archive/web/urn/current/maillist.html
> 
>   Related lists (used for IANA registration procedures (BCP 35/66):
>     [email-masked], [email-masked]
> 
> Additional information will be available at:
>   http://tools.ietf.org/wg/urnbis

Not yet assigned, so please leave this blank.

In fact you can delete everything up to this point because it's
administrivia. :)

> Description of Working Group:
> 
>   Uniform Resource Names (URNs) are persistent identifiers for
>   information resources.  

RFC 2141 says:

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers.

I think the "location-independent" part is important so people don't
think that URNs exist for the purpose of resolving a URN into a location
where the representation of a resource can be retrieved.

> The RFCs defining URNs and services based on
>   them were published 1997-2001.  Since then, the URN system has gained

Are URNs really a "system"?

>   popularity.  Among the more traditional parties with deep interest in
>   persistent identifiers and making heavy use of URNs are national
>   libraries; solely within this area, tens of millions of resources
>   have been assigned URNs; this enables efficient searching of and
>   persistent linking to these documents.
> 
>   This working group is chartered to revise the key RFCs describing the
>   URN system, including RFC 2141 (URN Syntax) and RFC 4306 (Namespace
>   Definition Mechanisms), 

I think we need to be very clear about what kind of revisions we're
talking about here.

> update important URN namespace specifications,

I think we'll want to list these separately and limit the scope of the
WG to only the listed namespace specifications (to be expanded only on
rechartering).

>   and to screen and update RFCs describing URN resolution principles
>   and practices.

Do we really want to take on URN resolution?

>   For RFC 2141, this revision will include in particular: an update of
>   the formal syntax specification in the light of the URI Standard
>   (STD 66, RFC 3986) using the ABNF from STD 68 (RFC 5234), a revision
>   of URN examples from imaginary ones into existing URNs in current
>   namespaces, providing a formal IANA registration for the 'urn' URI
>   scheme using the template from BCP 35 (RFC 4395), 

Do we have agreement that the URN space is founded in a URI scheme?

> and an update of
>   the section describing how URNs are resolved in the Internet.

By "section" do you mean RFCs 2169 and 2483?

>   RFC 4306 (BCP 66) needs a less pervasive update, mostly to align it
>   with the current IANA procedures and terminology as defined in BCP 26
>   (RFC 5226).
> 
>   Regarding URN Namespace specifications, the WG will focus on updates
>   for the definitions of URNs based on bibliographic identifier systems,
>   in particular RFC 3187 (URN Namespace for International Standard Book
>   Numbers) and RFC 3188 (URN Namespace for National Bibliography
>   Numbers).  In both cases, the respective identifier system and/or the
>   institutions and roles involved in their assignment and resolution
>   have evolved significantly since these RFCs have been published.
>   In particular, the URN:ISBN namespace needs to be extended according
>   to the revision of the international ISBN standard, and the usage of
>   the URN:NBNs has grown rapidly and there is a need to align the
>   namespace registration with experience and current practice.
>   In a second stage, RFC 3044 (URN Namespace for International Series
>   Standard Number) will be checked for the necessity of an update.

Those efforts seem worthwhile, although again we'll want to tightly
scope the work.

>   Thus, in support of the current international efforts to establish a
>   distributed, linked system of URN resolution systems for bibliographic
>   identifiers, the primary aim of the WG is an updated set of standards
>   documents, which is needed to assure uniformity and interoperability
>   of the URN resolution services.

Is this new work, or revision of existing work?

>   Alongside the modernization of these core RFCs for URNs and specific
>   URN namespaces, the working group will also consider a revision of
>   earlier RFCs related to the principles of URNs and URN resolution,
>   such as RFC 2483 (URI Resolution services necessary for URN
>   resolution), RFC 2276 (Architectural principles of Uniform Resource
>   Name Resolution), RFC 1737 (Functional requirements for Uniform
>   Resource Names) and RFC 2169 (A trivial convention for using HTTP in
>   URN resolution).  All these must be checked; if the document is still
>   deemed relevant, it will be modernized.

That sounds like a lot of work. Perhaps a phased approach will be needed?

>   The working group will also consider the possibility of publishing
>   Best Current Practices on how to resolve the URNs utilizing the
>   existing Internet protocols such as HTTP.  This BCP will be based on
>   the European URN resolution infrastructure under construction in the
>   project PersID.

Do we have references or I-Ds about that work? How can the URNbis WG (if
formed) collaborate with the PersID project?

>   Since the revised specifications will be based on existing production
>   systems and provide important guidelines for future implementers,
>   the WG aims at publishing the RFCs on the Standards Track and will try
>   to advance the core document at least to Draft Standard status as fast
>   as possible.

What is "the core document"? Do we think it will need to be cycled at
Proposed Standard? If so, let's clarify that. Pushing for Draft Standard
might be premature.

>   The WG can take on work to update other well-established URN namespace
>   definitions upon a case-by-case decision.

Perhaps text like this would be helpful:

   Although the group may provide advice regarding other URN namespaces,
   it will prioritize work on the above-mentioned namespaces first and
   will take on additional tasks as official milestones only after
   rechartering.

I think that if we don't have some text like that, the IESG will be
concerned about the open-ended nature of the charter.

> Input documents:
> 
>   RFC 2141
>   RFC 3406
> 
>   RFC 3187
>   RFC 3188
> 
>   RFC 2483
>   RFC 2276
>   RFC 1737
>   RFC 2169
> 
> Goals and Milestones (preliminary):
> 
>   Feb 2010   Initial WG formation as 'URN-R' (outside the IETF)
>   Mar 2010   WG work plan completed, brought to IETF APP Area
>   May 2010   first Internet-Drafts for most important core document
>              revisions
>   Jul 2010   Presentation of the group & early results at IETF 78 (BoF)
>   Aug 2010   Formal establishment of the IETF WG

Those might be helpful to you, but none of them belong in the milestones
for the WG since they would predate WG formation.

>   Dec 2010   WG Last Call on WG core document set
>   Feb 2011   core document set forwarded to IESG
>       2011   work on supporting documents (guidelines, URN resolution)
>       2012   implementation report for promoting 2141bis to Draft Std.

We don't need to define detailed milestones at this time -- IMHO it is
more important to come to agreement on the problem statement and
deliverables. The milestones will flow from that.

> Internet-Drafts:
> 
>   draft-ah-rfc2141bis-urn          (-00: March 2010)
>   draft-hakala-rfc3187bis-isbn-urn (-00: March 2010)
>   draft-hakala-rfc3188bis-nbn-urn  (-00 due for week 18/2010)
> 
> Request For Comments:
> 
>   none so far

Naturally. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 24 May 2010 23:45:24 +0200 (MESZ)

Peter,
many thanks for your support and the detailed comments.
Juha Hakala already has responded to many details.  Below are my
notes (inline), after a revised draft charter has been produced.

> Here is some feedback on the proposed charter. My apologies for the

We have discussed your comments (and other comments received)
and a second cut on the draft charter has just been posted.

> formulating a charter. It is especially important to clearly define
> the problem statement.

Of course, it already had been taken roughly in account earlier this
year when the procees to re-target the PersID / URN-R effort to the IETF
had been started.

>
> On 4/27/10 11:05 AM, Alfred Hönes wrote:
>> Folks,
>> ...

Done.

> We don't yet know if which AD will be the advisor, so please leave this

Done.

> Not yet assigned, so please leave this blank.

Put in placeholder, but left list information.

> In fact you can delete everything up to this point because it's

There's a lot of value in havint most of the information,
in particular for newcomers to the IETF.  And this way, the
submitted text hopefully better resembles current practice
of WG charters.

> where the representation of a resource can be retrieved.

This quotation from RFC 2141 now is literally included in the
draft charter.

> Are URNs really a "system"?

Anything structured somehow and composed of interacting components
is a system.
URNs are part of the structured URI framework; and for URNs, there are
the original namespaces underlying the URN NIDs and the related actors
and frequently computing systems for the assignment of identifiers and
achieving their uniqueness and persistence; so there is a lot of
structure and components.

>
>>   popularity.  Among the more traditional parties with deep interest
>>   in persistent identifiers and making heavy use of URNs are national
>>   This working group is chartered to revise the key RFCs describing
>>   the URN system, including RFC 2141 (URN Syntax) and RFC 4306
>>   (Namespace Definition Mechanisms),
>

The 'second cut' of the draft charter is significantly restructured
and amended and it elaborates at a much more detailed level on the
problem statement and the distinct tasks the WG is going to work on --
both at a high, summary level and down to the various existing RFCs,
grouped in core URN documents, URN namespace documents for
bibliographic identifiers, URN resolution, and "other".

> WG to only the listed namespace specifications (to be expanded only on

Essentially done, as already sketched above.

> Do we really want to take on URN resolution?

Yes.  URNs would be an academic exercise without resolution.
The current namespace registration template requests detailed per-NID
considerations, and the needs of the implementation and deployment of
an interlinked resolution system for URNs based on bibliographic
identifiers is the basic driving force behind this effort.
The group shall review existing RFCs specifically dedicated to URN
resolution in general, determine the degree of their ongoing relevance,
and decide which documents deserve updates.

> Do we have agreement that the URN space is founded in a URI scheme?

For the stakeholders of the BOF proposal, this has never been in doubt.
The lack of a formal URI scheme specification so far and the resulting
need for such is now spelled out even more clearly in the second cut
at the draft URNbis charter.

> By "section" do you mean RFCs 2169 and 2483?

No, this statement was in context of RFC 2141[bis], and in particular
RFC 3406[bis].

>
>>   RFC 3406 (BCP 66) needs a less pervasive update, mostly to align it

Please look at the revised draft charter.
We hope the restructured and amended text addresses thes concerns.

> Is this new work, or revision of existing work?

The work done in PersID is new, but based on seminal national work.
RFC 2141 is a Proposed Standard and RFC 3406 is a BCP, but RFC 2141
in its present form, has no chance of promotion on the Standards Track
because of their reliance on Obsoleted documents and the lack of
compatibility with the terminologu and formal description in present
Full Standards.  The URN namespace documents related to bibliographic
identifier systems presently are only Informational RFCs.
The National Libraries want to base their work on standards.

Therefore, the ultimate objective is to get PS for the revisions
of the latter documents immediately, and to progress a RFC 2141bis
document on the Internet Standards maturity latter as fast as
possible, following the time scale envisioned in BCP 09, and to
publish a revised BCP 66 compatible with current IANA guidelines.

> That sounds like a lot of work. Perhaps a phased approach will be

Indeed.
The order of mention in the 'first cut' was intended to reflect that
phased approach.  This is spelled out more explicitely in the revised
draft charter.

> formed) collaborate with the PersID project?

We expect to have at least one representative of most organizations
participating in PersID will actively contribute to the WG.  We also
expect that the ISO registration authorities for ISBN and ISSN as well
as representatives from the Library of Congress (which is managing the
assignment of non-ISO 3166 branches for NBNs) will review the documents
produced by the WG.

> Proposed Standard? If so, let's clarify that. Pushing for Draft Standard

The "core URN specification" (under revision by the proposed WG)
is comprised of RFCs 2141 and 3406.  We do not want to exclude
prematurely the need to perfome another iteration on 2141bis for DS,
but it is our hope that an implementation report for 2141bis might
suffice for promotion to DS after the period specified by BCP 09.

It would doubtlessly be very much appreciated if it became viable
to also promote the other core WG documents (revised URN namespace
definition documents for bibliographic identifieds) on the STDs Track,
but past experience of the inertia in the IETF and IESG let me
personally doubt this can be achieved (help proof me the contrary!).

>
>>   The WG can take on work to update other well-established URN
>>   namespace definitions upon a case-by-case decision.
>

The revised draft charter text puts more emphasis on "offering advice",
i.e. offering a service to URN namespace registrants (like e.g. DHCWG
or DNSEXT do for DHCP/DNS related work in other WGs or by Individual
submisisons), and it spells out the need to update the charter if
the WG wants to undertake additional concrete document development
in that area.

> for the WG since they would predate WG formation.

Was there for information purposes; dropped now.

> deliverables. The milestones will flow from that.

Left these four lines in the new version to outline the general idea
of the schedule we have in mind.

>>   draft-hakala-rfc3188bis-nbn-urn  (-00 due for week 18/2010)

The latter has been submitted now (last week), thus updated this item.

> Peter

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| 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]                     |
+------------------------+--------------------------------------------+