Network Working Group P. Koch Internet-Draft Universitaet Bielefeld Expires: May 18, 2005 November 17, 2004 Subject: [tags] Considered Harmful draft-koch-subject-tags-considered-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Various mailing lists modify the Subject: header field of messages sent to the list to contain a kind of identifier enclosed in square brackets. Every now and then this "feature" is also requested for the main IETF list. This document collects pros and cons of this approach, tries to identify the real issue and will, in a later stage, try to give a recommendation. Koch Expires May 18, 2005 [Page 1] Internet-Draft Subject: [tags] Considered Harmful November 2004 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Space . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Position . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Crosspostings . . . . . . . . . . . . . . . . . . . . . . 3 2.4 Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5 Colliding Uses . . . . . . . . . . . . . . . . . . . . . . 4 2.6 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 4 2.7 Internationalization . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Heads Up . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Highlighting . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Sort and Filter . . . . . . . . . . . . . . . . . . . . . 5 4. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 5 4.1 Envelope-From based Filters . . . . . . . . . . . . . . . 5 4.2 List-ID Header field . . . . . . . . . . . . . . . . . . . 5 4.3 Per list recipient addresses . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 7.2 Informational References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Koch Expires May 18, 2005 [Page 2] Internet-Draft Subject: [tags] Considered Harmful November 2004 1. Background Various mailing lists modify the Subject: header field of messages sent to the list to contain a kind of identifier enclosed in square brackets. Every now and then this "feature" is also requested for the main IETF list (one of the recurring topics nowadays). This document collects pros and cons of this approach, tries to identify the real issue and will, in a later stage, try to give a recommendation. 2. Problems Several mailing lists, including some of those set up to support IETF working groups, have been found to modify the Subject: header field. There are general, philosophical, issues with which entities should or should not modify parts of a message. Those set aside and also accepting that in general the community served by the list should be able to determine what best fits their needs, there are some technical and/or operational problems remaining. This section tries to summarize problems identified with the approach, in no particular order. 2.1 Space Space in the Subject: header field is limited, mostly due to limitations in the screen or window layout of the MUA. The tag identifier occupies at least 6 octets (let's assume that mailing list identifiers are at least 3 characters long), leaving less room for the actual subject. 2.2 Position With modified subjects (good practice suggests to insert the new subject before the old should the focus of discussion change in a thread) the tag may shift from left to right. Then it does no longer attract immediate attention or may even drop off the visible Subject: line, failing part of its mission. Response indicators, carrying their own bag of problems, may also lead to a right shift of the tag. 2.3 Crosspostings Crossposts to multiple mailing lists tend to end up with at least one tag per list in the Subject line. List identification is then no longer unambiguous. Also, more space in the subject line is used up. Koch Expires May 18, 2005 [Page 3] Internet-Draft Subject: [tags] Considered Harmful November 2004 2.4 Responses Mailing list expanders do not add a tag if one is already present and they recognize it, so the usual MUA reply function dies not interfere with list tagging. However, private responses, or maybe even forwarded messages will also carry the list tag. While for the purpose of giving context that might be correct, it's also confusing because it mixes personal mail with list mail. MUAs could always delete tags (or what appears to be a tag) from the Subject: header field, so mailing list expanders would always add (renew) it and private replies would appear as what they are. However, not all text enclosed by square brackets actually is a list tag. 2.5 Colliding Uses Some of the problems described above could be addressed if MUAs could generally treat square brackets as list name indicators and collapse, shift or sometimes even hide them. However, square brackets are ordinary characters without special function and are traditionally used to mark forwarded messages by [fwd], or to tag subtopics in high volume mailing lists. 2.6 Namespace While the address of a mailing list is unique (list redirection or forwarding nonwithstanding), in the tags lists are usually identified by the list's address' local part or variations thereof. This 'collapsed' namespace is inherently flat, unmanaged and thus gives opportunities for collisions. So, if widely accepted, the method will no longer be able to fulfill its task. Collisions are even more likely assuming that recipients usually are subscribed to multiple mailing lists addressing the same topic or with generic names like 'staff', 'info', etc. Further uniqueness considerations can be found in [RFC2919]. 2.7 Internationalization Subjects may contain non-ASCII characters, so that they are MIME-encoded per [RFC2047]. Some MUAs do replace square brackets by their quoted-printable equivalents =5B and =5D, so the receiving MUA and/or the mailing list expander may not recognize the presence of the tag. The latter case will result in multiple tags appearing on the Subject: line. As a countermeasure the list software would have to MIME decode the Koch Expires May 18, 2005 [Page 4] Internet-Draft Subject: [tags] Considered Harmful November 2004 header field, identify the tag, and re-encode, which in turn might alter or unify the Subject:. 3. Motivation Despite their drawbacks, Subject: [tags] are popular for some reasons to be collected in this section. 3.1 Heads Up List mails can easily be separated from personal mails. 3.2 Highlighting Highlighting or scoring mails for preferred or deferred presentation can be based on tags. 3.3 Sort and Filter Tagged mails can easily be sorted (grouped together) and filtered. 4. Alternative Approaches While the tags truely address a demand, there are and have been different approaches which do not force the list engine to modify the existing message headers in transit. 4.1 Envelope-From based Filters Mailing list expanders are supposed to substitute the envelope From field when relaying a message sent to a list [RFC2821, 3.10]. Some use a generic per list address ("owner=" or "-request"), some use per user identification to support matching incoming NDNs to subscribers. In any (decent) case, the envelope from (or a part of it) should uniquely identify the mailing list. Provided the MDA passes through the envelope from information, sorting and filtering can be done solely based on this data. This includes the users' opportunity to modify any headers they see fit. 4.2 List-ID Header field In [RFC 2919] a new header field "List-ID" is specified that uniquely identifies the mailing list that caused the message to be sent to the recipient. 4.3 Per list recipient addresses Conventions exist which support sub-addressing for the recipient, Koch Expires May 18, 2005 [Page 5] Internet-Draft Subject: [tags] Considered Harmful November 2004 enabling either mail filtering or direct delivery to a recipient's particular folder. While there may be some disadvatages on lists with posting restrictions, sub-addressing (or different addresses, for that matter) can be used to direct mailing list traffic to specific folders. 5. Security Considerations There may be security issues with using Subject: [tags], such as introducing trust by "forging" a certain tag, or by simply drawing the recipient's attention to a particular message. These risks are similar to those resulting from forged sender addresses and/or mimicked Subject: lines. 6. IANA Considerations This document does not define any new namespaces. In particular, there's currently no need for registering the mailing list tags. 7. References 7.1 Normative References [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001. 7.2 Informational References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Koch Expires May 18, 2005 [Page 6] Internet-Draft Subject: [tags] Considered Harmful November 2004 Author's Address Peter Koch Universitaet Bielefeld Technische Fakultaet 33594 Bielefeld DE Phone: +49 521 106 2902 EMail: pk@TechFak.Uni-Bielefeld.DE Koch Expires May 18, 2005 [Page 7] Internet-Draft Subject: [tags] Considered Harmful November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koch Expires May 18, 2005 [Page 8]