Re: [pop3ext] UIDL response to CAPA command

[Randall Gellens <[e-mail]>]

Hi Bill,

At 12:02 AM -0800 11/17/12, Bill Shannon wrote:

>  Sorry, I couldn't tell if you were agreeing with Chris or not.

My apologies.  I agree with Chris.  Sorry for not being clear.

>
>  I understand how it works for capabilities that have parameters.
>
>  What I don't understand is what the rules are for capabilities that
>  don't have parameters.

The capability description indicates in which states the capability 
is announced.

>
>  Let's try the simple yes or no question...
>
>  Does RFC 2449 allow the UIDL capability to be missing from a CAPA
>  response before authentication, but included in a CAPA response
>  after authentication?

No.  The description for it says it is announced in both states.

>
>  The spec says:
>
>     Capabilities available in the AUTHORIZATION state MUST be announced
>     in both states.
>
>  UIDL is not available in the AUTHORIZATION state, only the TRANSACTION
>  state, so the above doesn't apply.

The UIDL capability is announced in both states.  The UIDL command is 
only available in TRANSACTION state.

>
>  UIDL has no arguments, so all the rules about arguments don't apply.
>
>  Are there other rules in the spec that I'm missing?

Let me know if what I've said is unclear or ambiguous.

>
>
>  Randall Gellens wrote on 11/16/2012 10:36 PM:
>>  At 3:03 PM -0800 11/14/12, Bill Shannon wrote:
>>
>>>   Well, that was my initial reading as well, and I'd be happy with that
>>>   interpretation, but the spec says:
>>>
>>>      If a capability is announced in both states, but the argument might
>>>      differ after authentication, this possibility MUST be stated in the
>>>      capability description.
>>>
>>>      (These requirements allow a client to issue only one CAPA command if
>>>      it does not use any TRANSACTION-only capabilities, or any
>>>      capabilities whose values may differ after authentication.)
>>>
>>>   Note that it talks about "arguments" or "values", not about whether
>>>   the capability itself might be present or not.
>>
>>  The wording about arguments and values applies to those 
>> capabilities that are
>>  announced in both states.   The text is saying that the client has 
>> to be able to
>>  know if a capability that it wants to use might only be announced after
>>  authenticating, or if it is announced before authenticating, if it 
>> might have
>>  different parameters after authenticating.  If so, it needs to 
>> issue a second
>>  CAPA after authenticating, but if not, it can perhaps save a round-trip and
>>  pipeline other commands right after authenticating.
>>
>>  A quick check of the IANA registry at
>> 
>> http://www.iana.org/assignments/pop3-extension-mechanism/pop3-extension-mechanism.xml
>>  shows only two capabilities whose parameters may differ: 
>> LOGIN-DELAY and EXPIRE
>>  (which makes sense since these express server policy that may very 
>> well differ
>>  per user).  I don't see any capabilities listed that are only announced in
>>  TRANSACTION state, although IMPLEMENTATION is allowed to be (but 
>> of course no
>>  client behavior is affected).
>>
>>
>>>   It's that ambiguity that caused me to ask, just to be sure...
>>
>>  Sorry if the wording seemed ambiguous.  The intent is to group together for
>>  special notice two kinds of capabilities: those that are only announced in
>>  TRANSACTION state and those that are announced in both AUTHENTICATION and
>>  TRANSACTION but whose parameters may differ between the states.
>>
>>
>>>
>>>   Chris Newman wrote on 11/14/12 14:02:
>>>>   Section 6.8 says:
>>>>
>>>>   Announced states / possible differences:
>>>>   both / no
>>>>
>>>>   So it looks like you're not allowed by RFC 2994's CAPA 
>>>> registration for UIDL
>>>>   advertisement to change after authentication.
>>>>
>>>>           - Chris
>>>>
>>>>   --On November 14, 2012 13:14:25 -0800 Bill Shannon 
>>>> <[e-mail]>
>>>>  wrote:
>>>>>   Does RFC 2994 allow the UIDL capability to be missing from a CAPA
>>>>>   response before authentication, but included in a CAPA response
>>>>>   after authentication?
>   >>>
>>>
>>>   _______________________________________________
>>>   pop3ext mailing list
>>>   [e-mail]
>>>   https://www.ietf.org/mailman/listinfo/pop3ext
>>
>>
>>
>>
>
>  _______________________________________________
>  pop3ext mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/pop3ext


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The irony of the Information Age is that it has given new
respectability to uninformed opinion.       --John Lawton