[Extra] draft-ietf-extra-imap4rev2-04: ALERT

Michael Slusarz <michael.slusarz@open-xchange.com> Wed, 03 April 2019 22:12 UTC

Return-Path: <michael.slusarz@open-xchange.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AAD120298 for <extra@ietfa.amsl.com>; Wed, 3 Apr 2019 15:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
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 VqRyOPk0Ia5H for <extra@ietfa.amsl.com>; Wed, 3 Apr 2019 15:12:08 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DDF12016F for <extra@ietf.org>; Wed, 3 Apr 2019 15:12:08 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 4CDE46A23E for <extra@ietf.org>; Thu, 4 Apr 2019 00:12:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554329524; bh=A9PPHSzMRkLv2ctbPFANYrG/qg494UPhGEIX2tumM/Y=; h=Date:From:To:Subject:From; b=2H+nzGiv61HUWIIpxLSUj1WZQzVnB0BUde4BNv7OpIdNnrHI05GcLC9Hd7VYAiLsj JKDDCAqSw39rBO9JW0G4h0GjtdOpG48FETmwosvo6Huc7eOBGNKE5yDhodg4VxJunQ Cva50vTyZZt/ZNiXXea2hMPY0b15ptKZNKAvgGRNtqnRudCiqa1Rh7KiR/8YMo6mj3 8+fXwmtMpBtx7wXAkJ7B8HWShcKOGpz1q2cLtK2GNTXZdo7CTFwcssP97Ovpd1IL54 Pkkka41Lj6umCPCRVX3xBOd5AC/IX63edOvgQYGIxE93NOlUqotGKoZUsw0q1sNiG5 Zs8hGfHubQk4w==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 434463C0399 for <extra@ietf.org>; Thu, 4 Apr 2019 00:12:04 +0200 (CEST)
Date: Wed, 3 Apr 2019 16:12:04 -0600 (MDT)
From: Michael Slusarz <michael.slusarz@open-xchange.com>
To: extra@ietf.org
Message-ID: <1625398863.3912.1554329524199@appsuite.open-xchange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev10
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/inxQQJp4U27-BF8IchZZ80SwB4A>
Subject: [Extra] draft-ietf-extra-imap4rev2-04: ALERT
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 22:12:10 -0000

Is "ALERT" useful anymore?  It's limited to ASCII output, which restricts which languages can even be represented in the output text.

It becomes more useful if LANGUAGE extension is implemented and used.  But how many clients use this extension?

The context where ALERT seems most useful is during authentication.  Things like "your password has expired", "your account has been compromised", "Your email plan has expired, please renew your contract", etc.

Gmail has WEBALERT to facilitate this kind of user interaction by directing to a webpage, which is the standard way to facilitate this kind of more complex feedback.  Or maybe something like "[URLALERT <url>]", where URL can be any registered URL type and a client only needs to handle URL types it understands, would be more generic and future-proof.

Not sure if this is something to address in rev2, or something that would be better served in a future extension.

michael