Subject: [pop3ext] UIDL response to CAPA command

From: Bill Shannon <[email-masked]>
Date: Wed, 14 Nov 2012 13:14:25 -0800

Does RFC 2994 allow the UIDL capability to be missing from a CAPA
response before authentication, but included in a CAPA response
after authentication?

Thanks.

---

From: Bill Shannon <[email-masked]>
Date: Wed, 14 Nov 2012 13:16:02 -0800

Oops, I meant RFC 2449.

---

From: Chris Newman <[email-masked]>
Date: Wed, 14 Nov 2012 14:02:34 -0800

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

---

From: Bill Shannon <[email-masked]>
Date: Wed, 14 Nov 2012 15:03:32 -0800

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.

It's that ambiguity that caused me to ask, just to be sure...

Chris Newman wrote on 11/14/12 14:02:
> 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 <[email-masked]> wrote:

---

From: Bill Shannon <[email-masked]>
Date: Fri, 16 Nov 2012 16:56:04 -0800

I haven't heard from anyone else so I'm assuming the consensus opinion
is that the UIDL capability can't change based on authentication.

Thanks.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 16 Nov 2012 22:36:32 -0800

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

>  _______________________________________________
>  pop3ext mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/pop3ext

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Things will be bright in P.M.  A cop will shine a light in your face.

---

From: Bill Shannon <[email-masked]>
Date: Sat, 17 Nov 2012 00:02:36 -0800

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

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.

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?

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.

UIDL has no arguments, so all the rules about arguments don't apply.

Are there other rules in the spec that I'm missing?

Randall Gellens wrote on 11/16/2012 10:36 PM:
> 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
> 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).
> 
> 
> 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.
> 
> 
>>

---

From: Bill Shannon <[email-masked]>
Date: Sat, 17 Nov 2012 18:46:42 -0800

Thanks, Randall, now it's clear.

I guess I was reading "Announced states" / "both" as it *may* be
announced in both states, not it *must* be announced in both states.
Especially since the text seems to have explicit rules for lots of
other cases, but not for this case.

Randall Gellens wrote on 11/17/2012 12:23 AM:
> Hi Bill,
> 
> At 12:02 AM -0800 11/17/12, Bill Shannon wrote:
> 
> My apologies.  I agree with Chris.  Sorry for not being clear.
> 
>>
> The capability description indicates in which states the capability is announced.
> 
>>
> No.  The description for it says it is announced in both states.
> 
>>
>>  The spec says:
>>
> The UIDL capability is announced in both states.  The UIDL command is only
> available in TRANSACTION state.
> 
>>
> Let me know if what I've said is unclear or ambiguous.
> 
>>
>>

---

From: Randall Gellens <[email-masked]>
Date: Sat, 17 Nov 2012 00:23:21 -0800

Hi Bill,

>  What I don't understand is what the rules are for capabilities that

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

>  state, so the above doesn't apply.

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

-------------- Randomly selected tag: ---------------
The irony of the Information Age is that it has given new
respectability to uninformed opinion.       --John Lawton