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

[Alexey Melnikov <[e-mail]>]

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