From bill.shannon@oracle.com Wed Nov 14 13:14:34 2012 Return-Path: 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 E855221F85CE for ; Wed, 14 Nov 2012 13:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Xp7PIhrBkoyW for ; Wed, 14 Nov 2012 13:14:34 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6243E21F8548 for ; Wed, 14 Nov 2012 13:14:34 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAELEQhW022957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Nov 2012 21:14:27 GMT Received: from datsunx.us.oracle.com (datsunx.us.oracle.com [10.132.180.90]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAELEPTo024927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Nov 2012 21:14:26 GMT Received: from [IPv6:::1] (localhost [IPv6:::1]) by datsunx.us.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id qAELEP1H007550; Wed, 14 Nov 2012 13:14:25 -0800 (PST) Message-ID: <50A409B1.9020702@oracle.com> Date: Wed, 14 Nov 2012 13:14:25 -0800 From: Bill Shannon User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6 MIME-Version: 1.0 To: pop3ext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:14:35 -0000 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@oracle.com Wed Nov 14 13:16:08 2012 Return-Path: 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 7017721F89BC for ; Wed, 14 Nov 2012 13:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Fo3BzS6oGpjC for ; Wed, 14 Nov 2012 13:16:07 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A4A6E21F8957 for ; Wed, 14 Nov 2012 13:16:07 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAELG5Na024497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Nov 2012 21:16:06 GMT Received: from datsunx.us.oracle.com (datsunx.us.oracle.com [10.132.180.90]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAELG3XW000907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Nov 2012 21:16:05 GMT Received: from [IPv6:::1] (localhost [IPv6:::1]) by datsunx.us.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id qAELG2bx007553; Wed, 14 Nov 2012 13:16:02 -0800 (PST) Message-ID: <50A40A12.600@oracle.com> Date: Wed, 14 Nov 2012 13:16:02 -0800 From: Bill Shannon User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6 MIME-Version: 1.0 To: pop3ext@ietf.org References: <50A409B1.9020702@oracle.com> In-Reply-To: <50A409B1.9020702@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:16:08 -0000 Oops, I meant RFC 2449. Bill Shannon wrote on 11/14/12 13:14: > 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 chris.newman@oracle.com Wed Nov 14 14:02:40 2012 Return-Path: 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 59C7A21F881B for ; Wed, 14 Nov 2012 14:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 bjkTzgru29c6 for ; Wed, 14 Nov 2012 14:02:39 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D82A521F8819 for ; Wed, 14 Nov 2012 14:02:39 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAEM2cK4001626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Nov 2012 22:02:39 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAEM2cTW028202; Wed, 14 Nov 2012 22:02:38 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-28.12(7.0.5.28.0) 64bit (built Nov 6 2012)) with ESMTPA id <0MDH0045EZWB9400@gotmail.us.oracle.com>; Wed, 14 Nov 2012 14:02:37 -0800 (PST) Date: Wed, 14 Nov 2012 14:02:34 -0800 From: Chris Newman To: Bill Shannon , pop3ext@ietf.org Message-id: <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100.vpn.oracle.com> In-reply-to: <50A409B1.9020702@oracle.com> References: <50A409B1.9020702@oracle.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:02:40 -0000 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 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? From bill.shannon@oracle.com Wed Nov 14 15:03:37 2012 Return-Path: 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 6CCE021F85D8 for ; Wed, 14 Nov 2012 15:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PcOSGPSx9M34 for ; Wed, 14 Nov 2012 15:03:36 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8758C21F8558 for ; Wed, 14 Nov 2012 15:03:36 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAEN3Zth015449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Nov 2012 23:03:35 GMT Received: from datsunx.us.oracle.com (datsunx.us.oracle.com [10.132.180.90]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAEN3YoK021996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 23:03:34 GMT Received: from [IPv6:::1] (localhost [IPv6:::1]) by datsunx.us.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id qAEN3W2v008392; Wed, 14 Nov 2012 15:03:32 -0800 (PST) Message-ID: <50A42344.6080502@oracle.com> Date: Wed, 14 Nov 2012 15:03:32 -0800 From: Bill Shannon User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6 MIME-Version: 1.0 To: Chris Newman References: <50A409B1.9020702@oracle.com> <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100.vpn.oracle.com> In-Reply-To: <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100.vpn.oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 23:03:37 -0000 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: > 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 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? > From bill.shannon@oracle.com Fri Nov 16 16:56:11 2012 Return-Path: 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 E58B821F8BA2 for ; Fri, 16 Nov 2012 16:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 Y32kwCMoMn4T for ; Fri, 16 Nov 2012 16:56:10 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34321F8B68 for ; Fri, 16 Nov 2012 16:56:10 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAH0u8xw022822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Nov 2012 00:56:09 GMT Received: from datsunx.us.oracle.com (datsunx.us.oracle.com [10.132.180.90]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAH0u7Lv020805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Nov 2012 00:56:08 GMT Received: from [IPv6:::1] (localhost [IPv6:::1]) by datsunx.us.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id qAH0u4Kt021788; Fri, 16 Nov 2012 16:56:06 -0800 (PST) Message-ID: <50A6E0A4.6030102@oracle.com> Date: Fri, 16 Nov 2012 16:56:04 -0800 From: Bill Shannon User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6 MIME-Version: 1.0 To: pop3ext@ietf.org References: <50A409B1.9020702@oracle.com> <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100.vpn.oracle.com> <50A42344.6080502@oracle.com> In-Reply-To: <50A42344.6080502@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 00:56:11 -0000 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. Bill Shannon wrote on 11/14/12 15:03: > 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: >> 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 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? >> > From rg+ietf@qti.qualcomm.com Fri Nov 16 22:41:15 2012 Return-Path: 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 ; Fri, 16 Nov 2012 22:41:15 -0800 (PST) X-Quarantine-ID: 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 ; 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 ; 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 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: 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 , Chris Newman 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> 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. From bill.shannon@oracle.com Sat Nov 17 00:02:30 2012 Return-Path: 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 3B26321F890F for ; Sat, 17 Nov 2012 00:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 o0OsnbRjqiOZ for ; Sat, 17 Nov 2012 00:02:29 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by ietfa.amsl.com (Postfix) with ESMTP id DF24421F8471 for ; Sat, 17 Nov 2012 00:02:23 -0800 (PST) Received: from brmsunmail1-central.uk.sun.com ([10.79.11.28]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id qAH82KZP009182; Sat, 17 Nov 2012 08:02:21 GMT Received: from nissan.sfbay.sun.com (dhcp-amer-vpn-adc-anyconnect-10-154-133-117.vpn.oracle.com [10.154.133.117]) by brmsunmail1-central.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id qAH82HZg009024; Sat, 17 Nov 2012 08:02:17 GMT Received: from [192.168.0.4] (vostro [192.168.0.4]) by nissan.sfbay.sun.com (8.14.4+Sun/8.14.4) with ESMTP id qAH8RBaQ005952; Sat, 17 Nov 2012 00:27:11 -0800 (PST) Message-ID: <50A7449C.9070904@oracle.com> Date: Sat, 17 Nov 2012 00:02:36 -0800 From: Bill Shannon User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Randall Gellens References: <50A409B1.9020702@oracle.com> <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100 .vpn.oracle.com> <50A42344.6080502@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Chris Newman , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 08:02:30 -0000 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: > 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 >>> 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 > > > > From randy@qti.qualcomm.com Sat Nov 17 17:20:29 2012 Return-Path: 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 ABEE421F8455 for ; Sat, 17 Nov 2012 17:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 F+45XPkV+4fy for ; Sat, 17 Nov 2012 17:20:28 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6E51C21F84A1 for ; Sat, 17 Nov 2012 17:20:25 -0800 (PST) X-IronPort-AV: E=McAfee;i="5400,1158,6899"; a="7639545" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 17 Nov 2012 17:05:12 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6899"; a="428005833" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Nov 2012 17:20:24 -0800 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 17 Nov 2012 17:20:24 -0800 Message-ID: X-Mailer: Eudora for Mac OS X Date: Sat, 17 Nov 2012 17:20:22 -0800 To: From: Randall Gellens 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] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 01:20:29 -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 >>>> >>>> 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 From bill.shannon@oracle.com Sat Nov 17 18:46:28 2012 Return-Path: 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 97E0C21F860E for ; Sat, 17 Nov 2012 18:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 MXQDXPw9kqH2 for ; Sat, 17 Nov 2012 18:46:27 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18F21F84D3 for ; Sat, 17 Nov 2012 18:46:27 -0800 (PST) Received: from brmsunmail2-central.uk.sun.com ([10.79.11.29]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id qAI2kPFt016991; Sun, 18 Nov 2012 02:46:25 GMT Received: from nissan.sfbay.sun.com (dhcp-amer-vpn-adc-anyconnect-10-154-158-73.vpn.oracle.com [10.154.158.73]) by brmsunmail2-central.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id qAI2kN5f017568; Sun, 18 Nov 2012 02:46:23 GMT Received: from [192.168.0.4] (vostro [192.168.0.4]) by nissan.sfbay.sun.com (8.14.4+Sun/8.14.4) with ESMTP id qAI2jloB004673; Sat, 17 Nov 2012 18:45:47 -0800 (PST) Message-ID: <50A84C12.1060308@oracle.com> Date: Sat, 17 Nov 2012 18:46:42 -0800 From: Bill Shannon User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Randall Gellens References: <50A409B1.9020702@oracle.com> <196CBE3CC7222C8957041F15@dhcp-amer-vpn-rmdc-anyconnect-10-159-123-100 .vpn.oracle.com> <50A42344.6080502@oracle.com> <50A7449C.9070904@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Chris Newman , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 02:46:28 -0000 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: > >> 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 >>>>> 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 > > From randy@qti.qualcomm.com Sat Nov 17 00:23:44 2012 Return-Path: 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 ; 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 ; 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 ; 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: 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> <50A7449C.9070904@oracle.com> X-Mailer: Eudora for Mac OS X Date: Sat, 17 Nov 2012 00:23:21 -0800 To: Bill Shannon From: Randall Gellens 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 , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >>>> >>>> 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