Re: [pop3ext] UIDL response to CAPA command

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

Return-Path: <rg+ietf@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 C00FA21F869B for <pop3ext@ietfa.amsl.com>; Fri, 16 Nov 2012 22:41:15 -0800 (PST)
X-Quarantine-ID: <wn1C1uK5zJGm>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -101.599
X-Spam-Level:
X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 wn1C1uK5zJGm for <pop3ext@ietfa.amsl.com>; Fri, 16 Nov 2012 22:41:14 -0800 (PST)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id CE64121F866D for <pop3ext@ietf.org>; Fri, 16 Nov 2012 22:41:14 -0800 (PST)
X-IronPort-AV: E=McAfee;i="5400,1158,6898"; a="7540718"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 16 Nov 2012 22:16:48 -0800
From: Randall Gellens <randy@qti.qualcomm.com>
X-IronPort-AV: E=McAfee;i="5400,1158,6898"; a="368445304"
Received: from myvpn-l-1025.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.132.1]) by Ironmsg03-L.qualcomm.com with ESMTP; 16 Nov 2012 22:41:09 -0800
Mime-Version: 1.0
Message-Id: <p0624060bccccdd31ec74@[99.111.97.136]>
In-Reply-To: <50A42344.6080502@oracle.com>
References: <50A409B1.9020702@oracle.com> <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100 .vpn.oracle.com> <50A42344.6080502@oracle.com>
X-Mailer: Eudora for Mac OS X
Date: Fri, 16 Nov 2012 22:36:32 -0800
To: Bill Shannon <bill.shannon@oracle.com>, Chris Newman <chris.newman@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Cc: 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 06:41:15 -0000

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




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