IETF Logo Mail Archive

Re: [imapext] IMAP Capability Registry and RFC 5524: URLFETCH=BINARY vs URLAUTH=BINARY

Дилян Палаузов <dilyan.palauzov@aegee.org> Thu, 21 May 2020 08:04 UTC

Return-Path: <dilyan.palauzov@aegee.org>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0707D3A0AC5 for <imapext@ietfa.amsl.com>; Thu, 21 May 2020 01:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI4VBzewDAcp for <imapext@ietfa.amsl.com>; Thu, 21 May 2020 01:04:45 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43C63A0AC2 for <imapext@ietf.org>; Thu, 21 May 2020 01:04:43 -0700 (PDT)
Authentication-Results: mail.aegee.org/04L84baa1566229; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1590048278; i=dkim+MSA-tls@aegee.org; bh=rKdY8dzUfC65YQ2DWibVoSQR1D48ufWJrxuhhPT6WJo=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=Higf+SSdoqtgvaRwIEgUOvIsAeFmmX5BNW8s83HvYjp6R9ilSjaxmfIsfWbPOcooZ IJoSzdHJSIGuPeFMsTHX5tFzIasnS/6s5CqXaZa6dmdrSnn57WHlTLkwmQkUoAAkf+ l5pYHpeCbT0qRNB7yKBvSuxzHqk3AwC2TZcFfABYT0PfV6gNNahshWQ/Bib1iZxZ5R DeUThUJPIWFAfp/w4MAZYh/wqvPhy+jCw9HZj7ktxLBNRwg5IFXyZpioACBSiE7nyL Zjr8vS4impLMjZK65NlEhuoBcme7yFhEMTquIJjKwEN4VSOGbDBvLT1rUylVe/s6BN cNwWBgeaJU99uVJK0BNjQuFkl5WTxL90rJgeQyM5FQ4yXcRRHCjkqp32VZ5BTyFkHa uNSe6LJNMKG0ihR2TPf0r6uyAzof748cnTXWvG53R+GsUs+I1zJSQQqxxhwi/uRdeW IeJHg1zO6Rs2EHDjwzjiZoGIQS+M+ObL4CeeOx/m8W4L0g5/qvGWIdPFQs595Em3M3 c5RzbREPJSKZYhERs/OT6owFFgnyYVHBJ/BBnYFZx1SzqqQEVER2Zras6ZzQ0VowXc l8VcmwLhFNw694cL6U4bnIjYdysgvDnqz0uE56EKAgqz4ZbJs1hRtY2G9gX2EaYXEq k5/CG3B5JR7/Fbf1rOCphhOQ=
Authentication-Results: mail.aegee.org/04L84baa1566229; dkim=none
Received: from Tylan (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 04L84baa1566229 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 May 2020 08:04:37 GMT
Message-ID: <acf1fdf65f54d8bb780ca7f5f4a0965263e96921.camel@aegee.org>
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
To: Dave Cridland <dave@cridland.net>, Alexey Melnikov <alexey.melnikov@isode.com>
Cc: imapext@ietf.org
Date: Thu, 21 May 2020 08:04:36 +0000
In-Reply-To: <CAKHUCzyn+SLVe0SERXQURBF0K_5WpBaRt6kXxqmnJOTswGXQ3A@mail.gmail.com>
References: <4c6ed7902d8a21b14f59864881096f44f6b3bd24.camel@aegee.org> <d3c1e1ba-9917-c7b0-085b-a658a5f36615@isode.com> <CAKHUCzyn+SLVe0SERXQURBF0K_5WpBaRt6kXxqmnJOTswGXQ3A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.37.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.3 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/CkPnYFErS_LZ1tabOxFsTdOM9XY>
Subject: Re: [imapext] IMAP Capability Registry and RFC 5524: URLFETCH=BINARY vs URLAUTH=BINARY
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2020 08:04:47 -0000

Hello,

how shall the IANA IMAP Capabilities registry look like

-- SO --

URLAUTH=BINARY 	[RFC5524]

-- OR SO --

URLAUTH=BINARY 	[RFC5524]
URLFETCH=BINARY INVALID - RFC 5524 has introduced the URLAUTH=BINARY
capability, but accidentially inserted URLFETCH=BINARY in the IANA
registry.

Regards
  Дилян

On Wed, 2020-05-20 at 08:15 +0100, Dave Cridland wrote:
> Oh.
> It looks like I made a mistake in the IANA section, that was subtle
> enough never to be noticed by any of the reviewers or the editors, or
> indeed IANA. That was clever of me, wasn't it?
> 
> Given that the specification refers only to URLAUTH in defining the
> behaviour of the server, I think the IANA section is solely at fault,
> such means I have managed to get an errata into the registry.
> 
> Do I get a prize? Or a lifetime ban from writing any more RFCs?
> 
> Dave.
> 
> On Tue, 19 May 2020, 16:49 Alexey Melnikov,
> <alexey.melnikov@isode.com> wrote:
> >  
> >  Hi Дилян,
> >  On 17/05/2020 15:55, Дилян Палаузов wrote:
> >  
> >  
> > >  
> > > Hello,
> > > 
> > > The Internet Message Access Protocol (IMAP) Capabilities Registry
> > > at
> > > https://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml
> > > says:
> > > 
> > > URLFETCH=BINARY 	[RFC5524]
> > > 
> > > and RFC 5524, https://tools.ietf.org/html/rfc5524 says:
> > > 
> > > 
> > > 3.  Extended URLFETCH
> > > 
> > >    This extension is available in any IMAP server implementation
> > > that
> > >    includes URLAUTH=BINARY within its capability string.
> > > 
> > > 5. Formal Syntax
> > > 
> > >    capability       =/ "URLAUTH=BINARY"
> > > 
> > > 6.  IANA Considerations
> > > 
> > >    This document defines the URLFETCH=BINARY IMAP capability. 
> > > IANA has
> > >    added it to the registry accordingly.
> > > 
> > > My reading is, that the URLAUTH=BINARY and URLFETCH=BINARY
> > > capabilities
> > > mean the same.
> > >  
> >  I think one of these is a typo. I suspect "URLFETCH=BINARY" should
> > be "URLAUTH=BINARY", because "URLAUTH" is already registered as a
> > Capability. Dave? 
> > >  
> > > Please comment within a month on the following proposal for
> > > erratum:
> > > 
> > > New text:
> > > 
> > > 3.  Extended URLFETCH
> > > 
> > >    This extension is available in any IMAP server implementation
> > > that
> > >    includes URLAUTH=BINARY or URLFETCH=BINARY within its
> > > capability
> > >    string.
> > > 
> > > 5.  Formal Syntax
> > > 
> > >  capability       =/ "URLAUTH=BINARY" / "URLFETCH=BINARY"
> > > 
> > >       ; Command parameters; see Section 3.1
> > > 
> > > 6.  IANA Considerations
> > > 
> > >    This document defines the URLFETCH=BINARY and the
> > > URLAUTH=BINARY
> > > IMAP capabilities.  Both capabilities mean the same. IANA has
> > > added 
> > > URLFETCH=BINARY and will add URLAUTH=BINARY to the registry 
> > > accordingly.
> > >  
> >  If it is a typo, I would edit your suggestion to recommend one or
> > another, not both.
> >  Best Regards,
> >  Alexey
> >  
> >  
> > >  
> > > I do not insist to do the wording, anybody can take this over.
> > > 
> > > If there is knowledge, that all implementations have consolidated
> > > on a
> > > single capability wording, then the erratum can get smaller.
> > > 
> > > Greetings
> > >   Дилян
> > > 
> > > _______________________________________________
> > > imapext mailing list
> > > imapext@ietf.org
> > > https://www.ietf.org/mailman/listinfo/imapext
> > >  
> >  
> _______________________________________________
> imapext mailing list
> imapext@ietf.org
> https://www.ietf.org/mailman/listinfo/imapext

v2.23.0 | Report a Bug | By Email