Re: [pop3ext] UIDL response to CAPA command

Bill Shannon <bill.shannon@oracle.com> Wed, 14 November 2012 23:03 UTC

Return-Path: <bill.shannon@oracle.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 6CCE021F85D8 for <pop3ext@ietfa.amsl.com>; 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 <pop3ext@ietfa.amsl.com>; 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 <pop3ext@ietf.org>; 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 <pop3ext@ietf.org>; 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 <bill.shannon@oracle.com>
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 <chris.newman@oracle.com>
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\)" <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: 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 <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?
>