Re: [EAI] Regarding EAI-POP-05, UTF8 tag

[Joseph Yee <[e-mail]>]

On 23-Jun-09, at 6:32 PM, Randall Gellens wrote:

> At 4:05 PM -0400 6/15/09, Joseph Yee wrote:
>
>> Hi all,
>>
>> I re-read the latest version of eai-pop (05) and I think there were  
>> some should be deleted text from decision of changing to single  
>> mode-switch.
>>
>>
>> Section 3 UTF8 Capability
>> - current arguments have "USER, LIST, TOP"
>>
>> Since UTF8 is designed to use at authorization state only, LIST and  
>> TOP should remove from arguments.
>>
>> Suggested arguments list:
>>
>> Arguments:
>>   none, USER, APOP
>
> In the description of a new POP capability, "arguments" means  
> arguments that may appear following the CAPA tag (in the CAPA  
> response), not parameters of the command.  This can be confusing and  
> should be clarified in an update to RFC 2449.

Thanks for the clarification.

>
> So the text in -05 means that a UTF8 capable POP server includes in  
> its CAPA response the string "UTF8" optionally followed by any or  
> all of "USER", "LIST", and "TOP".  However, the -05 text only  
> describes what "USER" means (which is that the POP server permits  
> UTF8 in authentication and authorization text and applies SASLprep).
>
> The document does not say what it means if "LIST" or "TOP" are  
> included, and to be honest, I'm not sure I remember why these were  
> included.  There is some text in -05 that discusses the accuracy of  
> the size of a message as reported in LIST, so my guess is that the  
> intent is that if the server knows that it returns accurate sizes in  
> LIST, it includes LIST in the UTF8 CAPA response.  My guess that if  
> the server supports TOP and also is capable of handling downgrades  
> during TOP, it includes TOP in the UTF8 CAPA response.  However,  
> since POP servers don't up-convert, a client that issues UTF8  
> wouldn't see any difference between a server that included TOP or  
> LIST and one that didn't.  Only clients that don't issue UTF8 would  
> see a difference, because the differences only affects down- 
> converted messages.  Therefore, the only clients that could see a  
> difference won't see it, because any client that knows what "UTF8"  
> in the CAPA response means probably supports UTF8 and will issue the  
> UTF8 command, and so won't see any difference.  Older clients that  
> don't know about UTF8 and don't issue the UTF8 command would see a  
> difference but not know about it.  So, these two arguments are  
> useless and will be deleted from -06.
>
> Thanks for noticing this and bringing it up.

:)

>
>> I don't know how it should present both empty and non-empty  
>> arguments in RFC.  I'm suggesting that single command UTF8 (without  
>> any argument followed) could switch mode before authentication,  
>> hence I include "none" as possible argument.
>>
>> For "none" scenario:
>> S: +OK POP3 server ready
>> C: UTF8
>> S: +OK UTF8 POP3 enabled
>> C: USER non-ascii-address
>> S: +OK hello non-ascii-address
>> C: PASS password
>> .....
>>
>> I'm also thinking that "UTF8 must have argument followed" is fine  
>> too, but my personal thought is that if so, it applies to USER and  
>> APOP only.
>
> The UTF8 command does not have any parameters.  The client issues  
> "UTF8" and that's it.

Sounds good, I personally prefer this too.

Regards,
Joseph

>
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself  
> only
> -------------- Randomly selected tag: ---------------
> Television is simply automated day-dreaming.
>      --Lee Lovinger, _Quote_, July 30, 1967