INTERNET-DRAFT Charles H. Lindsey Usenet Format Working Group University of Manchester March 2005 Usenet Best Practice Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I 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.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in September 2005. Abstract This Draft is intended to become a "Best Current Practice" RFC. Its purpose is to set out how software should behave and conventions which users should observe, in order that Netnews in general, and Usenet in particular, should provide the most effective service to its users. [Remarks enclosed in square brackets and aligned with the left margin, such as this one, are not part of this draft, but are editorial notes to explain matters amongst ourselves, or to point out alternatives, or to assist the RFC Editor.] [In this draft, references to [NNTP] are to be replaced by [RFC 977], or else by references to the RFC arising from the series of drafts draft- ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at the time this document is published. C. H. Lindsey [Page 1] Usenet Best Practice March 2005 Table of Contents 1. Introduction .................................................. 4 1.1. Basic Concepts ............................................ 4 1.2. Objectives ................................................ 4 2. Definitions, Notations and Conventions ........................ 5 2.1. Definitions ............................................... 5 2.2. Textual Notations ......................................... 5 3. The Well-Behaved User Agent ................................... 6 3.1. The Well-Behaved Posting Agent ............................ 6 3.1.1. Construction of Headers ............................... 7 3.1.1.1. Date .............................................. 8 3.1.1.2. From .............................................. 8 3.1.1.3. Message-ID ........................................ 9 3.1.1.4. Subject ........................................... 9 3.1.1.5. Newsgroups ........................................ 10 3.1.1.6. Reply-To .......................................... 10 3.1.1.7. Organization ...................................... 10 3.1.1.8. Distribution ...................................... 10 3.1.1.9. Followup-To ....................................... 10 3.1.1.10. User-Agent ....................................... 10 3.1.2. Construction of Bodies ................................ 11 3.1.2.1. Signatures ........................................ 11 3.1.2.2. Usage of MIME ..................................... 12 3.1.2.3. Content-Transfer-Encoding ......................... 13 3.2. The Well-Behaved Followup Agent ........................... 15 3.2.1. Construction of Headers ............................... 15 3.2.1.1. Subject ........................................... 15 3.2.1.1.1. Examples ...................................... 17 3.2.1.2. Newsgroups ........................................ 17 3.2.1.3. Mail-Copies-To .................................... 17 3.2.1.4. References ........................................ 18 3.2.2. Construction of Bodies ................................ 18 3.2.2.1. Quoting and Attributions .......................... 18 3.2.2.2. Signatures ........................................ 20 3.2.2.3. Usage of MIME ..................................... 20 3.3. The Well-Behaved Reading Agent ............................ 20 3.3.1. Display of Headers .................................... 20 3.3.2. Presentation of Articles .............................. 21 3.3.2.1. Threading ......................................... 21 3.3.2.2. Killfiles ......................................... 23 3.3.2.3. Interpretation of Distributions ................... 23 3.3.3. Interpretation of Bodies .............................. 23 3.3.3.1. Usage of MIME ..................................... 24 3.4. The Well-Behaved Reply Agent .............................. 25 3.5. User Interfaces ........................................... 25 4. The Well-Behaved Injecting Agent .............................. 26 4.1. Construction of Headers ................................... 27 4.1.1. Sender ................................................ 27 4.1.2. Organization .......................................... 27 4.1.3. User-Agent ............................................ 27 4.1.4. Injection-Info ........................................ 28 C. H. Lindsey [Page 2] Usenet Best Practice March 2005 5. The Well-Behaved Relaying Agent ............................... 28 5.1. The Path Header ........................................... 29 5.1.1. Suggested Verification Methods ........................ 29 6. The Well-Behaved Serving Agent ................................ 30 6.1. Control Messages .......................................... 30 6.1.1. The 'newgroup' and 'mvgroup' Control Messages ......... 30 6.1.2. Cancel Messages ....................................... 30 7. The Well-Behaved Hierarchy Administrator ...................... 31 7.1. Control Messages .......................................... 31 7.2. Naming of Newsgroups ...................................... 32 7.3. Format of Bodies .......................................... 33 7.4. Promulgation .............................................. 34 8. The Well-Behaved Moderator .................................... 34 9. The Well-Behaved Poster ....................................... 34 9.1. Construction of Headers ................................... 34 9.1.1. From .................................................. 35 9.1.2. Summary ............................................... 35 9.1.3. Expires ............................................... 35 9.2. Construction of Bodies .................................... 35 10. References ................................................... 36 11. Acknowledgements ............................................. 37 12. Contact Address .............................................. 37 Appendix A - Notices .............................................. 38 C. H. Lindsey [Page 3] Usenet Best Practice March 2005 1. Introduction 1.1. Basic Concepts "Netnews" is a set of protocols for generating, storing and retrieving news "articles" (which resemble email messages) and for exchanging them amongst a readership which is potentially widely distributed. It is organized around "newsgroups", with the expectation that each reader will be able to see all articles posted to each newsgroup in which he participates. The syntax of such articles is defined in [USEFOR] and the actual protocols in [USEPRO]. "Usenet" is a particular worldwide open network based upon the Netnews protocols, with the newsgroups being organized into recognized "hierarchies". Anybody can join (it is simply necessary to negotiate an exchange of articles with one or more other participating hosts). Usenet "belongs" to those who administer the hosts of which it is comprised. There is no Cabal with overall authority to direct what is to be be allowed. Nevertheless, there do exist agencies within Usenet that have authority to establish policies and to perform administrative functions, but such authority derives solely from the consent of those sites which choose to recognize it (and who can decline to exchange articles with sites which choose not to recognize it). Usually, the authority of such an agency is restricted to a particular hierarchy, or group of hierarchies. A "policy" is a rule intended to facilitate the smooth operation of a network by establishing parameters which restrict behaviour that, whilst technically unexceptionable, would nevertheless contravene some accepted standard of "Good Netkeeping". Since the ultimate beneficiaries of a network are its human readers, who will be less tolerant of poorly designed interfaces than mere computers, articles in breach of established policy can cause considerable annoyance to their recipients. 1.2. Objectives The purpose of this document is to set out how software should behave and conventions which users should observe, in order that Netnews in general, and Usenet in particular, should provide the most effective service to its users. [USEFOR] and [USEPRO] are standards, and hence their requirements are mandatory. The requirements set out here are in addition to those. Their purpose is to establish "Best Current Practice", and hence they are advisory. Nevertheless, failure to observe them will severely prejudice the good order of Usenet, and cause great inconvenience to the users of that medium. NOTE: The extreme irritation caused to other readers by such violations is not to be underestimated; however, enforcement of such rules is more a matter of sensible design or of social C. H. Lindsey [Page 4] Usenet Best Practice March 2005 pressure (whose effectiveness should not be underestimated, even though it cannot be prescribed). Many of these requirements are matters of policy which may vary from network to network, from hierarchy to hierarchy within one network, and even between individual newsgroups within one hierarchy. It is assumed, for the purposes of this document, that agencies with varying degrees of authority to establish such policies will exist, and that where they do not, policy will be established by mutual agreement. However, it is NOT the purpose of this document to define how the authority of various agencies to exercise control or oversight of the various parts of Usenet is established (that is itself a matter of policy). For the benefit of networks and hierarchies without such established agencies, and to provide a basis upon which all agencies can build, this present document often provides default policy parameters, usually introducing them by a phrase such as "As a matter of policy ...". NOTE: The practices recommended here relate only to Netnews and Usenet, and not to any other medium. Nevertheless, it may be that some of them may turn out to be helpful for other media such as mailing lists. 2. Definitions, Notations and Conventions 2.1. Definitions All the technical terms defined in F-1.5 and P-2.1 are considered to be defined in this document also. 2.2. Textual Notations In this document, references to sections in [USEFOR] are prefixed with "F-" and references to sections in [USEPRO] are prefixed with "P-". This document contains explanatory NOTEs using the following format. These may be skipped by persons interested solely in the content of the specification. The purpose of the notes is to explain why choices were made, to place them in context, or to suggest possible implementation techniques. NOTE: While such explanatory notes may seem superfluous in principle, they often help the less-than-omniscient reader understand the true intent of the specification in cases where the wording is not entirely clear. Certain words, when capitalized, are used to define the significance of individual requirements. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words associated with the word "NOT", are to be interpreted as described in [RFC 2119]. C. H. Lindsey [Page 5] Usenet Best Practice March 2005 However, as provided in that RFC, the force of these words is lower here than would have been the case in a standards track document. In particular, violation of a MUST or SHOULD does not necessarily imply a failure of interoperability, but rather that established policy or accepted best practice would be breached, to the detriment of the good order of Usenet. NOTE: A requirement imposed on a relaying or serving agent regarding some particular article should be understood as applying only if that article is actually accepted for processing (since any agent may always reject any article entirely, for reasons of site policy). [That NOTE can probably be removed, or severely rewritten, once we have a better idea of the requirements/recommendations we are going to make in this document.] Wherever the context permits, use of the masculine includes the feminine and use of the singular includes the plural, and vice versa. Throughout this document we will give various examples. In order to prevent possible conflict with "Real World" entities and people the top level domain ".example" is used in all sample domains and addresses. The hierarchy "example.*" is also used as a sample hierarchy. Information on the ".example" top level domain is in [RFC 2606]. 3. The Well-Behaved User Agent The term "user agent" comprises posting agents, reading agents and followup agents as defined in [USEPRO], and also reply agents, by which is meant a user agent that is generating an email, presumably addressed to the poster of an article. Although it is usual for all these functionalities to be included within a single piece of software, it is convenient to discuss them separately here. This section is addressed primarily to the implementors of user agents. Whilst it is common for such agents to combine the functions of a Netnews User Agent (NUA) and a Mail User Agent (MUA), it needs to be realized that they serve different functions, and adding a few extra features to an MUA is unlikely to result in a good NUA, any more than adding a few extra features to an NUA would result in a good MUA. 3.1. The Well-Behaved Posting Agent The implementor of a posting agent SHOULD make it possible for a suitably perseverent poster to generate any article, however absurd, that conforms strictly to [USEFOR]. On the other hand, it needs to be understood that the difference between a good posting agent and a bad posting agent lies in its ability to encourage the poster to adhere to good standards of "netkeeping", by making it easy to generate articles that will be widely acceptable to the conventions and expectations of the Usenet community, and hard to generate articles outside of those norms. This is largely a matter of choosing C. H. Lindsey [Page 6] Usenet Best Practice March 2005 appropriate defaults for various parameters and settings. Here it shold be noted that what is acceptable in Email (which is a one-to-few communication where the author can be expected to be aware of the capabilities and preferences of his correspondents) may not be acceptable in Netnews (which is a one-to-many communication directed at an unseen and unknown audience). Much grief has arisen in the past from poorly designed agents which tried to imppose onto Usenet defaults and practices which were perfectly appropriate for Email. 3.1.1. Construction of Headers Whilst it SHOULD be possible to insert any legitimate header, not limited to those defined in [USEFOR] and including experimental headers, there are certain essential headers, namely the Subject, Newsgroups, Followup-To and Reply-To headers which the poster MUST be able to insert and/or edit (and to do so at any stage during the composition of the article). Note that this specifically includes the possibility of setting the followup to "poster". [s/experimental headers/X-headers/ if the term is not defined in USEFOR.] NOTE: This does not mean that header must be presented for editing in the exact form specified in [USEFOR]; a graphical interface for editing the various header contents would suffice, although it would be useful if that included the facility for the poster to determine the folding. Posting agents SHOULD permit the poster to include headers of arbitrary length (and MUST permit at least 79 characters). However, they SHOULD endeavour to keep individual header lines, so far as is possible, within 79 characters (or other established policy limit) by folding them at suitable places (however, the limit of 998 octets [RFC 2822]) on any individual header line still applies); but if the poster has manually folded a header within the accepted limits (to achieve some pleasing layout, for example) the posting agent SHOULD respect the poster's intent. NOTE: The reason for the figure 79 is to ensure that all lines will fit in a standard 80-column screen without having to be wrapped. The limit is 79 not 80 because, while 80 fit on a line, any character in the last column often forces a line-wrap. Although headers are defined in such a way that folding can take place between many of the lexical tokens (and even within some of them), [RFC 2822] RECOMMENDS that folding be limited to placing the CRLF at higher-level syntactic breaks and that, if a header content is defined as comma-separated values, folding occur after the comma separating the values, even if it is allowed elsewhere. It SHOULD also avoid leaving trailing WSP on the preceding line. There is a preferred case convention, which posters and posting agents SHOULD use: each hyphen-separated "word" has its initial letter (if any) in uppercase and the rest in lowercase, except that C. H. Lindsey [Page 7] Usenet Best Practice March 2005 some abbreviations have all letters uppercase (e.g. "Message-ID" and "MIME-Version"). [If USEFOR follows this, then add "The forms given in the various rules defining headers in [USEFOR] show the preferred forms (but relaying and reading agents are expected to tolerate articles not obeying this convention)."] A comment [RFC 2822]) is normally used to provide some human readable informational text, except at the end of a mailbox which contains no phrase, as in fred@foo.bar.example (Fred Bloggs) as opposed to "Fred Bloggs" . The former is a deprecated, but commonly encountered, usage for indicating the name of the person whose mailbox it is. Posting agents SHOULD NOT now be generating it. Headers that merely state defaults explicitly (e.g., a Followup-To header with the same content as the Newsgroups header, or a MIME Content-Type header with contents "text/plain; charset=us-ascii"), or state information that reading agents can typically determine easily themselves (e.g. the length of the body in octets) are redundant and posting agents SHOULD NOT include them. There follow some recommendations specific to particular headers. 3.1.1.1. Date It is RECOMMENDED to add a comment, after the , containing the time zone in human-readable form. However, many of the abbreviations commonly used for this purpose are ambiguous, and so the value given by the is the only definitive form. For example: Date: Sat, 26 May 2001 11:13:00 -0500 (EST) 3.1.1.2. From The mailboxes in the From header MUST contain syntactically valid email addresses identifying the poster(s). Each such mailbox SHOULD be a working email address, belonging to the poster(s) of the article, or the person or agent on whose behalf the article is posted. When, for whatever reason, a poster does not wish ro use a working address, the mailbox concerned SHOULD end in the top level domain ".invalid" [RFC 2606] (cf. P-7.5). NOTE: It is fashionable for posters to disguise their mail addresses to discourage malicious harvesting and for other purposes. Whilst the circumstances which might make this seem desirable are much to be regretted, the practice cannot be regarded as in the best interests of Usenet, and this document does not seek to promote the practice, even though it shows how to do it "correctly". Therefore, it is NOT recommended that C. H. Lindsey [Page 8] Usenet Best Practice March 2005 implementors should go out of their way to facilitate it. 3.1.1.3. Message-ID Posting agents have the option of generating their own message identifiers, or of leaving it to the injecting agent. Recall that it is an absolute requirement of [RFC 2822] and [USEFOR] that message identifiers should be unique with regard to all other Netnews articles or Email messages, past, present or future. Although it would in practice be sufficient to ensure that there were astronomical odds against a duplicated message identifier, the method RECOMMENDED in [RFC 2822] for bringing this about is by using the domain name (or possibly the IP address) of the originating site in the of the , together with the time of composition and other disambiguating material (such as a process number or a serial number) in the . It is also in order to include additional information of significance to the poster within the , and even to deliberately make a non-unique identifier in cases where the identical message is to be posted by several posters (for example, a cancel for an article which may also be cancelled by others). [Recall that we have two drafts regarding the construction of message identifiers on www.landfield.com/usefor that were written in the early days of Usefor. Maybe these should be dusted down, published, and referred to here.] 3.1.1.4. Subject There is a temptation amongst inventors of new protocols, and even amongst lawmakers [MALAMUD], to require particular phrases to be inserted or regognized automatically at particular places within the Subject header. This temptation is strongly to be resisted. [Remove the reference to [MALAMUD] if it has not made it to RFC by the time we go to press.] There are, however, two exceptions to this principle which have become hallowed by longstanding usage: 1. There is an established convention for the Subject header in a followup to begin with "Re: ", and this SHOULD be supported (see 3.2.1.1). 2. The former practice whereby a Subject starting with "cmsg" was construed as a control message (P-6) is now deprecated but, on account of legacy software, non-control messages SHOULD NOT start with the string "cmsg ". Nevertheless, it is still customary for the Subject content of a control message (i.e. an article that also contains a Control header) to start with the string "cmsg ", and this convention MAY be followed. Subject headers are for humans to read, and the most that user agents should do is to filter them as directed by their human readers. If some enhancement to Netnews requires support within the headers, then the proper procedure is to invent a new header for the purpose, or to C. H. Lindsey [Page 9] Usenet Best Practice March 2005 adapt an existing header (supposing it had the capability to support such adaptations). 3.1.1.5. Newsgroups There are restrictions on the length of components of s, and on the s themselves, as described more fully in 7.2. Posting and injecting agents MAY attempt to enforce them but, because of the possibility that hierarchy policies or future standards may relax them, it SHOULD be possible for posters to override such checks, and software MUST be so written that they can be disabled altogether. Posting agents MAY (and followup agents SHOULD) accept articles crossposted to newsgroups which do not exist on their local hosts, though posting agents SHOULD at least alert the poster to the situation and request confirmation. 3.1.1.6. Reply-To In the absence of Reply-To, the reply address(es) is the address(es) in the From header. For this reason a Reply-To SHOULD NOT be included if it just duplicates the From header. NOTE: Use of a Reply-To header is preferable to including a similar request in the article body, because replying agents can take account of Reply-To automatically. 3.1.1.7. Organization Posting agents are discouraged from providing a default value for this header unless it is acceptable to all posters using those agents and unless it contains useful information (including some indication of the poster's physical environment). See section 4.1.2 for an even stronger discouragement for injecting agents. 3.1.1.8. Distribution Posting agents SHOULD NOT provide a default Distribution header without giving the poster an opportunity to override it. 3.1.1.9. Followup-To A Followup-To header SHOULD NOT be included if it just duplicates the Newsgroups header. At least one of its s SHOULD exist on the posting agent's host (since a well behaved poster ought not to be setting followups to a place that he cannot read). Cf. a similar rule regarding crossposting in section P-7.2.2. 3.1.1.10. User-Agent Comments in User-Agent headers should be restricted to information regarding the product named to their left, such as its full name or platform information, and should be concise. Use as an advertising C. H. Lindsey [Page 10] Usenet Best Practice March 2005 medium (in the mundane sense) is discouraged. 3.1.2. Construction of Bodies It was the fashion at one time to indicate underlining within body texts using Backspace, in the form of an underscore (US-ASCII 95), a backspace, and a character, repeated for each character that should be underlined. Posting agents MAY support this mechanism, although it is no longer so common for reading agents to process it. NOTE: using this precise method should ensure that reading agents that cannot display the text underlined will at least display it correctly in an un-underlined form. The formfeed character (US-ASCII 12) (which is sometimes referred to as the "spoiler character") MAY be used (see 3.3.3 for its effect on reading agents). In plain-text articles (those with no MIME headers, or those with a MIME Media Type of "text/plain") posting agents SHOULD endeavour to keep the length of body lines within some reasonable limit. The size of this limit is a matter of policy, the default being to keep within 79 characters at most, and preferably within 72 characters (to allow room for quoting in followups). Except where "format=flowed" is being used (3.1.2.2), the line breaks shown to the poster during editing SHOULD be exactly as they will appear in the posted article. NOTE: That policy limit (e.g. 72 or 79) should be expressed as a number of characters (as they will be displayed by a reading agent) rather than as the number of octets used to encode them. For use on occasions where established policy prescribes different line lengths (this usually arises in groups where the charset for the language used is best represented using double width characters) the preferred line length SHOULD be a configurable option. Posting agents MUST permit the poster to create individual lines longer than the default or configured length if he so insists (which may require the cessation of any automatic generation of flowed lines [RFC 3676] on a temporary basis), but it SHOULD be made apparent to the poster (e.g. by issuing a warning) that the article contains lines longer that the customary length. If the software uses an external editor, the editor called by default SHOULD be able to meet all the requirements of this section. 3.1.2.1. Signatures A "personal signature" is a short closing text automatically added to the end of articles by posting agents, identifying the poster and giving his network addresses, etc. Whenever a poster or posting agent appends such a signature to an article, it MUST be preceded with a delimiter line containing (only) two hyphens (US-ASCII 45) followed by one SP (US-ASCII 32). The signature is considered to extend from C. H. Lindsey [Page 11] Usenet Best Practice March 2005 the last occurrence of that delimiter up to the end of the article (or up to the end of the part in the case of a multipart MIME body). Posting agents SHOULD provide a facility to enable the poster to add such signatures, and SHOULD discourage (at least with a warning) signatures of excessive length (4 lines is a commonly accepted limit). 3.1.2.2. Usage of MIME When the Media Type is "text/plain", the recommendations and limits on line lengths set out above SHOULD be observed. Posting agents MAY use the "format=flowed" parameter of "text/plain" (and also the "DelSp=yes" if appropriate) defined in [RFC 3676] so as to allow suitably equipped reading agents to reformat flowed paragraphs to suit the width of their display areas. However, it must be understood that many reading agents do not support that feature, and therefore the physical length of all lines SHOULD be restricted to the default preferred length of 72 characters, rather than the 78 recommended in [RFC 3676]. However, single words longer than that length (and this specifically applies to URIs [RFC 3986]) which MUST NEVER be split across more than one physical line. Exceptionally, it is suggested in [RFC 3986] that URIs MAY contain embedded whitespace and hence be split across lines, but in practice many user agents fail to recognize URIs split in this way. Other forms of text, such as "text/html" SHOULD NOT be used except in groups where established policy or custom so allows (7.3). However, where they are so used then, for the benefit of readers who see it only in its transmitted form, the material SHOULD be "pretty-printed" (for example by restricting its line length as above and by keeping sequences which control its layout or style separate from the meaningful text). Likewise, Media Types requiring special processing for their display, notably the "binary" Media Types "image", "audio" and "video" (including also material encoded by the "uuencode" protocol), together with most "application" types, SHOULD NOT be used except in groups where established policy or custom so allows (7.3). Exceptionally, those application types defined in [RFC 1847] and [RFC 3156] for use within "multipart/signed" articles, and the type "application/pgp-keys" (or other similar types containing digital certificates) may be used freely. The Media Type "message/partial" is not recommended for textual articles because the Media Type, and in particular the charset, of the complete article cannot be determined by examination of the second and subsequent parts, and hence (except when they are written in pure US-ASCII) it is not possible to read them as separate articles (as by a reader who wanted to "browse ahead" to see whether it was worth his while to read the whole set). Moreover, for full compliance with [RFC 2046] it would be necessary to use the "quoted- printable" encoding to ensure the material was 7bit-safe. In any case, breaking such long texts into several parts is usually C. H. Lindsey [Page 12] Usenet Best Practice March 2005 unnecessary, since modern transport agents should have no difficulty in handling articles of arbitrary length. On the other hand, "message/partial" may be useful for binaries of excessive length, since reading of the individual parts on their own is not required and they would likely already be encoded in a manner that was 7bit-safe. The Media Type "message/rfc822" SHOULD be used where complete news articles or email messages are to be included within another article (P-5.2). The Media Type "message/external-body" could be appropriate for texts which it would be uneconomic (in view of the likely readership) to distribute to the entire network. The Media Types "multipart/mixed", "multipart/parallel" and "multipart/signed" may be used freely in news articles. However, except where policy or custom so allows, the Media Type "multipart/alternative" SHOULD NOT be used, on account of the extra bandwidth consumed and the difficulty of quoting in followups. The Media Type "multipart/digest" is commended for any article composed of multiple messages more conveniently viewed as separate entities, thus enabling reading agents to move rapidly between them. The "boundary" should be composed of 28 hyphens (US-ASCII 45) (which makes each boundary delimiter 30 hyphens, or 32 for the final one) so as to enable reading agents which currently support the digest usage described in [RFC 1153] to continue to operate correctly. NOTE: The various recommendations given above regarding the usage of particular Media Types apply also within the individual parts of these multiparts. A multipart is preceded and followed by some spare text (a preamble before the first boundary and an epilogue after the last one). It is clear from [RFC 2046] that these texts are not to be considered part of the official message and SHOULD NOT be displayed by reading agents. It is useful for the preamble to contain words such as "This is a multipart message in MIME format" for the benefit of older reading agents that do not support MIME, but the epilogue SHOULD be empty and, in particular, it SHOULD NOT be used to hold the signature (3.1.2.1), as is sometimes done. 3.1.2.3. Content-Transfer-Encoding The normal expectation is that the Content-Transfer-Encoding [RFC 2045] will be "8bit (or maybe "7bit" if the charset allows it). Other Content-Transfer-Encodings SHOULD NOT be used unless there are pressing reasons to do so. The following are examples of such situations where a Content- Transfer-Encoding of other that "8bit" may be necessary. C. H. Lindsey [Page 13] Usenet Best Practice March 2005 1. The content type implies that the content is (or may be) "8bit- unsafe"; i.e. it may contain octets equivalent to the US-ASCII characters CR or LF (other than in the combination CRLF) or NUL. In that case one of the Content-Transfer-Encodings "base64" or "quoted-printable" MUST be used, and reading agents MUST be able to handle both of them. NOTE: If a future extension to the MIME standards were to provide a more compact encoding of binary suited to transport over an 8bit channel, it could be considered as an alternative to base64 once it had gained widespread acceptance. 2. It is often the case that "application" Media Types are textual in nature, and intelligible to humans as well as to machines, and where this state can be recognized by the posting agent (either through knowledge of the particular application type or by testing) the material SHOULD NOT be treated as 8bit-unsafe; this has the added benefit, where the posting agent uses other than CRLF for line endings internally, of automatically ensuring that line endings are processed correctly during transport. If, on the other hand, the posting agent recognizes that the material is not textual, or cannot reasonably determine it to be so, then the material MUST be encoded as for 8bit-unsafe (however, in that case, it is the responsibility of the agent generating the material to ensure that lines endings, if any, are represented correctly). NOTE: All the application types defined by P-5, namely "application/news-transmission", "application/news-groupinfo" and "application/news-checkgroups" are textual, and indeed designed for human reading. 3. Although the "text" Media Types should normally be encoded as 8bit (or 7bit), if the character set specified by the "charset=" parameter can include the 3 disallowed octets, then the material MUST be encoded as for 8bit-unsafe. This is most likely to arise in the case of 16-bit character sets such as UTF-16 ([UNICODE 3.2] or [ISO/IEC 10646]). In addition, where it is known that the material is subsequently to be gatewayed from Netnews to Email P- 7.9), the encoding "quoted-printable" MAY be used (otherwise the gateway might have to re-encode it itself). 4. Some protocols REQUIRE the use of a particular Content-Transfer- Encoding. In particular, the authentication protocol based on OpenPGP defined in [RFC 3156] mandates the use of one of the encodings "quoted-printable" or "base64". Whilst posters might be tempted to risk the use of "8bit" or "7bit" encodings (and indeed the referenced standard recommends that signed messages using those encodings be accepted and interpreted), they should be warned that differences in the treatment of trailing whitespace between OpenPGP [RFC 2440] and earlier versions of PGP may render signatures written with the one unverifiable by the other; and, moreover, Usenet articles are very likely to include trailing C. H. Lindsey [Page 14] Usenet Best Practice March 2005 whitespace in the form of a personal signature (3.1.2.1). 5. The Media Type message/partial [RFC 2046] is required to use encoding "7bit" (the encapsulated complete message may itself use encoding "quoted-printable" or "base64", but that information is only conveyed along with the first of the partial parts). NOTE: Although there would actually be no problem using encoding "8bit" in a pure Netnews (as opposed to Email) environment, this document discourages the use of "message/partial" except for binary material, which will likely be encoded to pass through "7bit" in any case. It may be necessary to change the Content-Transfer-Encoding at gateways. For example in the case where such an encapsulated news article with the Media Type "message/rfc822" is to be transported by email and it has Content-Transfer-Encoding "8bit", the Content- Transfer-Encoding may need to be changed, although there may well be no problems in practice if the email transport supports 8BITMIME [RFC 2821]. 3.2. The Well-Behaved Followup Agent Usenet is primarily a medium for discussion. The majority of articles that are posted are in fact followups to previous articles, and exceedingly complex threads can develop. Therefore, it is essential that user agents provide facilities for followups that will enable such elongated discussions to proceed smoothly. 3.2.1. Construction of Headers The requirements on inserting and editing headers already set out in 3.1.1 still apply, and apply in particular to those headers for which the followup agent has set default values. 3.2.1.1. Subject The Subject of the followup is, by default, taken from that of the precursor, but users are able to override that default; indeed they are to be encouraged to do so whenever appropriate in order to avoid long threads which have wandered far from the topic with which they originated, but which still adhere to the original Subject. It has been a long standing practice, both on Usenet and in Email, to prepend the "back-reference" "Re: " ,. [RFC 2822] and P-7.6) to the Subject when preparing a followup, as an indication to the reader that this is a continuation of discussion of an earlier topic rather than the start of a new one. [USEPRO] does not require this practice, but permits it so long as it is not applied if such a back-reference is already present, and provided no string other that "Re: " is used for the purpose. C. H. Lindsey [Page 15] Usenet Best Practice March 2005 However, the practice is not without its difficulties: 1. Although the "Re" (which is an abbreviation for the Latin "In re", meaning "in the matter of", and not an abbreviation of "Reference" as is sometimes erroneously supposed) may be understood by English speakers, and indeed by speakers of most European Languages, its use in a newsgroup where articles were customarily written in Arabic, or Hindi, or Chinese would be less than helpful. 2. It requires extra processing (to ignore it) in some reading agents which choose to consult the Subject header when deciding the best order in which to present articles to the reader (see 3.3.2.1). This burden has to be weighed against the relatively small benefit of the indication provided directly to readers. 3. Sometimes, followup agents attempt to use translations of "Re: " into other languages, as in "Sv: " and "Antwort: ". But it is not practicable for those reading agents which take some special note of "Re: " also to take note of translations into an indeterminate number of other languages, and for this reason [USEPRO] does not permit such translations. 4. Even the presence of "Re: " at the start of a Subject may occasionally be misleading, because it might have been deliberately placed there by a poster rather than having been generated automatically by a followup agent. 5. And finally, there are philosophical arguments against features within an unstructured header which imply specific recognition and support within user agents (for reason already explained in 3.1.1.4). Indeed, the only reason why [USEPRO] permits this particular exception is on account of its current widespread usage. For these reasons, this document does not seek to perpetuate this practice, and indeed it might be better if its use were eventually to be phased out. Nevertheless, it is certain that it will continue to happen for some considerable period of time in newgroups where English is the primary language, simply on account of the inertia already behind it. For this reason, section 3.3.2.1 RECOMMENDS striping away any initial "Re: " when comparing Subjects. It would be wiser for any followup agents which can detect apparent non-standard back-references such as "Re(2): ", "Sv: ", etc. to refrain from prepending anything further, but other attempts to mend that problem are likely to do more harm than good. As well as the addition of "Re: ", the Subject header MAY be refolded (which MAY include collapsing/expanding whitespace to/from a single SP at any point where the folding is changed). However, it MUST NOT (except by deliberate act of the poster) be truncated, extended or changed in any other way that might cause a reading agent to deduce that the subject of a thread had changed. C. H. Lindsey [Page 16] Usenet Best Practice March 2005 [Bruce wants users users to be requested to confirm that they are happy with the default Subject as provided.] 3.2.1.1.1. Examples In the following examples, please note that only "Re: " has any official status (and hence may be utilized by reading agents). "was: " is a convention used by many English-speaking posters to signal a change in subject matter. Software can always recognize that such changes have occurred from the References header. Subject: Film at 11 Subject: Re: Film at 11 Subject: Godwin's law considered harmful (was: Film at 11) Subject: Godwin's law (was: Film at 11) Subject: Re: Godwin's law (was: Film at 11) Subject: Re: Godwin's law 3.2.1.2. Newsgroups The Newsgroups of the followup are, by default, taken from those of the precursor, or from the precursor's Followup-To header (P-7.6). But if the precursor's Followup-To header is set to "poster", the user MUST be warned if he attempts to force the followup to be posted. Followup agents SHOULD accept articles crossposted to newsgroups which do not exist on their local hosts (as opposed to posting agents, for which that requirement is only "MAY"). 3.2.1.3. Mail-Copies-To [This header may yet be removed from the drafts.] If the user attempts to email the poster as well as to followup, in the case where the Mail-Copies-To header is absent, and even more so when it is present and there is an explicit "nobody", contrary to the RECOMMENDATION in P-7.6, then the followup agent SHOULD issue a warning and ask for confirmation. NOTE: This header is only relevant when posting followups to Netnews articles, and is to be ignored when sending pure email replies to the poster, which are handled as prescribed under the Reply-To header. [USEPRO] RECOMMENDS that where a followup is also emailed to the poster, a suitable Posted-And-Mailed header be added. NOTE: In addition to the Posted-And-Mailed header, some followup agents also include within the body a mention that the article is both posted and mailed, for the benefit of reading agents that do not normally show that header. C. H. Lindsey [Page 17] Usenet Best Practice March 2005 3.2.1.4. References Followup agents SHOULD trim message identifiers out of a References header but SHOULD NOT do so until the number of message identifiers exceeds 21, at which time trimming SHOULD be done by removing sufficient identifiers starting with the second from the left so as to bring the total down to 21 (but the first message identifier MUST NOT be trimmed). However, it would be wrong to assume that References headers containing more than 21 message identifiers will not occur. [21 was the figure agreed by the WG, but I think it would be better to recommend an overall cutoff at 998 characters, because I have seen followup agents that systematically undo the folding carefully put their by precursors.] 3.2.2. Construction of Bodies Followup agents SHOULD follow policies already described for posting agents (3.1.2) regarding the length of lines when generating new text Exceptionally, they SHOULD NOT adjust the length of quoted lines (3.2.2.1) in followups unless they are able to reformat them in a consistent manner. 3.2.2.1. Quoting and Attributions It is customary for the body of a followup to commence with an "attribution" referring to the "precursor" and to "quote" any text copied verbatim from the precursor with a suitable prefix. Followup agents MUST facilitate the automatic incorporation of these things, even though they are not mandated by any standard, in a manner consistent with the conventions described below. These conventions for quotations and attributions describe widely used practices. Since much software will attempt to recognize and act upon them, questions of interoperability can arise, and so the words "MUST", "SHOULD", etc. are here to be understood as more than advisory. When the precursor had used the "format=flowed" parameter of text/plain [RFC 3676], and when the followup agent also supports "format-flowed", flowed paragraphs in the precursor (including any flowed lines within quotations in the precursor) SHOULD be reflowed. Thus, if all agents supported "format=flowed", no physical line, quoted ot not, would ever exceed the default (or policy) limit, except by the deliberate intent of the poster. Where the precursor was not flowed, its lines SHOULD initially be left alone when quoting, except that already quoted lines which appeared (from the presence of trailing SP) to have been flowed by one of the precursor's precursors MAY be treated as such. For use when "format-flowed" is not available, or when it fails to resolve the problem, the poster SHOULD be provided with a facility to rewrap lines of quoted text (but only lines all at the same quoting level). C. H. Lindsey [Page 18] Usenet Best Practice March 2005 When a followup agent incorporates the "precursor" as a quotation, it MUST be distinguished from the surrounding text in some way, and SHOULD be so dintinguished by prefacing each line of the quoted text (even if it is empty) with the character ">" (or perhaps with "> " in the case of a previously unquoted line). This will result in multiple levels of ">" when quoted content itself contains quoted content, and it will also facilitate the automatic analysis of articles. A facility SHOULD be provided for the poster to select less than the complete body of the precursor in the quotation. NOTE: Whilst posters should edit quoted context to trim it down to the minimum necessary, followup agents SHOULD NOT attempt to enforce this beyond issuing a warning (past attempts to do so have been found to be notably counter-productive). Care needs to be taken to use appropriate charsets in the outbound followup, and to record them in a Content-Type header. A followup to an article containing non-ASCII material is very likely to contain non-ASCII material itself. The followup agent SHOULD also precede the quoted content by an "attribution line" (however, readers are warned not to assume that they are accurate, especially within multiply nested quotations). The following convention for such lines is intended to facilitate their automatic recognition and processing by sophisticated reading agents. The attribution SHOULD contain the name and/or the email address of the precursor's poster, as in Joe D. Bloggs wrote: or Helmut Schmidt schrieb: The attribution MAY contain also a single (the one from which the followup is being made), the precursor's message identifier and/or the precursor's Date and Time. Any of these that are present, SHOULD precede the name and/or email address. However, the inclusion or not of such fields SHOULD always be under the control of the poster. To enable this line, and the message identifier and the email address within it, to be recognized (for example to enable suitable reading agents to retrieve the precursor or email its poster by clicking on them), the following conventions SHOULD be observed: o The precursor's message identifier SHOULD be enclosed within <...> or o The precursor's poster's email address SHOULD be enclosed within <...> o The various fields may be separated by arbitrary text and they may be folded in the same way as headers, but attributions SHOULD always be terminated by a ":" followed by CRLF. Further examples: On comp.foo in <1234@bar.example> on 24 Dec 2001 16:40:20 +0000, "Joe D. Bloggs" wrote: C. H. Lindsey [Page 19] Usenet Best Practice March 2005 Am 24. Dez 2002 schrieb Helmut Schmidt : 3.2.2.2. Signatures Followup agents, when incorporating quoted text from a precursor, SHOULD NOT include the signature in the quotation. 3.2.2.3. Usage of MIME Followup agents which quote parts of a precursor SHOULD initially include all parts of the precursor that were displayed inline, as if they were a single part. 3.3. The Well-Behaved Reading Agent 3.3.1. Display of Headers The set of headers displayed to the reader of each article is usually a configurable option, but it MUST by default include at least the following: o From header o Subject header o Newsgroups header o Followup-To header o Reply-To header and SHOULD include the following: o Distribution header o Posted-And-Mailed header o Summary header o Control header Moreover it MUST include a facility to "Display ALL headers" on demand. NOTE: There is no necessity to display anything at all for a header that is completely absent, and indeed some of the ones listed may seldom, if ever, be seen; they are included simply because it is essential for the reader to be aware of them on the rare occasions when they do occur. There is no requirement to display the headers in the exact format defined in [USEFOR] (for example, header-names may be displayed in some local language), but all the information in each header MUST be shown in some form. It may be necessary to provide a scrollbar or some equivalent means in order to display long headers (particularly long Subject headers); alternatively, long headers can be folded for display (although any folding provided by the original poster SHOULD be retained if it will fit in the display area). In any case, the display area SHOULD be able to accomodate up to 79 characters (or other established policy limit - see 7.3). Even if some header appears to be non-compliant with [USEFOR], it is better to display it exactly as received rather than not to display it at all. C. H. Lindsey [Page 20] Usenet Best Practice March 2005 Reading agents need to be prepared for ancient usages (and even non- compliance) which nevertheless still appear from time to time. In particular, the following is often seen: fred@foo.bar.example (Fred Bloggs) as opposed to "Fred Bloggs" . The former is a deprecated, but commonly encountered, usage and reading agents SHOULD take special note of such comments as indicating (e.g. in killfiles) the name of the person whose mailbox it is. 3.3.2. Presentation of Articles 3.3.2.1. Threading Reading agents SHOULD present the articles in each newsgroup in an order which ensures that the reader never sees a followup or reply to an article unless he has already had an opportunity to read the original. However, this may be easier said than done. Here are some methods commonly used to fulfil this aim; none of them works perfectly. 1. Present the articles in the order they were received at the local serving agent. However, articles propagated via different routes with different delays may well arrive out of order, so this may not be reliable. 2. Sort the articles into order according to their Date headers. This will usually be better than the first method, but relies on the clock and timezone settings in posting agents being approximately correct. And although it satisfies the minimal recommendation at the head of this section, it will likely result in totally separate threads of discussion being merged in an unhelpful order. 3. Sort the articles according to their Subject headers (or group them according to their Subject headers, with the groups being presented in order of the Date header of the first article in each group). Within a group with the same Subject, sort according to the Date header. This works tolerably well, but within a long discussion with many divergent subthreads, those subthreads are still merged in an unhelpful order. Moreover, it will occasionally bring together totally unrelated articles that just happen to have the same Subject by chance. 4. Construct a tree in which each article is within a sub-tree headed by each article mentioned in its References header, and present articles by a depth-first traversal of that tree, sorting the siblings within each branch according to their Date headers. This method is usually superior to the ones mentioned earlier, but it can go wrong for a number of reasons. C. H. Lindsey [Page 21] Usenet Best Practice March 2005 a) References headers are sometimes absent, or incomplete (and are even permitted to be trimmed when they get too long), and earlier articles in the threads may have expired off the local server. Nevertheless, with careful implementation, these problems are mostly surmountable. b) A poster may join an existing discussion (and clearly intend to do so by using the same Subject header, possibly with a prepended "Re: ") and yet his article might not be created as a followup to any specific precursor and hence would not have a References header. Hence it would be presented quite apart from the other (sub-)threads of that discussion. c) Conversely, the topic of some sub-thread might have diverged so far from the original topic of discussion that some poster decides to create a totally new Subject for his followup. Nevertheless, that followup, and the whole sub- thread which issues from it, will still be presented in the midst of the other sub-threads of the original discussion. 5. To counter these various deficiences, various hybrid schemes have been devised which take account of all three headers, References, Subject and Date, and these often succeed in providing a more pleasing presentation to the reader. However, different readers can be pleased in different ways, and so it is often the case that reading agents provide configurable options to choose between several methods. This document does not single out any particular method as "the best". They are all to be considered acceptable, and implementors are encouraged to experiment accordingly. Nevertheless, it is inevitable that some combination of Subjects and followups will eventually arise that defeats even the most sophisticated scheme. It must be noted, however, in the case of those methods which rely on the comparison of Subject headers, whether to detect equality or for sorting, that there are certain additional precautions that need to be taken, such as: a) [USEPRO] permits a back-reference "Re: " to be prepended (optionally) to a Subject when creating a followup. Therefore, that back-reference SHOULD be stripped away before performing any comparison of Subjects. On the other hand, "Re:" is the only back-reference permitted, and therefore it is not necessary for translations of "Re: " into other languages to be recognized (even though such translations are sometimes generated by non-compliant followup agents). Likewise, that "Re: " is case-sensitive, although non-compliant agents that generate "RE: " are common enough that it might be wiser to accept that form also. b) It is not unknown for non-compliant followup agents to truncate the Subject header. Some reading agents therefore truncate the Subject before making any comparison. Sometimes this makes things better; sometimes it makes them worse. C. H. Lindsey [Page 22] Usenet Best Practice March 2005 c) The use of s ([RFC 2047]) within Subject headers can give rise to different ways of encoding the same Subject. Therefore, such encoding SHOULD be undone before any comparison of Subject headers is made. It cannot even be assumed that the back- reference "Re: " is not within an . 3.3.2.2. Killfiles The reader SHOULD be provided with a list of articles available for reading, as set out more fully in section 3.3.2. Within the list of articles presented, the reader SHOULD be given the choice of seeing only articles that have not yet been read, or of seeing all articles available in the particular newsgroup. Moreover, articles crossposted to many newsgroups SHOULD be considered to have been read once they have been seen in any of those groups. There SHOULD be a facility (usually known as a "killfile") for filtering out classes of article that the reader does not wish to see. As a minimum, it SHOULD be possible to filter on the Subject header (preferably using regular expressions to describe the filter) and on the From header, but ideally it should be possible on any header (so, for example, it would be possible to filter out excessive crossposting, or crossposts to particular groups). Moreover, it SHOULD be possible to filter out all followups to some given article, by filtering on the References header or by building upon whatever threading facility has been provided. The filters included in a killfile may be permanent, or for a limited period. A corresponding set of filters to preselect articles for reading MAY also be provided. 3.3.2.3. Interpretation of Distributions A reading agent MAY be configured so that articles whose Distribution headers contained unwanted s do not get displayed (this would be in addition to any filtering on distributions already performed by relaying and serving agents - see P-7.3). This might well be achieved by an appropriate application of killfiles. 3.3.3. Interpretation of Bodies Implementors of reading agents need to be aware of ancient usages (and even non-compliance) which nevertheless still appear from time to time, and SHOULD endeavour to recognize them and display them appropriately. An example of this is the use of Backspace by posting agents in order to construct composite characters (e.g. by underlining) (3.1.2). Tab (US-ASCII 9) SHOULD be interpreted as sufficient horizontal white space to reach the next of a set of fixed positions (customarily set at every 8th character). Formfeed (US-ASCII 12) (which is sometimes referred to as the "spoiler character") signifies a point at which the reading agent SHOULD pause and await reader interaction before C. H. Lindsey [Page 23] Usenet Best Practice March 2005 displaying further text. Reading agents MUST provide facilities to display the whole of long lines up to the maximum of 998 characters (whether by wrapping or by providing horizontal scroll bars). However, cutting and pasting of wrapped lines SHOULD copy the original unwrapped line (i.e. all CRLFs not in the original should be discarded). It is common for reading agents to recognize the presence of URIs in the bodies of articles and to permit them to be clicked upon. In such cases, URIs which contain whitespace or are split over lines SHOULD be recognized, as is recommended in Appendix C of [RFC 3986]. 3.3.3.1. Usage of MIME Even though this document, or applicable policy, may discourage the use of some Media Types, all reading agents SHOULD make some realistic attempt to display at least all text types (especially where the Content-Disposition is "inline", even if all that can be done is to exhibit any formatting information as received (thus allowing a suitably knowledgeable reader to interpret it manually). The same applies to unrecognized charsets. It is not expected that reading agents will necessarily be able to present characters in all possible charsets (for example, a reading agent might be able to present only the ISO-8859-1 (Latin 1) characters [ISO 8859]), but where unpresentable characters arise they SHOULD be presented in some escaped notation, e.g. octal or hexadecimal (rather than as some single distinctive glyph or by exhibiting a warning). Reading agents MAY interpret image, audio and video Media Types inline, but few in fact do so (and the use of such Media Types is anyway deprecated in the absence of established policy to the contrary - see 3.1.2.2). Likewise, reading agents MAY interpret "application" types (and SHOULD at least display those types which are inherently textual in nature). However, there are security risks inherent in some application types, and even in "text/html" (P- 8.2.2). Even requiring the reader to click on some icon before proceeding with the application has proven notoriously ineffective against malicious attacks. The only safe alternative is to execute the application within a protected environment, or "sandbox", outside of which its side effects cannot occur. Of the multipart Media Types, reading agents MUST handle correctly at least "multipart/mixed" and "multipart/alternative". Other multipart types that are not implemented directly MUST be treated as "multipart/mixed". It is a regular practice for some Usenet articles to consist of digests of other messages or informative documents (usually known as "FAQ"s). These take the form of digests, as defined in [RFC 1153] or of the MIME Media Type "multipart/digest". Reading agents SHOULD recognize both of these formats and enable the individual digest items to be presented separately, as if they were separate articles. C. H. Lindsey [Page 24] Usenet Best Practice March 2005 Reading agents SHOULD honour any Content-Disposition header that is provided (in particular, they SHOULD display any part of a multipart for which the disposition is "inline", possibly distinguished from adjacent parts by some suitable separator). In the absence of such a header, the body of an article or any part of a multipart with Media Type "text" SHOULD be displayed inline. 3.4. The Well-Behaved Reply Agent First and foremost, a reply agent is an Email agent, and therfore its primary responsibility is to generate messages that are compliant with [RFC 2822] and other applicable Email standards and conventions. When a reply is to be emailed to the poster of an article, the reply agent MUST initially create a To header from the Reply-To or From header, as appropriate, of the precursor. NOTE: A distinction is to be made between when a reply is emailed to the poster of an article, and when such a reply is also posted during the course of generating a followup; in the latter case (but not the former) it is expected that any Mail- Copies-To header will have been observed. Note also that use of the Posted-And-Mailed header is appropriate whenever a message is both posted and emailed, whether or not this is done during the course of a formal followup. [Remove those NOTEs if those headers disappear.] Since addresses ending in ".invalid" are undeliverable, reply agents SHOULD warn any user attempting to reply to them and SHOULD NOT, in any case, attempt to deliver to them (since that would be pointless anyway). 3.5. User Interfaces The basic functionalities provided to the poster MUST include the following: o To Post a new article; o To Followup to a an existing article; o To Reply by email to the poster of an existing article (assuming, of course, that an email capability is available); and SHOULD include o To Cancel or Supersede articles previously posted by that same user (though this mechanism MUST NOT be available for other people's articles). The commands provided to the user to instigate these operations SHOULD, in the case of agents designed for English speakers at least, make use of the words "Post", "Followup", "Reply" and "Cancel" (or of their initial letters). It is NOT sufficient, particularly in the case of user agents intended for dual Email and Netnews use, simply to re-use the words for the corresponding Email operations (such as "Send" instead of "Post" or "Reply" instead of "Followup" or "Delete" C. H. Lindsey [Page 25] Usenet Best Practice March 2005 instead of "Cancel"). It SHOULD be immediately evident to an ordinary, untrained user which command to use for each of the operations. There MAY also be a separate facility encompassing "Followup and Reply", but in that case the provisions of any Mail-Copies-To header in the precursor (3.2.1.3) SHOULD be observed. It SHOULD be possible to switch between the Followup, Reply and "do both" commands, even after the article body has been edited. If, for whatever reason, there is only one command encompassing all of these operations, its default action MUST be to Reply (with no possibility to configure it otherwise). The user is responsible for providing at least the Newsgroups and Subject headers of the new article; in the case of Followups and Replies, it is usual for the user agent to provide defaults for these, but in all cases facilites for the user to edit these MUST be provided. In particular, it MUST be possible to specify multiple Newsgroups (the effect of which MUST be for them to be cross-posted rather than multi-posted), but the poster SHOULD be prevented (or at least warned) from excessive crossposting and SHOULD be offered the opportunity to set a Followup-To header if he insists on an excessive cross-post. Excessive numbers of newsgroups in a Followup-To header SHOULD be discouraged likewise. The user MUST be warned (and SHOULD be prevented) if he attempts to post an article whose body is empty, or which contains only quoted text. When the article is finally posted, the user MUST be warned (with severe wording) (and SHOULD be prevented) if he attempts to post the same article again, unless the system is able to report explicitly that the original posting had failed. See section 3.1 for further requirements and recommendations to be followed when posting articles. 4. The Well-Behaved Injecting Agent The injecting agent bears a responsibility towards the rest of the network for ensuring both that the articles it injects are compliant with [USEFOR], and that they conform with the general expectations of the rest of the network as to what constitutes "proper behaviour". [USEPRO] therefore imposes a duty on it to check articles for compliance rather thoroughly, but also a general duty to be responsive to complaints concerning the behaviour of those who are permitted to post through it. An injecting agent MAY take account of the policies of any newsgroups or hierarchies that the article is posted to (though it would be unreasonable to expect it to be aware of the policies and idiosyncrasies of all the hierarchies that it might encounter). C. H. Lindsey [Page 26] Usenet Best Practice March 2005 As part of their responsibility for the actions of their posters, injecting agents MAY cancel articles which they have previously injected (P-6.3). [That paragraph will move back to USEPRO if the rules governing who may issue cancels are moved back.] 4.1. Construction of Headers According to [USEPRO], an injecting agent MAY add other headers not already provided by the poster, but SHOULD NOT alter, delete, or reorder any existing header. However, the addition of non-mandatory headers by the injecting agent may alter the posting agent's preferred presentation of information. Insofar as the injecting agent needs to add headers not present in the proto-article (whether mandatory headers or otherwise), it MUST also behave as a well-behaved posting agent (3.1) with regard to those headers, including the insertion of appropriate folding so as to keep line lengths within the accepted limits. 4.1.1. Sender The generation of the Sender header is to be regarded as the responsibility of the posting agent. Although adding this header by injecting agents is not forbidden by [USEPRO] (though overwriting an existing one is), and although some agents indeed do so, this practice SHOULD be phased out. Exposing a sender's mailbox has privacy implications; where the main or only purpose for doing so is as tracing information, it is preferable to use instead one of the options provided for the Injection-Info header. 4.1.2. Organization The general discouragement from providing a default value for this header (3.1.1.7) applies even more to injecting agents. Where all the posters using a given injecting agent belong to a single organization, including the name of that organization as the default might well be reasonable. But if the injecting agent is merely providing a service to the general public, providing the name of the service provider as the default organization is mere advertising, and makes no allowance for the possibility that subscribers to the service who do not provide an Organization header of their own might prefer not to have one at all. 4.1.3. User-Agent There is provision in [USEPRO] for injecting agents to include (or augment if already present) a User-Agent header to identify the software that they use but, again, use as an advertising medium (in the mundane sense) is discouraged (cf. 3.1.1.10). C. H. Lindsey [Page 27] Usenet Best Practice March 2005 4.1.4. Injection-Info Various headers such as NNTP-Posting-[Host, Date, etc.] (which actually had nothing to do with NNTP) and X-trace have not been standardized in [USEFOR], but have instead been incporporated in the new Injection-Info header (whose syntax incorporates more room for future extension). Use of those headers SHOULD therefore be phased out. The purpose of the various parameters of the Injection-Info header is to enable the injecting agent to make assertions about the origin of the article, in fulfilment of its responsibilities towards the rest of the network. These assertions can then be utilized as follows: 1. To enable the administrator of the injecting agent to respond to complaints and queries concerning the article. For this purpose, the parameters included SHOULD be sufficient to enable the administrator to identify its true origin (which parameters are best suited to this purpose will vary with the nature of the injecting site and of its relationship to the posters who use it - there is no benefit in including parameters which contribute nothing to this aim). An administrator MAY, with those parameters where the syntax so allows, use cryptic notations interpretable only by himself if he considers it appropriate to protect the privacy of that origin. 2. To enable relaying, serving and reading agents to recognize articles from origins which they might wish to reject, divert, or otherwise handle specially, for reasons of site policy. 3. To enable the timely identification of spews of articles arising from a common origin. NOTE: Administrators of injecting agents can choose which selection of the various parameters best enables them to fulfil their responsibilities. Some of these parameters identify the source of the article explicitly whereas others do so indirectly, thus affording more privacy to posters who value their anonymity, but also making harder the tracking of malicious disruption of the network, especially so if the administrators choose not to cooperate. There is thus a balance to be struck between the needs of privacy on the one hand and the good order of Usenet on the other, and administrators need to be aware of this when formulating their policies. 5. The Well-Behaved Relaying Agent [USEPRO] establishes as a basic principle that relaying agents are not to alter articles in any way during transmission (except for those headers explicitly defined to be "variant"). This applies even if the article is perceived not to be conformant with [USEFOR]; in such a case it MUST either be passed on as it stands, or else it should be discarded altogether. In this way, it will be ensured that all copies of a given article, wherever they appear throughout C. H. Lindsey [Page 28] Usenet Best Practice March 2005 Usenet, will be identical. In particular, [USEPRO] requires serving and relaying agents to accept any syntactially correct in Newsgroups headers, even if it would violate one or more of the policy restrictions set out in section 7.2; i.e. the injecting agent is the last place for such checks to be made (3.1.1.5). Even if relaying agents do not, as a matter of local policy, intend to honour certain control messages, they MUST still propagate them in the normal manner. 5.1. The Path Header It is important to be able to determine where a given article was injected into Usenet and the route it took to reach each site at which it appears. Both the Path and Injection-Info headers have an important part to play in this. [USEPRO] therefore imposes a strong obligation on relaying agents to verify where articles reached them from and to record this information in the Path header. It is important that these new requirements in [USEPRO] be adopted by all injecting and relaying agents at the earliest opportunity. [However, the precise form of the Path header is still under discussion.] 5.1.1. Suggested Verification Methods It is preferable to verify the claimed against the source than to make routine use of the '?' with consequential wasteful double-entry Path additions. If the incoming article arrives through some TCP/IP protocol such as NNTP, the IP address of the source will be known, and will likely already have been checked against a list of known FQDNs, IP addresses, or other registered aliases that the receiving site has agreed to peer with. Since the source host may have several IP addresses, checking the claimed FQDN or IP address against the source IP, or finding a suitable FQDN to report with a '?' , may involve several DNS lookups, following CNAME chains as required. Note that any reverse DNS lookup that is involved needs to be confirmed by a forward one. If the incoming article arrives through some other protocol, such as UUCP, that protocol MUST include a means of verifying the source site. In UUCP implementations, commonly each incoming connection has a unique login name and password, and that login name (or some alias registered for it) would be expected as the . If none of these methods is applicable, relaying agents SHOULD require connecting hosts to identify themselves using some cryptographic authentication mechanism (e.g. [NNTP-AUTH]). C. H. Lindsey [Page 29] Usenet Best Practice March 2005 6. The Well-Behaved Serving Agent The principles set out in section 5 regarding not altering articles in any way apply equally to serving agents. The article as stored MUST be identical to the article as injected (variant headers excepted). Serving agents commonly insert an Xref header into articles that they store (P-7.4) so as to enable reading agents to avoid displaying that article in more than one of the groups that it is crossposted to, and to enable them to distinguish that particular serving agent from others known to them. It is convenient, though not required, for a serving agent to use the same in Xref headers as the it inserts into Path headers. 6.1. Control Messages Serving agents SHOULD deny group control messages not issued by the appropriate administrative agencies, and therefore SHOULD take such steps as are reasonably practicable to validate their authenticity, e.g. by checking digital signatures in cases where they are provided. 6.1.1. The 'newgroup' and 'mvgroup' Control Messages Serving agents SHOULD, insofar as they are conveniently able to, reject all 'newgroup' and 'mvgroup' messages not meeting the policies of the relevant hierarchy. Since the 'mvgroup' control message was a feature newly introduced by [USEPRO], the requirements set for it were relatively light, so as to facilitate a rapid deployment within Usenet (treating it as a 'newgroup' message is minimally conformant). Nevertheless, to achieve full benefit, serving agents need to arrange to service requests for access to the old group by providing access to the new. [USEPRO] states how that MAY be done, but this documents goes further; serving agents SHOULD be upgraded to do so at the earliest opportunity. 6.1.2. Cancel Messages A cancel message may be issued in the following circumstances. 1. The poster of an article (or, more specifically, any entity mentioned in the From header or the Sender header, whether or not that entity was the actual poster) is always entitled to issue a cancel message for that article, and serving agents SHOULD honour such requests. Posting agents SHOULD facilitate the issuing of cancel messages by posters fulfilling these criteria. 2. The agent which injected the article onto the network (more specifically, the entity identified by the in front of the leftmost '%' delimiter in the Path header or in the Injection-Info header and, where appropriate, the moderator (more specifically, any entity mentioned in the Approved header) is always entitled to issue a cancel message for that article, and C. H. Lindsey [Page 30] Usenet Best Practice March 2005 serving agents SHOULD honour such requests. 3. Other entities MAY be entitled to issue a cancel message for that article, in circumstances where established policy for any hierarchy or group in the Newsgroups header, or established custom within Usenet, so allows (such policies and customs are not defined by this document). Such cancel messages MUST include an Approved header identifying the responsible entity. Serving agents MAY honour such requests, but SHOULD first take steps to verify their appropriateness. [There was one request to move that back into [USEPRO]. Any one else?] 7. The Well-Behaved Hierarchy Administrator The term "hierarchy administrator" means any agency responsible for administration of a (sub-)hierarchy (1.1), or in the absence of such an agency, the custom and usage generally accepted for that (sub-)hierarchy, insofar as such can be determined. 7.1. Control Messages In those hierarchies where appropriate administrative agencies exist (see 1.1), group control messages SHOULD NOT be issued except as authorized by those agencies, in which case the administrator needs to establish just what person (or other entity) is to be permitted to issue those messages; moreover he should at the same time establish s digital signature key to be used for authenticating them (P-6.1), and finally he SHOULD ensure that this information is widely promulgated for use by serving agents worldwide. Those issuing control messages should be aware that the former practice of using a Subject starting with "cmsg" in lieu of a control message is now deprecated (3.1.1.4) although they MAY continue to use that convention in addition to using a proper Control leader. The in 'newgroup' control messages (and the second <(new-)newsgroup-name> in 'mvgroup' control messages) SHOULD conform to whatever policies have been established by the administrator (7.2). Although, in accordance with [RFC 2822], a (as found in both 'newgroup' and 'checkgroups' messages) could have a maximum length of 998 octets, as a matter of policy a far lower limit, expressed in characters, SHOULD be set. The current convention is to limit its length so that the , the HTAB(s) (interpreted as 8-character tabs that takes one at least to column 24) and the (excluding any ) fit into 79 characters. This document does not seek to enforce any such rule, but any decision to extend it should be made as a specific decision for the hierarchy. Reading agents SHOULD therefore enable a of any length to be displayed, e.g. by wrapping it as required. C. H. Lindsey [Page 31] Usenet Best Practice March 2005 7.2. Naming of Newsgroups Because group control messages can only be issued on the authority of the responsible agency, it follows that the agency has complete control of the names of the newsgroups to be considered as valid members of that (sub-)hierarchy. Consequently, it needs to establish policies for the format of the s it intends to permit; these policies can be both technical and aesthetic. [USEFOR] provides by default the following technical restrictions upon which hierarchy administrators can then build, and which SHOULD in any case be applied in hierarchies not subject to such management. [Well, it doesn't provide them yet, but it needs to.] NOTE: These restrictions are intended to reflect existing practice and are intended both to avoid certain technical difficulties and to avoid unnecessary confusion. They may well change over time in the light of future experience. 1. Uppercase letters are forbidden. NOTE: Traditionally, s have been written in lowercase. However, posting agents SHOULD NOT convert uppercase characters to the corresponding lowercase forms except under the explicit instructions of the poster. 2. A is forbidden to consist entirely of digits. NOTE: This requirement was in [RFC 1036] but nevertheless several such groups have appeared in practice and implementors should be prepared for them. A common implementation technique uses each as the name of a directory and uses numeric filenames for each article within a group. Such an implementation needs to be careful when this could cause a clash (e.g. between article 123 of group xxx.yyy and the directory for group xxx.yyy.123). Once the latter group exists, the subsequent creation of the former would be precluded for all time. 3. A is limited to 30 s and a to 66 s (counting also the '.'s separating the s). NOTE: Whilst there is no longer any technical reason to limit the length of a (formerly, it was limited to 14 octets) nor of a , it should be noted that these names are also used in the where another overall policy limit applies (7.1) and, moreover, excessively long names can be exceedingly inconvenient in practical use. The 66 limit on s ensures that a Followup-To Header with such a name will still fit within 79 characters overall. C. H. Lindsey [Page 32] Usenet Best Practice March 2005 In the event that some future extension to [USEFOR] allows internationalized s including non-ASCII characters, there will be further technical issues to be taken into account, including: 4. What non-ASCII punctuations and other symbols are to be allowed. 5. What normalizations need to be observed to overcome multiple ways of constructing glyphs with identical or similar appearance. 6. Restrictions on mixing alphabets within one of a name (so as to avoid confusion between, for example, Latin A and Greek Alpha, and similar confusions between some Latin and Cyrillic letters - though retaining the restriction on uppercase letters will mitigate these problems somewhat). Aesthetic reasons for policy limitations are likely to include insistence upon a clear hierarchical structure (the tree of names needs to be neither too broad nor too deep), that the s of s are meaningful in the context of the language(s) expected to be used, that frivolous names are avoided, and that abbreviations are likely to be recognized by the intended readership. [David Wright has a FAQ on hierarchical naming which might give us some help.] 7.3. Format of Bodies Hierarchy administrators MAY declare, as a matter of policy, which languages and charsets are to be considered appropriate within their hierarchies (or within particular groups). Whereas in principle, any character set may be specified in the "charset=" parameter of a Media Type, readers cannot be expected to possess agents capable of displaying characters not needed for those chosen languages, hence administrators SHOULD choose charsets accordingly and/or limit the planes to be allowed within charsets based on [UNICODE 3.2], such UTF-8. This document has already provided (3.1.2,3.2.2) for a default limit on the length of lines (79, or preferably 72) within plain-text articles, and hierarchy administrators MAY change this, as a matter of policy (though there would seems to be little reason to do so except where the intended language and charsets so dictate - e.g. because of a need to use double-width characters). This document has also limited (3.1.2.2), by default, the Media types that may be used in articles to "text/plain". Hierarchy administrators MAY relax this, as a matter of policy (by allowing, for example, "text/http", the "binary" types "audio", "image" and "video", and selected "application" types), and they MAY similarly regulate the use of "message/partial". Hierarchy administrators MAY also impose other restrictions relevant to the nature of their hierarchy, such as limits on the overall size of articles, on the length of signatures, the topics to be discussed C. H. Lindsey [Page 33] Usenet Best Practice March 2005 (usually set out in a charter for each newsgroup) and the extent of advertising to be permitted. 7.4. Promulgation The policies established by each hierarchy administrator SHOULD be publicised (in the form of guidelines, FAQs and charters) in suitable *.announce groups within each hierarchy, and also on suitable web sites (although it should be understood that Usenet exists as a separate entity from the World Wide Web, and it would be wrong to assume that every Usenet user has web - or even email - access). NOTE: The promulgation of policies is one thing; the enforcement of policies is quite another. With the exception of s, for which technical controls exist, policy enforcement is a matter of peer pressure (which, when consistently applied, can be remarkably effective), possibly with the aid of the administrators of injecting agents through their ability, and even duty (4), to apply disciplinary pressure to their users. 8. The Well-Behaved Moderator A moderator MAY inform the poster if an article is accepted, and he SHOULD inform the poster if it is rejected (except where it appears to be a deliberate and malicious attempt to disrupt). A moderator SHOULD NOT (absent any established and widely promulgated policy to the contrary) remove any from the Newsgroups header, nor split an article into two versions with disjoint Newsgroups headers. These are matters more usually within the prerogative of the poster; moreover splitting can lead to fragmentation of threads. 9. The Well-Behaved Poster [What you see here is but the tip of a very large iceberg, being the particular advice to posters which has been transported from the earlier drafts of [ARTICLE]. There is much more that could, and probably should, be said. However, it would first be advsisable to study [RFC 1855] and to decide whether we want to adopt and adapt what is already stated there, even to the extent of obsoleting it entirely.] 9.1. Construction of Headers Posters SHOULD NOT include redundant headers such as Reply-To and Followup-To that merely duplicate the defaults (c.f. 3.1.1.6 and 3.1.1.9). C. H. Lindsey [Page 34] Usenet Best Practice March 2005 9.1.1. From Whether or not a valid address can subsequently be extracted from an address ending in ".invalid" falls outside the scope of this document but, obviously, posters wishing to disguise their address should not suppose that just adding ".invalid" to it will achieve that effect. 9.1.2. Summary The summary should be terse. Posters SHOULD avoid trying to cram their entire article into the headers; even the simplest query usually benefits from a sentence or two of elaboration and context, and not all reading agents display all headers. On the other hand the summary should give more detail than the Subject. 9.1.3. Expires An Expires header should only be used in an article if the requested expiry time is earlier or later than the time typically to be expected for such articles (for example, a notice for a meeting to be held tomorrow on the one hand, or a FAQ which should remain on servers until its next issue on the other). Local policy for each serving agent will dictate whether and when this header is obeyed and posters SHOULD NOT depend on it being completely followed. 9.2. Construction of Bodies Posters SHOULD avoid using control characters and escape sequences except for tab (US-ASCII 9), formfeed (US-ASCII 12) and, possibly, backspace (US-ASCII 8), for reasons already explained in section 3.3.3. NOTE: Backspace was historically used for underlining, done by an underscore (US-ASCII 95), a backspace, and a character, repeated for each character that should be underlined. Posters are warned that underlining is not available on all output devices or supported by all reading agents and is best not relied on for essential meaning. When preparing followups, posters SHOULD edit quoted context to trim it down to the minimum necessary. Posters SHOULD observe the policies established for each hierarchy (7.3) or, in the absence of such policies, to the defaults set out in this document, as regards: o The languages and charsets to be used; o The length of lines; o The acceptability of various Media Types, and especially of "text/html" and the "binary" types; o Conventions regarding the advisability of using "message/partial"; o Limits on the overall size of articles; o The topics to discussed in each group, as determined by its charter; C. H. Lindsey [Page 35] Usenet Best Practice March 2005 o The acceptability of advertising. 10. References [ARTICLE] Charles H. Lindsey, "News Article Format and Transmission", draft-ietf-usefor-article-format-*.txt. [ISO 8859] International Standard - Information Processing - 8-bit Single-Byte Coded Graphic Character Sets. Part 1: Latin alphabet No. 1, ISO 8859-1, 1987. Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. [ISO/IEC 10646] "International Standard - Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO/IEC 10646- 1:2000, 2000. [MALAMUD] "Labels in Subject Headers Considered Ineffective At Best", draft-malamud-subject-line-*.txt. [NNTP-AUTH] J. Vinocur, K. Murchison, and C. Newman, "NNTP Extension for Authentication", draft-ietf-nntpext-authinfo-*.txt. [RFC 1036] M. Horton and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987. [RFC 1153] F. Wancho, "Digest Message Format", RFC 1153, April 1990. [RFC 1847] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC 1855] S. Hambridge, "Netiquette Guidelines", RFC 1855, October 1995. [RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC 2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC 2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. C. H. Lindsey [Page 36] Usenet Best Practice March 2005 [RFC 2396] T. Berners-Lee, R. Fielding, U.C. Irvine, and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC 2440] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999. [RFC 2821] John C. Klensin and Dawn P. Mann, "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC 2822] P. Resnick, "Internet Message Format", RFC 2822, April 2001. [RFC 3156] M. Elkins, D. Del Torto, R. Levien, and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [RFC 3676] R. Gellens, "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004. [RFC 3986] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005. [UNICODE 3.2] The Unicode Consortium, "The Unicode Standard - Version 3.2, being an amendment to [UNICODE 3.1]", Unicode Standard Annex #28 , 2002. [USEFOR] K. Murchison et al, "News Article Format", draft-ietf- usefor-usefor-*.txt. [USEPRO] C. H. Lindsey, "News Article Architecture and Protocols", draft-ietf-usefor-usepro-*.txt. 11. Acknowledgements 12. Contact Address Editor Charles. H. Lindsey 5 Clerewood Avenue Heald Green Cheadle Cheshire SK8 3JU United Kingdom Phone: +44 161 436 6131 Email: chl@clw.cs.man.ac.uk C. H. Lindsey [Page 37] Usenet Best Practice March 2005 [ Working group chair Alexey Melnikov ] Comments on this draft should preferably be sent to the mailing list of the Usenet Format Working Group at ietf-usefor@imc.org. Appendix A - Notices Intellectual Property 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. Full 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. 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. C. H. Lindsey [Page 38]