Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC

From: Timo Sirainen <[email-masked]>
Date: Fri, 04 Feb 2011 20:18:28 +0200

On Tue, 2011-01-25 at 12:43 -0500, Barry Leiba wrote:
> We're halfway through the WGLC period, and have had no comments.
> Please, let's get at least two or three reviews of this version, and
> confirm (or refute) that it's ready to go.

Pretty quiet in here.. I've anyway reviewed. Just one thing:

>    S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL
>    4001,4003,4005,4007,4009
>    S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 6789023554)
>    UID ALL 195001:195004,169788

UIDVALIDITY changes rather suddenly in this example, so I think that's
just unnecessary confusion. Also the second one's UID set isn't sorted
as it should be.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Feb 2011 14:12:35 -0500

Hi, Timo.

> just unnecessary confusion. Also the second one's UID set isn't sorted

The UIDVALIDITY change does seem odd.  Given the UID ranges, it seems
intentional, but a little weird.  Alexey, did you have a particular
reason for including an example like that, without textual
explanation?

The sequence set does not need to be sorted; why do you say "as it
should be"?  According to RFC 3501, sorting it is a "MAY":

sequence-set    = (seq-number / seq-range) *("," sequence-set)
                    ; set of seq-number values, regardless of order.
                    ; Servers MAY coalesce overlaps and/or execute the
                    ; sequence in any order.
                    ; Example: a message sequence number set of
                    ; 2,4:7,9,12:* for a mailbox with 15 messages is
                    ; equivalent to 2,4,5,6,7,9,12,13,14,15
                    ; Example: a message sequence number set of *:4,5:7
                    ; for a mailbox with 10 messages is equivalent to
                    ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
                    ; overlap coalesced to be 4,5,6,7,8,9,10.

I actually think it's good to have an example where they're not
sorted, to make sure it's understood that clients MUST deal with that.

Barry

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 04 Feb 2011 21:43:23 +0200

> reason for including an example like that, without textual

I think textual explanation at least would be good if it's left.

> should be"?  According to RFC 3501, sorting it is a "MAY":

I thought they were supposed to be sorted in ESEARCH ALL. I even
verified it from the RFC, but looks like I just carelessly read what I
expected to read instead of what it really read. :) So forget about
this.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Feb 2011 21:25:57 +0000

Timo Sirainen wrote:

>just unnecessary confusion.
>
Good point. Should be UIDVALIDITY 1 on the second quoted line as well.

>Also the second one's UID set isn't sorted
>as it should be.
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Feb 2011 17:00:09 -0500

> Good point. Should be UIDVALIDITY 1 on the second quoted line as well.

And I think we should make the UIDs closer to the range in the first
line.  They don't HAVE to be, but the way it is seems a little odd.

Shall I submit the change and we say WGLC is done and we're ready to
send this up to the IESG?  Can we get a couple more reviews before we
do that?

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Feb 2011 15:48:27 -0700

> send this up to the IESG?  Can we get a couple more reviews before we

Sounds good to me. I've just changed the state to "revised I-D needed"
in the tracker. Once a new version magically appears, I'll request IETF
Last Call.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 Feb 2011 18:00:55 -0500

> in the tracker. Once a new version magically appears, I'll request IETF

The magic, she has happened.

b

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Feb 2011 16:04:51 -0700

> The magic, she has happened.

Magic is good.

Expect IETF Last Call soon.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Feb 2011 17:44:41 -0700

> Expect IETF Last Call soon.

But first I've reviewed the spec. :)

IMHO this document looks to be in good shape and I've found no
substantive issues.

Section 2 says:

   [[fix-for-pub-1: "X-DRAFT-I05-MMBX"
   (changes for publication)]]

When will this value be assigned, and by whom?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Feb 2011 10:29:55 +0000

>When will this value be assigned, and by whom?
The best thing is to do this in AUTH48 once it is clear that the 
document wouldn't change. So the change should be done by RFC Editor/IANA.