Tools-Team H. Levkowetz Internet-Draft June 11, 2006 Expires: December 13, 2006 Unique IETF Document and Information Tags draft-ietf-tools-document-tags-00.b Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 13, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The IETF currently names some of its working documents (drafts) and final documents (RFCs) using unique tags. These tags constitute a means of identifying an IETF document and its precise content uniquely, not only at a certain time, but also over time. This document proposes to extend this system, so it is applied to more types of IETF documents; in particular to agendas, charters, minutes, mailing-list messages and reviews; but also to other document types. Levkowetz Expires December 13, 2006 [Page 1] Internet-Draft IETF Document Tags June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tag design . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. New document types . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Agendas . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Minutes . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Charters . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Discusses . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. List messages . . . . . . . . . . . . . . . . . . . . . 7 3.6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Reviews . . . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Operational Notes . . . . . . . . . . . . . . . . . . . 8 3.9. Wiki pages . . . . . . . . . . . . . . . . . . . . . . . 8 4. Extension of the 'ietf' URN namespace . . . . . . . . . . . . 9 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Levkowetz Expires December 13, 2006 [Page 2] Internet-Draft IETF Document Tags June 2006 1. Introduction The practice of having unique tags for the documents which are handled by the IETF has proven useful over time. When referring to a certain internet-draft by its tag, which indicates document type, name, and revision, the document and its content is uniquely identified, and can be referred to and discussed with the valid assumption that anybody interested in the document can retrieve it from a local store, or from somewhere on the internet. Many other documents (in a wide sense) that are used or referred to in daily IETF work do not have such unique tags, but can only be referred to by URLs, and sometimes not even by that. Now, a URL as a document identifier is extremely useful in the context of retrieving a document if you have internet access, but it does not guarantee immutability of content or ability to refer to a document irrespective of its location. This document proposes to establish a set of document tags for a number of document types (in a wide sense) which do not today have any unique tags associated with them. 2. Tag design The power of IETF document tags to uniquely identify document content rests on three basic premises: 1. The document tag uniquely identifies the type of document: a tag starting with the string 'draft-' identifies an internet-draft, while a tag starting with the string 'RFC' or 'rfc' identifies a published IETF RFC. This makes the namespaces of the different document types non- overlapping, thus guaranteeing that tag uniqueness within a document type guarantees tag uniqueness over all IETF documents. 2. The document tag (excluding revision number) is unique to a given IETF document type: no other document of that type will ever be given the same tag as a previous document. For this to hold, some mechanism to ensure the uniqueness is needed; one way is to verify uniqueness at the time of submission of the document to a document repository. This provides tag uniqueness within a document type. 3. Once a document is made public, its content is never changed. New revisions of a draft are given a new unique tag by incrementing the revision number part of the tag. Revisions of RFCs are issued a completely new RFC number. Levkowetz Expires December 13, 2006 [Page 3] Internet-Draft IETF Document Tags June 2006 This guarantees that a certain document content is uniquely identified by its document tag, irrespective of the date and time at which it is looked up. In creating new document tags, we should take care to ensure that also the new tags will have the same qualities as the current tags, as listed above. This requires both that the tag format be appropriately designed, and that appropriate mechanisms for ensuring uniqueness of assigned tags are provided, as well as providing storage mechanisms which make it possible to retrieve a document by means of its unique tag. In some cases, the relevant documents are already today stored so that they can be uniquely retrieved by performing some (possibly obscure) resolution algorithm, followed by a HTTP or FTP request to the appropriate URL. In other cases, new storage and / or procedures are required. Charters, for instance, are not readily available other than in the 'current' revision; and reviews are not available from any repository at all. 3. New document types This section describes new tag types for a number of existing document types. Document types is here meant in a wide sense, covering also for instance IETF mailing list messages and IESG discusses. The document types covered are: * Agendas * Minutes * Charters * IESG Discusses and Comments * Operational Notes * List Messages * Reviews * Issues * Wiki Pages In general, all the proposed new tag types start with a unique text string followed by a dash; this is the same concept used by internet- Levkowetz Expires December 13, 2006 [Page 4] Internet-Draft IETF Document Tags June 2006 draft tags which uses the prefix 'draft-'. Below you'll find a table giving examples of the proposed tag formats. The examples assume a working group called xxwg, a draft with tag draft-ietf-xxwg-subj-blah-06, a reviewer with the email reviewer@example.org and an area director with email address ad.name@example.org . The notation is used to indicate the draft tag without the 'draft-' prefix; e.g., 'ietf-xxwg-subj- blah-06' for the draft tag above. The next section will describe the proposed tags in more detail. +-------------+-----------------------------------------------------+ | Document | Informal format and example | | type | | +-------------+-----------------------------------------------------+ | Agendas | agenda--- | | | agenda-65-xxwg-02 | | | | | Minutes | minutes--- | | | minutes-65-xxwg-00 | | | | | Charters | charter-- | | | charter-xxwg-04 | | | | | Discusses | discuss-- | | | discuss-ietf-xxwg-subj-blah-06-ad.name@example.org | | | | | Operational | ion--- | | notes | ion-iesg-id-guidelines-2005-03-25 | | | | | List | email---