Subject: [MORG] WGLC on draft-ietf-morg-inthread-00

From: Timo Sirainen <[email-masked]>
Date: Fri, 13 Feb 2009 17:50:53 -0500

Hello people,

Let's see if we can get our first RFC out:

This message officially starts the MOrg Working Group Last Call for the
following document:

The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions

<http://www.ietf.org/internet-drafts/draft-ietf-morg-inthread-00.txt>

The Working Group Last Call for this document starts on February 13th
and will end on February 28th. Please send any comments to the MOrg
mailing list or to the document authors. If you chose to do the latter,
please CC both Timo Sirainen <[email-masked]> and Randall Gellens
<[email-masked]>. Reviews that found no issues are also welcomed, so
if you review the document and find it acceptable, please let the
mailing list/authors+chairs know as well.

Also, in order to simplify tracking of various issues, please clearly
mark each issue in the message (ideally in the subject header field,
sending 1 issue per email message). Also, I would strongly encourage to
provide specific suggestions for solving issues you've raised (or at
least show an example of how your issue can be addressed).

- Timo, MOrg co-chair

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Feb 2009 22:19:40 +0000

><http://www.ietf.org/internet-drafts/draft-ietf-morg-inthread-00.txt>
Most of my comments are editorial:

In Section 2:

>    An IMAP server (see [RFC3501]) that supports the THREAD=REFS
>    extension MUST announce THREAD=REFS as capabilities.
>
as a capability.

>    This extension
>    adds no new commands and responses, only a new thread algorithm.
>
I think s/thread/threading.
    [...]   

>    An IMAP server that supports SEARCH=INTHREAD MUST announce both
>    SEARCH=INTHREAD and THREAD=REFS as capabilities. This extension
>
I suggest changing "This extension" to "The SEARCH=INTHREAD extension"

>    adds
>    no new commands and responses, but adds four new search-keys,
>    INTHREAD, THREADROOT, THREADLEAF and MESSAGEID, and one search
>    return option, THREAD=REFS.
>
 [...]

>3.4. The MESSAGEID Search Key
>
>    The MESSAGEID search key takes a sigle argument, and matches a
>    message if that message's normalized nessage-id is the same as the
>    argument.
>
I think the document needs to define what "normalized" means here.

>4.  The THREAD=REFS Thread Algorithm
>
>    The THREAD=REFS thread algorithm is defined as the part of
>    THREAD=REFERENCES (see [RFC5256]) which concerns itself with the
>    References, In-Reply-To and Message-ID fields.  THREAD=REFS ignores
>    Subject.
>
Does this mean that the algorithm is effectively ignoring step (5) from 
RFC 5256?

>    It is explicitly permitted for the server to persistently store
>    threading information, even if this causes the server to return
>    different information than it would otherwise. This can happen if
>    the first messages in a thread are deleted, for example.
>
This is a strange paragraph. Why is it needed?

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Feb 2009 22:27:58 +0000

Some additional comments:

>3.1. The INTHREAD Search Key
>  
>
 [...]

>    The INTHREAD search-key matches a message if its subsidiary search-
>    key matches at least one message in the same thread as the message.
>
Every time I looked at this sentence it makes me 20 seconds in order to 
understand it.
Wouldn't it be better to say that first all messages matching the 
subsidiary search-key are found. Then all messages belonging to the same 
threads are returned.

>3.5. The THREAD=* Search Return Option(s)
>
>    The THREAD=* search return options enables the client to select
>    which threading algorithm the server uses when processing INTHREAD,
>    THREADROOT and THREADLEAF as part of a SEARCH command. If THREAD=*
>    isn't specified, then the default for the SEARCH command is
>    THREAD=REFS.
>
I hate to raise this issue, but should we establish an IANA registry for 
search return options?

>5.  Formal Syntax
>
>    The following syntax specification uses the Augmented Backus-Naur
>    Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines
>    the non-terminals "capability" and "search-key", [RFC4466] defines
>    "search-return-opt", [RFC5256] defines "thread-alg", and [RFC5322]
>    defines "id-left" and "id-right".
>
>    Except as noted otherwise, all alphabetic characters are case-
>    insensitive.  The use of upper or lower case characters to define
>    token strings is for editorial clarity only.  Implementations MUST
>    accept these strings in a case-insensitive fashion.
>
>        capability   =/ "SEARCH=INTHREAD" / "THREAD=REFS"
>
>        search-key   =/ "INTHREAD" SP search-key / "MESSAGEID" SP "<"
>                        id-left "@" id-right ">"
>
I am not entirely convinced (but I haven't yet checked that '"<" id-left 
"@" id-right ">"' corresponds
to atom IMAP syntax. I think quoted strings/literals would be needed to 
represent some values.

> / "THREADROOT" /
>                        "THREADLEAF"

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Feb 2009 22:33:51 +0000

Alexey Melnikov wrote:

> I am not entirely convinced (but I haven't yet checked that '"<" 
> id-left "@" id-right ">"' corresponds
> to atom IMAP syntax. I think quoted strings/literals would be needed 
> to represent some values.

I am now positive about that:

 From RFC 5322:

   id-left         =   dot-atom-text / obs-id-left

   id-right        =   dot-atom-text / no-fold-literal / obs-id-right

   dot-atom-text   =   1*atext *("." 1*atext)

   atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"

"{" and "}" are not allowed in IMAP atom:

atom            = 1*ATOM-CHAR

ATOM-CHAR       = <any CHAR except atom-specials>

atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards /
                  quoted-specials / resp-specials

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Feb 2009 22:36:26 +0000

>mailing list/authors+chairs know as well.
I think the document is in a good shape, but I think a couple of my 
issues should be addressed before going further (ABNF and definition of 
normalization).

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 14 Feb 2009 22:08:14 -0500

Hi Timo,

> <http://www.ietf.org/internet-drafts/draft-ietf-morg-inthread-00.txt>

Technically OK, but I was left wondering why the heck I would want to 
implement the new SEARCH capabilities if I were a client. I think the 
document needs to have more examples or concrete use cases to better 
explain why these changes are important and how clients would make use of 
them, and what the benefit to the server is to implement.

At this point in time I think every IMAP extension has got to do a good job 
"selling itself" - because a lot of people (not the crowd here) think IMAP 
is good enough and more extensions are just "bloat" that no one will really 
use. All the MORG documents have got to make a strong case for why their 
adoption is beneficial.

For this document an explanation of what clients are doing today with 
threads and IMAP protocol use with that vs what would happen with the new 
extension would go a long way to justifying implementing this.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 15 Feb 2009 14:58:11 +0100

More later. Just now:

> I am now positive about that:

Why?

A client isn't permitted to send INTHREAD unless the server says it 
understands this syntax, so AFAICT nothing constrains the arguments to 
atoms.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 15 Feb 2009 14:05:46 +0000

> understands this syntax, so AFAICT nothing constrains the arguments to 

Creating new data types is bad, as it complicates protocol parsers.
If you remember, we had the same argument in Lemonade about URIs and at 
the end decided not to define a new data type.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 15 Feb 2009 18:22:53 +0100

Alexey Melnikov writes:
> If you remember, we had the same argument in Lemonade about URIs and 
> at the end decided not to define a new data type.

I'm not creating one. Message-IDs exist and the point is to use them. 
That are three possibilities:

1. Send "<" id-left "@" id-right ">" on the wire. As I put into the 
current draft.

2. Send an IMAP atom on the wire and say "when dequoted, MUST be < 
id-left @ id-right >". (As I recall, some Lemonade document does 
something like that.)

3. Send an IMAP atom on the wire and skip the rules about what it contains.

I dislike option 3 since the whole point is to deal with message-ids, so 
option 3 doesn't fit with the goal. As a general principle I think the 
syntax should correspond to the goal it supposedly expresses.

I dislike option 2 since I, as a parser, still have to check "<" id-left 
"@" id-right ">", it's just that I have to check atom syntax first and 
then parse the output of that. Option 2 complies with RFC 1925 point 
6a, but doesn't any extra value. (The matter would be different if 
something wanted the argument to be an atom.)

That leaves option 1 as my favoured option. Your?

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 15 Feb 2009 12:38:12 -0500

On Feb 15, 2009, at 12:22 PM, Arnt Gulbrandsen wrote:

>> If you remember, we had the same argument in Lemonade about URIs  
>> and at the end decided not to define a new data type.
>
> I'm not creating one. Message-IDs exist and the point is to use  
> them. That are three possibilities:
>

Dovecot typically parses input by reading and parsing the whole  
command. That won't work if the input doesn't have only valid IMAP  
atoms/strings/etc, so this would pretty much break my parser.

> 3. Send an IMAP atom on the wire and skip the rules about what it  

By "IMAP atom" I guess you mean string or something?

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 15 Feb 2009 19:08:35 +0000

> atoms/strings/etc, so this would pretty much break my parser.

Same for Isode's implementation. I would have to special case the new 
message-id data type.

> By "IMAP atom" I guess you mean string or something?

IMAP atom can't be used, because obsolete Message-id syntax allows for 
some weird things, including bare CRs.
So yes, I think this means IMAP string.