Re: [Extra] Adam Roach's Discuss on draft-ietf-extra-specialuse-important-03: (with DISCUSS and COMMENT)

Barry Leiba <barryleiba@computer.org> Thu, 07 June 2018 06:54 UTC

Return-Path: <barryleiba@gmail.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 DCAC5130E83; Wed, 6 Jun 2018 23:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Level:
X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Kjr8RuC_zuF1; Wed, 6 Jun 2018 23:54:19 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D78130E82; Wed, 6 Jun 2018 23:54:19 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id k17-v6so1403358ita.0; Wed, 06 Jun 2018 23:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MQ2cZS0gAYV76liGbidHwlXRue99clvYIuTb0mSyuxQ=; b=vE+vYYykJNgLID04QWIlExc+tZ7WGBpS4Cg5v/LLKNPXJcP1nZqHeYQ9TxyJDRIaaL F1RsVCd2xebU9CoxD9zPQN/2h+4t+PhGm5LH1vyWa/dOU6yB+j+ltIqMpkEmpOVIZJ7g QFBlnl7DyA86Ga5WRjk/+VYS/6dLJI15P28XsGWtokYzy0+aRfEmLyz9qR8ylKkKACpN qa6FTPWrkmaoRvnF28Z25ecQCJc/ut9Ew6KJAFY2FIgXCigmj8r6yQ5ZE7TgPdyBFtC+ yNEAj5yniBrB3NILGOoimYFhsi73tT7rA9964KP5EiWM0ABYnAnUtAOo2EFctceH+gVp yXzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MQ2cZS0gAYV76liGbidHwlXRue99clvYIuTb0mSyuxQ=; b=PfyVV263+X6a46uKUuFNCc6Ap90XH+0JKFq4n8YsKLu0pDsMb2SN4bkvq2/QOP4deq fHErt7vdxyihkWvRbgR53mBWhh8V6jv84sR7MNdpB0/onfWZre1f+4MPk+OghIfahnod M3q4T2exL3f8D/7VyoqJpNiY8oDy45QvdW0S3cAtpxQGXis1ZR+s5brqDqpYbxs3Pv0c 5rKgFbeIFpJVszOWiQuXAmD1wA6Mh5+GC/b1TFJZXwjJww6ppuoStonEzX3q0rLF9b4F 39ql+4w8mkVO27vPAOpJrTvG3xcUpO35kYr0EVpln4wTQM5mSBZ76h2tLVaMOPyBZn0I bA+Q==
X-Gm-Message-State: APt69E3huGbBhvhPYOm7YJf6QhC8dZTkviqPjQCbpE09/b+SMS4SWCMy Qz8OdQIY3D5oFjYrrH12SxrCD0Wq9wZtBpHy9YYC21JY
X-Google-Smtp-Source: ADUXVKLCv5fiGtD2XGB2csbGwLOB5gxKjnfGaTFNue5uTULPGfgTCPFDyOAkr71g66RKJXA9uKznrdEJ5/JFqK+eR20=
X-Received: by 2002:a24:f007:: with SMTP id s7-v6mr873746ith.15.1528354458638; Wed, 06 Jun 2018 23:54:18 -0700 (PDT)
MIME-Version: 1.0
Sender: barryleiba@gmail.com
Received: by 2002:ac0:8ea1:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 23:54:18 -0700 (PDT)
In-Reply-To: <152833758875.6300.13983676302738633190.idtracker@ietfa.amsl.com>
References: <152833758875.6300.13983676302738633190.idtracker@ietfa.amsl.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 07 Jun 2018 02:54:18 -0400
X-Google-Sender-Auth: Jdoz54L2j2De-EQn9_ZkjClr15I
Message-ID: <CALaySJKicughb4QAMxoic2kx0nQ8yTaFAdpQLRR4nMvo5WREmg@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-extra-specialuse-important@ietf.org, Bron Gondwana <brong@fastmailteam.com>, extra-chairs@ietf.org, extra@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/-s5D9-ZbZ6BLvp-6ptY3Ae13w-Y>
Subject: Re: [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
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: Thu, 07 Jun 2018 06:54:22 -0000

Thanks for the review, Adam.

> 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.

It took me a bit to understand that you mean "cardinality".

> 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":
...
> 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.

Look at RFC 6154 Section 2, and note the similar language throughout,
then the penultimate paragraph:

   In most cases, there will likely be at most one mailbox with
   a given attribute for a given user, but in some server or message
   store implementations it might be possible for multiple mailboxes to
   have the same special-use attribute.

That's intentional, and is as far as we want to go with it.  I don't
think we want to nor should say anything further in this document.

> 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 explain "chokes" in this context.  I don't see what a client
would do that would harm interoperability.  The only effect I can
envision if a server should allow multiple \Important mailboxes is
that if a client gives a user a "move this to the 'Important' mailbox"
function, the client will pick one, and different clients might pick a
different one.  The same situation exists with the other attributes
(consider \Drafts, \Flagged, or \Junk), and we see no harm there.

In practice, implementations do not allow multiple mailboxes with the
same attribute, following the "in most cases" clause from RFC 6154.
But if there turns out to be a good reason to allow it in some
situation(s) or in some message store(s), we don't want to disallow
it.

> 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).

You're right: I changed the references in the registry and forgot to
change them elsewhere; fixed now.  The reason it didn't get caught is
that the "obsoleted by" metadata is missing from RFC 3348 in the
datatracker.  I'll ask the tools team to fix that.

>>   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.

Yes, I missed that too.  Fixed (shortened).

Barry