Subject: [Extra] WGLC review of draft-ietf-extra-imap-list-myrights-02

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Mar 2018 11:42:29 +0200

The document's in very good shape and is almost ready.  I have a
couple of minor points below.

— Section 3 —

   For each listable mailbox matching
   the list pattern and selection options, the server MUST return an
   untagged LIST response followed by an untagged MYRIGHTS response
   containing the set of rights granted to the logged-in user.

We don’t usually specify any particular ordering for untagged
responses, and for the most part, ordering is not significant.  I
presume it’s not significant here, and that both of the following
would be equally acceptable to a client:

   C: A01 LIST "" % RETURN (MYRIGHTS)
   S: * LIST () "." "INBOX"
   S: * MYRIGHTS "INBOX" lrswipkxtecda
   S: * LIST () "." "foo"
   S: * MYRIGHTS "foo" lrs
   S: A01 OK List completed.

   C: A01 LIST "" % RETURN (MYRIGHTS)
   S: * LIST () "." "INBOX"
   S: * LIST () "." "foo"
   S: * MYRIGHTS "foo" lrs
   S: * MYRIGHTS "INBOX" lrswipkxtecda
   S: A01 OK List completed.

Now, one wonders whether this would also be acceptable:

   C: A01 LIST "" % RETURN (MYRIGHTS)
   S: * MYRIGHTS "foo" lrs
   S: * MYRIGHTS "INBOX" lrswipkxtecda
   S: * LIST () "." "INBOX"
   S: * LIST () "." "foo"
   S: A01 OK List completed.

…as a client might not be happy seeing MYRIGHTS responses for
mailboxes for which it has not yet seen a LIST response.

Also, the MUST attached to the production of the MYRIGHTS response is
contradicted by the MAY in the next paragraph.

I think we shouldn’t imply that the responses have to be interleaved,
and we should point out that the MYRIGHTS response for a given mailbox
can’t precede the LIST response for that mailbox.  Maybe this?:

NEW
   For each listable mailbox matching
   the list pattern and selection options, the server MUST return an
   untagged LIST response and SHOULD also return an untagged MYRIGHTS
   response containing the set of rights granted to the logged-in user.
   The ordering of the responses is significant only in that the server
   MUST NOT send a MYRIGHTS for a given mailbox before it sends that
   mailbox’s LIST response.
END

Now, as to the following paragraph that explains the SHOULD:

   If the server is unable to look up the set of rights for a given
   mailbox, it MAY drop the corresponding MYRIGHTS reply.

What else could it do?  If there are other reasonable choices, we
should say what they are.  If not, we shouldn’t imply that there are.
And it’s not really a MAY; the server has to do something reasonable,
so I suggest one of the following:

NEW-1
   If the server is unable to look up the set of rights for a given
   mailbox, it does not send the MYRIGHTS reply for that mailbox.
END

NEW-2
   If the server is unable to look up the set of rights for a given
   mailbox, it either does not send the MYRIGHTS reply for that
   mailbox or <—fill in other possible actions here—>.
END

— Section 8 —
It’s always a good idea to give IANA the full name of the registry,
rather than citing where the registry is defined (this is highlighted
by the fact that there are two registries “defined in Section 9 of
[RFC5258]”):

OLD
   This document defines the "LIST-MYRIGHTS" IMAP capability to be added
   to the registry defined in Section 12 of [RFC3501].
NEW
   This document defines the "LIST-MYRIGHTS" IMAP capability to be added
   to the “IMAP Capabilities” registry:
   <https://www.iana.org/assignments/imap-capabilities#imap-capabilities-1>
END

OLD
   This section registers the "MYRIGHTS" option to be added to the
   registry defined in Section 9 of [RFC5258].
NEW
   This section registers the "MYRIGHTS" option to be added to the
   “LIST-EXTENDED options” registry:
   <https://www.iana.org/assignments/imap-list-extended#imap-list-extended-1>
END

— Section 10.2 —
I find it somewhat odd to have a formal reference to 5819 (implying
that there’s something in there that the reader might find useful in
reading this one), when it’s only used in the Acknowledgments.  I
suggest changing the Acks to just say “RFC 5819” (plain text, not as a
citation), and removing the informative reference.

-- 
Barry

---

From: Ken Murchison <[email-masked]>
Date: Mon, 26 Mar 2018 08:38:13 -0400

Hi Barry,

Thanks for the review.  Changes have been made in the working copy:
<https://github.com/ietfextra/tracking/commit/436c8e56970cdf4bef73cbd887c1ee4eaf55b85d>

https://github.com/ietfextra/tracking/commit/436c8e56970cdf4bef73cbd887c1ee4eaf55b85d

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Mar 2018 16:31:52 +0200

> https://github.com/ietfextra/tracking/commit/436c8e56970cdf4bef73cbd887c1ee4eaf55b85d

Thanks!

b

---

From: "Chris Newman" <[email-masked]>
Date: Tue, 27 Mar 2018 17:28:37 -0700

I've reviewed this document and have no objection to advancement (modulo 
I agree with Barry's comment). At this time, we're unlikely to implement 
this; I'm not seeing a good cost/benefit argument for this right now.

		- Chris

On 26 Mar 2018, at 2:42, Barry Leiba wrote:

>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_imap-2Dcapabilities-23imap-2Dcapabilities-2D1&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=zxu1jprWa7J-LiS33mK4NK25q4gLF2X1XfIWfvUEX8s&s=EyBfSBVQ86647nAdh-A2h5ivDjVkv9zO_21PYKj1vqE&e=>
> END
>
> OLD
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_imap-2Dlist-2Dextended-23imap-2Dlist-2Dextended-2D1&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=zxu1jprWa7J-LiS33mK4NK25q4gLF2X1XfIWfvUEX8s&s=lULxUvEmF0NBmzkfrJDp0eM4q-MLdRvYQhLXcDffYTA&e=>
> END
>
> — Section 10.2 —
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=zxu1jprWa7J-LiS33mK4NK25q4gLF2X1XfIWfvUEX8s&s=CLhHcm-GWzsa1BRj2XpjBpC54_pvtE9sLYuiC_petyw&e=