idnits 2.17.1 draft-koch-subject-tags-considered-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 298. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 17, 2004) is 7094 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) == Missing Reference: 'RFC 2919' is mentioned on line 212, but not defined == Unused Reference: 'RFC2119' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'RFC2821' is defined on line 249, but no explicit reference was found in the text == Unused Reference: 'RFC2822' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 261, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Koch 2 Internet-Draft Universitaet Bielefeld 3 Expires: May 18, 2005 November 17, 2004 5 Subject: [tags] Considered Harmful 6 draft-koch-subject-tags-considered-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 18, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 Various mailing lists modify the Subject: header field of messages 42 sent to the list to contain a kind of identifier enclosed in square 43 brackets. Every now and then this "feature" is also requested for 44 the main IETF list. This document collects pros and cons of this 45 approach, tries to identify the real issue and will, in a later 46 stage, try to give a recommendation. 48 Table of Contents 50 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1 Space . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2 Position . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.3 Crosspostings . . . . . . . . . . . . . . . . . . . . . . 3 55 2.4 Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.5 Colliding Uses . . . . . . . . . . . . . . . . . . . . . . 4 57 2.6 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.7 Internationalization . . . . . . . . . . . . . . . . . . . 4 59 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1 Heads Up . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2 Highlighting . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3 Sort and Filter . . . . . . . . . . . . . . . . . . . . . 5 63 4. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 5 64 4.1 Envelope-From based Filters . . . . . . . . . . . . . . . 5 65 4.2 List-ID Header field . . . . . . . . . . . . . . . . . . . 5 66 4.3 Per list recipient addresses . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 71 7.2 Informational References . . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 73 Intellectual Property and Copyright Statements . . . . . . . . 8 75 1. Background 77 Various mailing lists modify the Subject: header field of messages 78 sent to the list to contain a kind of identifier enclosed in square 79 brackets. Every now and then this "feature" is also requested for 80 the main IETF list (one of the recurring topics nowadays). This 81 document collects pros and cons of this approach, tries to identify 82 the real issue and will, in a later stage, try to give a 83 recommendation. 85 2. Problems 87 Several mailing lists, including some of those set up to support IETF 88 working groups, have been found to modify the Subject: header field. 89 There are general, philosophical, issues with which entities should 90 or should not modify parts of a message. Those set aside and also 91 accepting that in general the community served by the list should be 92 able to determine what best fits their needs, there are some 93 technical and/or operational problems remaining. 95 This section tries to summarize problems identified with the 96 approach, in no particular order. 98 2.1 Space 100 Space in the Subject: header field is limited, mostly due to 101 limitations in the screen or window layout of the MUA. The tag 102 identifier occupies at least 6 octets (let's assume that mailing list 103 identifiers are at least 3 characters long), leaving less room for 104 the actual subject. 106 2.2 Position 108 With modified subjects (good practice suggests to insert the new 109 subject before the old should the focus of discussion change in a 110 thread) the tag may shift from left to right. Then it does no longer 111 attract immediate attention or may even drop off the visible Subject: 112 line, failing part of its mission. 114 Response indicators, carrying their own bag of problems, may also 115 lead to a right shift of the tag. 117 2.3 Crosspostings 119 Crossposts to multiple mailing lists tend to end up with at least one 120 tag per list in the Subject line. List identification is then no 121 longer unambiguous. Also, more space in the subject line is used up. 123 2.4 Responses 125 Mailing list expanders do not add a tag if one is already present and 126 they recognize it, so the usual MUA reply function dies not interfere 127 with list tagging. However, private responses, or maybe even 128 forwarded messages will also carry the list tag. While for the 129 purpose of giving context that might be correct, it's also confusing 130 because it mixes personal mail with list mail. 132 MUAs could always delete tags (or what appears to be a tag) from the 133 Subject: header field, so mailing list expanders would always add 134 (renew) it and private replies would appear as what they are. 135 However, not all text enclosed by square brackets actually is a list 136 tag. 138 2.5 Colliding Uses 140 Some of the problems described above could be addressed if MUAs could 141 generally treat square brackets as list name indicators and collapse, 142 shift or sometimes even hide them. However, square brackets are 143 ordinary characters without special function and are traditionally 144 used to mark forwarded messages by [fwd], or to tag subtopics in high 145 volume mailing lists. 147 2.6 Namespace 149 While the address of a mailing list is unique (list redirection or 150 forwarding nonwithstanding), in the tags lists are usually identified 151 by the list's address' local part or variations thereof. This 152 'collapsed' namespace is inherently flat, unmanaged and thus gives 153 opportunities for collisions. So, if widely accepted, the method 154 will no longer be able to fulfill its task. Collisions are even more 155 likely assuming that recipients usually are subscribed to multiple 156 mailing lists addressing the same topic or with generic names like 157 'staff', 'info', etc. 159 Further uniqueness considerations can be found in [RFC2919]. 161 2.7 Internationalization 163 Subjects may contain non-ASCII characters, so that they are 164 MIME-encoded per [RFC2047]. Some MUAs do replace square brackets by 165 their quoted-printable equivalents =5B and =5D, so the receiving MUA 166 and/or the mailing list expander may not recognize the presence of 167 the tag. The latter case will result in multiple tags appearing on 168 the Subject: line. 170 As a countermeasure the list software would have to MIME decode the 171 header field, identify the tag, and re-encode, which in turn might 172 alter or unify the Subject:. 174 3. Motivation 176 Despite their drawbacks, Subject: [tags] are popular for some reasons 177 to be collected in this section. 179 3.1 Heads Up 181 List mails can easily be separated from personal mails. 183 3.2 Highlighting 185 Highlighting or scoring mails for preferred or deferred presentation 186 can be based on tags. 188 3.3 Sort and Filter 190 Tagged mails can easily be sorted (grouped together) and filtered. 192 4. Alternative Approaches 194 While the tags truely address a demand, there are and have been 195 different approaches which do not force the list engine to modify the 196 existing message headers in transit. 198 4.1 Envelope-From based Filters 200 Mailing list expanders are supposed to substitute the envelope From 201 field when relaying a message sent to a list [RFC2821, 3.10]. Some 202 use a generic per list address ("owner=" or "-request"), some use per 203 user identification to support matching incoming NDNs to subscribers. 204 In any (decent) case, the envelope from (or a part of it) should 205 uniquely identify the mailing list. Provided the MDA passes through 206 the envelope from information, sorting and filtering can be done 207 solely based on this data. This includes the users' opportunity to 208 modify any headers they see fit. 210 4.2 List-ID Header field 212 In [RFC 2919] a new header field "List-ID" is specified that uniquely 213 identifies the mailing list that caused the message to be sent to the 214 recipient. 216 4.3 Per list recipient addresses 218 Conventions exist which support sub-addressing for the recipient, 219 enabling either mail filtering or direct delivery to a recipient's 220 particular folder. While there may be some disadvatages on lists 221 with posting restrictions, sub-addressing (or different addresses, 222 for that matter) can be used to direct mailing list traffic to 223 specific folders. 225 5. Security Considerations 227 There may be security issues with using Subject: [tags], such as 228 introducing trust by "forging" a certain tag, or by simply drawing 229 the recipient's attention to a particular message. These risks are 230 similar to those resulting from forged sender addresses and/or 231 mimicked Subject: lines. 233 6. IANA Considerations 235 This document does not define any new namespaces. In particular, 236 there's currently no need for registering the mailing list tags. 238 7. References 240 7.1 Normative References 242 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 243 Part Three: Message Header Extensions for Non-ASCII Text", 244 RFC 2047, November 1996. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 250 April 2001. 252 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 253 2001. 255 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 256 and Namespace for the Identification of Mailing Lists", 257 RFC 2919, March 2001. 259 7.2 Informational References 261 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 262 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 263 October 1998. 265 Author's Address 267 Peter Koch 268 Universitaet Bielefeld 269 Technische Fakultaet 270 33594 Bielefeld 271 DE 273 Phone: +49 521 106 2902 274 EMail: pk@TechFak.Uni-Bielefeld.DE 276 Intellectual Property Statement 278 The IETF takes no position regarding the validity or scope of any 279 Intellectual Property Rights or other rights that might be claimed to 280 pertain to the implementation or use of the technology described in 281 this document or the extent to which any license under such rights 282 might or might not be available; nor does it represent that it has 283 made any independent effort to identify any such rights. Information 284 on the procedures with respect to rights in RFC documents can be 285 found in BCP 78 and BCP 79. 287 Copies of IPR disclosures made to the IETF Secretariat and any 288 assurances of licenses to be made available, or the result of an 289 attempt made to obtain a general license or permission for the use of 290 such proprietary rights by implementers or users of this 291 specification can be obtained from the IETF on-line IPR repository at 292 http://www.ietf.org/ipr. 294 The IETF invites any interested party to bring to its attention any 295 copyrights, patents or patent applications, or other proprietary 296 rights that may cover technology that may be required to implement 297 this standard. Please address the information to the IETF at 298 ietf-ipr@ietf.org. 300 Disclaimer of Validity 302 This document and the information contained herein are provided on an 303 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 304 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 305 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 306 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 307 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 308 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 310 Copyright Statement 312 Copyright (C) The Internet Society (2004). This document is subject 313 to the rights, licenses and restrictions contained in BCP 78, and 314 except as set forth therein, the authors retain all their rights. 316 Acknowledgment 318 Funding for the RFC Editor function is currently provided by the 319 Internet Society.