Subject: [EAI] [Technical Errata Reported] RFC6855 (4029)

From: RFC Errata System <[email-masked]>
Date: Fri, 27 Jun 2014 13:45:39 -0700 (PDT)

The following errata report has been submitted for RFC6855,
"IMAP Support for UTF-8".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6855&eid=4029

--------------------------------------
Type: Technical
Reported by: Chris Newman <[email-masked]>

Section: 3

Original Text
-------------
   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
   contains a charset specification.  If an IMAP server receives such a
   "SEARCH" command in that situation, it SHOULD reject the command with
   a "BAD" response (due to the conflicting charset labels).

Corrected Text
--------------
   Once an IMAP client has enabled UTF-8 support with the "ENABLE
   UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
   contains a charset specification.  If an IMAP server receives such a
   "SEARCH" command in that situation, it SHOULD reject the command with
   a "BAD" response (due to the conflicting charset labels). This also
   applies to any IMAP command or extension that includes a charset
   label and associated strings in the command arguments. Such
   extensions presently include SORT, THREAD and MULTISEARCH.

Notes
-----
This is a straightforward extrapolation of the existing text, but a literal reading of the existing text is silent about how to deal with this situation.

Instructions:
-------------
This errata 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 (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6855 (draft-ietf-eai-5738bis-12)
--------------------------------------
Title               : IMAP Support for UTF-8
Publication Date    : March 2013
Author(s)           : P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed.
Category            : PROPOSED STANDARD
Source              : Email Address Internationalization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Fri, 27 Jun 2014 18:11:24 -0400

This could be thought of as beyond the scope of errata, but I actually
think it *is* within scope and I will mark it Verified early next week
if no one objects.  This absolutely is something that we would have
fixed in the original text if we'd thought of it.

Thanks for catching it now, Chris.

Barry

On Fri, Jun 27, 2014 at 4:45 PM, RFC Errata System
<[email-masked]> wrote:
> This is a straightforward extrapolation of the existing text, but a literal
> reading of the existing text is silent about how to deal with this situation.
>
> Instructions:
> -------------

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Jun 2014 19:24:18 -0400

--On Friday, June 27, 2014 18:11 -0400 Barry Leiba
<[email-masked]> wrote:

> This could be thought of as beyond the scope of errata, but I
> actually think it *is* within scope and I will mark it
> Verified early next week if no one objects.  This absolutely
> is something that we would have fixed in the original text if
> we'd thought of it.
> 

FWIW, I concur.  The extrapolation is obvious, but should have
been explicit.

To folks on the IMA list: as these sorts of things slowly
accumulate and as we see announcements like the recent Google
one to which Yao's recent note referred, it may be time to start
a discussion about doing a careful review of the documents,
upgrading them to cover these errata and questions, and moving
the whole stuff to full standard.  Does anyone care enough to do
work?  Do we have volunteers?

    john

>>    Once an IMAP client has enabled UTF-8 support with the
>>    "ENABLE UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH"
>>    command that contains a charset specification.  If an IMAP
>>    server receives such a "SEARCH" command in that situation,
>>    it SHOULD reject the command with a "BAD" response (due to
>>    the conflicting charset labels).
>> 
>> 
>> Corrected Text
>> --------------
>>    Once an IMAP client has enabled UTF-8 support with the
>>    "ENABLE UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH"
>>    command that contains a charset specification.  If an IMAP
>>    server receives such a "SEARCH" command in that situation,
>>    it SHOULD reject the command with a "BAD" response (due to
>>    the conflicting charset labels). This also applies to any
>>    IMAP command or extension that includes a charset label
>>    and associated strings in the command arguments. Such
>> This is a straightforward extrapolation of the existing text,
>> but a literal reading of the existing text is silent about
>> how to deal with this situation.
>> 
>> Instructions:
>> -------------
>> This errata 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 (IESG) can log in to change the status and
>> edit the report, if necessary.
>> 
>> Author(s)           : P. Resnick, Ed., C. Newman, Ed., S.
>> Shen, Ed. Category            : PROPOSED STANDARD
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 28 Jun 2014 10:20:51 +0200

> Thanks for catching it now, Chris.

We discussed it around May 2012. I think it was in the jabber/phone meeting 
when 6855-in-spe lost about twenty unnecessary rules in an hour. As I 
remember it, before the meeting there was a complex rule, and after it 
there was a simple rule. Now this erratum changes to a different simple 
rule.

It's not clear to me that either simple rule is noticeably better than the 
other.

Arnt

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 30 Jun 2014 15:08:21 +0900

> work?  Do we have volunteers?

I think it's still a bit early to seriously work on this, but I 
sincerely hope the time will come. I volunteer to review drafts, and to 
work on an update to RFC 6068 (mailto:), whether as part of the WG or not.

Regards,   Martin.