[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
- [Extra] draft-ietf-extra-imap4rev2-04: ALERT Michael Slusarz