[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                        S. Shalunov
Internet-Draft                                                 Internet2
Expires: August 4, 2005                                 January 31, 2005

             Requirements for Document Notification Service

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 4, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   The output of the IETF consists of documents.  The IETF process is
   largely related to changing the status of documents.  Active
   participation in the work of the IETF often consists of writing or
   editing documents or providing input to the process of changing the
   documents' status.  Passive participation often consists of reading
   documents and observing the changes of their status.  This document
   describes the requirements for an automated service that helps the

Shalunov                 Expires August 4, 2005                 [Page 1]

Internet-Draft        Document Notification Service         January 2005

   IETF participants to learn about the existence and follow the changes
   of status of any particular document.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Document Definition and Document Tags  . . . . . . . . . . . .  5
   4.  Document States  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Events in the Life of a Document . . . . . . . . . . . . . . .  9
     5.1   Event Anatomy  . . . . . . . . . . . . . . . . . . . . . .  9
       5.1.1   Document tag . . . . . . . . . . . . . . . . . . . . .  9
       5.1.2   Serial number  . . . . . . . . . . . . . . . . . . . .  9
       5.1.3   Document name  . . . . . . . . . . . . . . . . . . . .  9
       5.1.4   Document state . . . . . . . . . . . . . . . . . . . .  9
       5.1.5   Date and time  . . . . . . . . . . . . . . . . . . . . 10
       5.1.6   Event title  . . . . . . . . . . . . . . . . . . . . . 10
       5.1.7   Event abstract . . . . . . . . . . . . . . . . . . . . 10
       5.1.8   Event URL  . . . . . . . . . . . . . . . . . . . . . . 10
       5.1.9   Event type . . . . . . . . . . . . . . . . . . . . . . 11
     5.2   Types of Events  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Kinds of Notification  . . . . . . . . . . . . . . . . . . . . 13
     6.1   Existence Notification . . . . . . . . . . . . . . . . . . 13
     6.2   Status Notification  . . . . . . . . . . . . . . . . . . . 14
   7.  Notification Dissemination Mechanisms  . . . . . . . . . . . . 15
     7.1   Email Notification Dissemination . . . . . . . . . . . . . 15
     7.2   RSS Notification Dissemination . . . . . . . . . . . . . . 15
     7.3   Atom Notification Dissemination  . . . . . . . . . . . . . 15
     7.4   WWW Notification Dissemination . . . . . . . . . . . . . . 15
   8.  Errors, Amendments, and Event Retention  . . . . . . . . . . . 16
   9.  Phases of Tool Development . . . . . . . . . . . . . . . . . . 17
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 18
   11.   Internationalization Considerations  . . . . . . . . . . . . 19
   12.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 20
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21
     13.1  Normative References . . . . . . . . . . . . . . . . . . . 21
     13.2  Informative References . . . . . . . . . . . . . . . . . . 21
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   B.  Revision History . . . . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 24

Shalunov                 Expires August 4, 2005                 [Page 2]

Internet-Draft        Document Notification Service         January 2005

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Shalunov                 Expires August 4, 2005                 [Page 3]

Internet-Draft        Document Notification Service         January 2005

2.  Introduction

   At present, notifications related to IETF documents are sent to up to
   three different mailing lists: the IETF announcements list
   (ietf-announce@ietf.org), the general IETF list (ietf@ietf.org), and
   to the mailing list of the working group, if there is one.  Different
   types of messages go to different mailing lists.  Someone who is
   interested in all notifications about a particular document would
   need to subscribe to the three mailing lists and monitor subject
   lines for both the document's file name and its title.  Such person
   would receive not only notifications about the document status and
   its changes, but also various messages related to the discussion of
   the document.  For some people, this would be a convenient way to
   follow a document.  Others might find that they might be getting too
   many messages of no interest and risk missing messages of interest.

   An automated notification service that allows one to follow only the
   changes of official status of a document, without necessarily
   following the changes of all the IETF documents, or the day-to-day
   activity of the working group responsible for the document, thus,
   appears beneficial.  This document describes requirements for such a
   notification service.  When this service is deployed, it becomes
   immediately useful on its own right by supplementing the existing
   notification mechanisms.  As experience is gained with the tool and
   it is accepted by the IETF community, the tool might be used to help
   automate existing notification mechanisms.

Shalunov                 Expires August 4, 2005                 [Page 4]

Internet-Draft        Document Notification Service         January 2005

3.  Document Definition and Document Tags

   This document discusses the status of other documents.  These other
   documents include:
   1.  IETF internet-drafts;
   2.  RFC documents;
   3.  STD documents;
   4.  BCP documents;
   5.  FYI documents.
   In the future, this list might be expanded, should the IETF or the
   RFC editor choose to start new document series.

   Throughout the life of a document, continuity between versions is
   preserved by being able to refer to the document using the same tag.
   This tag will be called a document tag.  This document assumes that
   any documents to which the automated notification service needs to be
   applicable possess these document tags.  Document tags are strings of

   For an internet-draft, the document tag is the file name without any
   extension or a version number (dot in front of an extension and dash
   in front of a version number are omitted, as well).  For example,
   this document's tag is "draft-ietf-tools-notification" (without
   quotes, naturally).  Documents' tags never change; so, should this
   document ever be published as an RFC, the document tag will remain
   the same; should this document be published, e.g., as a BCP and later
   reclassified as a historic FYI, the document tag would still be the
   same.  Note that the RFC editor currently already keeps the
   internet-draft file name (without the extension or the initial
   "draft-" string, but with the version number) from which an RFC
   originated; it can be found in the file rfc-index.xml distributed by
   the RFC editor as the <draft> element.  This is an extremely useful
   practice that should continue.

   It is clearly preferable that document tags be unique.  However, the
   current IETF policies do not appear to disallow the reuse of the file
   name of an expired internet-draft for a new internet-draft.  Changing
   this unfortunate policy is outside of scope of this document and of
   the IETF Tools team in general.  Should such tag collision occur, the
   notification service MAY treat the new internet-draft as a
   continuation of the old one (for the purposes of notifications).  The
   author believes that such collisions need to be prevented from
   happening by the internet-drafts administrator (or the
   internet-drafts submission tool, or whatever or whoever accepts IETF
   internet-draft in the future).  Note that the tool currently used by
   the internet-drafts administrator will (advantageously) not allow
   such reuse.

Shalunov                 Expires August 4, 2005                 [Page 5]

Internet-Draft        Document Notification Service         January 2005

   Frequently, personal drafts are republished as working group drafts.
   In this case, since heritage can be partial and ambiguous, the new
   working group draft MUST be treated by the notification service as a
   completely new document.  However, when the requisite information is
   available to the notifications service, it SHOULD issue an event of
   type REPUBLISHED-NEW-TAG (see Section 5.2).  The notification of
   event of this type will include enough information to continue
   tracking the same logical document.

Shalunov                 Expires August 4, 2005                 [Page 6]

Internet-Draft        Document Notification Service         January 2005

4.  Document States

   As the document lives, it goes through a sequence of states.  A
   change in the state always constitutes an event (see Section 5) that
   needs to be reported; however, not all events are necessarily
   associated with a change of state.

   The following states are currently defined:
   I-D-EXISTS Initial (default) state for all internet-drafts.  Not
      being tracked by the IESG as no request has been made of the IESG.
   PUBLICATION-REQUESTED A formal request has been made to
      advance/publish the document, following the procedures in Section
      7.5 of [RFC2418].  The request could be from a WG chair, from an
      individual through the RFC Editor, etc.  A document in this state
      has not (yet) been reviewed by an AD nor has any official action
      been taken on it.
   AD-EVALUATION A specific AD (e.g., the "Area Advisor" for the WG) has
      begun their review of the document to verify that it is ready for
      advancement.  The shepherding AD is responsible for doing any
      necessary review before starting an IETF Last Call or sending the
      document directly to the IESG as a whole.
   EXPERT-REVIEW An AD sometimes asks for an external review by an
      outside party as part of evaluating whether a document is ready
      for advancement.  MIBs, for example, are reviewed by the "MIB
      doctors".  Other types of reviews may also be requested (e.g.,
      security, operations impact, etc.)  Documents stay in this state
      until the review is complete and possibly until the issues raised
      in the review are addressed.
   IETF-LAST-CALL-REQUESTED The AD has requested that an IETF Last Call
      be started, but the the actual Last Call message has not been
   IN-IETF-LAST-CALL The document is currently waiting for IETF Last
      Call to complete.  Last Calls for WG documents typically last 2
      weeks, those for individual submissions last 4 weeks.
   WAITING-FOR-WRITEUP Before a standards-track or BCP document is
      formally considered by the entire IESG, the AD must write up a
      protocol action.  The protocol action is included in the approval
      message that the Secretariat sends out when the document is
      approved for publication as an RFC.
   WAITING-FOR-AD-GOAHEAD As a result of the IETF Last Call, comments
      may need to be responded to and a revision of the ID may be needed
      as well.  The AD is responsible for verifying that all Last Call
      comments have been adequately addressed and that the (possibly
      revised) document is in the I-D directory and ready for
      consideration by the IESG as a whole.

Shalunov                 Expires August 4, 2005                 [Page 7]

Internet-Draft        Document Notification Service         January 2005

   IESG-EVALUATION The document is being formally reviewed by the entire
      IESG.  In this phase, each AD reviews the document and airs any
      issues they may have.  Unresolvable issues are documented as
      "discuss" comments that can be forwarded to the authors/WG.
   IESG-EVALUATION-DEFER An AD requested additional time to review the
      document.  In the current IESG procedures, this deferral is
      designed to be an exception mechanism, and can only be invoked
      once, the first time the document comes up for discussion during a
   APPROVED-ANNOUNCEMENT-TO-BE-SENT The IESG has approved the document
      for publication, but no official approval message has been sent
   APPROVED-ANNOUNCEMENT-SENT The IESG has approved the document for
      publication, and an official approval message has been sent to the
      RFC editor.
   RFC-ED-QUEUE The document is in the RFC editor queue.
   RFC-PUBLISHED Published as an RFC.
   DNP-WAITING-FOR-AD-NOTE Do Not Publish: The IESG recommends against
      publishing the document, but the writeup explaining its reasoning
      has not yet been produced.
   DNP-ANNOUNCEMENT-TO-BE-SENT The IESG recommends against publishing
      the document, the writeup explaining its reasoning has been
      produced, but the official "do not publish" recommendation message
      has not been sent yet.
   AD-IS-WATCHING An AD is aware of the document and has chosen to place
      the document in a separate state in order to keep a closer eye on
      it (for whatever reason).  Documents in this state are still not
      being actively tracked in the sense that no formal request has
      been made to publish or advance the document.  The sole difference
      between this state and I-D-EXISTS is that an AD has chosen to put
      it in a separate state, to make it easier to keep track of (for
      his or her own reasons).
   DEAD Document is "dead" and is no longer being tracked.
   EXPIRED The document has expired in the I-D repository without
      entering the publication process.  If the document enters the
      publication process and is later withdrawn or replaced, the DEAD
      state is used instead.

   New states might be defined by the IETF in the future, but (so that
   future software can continue to work with old documents) the states
   listed here MUST be supported by all implementations even if a state
   is deprecated and its use in new documents is discouraged or
   prohibited.  Should a state be deprecated, it must not be removed
   from the list above, but rather its description should receive a note
   explaining the deprecated status of the state.

Shalunov                 Expires August 4, 2005                 [Page 8]

Internet-Draft        Document Notification Service         January 2005

5.  Events in the Life of a Document

   The notification service deals with events in the life of documents.

5.1  Event Anatomy

   An event is a tuple with the following members:
   1.  Document tag;
   2.  Serial number;
   3.  Document (new) name;
   4.  Document (new) state;
   5.  Date and time;
   6.  Event title;
   7.  Event abstract;
   8.  Event URL;
   9.  Event type.
   The individual members of the tuple are discussed below.

5.1.1  Document tag

   Document tags are explained in Section 3.

5.1.2  Serial number

   The serial number of an event is an unsigned decimal integer (i.e.,
   "0" or a non-empty string of characters from "0" to "9" that does not
   start with "0").  For any given document tag, events are numbered
   sequentially, starting from 0, as they enter the notification system.
   With each new event for a given document tag, the serial number is
   incremented by 1.  Thus, the tuple <document tag, serial number>
   forms a unique identifier of an event within the notification system.
   See Section 8 for more information on treatment of serial numbers
   when events are later found completely fictitious or need amendments.

5.1.3  Document name

   For an internet-draft, the name of the document is the file name
   without the extension (or the dot preceding it): e.g.,
   "draft-ietf-tools-notification-00".  For other kinds of documents,
   the name is the document series name followed by the document number
   (without a separating space): e.g., "RFC1234".  Note that an event is
   often (but not always) associated with a change in the name of the
   document.  The new name is always used.

5.1.4  Document state

   The document state is the new state of the document after the event.
   (The old state might or might not coincide with the new state.)

Shalunov                 Expires August 4, 2005                 [Page 9]

Internet-Draft        Document Notification Service         January 2005

   Document states are strings of characters discussed in Section 4.

5.1.5  Date and time

   Date and time are specified together in the following format: four
   digits specifying year; dash; two digits specifying month; dash; two
   digits specifying day of the month; the capital letter "T"; two
   digits specifying the hour of the day in 24-hour format; colon; two
   digits specifying minute; two digits specifying second; and, finally,
   the capital letter "Z".  This timestamp always contains exactly 20
   characters and refers to universal coordinated time (UTC).  The
   timestamp describes the time when the event occured.  Example of a
   valid timestamp: "2005-01-24T04:15:12Z".  This timestamp format MUST
   be used; no other formats or variations or this format are allowed.

5.1.6  Event title

   The title of the event is a human-readable synopsis of the event.  It
   should be suitable for use as an email message subject or a web page
   title.  Examples of reasonable titles:
   o  "New internet-draft: draft-ietf-tools-notification-00.txt";
   o  "New version of internet-draft:
   o  "Draft forwarded to IESG: draft-ietf-tools-notification-17.txt";
   o  "IESG comments on draft-ietf-tools-notification-17.txt";
   o  "draft-ietf-tools-notification-17.txt published as RFC8888";
   o  "RFC9999 obsoletes RFC8888".
   (Naturally, the quotes do not appear in the actual titles.) Examples
   of bad titles:
   o  "Event happened";
   o  "Draft advanced";
   o  "RFC publication";
   o  "Frobnication Considered Harmful on the Internet".
   Note that, in particular, the title of the document itself makes a
   poor event title.

5.1.7  Event abstract

   The event abstract elucidates the event and should be suitable for
   being used as a body of an email message or of a short web page that
   would be followed by the event URL, where more information about the
   event could be obtained.  The abstract generally should not exceed a
   page of text or so.  The abstract SHOULD contain as much relevant
   information as practical within the space limits.

5.1.8  Event URL

   The event URL points to a more complete description of the event.

Shalunov                 Expires August 4, 2005                [Page 10]

Internet-Draft        Document Notification Service         January 2005

   For example, currently, the URL might point to a relevant URL within
   the I-D tracker [cite: FIXME].  Should no event description be
   published as a document with a URL, the event URL MAY be the URL of
   the document itself.

5.1.9  Event type

   The event type, as a member of the event tuple, is an opaque
   identifier (a string of characters).  Particular event types are
   discussed in Section 5.2.

5.2  Types of Events

   The following event types are valid:
   NEW New document is created.
   VERSION New version of an internet-draft is available.
   EXPIRED The current version of the draft has expired without a new
      version submitted.
   RESURRECTED After an expiration, a new version of the draft has been
      submitted and became available or the text of the draft has been
      made current again in some other way.
   REPUBLISHED-NEW-TAG The old document has now been abandoned and a new
      document with a new document tag has been issued to replace it
      (perhaps a personal internet-draft has been replaced with a
      working-group draft).  When an event of this type enters the
      system, notification MUST include information on ways to easily
      subscribe to notifications related to the new (republished)
      document, but the user SHOULD NOT start to receive these
      notifications automatically and without further action.
      Naturally, the old document tag is used with events of this type.
      Note that human judgment is required to generate an event of this
      type, so a working group chair for the working group that accepted
      the republished document needs to be able to supply information to
      the notification service to have any events of this type
   WGLC Working group last call issued on the document.
   IESG-SUBMIT The document has been submitted to the IESG for approval.
   IESG-CHANGE The document had some status change while being
      considered by the IESG (e.g., IESG review, comments, request for a
   IETFLC General IETF last call issued on the document.
   RFC-SUBMIT The document has been submitted to the RFC editor for
   RFC-CHANGE The document, not yet published by the RFC editor, had
      some status change (e.g., authors' 48 hours).

Shalunov                 Expires August 4, 2005                [Page 11]

Internet-Draft        Document Notification Service         January 2005

   RFC-PUBLISHED The document is published as an RFC (and, perhaps,
      simultaneously as an STD, BCP, or FYI).
   STD-REMOVED The document is no longer an STD.
   BCP-REMOVED The document is no longer a BCP.
   STD-CHANGED The status of an STD changed while it remained an STD
      (e.g., advanced).
   RFC-CHANGED The document remains an RFC, but some change in its
      status happened (other than those specifically mentioned above,
      e.g., a FYI reclassified as historic).
   ERROR An event was previously entered into the system erroneously and
      this is now discovered and corrected (e.g., it was erroneously
      detected that a document was forwarded to the RFC editor when, in
      fact, the document still remains in the IESG queue).
   MISC An event related to the document, but not mentioned above.

   The most specific event type MUST always be used.  In particular, the
   MISC event type MUST NOT be used when a more appropriate event type

Shalunov                 Expires August 4, 2005                [Page 12]

Internet-Draft        Document Notification Service         January 2005

6.  Kinds of Notification

   Notifications are generally of two kinds: notifications of existence
   of documents, which help the service's user learn about new
   internet-drafts (Section 6.1), and notifications about the change of
   status of specific documents, which help learn about events in the
   life of a particular document a user is interested in (Section 6.2).

   Existence notifications deal with events of type NEW.  Status change
   notifications deal with events of all other types.

6.1  Existence Notification

   Just as document tags define particular documents, some way is needed
   to define classes of documents about which a user would like to
   learn.  For simplicity's sake, these tags are based on file names.

   An existential tag is a sequence of characters, of which three have a
   special meaning: asterisk ("*"), question mark ("?"), and backslash
   ("\").  A document tag can match an existential tag.  Given an
   existential tag and a document tag, the match is decided as follows:
   1.  In the existential tag, all sequences of two consecutive
       backslash characters (as the string representing the tag is read
       from left to right) are replaced with a pseudo-character
       <backslash> not otherwise in the alphabet.
   2.  In the existential tag, all asterisks not preceded with a
       backslash are replaced with a pseudo-character <asterisk> not
       otherwise in the alphabet.
   3.  In the existential tag, all question marks not preceded with a
       backslash are replaced with a pseudo-character <question> not
       otherwise in the alphabet.
   4.  In the existential tag, all <backslash> pseudo-characters are
       replaced with a backslash.
   5.  If, in the existential tag, each <asterisk> pseudo-character can
       be replaced with a (possibly empty) string of characters and each
       <question> pseudo-character can be replaced with a single
       character so that the existential tag coincides with the document
       tag, the document tag matches the existential tag.  Otherwise, it
       does not match.
   Note: the preceding forms a definition of matching, not an algorithm
   suitable to actually verify matches in the software implementing the
   notification service.

   An event is said to match an existential tag if the event's type is
   NEW and the event's document tag matches the existential tag.

   The user of the notification service obtains a set of events of
   interest by deciding on existential tags of interest and then

Shalunov                 Expires August 4, 2005                [Page 13]

Internet-Draft        Document Notification Service         January 2005

   submitting these tags in a way discussed in Section 7 to the
   notification service.

   For example, a user interested in internet-drafts of the IETF Tools
   team might subscribe to the existential tag "draft-ietf-tools-*".  To
   watch emergence of personal drafts by John Doe, one might use
   "draft-doe-*".  To watch emergence of all new internet-drafts, "*"
   can be used.

6.2  Status Notification

   A user can submit a document tag to the notification service in a way
   discussed in Section 7 to obtain a set of all events whose document
   tag equals to the one submitted.

Shalunov                 Expires August 4, 2005                [Page 14]

Internet-Draft        Document Notification Service         January 2005

7.  Notification Dissemination Mechanisms

   Different users would find different notification mechanisms more
   convenient.  The following mechanisms are defined:
   1.  Email,
   2.  RSS,
   3.  Atom, and
   4.  WWW.

7.1  Email Notification Dissemination

   Users can subscribe to existence notifications with given existential
   tags and to status notifications with given document tags.  Each
   event that requires notification would then generate a single,
   separate, email message.

   Email messages generated by the notification service MUST conform to

7.2  RSS Notification Dissemination

   FIXME: I might use some help here.  I really only use RSS with

7.3  Atom Notification Dissemination

   Atom [Atom] feeds are similar to RSS feeds (Section 7.2) and are
   meant to eventually replace them.

7.4  WWW Notification Dissemination

   The WWW mechanism is similar to the RSS and Atom mechanisms
   (Section 7.2 and Section 7.3), except for the format.  In the case of
   WWW notifications, an HTML representation of the feed is used.  All
   events associated with the user-selected tags are displayed in
   reverse chronological order.  The notification service MAY, for
   implementation's simplicity's sake, present events associated with a
   document tag in reverse numeric order by serial number; of course, no
   such option is available for existential tags.

Shalunov                 Expires August 4, 2005                [Page 15]

Internet-Draft        Document Notification Service         January 2005

8.  Errors, Amendments, and Event Retention

   Should it be detected that a notification for an event was generated
   in error (the event did not, in fact, occur), a new event of type
   ERROR is created that explains in its title and abstract the nature
   of the error.  Email notifications are generated for this new event.
   Subsequently, the erroneous event, together with the new event of
   type ERROR, is removed from RSS, Atom, and WWW notification feeds.

   Should it be detected that a notification for an event was generated
   with an error, the event, in its corrected form, should reenter the
   notification service.  When email notifications are generated, it
   MUST be noted in the title (using the word "CORRECTED" in uppercase,
   followed by a colon, at the start of the title) and in the abstract
   that the event was corrected.  The correct type of event MUST be
   transmitted in this case (rather than "ERROR").  Subsequently, the
   erroneous event is corrected in the RSS, Atom, and WWW notification

   Note that these provisions only cover true clerical errors and not
   errors of judgment or others.

   The notification service retains information about all events in
   perpetuity.  While not visible through the RSS, Atom, and WWW
   notification interfaces, any history of revisions of erroneous events
   MUST be retained in perpetuity, as well.

   Serial numbers continue to increase sequentially for events that are
   reissued in an amended form.  Events of type ERROR get their own
   serial number in the usual way, as well; in addition, the serial
   number of the event canceled by the event of type ERROR MUST NOT be
   reused.  Thus, when an event of type ERROR is processed, the RSS,
   Atom, and WWW feeds will be (perhaps after addition of another event)
   missing two numbers in the sequence (not necessarily consecutive

Shalunov                 Expires August 4, 2005                [Page 16]

Internet-Draft        Document Notification Service         January 2005

9.  Phases of Tool Development

   FIXME: This needs to be discussed further.

Shalunov                 Expires August 4, 2005                [Page 17]

Internet-Draft        Document Notification Service         January 2005

10.  Security Considerations

   To prevent unwanted email notifications, the notification service
   should follow the usual good mailing list practice: only subscribe
   after receiving a confirmation (via email or WWW) of a subscription
   message sent to the email address being subscribed; an exception is
   formed, of course, when an authenticated WWW user is subscribing his
   own address to new notifications.

   To prevent sensitive information disclosure, the notification service
   SHOULD strive to run with the privileges of an unauthenticated
   network user.  (To minimize polling, the service might receive
   privileged hints of the form "there is new data for draft
   such-and-such in the I-D tracker" or similar, but the actual data put
   into the notifications should come, as much as possible, from an
   already public source.)  In cases where the notification service
   would, by design, be disclosing information not otherwise public,
   careful auditing would need to be conducted: just as it is conducted
   with the tools that currently make the needed information public.

   In general, with email notification, those with access to the mailbox
   of the recipient are to be able to unsubscribe from future
   notifications.  However, IETF mailing lists (such as working group
   mailing lists) are an important exception to this.  Subscribers to
   IETF mailing lists MUST NOT be able to unsubscribe the mailing lists
   from document notifications to which the list administrator has
   subscribed them (users are, of course, always free to unsubscribe
   from the IETF mailing list itself, but they are not to decide whether
   the mailing list will receive notifications about, e.g., a working
   group draft).  FIXME: The exact way in which this is best
   accomplished needs to be discussed further.

Shalunov                 Expires August 4, 2005                [Page 18]

Internet-Draft        Document Notification Service         January 2005

11.  Internationalization Considerations

   The IETF generally conducts its business in English.  However, should
   notification of events in other languages become necessary in the
   future (after, perhaps, a policy change), the notification service
   MUST be able to use UTF-8 character set from the start.  Since, for
   characters in US-ASCII, UTF-8 coincides with US-ASCII, the burden of
   using UTF-8 on the implementor is negligible (and consists mostly of
   placing "UTF-8" in any appropriate character set fields, where

   Some email clients and many WWW clients display messages and pages in
   UTF-8 differently from messages in US-ASCII, or not at all, even when
   the text does not actually contain any characters not in US-ASCII.
   For this unfortunate reason, the notification service MUST use the
   US-ASCII character set specification when the message happens to
   actually be in US-ASCII, reserving UTF-8 for the occasions when
   characters outside of US-ASCII are actually present.

Shalunov                 Expires August 4, 2005                [Page 19]

Internet-Draft        Document Notification Service         January 2005

12.  IANA Considerations

   This document requires no action from the IANA.

Shalunov                 Expires August 4, 2005                [Page 20]

Internet-Draft        Document Notification Service         January 2005

13.  References

13.1  Normative References

   [Atom]     Nottingham, M. and R. Sayre, "The Atom Syndication
              Format", Work in
              progress, draft-ietf-atompub-format-05.txt, January 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2919]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
              and Namespace for the Identification of Mailing Lists",
              RFC 2919, March 2001.

13.2  Informative References

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

Author's Address

   Stanislav Shalunov
   1000 Oakbrook Drive, Suite 300
   Ann Arbor, MI  48104

   Phone: +1-734-913-4260
   Email: shalunov@internet2.edu
   URI:   http://www.internet2.edu/~shalunov/

Shalunov                 Expires August 4, 2005                [Page 21]

Internet-Draft        Document Notification Service         January 2005

Appendix A.  Acknowledgments

   The author gratefully acknowledges the contributions of: Harald
   Alvestrand, Donald Eastlake, Bill Fenner, Joel Halpern, Henrik
   Levkowetz, and Thomas Narten.

Shalunov                 Expires August 4, 2005                [Page 22]

Internet-Draft        Document Notification Service         January 2005

Appendix B.  Revision History

   FIXME: This section needs to be removed before publication.

   $Log: draft-ietf-tools-notification.xml,v $
   Revision 1.13  2005/01/31 18:46:24  shalunov
   Make xml2rfc happier.

   Revision 1.12  2005/01/31 18:36:31  shalunov

   Revision 1.11  2005/01/31 18:35:09  shalunov
   Manually insert old revision history.

   Revision 1.10  2005/01/31 18:30:47  shalunov
   Try to fix the revision history

   Revision 1.9  2005/01/31 18:17:14  shalunov
   Insert stub Atom section and revision history.

   Revision 1.8  2005/01/31 17:51:34  shalunov;  lines: +33 -6
   Event type REPUBLISHED-NEW-TAG.  Merge notification kinds into
   single section.

   Revision 1.7  2005/01/31 17:33:25  shalunov;  lines: +140 -24
   States from https://datatracker.ietf.org/public/states_table.cgi.

   Revision 1.6  2005/01/26 22:18:12  shalunov;  lines: +7 -5

   Revision 1.5  2005/01/26 22:08:58  shalunov;  lines: +101 -10
   Changes mostly based on discussion during today's call.  Added new
   members of the event tuple: document state and serial number.
   Discussed both.  Minor changes and clarifications.

   Revision 1.4  2005/01/26 08:57:23  shalunov;  lines: +1 -1
   References -> Normative References

   Revision 1.3  2005/01/26 08:47:29  shalunov;  lines: +13 -5
   Pass over the document.  Minor edits.  <draft> element.

   Revision 1.2  2005/01/26 00:49:33  shalunov
   Bill Fenner says in
   200501251752.j0PHqJJE003535@bright.research.att.com that
   the tool that the secretariat uses prevents reuse of expired drafts'
   names.  Reflected.

Shalunov                 Expires August 4, 2005                [Page 23]

Internet-Draft        Document Notification Service         January 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Shalunov                 Expires August 4, 2005                [Page 24]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/