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 ( below: "[JCK]" ) Alfred Hönes ( 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 and closely-related 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 making widespread use of URNs and need changes to get a solid and recognized base for their work (of course not every national library is using URNs). They need to keep digitized material for ~500yrs. Full cooperation between the implementers and libraries is lacking -- "wheel re-invention" -- 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]: Libraries have the widest use. Recently namespaces have been assigned to SIM cards, but not expected to see 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 article 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). They now are out of date and not in sync with current Full Standards, notably RFC 3986. RFC 2141 also has inconsistencies between its formal syntax and prose description, and an 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 example 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, trademarks, and/or per-resource fees) {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 3044 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 kind og sn 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 (Fondazione Rinascimento Digitale): 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 [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.