Subject: [urn] DRAFT minutes of URNBIS BOF at IETF 78 -- please check!

From: Alfred Hönes <[email-masked]>
Date: Fri, 6 Aug 2010 14:01:57 +0200 (MESZ)

All,
as promised in the URNBIS BOF session, I have produced (draft) minutes
of the BOF, based on the Jabber log.  (Kudos to Pete Resnick!)

Attached is the current draft version of the minutes.
I have tried to join some discussion threads for better readability,
although they had been spread out by delays induced by jabber and
queueing on the mic.

Since I again have been distracted a lot, this has taken longer than
I had hoped, and some details might be missing or misrepresented.
So please check thoroughly if you have participated in the session
(in person or remote)!

Please send your comments/corrections/additions within the next 10 days
to the URN list or in personal communication.
I'll then be back online, sum up, and update the minutes before
submission to the IETF 78 proceedings.

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

Minutes of the URNBIS BOF, IETF 78
==================================

These minutes are based on the final agenda of the BOF available at:
   http://www.ietf.org/proceedings/78/agenda/urnbis.txt
and the jabber log of the BOF available at:
   http://www.IETF.ORG/jabber/logs/urnbis/2010-07-27.txt

BOF CHAIRS

   John C. Klensin <john-ietf at jck.com>    ( below: "[JCK]" )
   Alfred Hönes <ah at TR-Sys.de>            ( below: "[AH]" )

DATE/TIME/VENUE:

   27 July, Tuesday, 0900 - 1130 (UTC+0200), Room 0.8 Rome
   used time:        0909 - 1106 (UTC+0200)

GOAL:  to charter a new WG

RECOMMENDED READING FOR ATTENDEES/PARTICIPANTS:
      The "Introduction" sections (at least!) of the following
      I-Ds (also listed in the draft charter):

  draft-ah-rfc2141bis-urn          (-00: submitted March 2010,
                                    -02 posted on May 31 2010)
  draft-hakala-rfc3187bis-isbn-urn (-00: submitted March 2010)
  draft-hakala-rfc3188bis-nbn-urn  (-00: submitted May 2010)

      Preliminary draft charter:
  http://www.ietf.org/mail-archive/web/urn/current/msg01431.html

AGENDA:

1. Administrivia (Chairs)

   - Note takers, Jabber scribes

     Pete Resnick ([PR] below) volunteered as jabber scribe. Thanks!
     BOF co-chair [AH] will produce minutes based on jabber log.

   - "Note Well"

     In particular IETF first time participants are reminded of the
     "Note Well"; blue sheets circulated in advance.

   - Agenda bashing

     [JCK]: The agenda had been sketched for a 1:30h time slot, but
     due to IETF agenda changes we have a 2:30h slot; therefore the
     presentations will be given in more detail than planned.

2. Presentations

   All given by Juha Hakala  (below: [JH])

2.1. The need for up-to-date URN Standard documents

       -  where do URNs come from, why do we need them
       -  URN work in the IETF, from mid 1970's until today
       -  what happened on a wider scale, regarding URIs
       -  mismatches and inconsistencies, lack of maturity

   Slides:  ("The need for up-to-date URN Standard documents")
      http://www.ietf.org/proceedings/78/slides/urnbis-1.pdf

   {slide #2, "URN usage", solicits discussion}

   National libraries are using URN widespread and need changes to
   get a solid and recognized base for their work (but not every
   national library is using URNs).
   They need to keep digitized material for ~500yrs.
   Still co-op between the implementers lacking -- "wheel re-invention"
   among libraries, but we do therefore have multiple implementations.

   Peter Saint-Andre (below: [PSA]): Question:
      Other than libraries, other usages (xml namespaces, etc.)?
      Have you done survey outside of the library community?
   [JH]: Only cursory. No one has checked for dead namespaces,
         but several being used.
         40 formal URN namespaces registered; more in the pipeline.
   [AH]: Library has the widest use. Recently namespaces assigned
         to SIM cards, but not expected for wide use yet.
   [PSA]: Want to make sure we're gathering the right requirements
         and not skewing conversation towards libraries.
   [AH]: Yes.
   Glenn Kowack (TRSE): For discussion: want to know
         how to decommission namespaces that are dead.
   [JH]: Need to have BCP or the like to describe some of these operations.
         In general, decommissioning contradicts persistence.
         The SIM card example is an interesting nice case.
         SIM card may go away, but logs/recordings of phone calls
         might be archived and hence will be longer lived.
   Heeyoung Jung: Question for representation of digital contents, I think.
   [JH]: Archived telephone calls might be associated with the SIM card
         URNs for purpose of identification in archives.
         That community can approach the urn folks.
         But no reason urn can't be used.
         A detailed example (from Finnish National Library):
         Journal issues get urns. Each article inside gets a urn.
         Each image inside that gets a urn.
         So, if there is an identifier system, then not a problem.
   [JCK]: Short answer: Yes.
   [JCK]: We've been directed to not start with new schemes,
         but in principle it is not a problem.
   [JH]: Caveat that there must be an identifier system in place.

   {slide #2, "Issues"}

   Clarification / correction:
     Key documents (RFC 2141 and 2483) not on Standards Track or have
     not been advanced (RFC 2141 is Proposed Std, RFC 3406 is BCP),
     and they now are out of date and  not in sync with current Full
     Standards.  RFC 2141 also has inconsistencies between formal
     syntax and prose description, and apparent error in BNF.

   Must also figure out what to do with namespace registrations.

   RFC 2483 does not take into account increased complexity of
   library systems and new requirements for services based on URNs.

   {slide #3, "URNBIS WG"}

   Need to do a facelift (revising key documents as necessary)
   Already attempted RFC 2141 and 3187/3188 rewrite.
   {[AH]: see list of recommended readings in agenda.}

   Best way is to establish new WG.

2.2. One URN "customer":
       -  National library use of URNs
       -  a short presentation of project PersID

   Slides:  ("PersID -- National Libraries and URNs")
      http://www.ietf.org/proceedings/78/slides/urnbis-2.pdf

   When the slides talk about "national libraries" for short, this also
   includes key research and government organizations tasked to archive
   and preserve (digital) content.

   Base requirements:
   Must identify every digital document (100's of millions)
   We have ISBN and ISSN, also NBN (national bibliographic number) -- as
   an escape mechanism for where no other ID (like ISBN/ISSN) is assigned
   You don't give NBN to things you're not going to keep for a long time.

   [JCK]: Two copies of the same object, different libraries, get
         different NBNs?
   [JH]: That can happen. Still leaves questions of when two documents
         are "the same".  Use of identifier is as unique (persistent)
         access keys.
   [JCK]: Cannot touch question of "what constitutes 'same'" - neither
         BOF nor WG are going to solve it.

   ISBN/ISSN is not "actionable in the web", and not all NBNs are
   globally unique (but URN:NBNs are).
   URNs and other persistent IDs get you a persistent link.
   Examples of usages today: embedding URNs into 'http' URIs.
   Long term, the URN: should be actionable by itself.
   URNs give you a single point of control for all of the items.

   Julian Reschke ([JR]) points out that it is possible to use HTTP
         proxies as a way to resolve such URNs, and code exists in the
         wild to do that.
         Memento discussion in httpbis might be a connection.
   [JH]: This is complementary work.
   [JCK]: The other reason for this abstraction - this depends on http,
         and HTTP could always go away.  URNs are protocol-independent.

   {slide #3: "URN users"}

   Ex: Aim at national library of Norway is to digitize *everything*
   (petabytes) in their collection.
   National libraries are very important because of the persistency
   of collections. Important for legal reasons.
   There is a need for a solution that will *not* be commercialized
   (i.e., be subject to patents and trademarks)

   {slide #4: "PersID project, www.persid.org"}

   [PSA] notes: slides are on global resolver service infrastructure
   [JH]: Global is eventual goal.  Starting with European NBN space.
     Want to establish policy to maintain this on international scale.

   {skipping to slide #6, "Why URN-NBN?"}

   URNs already widely used. Wanted to avoid re-inventing the wheel.
   NBNs are open and flexible: National library can give permission
   to other folks for use.
   Other users can adapt the system for local requirements.
   Product of this effort will be open source.

   {slide #7 gives List of participants}

2.3. Work items -- problem statement and scope of work

   Slides: (Work items: problem statement and goal of work")
      http://www.ietf.org/proceedings/78/slides/urnbis-0.pdf

     a) general goals and non-goals

        WG should evaluate existing RFCs, checking for new RFCs that
        are relevant.

        No changes of the basis of the URN system,
        nothing that will make existing implementations (URN namespaces
        and related resolution systems) non-compliant.

        Elaborations regarding URN Services:
          Should look to see if current specs match current use, e.g.,
          existing services doc has a service to find all locations
          where a resource is available, But this is based on a very
          simple model. Requirements are moving towards a "description
          of work" and "multiple manifestations" of the work.
          Each version (.doc format, xml format) gets their own URN.
          Links between these should be available in the resolver system.
          So, we need a service to find all of the other URNs related
          to a work.  Such a service not yet described now.

     Leslie Daigle [LD] (relayed from jabber):  I can't quite remember
       which BoF that was -- some of this work was explored in attempts
       at follow-on work to URNs but the APP Area/IETF didn't have the
       energy/interest.  The point remains the same -- don't necessarily
       lump that *into* URNs.
     [JCK]: Even a URN-to-URN service is a resolution service, which
       we'll talk about later in the BOF.  But for now, we hope to avoid
       touching those, at least until base work is done.

     b) Core URN documents
        -  formal specification / revision of RFC 2141

           We already have an I-D to bring this in compliance with 3986
           and provide a formal registration of the 'urn' URI scheme.
           An open question is whether to deal with fragments and queries.
           There already are in the wild some (sporadic) URNs containing
           fragment parts.  Idea is to admit these in the syntax, but
           mention caveats; these options would need to be adopted
           per URN namespace, by the namespace defining documents; this
           way, parsers could be made uniform, to cover the general case.

        -  namespace registration / revision of RFC 3406

           Most likely adaptation to current IANA procedures BCP needed,
           but no change in actual namespace registration procedures
           envisioned.

           Regarding URN Services document (RFC 2483) {see above}:

      [JCK]: Leslie, I think there is some chance that there is energy
           now (just a hypothesis), but that makes it even more important
           to try to concentrate on the feasible and navigate around,
           rather than through the ratholes.
      [LD] via jabber: JCK -- would certainly be cool if there is energy
           now.  Wish our records of the past were more complete, so we
           could pick up the threads.

     c) URN namespaces for bibliograpic identifier systems
        - ISBN URNs / revision of RFC 3187
        - NBN URNs  / revision of RFC 3188
        - ISSN URNs  / revision of RFC 3044

        The ISBN and ISSN standards were recently updated.
        So RFCs 3187 and 3144 need mods to deal with the extensions
        in the underlying (ISO standard) namespaces.
        ISSN and Linking ISSN might need two different namespaces.

        RFC 3188 needs to be updated to reflect 10 years experience.
        It had been written as kinda academic exercise when no NBN URNs
        existed yet; now there are 100s of millions and widespread
        experience.  The present draft tries to take that into account.

     d) Review of other URN namespaces

        - review existing namespace registration RFCs
          {with respect to RFC 3986 etc. and work in b) above}

          We don't know what needs to be done with other namespaces.
          Some of them might be fine.  Others might need updates to
          catch up / better align with the revised base documents
          and/or to allow advancing on the Standards Track.

        - point original registrants to issues / needs for update

        - take on work on revisions in WG (only upon rechartering)

        - serve as a voluntary forum of competence in support of
          new URN namespace registrants and IANA urn-nid expert

        - regarding URN Resolution   {no slides}

          In order to keep the scope of the proposed WG plausible,
          a review and revision or addition of URN Resolution
          protocols will not be part of an initial proposed charter.
          Nonetheless, if time permits, a brief overview of principles,
          systems, issues and experience from other work will be
          included for context:

          - review existing RFCs for relevance and need for update
          - discuss whether new URN resolution framework document is
            needed
          - Possible future BCP on use of HTTP for URN resolution
          - based on experience in Project PersID

     e) staging of work, possible milestones, advancing of STD maturity

        2141, 3044, 3187 and 3188 revisions (underway) are top priority.
        Then look at RFCs which don't reflect existing implementations
        (e.g. 2483 never describes the syntax and semantics of the
        metadata)
        Then, review other URN related RFCs (e.g., resolution service).

3. Open Q&A for presentations  (Chairs)

     Question: Evaluation of other persistent ID systems?

     [JH]: Might want to take this on as a BCP kind of task.
           Don't want current infrastructures to disappear.
     [JCK]: Sequencing is important. Can't do all this work at once.
         Main thing to exclude from initial work is anything to do
         with resolution.  Proposal is to look at the documents and
         examples and then come back.
     [JR]: Seems like obvious work to do.

     [JR]: Pointer to HTTP wrt to non-HTTP URIs in HTTP requests:
           http://tools.ietf.org/wg/httpbis/trac/ticket/218

     [JR]: Need to get the charter done.

4. Discussion of Draft Charter and Work Plan (Chairs/ADs)

     [PSA]: Question about implementation/deployment experience:
         How do we get folks to contribute?

     [JCK]: Important piece is communities who are not libraries per se.

     [PSA]: Not even clear that library folks are well represented.
         Are they?
         Also good to reach out to the 40-odd registrants of namespaces.

     [JH]: There are a number of implementations, but they're very
         simple.  There's a lack of sophistication in user services.
         Question is how to get towards full implementation.
         Re: Communities, I have connections with libraries.
         Hope we can get the other registrants involved.
         Libraries might not have same requirements.

     [AH]: Who has dealt with other URN namespaces? (3 hands go up)

     [JCK]: Contact information in the registry, so we can go find
         those folks.

     [JCK]: Who's looked at the charter?
       (A handful of hands)

     [PSA]: That's the draft charter:
         http://www.ietf.org/mail-archive/web/urn/current/msg01431.html

     [JCK]: Are there others who want to work on this?
       (2 hands)

     [AH]: There are folks who are interested but not here.

     [LD] (from jabber): General comment:
          The draft charter is very national-library focused.
          URNs are actually more broad than that.
          Anything that gets chartered to further URNs must
          acknowledge that there is more than the library focus.

     [JCK]: What else?

     [PSA]: Resolution might need to be off the initial charter.
     [JCK]: Yes, broad agreement in the room on that.

     [PSA]: Concern about lack of people. Who will review?
       (10 hands)
     [PSA]: That's better. We need to "socialize" this.
         Get the word out, etc.
     [LD] via jabber: If there is general energy here to pick up
         the work, *that* would be worth socializing.
     [JR]: Updating the base URN spec is important and will get review.
         People *are* confused about the relation between URN and URI,
         and syntactical details such as fragment identifiers.

     Maurizio Lunghi (Italian National Library, Firenze):
         Trying to do this for different user communities.
         We are working on distributed architecture (on resolution,
         on collections, etc.). Setting up a national registry.
         So, this is to put together different user communities.
         ISBN just about books, but NBN are for different types of content.

     [JCK]: This is going to be for *persistent* IDs.

     [JH]: Need RFCs to reflect widespread implementation.  We are
         requiring URNs for long-term things. This is viable to do.

     Martin Dürst [MD] from jabber:
         To [JH]: "requiring URNs for long-term things"?
         Does this mean "if it's long-term, it must be an URN"?
         Or "if it's an URN, it must be long-term"?  It reads like
         the former, but I think that would clearly be going too far.
     [AH] Yes -- in general, the latter.
     [JH]: To Martin: This is a political thing in Finland.
        For all things that are persistent, they must have a URN.
     [MD] (via jabber): To [JH]: Is that for the Finnish government,
        or for everybody in Finland, even in private dealings?
     [JH]: To Martin: No, government and public sector.

     [JCK]: Question: Do we need to set up a liaison with TC46?
     [JH]: There was agreement in ISO generally that standardizing URNs
         was do-able.
     [JCK]: Slightly different Question: Are there organizations
         in the TC46 community that a liaison would help bring in?
     [JH]: TC46 folks are more involved in DOI (handles).
         That might slant the discussion.
     [PSA]: Digital Object Identifiers <http://www.doi.org/>

     [JR]: But any URN can be made a URL by implementing a resolver.

     [JCK]: If they are persistent, they must be of the objects (URN),
        not their locations (URLs).

     [JcK]: TC46 is an ISO technical committee.
        Main interest is communications in the documentary community.
        We can (a) ignore TC46, (b) use current liaison and bring
        new documents to them to have ISO endorse them, or
        (c) go to them and say, "we're working on this and want a
        liaison for the work."
        The third is good because we might get more involvement.
        However, they move "slowly", so they could hold us up.
     [AH]: We should invite individuals to contribute, not the TC.

     [JR]: Is the plan to bring the base URN spec to draft standard?
     [AH]: Depends on changes to standards process (cf. Wed. Plenary).
     [JR]: 2141 is on standards track.
     [AH]: But the rest need to get on the standards track.
     [JCK]: DS is a possibility, but not a target.

     [JCK]: Charter will go to the mailing list soon.

5. Conclusions and Next Steps  (Chairs/ADs)

     [AH]: Question to AD(s) What's your impression, what next?

     [PSA]: Let's figure out the running code and get things into
         the base spec. Charter discussion to the mailing list.
         Will be discussed by ADs, but overall, encouraging.

---

From: Juha Hakala <[email-masked]>
Date: Mon, 16 Aug 2010 13:21:18 +0300

Hello,

These draft minutes are both complete and correct description of what 
happened during the BOF. There was just one typo (3144 instead of 3044) 
that should be corrected; otherwise the draft looks fine to me.

Alfred, thank you for preparing this document.

Best regards,

Juha

Alfred � wrote:
>   Alfred H�nes.
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Aug 2010 19:40:41 -0400

Hi.

The preliminary minutes (a slightly updated and reformatted
version of the ones discussed a week ago) have now been posted
at http://www.ietf.org/proceedings/78/minutes/urnbis.txt

If anyone has corrections or comments they can, if necessary, be
incorporated until mid-September.

regards,
   john