idnits 2.17.1 draft-ietf-usefor-message-id-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 225 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1036 (ref. 'NEWS') (Obsoleted by RFC 5536, RFC 5537) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 1750 (ref. 'PRNG') (Obsoleted by RFC 4086) Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Matt Curtin 2 draft-ietf-usefor-message-id-01.txt The Ohio State University 3 Category-to-be: Informational Jamie Zawinski 4 Netscape Communications 6 July 1998 7 Expires: Six Months from above date 9 Recommendations for generating Message IDs 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 26 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 27 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This draft provides recommendations on how to generate globally unique 32 Message IDs in client software. 34 Table of Contents 36 1. Introduction 37 2. Message-ID formatting 38 3. Message-ID generation 39 3.1 "Domain part" 40 3.2 "Local part" 41 3.2.1 Sequence number 42 3.2.2 Using a pseudorandom number generator 43 3.2.3 Using a hash 44 3.3 Bringing it all together 45 4. Acknowledgments 46 5. References 47 6. Authors' addresses 49 1. Introduction 51 Message-ID headers are used to uniquely identify Internet messages. 52 Having a unique identifier for each message has many benefits, 53 including ease in the following of threads and intelligent scoring of 54 messages based on threads to which they belong. 56 It has been suggested that it is impossible for client software to be 57 able to generate globally-unique Message-IDs. We believe this to be 58 incorrect, and herein to offer suggestions for generating unique 59 Message-IDs. 61 2. Message-ID formatting 63 As defined in [NEWS], a message ID consists of two parts, a local part 64 and a domain, separated by an at-sign and enclosed in angle brackets: 66 message-id = "<" local-part "@" domain ">" 68 Practically, news message IDs are a restricted subset of mail message 69 IDs. In particular, no existing news software copes properly with mail 70 quoting conventions within the local part, so software generating a 71 Message-ID would be well-advised to avoid this pitfall. 73 It is also noted that some buggy software considers message IDs 74 completely case-insensitive, in violation of the standards. It is 75 therefore advised that one not generate IDs such that two IDs so 76 generated can differ only in character case. 78 3. Message-ID generation 80 As shown above, the Message-ID is made up of two sections. We'll 81 consider each seperately. 83 3.1. "Domain part" 85 On many client systems, it is not always possible to get the 86 fully-qualified domain name (FQDN) of the local host. In that 87 situation, a reasonable fallback course of action would be to use the 88 domain-part of the user's return address. (Use of an unqualified 89 hostname for the domain part of the Message-ID header would be 90 foolish, and should never be done.) 92 Using the domain-part of the user's return address makes the 93 generation of the "local part" be more important; in particular, it 94 means that a process ID is probably not sufficient. 96 3.2. "Local part" 98 The most popular method of generating local parts is to use the date and 99 time, plus some way of distinguishing between simultaneous postings on 100 the same host (e.g. a process number), and encode them in a suitably- 101 restricted alphabet. 103 A number of approaches here are possible. Each has its advantages and 104 drawbacks. The importance of the local part's uniqueness increases 105 with the frequency of messages being generated in a given domain. 106 Using several of these methods together will produce a Message-ID that 107 is longer, but significantly less likely to collide. 109 3.2.1. Sequence number 111 An older but now less-popular alternative is to use a sequence number, 112 incremented each time the host generates a new message ID; this is 113 workable for servers, but requires careful design to cope properly 114 with simultaneous posting attempts, and is not as robust in the 115 presence of crashes and other malfunctions. For client Message-ID 116 generation, particularly on hosts where the exact FQDN cannot be 117 obtained, or is subject to change, this might not even be workable. 119 3.2.2. Using a psuedorandom number generator 121 One could take 64 bits from a good, well-seeded pseudorandom number 122 generator [PRNG] in order to significantly increase the uniqueness of 123 the Message-ID. The advantage of this method is that it is fast and 124 generally effective. The disadvantage is that in a perfect random 125 number generation scheme, the possibility of getting the same number 126 twice in a row is exactly the same probability as getting any two 127 numbers. 129 3.2.3. Using a hash 131 Another approach would be to generate a hash of the message and use 132 that after the timestamp. If this is done well, this can also 133 significantly reduce the opportunity for collision, and will generate 134 a value that is relatively unique. Note that, in practice, this is 135 more difficult than it sounds. It is recommended that a 136 cryptographically secure hash function [SHA1, MD5] be used, as 137 others, such as CRC, are likely to have higher instances of collision. 139 3.3. Bringing it all together 141 In summary, the approaches to generating a Message-ID that we'll 142 consider here are in the following format: 144 1 Append "<". 146 2 Get the current time in the highest resolution to which you have 147 access (at least seconds, though most systems will give you 148 milliseconds) and generate a timestamp in the format 149 yyyymmddHHMMSS.ss; 151 3 Generate additional data to prevent Message-ID collision on two 152 messages processed by the same host at precisely the same 153 moment. (See section 3.2.) Convert these two numbers to base 36 154 (0-9 and A-Z), and write the first number, then additional parts, 155 each section seperated by a ".", and an "@". 157 5 Append the FQDN of the local host, or the host name in the user's 158 return address. 160 6 Append ">". 162 4. Acknowledgments 164 This document is partially derived from an earlier, unrelated draft by 165 Henry Spencer. 167 5. References 169 Ref. Author, title IETF status (June 1998) 170 ---------------------- 171 --- ------------- 173 [NEWS] M.R. Horton, R. Adams: "Standard Non-standard (but still 174 for interchange of USENET widely used as a de-facto 175 messages", RFC 1036, December standard). 176 1987. 178 [SHA1] National Institute of Standards 179 and Technology (NIST), "Announcement 180 of Weakness in the Secure Hash 181 Standard", May 1994. (Update of 182 FIPS 180: "Secure Hash Standard".) 184 [MD5] R. Rivest: "The MD5 Message-Digest Informational (but 185 Algorithm", RFC 1321, April 1992. (widely used as a 186 de-facto standard). 188 [PRNG] D. Eastlake, 3rd, S. Crocker, Informational. 189 J. Schiller: "Randomness 190 Recommendations for Security", 191 RFC 1750, December 1994. 193 6. Authors' Addresses 195 Matt Curtin 196 The Ohio State University 197 791 Dreese Laboratories 198 2015 Neil Ave 199 Columbus OH 43210 200 +1 614 292 7352 201 cmcurtin@cis.ohio-state.edu 203 Jamie Zawinski 204 Netscape Communications Corporation 205 501 East Middlefield Road 206 Mountain View, CA 94043 207 (650) 937-2620 208 jwz@netscape.com