Re: [pop3ext] UIDL response to CAPA command

Randall Gellens <randy@qti.qualcomm.com> Sat, 17 November 2012 08:23 UTC

Return-Path: <randy@qti.qualcomm.com>
X-Original-To: pop3ext@ietfa.amsl.com
Delivered-To: pop3ext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA65921F8A22 for <pop3ext@ietfa.amsl.com>; Sat, 17 Nov 2012 00:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.564
X-Spam-Level:
X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGWiMr9rXmmI for <pop3ext@ietfa.amsl.com>; Sat, 17 Nov 2012 00:23:43 -0800 (PST)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id B0B2521F890F for <pop3ext@ietf.org>; Sat, 17 Nov 2012 00:23:43 -0800 (PST)
X-IronPort-AV: E=McAfee;i="5400,1158,6898"; a="7545050"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 16 Nov 2012 23:59:00 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,6898"; a="1896494"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Nov 2012 00:23:24 -0800
Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sat, 17 Nov 2012 00:23:23 -0800
Message-ID: <p06240610ccccf8b75ff1@[99.111.97.136]>
In-Reply-To: <50A7449C.9070904@oracle.com>
References: <50A409B1.9020702@oracle.com> <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100 .vpn.oracle.com> <50A42344.6080502@oracle.com> <p0624060bccccdd31ec74@[99.111.97.136]> <50A7449C.9070904@oracle.com>
X-Mailer: Eudora for Mac OS X
Date: Sat, 17 Nov 2012 00:23:21 -0800
To: Bill Shannon <bill.shannon@oracle.com>
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.39.5]
X-Mailman-Approved-At: Mon, 19 Nov 2012 04:52:36 -0800
Cc: Chris Newman <chris.newman@oracle.com>, pop3ext@ietf.org
Subject: Re: [pop3ext] UIDL response to CAPA command
X-BeenThere: pop3ext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions and updates to Post Office Protocol \(POP3\)" <pop3ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pop3ext>, <mailto:pop3ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pop3ext>
List-Post: <mailto:pop3ext@ietf.org>
List-Help: <mailto:pop3ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pop3ext>, <mailto:pop3ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Nov 2012 08:23:44 -0000

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 
>>>> <bill.shannon@oracle.com>
>>>>  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
>>>   pop3ext@ietf.org
>>>   https://www.ietf.org/mailman/listinfo/pop3ext
>>
>>
>>
>>
>
>  _______________________________________________
>  pop3ext mailing list
>  pop3ext@ietf.org
>  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