[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Timo Sirainen wrote:


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>


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?