From nobody Sun Feb 25 08:17:06 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C476F12025C for ; Sun, 25 Feb 2018 08:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 CJ4cZiLhI4VP for ; Sun, 25 Feb 2018 08:17:03 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68931201FA for ; Sun, 25 Feb 2018 08:17:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 11CA8B80C6A; Sun, 25 Feb 2018 08:16:55 -0800 (PST) To: barryleiba@computer.org, nicolson@google.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, rg+ietf@qualcomm.com, barryleiba@computer.org, tss@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: rag@ragged-software.com, morg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180225161655.11CA8B80C6A@rfc-editor.org> Date: Sun, 25 Feb 2018 08:16:55 -0800 (PST) Archived-At: Subject: [MORG] [Technical Errata Reported] RFC6154 (5265) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 16:17:05 -0000 The following errata report has been submitted for RFC6154, "IMAP LIST Extension for Special-Use Mailboxes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5265 -------------------------------------- Type: Technical Reported by: Roy A. Gilmore Section: GLOBAL Original Text ------------- Corrected Text -------------- Notes ----- In RFC6154, the special-use attributes are consistently shown with initial capitals, but there doesn't appear to be any guidance whether the special-use attributes are case-sensitive, case-insensitive, or implementation defined. This could lead to interoperability issues. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6154 (draft-ietf-morg-list-specialuse-06) -------------------------------------- Title : IMAP LIST Extension for Special-Use Mailboxes Publication Date : March 2011 Author(s) : B. Leiba, J. Nicolson Category : PROPOSED STANDARD Source : Message Organization Area : Applications Stream : IETF Verifying Party : IESG From nobody Sun Feb 25 12:03:46 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3186812711E for ; Sun, 25 Feb 2018 12:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eDPoJDQvRLrt for ; Sun, 25 Feb 2018 12:03:42 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 493BE126C2F for ; Sun, 25 Feb 2018 12:03:42 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id u84so453318ywg.9 for ; Sun, 25 Feb 2018 12:03:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=zqJgvuhxP1mVgKUQ42fCxIqXLiCw2BgLR0RGIQXCVaU=; b=aJVIa+OnvCe4dTQrJOTlevg8rdDNKLtJl1hh2Mh+5d5M0s2DyrIj9gK2ICEF+k1tb4 Oi1pKEWuq+tdwBrEqnOhW17kQ3rcQN5ONyRZXXSivpsEGGKrd3Pi4TPFDMZLLo46Mr3Q qNraD5N2j2cLPNnXgTxrZSBs0vEKd4RKC382ODxvvx5Mszi1Df/5P+NGlGCylkcn8SaC hbax++NrBrxkymgSWUi68bWoMM+5FGXixAlbHT/mxmCCK2VwQkOWFYXrohKFfwPcE4Kp 2MIb33GmcoruKQTIyOyGkHcIWvffnt7JP4OqCuEvXUSJwY9rQFsVK7V5AsV5KKK5bMab bVQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=zqJgvuhxP1mVgKUQ42fCxIqXLiCw2BgLR0RGIQXCVaU=; b=tUTAPCRDZcpaNNnCBoPr8i2BdDoWRyCceUfYhQLwTu7rMLwanCCqMw+Jy+oo38+ePC qxU/QVmstbDpcqBX2QpZ4kqU5j+ojVXv4qzBJix/tlk7y5rQGUaIbWWVmYI4LofbUTnY Q9g06HQMLHJ8DK1TtM9J2DQlSdFadHMc/2al5RZNk0LbIAiU+ckDBwv1DR9hzkB+j5xE drJZbgWp+PEHZ7VTQjRUXQc3HghaCC6zCqVazcBAhQc5kPWCdrFkMwAmXNFUyTHqpNPw o4JcxYoTVfW2QX4M1gAZDWl3iX+G4E1aYts7sh1TGjCW/HswbIamSlRVwqq98MtUH/8y tNTg== X-Gm-Message-State: APf1xPBnP64RrVvxP5K06+9OKEsxP8CxIsqWJ14opbZPr9glBR/WqCzU YmV8L4HYkIbndZzgU9FCCUCHzzsFu2QVHEvooj4= X-Google-Smtp-Source: AG47ELtXKoihH7fNcxgiZLGpSPn0m0LpLfSlzVVFf2mEQZD7paHV3H+kK5OUxAKZOS6vpUIDQs9cezbsQ4BoeUzegjE= X-Received: by 10.129.68.18 with SMTP id r18mr5268557ywa.184.1519589021282; Sun, 25 Feb 2018 12:03:41 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:a25:b7cb:0:0:0:0:0 with HTTP; Sun, 25 Feb 2018 12:03:40 -0800 (PST) In-Reply-To: <20180225161655.11CA8B80C6A@rfc-editor.org> References: <20180225161655.11CA8B80C6A@rfc-editor.org> From: Barry Leiba Date: Sun, 25 Feb 2018 12:03:40 -0800 X-Google-Sender-Auth: 83PEmCjDK4IUeGCgkbHSuNncFrA Message-ID: To: RFC Errata System Cc: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= , Ben Campbell , Alexey Melnikov , Adam Roach , Randall Gellens , Timo Sirainen , rag@ragged-software.com, morg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 20:03:44 -0000 Roy, thanks for taking the time to make this report. As this is an IMAP extension, it inherits such aspects from IMAP, RFC 3501. The beginning of RFC 3501 Section 9 says this: Note: [ABNF] rules MUST be followed strictly; in particular: (1) Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. The notations here such as "\Archive" match the related non-extended notations in RFC 3501 such as "\Noselect", all done for the same editorial style and all subject to that note in RFC 3501. Alexey, I suggest marking this report as "rejected". That said, while this doesn't represent an error or omission in the spec, it certainly wouldn't have hurt to have been explicit about this. So I also suggest that any work the Extra working group does related to IMAP takes an extra sentence here or there to be clear that the items it defines are case-insensitive, and that the case shown in the text is merely an editorial choice (perhaps just by explicitly saying "See the ABNF notes at the beginning of RFC 3501 Section 9."). Barry On Sun, Feb 25, 2018 at 8:16 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC6154, > "IMAP LIST Extension for Special-Use Mailboxes". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5265 > > -------------------------------------- > Type: Technical > Reported by: Roy A. Gilmore > > Section: GLOBAL > > Original Text > ------------- > > > Corrected Text > -------------- > > > Notes > ----- > In RFC6154, the special-use attributes are consistently shown with initia= l capitals, but there doesn't appear to be any guidance whether the special= -use attributes are case-sensitive, case-insensitive, or implementation def= ined. This could lead to interoperability issues. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6154 (draft-ietf-morg-list-specialuse-06) > -------------------------------------- > Title : IMAP LIST Extension for Special-Use Mailboxes > Publication Date : March 2011 > Author(s) : B. Leiba, J. Nicolson > Category : PROPOSED STANDARD > Source : Message Organization > Area : Applications > Stream : IETF > Verifying Party : IESG --=20 Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From nobody Sun Feb 25 21:19:07 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC668129C51 for ; Sun, 25 Feb 2018 21:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ragged-software.com 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 FvW_Ol-C2K46 for ; Sun, 25 Feb 2018 21:19:03 -0800 (PST) Received: from jax4mhob25.registeredsite.com (jax4mhob25.registeredsite.com [64.69.218.113]) (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 01A70128C0A for ; Sun, 25 Feb 2018 21:19:02 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by jax4mhob25.registeredsite.com (8.14.4/8.14.4) with ESMTP id w1Q5Ivq4029478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Feb 2018 00:18:57 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 jax4mhob25.registeredsite.com w1Q5Ivq4029478 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ragged-software.com; s=default; t=1519622339; bh=8P2BjP9+kBr5CTI1bxml3H/rboh8oCWyj3scpmHmGAI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cHwNAnO/wNZwro3VbHnHeaMtUSj/KH3aN7nnebnMWYGBvbwfpzfE5Ga5dQrszMOdS 1jtVgWVOf58n0EQG+cNXSJ6aDGj8wnHc+yAthbkCrfKsJ+e5midmBKuhOgPWXyrg5P 5UMdiUQp4DuygHDmEDcAgpIEIx6ZiqKV4cbkyJy0= Received: (qmail 31460 invoked by uid 0); 26 Feb 2018 05:18:57 -0000 X-TCPREMOTEIP: 108.254.82.121 X-Authenticated-UID: rag@ragged-software.com Received: from unknown (HELO thor.internal.ragged-software.com) (rag@ragged-software.com@108.254.82.121) by 0 with ESMTPA; 26 Feb 2018 05:18:57 -0000 To: Barry Leiba , RFC Errata System Cc: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= , Ben Campbell , Alexey Melnikov , Adam Roach , Randall Gellens , Timo Sirainen , morg References: <20180225161655.11CA8B80C6A@rfc-editor.org> From: "Roy A. Gilmore" Organization: RAGged Software Message-ID: Date: Sun, 25 Feb 2018 21:18:10 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AA10C25EE3C8234BE7BFE0A4" Content-Language: en-US Archived-At: Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 05:19:06 -0000 This is a multi-part message in MIME format. --------------AA10C25EE3C8234BE7BFE0A4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Barry, Thank you for clarifying this behavior. Upon reflecting on your rationale, I agree with your recommendation of "rejected", if for no other reason than because I had not claimed that were actually any errors or omissions in the specification, and I simply wanted clarification of a specific behavior that was not addressed within the specification itself (even though it *is* addressed in the referenced RFC 3501). In hindsight, carefully re-reading both RFC 6154 Section 6, specifically: mbx-list-oflag =/  use-attr ; Extends "mbx-list-oflag" from IMAP base [RFC3501] and RFC 3501 Section 9, would have answered my question. I wish I had been more thorough in my research. In my defense, sometimes the answer to a trivial question is buried under many layers of chained referenced specifications, and RTFM takes days of wading through irrelevant referenced specifications to find the single phrase that actually defines a behavior. Thank you again, Roy A. Gilmore -- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. (Robert A. Heinlein, Time Enough for Love) On 02/25/2018 12:03 PM, Barry Leiba wrote: > Roy, thanks for taking the time to make this report. > > As this is an IMAP extension, it inherits such aspects from IMAP, RFC > 3501. The beginning of RFC 3501 Section 9 says this: > > Note: [ABNF] rules MUST be followed strictly; in > particular: > > (1) Except as noted otherwise, all alphabetic characters > are case-insensitive. The use of upper or lower case > characters to define token strings is for editorial clarity > only. Implementations MUST accept these strings in a > case-insensitive fashion. > > The notations here such as "\Archive" match the related non-extended > notations in RFC 3501 such as "\Noselect", all done for the same > editorial style and all subject to that note in RFC 3501. > > Alexey, I suggest marking this report as "rejected". > > That said, while this doesn't represent an error or omission in the > spec, it certainly wouldn't have hurt to have been explicit about > this. So I also suggest that any work the Extra working group does > related to IMAP takes an extra sentence here or there to be clear that > the items it defines are case-insensitive, and that the case shown in > the text is merely an editorial choice (perhaps just by explicitly > saying "See the ABNF notes at the beginning of RFC 3501 Section 9."). > > Barry > > > On Sun, Feb 25, 2018 at 8:16 AM, RFC Errata System > wrote: >> The following errata report has been submitted for RFC6154, >> "IMAP LIST Extension for Special-Use Mailboxes". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5265 >> >> -------------------------------------- >> Type: Technical >> Reported by: Roy A. Gilmore >> >> Section: GLOBAL >> >> Original Text >> ------------- >> >> >> Corrected Text >> -------------- >> >> >> Notes >> ----- >> In RFC6154, the special-use attributes are consistently shown with initial capitals, but there doesn't appear to be any guidance whether the special-use attributes are case-sensitive, case-insensitive, or implementation defined. This could lead to interoperability issues. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6154 (draft-ietf-morg-list-specialuse-06) >> -------------------------------------- >> Title : IMAP LIST Extension for Special-Use Mailboxes >> Publication Date : March 2011 >> Author(s) : B. Leiba, J. Nicolson >> Category : PROPOSED STANDARD >> Source : Message Organization >> Area : Applications >> Stream : IETF >> Verifying Party : IESG > > --------------AA10C25EE3C8234BE7BFE0A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Barry,

Thank you for clarifying this behavior. Upon reflecting on your rationale, I agree with your recommendation of "rejected", if for no other reason than because I had not claimed that were actually any errors or omissions in the specification, and I simply wanted clarification of a specific behavior that was not addressed within the specification itself (even though it *is* addressed in the referenced RFC 3501). In hindsight, carefully re-reading both RFC 6154 Section 6, specifically:

mbx-list-oflag =/  use-attr
                 ; Extends "mbx-list-oflag" from IMAP base [RFC3501]

and RFC 3501 Section 9, would have answered my question. I wish I had been more thorough in my research. In my defense, sometimes the answer to a trivial question is buried under many layers of chained referenced specifications, and RTFM takes days of wading through irrelevant referenced specifications to find the single phrase that actually defines a behavior.

Thank you again,

Roy A. Gilmore

--
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. (Robert A. Heinlein, Time Enough for Love)

On 02/25/2018 12:03 PM, Barry Leiba wrote:
Roy, thanks for taking the time to make this report.

As this is an IMAP extension, it inherits such aspects from IMAP, RFC
3501.  The beginning of RFC 3501 Section 9 says this:

        Note: [ABNF] rules MUST be followed strictly; in
        particular:

        (1) Except as noted otherwise, all alphabetic characters
        are case-insensitive.  The use of upper or lower case
        characters to define token strings is for editorial clarity
        only.  Implementations MUST accept these strings in a
        case-insensitive fashion.

The notations here such as "\Archive" match the related non-extended
notations in RFC 3501 such as "\Noselect", all done for the same
editorial style and all subject to that note in RFC 3501.

Alexey, I suggest marking this report as "rejected".

That said, while this doesn't represent an error or omission in the
spec, it certainly wouldn't have hurt to have been explicit about
this.  So I also suggest that any work the Extra working group does
related to IMAP takes an extra sentence here or there to be clear that
the items it defines are case-insensitive, and that the case shown in
the text is merely an editorial choice (perhaps just by explicitly
saying "See the ABNF notes at the beginning of RFC 3501 Section 9.").

Barry


On Sun, Feb 25, 2018 at 8:16 AM, RFC Errata System
<rfc-editor@rfc-editor.org> wrote:

The following errata report has been submitted for RFC6154,
"IMAP LIST Extension for Special-Use Mailboxes".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5265

--------------------------------------
Type: Technical
Reported by: Roy A. Gilmore <rag@ragged-software.com>

Section: GLOBAL

Original Text
-------------


Corrected Text
--------------


Notes
-----
In RFC6154, the special-use attributes are consistently shown with initial capitals, but there doesn't appear to be any guidance whether the special-use attributes are case-sensitive, case-insensitive, or implementation defined. This could lead to interoperability issues.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6154 (draft-ietf-morg-list-specialuse-06)
--------------------------------------
Title               : IMAP LIST Extension for Special-Use Mailboxes
Publication Date    : March 2011
Author(s)           : B. Leiba, J. Nicolson
Category            : PROPOSED STANDARD
Source              : Message Organization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

--------------AA10C25EE3C8234BE7BFE0A4-- From nobody Mon Feb 26 04:10:39 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E84C12D779 for ; Mon, 26 Feb 2018 04:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 VQtx-jttc2fv for ; Mon, 26 Feb 2018 04:10:36 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA47124234 for ; Mon, 26 Feb 2018 04:10:35 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 543ACFA0035; Mon, 26 Feb 2018 12:10:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1519647033; bh=PHUL28t5pFJ/AsUyw0LHgsKNWBeIfavWd3L4q2RNz40=; h=From:To:Subject:Date:In-Reply-To:References:From; b=r4+dZh+1YsoCmTaHGmrDboio8i2AQo6XOJlUgZy2on+hTY7i7QFN3Knka25EP+IGR +W9NlvvgI5jxb2JK3GSpP9IF5NgZGk9Xxc2PcNA6LayCHFpso9ngMDqOy64mnjPzk/ bypVa9ozHj/Qutb1M2VlxKhqLl+8j7iHapNK9Iag= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1519647032-29839-31493/11/2; Mon, 26 Feb 2018 12:10:32 +0000 From: Arnt Gulbrandsen To: morg@ietf.org Date: Mon, 26 Feb 2018 12:10:31 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20180225161655.11CA8B80C6A@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 12:10:38 -0000 Barry Leiba writes: > That said, while this doesn't represent an error or omission in the > spec, it certainly wouldn't have hurt to have been explicit about > this. So I also suggest that any work the Extra working group does > related to IMAP takes an extra sentence here or there to be clear that > the items it defines are case-insensitive, and that the case shown in > the text is merely an editorial choice (perhaps just by explicitly > saying "See the ABNF notes at the beginning of RFC 3501 Section 9."). The problem here is that IMAP documents suffer from a moderate case of "do as I say, not as I do" syndrome. They say to treat flag names, keywords etc case insensitively, but the document authors treat those things case sensitively in the document. There's a perfectly clear rule on page 81, and most of the 107 other pages are written as if the opposite rule were in force. That's not kind to the reader. Arnt From nobody Mon Feb 26 06:17:18 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97578120725 for ; Mon, 26 Feb 2018 06:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 shtCcTs3N5J8 for ; Mon, 26 Feb 2018 06:17:11 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 DC4F412D7F1 for ; Mon, 26 Feb 2018 06:17:07 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id w12so5097467ywa.8 for ; Mon, 26 Feb 2018 06:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jd/en3OJp4WKwojdxdCCgU4dE4ABVne2VmCa4UcGbR4=; b=g5XyjbhQylzoKXtY3wsLmgL2znLOxHyTxJA2LMkjial3Zj7ZsW/bf1UaHQyYQDR4Ww DWi6ZMbSukKC4Mk82ePjdz35ykIFMFj78InEJ3vjoRWL4rgOM4WX9xCYPWk6JNck2Jks 2pLsz82dPDCH4HJNJ72WQOWuVMWPRNj5/+FforwHDtawgTXAp+zJsWuFkq32YpendhLv iTGXYSxEVbGh35W9s9qxzTGvExBkRbBxLI2l3hidWB5tIVfnaqx+56zOemRK+AbUo52P M4dsCVbGisKc4uB1039A5ysv9iVUaGuuljpfvns9fMcI9eKXxuwnMb4oLThZrZslyzZz rfsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jd/en3OJp4WKwojdxdCCgU4dE4ABVne2VmCa4UcGbR4=; b=tmY82gF+6PS7wj8DytJ6jAPToGl/zCQ32ai5p8tb7QaQ5sbrJY+Gb3HKK3DD8VAGOH 0w7S2gYJpO+FHGmMfDcHhYcmSAJLYg8U1Tm/qSSeYFZLIPWvxdbcW90r/gvxMSsjlKLW PlcY6fqoBSxS9eyeh342Ax36Z6pVOGCpOFlT+hpss6/aZYaDoOsem3jd3P1GO3/bHdXd uRJzb1OgEBtMlAR4AmLNW9cpKLf0k07TXvGmHvA01ARrm11YTG0ms15icux5GRsfR/jS AgmE7Tjw6T69ynyY3G+tuOztlcHRcoV6BK4qdPAYjzPS3DPUk0sS9i5aGJvK9NBFZqIc UOEQ== X-Gm-Message-State: APf1xPAdBxM+BJlWNMtYkBrZmstMcYFGlIrlm5RNR3fKHpOAxBF7Rke9 P/uLGdrO7QJS52TIlCdtJRykJi8WZJNu68b3vgY= X-Google-Smtp-Source: AH8x227DMravovKRcO7Hi4gNp1cvjqoCkFcf+AQtyMEmVGB10fWPMG+dPmfebc7FIrYDbEaMC35OflQtf6krubDFoMo= X-Received: by 10.129.42.194 with SMTP id q185mr6916164ywq.245.1519654626814; Mon, 26 Feb 2018 06:17:06 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:a25:b7cb:0:0:0:0:0 with HTTP; Mon, 26 Feb 2018 06:17:06 -0800 (PST) In-Reply-To: References: <20180225161655.11CA8B80C6A@rfc-editor.org> From: Barry Leiba Date: Mon, 26 Feb 2018 06:17:06 -0800 X-Google-Sender-Auth: BVlzxqHr8gNJ_5xEGs6u7q7-b3o Message-ID: To: "Roy A. Gilmore" Cc: RFC Errata System , =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= , Ben Campbell , Alexey Melnikov , Adam Roach , Randall Gellens , Timo Sirainen , morg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 14:17:17 -0000 > In my defense, sometimes the answer to a > trivial question is buried under many layers of chained referenced > specifications, and RTFM takes days of wading through irrelevant referenced > specifications to find the single phrase that actually defines a behavior. Indeed, and no "defense" needed there. I am glad that you made the report, as it showed that it *is* easy to miss that point, and I think we should make it easier on implementors who have to read and digest multiple specifications. It's simple to include a reminder about that point, as I've just added to draft-leiba-extra-specialuse-important in Section 3.1. Barry From nobody Tue Feb 27 17:54:36 2018 Return-Path: X-Original-To: morg@ietfa.amsl.com Delivered-To: morg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC95124D68 for ; Tue, 27 Feb 2018 17:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 NOTWe4E5UB8t for ; Tue, 27 Feb 2018 17:54:31 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3E2127775 for ; Tue, 27 Feb 2018 17:54:31 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 27 Feb 2018 17:55:30 -0800 From: "Randall Gellens" To: "Arnt Gulbrandsen" Cc: morg@ietf.org Date: Tue, 27 Feb 2018 17:54:30 -0800 X-Mailer: MailMate Trial (1.10r5443) Message-ID: <492D42AA-73E5-401D-866F-F6D7AFC2CA31@randy.pensive.org> In-Reply-To: References: <20180225161655.11CA8B80C6A@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265) X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 01:54:34 -0000 On 26 Feb 2018, at 4:10, Arnt Gulbrandsen wrote: > Barry Leiba writes: >> That said, while this doesn't represent an error or omission in the >> spec, it certainly wouldn't have hurt to have been explicit about >> this. So I also suggest that any work the Extra working group does >> related to IMAP takes an extra sentence here or there to be clear >> that >> the items it defines are case-insensitive, and that the case shown in >> the text is merely an editorial choice (perhaps just by explicitly >> saying "See the ABNF notes at the beginning of RFC 3501 Section 9."). > > The problem here is that IMAP documents suffer from a moderate case of > "do as I say, not as I do" syndrome. They say to treat flag names, > keywords etc case insensitively, but the document authors treat those > things case sensitively in the document. > > There's a perfectly clear rule on page 81, and most of the 107 other > pages are written as if the opposite rule were in force. That's not > kind to the reader. > Hi Arnt, If you’re saying that writing a document using only one case form whenever the same token is used is unclear as to if case is semantically important, while mixing up the uses in the document so that some are capitalized, some are all lower case, while others are randomly mixed makes it clear that case is not important, I’d disagree. I think the latter form merely enhances any confusion as to if the editorial case is saying something or just accidental. Far better is to be explicit, even if only a handful of words (e.g., “case is irrelevant, per RFC 3501”). --Randall