idnits 2.17.1 draft-ietf-drums-replyto-meaning-00.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-04-25) 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 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 1997) is 9658 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) == Unused Reference: 'IMAIL' is defined on line 283, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. 'IMAIL') (Obsoleted by RFC 2822) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Reply-To-Meaning Proposal Innosoft 4 Document: draft-ietf-drums-replyto-meaning-00.txt November 1997 6 Reply-To-Meaning Proposal 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Introduction 29 This is a candidate proposal for one way which the problems with 30 the reply-to header in email could be resolved. Under no 31 circumstances should this be implemented as it is only a candidate 32 for a solution and no decision has yet been made. This proposal 33 distinguishes the different incompatible uses of the Reply-To 34 header with a new Reply-To-Meaning header. This has the advantage 35 of being relatively simple, not invalidating most current practices 36 and allowing mail user agents to present more predictable user 37 interfaces. 39 1. Conventions Used in this Document 41 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 42 NOT", and "MAY" in this document are to be interpreted as described 43 in "Key words for use in RFCs to Indicate Requirement Levels" 44 [KEYWORDS]. 46 2. Reply-To Current Practice 48 The Reply-To header is currently used for the following purposes: 50 (1) The author/sender can suggest a complete list of addresses 51 which should receive any reply (e.g., a review committee). 53 (2) The author/sender can recommend an address or addresses to use 54 instead of the "from" address for replies. 56 (3) The author/sender can post to multiple mailing lists and 57 suggest group replies go to only one of them. 59 (4) When the author/sender is subscribed to a mailing list, he can 60 suggest that he doesn't want two copies of group replies to 61 messages he posts to the list. 63 (5) A mailing list can suggest that the list is a discussion list 64 and replies should be sent just to the list by default. 66 Many current MUAs have undesirable results with one or more of 67 these uses. However, if the MUA knew the intent when the reply-to 68 header was added, the undesirable results can be eliminated. 70 Alternative proposals to this one have suggested that the meaning 71 of Reply-To be restricted to (1), (2) or (3) and that additional 72 headers would be added for any of the other uses deemed important. 74 3. Reply-To-Meaning Header 76 The Reply-To-Meaning header is used to indicate the intent when the 77 Reply-To header was added. It has five values: "any", "private", 78 "group", "non-list" or "list." 80 any 81 The "any" meaning indicates that the author/sender added the 82 reply-to header as a suggested target for any reply (e.g., use 83 1 above). 85 private 86 The "private" meaning indicates that the author/sender added 87 to Reply-To header as an address for private replies to use 88 instead of the "From" header (e.g., use 2 above). 90 group 91 The "group" meaning indicates that the author/sender added the 92 Reply-To header as a complete list of addresses where group 93 replies should be sent (e.g., use 3 and/or 4 above). 95 non-list 96 The "non-list" meaning simply indicates that the author/sender 97 added the reply-to header (e.g., any one of 1-4 above). 99 list 100 The "list" meaning indicates that the Reply-To header was 101 added by a mailing list (e.g., use 5 above). 103 The formal syntax using ABNF from message format standard: 105 reply-to-meaning-header = "Reply-To-Meaning:" 1*FWS meaning-keyword 107 meaning-keyword = "any" / "private" / "group" / "non-list" / "list" 108 / extension-token 110 Unknown extension-tokens are treated as equivalent to no Reply-To- 111 Meaning header. Meaning keywords are interpreted in a 112 case-insensitive fashion. 114 4. Examples 116 Here are a series of examples of various uses: 118 From: Chris Newman 119 To: DRUMS mailing list 120 Subject: I'll collect straw-poll responses 121 Reply-To: Chris Newman 122 Reply-To-Meaning: any 124 In this mailing list posting, the author has asked that all replies 125 go to his straw-poll address. 127 From: Chris Newman 128 To: DRUMS mailing list 129 Reply-To: Chris's DRUMS inbox 130 Reply-To-Meaning: private 132 This author has a special address for private replies to his 133 postings on this list. This might also be used by a someone with a 134 secretary to review incoming responses. 136 From: Chris Newman 137 To: DRUMS mailing list 138 Reply-To: DRUMS mailing list 139 Reply-To-Meaning: group 141 This author doesn't want private copies of replies sent to the 142 list. 144 From: Chris Newman 145 To: DRUMS mailing list 146 Reply-To: DRUMS mailing list 147 Reply-To-Meaning: non-list 149 This indicates that the author explicitly added the Reply-To header 150 and the mailing list didn't change it. Although meaning (2) can't 151 be distinguished from meanings (1), (3) or (4), this does give 152 assurance that the author will see replies if the Reply-To header 153 is used without the From header. 155 From: Chris Newman 156 To: DRUMS mailing list 157 Reply-To: DRUMS mailing list 158 Reply-To-Meaning: list 160 This indicates that the list is a discussion list and it added the 161 Reply-To header to direct generic replies to the list. There is no 162 assurance that the author is subscribed to the list. In addition, 163 if the author included additional lists or people in a CC header, 164 they probably won't see replies directed only to the Reply-To 165 header. 167 5. Interpretation in Common Reply Functions 169 Many user agents provide more than one function to construct a 170 default set of target addresses for replies. This section suggests 171 how Reply-To-Meaning can be interpreted by certain common reply 172 functions: 174 Private Reply 175 A private reply is intended for the author(s) or the 176 delegate(s) of the author(s). When there is no Reply-To 177 header, or the Reply-To-Meaning is "group" or "list" then the 178 From header is used as the default set of target addresses for 179 replies. When Reply-To-Meaning is "private", then the Reply- 180 To header is used instead of the From header. If there is no 181 Reply-To-Meaning, or Reply-To-Meaning is "any" or "non-list" 182 then the MUA can offer the user a choice between using the 183 Reply-To or "From" header. 185 NOTE: if a Reply-To header was constructed with intent (1) or 186 (3)-(5), and was used without warning in a private reply, then 187 the reply could be directed to more recipients than the user 188 intended and cause serious embarassment or other undesirable 189 consequences. 191 Group Reply (also known as Reply All) 192 A group reply is intended for all authors and recipients of 193 the original message. When there is no Reply-To header, it is 194 constructed by using the contents of the original From, To and 195 CC header as the default set of reply targets (with duplicates 196 and possibly the replying user's address removed). When 197 Reply-To-Meaning is "any" or "group" the Reply-To address is 198 used as the complete set of reply targets. When Reply-To- 199 Meaning is "private" or "non-list", the Reply-To, To and CC 200 addresses are used as the default set of targets. Otherwise, 201 Reply-To, To, CC and From are all used as the default set of 202 targets. 204 NOTE: This can result in undesired duplicate copies of a reply 205 when a list address is included which the original author was 206 subscribed to and Reply-To-Meaning is not added. However, 207 this definition assumes duplicate copies are less harmful than 208 risking the omission of the original author. With the 209 opposite assumption, if Reply-To-Meaning was "list" or absent 210 only the Reply-To, To and CC headers would be used. 212 Generic Reply / Gateway 213 A generic reply is simply a desire to reply to the set of 214 recipients most likely to want the reply. It does not specify 215 a preference for a "private" or "group" reply. This is also 216 the set of addresses that gateways are forced to convey when 217 the target mail environment has a single reply-target address 218 list. This is defined as the Reply-To header, if present, and 219 the From header otherwise. User agents which offer this 220 function should draw attention to the Reply-To header when 221 it's present. Reply-To-Meaning has no impact on this 222 function. 224 6. Mailing List Rules 226 When a mailing list receives a message it MUST NOT alter an 227 existing Reply-To header. If there is a Reply-To header and no 228 Reply-To-Meaning header, the list SHOULD add a "Reply-To-Meaning: 229 non-list" header. 231 Mailing lists SHOULD NOT add a Reply-To header when one is not 232 present. However, if they do they MUST also add "Reply-To-Meaning: 233 list." In the short term it is particularly undesirable to do 234 this, as it can cause problems for user agents which don't 235 understand the Reply-To-Meaning header. Such user agents may make 236 it difficult to construct private replies. In addition, if a 237 message is posted to several lists, generic replies and some older 238 user agents may fragment the conversation to a single list. 240 7. Pro/Con Analysis 242 Pros: 244 * This is a fairly simple proposal 246 * This does not invalidate most current practices, which minimizes 247 deployment problems. 249 * This won't cause problems for legacy gateways which will never be 250 upgraded. 252 Cons: 254 * This is an ugly design because it leaves Reply-To overloaded. 256 * Legacy mailing lists which change existing reply-to headers will 257 really mess things up. 259 * This opens up the possibility of permitting lists to add Reply-To 260 headers which could cause short term problems as discussed in 261 section 6. 263 * There is no way to redirect private replies to a non-author and 264 group replies to a different target in the same message. 266 8. Security Considerations 268 There are a number of cases where a private reply could be 269 misdirected to a large group of people. Although this proposal 270 reduces the chances of this happening, it remains important for 271 MUAs to draw attention to Reply-To headers and reply targets in 272 most situations. 274 9. Open Issues with this Proposal 275 The "any" meaning will force current user agents to change their 276 interfaces for private replies when "any" is present. This will 277 probably be controversial. 279 The severity of the pros and cons is probably controversial. 281 10. References 283 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text 284 Messages", RFC 822, University of Delaware, August 1982. 286 288 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 289 Requirement Levels", RFC 2119, Harvard University, March 1997. 291 293 11. Author's Address 295 Chris Newman 296 Innosoft International, Inc. 297 1050 Lakes Drive 298 West Covina, CA 91790 USA 300 Email: chris.newman@innosoft.com