Re: [EAI] [Technical Errata Reported] RFC6857 (6573)

It's not just undesirable; the example doesn't produce a result that conforms to
section 3.1.5 and 3.1.8. There are various ways to fix this, but the suggested
one is probably the simplest and therefore best.

This erratum should be marked as verified.

Beyond that, I take note that the the way the text is written suggests that the
genesis of this error lies in the apparent need to use separate encoded-words
for the display-name and addr-spec, which in turn suggests they have an attached
semantic that is sufficient to cause the space to be inserted.

This is not, in fact, the case: An RFC 2047 decoder is simply going to say,
"Adjacent encoded words, remove space" and be done with it.

If and when this specification is revised, it would be a good idea to clarify
this point.

				Ned

> The following errata report has been submitted for RFC6857,
> "Post-Delivery Message Downgrading for Internationalized Email Messages".

> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6573

> --------------------------------------
> Type: Technical
> Reported by: Kaspar Etter <me@kasparetter.com>

> Section: A

> Original Text
> -------------
>    From: =?UTF-8?Q?DISPLAY-LOCAL?=
>          =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;

> Corrected Text
> --------------
>    From: =?UTF-8?Q?DISPLAY-LOCAL_?=
>          =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;

> Notes
> -----

> Taking the original text from Errata 3955
> (https://www.rfc-editor.org/errata/eid3955), the two encoded-words decode to:
> DISPLAY-LOCALNON-ASCII-LOCAL@example.com :; (According to section 6.2 of RFC
> 2047, linear whitespace between adjacent encoded-words is ignored.) This is
> clearly not desirable and thus a space should be encoded at the end of all
> display names in appendix A.

> 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.

> --------------------------------------
> RFC6857 (draft-ietf-eai-popimap-downgrade-08)
> --------------------------------------
> Title               : Post-Delivery Message Downgrading for Internationalized Email Messages
> Publication Date    : March 2013
> Author(s)           : K. Fujiwara
> Category            : PROPOSED STANDARD
> Source              : Email Address Internationalization
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima