Re: [Extra] draft-ietf-extra-imap4rev2-04 review

["Chris Newman" <[e-mail]>]

On 25 Mar 2019, at 13:04, Timo Sirainen wrote:
>> 3.4.  Logout State
>>
>
>>    A server MUST NOT unilaterally close the connection without 
>> sending
>>    an untagged BYE response that contains the reason for having done 
>> so.
>
> Also already in RFC 3501, but this MUST NOT has to be violated 
> sometimes. For example otherwise it would allow client to FETCH a 
> large message and keep reading it very very slowly over days, and 
> server wouldn't be allowed to disconnect it, because it can't send BYE 
> in the middle of the large mail literal.

Another example is if a client gets hung up (or goes silently offline) 
during a TLS negotiation. The server has to eventually timeout the 
connection but it would be semantically wrong to send a "* BYE" since 
there's no data channel. One case where this happened was when our SSL 
stack dropped support for an SSLv2-compatible hello (allowed by RFC 
6176), but some very old client kept sending such a hello (prohibited by 
RFC 6176). Incidentally, SSLv2 is completely incompatible with SSLv3 so 
the client sends something that's not sufficient to complete an SSLv3 
packet so both ends get stuck waiting until one side hangs up.

>> 5.1.  Mailbox Naming
>
>> servers MAY accept a de-normalized UTF-8 mailbox name and convert it 
>> to Net-Unicode prior to mailbox creation).
> and:
>> Some server implementations
>>    are fully case-sensitive in ASCII range; others preserve case of a
>>    newly-created name but otherwise are case-insensitive; and yet 
>> others
>>    coerce names to a particular case.
>
> This seems rather difficult from client's point of view. It CREATEs a 
> mailbox, but the client can't find it anymore because it changed. 
> Seems to me it would be less strange if the server simply failed the 
> CREATE entirely.

I had mistakenly thought this as well until I encountered the real-world 
situation. There are widely deployed mail clients that do not normalize 
Unicode when sending it to the server for mailbox names and also behave 
very badly from a UI perspective if CREATE fails. I tried an 
implementation which rejected CREATE when the client used a name in 
violation of 5198 and a customer insisted I provide a way to allow 
invalid names.

> If this is allowed for CREATE, is such conversion done for 
> SELECT/EXAMINE/APPEND as well?

I doubt this is necessary in practice. Most clients will take what they 
get from LIST responses and use that. Clients also have to deal well 
with SELECT/EXAMINE/APPEND failures because of reality.

> What about LIST "" <non-normalized name> - would it return the 
> normalized name?

I doubt most clients use that form of list, so I wouldn't implement that 
unless necessary.

		- Chris