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

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jun 2018 19:13:08 -0700

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jun 2018 02:54:18 -0400

Thanks for the review, Adam.

> servers that make different assumptions around \Important mailbox ordinality.

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

> in this passage from section 5 imply that only one mailbox is allowed to be
...
> 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.

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

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

> protocol element, I don't think the RFC editor can automatically fix it.

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

Barry

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Jun 2018 02:01:08 -0500

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

Ugh. Sorry, brain handed me the wrong word.

> think we want to nor should say anything further in this document.

I did go looking for text that said something to this effect in the 
general sense, but didn't locate this. If you're comfortable that IMAP 
implementations will generally be aware of this, then the situation 
seems to be okay. I'll clear my DISCUSS.

/a