[Extra] Adam Roach's Discuss on draft-ietf-extra-specialuse-important-03: (with DISCUSS and COMMENT)
Adam Roach <adam@nostrum.com> Thu, 07 June 2018 02:13 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: extra@ietf.org
Delivered-To: extra@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA90E130E14; Wed, 6 Jun 2018 19:13:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-extra-specialuse-important@ietf.org, Bron Gondwana <brong@fastmailteam.com>, extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152833758875.6300.13983676302738633190.idtracker@ietfa.amsl.com>
Date: Wed, 06 Jun 2018 19:13:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/eW7OiirYglFFtBD8cdytC2cA6h4>
Subject: [Extra] Adam Roach's Discuss on draft-ietf-extra-specialuse-important-03: (with DISCUSS and COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 07 Jun 2018 02:13:09 -0000
Adam Roach has entered the following ballot position for draft-ietf-extra-specialuse-important-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-specialuse-important/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work everyone has done on this document. I have a concern about an ambiguity that can potentially lead to interop issues between clients and servers that make different assumptions around \Important mailbox ordinality. The second example in section 3.2.2 and the use of the singular form "mailbox" in this passage from section 5 imply that only one mailbox is allowed to be tagged "\Important": > As noted in RFC 6154, it is wise to protect the IMAP channel from > passive eavesdropping, and to defend against unauthorized discernment > of the identity of a user's "\Important" mailbox... However, I find no normative text that indicates whether this is expected to be inherent to the mechanism, or whether servers can exercise discretion about allowing more than one mailbox to be tagged \Important. In particular, I want to ensure that no one develops a client that assumes that the server will prevent it from having multiple such mailboxes (relying on an error in the case that it tries to create a second one), and then chokes when it happens. Similar issues can arise with a permissive server and two clients with different notions about whether multiple \Important mailboxes are allowed. Please add normative language that either explicitly disallows this behavior, or explicitly allows this behavior. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract, Introduction, and Informative References section of this document all refer to the obsolete RFC 3348, while the table in section 6.3 refers to RFC 5258, which is the document that obsoleted RFC 3348. I think you want to make this consistent within the document (namely, I think this document should not mention RFC 3348 anywhere). --------------------------------------------------------------------------- §3.2.2: > C: t1 CREATE "Important Messages" (USE (\Important)) > S: t1 NO [USEATTR] Mailbox not created; an \Important mailbox already exists The server response in this example is too long for the RFC format; and, being a protocol element, I don't think the RFC editor can automatically fix it. Please consider either using a shorter message in the example, or introducing a documentation convention that allows wrapping of lines where the protocol does not. (It is common in SIP and SDP to add a line break and small indent, along with a note that such line breaks are to comply with the RFC format and do not appear on the wire).