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

[Randall Gellens <[e-mail]>]

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.

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.

-- 
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