[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/