From nobody Sat Feb 1 11:00:42 2020 Return-Path: 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 17A3D120881 for ; Sat, 1 Feb 2020 11:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 3hWap_FScU2g for ; Sat, 1 Feb 2020 11:00:33 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA2312082B for ; Sat, 1 Feb 2020 11:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1580583631; d=isode.com; s=june2016; i=@isode.com; bh=+/9UsSLhKI0pyQ9n/CWRwyO3Sq86Dwlw5QVCpxKwWeg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=VW6fBt8vXkVBxa/EwGK8me1ox8us3sQ5hA2ARuJULODcxzWshO8OqnozOmmDwUUhGNB8H5 3k0sy2F1r0FUiGxcw7YzLUlz8+bU+PRhiBo/5KNPDO/Q1+sIFn9L+XgBohRZcqWBauCSar g/oSyusWXs1CLsdy4dzQxIpKbKnm7XQ=; Received: from [192.168.0.2] (0546c907.skybroadband.com [5.70.201.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 1 Feb 2020 19:00:31 +0000 From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> Date: Sat, 1 Feb 2020 19:00:30 +0000 Cc: extra@ietf.org, Barry Leiba Message-Id: <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> To: Timo Sirainen , Bron Gondwana MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-DE4E868C-70B5-447A-AC33-73B87F07AF73 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 19:00:40 -0000 --Apple-Mail-DE4E868C-70B5-447A-AC33-73B87F07AF73 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > On 29 Jan 2020, at 14:20, Timo Sirainen wrote: >=20 >> On 29. Jan 2020, at 14.08, Bron Gondwana wrote: >>=20 >> 2.2.1 Client protocol >>=20 >> "A different tag is generated by the client for each command". There's n= o "MUST" on this, and certainly I've seen clients which don't. Do we want t= o make that more strict in rev2? It would be a bit of a pain on the command= line where I normally use ".", but it's also annoying as a server author tha= t you can't rely on tag uniqueness. >>=20 >> Maybe the client SHOULD generate a different tag for every command, but a= server MUST accept tag reuse (could restrict concurrency, a tag can only be= reused after it's been "returned") >=20 > I haven't seen this as a problem, so I don't really care either way. I don=E2=80=99t see this as a problem and I don=E2=80=99t want to make the s= erver check for reuse. I am Ok with adding informative suggestion for clients to generate unique ta= gs to ease in debugging issues. Would this work for people? >=20 >> 2.3.1.1 UID Attribute >>=20 >> "The next unique identifier value MUST NOT change unless new messages are= added to the mailbox". I would very much like that first MUST NOT to be we= akened to "SHOULD NOT". My reasoning is that you could have a virtual mailb= ox which used a global sequence number per message. It would behave to clie= nts as if a message had been delivered and then immediately expunged. I'm p= retty sure clients don't care - they'll fetch the range, discover that nothi= ng new has appeared, and stay happy. The second MUST is obviously correct, t= hat the UIDNEXT must increase when messages are delivered. >=20 > Agreed. I am fine with this change. Our server sometimes increment UIDNEXT during so= me failed COPY or APPEND, so obviously relaxing this would be better for us.= =20 >=20 >> 5.1 Mailbox Naming >>=20 >> This doesn't solve one of my naming bugbears. The spec says things like "= servers MAY accept a de-normalized UTF-8 mailbox name and conver it to Net-U= nicode prior to mailbox creation." - there is no clear way to know what the S= ELECTable name will be after creating a mailbox. >>=20 >> If I was designing this myself from scratch I would say that "SELECT of t= he same octets that were passed to CREATE MUST open that same mailbox" or so= mething to that effect. Since we're messing with how mailbox naming works s= omewhat for imap4rev2, I'd be keen to add this restriction on server behavio= ur so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> D= OESN'T EXIST" loop. I agree this is a problem and happy to do what you suggest. >>=20 >> It still doesn't mean that you can reliably tell the correct octets for t= he matching mailbox from the LIST response though :( >=20 > Is it too late to add a new response code? Something like: >=20 > * OK [CREATED] TAG "a123" NAME "Denormalized name" Response codes are cheap and don=E2=80=99t break older clients, so I am happ= y to add one. >=20 >> 6.3.2 SELECT command >>=20 >> I also saw somewhere that the server can unilaterally send a "* [CLOSED]"= response at any point if it's had to close the mailbox (e.g. it got deleted= , or IO errors). I'm not sure if that requires opt-in to IMAP4REV2, since o= therwise clients will not be aware to watch for it. This may need to be cla= rified.=20 Agreed. >> Current behaviour of our server right now is to drop the connection entir= ely, which is ugly - but it's rare and all clients already need to handle it= cleanly, so it guarantees no messed up data model for the clients. >=20 > Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't think clie= nts are going to implement it correctly since it almost never happens, so no= body tests that code path. Let me think about this. >=20 >> 6.3.4 and 6.3.5 CREATE and DELETE >>=20 >> Can we make it illegal to "DELETE" a mailbox with children rather than ma= ke it a \NoSelect mailbox pretty pretty please? I'm just looking at some pa= tches to deal with Outlook misbehaving with this precise situation, and it's= all horrible. Because of mailboxId requirements for JMAP we've been forced= to keep these things around as "intermediate" mailboxes anyway, and it's be= en the source of tons of bugs. >=20 > \NoSelect seems to be causing confusion in general, and Dovecot nowadays h= as options that makes it try to avoid creating them. But I'm not sure if it n= eeds to be made illegal in the RFC itself. I think your server implementatio= n can just decide to reject DELETE if it has children. >=20 > It sounds like your issues are with \NoSelect mailboxes in general, not ju= st this specific way of creating them with DELETE? For example CREATE a/b co= uld create "a" se \NoSelect also. I am happy to disallow this, or at least say that servers can either disallo= w delete of a mailbox with children or add \NoSelect to it. >=20 >> 6.3.6 RENAME=20 >>=20 >> I thought we had agreed to strongly recommend against clients using RENAM= E INBOX Other, but maybe I've forgotten. I don't see it in the minutes, so m= aybe it's just my wishful thinking. >=20 > Dovecot doesn't allow RENAME INBOX in some configurations. I don't remembe= r people complaining. =46rom the client prospective I am disagreeing with this, renaming INBOX is u= seful for archiving. I am happy to say that some servers might disallow this though. Would that b= e Ok with people? >=20 >> We definitely have an option in Cyrus IMAP to make subscriptions follow R= ENAME. It's one of the warts (largely due to Thunderbird showing greyed out= folders and confusing people). >=20 > We haven't needed to do this yet. I think the \NoSelect folders have been m= ore of a reason for Thunderbird confusion. >=20 >> 6.3.7 SUBSCRIBE >>=20 >> Speak of the devil. Lots of sites violate the MUST NOT unilaterally remo= ve rule. Should we weaken it to SHOULD? The justification for the MUST is "= the server site might choose to do X" - well, if the server site is doing th= at, then maybe they SHOULDN'T unilaterally remove the subscriptions, but oth= erwise it's a better user experience and what people want. >>=20 >> (also: by enabling a non-default break the rules config, it's what our se= rver does!) >=20 > The original use case for not auto-removing a subscription is rather ancie= nt already. I'd be fine with changing subscriptions to follow deletes and re= names in the rev2 mode (but better not change behavior in rev1 mode). I think I would rather weaken this to SHOULD and I would rather not require c= hange in behaviour for servers that already comply with the MUST NOT. >=20 >> 6.3.8 UNSUBSCRIBE >>=20 >> This command returns a tagged OK response only if the unsubscription is s= uccessful. - this is not clear on what happens if the mailbox is not current= ly subscribed - does it silently succeed, or is there an expected error? >>=20 >> For what it's worth, our server just says "OK Completed" even if it's alr= eady been unsubscrbed - and likewise for subscribe if it's already subscribe= d it just say "yep, all good". >=20 > Same with Dovecot. I think should keep the OK behavior, since that's what i= s commonly been done. I think returning OK if not subscribed would be a better behaviour for clien= ts. So I would be happy to change the text. >=20 >> 6.3.10 NAMESPACE >>=20 >> We've created a conflict here. The NAMESPACE command contains prefix str= ings for the individual namespaces, and says: >>=20 >> The prefix string allows a client to do things such as automatically >> creating personal mailboxes or LISTing all available mailboxes within >> a namespace. >>=20 >> Which contradicts the advice we gave back in the LIST command not to use p= refix. Perhaps we should change the LIST advice to be "only use the empty p= refix or prefixes given in the NAMESPACE response"? >=20 > I think you're mixing "namespace prefixes" with "list references"? I don't= think the above sentence advocates using LIST reference parameter, just usi= ng the namespace prefix for listing e.g. LIST "" ns-prefix/* Exactly. >=20 > Anyway, I see lots and lots of text is still preserved for the LIST refere= nce parameter explanation, even though it shouldn't be used. Couldn't we jus= t decide to get rid of it entirely in rev2 and say the reference MUST be emp= ty? Or say only that is is implementation-defined and refer to IMAP4rev1 if a= nyone wants to see how it used to be implemented? I kept the text because non empty reference is still allowed. I think I woul= d rather allow it and mark the text as recommended server behaviour if non e= mpty reference parameter is supplied. Maybe move it to a separate section fo= r clarity? >=20 >> 6.3.11 STATUS >>=20 >> Note: The STATUS command is intended to access the status of >> mailboxes other than the currently selected mailbox. Because the >> STATUS command can cause the mailbox to be opened internally, and >> because this information is available by other means on the >> selected mailbox, the STATUS command SHOULD NOT be used on the >> currently selected mailbox. >>=20 >> This advice is all well and good, but it says nothing about what the serv= er may or may not do when it gets one of these STATUS commands. This is par= ticularly relevant in the context of LIST RETURN STATUS, where it's hard to c= onstruct list patterns which explicitly avoid the currently selected mailbox= . Good point. I think this should be allowed on the selected mailbox. >>=20 >> Likewise with the: MUST NOT be used as a "check for new messages in the s= elected mailbox" assertion. Plenty of clients will do a STATUS run across f= olders and if they're doing LIST RETURN STATUS they're gonna find out about t= he new messages if the server returns it. Clients can not rely on it workin= g is a more honest representation of what happens. >>=20 >> I'd like to see that IMAP4REV2 servers MUST implement STATUS of the curre= ntly selected mailbox. Yes, it's a special codepath - but if you're already= testing if it's the currently open mailbox then you're at exactly the right= place to do the right thing: >=20 > Also this is the only way to get the current UIDNEXT of the selected mailb= ox (since it might be higher than last message's UID). >=20 > The main ambiguity though is whether STATUS on the current mailbox is expe= cted to check for new changes. Dovecot implements it in a way that it doesn'= t check for changes. I think there used to be even a good reason for that. I am ambivalent on what server behaviour should be in this case. I am Ok wit= h saying that the client can=E2=80=99t expect the server to check for change= s. >=20 >> 6.4.4.1 SAVE Result >>=20 >> I'm not sure I understand the interaction here with closing and re-openin= g a mailbox. I would expect that closing a mailbox would wipe the SAVED res= ult, >=20 > I think it practically says that, since it says that SELECT/EXAMINE resets= it to empty sequence. It's not really relevant whether it happens when the m= ailbox is closed or when the next mailbox is opened, because you can't use i= t in non-selected state anyway.. Exactly :-). >=20 >> and that trying to use a SAVED result when there isn't one should return a= n error. >=20 > It says that the default is an empty sequence. So it won't result in an er= ror, just a non-matching set. I'm fine with this behavior, especially since i= t's easier to implement and I don't really see much of a downside. Same here. That was the intent. >=20 >> Speaking of which, Example 5 is wrong: It says that the second search com= mand leads to the variable containing no messages, but the second search com= mand did not contain the RETURN SAVE option, so it should not have altered t= he variable. >=20 > Right. And even if it did contain RETURN SAVE option it still shouldn't ha= ve altered the variable, because: >=20 > """ > Any of the following SEARCH commands MUST NOT change the search > result variable: >=20 > a SEARCH command that caused the server to return the BAD tagged > response, > """ Ok, I will recheck the example. >=20 >> 7.4.2 FETCH Response >>=20 >> I remember past bugs with UID in "unsolicited" FLAGS responses. Do we ne= ed to require that including UID only happen after ENABLE IMAP4REV2 (as it i= s for ENABLE QRESYNC)? >=20 > Might be useful to require UID for any untagged FETCH reply. It can simpli= fy client behavior. I think we agreed to this. I think I mention this for IDLE, but didn=E2=80=99= t say it in this section. What is the best place for this text? Best Regards, Alexey --Apple-Mail-DE4E868C-70B5-447A-AC33-73B87F07AF73 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
On 29 Jan 2020, at 14:20, Timo Sirainen <timo@sirainen.com> wrote:

On 29. Jan 2020, at 14.08, Bron Gondwana <brong@fastmailteam.com> wrot= e:

2.2.1 Client protocol

"A different tag is generated by the client for each command".  T= here's no "MUST" on this, and certainly I've seen clients which don't. = Do we want to make that more strict in rev2?  It would be a bit of a p= ain on the commandline where I normally use ".", but it's also annoying as a= server author that you can't rely on tag uniqueness.

Maybe the client SHOULD generate a different tag for every command, bu= t a server MUST accept tag reuse (could restrict concurrency, a tag can only= be reused after it's been "returned")

I haven't seen this as a problem, so I don'= t really care either way.

I don= =E2=80=99t see this as a problem and I don=E2=80=99t want to make the server= check for reuse.

I am Ok with adding informative suggest= ion for clients to generate unique tags to ease in debugging issues. Would t= his work for people?

2.3.1.1 UID Attribute

"The next unique identifier value M= UST NOT change unless new messages are added to the mailbox".  I would very much like that fi= rst MUST NOT to be weakened to "SHOULD NOT".  My reasoning is that you c= ould have a virtual mailbox which used a global sequence number per message.=   It would behave to clients as if a message had been delivered and the= n immediately expunged.  I'm pretty sure clients don't care - they'll f= etch the range, discover that nothing new has appeared, and stay happy. = ; The second MUST is obviously correct, that the UIDNEXT must increase when m= essages are delivered.

Agreed.

I am f= ine with this change. Our server sometimes increment UIDNEXT during some fai= led COPY or APPEND, so obviously relaxing this would be better for us. =

= 5.1 Mailbox Naming

This doesn't solve one of my= naming bugbears.  The spec says things like "servers MAY accept a de-normalized UT= F-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." -<= /i> <= /span>there is no clear way to know what the SELECTable name will be= after creating a mailbox.

If I was designing thi= s myself from scratch I would say that "SELECT of the same octets that were p= assed to CREATE MUST open that same mailbox" or something to that effect.&nb= sp; Since we're messing with how mailbox naming works somewhat for imap4rev2= , I'd be keen to add this restriction on server behaviour so that clients do= n't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" l= oop.
I agree this is a problem and happy to do what you suggest.

It still doesn't mean that you can reliably tell t= he correct octets for the matching mailbox from the LIST response though :(<= br class=3D"">

Is it t= oo late to add a new response code? Something like:

* OK [CREATED] TAG "a123" NAME "Denormalized name"

Response codes are cheap and don=E2=80=99t b= reak older clients, so I am happy to add one.
<= div dir=3D"ltr">

6.3.2 SELECT command

I also saw somewhere t= hat the server can unilaterally send a "* [CLOSED]" response at any point if= it's had to close the mailbox (e.g. it got deleted, or IO errors).  I'= m not sure if that requires opt-in to IMAP4REV2, since otherwise clients wil= l not be aware to watch for it.  This may need to be clarified.  <= /div>

Agreed.

Current beh= aviour of our server right now is to drop the connection entirely, which is u= gly - but it's rare and all clients already need to handle it cleanly, so it= guarantees no messed up data model for the clients.

Yeah, I'd prefer just BYE instead of unilate= ral CLOSED. I don't think clients are going to implement it correctly since i= t almost never happens, so nobody tests that code path.

Let me think about this.

6.3.4 and 6.3= .5 CREATE and DELETE

Can we make it illegal= to "DELETE" a mailbox with children rather than make it a \NoSelect mailbox= pretty pretty please?  I'm just looking at some patches to deal with O= utlook misbehaving with this precise situation, and it's all horrible. = Because of mailboxId requirements for JMAP we've been forced to keep these t= hings around as "intermediate" mailboxes anyway, and it's been the source of= tons of bugs.

\NoSelect seems to be causing confusion in general, and Dovecot now= adays has options that makes it try to avoid creating them. But I'm not sure= if it needs to be made illegal in the RFC itself. I think your server imple= mentation can just decide to reject DELETE if it has children.
It sounds like your issues are with \NoSelect mailbox= es in general, not just this specific way of creating them with DELETE? For e= xample CREATE a/b could create "a" se \NoSelect also.

I am happy to disallow this, or at least say that ser= vers can either disallow delete of a mailbox with children or add \NoSelect t= o it.

6.3.6 RENAME 

I thought we had agreed to s= trongly recommend against clients using RENAME INBOX Other, but maybe I've f= orgotten.  I don't see it in the minutes, so maybe it's just my wishful= thinking.

=
Dovecot doesn't allow RENAME INBOX in some configurations. I don't reme= mber people complaining.

=46rom= the client prospective I am disagreeing with this, renaming INBOX is useful= for archiving.

I am happy to say that some servers= might disallow this though. Would that be Ok with people?

We definitely have a= n option in Cyrus IMAP to make subscriptions follow RENAME.  It's one o= f the warts (largely due to Thunderbird showing greyed out folders and confu= sing people).

We haven't needed to do this yet. I think the \NoSelect folders have= been more of a reason for Thunderbird confusion.

6.3.7 SUBSCRIBE

Speak of the d= evil.  Lots of sites violate the MUST NOT unilaterally remove rule.&nbs= p; Should we weaken it to SHOULD?  The justification for the MUST is "t= he server site might choose to do X" - well, if the server site is doing tha= t, then maybe they SHOULDN'T unilaterally remove the subscriptions, but othe= rwise it's a better user experience and what people want.

(also: by enabling a non-default break the rules config, it's what= our server does!)

The original use case for not auto-removing a subscription is r= ather ancient already. I'd be fine with changing subscriptions to follow del= etes and renames in the rev2 mode (but better not change behavior in rev1 mo= de).

I think I would rather wea= ken this to SHOULD and I would rather not require change in behaviour for se= rvers that already comply with the MUST NOT.

6.3.8 UNSUBSCRIBE<= /b>

<= div style=3D"caret-color: rgb(0, 0, 0); font-size: 12px; font-style: normal;= font-variant-caps: normal; font-weight: normal; letter-spacing: normal; tex= t-align: start; text-indent: 0px; text-transform: none; white-space: normal;= word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; f= ont-family: Arial;" class=3D"">This command returns a tagged O= K response only if the unsubscription is successful. - this is not clear on what happens if the ma= ilbox is not currently subscribed - does it silently succeed, or is there an= expected error?

For what it's worth, our serve= r just says "OK Completed" even if it's already been unsubscrbed - and likew= ise for subscribe if it's already subscribed it just say "yep, all good".

Same wit= h Dovecot. I think should keep the OK behavior, since that's what is commonl= y been done.

I think returning O= K if not subscribed would be a better behaviour for clients. So I would be h= appy to change the text.
=
6.3.10 NAMESPACE

We've c= reated a conflict here.  The NAMESPACE command contains prefix strings f= or the individual namespaces, and says:

   The prefix string allows a client to do things=
 such as automatically
   creating personal mailboxes or LISTing all available mailboxes within
   a namespace.

Which contradicts the advice we= gave back in the LIST command not to use prefix.  Perhaps we should ch= ange the LIST advice to be "only use the empty prefix or prefixes given in t= he NAMESPACE response"?

I think you're mixing "namespace prefixes" with "list refe= rences"? I don't think the above sentence advocates using LIST reference par= ameter, just using the namespace prefix for listing e.g. LIST "" ns-prefix/*=

Exactly.

Anyway, I see lo= ts and lots of text is still preserved for the LIST reference parameter expl= anation, even though it shouldn't be used. Couldn't we just decide to get ri= d of it entirely in rev2 and say the reference MUST be empty? Or say only th= at is is implementation-defined and refer to IMAP4rev1 if anyone wants to se= e how it used to be implemented?

I kept the text because non empty reference is still allowed. I think I wo= uld rather allow it and mark the text as recommended server behaviour if non= empty reference parameter is supplied. Maybe move it to a separate section f= or clarity?

6.3.11 STATUS

      Note: The STATUS command is intended to a=
ccess the status of
      mailboxes other than the currently selected mailbox.  Because the
      STATUS command can cause the mailbox to be opened internally, and
      because this information is available by other means on the
      selected mailbox, the STATUS command SHOULD NOT be used on the
      currently selected mailbox.

This advice i= s all well and good, but it says nothing about what the server may or may no= t do when it gets one of these STATUS commands.  This is particularly r= elevant in the context of LIST RETURN STATUS, where it's hard to construct l= ist patterns which explicitly avoid the currently selected mailbox.

Good p= oint. I think this should be allowed on the selected mailbox.

=

Likewise with the: MUST NOT be used as a "check for new= messages in the selected mailbox"&nbs= p;assertion.  Plenty of clients will do a STATUS run across f= olders and if they're doing LIST RETURN STATUS they're gonna find out about t= he new messages if the server returns it.  Clients can not rely on it w= orking is a more honest representation of what happens.
=


I'd like to see that IMAP4REV2 servers MUST implement STATUS of the cu= rrently selected mailbox.  Yes, it's a special codepath - but if you're= already testing if it's the currently open mailbox then you're at exactly t= he right place to do the right thing:

Also this is the only way to get the current= UIDNEXT of the selected mailbox (since it might be higher than last message= 's UID).

The main ambiguity though is wh= ether STATUS on the current mailbox is expected to check for new changes. Do= vecot implements it in a way that it doesn't check for changes. I think ther= e used to be even a good reason for that.

I am ambivalent on what server behaviour should be in this case. I= am Ok with saying that the client can=E2=80=99t expect the server to check f= or changes.

6.4.4.1 SAVE Result

I'm not sure I= understand the interaction here with closing and re-opening a mailbox. = ; I would expect that closing a mailbox would wipe the SAVED result,
<= /div>

I think it practically says= that, since it says that SELECT/EXAMINE resets it to empty sequence. It's n= ot really relevant whether it happens when the mailbox is closed or when the= next mailbox is opened, because you can't use it in non-selected state anyw= ay..

Exactly :-).

and that tryin= g to use a SAVED result when there isn't one should return an error.

It says that t= he default is an empty sequence. So it won't result in an error, just a non-= matching set. I'm fine with this behavior, especially since it's easier to i= mplement and I don't really see much of a downside.

Same here. That was the intent.

Speaking of which, Example= 5 is wrong: It says that the second search command leads to the variable co= ntaining no messages, but the second search command did not contain the RETU= RN SAVE option, so it should not have altered the variable.

Right. And even if it d= id contain RETURN SAVE option it still shouldn't have altered the variable, b= ecause:

"""
   Any of the following SEARCH commands MUST NOT change t= he search
   result variable:

      a SEARCH command that cau= sed the server to return the BAD tagged
    &= nbsp; response,
"""
=

Ok, I will recheck the example.
=

= 7.4.2 FETCH Response
=
I remember past bugs wi= th UID in "unsolicited" FLAGS responses.  Do we need to require that in= cluding UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)= ?

Migh= t be useful to require UID for any untagged FETCH reply. It can simplify cli= ent behavior.

I think we agreed= to this. I think I mention this for IDLE, but didn=E2=80=99t say it in this= section. What is the best place for this text?

Bes= t Regards,
Alexey

= --Apple-Mail-DE4E868C-70B5-447A-AC33-73B87F07AF73-- From nobody Sun Feb 2 07:16:43 2020 Return-Path: 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 AF19E12003F for ; Sun, 2 Feb 2020 07:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6jqzA5CoJIxM for ; Sun, 2 Feb 2020 07:16:38 -0800 (PST) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id A53381200DF for ; Sun, 2 Feb 2020 07:16:37 -0800 (PST) Received: from [192.168.10.104] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 340222B3C8B; Sun, 2 Feb 2020 15:16:36 +0000 (UTC) From: Timo Sirainen Message-Id: <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1831F738-855A-4ABC-BF6B-66FF611EE8B6" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Sun, 2 Feb 2020 17:16:34 +0200 In-Reply-To: <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> Cc: extra@ietf.org To: Alexey Melnikov References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 15:16:42 -0000 --Apple-Mail=_1831F738-855A-4ABC-BF6B-66FF611EE8B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 1. Feb 2020, at 21.00, Alexey Melnikov = wrote: >=20 > Hi, >=20 > On 29 Jan 2020, at 14:20, Timo Sirainen > wrote: >=20 >> On 29. Jan 2020, at 14.08, Bron Gondwana > wrote: >>>=20 >>> 2.2.1 Client protocol >>>=20 >>> "A different tag is generated by the client for each command". = There's no "MUST" on this, and certainly I've seen clients which don't. = Do we want to make that more strict in rev2? It would be a bit of a = pain on the commandline where I normally use ".", but it's also annoying = as a server author that you can't rely on tag uniqueness. >>>=20 >>> Maybe the client SHOULD generate a different tag for every command, = but a server MUST accept tag reuse (could restrict concurrency, a tag = can only be reused after it's been "returned") >>=20 >> I haven't seen this as a problem, so I don't really care either way. >=20 > I don=E2=80=99t see this as a problem and I don=E2=80=99t want to make = the server check for reuse. >=20 > I am Ok with adding informative suggestion for clients to generate = unique tags to ease in debugging issues. Would this work for people? Fine with me. >>> It still doesn't mean that you can reliably tell the correct octets = for the matching mailbox from the LIST response though :( >>=20 >> Is it too late to add a new response code? Something like: >>=20 >> * OK [CREATED] TAG "a123" NAME "Denormalized name" >=20 > Response codes are cheap and don=E2=80=99t break older clients, so I = am happy to add one. I guess an optional reply which can send both the changed name and/or = mailboxid. Maybe something like: * OK [CREATED] TAG "a123" NAME "Denormalized name" MAILBOXID "123456" Although I'm not sure if some part of it would be nicer inside = parenthesis. >>> 6.3.6 RENAME=20 >>>=20 >>> I thought we had agreed to strongly recommend against clients using = RENAME INBOX Other, but maybe I've forgotten. I don't see it in the = minutes, so maybe it's just my wishful thinking. >>=20 >> Dovecot doesn't allow RENAME INBOX in some configurations. I don't = remember people complaining. >=20 > =46rom the client prospective I am disagreeing with this, renaming = INBOX is useful for archiving. >=20 > I am happy to say that some servers might disallow this though. Would = that be Ok with people? Fine with me. >>> 6.3.7 SUBSCRIBE >>>=20 >>> Speak of the devil. Lots of sites violate the MUST NOT unilaterally = remove rule. Should we weaken it to SHOULD? The justification for the = MUST is "the server site might choose to do X" - well, if the server = site is doing that, then maybe they SHOULDN'T unilaterally remove the = subscriptions, but otherwise it's a better user experience and what = people want. >>>=20 >>> (also: by enabling a non-default break the rules config, it's what = our server does!) >>=20 >> The original use case for not auto-removing a subscription is rather = ancient already. I'd be fine with changing subscriptions to follow = deletes and renames in the rev2 mode (but better not change behavior in = rev1 mode). >=20 > I think I would rather weaken this to SHOULD and I would rather not = require change in behaviour for servers that already comply with the = MUST NOT. But is the MUST NOT or SHOULD NOT behavior wanted nowadays anymore? = Especially subscriptions not following RENAME is annoying for clients = because they have to explicitly transfer the subscription as well. So my = suggestion would be that if ENABLE IMAP4rev2 is used then subscriptions = would follow RENAME/DELETE. >>> 6.3.10 NAMESPACE >>>=20 >>> We've created a conflict here. The NAMESPACE command contains = prefix strings for the individual namespaces, and says: >>>=20 >>> The prefix string allows a client to do things such as = automatically >>> creating personal mailboxes or LISTing all available mailboxes = within >>> a namespace. >>>=20 >>> Which contradicts the advice we gave back in the LIST command not to = use prefix. Perhaps we should change the LIST advice to be "only use = the empty prefix or prefixes given in the NAMESPACE response"? >>=20 >> I think you're mixing "namespace prefixes" with "list references"? I = don't think the above sentence advocates using LIST reference parameter, = just using the namespace prefix for listing e.g. LIST "" ns-prefix/* >=20 > Exactly. >>=20 >> Anyway, I see lots and lots of text is still preserved for the LIST = reference parameter explanation, even though it shouldn't be used. = Couldn't we just decide to get rid of it entirely in rev2 and say the = reference MUST be empty? Or say only that is is implementation-defined = and refer to IMAP4rev1 if anyone wants to see how it used to be = implemented? >=20 > I kept the text because non empty reference is still allowed. I think = I would rather allow it and mark the text as recommended server = behaviour if non empty reference parameter is supplied. Maybe move it to = a separate section for clarity? I think a separate section would be clearer. >>> 7.4.2 FETCH Response >=20 >>>=20 >>> I remember past bugs with UID in "unsolicited" FLAGS responses. Do = we need to require that including UID only happen after ENABLE IMAP4REV2 = (as it is for ENABLE QRESYNC)? >>=20 >> Might be useful to require UID for any untagged FETCH reply. It can = simplify client behavior. >=20 > I think we agreed to this. I think I mention this for IDLE, but = didn=E2=80=99t say it in this section. What is the best place for this = text? Maybe near the beginning of the 7.4.2 section?= --Apple-Mail=_1831F738-855A-4ABC-BF6B-66FF611EE8B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 1. Feb 2020, at 21.00, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

Hi,

On 29 Jan 2020, at 14:20, Timo Sirainen <timo@sirainen.com> = wrote:

On 29. Jan 2020, at 14.08, Bron = Gondwana <brong@fastmailteam.com> wrote:

2.2.1 Client = protocol

"A different tag is generated by the client for = each command".  There's no "MUST" on this, and certainly I've = seen clients which don't.  Do we want to make that more strict in = rev2?  It would be a bit of a pain on the commandline where I = normally use ".", but it's also annoying as a server author that you = can't rely on tag uniqueness.

Maybe the client SHOULD generate a different tag for every = command, but a server MUST accept tag reuse (could restrict concurrency, = a tag can only be reused after it's been "returned")

I haven't seen this as a problem, so I = don't really care either way.

I don=E2=80=99t see this as a problem = and I don=E2=80=99t want to make the server check for reuse.

I am Ok with adding = informative suggestion for clients to generate unique tags to ease in = debugging issues. Would this work for people?

Fine with me.

It still doesn't mean that you can reliably = tell the correct octets for the matching mailbox from the LIST response = though :(

Is it too late to add a new response = code? Something like:

* OK [CREATED] TAG "a123" NAME "Denormalized = name"

Response codes are cheap and don=E2=80=99t break older = clients, so I am happy to add one.

I= guess an optional reply which can send both the changed name and/or = mailboxid. Maybe something like:

* = OK [CREATED] TAG "a123" NAME "Denormalized name" MAILBOXID = "123456"

Although I'm not sure if = some part of it would be nicer inside parenthesis.

6.3.6 = RENAME 

I thought we had agreed to = strongly recommend against clients using RENAME INBOX Other, but maybe = I've forgotten.  I don't see it in the minutes, so maybe it's just = my wishful thinking.

Dovecot doesn't allow = RENAME INBOX in some configurations. I don't remember people = complaining.

=46rom the client prospective I am disagreeing with = this, renaming INBOX is useful for archiving.

I am happy to say that some servers = might disallow this though. Would that be Ok with people?

Fine with me.

6.3.7 = SUBSCRIBE

Speak of the devil.  = Lots of sites violate the MUST NOT unilaterally remove rule.  = Should we weaken it to SHOULD?  The justification for the MUST is = "the server site might choose to do X" - well, if the server site is = doing that, then maybe they SHOULDN'T unilaterally remove the = subscriptions, but otherwise it's a better user experience and what = people want.

(also: by enabling a = non-default break the rules config, it's what our server does!)

The original use case for not = auto-removing a subscription is rather ancient already. I'd be fine with = changing subscriptions to follow deletes and renames in the rev2 mode = (but better not change behavior in rev1 = mode).

I think I would rather weaken this to SHOULD and I = would rather not require change in behaviour for servers that already = comply with the MUST NOT.

But is the MUST NOT or SHOULD NOT behavior wanted = nowadays anymore? Especially subscriptions not following RENAME is = annoying for clients because they have to explicitly transfer the = subscription as well. So my suggestion would be that if ENABLE IMAP4rev2 = is used then subscriptions would follow RENAME/DELETE.

6.3.10 = NAMESPACE

We've created a conflict here.  The = NAMESPACE command contains prefix strings for the individual namespaces, = and says:

   The =
prefix string allows a client to do things such as automatically
   creating personal mailboxes or LISTing all available mailboxes within
   a namespace.

Which contradicts the advice = we gave back in the LIST command not to use prefix.  Perhaps we = should change the LIST advice to be "only use the empty prefix or = prefixes given in the NAMESPACE response"?

I think you're mixing "namespace = prefixes" with "list references"? I don't think the above sentence = advocates using LIST reference parameter, just using the namespace = prefix for listing e.g. LIST "" = ns-prefix/*

Exactly.
Anyway, I see lots and lots of text is = still preserved for the LIST reference parameter explanation, even = though it shouldn't be used. Couldn't we just decide to get rid of it = entirely in rev2 and say the reference MUST be empty? Or say only that = is is implementation-defined and refer to IMAP4rev1 if anyone wants to = see how it used to be implemented?

I kept the text because non empty = reference is still allowed. I think I would rather allow it and mark the = text as recommended server behaviour if non empty reference parameter is = supplied. Maybe move it to a separate section for clarity?

I = think a separate section would be clearer.

7.4.2 FETCH = Response

I remember past bugs with = UID in "unsolicited" FLAGS responses.  Do we need to require that = including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE = QRESYNC)?

Might be useful to require UID for any = untagged FETCH reply. It can simplify client = behavior.

I think we agreed to this. I think I mention this for = IDLE, but didn=E2=80=99t say it in this section. What is the best place = for this text?

Maybe = near the beginning of the 7.4.2 section?
= --Apple-Mail=_1831F738-855A-4ABC-BF6B-66FF611EE8B6-- From nobody Tue Feb 4 10:15:17 2020 Return-Path: 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 98ECF120143 for ; Tue, 4 Feb 2020 10:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.736 X-Spam-Level: X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 ezNuv18y4B8k for ; Tue, 4 Feb 2020 10:15:15 -0800 (PST) Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 99AF512013B for ; Tue, 4 Feb 2020 10:15:15 -0800 (PST) Received: (qmail 39639 invoked from network); 4 Feb 2020 18:15:15 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (AES128-SHA encrypted) SMTP (4a9390de-477a-11ea-94f8-bf1f0e42464a); Tue, 04 Feb 2020 10:15:15 -0800 From: Michael Peddemors To: extra@ietf.org, ietf-smtp@ietf.org, kitten@ietf.org Organization: LinuxMagic Inc. Message-ID: <0b833564-8502-c100-4c4b-c94937e4f40d@linuxmagic.com> Date: Tue, 4 Feb 2020 10:15:15 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 4a9390de-477a-11ea-94f8-bf1f0e42464a X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: [Extra] [FEEDBACK REQUEST] "Birds of a Feather (BOF)" on Email Security X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:15:16 -0000 It was suggested I cross post to these list(s), with only a few days left before the deadline for requesting a "Birds of a Feather" session, I am proposing that a meeting be held in Vancouver for a BOF suggestion surrounding all those that are interested in solving problems around email security. Specifically, to determine how wide or narrow the scope of such a session should be.. we can discuss how IETF can weigh in some of our largest threats (such as POP and SMTP authentication over unencrypted networks is still enshrined in RFC's) various proposals for multi-factor authentication, improvements to the protocols to support other methods, such as our own CLIENTID as trust factors, access control tools, or two factor authentication, and any other topics that span across all email protocols. Email security is one of the largest threats today, and it is an opportunity to weigh in what role the IETF can play in improving the situation. The thread is posted on the 'art@ietf.org' mailing list, and would like to see your feedback on what other cross protocol issues might be included, and or discussed as part of this BOF. And of course, please feel free to chime in if you feel that this BOF should be more narrowly focused, or wider focused. -- Michael -- PS, Look forward to seeing everyone in Vancouver. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "MagicSpam" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Thu Feb 6 17:31:07 2020 Return-Path: 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 69BAB120143 for ; Tue, 4 Feb 2020 10:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.736 X-Spam-Level: X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 SAdKJX7sRaWA for ; Tue, 4 Feb 2020 10:13:48 -0800 (PST) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBA612013B for ; Tue, 4 Feb 2020 10:13:48 -0800 (PST) Received: (qmail 7203 invoked from network); 4 Feb 2020 18:07:08 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (AES128-SHA encrypted) SMTP (27f38dc8-4779-11ea-b3af-ff3a3e9809f1); Tue, 04 Feb 2020 10:07:08 -0800 To: extra@ietf.org, ietf-smtp@ietf.org, kitten@ietf.org From: Michael Message-ID: <76331382-04b0-383d-2998-e3833dc15af5@wizard.ca> Date: Tue, 4 Feb 2020 10:07:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: 27f38dc8-4779-11ea-b3af-ff3a3e9809f1 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: X-Mailman-Approved-At: Thu, 06 Feb 2020 17:31:06 -0800 Subject: [Extra] [FEEDBACK REQUEST] "Birds of a Feather (BOF)" on Email Security X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:13:49 -0000 It was suggested I cross post to these list(s), with only a few days left before the deadline for requesting a "Birds of a Feather" session, I am proposing that a meeting be held in Vancouver for a BOF suggestion surrounding all those that are interested in solving problems around email security. Specifically, to determine how wide or narrow the scope of such a session should be.. we can discuss how IETF can weigh in some of our largest threats (such as POP and SMTP authentication over unencrypted networks is still enshrined in RFC's) various proposals for multi-factor authentication, improvements to the protocols to support other methods, such as our own CLIENTID as trust factors, access control tools, or two factor authentication, and any other topics that span across all email protocols. Email security is one of the largest threats today, and it is an opportunity to weigh in what role the IETF can play in improving the situation. The thread is posted on the 'art@ietf.org' mailing list, and would like to see your feedback on what other cross protocol issues might be included, and or discussed as part of this BOF. And of course, please feel free to chime in if you feel that this BOF should be more narrowly focused, or wider focused. -- Michael -- PS, Look forward to seeing everyone in Vancouver. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "MagicSpam" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Thu Feb 6 20:04:25 2020 Return-Path: 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 6B542120132 for ; Thu, 6 Feb 2020 20:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=3FDI0Pa6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iEx2JEiA 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 gM4fb-cg2C4B for ; Thu, 6 Feb 2020 20:04:21 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D7D12001B for ; Thu, 6 Feb 2020 20:04:20 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2000721C4E for ; Thu, 6 Feb 2020 23:04:19 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute6.internal (MEProxy); Thu, 06 Feb 2020 23:04:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=qOlghsy P78QdUrwc+XBKAeym8B6GwVhoYODqzyRt7No=; b=3FDI0Pa6ZXYojo+xxi/c64A YK3egV3cKyosC9qoGqb8Yq+wMbECNhOnVlYOCGkJaYW2Js/SJr92FMrekR6vLaKX LGLYpmZ/Tj7gp1U5GwEVDv8DeVvjt4Gl06fIg4tA/Kt92rLvUWoofO48BChHqR0h CjcP98pm17ibn1U8b32rd+kUjQ6VtY8SMJcz0+m4qQmNhGfNhezXFIl1tVoVBFqP 5pJgOaxAz9n5dZQqZ3tWkZ1ux64Kk9APrvT5JqDd9LGjO9L3eaSCnDgXHUQL0rxn 2tL2DzHEsm1LFlSMhRnIZC8GZO3dtu2tMP5fsbsu5+8OVAWNAl3dVYhKNtwd6YQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qOlghs yP78QdUrwc+XBKAeym8B6GwVhoYODqzyRt7No=; b=iEx2JEiA4ovC6hz/Sk6Pk9 1SWzqjMkmTOoLtQrIJtzxK+5CYsqx61spC/pKk9wIVZr3iU65IaB53t6NHSeAIR7 L+YU66mBklAiSQ33CXumelET8mFnwiIHzN5cmmJ9K/+kgiDkXdR85Q+ZE4GtPB0e Dz3x3lzyOfkYeFYIUm6N3DG6fkPwycBrcg00elpsLu1EyQarnqpHOS9FgDLmdaRs OD/LWGg8VcE0JvVsuiRibuzahrQ9pqYd6X13yN+CyVElfOUn4F8ZPLFpxBdytCbI yMVUme8ahmtq1o4v1w5WnVBL/yltSe6uEZaviYbN7PfKkiM7GpDF7WVavvAG/YvA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheeggdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1B20524009E; Thu, 6 Feb 2020 23:04:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-871-gf1112c6-fmnext-20200202v1 Mime-Version: 1.0 Message-Id: <0f234581-1648-4549-b80f-3af97b3d1080@beta.fastmail.com> In-Reply-To: <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> Date: Fri, 07 Feb 2020 15:03:51 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=56e8d93d035d4e0791983b97c3d9a487 Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 04:04:23 -0000 --56e8d93d035d4e0791983b97c3d9a487 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alexey, I agree with all the things Timo said. I've added a couple more comments= below. Do you want me to create github issues to track each thing, or are you h= appy that you know what changes are needed? Again - sorry for the late final review and hence pushing the timeline b= ack on this. Cheers, Bron. On Sun, Feb 2, 2020, at 06:00, Alexey Melnikov wrote: > On 29 Jan 2020, at 14:20, Timo Sirainen > wrote: >> Is it too late to add a new response code? Something like: >>=20 >> * OK [CREATED] TAG "a123" NAME "Denormalized name" >=20 > Response codes are cheap and don=E2=80=99t break older clients, so I a= m happy to add one. Along with the instruction to add MAILBOXID if RFC8474 is supported, I'm= good with this. >> Current behaviour of our server right now is to drop the connection e= ntirely, which is ugly - but it's rare and all clients already need to h= andle it cleanly, so it guarantees no messed up data model for the clien= ts. >>=20 >> Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't think= clients are going to implement it correctly since it almost never happe= ns, so nobody tests that code path. >=20 > Let me think about this. We still need a decision on this. I'm going to keep dropping connections= regardless in this rare case, because there's a horrible long tail of c= lients, and debugging their broken caches if we ever confuse them is ver= y difficult. >> It sounds like your issues are with \NoSelect mailboxes in general, n= ot just this specific way of creating them with DELETE? For example CREA= TE a/b could create "a" se \NoSelect also. >=20 > I am happy to disallow this, or at least say that servers can either d= isallow delete of a mailbox with children or add \NoSelect to it. Sounds good to me. Allowing the disallow is enough :) >>=20 >>> *6.3.6 RENAME * >>>=20 >>> I thought we had agreed to strongly recommend against clients using = RENAME INBOX Other, but maybe I've forgotten. I don't see it in the minu= tes, so maybe it's just my wishful thinking. >>=20 >> Dovecot doesn't allow RENAME INBOX in some configurations. I don't re= member people complaining. >=20 > From the client prospective I am disagreeing with this, renaming INBOX= is useful for archiving. >=20 > I am happy to say that some servers might disallow this though. Would = that be Ok with people? Works for me. >>=20 >>> We definitely have an option in Cyrus IMAP to make subscriptions fol= low RENAME. It's one of the warts (largely due to Thunderbird showing gr= eyed out folders and confusing people). >>=20 >> We haven't needed to do this yet. I think the \NoSelect folders have = been more of a reason for Thunderbird confusion. >>=20 >>> *6.3.7 SUBSCRIBE* >>>=20 >>> Speak of the devil. Lots of sites violate the MUST NOT unilaterally = remove rule. Should we weaken it to SHOULD? The justification for the MU= ST is "the server site might choose to do X" - well, if the server site = is doing that, then maybe they SHOULDN'T unilaterally remove the subscri= ptions, but otherwise it's a better user experience and what people want= . >>>=20 >>> (also: by enabling a non-default break the rules config, it's what o= ur server does!) >>=20 >> The original use case for not auto-removing a subscription is rather = ancient already. I'd be fine with changing subscriptions to follow delet= es and renames in the rev2 mode (but better not change behavior in rev1 = mode). >=20 > I think I would rather weaken this to SHOULD and I would rather not re= quire change in behaviour for servers that already comply with the MUST = NOT. Yeah, totally. I'm fine with SHOULD, and I don't care about=20 >>=20 >>> *6.3.10 NAMESPACE* >>>=20 >>> We've created a conflict here. The NAMESPACE command contains prefix= strings for the individual namespaces, and says: >>>=20 >>> The prefix string allows a client to do things such as automatica= lly creating personal mailboxes or LISTing all available mailboxes within= a namespace. >>>=20 >>> Which contradicts the advice we gave back in the LIST command not to= use prefix. Perhaps we should change the LIST advice to be "only use th= e empty prefix or prefixes given in the NAMESPACE response"? >>=20 >> I think you're mixing "namespace prefixes" with "list references"? I = don't think the above sentence advocates using LIST reference parameter,= just using the namespace prefix for listing e.g. LIST "" ns-prefix/* >=20 > Exactly. >>=20 >> Anyway, I see lots and lots of text is still preserved for the LIST r= eference parameter explanation, even though it shouldn't be used. Couldn= 't we just decide to get rid of it entirely in rev2 and say the referenc= e MUST be empty? Or say only that is is implementation-defined and refer= to IMAP4rev1 if anyone wants to see how it used to be implemented? >=20 > I kept the text because non empty reference is still allowed. I think = I would rather allow it and mark the text as recommended server behaviou= r if non empty reference parameter is supplied. Maybe move it to a separ= ate section for clarity? I don't think any change is needed here, sorry for adding confusion. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --56e8d93d035d4e0791983b97c3d9a487 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

=
I agree with all the things Timo= said. I've added a couple more comments below.

Do you wa= nt me to create github issues to track each thing, or are you happy that= you know what changes are needed?

Again - sorry for the = late final review and hence pushing the timeline back on this.
=

Cheers,

Bron.
=


On Sun, Feb 2, 2020, a= t 06:00, Alexey Melnikov wrote:
On 29 Jan 2020, = at 14:20, Timo Sirainen <timo@s= irainen.com> wrote:
Is it too late to add a new response code? Something lik= e:

* OK [CREATED] TAG "a123" NAME "Denormal= ized name"

Respons= e codes are cheap and don=E2=80=99t break older clients, so I am happy t= o add one.

Along with the instru= ction to add MAILBOXID if RFC8474 is supported, I'm good with this.
<= /div>

Current behaviour of our server right now = is to drop the connection entirely, which is ugly - but it's rare and al= l clients already need to handle it cleanly, so it guarantees no messed = up data model for the clients.

Yeah, I'd pr= efer just BYE instead of unilateral CLOSED. I don't think clients are go= ing to implement it correctly since it almost never happens, so nobody t= ests that code path.

Let me think about this.

We s= till need a decision on this.  I'm going to keep dropping connectio= ns regardless in this rare case, because there's a horrible long tail of= clients, and debugging their broken caches if we ever confuse them is v= ery difficult.

It sounds like your issues are with \N= oSelect mailboxes in general, not just this specific way of creating the= m with DELETE? For example CREATE a/b could create "a" se \NoSelect also= .

I am happy to di= sallow this, or at least say that servers can either disallow delete of = a mailbox with children or add \NoSelect to it.

Sounds good to me.  Allowing the disallow is enough= :)


6.3.6 RE= NAME 
=

I thought = we had agreed to strongly recommend against clients using RENAME INBOX O= ther, but maybe I've forgotten.  I don't see it in the minutes, so = maybe it's just my wishful thinking.
Dovecot doesn't allow RENAME INBOX in some configurations. = I don't remember people complaining.
<= div>
From the client prospective I am disagreeing with thi= s, renaming INBOX is useful for archiving.

I am happy to say that some servers might disallow this thoug= h. Would that be Ok with people?

Works for me.


We definitely h= ave an option in Cyrus IMAP to make subscriptions follow RENAME.  I= t's one of the warts (largely due to Thunderbird showing greyed out fold= ers and confusing people).

We haven't needed to do this yet. I think the \NoSelect folders have = been more of a reason for Thunderbird confusion.

6.3.7 SUBSCRIBE

Speak of the devil.&nbs= p; Lots of sites violate the MUST NOT unilaterally remove rule.  Sh= ould we weaken it to SHOULD?  The justification for the MUST is "th= e server site might choose to do X" - well, if the server site is doing = that, then maybe they SHOULDN'T unilaterally remove the subscriptions, b= ut otherwise it's a better user experience and what people want.

(also: b= y enabling a non-default break the rules config, it's what our server do= es!)

The original use ca= se for not auto-removing a subscription is rather ancient already. I'd b= e fine with changing subscriptions to follow deletes and renames in the = rev2 mode (but better not change behavior in rev1 mode).
=

I think I would rather weaken thi= s to SHOULD and I would rather not require change in behaviour for serve= rs that already comply with the MUST NOT.

Yeah, totally.  I'm fine with SHOULD, and I don't care ab= out


6.3.10 = NAMESPACE

We've created a conflict here.  The NAMESPACE command = contains prefix strings for the individual namespaces, and says:

   The prefix string allows a client to do th=
ings such as automatically
   creating personal mailboxes or LISTing all available mailboxes within=

   a namespace.

Which contradicts the advice we gave back in the LIST comma= nd not to use prefix.  Perhaps we should change the LIST advice to = be "only use the empty prefix or prefixes given in the NAMESPACE respons= e"?

I think you're mixin= g "namespace prefixes" with "list references"? I don't think the above s= entence advocates using LIST reference parameter, just using the namespa= ce prefix for listing e.g. LIST "" ns-prefix/*

Exactly.

Anyway, I see lots and lots o= f text is still preserved for the LIST reference parameter explanation, = even though it shouldn't be used. Couldn't we just decide to get rid of = it entirely in rev2 and say the reference MUST be empty? Or say only tha= t is is implementation-defined and refer to IMAP4rev1 if anyone wants to= see how it used to be implemented?

I kept the text because non empty reference is still a= llowed. I think I would rather allow it and mark the text as recommended= server behaviour if non empty reference parameter is supplied. Maybe mo= ve it to a separate section for clarity?

I don't think any change is needed here, sorry for adding confu= sion.


--
  Bron Gondwana, CEO, = Fastmail Pty Ltd
  brong@fastmail= team.com


--56e8d93d035d4e0791983b97c3d9a487-- From nobody Fri Feb 7 05:32:18 2020 Return-Path: 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 9B07D12086A for ; Fri, 7 Feb 2020 05:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 m7BJX-n3nkTB for ; Fri, 7 Feb 2020 05:32:14 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C4CF3120869 for ; Fri, 7 Feb 2020 05:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1581082333; d=isode.com; s=june2016; i=@isode.com; bh=WyDAM/nhb0Y7BlXo3cTjUCpX/i3WH3KOU4iFfWYYSss=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=EKuO9YnxQLe0wG37XCmbJG6m0zzY82tKmkntKCHKqqQk5dzuoeua/lBQe1laqcMa2gep1S 1iL0fjJJ13K+2zRgDudUqA6c15elfB7bz130W5m6vBCPfZJl5BThwras+rKwyQIUM4590R 32QflmZAtu4XhpLO3plboqKRA94eUOo=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 7 Feb 2020 13:32:12 +0000 To: Bron Gondwana , extra@ietf.org References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <0f234581-1648-4549-b80f-3af97b3d1080@beta.fastmail.com> From: Alexey Melnikov Message-ID: Date: Fri, 7 Feb 2020 13:31:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: <0f234581-1648-4549-b80f-3af97b3d1080@beta.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6EC6D6D1427D7F983C6AEB8C" Content-Language: en-US Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 13:32:17 -0000 --------------6EC6D6D1427D7F983C6AEB8C Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Bron, On 07/02/2020 04:03, Bron Gondwana wrote: > Hi Alexey, > > I agree with all the things Timo said. I've added a couple more=20 > comments below. I started replying to your emails and applied some changes, but I=20 haven't done all of them. I will send an email on this. > Do you want me to create github issues to track each thing, or are you=20 > happy that you know what changes are needed? I think I am Ok for now without tracking issues in github. > Again - sorry for the late final review and hence pushing the timeline=20 > back on this. No worries. Best Regards, Alexey > > Cheers, > > Bron. > > > On Sun, Feb 2, 2020, at 06:00, Alexey Melnikov wrote: >> On 29 Jan 2020, at 14:20, Timo Sirainen > > wrote: >>> Is it too late to add a new response code? Something like: >>> >>> * OK [CREATED] TAG "a123" NAME "Denormalized name" >> >> Response codes are cheap and don=E2=80=99t break older clients, so I am h= appy=20 >> to add one. > > Along with the instruction to add MAILBOXID if RFC8474 is supported,=20 > I'm good with this. > >>> Current behaviour of our server right now is to drop the connection=20 >>> entirely, which is ugly - but it's rare and all clients already need=20 >>> to handle it cleanly, so it guarantees no messed up data model for=20 >>> the clients. >>> >>> Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't=20 >>> think clients are going to implement it correctly since it almost=20 >>> never happens, so nobody tests that code path. >> >> Let me think about this. > > We still need a decision on this. I'm going to keep dropping=20 > connections regardless in this rare case, because there's a horrible=20 > long tail of clients, and debugging their broken caches if we ever=20 > confuse them is very difficult. > >>> It sounds like your issues are with \NoSelect mailboxes in general,=20 >>> not just this specific way of creating them with DELETE? For example=20 >>> CREATE a/b could create "a" se \NoSelect also.. >> >> I am happy to disallow this, or at least say that servers can either=20 >> disallow delete of a mailbox with children or add \NoSelect to it. > > Sounds good to me.=C2=A0 Allowing the disallow is enough :) > >>> >>>> *6.3.6 RENAME* >>>> >>>> I thought we had agreed to strongly recommend against clients using=20 >>>> RENAME INBOX Other, but maybe I've forgotten.=C2=A0 I don't see it in= =20 >>>> the minutes, so maybe it's just my wishful thinking. >>> >>> Dovecot doesn't allow RENAME INBOX in some configurations. I don't=20 >>> remember people complaining. >> >> From the client prospective I am disagreeing with this, renaming=20 >> INBOX is useful for archiving. >> >> I am happy to say that some servers might disallow this though. Would=20 >> that be Ok with people? > > Works for me. > >>> >>>> We definitely have an option in Cyrus IMAP to make subscriptions=20 >>>> follow RENAME.=C2=A0 It's one of the warts (largely due to Thunderbird= =20 >>>> showing greyed out folders and confusing people). >>> >>> We haven't needed to do this yet. I think the \NoSelect folders have=20 >>> been more of a reason for Thunderbird confusion. >>> >>>> *6.3.7 SUBSCRIBE* >>>> >>>> Speak of the devil.=C2=A0 Lots of sites violate the MUST NOT=20 >>>> unilaterally remove rule.=C2=A0 Should we weaken it to SHOULD?=C2=A0 Th= e=20 >>>> justification for the MUST is "the server site might choose to do=20 >>>> X" - well, if the server site is doing that, then maybe they=20 >>>> SHOULDN'T unilaterally remove the subscriptions, but otherwise it's=20 >>>> a better user experience and what people want. >>>> >>>> (also: by enabling a non-default break the rules config, it's what=20 >>>> our server does!) >>> >>> The original use case for not auto-removing a subscription is rather=20 >>> ancient already. I'd be fine with changing subscriptions to follow=20 >>> deletes and renames in the rev2 mode (but better not change behavior=20 >>> in rev1 mode). >> >> I think I would rather weaken this to SHOULD and I would rather not=20 >> require change in behaviour for servers that already comply with the=20 >> MUST NOT. > > Yeah, totally.=C2=A0 I'm fine with SHOULD, and I don't care about > >>> >>>> *6.3.10 NAMESPACE* >>>> >>>> We've created a conflict here.=C2=A0 The NAMESPACE command contains=20 >>>> prefix strings for the individual namespaces, and says: >>>> >>>> The prefix string allows a client to do things such as automaticall= y >>>> creating personal mailboxes or LISTing all available mailboxes with= in >>>> a namespace. >>>> >>>> Which contradicts the advice we gave back in the LIST command not=20 >>>> to use prefix.=C2=A0 Perhaps we should change the LIST advice to be=20 >>>> "only use the empty prefix or prefixes given in the NAMESPACE=20 >>>> response"? >>> >>> I think you're mixing "namespace prefixes" with "list references"? I=20 >>> don't think the above sentence advocates using LIST reference=20 >>> parameter, just using the namespace prefix for listing e.g. LIST ""=20 >>> ns-prefix/* >> >> Exactly. >>> >>> Anyway, I see lots and lots of text is still preserved for the LIST=20 >>> reference parameter explanation, even though it shouldn't be used.=20 >>> Couldn't we just decide to get rid of it entirely in rev2 and say=20 >>> the reference MUST be empty? Or say only that is is=20 >>> implementation-defined and refer to IMAP4rev1 if anyone wants to see=20 >>> how it used to be implemented? >> >> I kept the text because non empty reference is still allowed. I think=20 >> I would rather allow it and mark the text as recommended server=20 >> behaviour if non empty reference parameter is supplied. Maybe move it=20 >> to a separate section for clarity? > > I don't think any change is needed here, sorry for adding confusion. > > > -- > =C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd > =C2=A0 brong@fastmailteam.com > > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra --------------6EC6D6D1427D7F983C6AEB8C Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Bron,

On 07/02/2020 04:03, Bron Gondwana wrote:
Hi Alexey,

I agree with all the things Timo said. I've added a couple more comments below.
I started replying to your emails and applied some changes, but I haven't done all of them. I will send an email on this.
Do you want me to create github issues to track each thing, or are you happy that you know what changes are needed?
I think I am Ok for now without tracking issues in github.
Again - sorry for the late final review and hence pushing the timeline back on this.

No worries.


Best Regards,

Alexey


Cheers,

Bron.


On Sun, Feb 2, 2020, at 06:00, Alexey Melnikov wrote:
On 29 Jan 2020, at 14:20, Timo Sirainen <= timo@sirainen.com> wrote:
Is it too late to add a new response code? Something like:

* OK [CREATED] TAG "a123" NAME "Denormalized name"

Response codes are cheap and don=E2=80=99t break older clie= nts, so I am happy to add one.

Along with the instruction to add MAILBOXID if RFC8474 is supported, I'm good with this.

Current behaviour of our server right now is to drop the connection entirely, which is ugly - but it's rare and all clients already need to handle it cleanly, so it guarantees no messed up data model for the clients.

Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't think clients are going to implement it correctly since it almost never happens, so nobody tests that code path.

Let me think about this.

We still need a decision on this.=C2= =A0 I'm going to keep dropping connections regardless in this rare case, because there's a horrible long tail of clients, and debugging their broken caches if we ever confuse them is very difficult.

It sounds like your issues are with \NoSelect mailboxes in general, not just this specific way of creating them with DELETE? For example CREATE a/b could create "a" se \NoSelect also..

I am happy to disallow this, or at least say that servers can either disallow delete of a mailbox with children or add \NoSelect to it.

Sounds good to me.=C2=A0 Allowing th= e disallow is enough :)


6.3.6 RENAME=C2=A0=

I thought we had agreed to strongly recommend against clients using RENAME INBOX Other, but maybe I've forgotten.=C2=A0 I don't see it in the minutes, so maybe it's just my wishful thinking.

Dovecot doesn't allow RENAME INBOX in some configurations. I don't remember people complaining.

From the client prospective I am disagreeing with this, renaming INBOX is useful for archiving.

I am happy to say that some servers might disallow this though. Would that be Ok with people?

Works for me.


We definitely have an option in Cyrus IMAP to make subscriptions follow RENAME.=C2=A0 It's one of the warts (largely due to Thunderbird showing greyed out folders and confusing people).

We haven't needed to do this yet. I think the \NoSelect folders have been more of a reason for Thunderbird confusion.

6.3.7 SUBSCRIBE

Speak of the devil.=C2=A0 Lots of sites violate the MUST NOT unilaterally remove rule.=C2=A0 Should we weaken it to SHOULD?=C2=A0 The justification for the MUST i= s "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want.

(also: by enabling a non-default break the rules config, it's what our server does!)

The original use case for not auto-removing a subscription is rather ancient already. I'd be fine with changing subscriptions to follow deletes and renames in the rev2 mode (but better not change behavior in rev1 mode).

I think I would rather weaken this to SHOULD and I would rather not require change in behaviour for servers that already comply with the MUST NOT.

Yeah, totally.=C2=A0 I'm fine with SHOULD, and I don't care about


6.3.10 NAMESPACE

We've created a conflict here.=C2=A0 The NAMESPACE command contains prefix strings for the individual namespaces, and says:

   The pr=
efix string allows a client to do things such as automatically
   creating personal mailboxes or LISTing all available mailboxes within
   a namespace.

Which contradicts the advice we gave back in the LIST command not to use prefix.=C2=A0 Perhaps we should change the LIST advice to be "only use the empty prefix or prefixes given in the NAMESPACE response"?

I think you're mixing "namespace prefixes" with "list references"? I don't think the above sentence advocates using LIST reference parameter, just using the namespace prefix for listing e.g. LIST "" ns-prefix/*

Exactly.

Anyway, I see lots and lots of text is still preserved for the LIST reference parameter explanation, even though it shouldn't be used. Couldn't we just decide to get rid of it entirely in rev2 and say the reference MUST be empty? Or say only that is is implementation-defined and refer to IMAP4rev1 if anyone wants to see how it used to be implemented?

I kept the text because non empty reference is still allowed. I think I would rather allow it and mark the text as recommended server behaviour if non empty reference parameter is supplied. Maybe move it to a separate section for clarity?

I don't think any change is needed here, sorry for adding confusion.


--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd=
=C2=A0 brong@fastmailteam.com



_______________________________=
________________
Extra mailing list
Extra@i=
etf.org
https://www.ietf.org/mailman/listinfo/extra
--------------6EC6D6D1427D7F983C6AEB8C-- From nobody Fri Feb 7 06:32:59 2020 Return-Path: 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 7158E120236 for ; Fri, 7 Feb 2020 06:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=b7031iLZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fImOjPFq 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 JQwUY39J6Kt3 for ; Fri, 7 Feb 2020 06:32:56 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0058A120048 for ; Fri, 7 Feb 2020 06:32:55 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id CEB6A321; Fri, 7 Feb 2020 09:32:54 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Fri, 07 Feb 2020 09:32:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:cc:subject:content-type; s= fm2; bh=BZ6s8KRdO/mP4XvvsdbjlVtSyK2XK6lsOOn0oRvkYTA=; b=b7031iLZ yzan5xKeqtSmVIhiWOE/YoKV3nFI0S3ZKrvXr4mC9y6CBPMEoXw3SFHN2lRJDo5U ddgANfachnBG7h+TEEXapFKC1zymtOztJMkJ+FsgIayA4/eqBBtOqY/FneqWFwc7 6SOo4Kiugg/Utp3gFRbyfaTGM0zjuxazosfngYWlSXCPGcsmh3kzLMfJ8JPC+uj8 CdXgEfTFMYukULUmp2vlpq96scM2CBuvi/sDLnw3sWb5GGHm+84kXhGT2fYfIZZf u1h03xVcXZ3PoyGsQMxT31tbIHO8VXAmgpXNOyA2PPL6L+wFy9eb6pQ4Hvk2UsQl LR962+eJGk/Hgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=BZ6s8KRdO/mP4XvvsdbjlVtSyK2XK 6lsOOn0oRvkYTA=; b=fImOjPFqpcTG4Rndu5LaAy3gQQOiFTD1S+lEO/Nj8Qv0v DmEb5mV32STwNb9uP9Oaaa9ayOkUws3WVLtGFNEK4vmVstS2mm1ZspZPxhn61/8T q8XAZLe5Eh/Aul3zwddXDW0D7NpeLKZn8akaTq0Xy4zjbgJBJ+Jl5VQ1M8E3Z0bE kJ/QrEh/va0G3Ec5GIXa7ydgKTtKPS6HriJhWf7lDkaWs/nnGWgTRUaSmiuVyUUK E8PpOT2W3tI6B31xj+4Vg0f/I7Nbkcv/6bBgt08zP0T1UmYxv1pOjW/DOAToPVI3 1MjysaG5MMSPnctt3UDlwZt+NJSgk7myOlRt5E/9A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheehgdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgigvgih ucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmqe enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghm vghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 23453660065; Fri, 7 Feb 2020 09:32:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <3577940f-f6a8-46a7-a03f-5ec407fe7b77@www.fastmail.com> Date: Fri, 07 Feb 2020 14:32:14 +0000 From: "Alexey Melnikov" To: "Michael Slusarz" Cc: "Barry Leiba" , extra@ietf.org, "Murray S. Kucherawy" Content-Type: text/plain Archived-At: Subject: [Extra] Updates to draft-ietf-extra-imap-fetch-preview-07 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 14:32:57 -0000 Hi Michael, Thank you for the updated document. I think it is moving in the right direction after our talk in Singapore, but I think you introduced some new problems in the latest version: You changed the document to use media types for preview algorithms. This is great. However: You use "text/imap-fetch-preview" media type. Somewhere in the document you say that preview algorithm types should be registered media types (good!), but this media type is not registered. My suggestion is that you change the document to use "text/plain" media type (which is already registered) and just specify that it means what you use "text/imap-fetch-preview" for in -07. If you are happy with this change and can do it quickly (by the end of February, but earlier is better), then I can approve this document before I step down from IESG at the end of March. Thank you, Alexey From nobody Fri Feb 7 08:58:21 2020 Return-Path: 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 16B1912084E for ; Fri, 7 Feb 2020 08:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 Agx8A0H2AwRW for ; Fri, 7 Feb 2020 08:58:15 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9298112025D for ; Fri, 7 Feb 2020 08:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1581094693; d=isode.com; s=june2016; i=@isode.com; bh=a6Fwo9BpvVDqZFZXr15dME0wJxHD98TjV33ywvdGkKU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Sto+gflj33ZpLVyEbP2zCQSaga3a1bFW8N4bfr8R2S8C1DzoNQBO1Okg1DqAVcEVwjC+MY OGsyVLjRQzS5TAlZt6WNhDPLgG/RBkintxlmI9DLMHgCnC+S3RFdbrKLl+JbK6neuurkZZ nPimfsdMFcL0pXp57UqdVIqKI8AnvwM=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 7 Feb 2020 16:58:13 +0000 From: Alexey Melnikov To: Timo Sirainen , Bron Gondwana Cc: extra@ietf.org, Barry Leiba References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> Message-ID: Date: Fri, 7 Feb 2020 16:57:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------2B4E6F4D8A632CC40768E012" Content-Language: en-US Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 16:58:19 -0000 --------------2B4E6F4D8A632CC40768E012 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi, On 29 Jan 2020, at 14:20, Timo Sirainen > wrote: > On 29. Jan 2020, at 14.08, Bron Gondwana > wrote: >> >> *2.2.1 Client protocol* >> * >> * >> /"A different tag is generated by the client for each command"./=20 >> There's no "MUST" on this, and certainly I've seen clients which=20 >> don't.=C2=A0 Do we want to make that more strict in rev2?=C2=A0 It would = be a=20 >> bit of a pain on the commandline where I normally use ".", but it's=20 >> also annoying as a server author that you can't rely on tag uniqueness. >> >> Maybe the client SHOULD generate a different tag for every command,=20 >> but a server MUST accept tag reuse (could restrict concurrency, a tag=20 >> can only be reused after it's been "returned") > > I haven't seen this as a problem, so I don't really care either way. I don=E2=80=99t see this as a problem and I don=E2=80=99t want to require se= rvers to=20 check for reuse. I am Ok with adding informative suggestion for clients to generate=20 unique tags to ease in debugging issues. Would this work for people? > >> *2.3.1.1 UID Attribute >> * >> / >> / >> /"The next unique identifier value MUST NOT change unless new=20 >> messages are added to the mailbox". /I would very much like that=20 >> first MUST NOT to be weakened to "SHOULD NOT".=C2=A0 My reasoning is that= =20 >> you could have a virtual mailbox which used a global sequence number=20 >> per message.=C2=A0 It would behave to clients as if a message had been=20 >> delivered and then immediately expunged.=C2=A0 I'm pretty sure clients=20 >> don't care - they'll fetch the range, discover that nothing new has=20 >> appeared, and stay happy.=C2=A0 The second MUST is obviously correct, tha= t=20 >> the UIDNEXT must increase when messages are delivered. > > Agreed. I was initially fine with this change, but after rereading this sentence=20 I think it is mostly Ok as is. I think a possible point to clarify is=20 that if a message is added and removed in another session, the UIDNEXT=20 will be updated, even if the change is not reported in the current=20 session. This is perfectly fine behaviour and should also work for the=20 virtual mailbox case. >> *5.1 Mailbox Naming* >> >> This doesn't solve one of my naming bugbears.=C2=A0 The spec says things= =20 >> like/"servers MAY accept a de-normalized UTF-8 mailbox name and=20 >> conver it to Net-Unicode prior to mailbox creation." -/*//*there is=20 >> no clear way to know what the SELECTable name will be after creating=20 >> a mailbox. >> >> If I was designing this myself from scratch I would say that "SELECT=20 >> of the same octets that were passed to CREATE MUST open that same=20 >> mailbox" or something to that effect.=C2=A0 Since we're messing with how= =20 >> mailbox naming works somewhat for imap4rev2, I'd be keen to add this=20 >> restriction on server behaviour so that clients don't fall into a=20 >> "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop. I agree this is a problem and happy to do what you suggest. >> >> It still doesn't mean that you can reliably tell the correct octets=20 >> for the matching mailbox from the LIST response though :( > > Is it too late to add a new response code? Something like: > > * OK [CREATED] TAG "a123" NAME "Denormalized name" Response codes are cheap and don=E2=80=99t break older clients, so I am happ= y to=20 add one. > >> *6.3.2 SELECT command >> * >> >> I also saw somewhere that the server can unilaterally send a "*=20 >> [CLOSED]" response at any point if it's had to close the mailbox=20 >> (e.g. it got deleted, or IO errors).=C2=A0 I'm not sure if that requires= =20 >> opt-in to IMAP4REV2, since otherwise clients will not be aware to=20 >> watch for it.=C2=A0 This may need to be clarified. Agreed. >> Current behaviour of our server right now is to drop the connection=20 >> entirely, which is ugly - but it's rare and all clients already need=20 >> to handle it cleanly, so it guarantees no messed up data model for=20 >> the clients. > > Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't think=20 > clients are going to implement it correctly since it almost never=20 > happens, so nobody tests that code path. Let me think about this. > >> *6.3.4 and 6.3..5 CREATE and DELETE >> * >> >> Can we make it illegal to "DELETE" a mailbox with children rather=20 >> than make it a \NoSelect mailbox pretty pretty please?=C2=A0 I'm just=20 >> looking at some patches to deal with Outlook misbehaving with this=20 >> precise situation, and it's all horrible.=C2=A0 Because of mailboxId=20 >> requirements for JMAP we've been forced to keep these things around=20 >> as "intermediate" mailboxes anyway, and it's been the source of tons=20 >> of bugs. > > \NoSelect seems to be causing confusion in general, and Dovecot=20 > nowadays has options that makes it try to avoid creating them. But I'm=20 > not sure if it needs to be made illegal in the RFC itself. I think=20 > your server implementation can just decide to reject DELETE if it has=20 > children. > > It sounds like your issues are with \NoSelect mailboxes in general,=20 > not just this specific way of creating them with DELETE? For example=20 > CREATE a/b could create "a" se \NoSelect also. I am happy to disallow this, or at least say that servers can either=20 disallow delete of a mailbox with children or add \NoSelect to it. I think the only safe for clients to do is to assume that deleting a=20 mailbox with submailboxes is not going to work, so the client needs to=20 delete each child separately. >> *6.3.6 RENAME* >> >> I thought we had agreed to strongly recommend against clients using=20 >> RENAME INBOX Other, but maybe I've forgotten.=C2=A0 I don't see it in the= =20 >> minutes, so maybe it's just my wishful thinking. > > Dovecot doesn't allow RENAME INBOX in some configurations. I don't=20 > remember people complaining. From the client prospective I am disagreeing with this, renaming INBOX=20 is useful for archiving. I am happy to say that some servers might disallow this though. Would=20 that be Ok with people? > >> We definitely have an option in Cyrus IMAP to make subscriptions=20 >> follow RENAME.=C2=A0 It's one of the warts (largely due to Thunderbird=20 >> showing greyed out folders and confusing people). > > We haven't needed to do this yet. I think the \NoSelect folders have=20 > been more of a reason for Thunderbird confusion. > >> *6.3.7 SUBSCRIBE >> * >> >> Speak of the devil. Lots of sites violate the MUST NOT unilaterally=20 >> remove rule.=C2=A0 Should we weaken it to SHOULD?=C2=A0 The justification= for=20 >> the MUST is "the server site might choose to do X" - well, if the=20 >> server site is doing that, then maybe they SHOULDN'T unilaterally=20 >> remove the subscriptions, but otherwise it's a better user experience=20 >> and what people want. >> >> (also: by enabling a non-default break the rules config, it's what=20 >> our server does!) > > The original use case for not auto-removing a subscription is rather=20 > ancient already. I'd be fine with changing subscriptions to follow=20 > deletes and renames in the rev2 mode (but better not change behavior=20 > in rev1 mode). I think I would rather weaken this to SHOULD and I would rather not=20 require change in behaviour for servers that already comply with the=20 MUST NOT. > >> *6.3.8 UNSUBSCRIBE* >> >> /This command returns a tagged OK response only if the unsubscription=20 >> is successful./- this is not clear on what happens if the mailbox is=20 >> not currently subscribed - does it silently succeed, or is there an=20 >> expected error? >> >> For what it's worth, our server just says "OK Completed" even if it's=20 >> already been unsubscrbed - and likewise for subscribe if it's already=20 >> subscribed it just say "yep, all good". > > Same with Dovecot. I think should keep the OK behavior, since that's=20 > what is commonly been done. I think returning OK if not subscribed would be a better behaviour for=20 clients. (I have lots of comments in my client asking what should be=20 done if UNSUBSCRIBE fails, for example.) So I would be happy to change=20 the text. > >> *6.3.10 NAMESPACE* >> >> We've created a conflict here.=C2=A0 The NAMESPACE command contains prefi= x=20 >> strings for the individual namespaces, and says: >> >> The prefix string allows a client to do things such as automatically >> creating personal mailboxes or LISTing all available mailboxes within >> a namespace. >> >> Which contradicts the advice we gave back in the LIST command not to=20 >> use prefix.=C2=A0 Perhaps we should change the LIST advice to be "only us= e=20 >> the empty prefix or prefixes given in the NAMESPACE response"? > > I think you're mixing "namespace prefixes" with "list references"? I=20 > don't think the above sentence advocates using LIST reference=20 > parameter, just using the namespace prefix for listing e.g. LIST ""=20 > ns-prefix/* Exactly. > > Anyway, I see lots and lots of text is still preserved for the LIST=20 > reference parameter explanation, even though it shouldn't be used.=20 > Couldn't we just decide to get rid of it entirely in rev2 and say the=20 > reference MUST be empty? Or say only that is is implementation-defined=20 > and refer to IMAP4rev1 if anyone wants to see how it used to be=20 > implemented? I kept the text because non empty reference is still allowed. I think I=20 would rather allow it and mark the text as recommended server behaviour=20 if non empty reference parameter is supplied. Maybe move it to a=20 separate section for clarity? > >> *6.3.11 STATUS >> * >> >> Note: The STATUS command is intended to access the status of >> mailboxes other than the currently selected mailbox. Because the >> STATUS command can cause the mailbox to be opened internally, and >> because this information is available by other means on the >> selected mailbox, the STATUS command SHOULD NOT be used on the >> currently selected mailbox. >> >> This advice is all well and good, but it says nothing about what the=20 >> server may or may not do when it gets one of these STATUS commands.=C2=A0= =20 >> This is particularly relevant in the context of LIST RETURN STATUS,=20 >> where it's hard to construct list patterns which explicitly avoid the=20 >> currently selected mailbox. Good point. I think this should be allowed on the selected mailbox. >> >> Likewise with the:/MUST NOT be used as a "check for new messages in=20 >> the selected mailbox"/assertion. Plenty of clients will do a STATUS=20 >> run across folders and if they're doing LIST RETURN STATUS they're=20 >> gonna find out about the new messages if the server returns it.=C2=A0=20 >> Clients can not rely on it working is a more honest representation of=20 >> what happens. >> >> I'd like to see that IMAP4REV2 servers MUST implement STATUS of the=20 >> currently selected mailbox.=C2=A0 Yes, it's a special codepath - but if= =20 >> you're already testing if it's the currently open mailbox then you're=20 >> at exactly the right place to do the right thing: > > Also this is the only way to get the current UIDNEXT of the selected=20 > mailbox (since it might be higher than last message's UID). > > The main ambiguity though is whether STATUS on the current mailbox is=20 > expected to check for new changes. Dovecot implements it in a way that=20 > it doesn't check for changes. I think there used to be even a good=20 > reason for that. I am ambivalent on what server behaviour should be in this case. I am Ok=20 with saying that the client can=E2=80=99t expect the server to check for cha= nges. > >> 6.4.4.1 SAVE Result >> >> I'm not sure I understand the interaction here with closing and=20 >> re-opening a mailbox.=C2=A0 I would expect that closing a mailbox would= =20 >> wipe the SAVED result, > > I think it practically says that, since it says that SELECT/EXAMINE=20 > resets it to empty sequence. It's not really relevant whether it=20 > happens when the mailbox is closed or when the next mailbox is opened,=20 > because you can't use it in non-selected state anyway.. Exactly :-). > >> and that trying to use a SAVED result when there isn't one should=20 >> return an error. > > It says that the default is an empty sequence. So it won't result in=20 > an error, just a non-matching set. I'm fine with this behavior,=20 > especially since it's easier to implement and I don't really see much=20 > of a downside. Same here. That was the intent. > >> Speaking of which, Example 5 is wrong: It says that the second search=20 >> command leads to the variable containing no messages, but the second=20 >> search command did not contain the RETURN SAVE option, so it should=20 >> not have altered the variable. > > Right. And even if it did contain RETURN SAVE option it still=20 > shouldn't have altered the variable, because: > > """ > =C2=A0 =C2=A0Any of the following SEARCH commands MUST NOT change the sear= ch > =C2=A0 =C2=A0result variable: > > =C2=A0 =C2=A0 =C2=A0 a SEARCH command that caused the server to return the= BAD tagged > =C2=A0 =C2=A0 =C2=A0 response, > """ Ok, I will recheck the example. > >> *7.4.2 FETCH Response* >> >> I remember past bugs with UID in "unsolicited" FLAGS responses.=C2=A0 Do= =20 >> we need to require that including UID only happen after ENABLE=20 >> IMAP4REV2 (as it is for ENABLE QRESYNC)? > > Might be useful to require UID for any untagged FETCH reply. It can=20 > simplify client behavior. I think we agreed to this. I think I mention this for IDLE, but didn=E2=80= =99t=20 say it in this section. What is the best place for this text? At the top=20 of the section describing FETCH response? Best Regards, Alexey --------------2B4E6F4D8A632CC40768E012 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi,

On 29 Jan 2020, at 14:20, Timo Sirainen <timo@sirainen.com> wrote:

On 29. Jan 2020, at 14.08, Bron Gondwana <brong@fastmailte= am.com> wrote:

2.2.1 Client protocol

"A different tag is generated by the client for each command".=C2= =A0 There's no "MUST" on this, and certainly I've seen clients which don't.=C2=A0 Do we want to make that more strict in rev2?=C2=A0 It would be a bit of a pain on the commandline where I normally use ".", but it's also annoying as a server author that you can't rely on tag uniqueness.

Maybe the client SHOULD generate a different tag for every command, but a server MUST accept tag reuse (could restrict concurrency, a tag can only be reused after it's been "returned")

I haven't seen this as a problem, so I don't really care either way.

I don=E2=80=99t see this as a problem and I don=E2=80=99t want to requir= e servers to check for reuse.

I am Ok with adding informative suggestion for clients to generate unique tags to ease in debugging issues. Would this work for people?

2.3.1.1 UID Attribute

"The next unique identifier value MUST NOT change unless new messages are added to the mailbox".=C2=A0=C2=A0I would ver= y much like that first MUST NOT to be weakened to "SHOULD NOT".=C2=A0 My reasoning is that you could have a virtual mailbox which used a global sequence number per message.=C2=A0 It would behave to clients as if a message had been delivered and then immediately expunged.=C2=A0 I'm pretty sure clients don't care - they'll fetch the range, discover that nothing new has appeared, and stay happy.=C2=A0 The second MUST is obviously correct, that the UIDNEXT must increase when messages are delivered.

Agreed.

I was initially fine with this change, but after rereading this sentence I think it is mostly Ok as is. I think a possible point to clarify is that if a message is added and removed in another session, the UIDNEXT will be updated, even if the change is not reported in the current session. This is perfectly fine behaviour and should also work for the virtual mailbox case.

5.1 Mailbox Naming

This doesn't solve one of my naming bugbears.=C2=A0 The spec says things like=C2=A0"servers MAY accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." -=C2=A0there is no clear way to know what the SELECTable name will be after creating a mailbox.

If I was designing this myself from scratch I would say that "SELECT of the same octets that were passed to CREATE MUST open that same mailbox" or something to that effect.=C2=A0 Since we're messing with how mailbox naming works somewhat for imap4rev2, I'd be keen to add this restriction on server behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop.

I agree this is a problem and happy to do what you suggest.

It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :(

Is it too late to add a new response code? Something like:

* OK [CREATED] TAG "a123" NAME "Denormalized name"

Response codes are cheap and don=E2=80=99t break older clients, so I a= m happy to add one.

6.3.2 SELECT command

I also saw somewhere that the server can unilaterally send a "* [CLOSED]" response at any point if it's had to close the mailbox (e.g. it got deleted, or IO errors).=C2=A0 I'm not sure if that requires opt-in to IMAP4REV2, since otherwise clients will not be aware to watch for it.=C2=A0 This may need to be clarified.=C2=A0

Agreed.

Current behaviour of our server right now is to drop the connection entirely, which is ugly - but it's rare and all clients already need to handle it cleanly, so it guarantees no messed up data model for the clients.

Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't think clients are going to implement it correctly since it almost never happens, so nobody tests that code path.

Let me think about this.

6.3.4 and 6.3..5 CREATE and DELETE

Can we make it illegal to "DELETE" a mailbox with children rather than make it a \NoSelect mailbox pretty pretty please?=C2=A0 I'm jus= t looking at some patches to deal with Outlook misbehaving with this precise situation, and it's all horrible.=C2=A0 Because of mailboxId requirements for JMAP we've been forced to keep these things around as "intermediate" mailboxes anyway, and it's been the source of tons of bugs.

\NoSelect seems to be causing confusion in general, and Dovecot nowadays has options that makes it try to avoid creating them. But I'm not sure if it needs to be made illegal in the RFC itself. I think your server implementation can just decide to reject DELETE if it has children.

It sounds like your issues are with \NoSelect mailboxes in general, not just this specific way of creating them with DELETE? For example CREATE a/b could create "a" se \NoSelect also.

I am happy to disallow this, or at least say that servers can either disallow delete of a mailbox with children or add \NoSelect to it.

I think the only safe for clients to do is to assume that deleting a mailbox with submailboxes is not going to work, so the client needs to delete each child separately.
6.3.6 RENAME= =C2=A0

I thought we had agreed to strongly recommend against clients using RENAME INBOX Other, but maybe I've forgotten.=C2=A0 I don't see i= t in the minutes, so maybe it's just my wishful thinking.

Dovecot doesn't allow RENAME INBOX in some configurations. I don't remember people complaining.

From the client prospective I am disagreeing with this, renaming INBOX is useful for archiving.

I am happy to say that some servers might disallow this though. Would that be Ok with people?

We definitely have an option in Cyrus IMAP to make subscriptions follow RENAME.=C2=A0 It's one of the warts (largely due to Thunderbird showing greyed out folders and confusing people).

=20
We haven't needed to do this yet. I think the \NoSelect folders have been more of a reason for Thunderbird confusion.

6.3.7 SUBSCRIBE

Speak of the devil.=C2=A0 Lots of sites violate the MUST NOT unilaterally remove rule.=C2=A0 Should we weaken it to SHOULD?=C2=A0 The justification for the MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want.

(also: by enabling a non-default break the rules config, it's what our server does!)

The original use case for not auto-removing a subscription is rather ancient already. I'd be fine with changing subscriptions to follow deletes and renames in the rev2 mode (but better not change behavior in rev1 mode).

I think I would rather weaken this to SHOULD and I would rather not require change in behaviour for servers that already comply with the MUST NOT.

6.3.8 UNSUBSCRIBE

This command returns a tagged OK response only if the unsubscription is successful.=C2=A0- thi= s is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error?

For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed - and likewise for subscribe if it's already subscribed it just say "yep, all good".

Same with Dovecot. I think should keep the OK behavior, since that's what is commonly been done.

I think returning OK if not subscribed would be a better behaviour for clients. (I have lots of comments in my client asking what should be done if UNSUBSCRIBE fails, for example.) So I would be happy to change the text.

6.3.10 NAMESPACE

We've created a conflict here.=C2=A0 The NAMESPACE command contains prefix strings for the individual namespaces, and says:

   The prefix string allows a client to do things such as automatical=
ly
   creating personal mailboxes or LISTing all available mailboxes within
   a namespace.

Which contradicts the advice we gave back in the LIST command not to use prefix.=C2=A0 Perhaps we should change the LIST advice to be "only use the empty prefix or prefixes given in the NAMESPACE response"?

I think you're mixing "namespace prefixes" with "list references"? I don't think the above sentence advocates using LIST reference parameter, just using the namespace prefix for listing e.g. LIST "" ns-prefix/*

Exactly.

Anyway, I see lots and lots of text is still preserved for the LIST reference parameter explanation, even though it shouldn't be used. Couldn't we just decide to get rid of it entirely in rev2 and say the reference MUST be empty? Or say only that is is implementation-defined and refer to IMAP4rev1 if anyone wants to see how it used to be implemented?

I kept the text because non empty reference is still allowed. I think I would rather allow it and mark the text as recommended server behaviour if non empty reference parameter is supplied. Maybe move it to a separate section for clarity?

6.3.11 STATUS

      Note: The STATUS command is intended to access the status of
      mailboxes other than the currently selected mailbox.  Because the
      STATUS command can cause the mailbox to be opened internally, and
      because this information is available by other means on the
      selected mailbox, the STATUS command SHOULD NOT be used on the
      currently selected mailbox.

This advice is all well and good, but it says nothing about what the server may or may not do when it gets one of these STATUS commands.=C2=A0 This is particularly relevant in the context of LIST RETURN STATUS, where it's hard to construct list patterns which explicitly avoid the currently selected mailbox.

Good point. I think this should be allowed on the selected mailbox.


Likewise with the:=C2=A0MUST NOT be used as a "check for new messages in the selected mailbox"= =C2=A0assertion.=C2=A0 Plenty of clients will do a STATUS run across folders and if they're doing LIST RETURN STATUS they're gonna find out about the new messages if the server returns it.=C2=A0 Clients can not rely on it working is a more honest representation of what happens.


I'd like to see that IMAP4REV2 servers MUST implement STATUS of the currently selected mailbox.=C2=A0 Yes, it's a special codepath - but if you're already testing if it's the currently open mailbox then you're at exactly the right place to do the right thing:

Also this is the only way to get the current UIDNEXT of the selected mailbox (since it might be higher than last message's UID).

The main ambiguity though is whether STATUS on the current mailbox is expected to check for new changes. Dovecot implements it in a way that it doesn't check for changes. I think there used to be even a good reason for that.

I am ambivalent on what server behaviour should be in this case. I am Ok with saying that the client can=E2=80=99t expect the server to c= heck for changes.

6.4.4.1 SAVE Result

I'm not sure I understand the interaction here with closing and re-opening a mailbox.=C2=A0 I would expect that closing a mailbox would wipe the SAVED result,

I think it practically says that, since it says that SELECT/EXAMINE resets it to empty sequence. It's not really relevant whether it happens when the mailbox is closed or when the next mailbox is opened, because you can't use it in non-selected state anyway..

Exactly :-).

and that trying to use a SAVED result when=20there isn't one should return an error.

It says that the default is an empty sequence. So it won't result in an error, just a non-matching set. I'm fine with this behavior, especially since it's easier to implement and I don't really see much of a downside.

Same here. That was the intent.

Speaking of which, Example 5 is wrong: It says that the second search command leads to the variable containing no messages, but the second search command did not contain the RETURN SAVE option, so it should not have altered the variable.

Right. And even if it did contain RETURN SAVE option it still shouldn't have altered the variable, because:

"""
=C2=A0 =C2=A0Any of the following SEARCH comma= nds MUST NOT change the search
=C2=A0 =C2=A0result variable:

=C2=A0 =C2=A0 =C2=A0 a SEARCH command that cau= sed the server to return the BAD tagged
=C2=A0 =C2=A0 =C2=A0 response,
"""

Ok, I will recheck the example.


7.4.2 FETCH Response

I remember past bugs with UID in "unsolicited" FLAGS responses.=C2=A0 Do we nee= d to require that including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)?

Might be useful to require UID for any untagged FETCH reply. It can simplify client behavior.

I think we agreed to this. I think I mention this for IDLE, but didn=E2=80=99t say it in this section. What is the best place for this text? At the top of the section describing FETCH response?

Best Regards,
Alexey


--------------2B4E6F4D8A632CC40768E012-- From nobody Fri Feb 7 09:04:40 2020 Return-Path: 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 47E4312084E for ; Fri, 7 Feb 2020 09:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 8fdSdT55afaY for ; Fri, 7 Feb 2020 09:04:37 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id F37AC12088E for ; Fri, 7 Feb 2020 09:04:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1581095075; d=isode.com; s=june2016; i=@isode.com; bh=8qyEBibAnpM0BQCJwiTamfeh6r37tUl4xjP+jahiA7k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=c49W2gD5/+EJnINVXIsIF84MdnwpeXN1DV7p/yepVOkMw/kogwSLP17GN8Et+srj5qt7Bk qvaQE0yGiwyuiKPuuZKIlWNzr9nivQ+qVC5K8y/Rzx7nUs+81bXDANJotkrqLFajFJk2eg gDxZd/U3ycKKPrevcw2YzwfJTa0UL24=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 7 Feb 2020 17:04:35 +0000 From: Alexey Melnikov To: Bron Gondwana , extra@ietf.org Cc: Barry Leiba References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> Message-ID: Date: Fri, 7 Feb 2020 17:04:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8D5D4813768B93B738B03B0D" Content-Language: en-US Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 17:04:39 -0000 --------------8D5D4813768B93B738B03B0D Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Bron, Replying to issues raised not covered by my reply to Timo: On 29/01/2020 12:08, Bron Gondwana wrote: > Sorry about the delay in doing this!=C2=A0=C2=A0 I was supposed to be doin= g the=20 > shepherding write-up, and so I figured I should read it properly. > > I've had a full read through over some very many days (I admit, I=20 > skimmed through the ABNF) and I have comments.=C2=A0 It's long, and=20 > hopefully comprehensive - though I'm sure I missed things. > > > *2.1 Link level > * > > Is it appropriate to mention TLS on 993 here?=C2=A0 It's mentioned deep=20 > within the document, but not here. Done. > *2.3.2 Flags Message Attribute > * > > formatting issue: $Forwarded is duplicated 3 times and $MDNSent is=20 > duplicated twice in the plain-text format. This is actually a bug in TXT rendering from XML. =C2=A0[snip] > *6.3.1 ENABLE command > * > > The example shows a conversation with an imap4rev1 only server. Fixed. > The examples don't clearly show that only the newly enabled responses=20 > are correct, e.g. the sequence: > > C1 ENABLE CONDSTORE > * ENABLED CONDSTORE > C1 OK foo > C2 ENABLE CONDSTORE QRESYNC > * ENABLED QRESYNC > C2 OK foo > > The second doesn't say "ENABLED CONDSTORE" because it was already=20 > enabled earlier on this connection. Actually, it is perfectly Ok for the server to return in response to C2: * ENABLED QRESYNC CONDSTORE The text in the document wasn't entirely clear. It was trying to say=20 that the preferred server behaviour is: L1 ENABLE A B * ENABLED A B L1 OK foo L2 ENABLE C * ENABLED C L2 OK foo and not L2 ENABLE C * ENABLED A B C L2 OK foo I clarified this. > > (AKA: clients MUST remember what they have enabled) > > *6.3.2 SELECT command > * > > The [UIDNEXT ] response is duplicated with two different pieces of=20 > text. Again, this is a tool issue. > /When deselecting a selected mailbox, the server MUST return an=20 > untagged OK response with the "[CLOSED]" response code when the=20 > currently selected mailbox *is closed (see Paragraph 10). */*- I'm not=20 > sure where "Paragraph 10" is.** > * I will check. I think the section reference for response codes is missing. > The last paragraph of this section has the word "deprecated" spelled=20 > as "depractated". Fixed. > > *6.3.7 SUBSCRIBE > * > > Speak of the devil.=C2=A0 Lots of sites violate the MUST NOT unilaterally= =20 > remove rule.=C2=A0 Should we weaken it to SHOULD? Done. > =C2=A0 The justification for the MUST is "the server site might choose to= =20 > do X" - well, if the server site is doing that, then maybe they=20 > SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a=20 > better user experience and what people want. > > (also: by enabling a non-default break the rules config, it's what our=20 > server does!) > > *6.3.8 UNSUBSCRIBE* > > /This command returns a tagged OK response only if the unsubscription=20 > is successful. /- this is not clear on what happens if the mailbox is=20 > not currently subscribed - does it silently succeed, or is there an=20 > expected error? > > For what it's worth, our server just says "OK Completed" even if it's=20 > already been unsubscrbed - and likewise for subscribe if it's already=20 > subscribed it just say "yep, all good". I agree that your server behaviour is sensible. Updated description of=20 both SUBSCRIBE and UNSUBSCRIBE. > > . create INBOX.foo > . OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed > . subscribe INBOX.foo > . OK Completed > . unsubscribe INBOX.foo > . OK Completed > . unsubscribe INBOX.foo > . OK Completed > . subscribe INBOX.foo > . OK Completed > . subscribe INBOX.foo > . OK Completed > > > *6.3.9 LIST > * > > There's a weird line wrapping near the top of page 44 where a=20 > paragraph is split in half: > > The reference and mailbox name arguments are interpreted into a > canonical form that represents an unambiguous left-to-right > hierarchy. The returned mailbox names will be in the interpreted > form, > > that we call "canonical LIST pattern" later in this document. To > define the term "canonical LIST pattern" formally: it refers to the > canonical pattern constructed internally by the server from the > reference and mailbox name arguments. I will double check, but I think it is another rendering issue to TXT=20 format (there is a comment in bettween 2 parts of the sentence. > > *6.3.9.2 LIST Return Options > * > > The CHILDREN item is duplicated with two different pieces of text. Again, a rendering issue. These are actually 2 separate paragraphs under=20 the same item. > *6.4.4 SEARCH > * > > For example, > the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all > deleted messages from Smith that were placed in the mailbox since > February 1, 1994. > > That's not strictly true - SAVEDATE would be "placed in the mailbox".=C2= =A0=20 > The wording should say "with INTERNALDATE greater than February 1,=20 > 1994" or so. Good point. Fixed. > *6.4.4.1 SAVE Result > * > > I'm not sure I understand the interaction here with closing and=20 > re-opening a mailbox.=C2=A0 I would expect that closing a mailbox would=20 > wipe the SAVED result, and that trying to use a SAVED result when=20 > there isn't one should return an error. I think Timo explained this well in his response. =C2=A0[snip] > > *7.1 Status Responses > * > > Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks=20 > like an attempt to do dot points! Changed :-). =C2=A0[snip] Best Regards, Alexey --------------8D5D4813768B93B738B03B0D Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Bron,

Replying to issues raised not covered by my reply to Timo:

On 29/01/2020 12:08, Bron Gondwana wrote:
Sorry about the delay in doing this!=C2=A0=C2=A0 I was supposed to be doing the shepherding write-u= p, and so I figured I should read it properly.

I've had a full read through over some very many days (I admit, I skimmed through the ABNF) and I have comments.=C2=A0 It's long, and hopefully comprehensive - though I'm sure I missed things.


2.1 Link level

Is it appropriate to mention TLS on 993 here?=C2=A0 It's mentioned deep within the document, but not here.
Done.
2.3.2 Flags Message Attribute

formatting issue: $Forwarded is duplicated 3 times and $MDNSent is duplicated twice in the plain-text format.

This is actually a bug in TXT rendering from XML.

=C2=A0[snip]

6.3.1 ENABLE command

The example shows a conversation with an imap4rev1 only server.
Fixed.
The examples don't clearly show that only the newly enabled responses are correct, e.g. the sequence:

C1 ENABLE CONDSTORE
* ENABLED CONDSTORE
C1 OK foo
C2 ENABLE CONDSTORE QRESYNC
* ENABLED QRESYNC
C2 OK foo

The second doesn't say "ENABLED CONDSTORE" because it was already enabled earlier on this connection.

Actually, it is perfectly Ok for the server to return in response to C2:

* ENABLED QRESYNC CONDSTORE

The text in the document wasn't entirely clear. It was trying to say that the preferred server behaviour is:

L1 ENABLE A B
* ENABLED A B
L1 OK foo

L2 ENABLE C
* ENABLED C
L2 OK foo

and not

L2 ENABLE C
* ENABLED A B C
L2 OK foo

I clarified this.

(AKA: clients MUST remember what they have enabled)

6.3.2 SELECT command

The [UIDNEXT <n>] response is duplicated with two different pieces of text.
Again, this is a tool issue.
When deselecting a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox is closed (see Paragraph 10). - I'm not sure where "Paragraph 10" is.
I will check. I think the section reference for response codes is missing.
The last paragraph of this section has the word "deprecated" spelled as "depractated".
Fixed.

6.3.7 SUBSCRIBE

Speak of the devil.=C2=A0 Lots of si= tes violate the MUST NOT unilaterally remove rule.=C2=A0 Should we weake= n it to SHOULD?
Done.
=C2=A0 The justification for the MUS= T is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want.

(also: by enabling a non-default break the rules config, it's what our server does!)

6.3.8 UNSUBSCRIBE

This command returns a tagged OK response only if the unsubscription is successful. - this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error?

For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed - and likewise for subscribe if it's already subscribed it just say "yep, all good".
I agree that your server behaviour is sensible. Updated description of both SUBSCRIBE and UNSUBSCRIBE.

. create INBOX.foo
. OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed
. subscribe INBOX.foo
. OK Completed
. unsubscribe INBOX.foo
. OK Completed
. unsubscribe INBOX.foo
. OK Completed
. subscribe INBOX.foo
. OK Completed
. subscribe INBOX.foo
. OK Completed


6.3.9 LIST

There's a weird line wrapping near the top of page 44 where a paragraph is split in half:

   The reference and mailbox name arguments are interpreted into =
a
   canonical form that represents an unambiguous left-to-right
   hierarchy.  The returned mailbox names will be in the interpreted
   form,

   that we call "canonical LIST pattern" later in this document.  To
   define the term "canonical LIST pattern" formally: it refers to the
   canonical pattern constructed internally by the server from the
   reference and mailbox name arguments.
I will double check, but I think it is another rendering issue to TXT format (there is a comment in bettween 2 parts of the sentence.

6.3.9.2 LIST Return Options

The CHILDREN item is duplicated with two different pieces of text.

Again, a rendering issue. These are actually 2 separate paragraphs under the same item.


6.4.4 SEARCH
 

   For example,
   the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
   deleted messages from Smith that were placed in the mailbox since
   February 1, 1994.

That's not strictly true - SAVEDATE would be "placed in the mailbox".=C2=A0 The wording should say "with INTERNALDATE greater than February 1, 1994" or so.

Good point. Fixed.


6.4.4.1 SAVE Result

I'm not sure I understand the interaction here with closing and re-opening a mailbox.=C2=A0 I woul= d expect that closing a mailbox would wipe the SAVED result, and that trying to use a SAVED result when there isn't one should return an error.
I think Timo explained this well in his response.

=C2=A0[snip]


7.1 Status Responses

Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks like an attempt to do dot points!
Changed :-).

=C2=A0[snip]

Best Regards,

Alexey

--------------8D5D4813768B93B738B03B0D-- From nobody Wed Feb 12 06:59:27 2020 Return-Path: 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 12083120077; Wed, 12 Feb 2020 06:59:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <158151956199.17982.2762568794986363570@ietfa.amsl.com> Date: Wed, 12 Feb 2020 06:59:22 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-12.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 14:59:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-12.txt Pages : 157 Date : 2020-02-12 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-12 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 13 15:47:41 2020 Return-Path: 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 AC64E120020 for ; Thu, 13 Feb 2020 15:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=2sI6I4Jp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pwohqT7T 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 yFL9wRbATeKV for ; Thu, 13 Feb 2020 15:47:37 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26746120289 for ; Thu, 13 Feb 2020 15:47:37 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 165B92208A for ; Thu, 13 Feb 2020 18:47:36 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 13 Feb 2020 18:47:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=nwtF2dh rAj0DMSgZuSNdsQbJHsCkwLaqJh5xnTzn24w=; b=2sI6I4JpDw92naug1NRDvYl mKXTv7y7t2z7AADt/Iza3S6NQrJfr1J5/joLR1sMXZT2ey6u6bVrKApqwSrqAfNQ xd/MJSme//KLKBIaCTRP4OmMrErr/jfKSPNs9cmp9K8NODRTbvwAYQ22rRQSr7ba 8PDFFXCkcp4zE0bfBOyU92NjYM6r892F2Cvc97UHfyLIl+eupNkYBp0s0vlyfJOl 8bCLzx5ZL5bx4H12+Cfk/d2xQOVcyOJLysvBdHztQUuzNrMQi5w2i0YqA3A68CRx Plw+5y/gkzk8iMBR/AOk+qkqbl15k0igxQy0XUBRo282UFR/iX5QL4liWfvanug= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=nwtF2d hrAj0DMSgZuSNdsQbJHsCkwLaqJh5xnTzn24w=; b=pwohqT7TCADG0hbF1w9p7U 4K394PlXtSnKHvOwqQ0HSZUNq/XiqynnMJEMCgZzT6nkyFqZmL3t0LboJaeGTyRm NF1JDwtWnlxlMz+AyDkCnfeA7f2m27W5IaDQD+1dXA2BkEwJRRt9nD6LVy3w/AgO a+XVLDLHxyL9b+t0bkj3zWM3Yb+ySU4dxY+MOlPYfQWhQslnLK6364nlig9AioLL 5EyfdrgXRm1sD5jQduzAc9VN2bZWeaJgUa0NWjKEgn12VCaE4HUr+TrrxTM6bVsa q7fpScuu9VosiocSD9cM4XTJgeg2pz5D8KOXiftISVc5EC8Pk7/3quvnycqip3BA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrieelgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhg sehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C74D6180091; Thu, 13 Feb 2020 18:47:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-871-gf1112c6-fmnext-20200202v1 Mime-Version: 1.0 Message-Id: <345e934f-e540-4b42-bd5e-8c1e1f6965f8@www.fastmail.com> In-Reply-To: References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> Date: Fri, 14 Feb 2020 10:47:15 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=b42ed1843bb541a6b5373f688aa0bb13 Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 23:47:40 -0000 --b42ed1843bb541a6b5373f688aa0bb13 Content-Type: text/plain Thanks Alexey, I see there's a -12 there now, and I'm happy with all the edits in it :) There are still some outstanding points from this thread - are you expecting to issue a -13 for those? Thanks, Bron. On Sat, Feb 8, 2020, at 04:04, Alexey Melnikov wrote: > Hi Bron, > Replying to issues raised not covered by my reply to Timo: > On 29/01/2020 12:08, Bron Gondwana wrote: >> Sorry about the delay in doing this! I was supposed to be doing the shepherding write-up, and so I figured I should read it properly. >> >> I've had a full read through over some very many days (I admit, I skimmed through the ABNF) and I have comments. It's long, and hopefully comprehensive - though I'm sure I missed things. >> >> >> *2.1 Link level* >> >> Is it appropriate to mention TLS on 993 here? It's mentioned deep within the document, but not here. > Done. > >> *2.3.2 Flags Message Attribute* >> >> formatting issue: $Forwarded is duplicated 3 times and $MDNSent is duplicated twice in the plain-text format. > This is actually a bug in TXT rendering from XML. > [snip] >> *6.3.1 ENABLE command* >> >> The example shows a conversation with an imap4rev1 only server. > Fixed. > >> The examples don't clearly show that only the newly enabled responses are correct, e.g. the sequence: >> >> C1 ENABLE CONDSTORE >> * ENABLED CONDSTORE >> C1 OK foo >> C2 ENABLE CONDSTORE QRESYNC >> * ENABLED QRESYNC >> C2 OK foo >> >> The second doesn't say "ENABLED CONDSTORE" because it was already enabled earlier on this connection. > Actually, it is perfectly Ok for the server to return in response to C2: > * ENABLED QRESYNC CONDSTORE > > The text in the document wasn't entirely clear. It was trying to say that the preferred server behaviour is: > > L1 ENABLE A B > * ENABLED A B > L1 OK foo > > L2 ENABLE C > * ENABLED C > L2 OK foo > > and not > > L2 ENABLE C > * ENABLED A B C > L2 OK foo > > I clarified this. >> >> (AKA: clients MUST remember what they have enabled) >> >> *6.3.2 SELECT command* >> >> The [UIDNEXT ] response is duplicated with two different pieces of text. > Again, this is a tool issue. > >> *When deselecting a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox *is closed (see Paragraph 10). ***- I'm not sure where "Paragraph 10" is.*** > I will check. I think the section reference for response codes is missing. > >> The last paragraph of this section has the word "deprecated" spelled as "depractated". > Fixed. > >> >> *6.3.7 SUBSCRIBE* >> >> Speak of the devil. Lots of sites violate the MUST NOT unilaterally remove rule. Should we weaken it to SHOULD? > Done. > >> The justification for the MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want. >> >> (also: by enabling a non-default break the rules config, it's what our server does!) >> >> *6.3.8 UNSUBSCRIBE* >> >> *This command returns a tagged OK response only if the unsubscription is successful. *- this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error? >> >> For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed - and likewise for subscribe if it's already subscribed it just say "yep, all good". > I agree that your server behaviour is sensible. Updated description of both SUBSCRIBE and UNSUBSCRIBE. > >> >> . create INBOX.foo >> . OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed >> . subscribe INBOX.foo >> . OK Completed >> . unsubscribe INBOX.foo >> . OK Completed >> . unsubscribe INBOX.foo >> . OK Completed >> . subscribe INBOX.foo >> . OK Completed >> . subscribe INBOX.foo >> . OK Completed >> >> >> *6.3.9 LIST* >> >> There's a weird line wrapping near the top of page 44 where a paragraph is split in half: >> >> The reference and mailbox name arguments are interpreted into a canonical form that represents an unambiguous left-to-right hierarchy. The returned mailbox names will be in the interpreted form, that we call "canonical LIST pattern" later in this document. To define the term "canonical LIST pattern" formally: it refers to the canonical pattern constructed internally by the server from the reference and mailbox name arguments. >> > I will double check, but I think it is another rendering issue to TXT format (there is a comment in bettween 2 parts of the sentence. > >> >> *6.3.9.2 LIST Return Options* >> >> The CHILDREN item is duplicated with two different pieces of text. > Again, a rendering issue. These are actually 2 separate paragraphs under the same item. > >> *6.4.4 SEARCH * >> >> For example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all deleted messages from Smith that were placed in the mailbox since February 1, 1994. >> >> >> That's not strictly true - SAVEDATE would be "placed in the mailbox". The wording should say "with INTERNALDATE greater than February 1, 1994" or so. > Good point. Fixed. > >> *6.4.4.1 SAVE Result* >> >> I'm not sure I understand the interaction here with closing and re-opening a mailbox. I would expect that closing a mailbox would wipe the SAVED result, and that trying to use a SAVED result when there isn't one should return an error. > I think Timo explained this well in his response. > > > [snip] >> >> *7.1 Status Responses* >> >> Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks like an attempt to do dot points! > Changed :-). > > [snip] > Best Regards, > Alexey > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --b42ed1843bb541a6b5373f688aa0bb13 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Alexey, I see there's a -12 there now, and I'm= happy with all the edits in it :)

There are still some o= utstanding points from this thread - are you expecting to issue a -13 fo= r those?

Thanks,

Bron.

On Sat, Feb 8, 2020, at 04:04, Al= exey Melnikov wrote:

Hi = Bron,

Replying to issues raised not covered by my reply to Ti= mo:

On 29/01/2020 12:08, Bron G= ondwana wrote:
Sorry about the delay in doing this!   I was supposed to be doing the shepherding wri= te-up, and so I figured I should read it properly.

I've had = a full read through over some very many days (I admit, I skimmed through the ABNF) and I have comments.  It's long, and hopefully comprehensive - th= ough I'm sure I missed things.


2.1 Link level

Is it appropri= ate to mention TLS on 993 here?  It's mentioned deep within the document, but = not here.
Done.

=
2.3.2 Flag= s Message Attribute

<= /div>
formatting issue: $Forwarded is duplicated 3 times and $MDNSent is duplicated twice in the plain-text format.

This is actually a b= ug in TXT rendering from XML.

 [snip]

6.3.1 ENABLE command

The example shows a conversation with an imap4rev1 only server.
Fixed.=

The examples don't clearly show that only the newly enabled responses are correct, e.g. the sequence:

<= div style=3D"font-family:Arial;">C1 ENABLE CONDSTORE
* ENABLED CONDSTORE
C1 OK foo
C2 E= NABLE CONDSTORE QRESYNC
* ENA= BLED QRESYNC
C2 OK foo

The second doesn't say "ENABLED CONDSTORE" because it was already enabled earlier on this connection.

Actually, it is per= fectly Ok for the server to return in response to C2:

* ENABLED QRESYNC = CONDSTORE

The text in the document wasn't entirely clear. It was trying to say that the preferred server behaviour is:

L1 = ENABLE A B
* ENABLED A B
<= /div>
L1 OK foo

L2 ENABL= E C
* ENABLED C
L2 OK foo

and not

L2 ENABLE C
= * ENABLED A B C
L2 OK foo
=

I clarified this.

(AKA: clients MUST rem= ember what they have enabled)

6.3.2 SELECT comman= d

The [UIDNEXT <n>] response is duplicated with two different pieces of text.
Again, this is a tool issue.

When deselecting= a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox is closed (see Paragraph 10). - I'm not sure where "Paragraph 10" is.
I will check. I think the section reference for response codes= is missing.

The last paragraph of this section has the word "deprecated" spelled as "depractated".
Fixed.

=

6.3.7 SUBSCRIBE<= br>

Speak of the devil.  Lots of sites violate the MUST NOT unilaterally remove rule.  Should we w= eaken it to SHOULD?
Done.
 = ; The justification for the MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want.

(also: by enabli= ng a non-default break the rules config, it's what our server does!)

6.3.8 UNSUBSCRIBE
<= br>
This command returns a tag= ged OK response only if the unsubscription is successful. - this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error?

<= /div>
For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed -= and likewise for subscribe if it's already subscribed it just say "yep, all good".
I agree that you= r server behaviour is sensible. Updated description of both SUBSCRIBE and UNSUBSCRIBE.


. create INBOX.foo
. OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed
. subscribe INBOX.foo
. OK Completed
. unsubscribe INBOX.foo
. OK Completed
. unsubscrib= e INBOX.foo
. OK Completed
. subscribe INBOX.foo
=
. OK Completed
. subscribe INBOX.foo
. OK Completed
<= br>

6.3.9 LIST

There's a weird line wra= pping near the top of page 44 where a paragraph is split in half:
= 

   The reference and ma=
ilbox name arguments are interpreted into a
   canonical form that represents an unambiguous left-to-right
   hierarchy.  The returned mailbox names will be in the interpreted
   form,

   that we call "canonical LIST pattern" later in this document.  To
   define the term "canonical LIST pattern" formally: it refers to the
   canonical pattern constructed internally by the server from the
   reference and mailbox name arguments.
I will double check, but I think it is anoth= er rendering issue to TXT format (there is a comment in bettween 2 parts of the sentence.<= br>


6.3.9.2 LIST = Return Options

=
The CHILDREN item is duplicated with two different pieces of text.

Agai= n, a rendering issue. These are actually 2 separate paragraphs under the same item.


6.4.4 SEARCH
 

   For example,
   the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
   deleted messages from Smith that were placed in the mailbox since
   February 1, 1994.

That's not strictly true - SAVEDATE would be "placed in the mailbox".  The wording sho= uld say "with INTERNALDATE greater than February 1, 1994" or so.
=

Good point. Fixed.


6.4.4.1 SAVE Result=

I'm not sure I understand the interaction here with closing and re-opening a mailbox.  I = would expect that closing a mailbox would wipe the SAVED result, and that trying to use a SAVED result when there isn't one should return an error.
I think Timo explain= ed this well in his response.


<= p> [snip]


7.1 Status Respo= nses

Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks like an attempt to do dot points!
Changed :-).

 [snip]

Best Regards,

Alexey

_______________________________________________
= Extra mailing list
Extra@ietf.org
https://ww= w.ietf.org/mailman/listinfo/extra

<= div style=3D"font-family:Arial;">
--
  Bron Gon= dwana, CEO, Fastmail Pty Ltd
  br= ong@fastmailteam.com

<= div style=3D"font-family:Arial;">
--b42ed1843bb541a6b5373f688aa0bb13--