Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-15.txt

Alexey Melnikov <> Tue, 15 September 2020 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF63F3A14B3 for <>; Tue, 15 Sep 2020 10:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uJyMm9lxu9Vl for <>; Tue, 15 Sep 2020 10:31:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 101923A14B1 for <>; Tue, 15 Sep 2020 10:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1600191117;; s=june2016;; bh=HtmR1NdS8YXOxsnBAyI2+WYbXqi1wSi+vPBO2P2ycDk=; 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=Y0pT3YHsv36kVPTjmYtskQxY/YFDOTo6+FUMyKm0/mVR1DELp4ArvnZRqATVICPJgKQNCZ F+Cn0XtGqjC3tIovCaYApu2fj+grQ1lmvYo5C+ABWBGdriDBgVTHTecdcCGG5w3lbLt8dt QEHoZw4xcEGlkcP7ApiSU9t0Ikd+gew=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 15 Sep 2020 18:31:56 +0100
From: Alexey Melnikov <>
To: Stephan Bosch <>,
References: <> <> <> <>
Message-ID: <>
Date: Tue, 15 Sep 2020 18:31:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <>
Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-15.txt
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, 15 Sep 2020 17:32:00 -0000

Hi Stephan,

Below I followup on the rest of your suggested changes/questions. 
Hopefully I addressed/replied to all remaining issues that you've raised.

On 16/07/2020 13:21, Stephan Bosch wrote:
> Hi Alexey,
> Did you see my review (below) ?
> Regards,
> Stephan.
> Op 22-6-2020 om 19:56 schreef Stephan Bosch:


>> -> The SPECIAL-USE extension, which adds selection and return 
>> options, is not mentioned here, while the specification envelops it.

The idea is that SPECIAL-USE attributes are returned automatically, even 
when not requested. So this is a subset of SPECIAL-USE functionality.


>> section-6.3.12:
>>    On successful completion of an APPEND, the server SHOULD return an
>>    APPENDUID response code.
>> -> This response code is not explained at this port. Provide brief 
>> purpose or reference to where it is explained.
>>    In the case of a mailbox that has UIDNOTSTICKY status (see
>>    UIDNOTSTICKY response code definition)
>> -> See where? Needs reference.
>> section-6.4.5:
>> -> Now that the BINARY fetch items are also part of the 
>> specification, the "<section>" bit should probably be described 
>> separately before the enumeration of fetch data items. Stuffing it in 
>> the description of BODY is confusing, as it applies to several fetch 
>> items now.
I moved this to a separate subsection now.
>>    BODYSTRUCTURE  The [MIME-IMB] body structure of the message. This is
>>       computed by the server by parsing the [MIME-IMB] header fields in
>>       the [RFC-5322] header and [MIME-IMB] headers.
>>    ENVELOPE  The envelope structure of the message.  This is computed by
>>       the server by parsing the [RFC-5322] header into the component
>>       parts, defaulting various fields as necessary.
>> -> At least these two could use a forward reference to the FETCH 
>> response section, where the semantics of these are described in more 
>> detail. Could also put a single reference in the sentence announcing 
>> the list of data items.
>> section-6.4.7:
>>    On successful completion of a COPY, the server SHOULD return a
>>    COPYUID response code.
>> -> This response code is not explained at this point. Provide brief 
>> purpose or reference to where it is explained (weirdly, section on 
>> MOVE does this correctly).
>>    In the case of a mailbox that has UIDNOTSTICKY status (see the
>>    UIDNOTSTICKY response code), the server MAY omit the COPYUID response
>>    code as it is not meaningful.
>> -> See where? Needs reference.
>> section-7.4.2:
>>             Note: [RFC-5322] requires that all messages have a valid
>>             Date header.  Therefore, the date member in the envelope can
>>             not be NIL or the empty string.
>> -> We all like to live in a perfect world, but what should the server 
>> do if the sender is naughty and the message has no Date header? 
>> Return the internal date instead?
>>         Note: [RFC-5322] requires that the In-Reply-To and Message-
>>             ID headers, if present, have non-empty content. Therefore,
>>             the in-reply-to and message-id members in the envelope can
>>             not be the empty string.
>> -> Same...
I clarified that malformed message can have this as the empty string.
>>             Note: [RFC-5322] requires that all messages have a valid
>>             From header.  Therefore, the from, sender, and reply-to
>>             members in the envelope can not be NIL.
>> -> Same...

I clarified that a malformed or a draft message can have these as NIL.

Best Regards,