Re: [EAI] AD review of draft-ietf-eai-pop-06

[Alexey Melnikov <[e-mail]>]

After further discussion of this document with Kurt Zeilenga:

Alexey Melnikov wrote:

>> 3.2. USER Argument to UTF8 Capability
>>
>>    If the USER argument is included with this capability, it indicates
>>    that the server accepts UTF-8 user names and passwords and applies
>>    SASLprep [RFC4013] to the arguments of the AUTH, USER, PASS and APOP
>>    commands.  A client that supports APOP and permits UTF-8 in user
>>    names or passwords MUST also implement SASLprep [RFC4013] on the user
>>    name and password used to compute the APOP digest.
>
> I think the last sentence should read:
>
>  A client that supports APOP and permits UTF-8 in user
>   names or passwords MUST apply SASLprep [RFC4013] to the user
>   name and password used to compute the APOP digest.
>
> Also, the document is missing a statement about what should be done 
> about Unicode characters disallowed by SASLPrep.
> So, I would recommend adding the following sentence:
>
>   The server MUST reject UTF-8 user names/password which fails to comply
>   with the formal syntax in RFC 3629 [RFC3629] or if it encounters a 
> Unicode
>   characters listed in section 2.3 of RFC 4013 [RFC4013].

Kurt said that SASLPrep is a MUST for both clients and servers 
implementing APOP. For USER/PASS, he suggested that SASLPrep is a SHOULD 
on the server side only (this matches SASL PLAIN mechanism).

>>    The client does not need to issue the UTF8 command prior to using
>>    UTF8 in authentication.  However, clients MUST NOT use UTF8 in USER,
>>    PASS, or APOP commands unless the USER argument is included with the
>>    UTF8 capability.
>>
>>    Use of UTF8 in the AUTH command is governed by the SASL mechanism.
>
> Should this have an Informative reference to RFC 4422?
>
> As a side note: UTF-8 was always allowed in AUTH command, as support 
> for it is required by SASL.

Please delete any references to UTF8 updating how AUTH command behave 
(this affects both sections 3 and 3.2). Each SASL mechanism describes 
how username and passwords (if any) are encoded, so the current text in 
EAI-POP3 can be read as conflicting with this.