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

Dave Cridland <dave@cridland.net> Wed, 20 May 2020 07:15 UTC

Return-Path: <dave@cridland.net>
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 DF0C03A128A for <imapext@ietfa.amsl.com>; Wed, 20 May 2020 00:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
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 2QLWT8ZAOzzo for <imapext@ietfa.amsl.com>; Wed, 20 May 2020 00:15:33 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99CC3A1282 for <imapext@ietf.org>; Wed, 20 May 2020 00:15:32 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id f134so1550101wmf.1 for <imapext@ietf.org>; Wed, 20 May 2020 00:15:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WE5SUuoZ775mupcKS4fmaw2Jmgm7ChfARBlilQqL0MU=; b=OXXaHAq3L3LjCQscWnDv6AI05oAf5+JC0AjCwkfUXavZ0V4YZGqxO3MX2Fx1rRGytm me4sVz9l3w41bF+V8xarEram7IK75dCx6zKDhDz+3QZq16iOig3vsZe0yqc5GPg3wOC3 L27+OmUwYtu8yUu5YAhF08yUvReIZ4tdaBpec=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WE5SUuoZ775mupcKS4fmaw2Jmgm7ChfARBlilQqL0MU=; b=PIuPns4uahRZ2PDIcfpOudTNDLUOVm6/usZfBPDVQRjIzxJV6jjI4ViWY9LiLgqA0m tUDW5s6Kky5a0g7Qx2liL0Z8+uajwYzBJFtnHkT5dpmpNJOqHAjyJtFCK5yRkHzDu2yI lGSmpJZ0XtE48Q09KoV53si7c+5VY6M5SlNQmoVG6tI1EMiCwEgU2cDIASIkwneVi+ut zMGW6OA7eAnrGl2j98Rz6P/Bf7EOInj6A5qD7HkezUjMzE7kJWcQhu/QHg6UjRQn3YYy rJtl+lvVR5u3RBVu6o0HUwvGLCunj8zAK8iLr50TtJQ8pogmWqe2AVrz6gd7jNnh5r91 99cw==
X-Gm-Message-State: AOAM532R7tdntONfwNn6hgebqm2a2dW3nDNkY79dGXAQHlgGNgWTziKT zxGE1p3+jULHGrK/woBQKcsdjBe4jEqrkfe4zkLJaF0g
X-Google-Smtp-Source: ABdhPJxJKHse8eKjB73H9oPL1jywq4tQwQh53S7L7fd07+HctrJegtk3xtwgGsg7Tshg2mS6ORwrh7xQdRvHawkJroY=
X-Received: by 2002:a1c:5985:: with SMTP id n127mr3110479wmb.64.1589958930811; Wed, 20 May 2020 00:15:30 -0700 (PDT)
MIME-Version: 1.0
References: <4c6ed7902d8a21b14f59864881096f44f6b3bd24.camel@aegee.org> <d3c1e1ba-9917-c7b0-085b-a658a5f36615@isode.com>
In-Reply-To: <d3c1e1ba-9917-c7b0-085b-a658a5f36615@isode.com>
From: Dave Cridland <dave@cridland.net>
Date: Wed, 20 May 2020 08:15:20 +0100
Message-ID: <CAKHUCzyn+SLVe0SERXQURBF0K_5WpBaRt6kXxqmnJOTswGXQ3A@mail.gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: Дилян Палаузов <dilyan.palauzov@aegee.org>, imapext@ietf.org
Content-Type: multipart/alternative; boundary="000000000000475b5a05a60f2922"
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/9Yfxt1t7iG1waiX9pzVL_cLbajQ>
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: Wed, 20 May 2020 07:15:35 -0000

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 athttps://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 listimapext@ietf.orghttps://www.ietf.org/mailman/listinfo/imapext
>
>