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

From: Stephan Bosch <[email-masked]>
Date: Wed, 2 Sep 2020 22:06:23 +0200

Hi Alexey,

On 29/07/2020 17:55, Alexey Melnikov wrote:
> Hi Stephan,
> 
> Thank you very much for your detailed review. Replying to most of your 
> comments below. Your remaining issues I will address in a later 
> revision/reply to later.
> 

>>> section-6.3.9:
>>>
>>> -> This section mentions several examples of specific selection and 
>>> return options without introduction. It should maybe refer to 
>>> subsequent sections at the first instance of this.
> 
> The document already says:
> 
>     Initial selection options and return options are defined in the
>     following subsections, and new ones will also be defined in
>     extensions.
> 
> Do you think this is not sufficient?

Right. I seem to have overlooked that sentence.

>>>    Future extensions to this
>>>    specification should keep parallelism in mind and define a pair of
>>>    corresponding options.
>>> -> So, what exactly is meant by "parallelism" here? Do you mean 
>>> "dualism" or something like that (which I actually find equally 
>>> confusing)?
> 
> I think I clarified this a bit, but expanding the description:
> 
>        In general, each selection option except RECURSIVEMATCH will have
>        a corresponding return option with the same name.  The REMOTE 
> selection option is an anomaly
>        in this regard, and does not have a corresponding return option.
>        That is because it expands, rather than restricts, the set of 
> mailboxes
>        that are returned.  Future extensions to this specification 
> should keep
>        this parallelism in mind and define a pair of corresponding
>        selection and return options.
> 

Yeah, better.

>>>    It is an error for the server to return both a \HasChildren and a
>>>    \HasNoChildren attribute in the same LIST response.
>>> -> Any recommendation for what clients should do if this does happen? 
>>> Provisionally treat it as \HasChildren?

No word on this? Do we want to avoid recommending error mitigation 
strategies in the document?

>>> section-7.4.1:
>>>
>>> -> Isn't this sub-section supposed to be in the section before? It is 
>>> about the mailbox size, not message data.
> Arguably EXPUNGE is about message status (the message is no longer 
> there). But I can go either way on this.

I don't have an opinion really. I was just worried this was wrong 
somehow. Maybe others can weigh in.

>>> section-12.1:
>>>
>>>    As this specification revises the AUTH= prefix, STARTTLS and
>>>    LOGINDISABLED extensions previously defined in [IMAP-TLS], IANA is
>>>    requested to update registry entries for these 3 extensions to point
>>>    to this document.
>>> -> This is not noted in the document header.
> 
> Can you explain what is the issue with this text? Are you talking about 
> documents listed as Updated/Obsolete?

Yes.

Regards,

Stephan.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 3 Sep 2020 09:53:20 +0100

On 02/09/2020 21:06, Stephan Bosch wrote:

>>>> -> Any recommendation for what clients should do if this does 
>>>> happen? Provisionally treat it as \HasChildren?
>

I am still thinking about this. General answer is "sometimes" :-). Cases 
about malformed email messages are the most difficult to decide.

In this particular case I think if both are present, the client needs to 
pretend that neither is set and behave accordingly.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Sep 2020 15:23:57 +0100

Hi Stephan,

> On 29/07/2020 17:55, Alexey Melnikov wrote:
  [snip]
>> Can you explain what is the issue with this text? Are you talking 
>> about documents listed as Updated/Obsolete?
>
> Yes.

Actually, I think if I drop "previously defined in [IMAP-TLS]", then no 
further changes are needed. There is no reason to "update" IMAP-TLS 
document, as it was already updated once by RFC 3501.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Sep 2020 18:31:57 +0100

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