Subject: [MORG] [Technical Errata Reported] RFC6154 (5265)

From: RFC Errata System <[email-masked]>
Date: Sun, 25 Feb 2018 08:16:55 -0800 (PST)

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 <[email-masked]>

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: Barry Leiba <[email-masked]>
Date: Sun, 25 Feb 2018 12:03:40 -0800

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

-- 
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/

---

From: "Roy A. Gilmore" <[email-masked]>
Date: Sun, 25 Feb 2018 21:18:10 -0800

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)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 26 Feb 2018 12:10:31 +0000

> 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: Barry Leiba <[email-masked]>
Date: Mon, 26 Feb 2018 06:17:06 -0800

> 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: "Randall Gellens" <[email-masked]>
Date: Tue, 27 Feb 2018 17:54:30 -0800

On 26 Feb 2018, at 4:10, Arnt Gulbrandsen wrote:

> 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