Subject: A mailing list protocol

From: S Moonesamy <[email-masked]>
Date: Tue, 04 Dec 2012 12:38:23 -0800

Hello,

I submitted a draft which discusses about a mailing list protocol 
[1].  It is a code of courtesy that the reader may wish to extend to 
others to facilitate the exchange of opinions and ideas, and to 
facilitate mailing list discussions.  Sally Hambridge deserves full 
credit for most of the text.

The draft is not about rules, guidelines or BCPs.  The problems I 
encountered are:

  (a) excessive text in mailing list messages causing the message digest to be
      sent after a few messages are posted to a mailing list.

  (b) replies to messages which use an odd quoting style [2].

You are invited to criticize the draft.

Regards,
S. Moonesamy

1. http://tools.ietf.org/html/draft-moonesamy-mail-list-protocol-00
2. http://home.in.tum.de/~jain/software/outlook-quotefix/

---

From: "George, Wes" <[email-masked]>
Date: Tue, 4 Dec 2012 17:19:14 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> S Moonesamy
>

[WEG] The referenced program doesn't work for anything 2007 or later (aka versions still supported by MS), making it of limited use.

Is there an IETF standard format for handling inline quote replies? Is it just not implemented in certain mail clients? If there isn't a relevant standard, then we have no business whining that people are doing it "wrong", and we should probably get to work defining one, either for use on the client side, or possibly an extension for common mailman software to parse and fix it on the server side to compensate for odd client implementations.

The last thread that talked about how to do email "correctly" focused on the usual bashing of those using outlook or company email addresses, rather than much in the way of helpful advice on how to make it less bad.
[ https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=64911&tid=1354657596 ]

Browbeating people into changing mail clients will be less than effective, but something that systematically makes it easier to see who is responsible for what comment in a multi-person thread regardless of source email client would be welcome. While we're at it, we could maybe implement a fix for the common problem of mangled subject lines that make it very difficult to sort by thread, and add a server-side filter that removes the legal bilgewater automatically added to some outgoing messages (example will follow in this very message) before sending it to the rest of the list recipients, etc.

I'd support a draft of that nature, but rehashing an old draft about nettiquete 101 is less helpful. A simple reference to the original in the Tao webpage would probably be sufficient to get the behavioral point across, and then we can focus more on the technical problem that we appear to have.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Dec 2012 14:55:46 -0800

> [WEG] The referenced program doesn't work for anything 2007 or later (aka versions still supported by MS), making it of limited use.

I'm happy to share my (crappy) VB macro for doing this.  I recall
fixing it so that it worked from individual message windows (as
opposed to just the main window), but I lost the edit when I moved
companies and haven't bothered to go back and fix it.

http://pastebin.com/ebMv7vrw

Some effort required to install, but not beyond the capabilities of
anyone who could be bothered to try.

---

From: Scott Brim <[email-masked]>
Date: Tue, 4 Dec 2012 20:34:32 -0500

Those are all endpoint implementation problems and thus not subject to IETF standardization :-)

---

From: Arturo Servin <[email-masked]>
Date: Wed, 05 Dec 2012 12:16:47 -0200

What are "those"?

	Without the context it is impossible to guess, at least for me.

.as

---

From: S Moonesamy <[email-masked]>
Date: Wed, 05 Dec 2012 08:52:59 -0800

Hi Arturo,
>         Without the context it is impossible to guess, at least for me.

According to 
http://www.ietf.org/mail-archive/web/ietf/current/msg76273.html 
the message posted by Scott Brim ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg76275.html 
) is a follow-up comment to the message posted by 
Martin Thomson.  The messages posted by these two 
persons are related to the message posted by Wes 
George ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg76271.html 
).  That message contains the words "client 
implementations".  The comment from Scott Brim could be rewritten as:

   The issues mentioned by George Wes and Martin Thomson are all endpoint
   implementation problems and thus not subject to IETF standardization.

As the sentence written by Scott Brim has a 
smiley at the end, the idea expressed might be  somewhat similar to:

   Mi perro se comió las hojas donde estaban mis deberes del colegio.

The comment is actually a good argument.  Whether 
it would be valid or not is a matter of context.

Regards,
S. Moonesamy

---

From: Dave Cridland <[email-masked]>
Date: Thu, 06 Dec 2012 12:36:07 +0000

On Tue Dec  4 22:19:14 2012, George, Wes wrote:
> Is there an IETF standard format for handling inline quote replies?  
> Is it just not implemented in certain mail clients? 

RFC 3676? (As used here).

It is admittedly primarily useful in simple replies rather than  
quoting (and therefore attribution) from multiple parent messages;  
however that's by far the common case. A further specifcation to  
annotate attribution would be possible, though in principle that  
would be usefully based on the References field.

> Browbeating people into changing mail clients will be less than  
> effective, but something that systematically makes it easier to see  
> who is responsible for what comment in a multi-person thread  
> regardless of source email client would be welcome. While we're at  
> it, we could maybe implement a fix for the common problem of  
> mangled subject lines that make it very difficult to sort by  
> thread, and add a server-side filter that removes the legal  
> bilgewater automatically added to some outgoing messages (example  
> will follow in this very message) before sending it to the rest of  
> the list recipients, etc.

I've not really had a problem with searching for the subject root, in  
general, but I'd be happy to agree despite inexperience with the  
issue that there are standards for reply-mangling of subjects and we  
should note that.

My more common problem is a lack of in-reply-to or references fields  
that I can use for in-thread navigation, which I find particularly  
useful.

In general, there are a number of technical standards and protocols  
which are useful, or essential, for IETF participation; documenting  
these in a single location would seem beneficial.

Dave.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 06 Dec 2012 19:03:33 +0100

> these in a single location would seem beneficial.

Don't forget the confidentiality notices conundrum, see e.g.
http://www.ietf.org/mail-archive/web/ietf/current/msg67495.html

---

From: "John Levine" <[email-masked]>
Date: 6 Dec 2012 21:24:00 -0000

>Is there an IETF standard format for handling inline quote replies?

It's defined in the same RFC that specifies the setting of the
Reply-To: header in mailing lists.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 09 Dec 2012 11:43:39 -0800

Hello,

Thanks to all of you who provided feedback on this thread and 
off-list.  I'll attempt to summarize the comments on this thread.

Wes George asked whether there was an IETF standard format for 
handling inline quote replies and whether it has been implemented 
[1].  He mentioned that rehashing an old draft about nettiquete 101 
is less helpful.  He also commented  about the common problem of 
mangled subject lines that make it very difficult to sort by 
thread.  There was also an off-list comment about this.   Scott 
Brim's comment [2] is an interesting view about standardization.

Dave Cridland mentioned RFC 3676 [3].  He pointed out that it 
primarily useful in simple replies rather than quoting.  One of the 
problem he encounters is a lack of in-reply-to or references fields 
that I can use for in-thread navigation.  Alessandro Vesely commented 
about disclaimers in messages [4].

I avoided a discussion of standards or to dictate etiquette in 
draft-moonesamy-mail-list-protocol.  Section 2 list points which may 
see obvious to a lot of people on this mailing list.  The text at 
http://www.ietf.org/newcomers.html doesn't provide a lot of 
information about facilitating discussions.

I would like to ask you to pick the three points from Section 2 ( 
http://tools.ietf.org/html/draft-moonesamy-mail-list-protocol-00 ) 
which you consider as helpful to facilitate mailing list discussion 
and send them to me off-list.  I'll post a summary to this mailing 
list after a week.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/ietf/current/msg76271.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg76275.html
3. http://www.ietf.org/mail-archive/web/ietf/current/msg76295.html
4. http://www.ietf.org/mail-archive/web/ietf/current/msg76296.html

---

From: Melinda Shore <[email-masked]>
Date: Sun, 09 Dec 2012 11:40:26 -0900

On 12/9/12 10:43 AM, S Moonesamy wrote:
> http://tools.ietf.org/html/draft-moonesamy-mail-list-protocol-00 ) which
> you consider as helpful to facilitate mailing list discussion and send
> them to me off-list.  I'll post a summary to this mailing list after a
> week.

I'm increasingly not a fan of process documents.  It may be the case
that we need a process document addressing the problem of excessive
process documents.  I hope that where your efforts end up is a wiki
page or some such, which I think would be helpful, rather than an RFC,
which I think would not.

Melinda

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 09 Dec 2012 20:54:46 +0000

> page or some such, which I think would be helpful, rather than an RFC,

Pretty much everything in the draft is covered by many third party wikis
and faqs already.  Perhaps a paragraph in the Tao document would suffice
instead of an rfc?

Nick

---

From: John C Klensin <[email-masked]>
Date: Sun, 09 Dec 2012 16:17:11 -0500

--On Sunday, December 09, 2012 11:40 -0900 Melinda Shore
<[email-masked]> wrote:

>> http://tools.ietf.org/html/draft-moonesamy-mail-list-protocol
>> -00 ) which you consider as helpful to facilitate mailing
>> list discussion and send them to me off-list.  I'll post a
>> summary to this mailing list after a week.
> 
> I'm increasingly not a fan of process documents.  It may be
> the case that we need a process document addressing the
> problem of excessive process documents.  I hope that where
> your efforts end up is a wiki page or some such, which I think
> would be helpful, rather than an RFC, which I think would not.

+1 and an observation:  

I think there is a simple test as to when a process document is
actually necessary.  If the nature of the relevant process is
such that one wants a violation to constitute an appeal-able or
recall-able event and believes that the problem created by a
violation is serious appeal or recall should probably succeed,
then getting formal consensus and generating a BCP RFC is
probably justified.  For anything that constitutes general
guidance (as in this case) or is a statement about how some
entity intends to do things until their change their minds
again, "wiki page or some such" should be perfectly adequate and
less likely to waste community time on splitting hairs, picking
nits, and other not-very-productive activities.

Note that the above is consistent with the recent decision(s)
about the Tao: informative document, general guidance, but not
something that contains rule whose violation can be appealed,
hence a web page and some guidance about how it will be
maintained, not a series of RFCs.

    john

---

From: Hector Santos <[email-masked]>
Date: Sun, 09 Dec 2012 16:21:58 -0500

> page or some such, which I think would be helpful, rather than an RFC,

+1, thank you for speaking up.

-- 
HLS

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Dec 2012 07:39:49 +0900

> I'm increasingly not a fan of process documents.

the rise of a bureaucratic class is a dangerous sign of ossification.

i just failed gobbling for an image of the net police ticket dr postel
used to have on his wall.  if anyone has an image, i would dearly love
a copy.  advthanksance.

randy

---

From: Randall Gellens <[email-masked]>
Date: Sun, 9 Dec 2012 18:17:52 -0800

>  Is there an IETF standard format for handling inline quote replies?

Yes, RFC 3676.

>   Is it just not implemented in certain mail clients?

Sadly, yes.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Ask not what you can do for your country, ask what's for lunch.
                         --Orson Welles on reaching 300 pounds

---

From: Randall Gellens <[email-masked]>
Date: Sun, 9 Dec 2012 18:28:44 -0800

At 11:43 AM -0800 12/9/12, S Moonesamy wrote:

> primarily useful in simple replies rather than quoting.

Just to clarify: Dave didn't say that RFC 3676 is not useful for 
quoting (indeed, quoting is one of it's main points).  Dave pointed 
out that RFC 3676 didn't include a mechanism to attribute each quote 
to a specific author, which is true.  Dave also pointed out that this 
attribution could in theory be accomplished by matching the quote 
level (which is included) to the 'References:' chain, although this 
would be fragile in practice because so few clients correctly 
implement 'References:'.

>  One of the problem he encounters is a lack of in-reply-to or 
> references fields that I can use for in-thread navigation.

Used for threading in general, not in-thread navigation (I'm not sure 
I understand the difference, but to me, threading is the ability to 
group together messages in a logical thread or discussion, while 
in-thread navigation would be the ability to jump around within a 
thread).

-------------- Randomly selected tag: ---------------
With most men, life is like backgammon -- half skill and half luck.
                                           --Oliver Wendell Holmes

---

From: Randall Gellens <[email-masked]>
Date: Sun, 9 Dec 2012 18:33:29 -0800

>  page or some such, which I think would be helpful, rather than an RFC,

Unfortunately, I see little evidence that any of these would be 
useful in this case.  Process documents, web pages, and the like can 
only be useful if people follow them, and I don't see cause for 
optimism that anyone who isn't currently following what we desire 
will start doing so once the RFC or wiki page is published.  I'd be 
delighted to be wrong, of course.

-------------- Randomly selected tag: ---------------
Surströmmingspremier (SEUR-stomins-prem-ya; Swedish; noun): The
first day of the year when it is acceptable eat Surströmming,
extremely foul-smelling fermented herring (banned in some apartment
complexes, airplanes, etc.) -- literally, "sour fish premier."