Re: [ietf-smtp] CC'ing ticket systems

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 08 July 2020 19:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4CC3A07A2 for <ietf-smtp@ietfa.amsl.com>; Wed, 8 Jul 2020 12:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzBbUdIfEj9h for <ietf-smtp@ietfa.amsl.com>; Wed, 8 Jul 2020 12:52:37 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB923A07A7 for <ietf-smtp@ietf.org>; Wed, 8 Jul 2020 12:52:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 09978389A1; Wed, 8 Jul 2020 15:49:41 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U3l2JZS1YLip; Wed, 8 Jul 2020 15:49:39 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 44C643899F; Wed, 8 Jul 2020 15:49:39 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6B286A8; Wed, 8 Jul 2020 15:52:33 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tony Finch <dot@dotat.at>, ietf-smtp@ietf.org
In-Reply-To: <alpine.DEB.2.20.2007071746190.21235@grey.csi.cam.ac.uk>
References: <16746.1594119340@localhost> <6.2.5.6.2.20200707062121.11a2daf0@elandnews.com> <alpine.DEB.2.20.2007071746190.21235@grey.csi.cam.ac.uk>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 08 Jul 2020 15:52:33 -0400
Message-ID: <8864.1594237953@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/tCFGCMRGFsRDxufIc4Z38p9LHuU>
Subject: Re: [ietf-smtp] CC'ing ticket systems
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 19:52:39 -0000

Tony Finch <dot@dotat.at> wrote:
    > There's a bit more to this ticketing system problem than just the
    > auto-responses. (And auto-response suppression doesn't kick in if the
    > thread involves people CC:ing each other directly as well as a mailing
    > list and a ticketing system etc...)

Right.

So one manual approach that I've taken for over a decade is to email the
ticket system with a mostly empty message, and then reply to that with the
CC.  This works for systems that expect that, but for many systems, the
humans behind the system are confused by the "emptyish" message.
{And some ticket systems only like to expose a web interface to start a ticket}

I have sometimes initiated tickets on behalf of another party.
(for instance, my mom).  And I wish to be on the CC, but not be the
primary party.


I now have the Subject line (or other thing) initialized, and the other
participants now fill interact with the same ticket.
This is annoying, because I have to wait for an email round trip,
and I have to suspend my (brain) state for awhile.

    > There is the related problem that certain common mail software also
    > willfully fails to implement standard threading. So even if ticketing
    > systems were aware of threads they would still have to cope with other
    > mail software that breaks threads.

I am a bit surprised to hear this, because I thought that they all had
figured out threading-by-top-quoting, but I guess I am wrong.

I notice that many ticket systems now try to assume top-quoting, put their
ticket number into the body, and they ask me write above some line.
I am perplexed that there are systems that omit the Subject line with
replying, but I have experienced it. I assume some phones.

I think that many non-IT organizations should make more use of ticketing
systems. Many do, but do not expose them to the public/customers for reasons
which I think are simply a question of short-sighteness, but also because the
interaction is non-standard.

There are also multi-lingual aspects which the lack of standards makes hard,
because the locatization of the actions has to be done centrally.
(French or English first?  Both offend someone in Ottawa/Gatineau)

Some solutions that I can imagine:
1) a way to get the ticket initialized with the info in a standard place.
   I can imagine new headers for this.
   I can also imagine new SMTP verbs for this, but I expect that won't fly.

2) As you and John have suggested, a BCP that explains how to use In-Reply-To
   headers tie replies back to the same initial ticket.

3) Some kind of notification from the ticket system with a mime type that
   tells me about my ticket and how to interact with it.
   Ideally this content could be forwarded as part of the next CC.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-