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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 15 September 2020 17:31 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF63F3A14B3 for <extra@ietfa.amsl.com>; Tue, 15 Sep 2020 10:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJyMm9lxu9Vl for <extra@ietfa.amsl.com>; Tue, 15 Sep 2020 10:31:58 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 101923A14B1 for <extra@ietf.org>; Tue, 15 Sep 2020 10:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1600191117; d=isode.com; s=june2016; i=@isode.com; 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 [192.168.0.5] (97e1f4dd.skybroadband.com [151.225.244.221]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <X2D6jAAsYSVU@waldorf.isode.com>; Tue, 15 Sep 2020 18:31:56 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Stephan Bosch <stephan.bosch=40open-xchange.com@dmarc.ietf.org>, extra@ietf.org
References: <159238763595.1803.574245566610096074@ietfa.amsl.com> <b4390473-241f-6860-2ebb-fdf4dad06ec8@isode.com> <a7304716-b160-4731-e145-934cb127d28e@open-xchange.com> <b908d009-5ee4-9caa-63ea-23788a270188@open-xchange.com>
Message-ID: <d16eb994-157d-60c4-b60e-d7e852064b6a@isode.com>
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: <b908d009-5ee4-9caa-63ea-23788a270188@open-xchange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/KIaZBXqm2JiE9ywFb13GwgjYnko>
Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-15.txt
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=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:

  [snip]

>>
>> -> 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.

  [snip]

>> 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.
Fixed.
>>
>>    In the case of a mailbox that has UIDNOTSTICKY status (see
>>    UIDNOTSTICKY response code definition)
>> -> See where? Needs reference.
Fixed.
>>
>> 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.
Added.
>>
>> 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).
Fixed.
>>
>>    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.
Fixed
>> 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,

Alexey