From: http://tools.ietf.org/id/draft-ietf-tools-notification-03.txt See: http://tools.ietf.org/id/draft-ietf-tools-notification Title: Requirements for Document Notification Service Reference: IETF Network Working Group, Internet Draft 'draft-ietf-tools-notification-03.txt' Date: January 31, 2005 See also: http://xml.coverpages.org/specProduction.html#ietf ======================================================================== Network Working Group S. Shalunov Internet-Draft Internet2 Expires: August 4, 2005 January 31, 2005 Requirements for Document Notification Service draft-ietf-tools-notification-03.txt 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. 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 August 4, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 characters. 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 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 sent. 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 telechat. APPROVED-ANNOUNCEMENT-TO-BE-SENT The IESG has approved the document for publication, but no official approval message has been sent yet. 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 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: draft-ietf-tools-notification-17.txt"; 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 generated. 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 change). IETFLC General IETF last call issued on the document. RFC-SUBMIT The document has been submitted to the RFC editor for publication. 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 exists. 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 not otherwise in the alphabet. 2. In the existential tag, all asterisks not preceded with a backslash are replaced with a pseudo-character not otherwise in the alphabet. 3. In the existential tag, all question marks not preceded with a backslash are replaced with a pseudo-character not otherwise in the alphabet. 4. In the existential tag, all pseudo-characters are replaced with a backslash. 5. If, in the existential tag, each pseudo-character can be replaced with a (possibly empty) string of characters and each 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 [RFC2919]. 7.2 RSS Notification Dissemination FIXME: I might use some help here. I really only use RSS with rss2email. 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 feeds. 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 numbers). 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 required). 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 Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104 US 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 release-03 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. Acknowledgments. Revision 1.6 2005/01/26 22:18:12 shalunov; lines: +7 -5 Minor. 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. 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shalunov Expires August 4, 2005 [Page 24]