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.
- [pop3ext] UIDL response to CAPA command Bill Shannon
- Re: [pop3ext] UIDL response to CAPA command Bill Shannon
- Re: [pop3ext] UIDL response to CAPA command Chris Newman
- Re: [pop3ext] UIDL response to CAPA command Bill Shannon
- Re: [pop3ext] UIDL response to CAPA command Bill Shannon
- Re: [pop3ext] UIDL response to CAPA command Randall Gellens
- Re: [pop3ext] UIDL response to CAPA command Bill Shannon
- Re: [pop3ext] UIDL response to CAPA command Randall Gellens
- Re: [pop3ext] UIDL response to CAPA command Bill Shannon
- Re: [pop3ext] UIDL response to CAPA command Randall Gellens