Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt

From: Jan Kundrát <[email-masked]>
Date: Tue, 03 Dec 2013 11:45:38 +0100

So, with the WG last call deadline approaching, I would appreciate some 
sort of feedback on the points I raised.

The so far unaddressed issues are:

- Some corner cases are not well-defined when it comes to VANISHED 
reporting of messages which were just made available to the client via 
EXISTS.

- Relation with METADATA and ANNOTATE-EXPERIMENT-1. What I would like to 
see here is explicit confirmation that any change in METADATA increments 
the HIGHESTMODSEQ and that the data tracked by ANNOTATE-EXPERIMENT-1 are in 
fact "metadata" to be included in the MODSEQ tracking.

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 3 Dec 2013 14:22:05 +0200

On 26.11.2013, at 0.54, Jan Kundrát <[email-masked]> wrote:

>> However, I don't see a problem with this. Can you elaborate why sending VANISHED for UIDs the client hasn't seen yet is a problem?
> 
> Safety. QRESYNC is a complex extension and there's quite a potential for both servers and clients to introduce subtle bugs which only manifest themselves in uncommon situations. When my client sees something which doesn't make any sense, it's much better to reject this explicitly and point out that either the server or the client are broken than to lose data.
> 
> One example:
> 
> (two messages exists, UIDs 1 and 2)
> S: * 4 EXISTS
> S: * VANISHED 5
> 
> What UIDs are present at this point?

Doesn’t matter, you only knew about UIDs 1 and 2, which are present.

> Are there two, three or four messages in there, i.e. did VANISHED actually remoev anything?

Assuming we’ll now require that there are no unnecessary VANISHED replies, there are 3 messages. You’ll have to FETCH their UIDs (and other data) in any case, so you simply remove the last message. This is what imaptest does: http://hg.dovecot.org/imaptest/file/7c63941f6c03/src/client.c#l124

> This is why I proposed replacing EXISTS with something like the UID-based ARRIVED [1]. This was rejected in an attempt at reducing the amount of changes needed in the existing software, which makes sense. However, I believe that these corner cases have to described in the spec.

NOTIFY would allow sending FETCH responses with UIDs when new messages arrive.

---

From: Jan Kundrát <[email-masked]>
Date: Tue, 03 Dec 2013 17:27:11 +0100

On Tuesday, 3 December 2013 13:22:05 CEST, Timo Sirainen wrote:
> Assuming we’ll now require that there are no unnecessary 
> VANISHED replies, there are 3 messages. You’ll have to FETCH 
> their UIDs (and other data) in any case, so you simply remove 
> the last message. This is what imaptest does: 
> http://hg.dovecot.org/imaptest/file/7c63941f6c03/src/client.c#l124

And that's the point I'm making here. I want to make sure that each UID I 
see in the VANISHED list corresponds to an actual removal. Look at the 
current wording:

   Note that a VANISHED response [...] MUST only contain UIDs for
   messages expunged since the last VANISHED/EXPUNGE response sent for
   the currently opened mailbox or since the mailbox was opened.  That
   is, servers MUST NOT send UIDs for previously expunged messages,
   unless explicitly requested to do so by the UID FETCH (VANISHED)
   command.

This wording does not forbid the following behavior:

- 2 messages exist, UIDs 1 and 2
S: * 2 EXISTS
- UIDs now 1, 2, 3, 4, but client doesn't know that yet
- one message arrives, UIDs are now (1,2,3,4,5), the server does not send 
out EXISTS for some reason before it is removed in a concurrent session
S: * VANISHED 5

Yes, the server would be very dumb to do this. However, I prefer to not 
make any room for an incorrect interpretation here. See my other mail for 
the proposed wording.

Cheers,
Jan

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 03 Dec 2013 19:58:42 +0000

does this mean it would place the burden on the server to track what 
UIDs the client shoudl know about just so a client doesn't have to 
discard a VANISHED response for a message it had no knowledge of?

Seems backwards to me.  I would imagine it would be more trouble than 
it's worth to break things on that, when you can simply ignore it - why 
should a client care if a message it never knew about is deleted?

Seems to me that by placing more onerous requirements on the server 
(like maintaining a view of reported UIDs under all circumstances), that 
is more likely to lead to real in-the-world problems?

Adrien

------ Original Message ------
From: "Jan Kundrát" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 4/12/2013 5:27:11 a.m.
Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt
>>Assuming we’ll now require that there are no unnecessary VANISHED 
>>replies, there are 3 messages. You’ll have to FETCH their UIDs (and 
>>other data) in any case, so you simply remove the last message. This 
>>is what imaptest does: 
>And that's the point I'm making here. I want to make sure that each UID 
>I see in the VANISHED list corresponds to an actual removal. Look at 
>the current wording:
>
>- one message arrives, UIDs are now (1,2,3,4,5), the server does not 
>send out EXISTS for some reason before it is removed in a concurrent 
>session
>S: * VANISHED 5
>
>make any room for an incorrect interpretation here. See my other mail 
>for the proposed wording.
>
>Cheers,
>Jan
>
>-- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
>_______________________________________________
>imapext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/imapext

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 3 Dec 2013 22:08:06 +0200

This requirement doesn’t place any extra restrictions that don’t already exist with regular EXPUNGE. If server has sent “* 5 EXISTS” to client last, the server would never send “* 6 EXPUNGE” to client. In a similar way it wouldn’t send the equivalent VANISHED with 6’s UID. This situation of course happens only if a message arrives and is immediately expunged without never having had a chance to be sent to client via EXISTS.

So Jan isn’t talking about keeping track of which FETCH UID replies have been sent to client, that would be extra trouble. I think Jan’s wording here is confusing:

 A VANISHED response without the EARLIER tag MUST only refer to a UID
 which was visible to the session at the time the response is sent.
 In particular, this means that VANISHED response MUST NOT refer to a
 message whose removal was already communicated to the client, or to
 a message whose UID has not been present in the mailbox yet.  This is
 required to prevent a possible race condition where new arrivals for
 which the UID is not yet known by the client are expunged.

It shouldn’t be talking about UIDs’ visibility at all. It should be talking about messages’ visibility (via EXISTS). Whether the client knows the new messages’ UIDs isn’t relevant.

On 3.12.2013, at 21.58, Adrien de Croy <[email-masked]> wrote:

> 
> does this mean it would place the burden on the server to track what UIDs the client shoudl know about just so a client doesn't have to discard a VANISHED response for a message it had no knowledge of?
> 
> Seems backwards to me.  I would imagine it would be more trouble than it's worth to break things on that, when you can simply ignore it - why should a client care if a message it never knew about is deleted?
> 
> Seems to me that by placing more onerous requirements on the server (like maintaining a view of reported UIDs under all circumstances), that is more likely to lead to real in-the-world problems?
> 
> Adrien
> 
> 
>> And that's the point I'm making here. I want to make sure that each UID I see in the VANISHED list corresponds to an actual removal. Look at the current wording:
>> 
>> - one message arrives, UIDs are now (1,2,3,4,5), the server does not send out EXISTS for some reason before it is removed in a concurrent session
>> S: * VANISHED 5
>> 
>> Yes, the server would be very dumb to do this. However, I prefer to not make any room for an incorrect interpretation here. See my other mail for the proposed wording.
>> 
>> Cheers,
>> Jan
>>

---

From: Dave Cridland <[email-masked]>
Date: Tue, 3 Dec 2013 21:15:56 +0000

> (two messages exists, UIDs 1 and 2)

I think this is a terrible example, but I think the problem is real. Try
this one:

C: A SELECT INBOX
S: [...]
S: * UIDNEXT 10000
S: * EXISTS 8999
S: A OK [READ-WRITE] Done.

Simple enough here. Client wants to look at the last 1k messages. I'll show
an ESEARCH, though this could equally well be a FETCH.

C: B UID SEARCH RETURN (ALL) 8000:*
S: * ESEARCH (TAG "B") UID ALL 9000:9999
S: B OK Completed.

But now:

C: C NOOP
S: * VANISHED 5
S: C OK Done.

How many messages are now in the INBOX?

Dave.

---

From: Jan Kundrát <[email-masked]>
Date: Wed, 04 Dec 2013 00:00:39 +0100

On Tuesday, 3 December 2013 21:08:06 CEST, Timo Sirainen wrote:
> So Jan isn’t talking about keeping track of which FETCH UID 
> replies have been sent to client, that would be extra trouble.

Thanks, that's exactly what I meant. You are right that talking about 
messages is clearer than mudding the waters with UIDs -- sorry for this 
confusion.

What about this, then:

   Note that a VANISHED response without the EARLIER tag (i.e.
   a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages
   expunged in other connections) MUST only refer to a message
   which was visible to the client at the time VANISHED is sent.
   That is, servers MUST NOT send send UIDs for previously expunged
   messages, or messages which were not announced to the client via
   EXISTS. This means that each UID listed in a VANISHED response
   results in the client decrementing the message count by one. This
   is required to prevent a possible race condition where new arrivals
   for which the UID is not yet known by the client are immediately
   expunged.

   For example, if the mailbox contained UIDs 2 and 4, each of the
   following responses would consitute a broken server implementation:

   * VANISHED 1
   * VANISHED 3
   * VANISHED 5

I have the impression that splitting the VANISHED response into VANISHED 
and VANISHED EARLIER would make sense. These are very different from a 
client's point of view. If the XML source of the RFC is available, I'm 
volunteering to make this happen.

Cheers,
Jan

---

From: Michael M Slusarz <[email-masked]>
Date: Fri, 06 Dec 2013 17:16:14 -0700

Last minute suggestions, mostly editorial:

* Abstract: The first two paragraphs are a lengthy description on  
CONDSTORE behavior with respect to multiple IMAP clients  
accessing/altering a common mailbox (a "protected update mechanism").   
That seems to be a rarer use-case; the majority of IMAP users are  
using a single client to access personal mailboxes vs. the more  
specialized use of a "message queue".

To me, the more important real-world usage of CONDSTORE is the ability  
to quickly and accurately sync flag changes and/or the more general  
ability to accurately determine if a mailbox has been altered via  
HIGHESTMODSEQ.  I suggest this should be mentioned first instead of  
second.

* Regarding HIGHESTMODSEQ/NOMODSEQ: the document uses the language  
"the OK untagged response".  That can be a bit confusing when reading  
since it can be interpreted as SELECT/EXAMINE only containing a single  
untagged OK response.

Understood that someone needs to be familiar with 3501 before being  
able to interpret this document, but wondering if the phrase "an OK  
untagged response" should be used instead.  To me, this more clearly  
indicates that HIGHESTMODSEQ/NOMODSEQ needs to appear in one of the  
(possibly multiple) OK responses.

* All examples referring to MODSEQs: The examples can be a bit hard to  
visually parse given large MODSEQ numbers, since it is not readily  
apparent the relationship between the various MODSEQ values.

Example 3:

    C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045)
       +FLAGS.SILENT (\Deleted)
    S: * 1 FETCH (UID 4 MODSEQ (12121231000))
    S: * 2 FETCH (UID 6 MODSEQ (12121230852))
    S: * 4 FETCH (UID 8 MODSEQ (12121130956))
    S: a103 OK Conditional Store completed

In this example, the '1212123' prefix is noise that makes it difficult  
to determine the relationship between the significant digits in the  
MODSEQs.  On first glance, it is not easy to see that 12121230852 >  
12121230045.

To me, at least, simpler MODSEQs make for an easier understanding that  
all UIDs specified in the STORE command were in fact changed:

    C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 5)
       +FLAGS.SILENT (\Deleted)
    S: * 1 FETCH (UID 4 MODSEQ (6))
    S: * 2 FETCH (UID 6 MODSEQ (7))
    S: * 4 FETCH (UID 8 MODSEQ (8))
    S: a103 OK Conditional Store completed

* UID information in FETCH responses is only required if QRESYNC is  
enabled (3.2.3).  However, the only examples of what happens when an  
external agent triggers an unsolicited FETCH response appear in the  
CONDSTORE section, and it doesn't include UID information.  E.g., from  
Page 17:

        C: C360 NOOP
        S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
        S: C360 OK Noop completed

While discussing QRESYNC prospectively within the CONDSTORE definition  
might be a bit confusing, it is also the logical place to do so given  
the current examples.  At least a mention might be made to 3.2.3:  
'Note that this FETCH response MUST include UID data if both a  
"CONDSTORE enabling command" has been issued and QRESYNC is supported  
by the server'.

* Section 3.2.2 typo: "REQUIREd" should be "REQUIRED".

* Section 3.2.5: Document indicates BAD tagged response should be  
issued if VANISHED UID FETCH modifier is either used with a FETCH  
command or if ENABLE QRESYNC has not been issued.

For completeness, this should also be made clear for the instance  
where the VANISHED modifier is either used without CHANGEDSINCE -or-  
an additional UID FETCH modifier is used:

    The VANISHED UID FETCH modifier MUST only be specified together with
    the CHANGEDSINCE UID FETCH modifier. If the VANISHED UID FETCH modifier
    is used without the CHANGEDSINCE UID FETCH modifier, or if additional
    UID FETCH modifiers besides CHANGEDSINCE and VANISHED are used, the
    server MUST respond with a tagged BAD response.

michael

___________________________________
Michael Slusarz [[email-masked]]

---

From: Michael M Slusarz <[email-masked]>
Date: Fri, 06 Dec 2013 17:56:20 -0700

>    S: a103 OK Conditional Store completed

On further review: isn't this example wrong?  Why is UID 8 returned?   
It has a MODSEQ lower than the UNCHANGEDSINCE value, so it didn't fail  
the UNCHANGEDSINCE test.  Therefore, it must have already had the  
\Deleted flag set.  Since .SILENT was specified, only the messages  
that had flag data altered should be returned in FETCH untagged  
responses (UIDs 4,6).

The correct example should be:

Or maybe this was intended:

     S: * 4 FETCH (UID 8 MODSEQ (12121230956))

(i.e. MODSEQ 12121*2*30956 instead of 12121*1*30956.  This is a good  
example of why simpler MODSEQ examples might be preferable).

michael

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Dec 2013 11:33:27 +0000

Hi Jan,

On 03/12/2013 10:45, Jan Kundrát wrote:
> So, with the WG last call deadline approaching, I would appreciate 
> some sort of feedback on the points I raised.
>
> - Relation with METADATA and ANNOTATE-EXPERIMENT-1. What I would like 
> to see here is explicit confirmation that any change in METADATA 
> increments the HIGHESTMODSEQ
Yes, I just added this to the document.
> and that the data tracked by ANNOTATE-EXPERIMENT-1 are in fact 
> "metadata" to be included in the MODSEQ tracking.
Ok, I clarified this in my copy.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Dec 2013 11:44:29 +0000

Hi Michael,
Thank you for your detailed comments.

> HIGHESTMODSEQ.  I suggest this should be mentioned first instead of 
Yes, I was already thinking about this. At minimum I want to swap the 
order. I haven't done this change in my copy of the document yet, but it 
is pending.

> (possibly multiple) OK responses.
Good point, changed.

> MODSEQs.  On first glance, it is not easy to see that 12121230852 > 
I am a bit worried about introducing bugs by a change like this (I've 
done that in the past). So I would like to hear what other people think 
about this?

  [...]
> * Section 3.2.2 typo: "REQUIREd" should be "REQUIRED".
Fixed, thanks.

>    server MUST respond with a tagged BAD response.
I don't think we can have restriction on other future FETCH modifiers. 
So I am Ok with your text if "or if additional UID FETCH modifiers 
besides CHANGEDSINCE and VANISHED are used" is dropped from it. Does 
this sound reasonable?

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Dec 2013 11:47:42 +0000

Hi Michael,
Answering to your remaining comment in a separate message.

> "CONDSTORE enabling command" has been issued and QRESYNC is supported 
Hmm, this brings an interesting question: should the requirement to 
return UIDs also apply to CONDSTORE?

Best Regards,
Alexey

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 09 Dec 2013 12:05:43 +0000

------ Original Message ------
From: "Alexey Melnikov" <[email-masked]>
>done that in the past). So I would like to hear what other people think 
I agree with Michael.

When I first saw the very long UIDs, I found it hard to compare them.  
This made it more effort to see what was going on.  There's also more 
chance of a typo, as in the UID for #4 (12121130956 should read 
12121230956), which makes the example incorrect.

Cheers

Adrien

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Dec 2013 12:07:17 +0000

Hi Jan,

On 03/12/2013 23:00, Jan Kundrát wrote:
>> So Jan isn’t talking about keeping track of which FETCH UID replies 
>> have been sent to client, that would be extra trouble.
>
> messages is clearer than mudding the waters with UIDs -- sorry for 
> this confusion.
>
> What about this, then:
>
Ok, I like this text. This was always the intent and this is what my 
client assumes.

> I have the impression that splitting the VANISHED response into 
> VANISHED and VANISHED EARLIER would make sense. These are very 
> different from a client's point of view. If the XML source of the RFC 
> is available, I'm volunteering to make this happen.
https://github.com/aamelnikov/draft-rfc4551-bis
But wait till I post a new version (should be later today).

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 09 Dec 2013 23:17:21 +1100

> return UIDs also apply to CONDSTORE?

I would vote yes - CONDSTORE enabling command means UIDs in everything.

It's very unlikely to break any existing clients.

Bron.

-- 
  Bron Gondwana
  [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Dec 2013 12:21:05 +0000

> example of why simpler MODSEQ examples might be preferable).
Good catch. I've fixed the example for now.

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 9 Dec 2013 14:28:22 +0200

> It's very unlikely to break any existing clients.

It wouldn’t hurt, but I’m not sure if it would help much either. I think I proposed this somewhere, but I can’t find where. Or at least not in errata. Anyway, I think the point was that with QRESYNC the client wouldn’t necessarily have to keep MSN <-> UID mapping, since it gets VANISHED replies. With only CONDSTORE enabled the client would still have to keep the mapping to handle EXPUNGE replies.

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 9 Dec 2013 14:30:33 +0200

On 9.12.2013, at 14.05, Adrien de Croy <[email-masked]> wrote:

>>> To me, at least, simpler MODSEQs make for an easier understanding that all UIDs specified in the STORE command were in fact changed:
>>> 
>> I am a bit worried about introducing bugs by a change like this (I've done that in the past). So I would like to hear what other people think about this?
> I agree with Michael.
> 
> When I first saw the very long UIDs, I found it hard to compare them.  This made it more effort to see what was going on.  There's also more chance of a typo, as in the UID for #4 (12121130956 should read 12121230956), which makes the example incorrect.

Then again if only short modseqs are shown everywhere, client implementors are going to use 32bit ints for them..

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 09 Dec 2013 12:35:11 +0000

------ Original Message ------
From: "Timo Sirainen" <[email-masked]>
>>>>  To me, at least, simpler MODSEQs make for an easier understanding 
>>>>that all UIDs specified in the STORE command were in fact changed:
>>>>
>>>  I am a bit worried about introducing bugs by a change like this 
>>>(I've done that in the past). So I would like to hear what other 
>>>people think about this?
>>  I agree with Michael.
>>
>Then again if only short modseqs are shown everywhere, client 
>implementors are going to use 32bit ints for them..

from memory I thought it was explicitly stated to use larger than 32 
bits signed.

Most ironic that message size is limited to 32 bits and mod seq isn't.  
That one is a train coming the wrong way down the tunnel.

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 9 Dec 2013 14:41:33 +0200

On 9.12.2013, at 14.35, Adrien de Croy <[email-masked]> wrote:

> from memory I thought it was explicitly stated to use larger than 32 bits signed.

Sure, but it’s only mentioned twice in the document. Easy to forget while implementing and only looking at examples with small modseq numbers. 1-2 examples with large modseqs would be good I think.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 9 Dec 2013 13:42:13 +0100

> Then again if only short modseqs are shown everywhere, client implementors are going to use 32bit ints for them..

I completely agree with Timo.

It's easy to make them comparable at a glance, just make sure there's
always a few digits more and the top digit increases. It's easy to
tell that 38823478494237 > 22347894237.

64-bit numbers are nice, they give us range. (Did I say 64? Oh foo. I
meant 63. Must be kind to the java clients.)

Arnt

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 10 Dec 2013 14:22:06 +1100

> meant 63. Must be kind to the java clients.)

It sure was nice in Cyrus switching to 64 bits for quota and ditching uquota_t in
the process.  63 bits ought to be enough for anybody.

Bron.

-- 
  Bron Gondwana
  [email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Dec 2013 14:14:20 +0100

Hi,

> Then again if only short modseqs are shown everywhere, client implementors are going to use 32bit ints for them..

Best to show a real life example that has been cut and pasted from log
files.  That gets rid of any introduced errors.

Eliot

---

From: Michael M Slusarz <[email-masked]>
Date: Tue, 10 Dec 2013 11:07:49 -0700

Quoting Alexey Melnikov <[email-masked]>:

>> where the VANISHED modifier is either used without CHANGEDSINCE  
>> -or- an additional UID FETCH modifier is used:
>>
> I don't think we can have restriction on other future FETCH  
> modifiers. So I am Ok with your text if "or if additional UID FETCH  
> modifiers besides CHANGEDSINCE and VANISHED are used" is dropped  
> from it. Does this sound reasonable?

That sounds more correct.

FWIW, I did a quick check of Cyrus and Dovecot when I wrote this and  
they both issue BAD responses.

michael

---

From: Michael M Slusarz <[email-masked]>
Date: Tue, 10 Dec 2013 11:12:06 -0700

Quoting Arnt Gulbrandsen <[email-masked]>:

>> > When I first saw the very long UIDs, I found it hard to compare  
>> them.  This made it more effort to see what was going on.  There's  
>> also more chance of a typo, as in the UID for #4 (12121130956  
>> should read 12121230956), which makes the example incorrect.
>>

Maybe a combo of what Timo and Arnt suggest.  Keep a couple of  
examples with longer modseqs, to ensure there are some non 32-bit  
examples, but for those examples format the long modsesq the way Arnt  
suggests to make it easier to distinguish them.

michael

---

From: Michael M Slusarz <[email-masked]>
Date: Tue, 10 Dec 2013 11:24:50 -0700

Quoting Timo Sirainen <[email-masked]>:

> It wouldn’t hurt, but I’m not sure if it would help much either. I  
> think I proposed this somewhere, but I can’t find where. Or at least  
> not in errata.

Errata #1807 to RFC 5162.

> Anyway, I think the point was that with QRESYNC the client wouldn’t  
> necessarily have to keep MSN <-> UID mapping, since it gets VANISHED  
> replies. With only CONDSTORE enabled the client would still have to  
> keep the mapping to handle EXPUNGE replies.

Agreed.

As Bron points out, it's not going to break any existing clients -  
clients still need to keep a MSN/UID mapping for this particular  
CONDSTORE behavior regardless of the presence of UIDs.  Given the  
assumption elsewhere in the draft that it is expected server authors  
will implement both extensions at the same time, it would be easiest  
to simply make all FETCH responses look the same.  And it eliminates  
the extra work documentation-wise to describe two different FETCH  
responses based on very subtle environment differences that apply to  
only a very few client authors.

michael

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Dec 2013 13:50:14 +0000

> the process.  63 bits ought to be enough for anybody.
This is an issue that Dave Cridland also raised privately with me, but I 
forgot to report it on the mailing list. So, should the new document 
require use of 63 bit mod-sequences?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 11 Dec 2013 15:50:04 +0100

On Wed, Dec 11, 2013 at 01:50:14PM +0000, Alexey Melnikov wrote:
> This is an issue that Dave Cridland also raised privately with me,
> but I forgot to report it on the mailing list. So, should the new
> document require use of 63 bit mod-sequences?

Yes.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 11 Dec 2013 16:53:22 +0200

>> document require use of 63 bit mod-sequences?

Yeah, 63bit is enough, no point in making people’s life more difficult than it has to be.

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 12 Dec 2013 07:51:05 +1100

> Yeah, 63bit is enough, no point in making people’s life more difficult than it has to be.

I agree (even if I do have to go fix my personal user where I intentionally set the high bit to see what breaks...)

Bron.

-- 
  Bron Gondwana
  [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Dec 2013 22:37:21 +0000

Hi Michael,

> "CONDSTORE enabling command" has been issued and QRESYNC is supported 
I think all responses of the Example 14 need to be updated. So yes, I've 
updated the draft to say something similar to what you suggested.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Dec 2013 23:23:13 +0000

On 14/12/2013 22:37, Alexey Melnikov wrote:
>> CONDSTORE section, and it doesn't include UID information.  E.g., 
>> from Page 17:
>>
>>        C: C360 NOOP
>> While discussing QRESYNC prospectively within the CONDSTORE 
>> definition might be a bit confusing, it is also the logical place to 
>> do so given the current examples.  At least a mention might be made 
>> to 3.2.3: 'Note that this FETCH response MUST include UID data if 
>> both a "CONDSTORE enabling command" has been issued and QRESYNC is 
>> supported by the server'.
> I think all responses of the Example 14 need to be updated. So yes, 
> I've updated the draft to say something similar to what you suggested.
I also made the requirement to include UID information a SHOULD level 
requirement for CONDSTORE. This would encourage new implementations to 
do that without breaking existing CONDSTORE-only implementations.