Subject: [EAI] Comments on Post-delivery downgrade draft (draft-ietf-eai-popimap-downgrade-04.txt)

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 21 Mar 2012 15:42:35 +0900

These are my comments on draft-ietf-eai-popimap-downgrade-04.txt:

(see also my more general questions in an earlier mail)

Abstract:

"to be traditional message format" -> "to be in traditional message format"?

                                      "The purpose of post-delivery
    message downgrading is to enable POP/IMAP servers to deliver
    internationalized messages to traditional POP/IMAP clients.":
At this point in the abstract, it was quite clear to me that the purpose 
was to "enable POP/IMAP servers to deliver internationalized messages to 
traditional POP/IMAP clients". So this sounded like an unnecessary 
repetition. What is not a repetition is the term "post-delivery message 
downgrading". I suggest replacing the above sentence with something like 
"This is called  post-delivery message downgrading."

                                                                "In the
    process, message elements requiring internationalized treatment can
    be removed or recoded and receivers can know they received messages
    containing such elements even if they cannot receive the elements
    themselves.":
The two "can" (in particular the first) in this sentence don't work. 
Because we want to avoid "may", I suggest rewording to "It can happen 
that ...".

1.1 Problem statement:

"([RFC6530] and [RFC6532] allows UTF-8 characters in those mail header 
fields.":
- Nit: closing parenthese missing
- Nit: "allows" -> "allow"
- Serious rant: There are NO "UTF-8 characters". There are Unicode 
characters encoded in UTF-8. It may be simpler and clearer even (because 
there is also RFC 2047-encoded UTF-8) to say "allow raw UTF-8"

Section 1.3:

Redefinition (update) of From/Sender in RFC 5322: I am in no position to 
judge how much software is out there that will blow up on this, but the 
description in Section 3 (many will tolerate ... will fail in 
unpredictable ways) doesn't instill much confidence. I'd be way more 
happy if the description read "to the knowledge of the WG, and after 
extensive trial with a wide variety of software, no clients were found 
that don't tolerate this" (assuming it's true).
I'm assuming that the WG has already discussed this, and it's okay for 
everybody who has a lot of implementation and infrastructure experience, 
but if not, I'm really not seeing the point of defining a downgrade that 
does 99% of the job to then blow up on some edge cases.

"MIME header fields are expanded in [RFC6532]." -> The definition of 
MIME header fields in Internationalized Email Messages is given in [RFC 
6532]."

2. Terminology

"This document depends on [RFC6532].  Key words used in those
documents are used in this document, too.":
Only one document is mentioned, but it says "documents". Also, I first 
though this was an indirect import from RFC 2119, but those key words 
are given at the start of section 2. So I have no idea what this 
paragraph refers to. Please explain or reword.

Section 3

ENCODED-WORD "<" NO_EXISTING_ADDRESS ">":
nit: I'd change "NO_EXISTING_ADDRESS" to "NON_EXISTING_ADDRESS"
opinion: I'd strongly prefer this to an update of RFC 5322.
proposal: It's not a bad idea to move the UTF-8 address to the display 
name. But this should be done in a way that doesn't cancel the original 
display name. So instead of
   before:  From: Иван Грозный <[email-masked]>
   after:   From: =?UTF-8?Q?=d0=b8=d0=b2=d0=b0=d0=[email-masked]?=
                  <[email-masked]>

something like:
   before:  From: Иван Грозный <[email-masked]>
   after (without RFC 2047 encoding):
            From: Иван Грозный ([email-masked])
                   <[email-masked]>

That proposal also applies to Arnt's simplified draft. The reason for 
this is that although often there is overlapping information in address 
and display text, it's usually only some part that's overlapping, and 
the rest is helpful, too.

"@imap.example.com": I prefer the idea of using .invalid. The clearer it 
is that this isn't a real address (both to humans and software), the better.

Section 5

The draft should be extremely clear on the fact that the "Downgrading-" 
prefix isn't a general convention, but is reserved for exactly those 
header it is used with in the spec.

5.1.1: This is about a specific header field, it seems to belong in 5.2.

5.2.  Downgrading Method for Each Header Field

    "Header fields are listed in [RFC4021]." -> "[RFC 4021] establishes
    a registry of header fields." (There are headers that are not listed
    in RFC 4021.)

5.2.9.  Other Header Fields

    "and their field value are" -> "and their field values are"

7.  Security Considerations

    The purpose of post-delivery message downgrading is to allow POP/IMAP
    servers to deliver internationalized messages to traditional POP/IMAP
    clients and permit them to work with those messages.

    The last clause ("permit them to work with these messages") is 
unclear. What "work" can be done?

References: Please order by RFC number, to make it easy to find each 
reference quickly.

Regards,    Martin.

---

From: [email-masked]
Date: Thu, 22 Mar 2012 18:27:59 +0900 (JST)

Thanks very much for your comments.

> From: "Martin J. Dürst" <[email-masked]>
> Abstract:
> 

updated my local copy.

> At this point in the abstract, it was quite clear to me that the
> purpose was to "enable POP/IMAP servers to deliver internationalized
> messages to traditional POP/IMAP clients". So this sounded like an
> unnecessary repetition. What is not a repetition is the term
> "post-delivery message downgrading". I suggest replacing the above
> sentence with something like "This is called post-delivery message
> downgrading."

I will consider how to update.

> The two "can" (in particular the first) in this sentence don't
> work. Because we want to avoid "may", I suggest rewording to "It can
> happen that ...".

I will consider how to update.

> - characters encoded in UTF-8. It may be simpler and clearer even
> - (because there is also RFC 2047-encoded UTF-8) to say "allow raw
> - UTF-8"

updated.

> Section 1.3:
> 
> Redefinition (update) of From/Sender in RFC 5322: I am in no position
> to judge how much software is out there that will blow up on this, but
> the description in Section 3 (many will tolerate ... will fail in
> everybody who has a lot of implementation and infrastructure
> experience, but if not, I'm really not seeing the point of defining a
> downgrade that does 99% of the job to then blow up on some edge cases.

Redefinition of From/Sender in RFC 5322 is a WG conclusion, but I'm
not sure that all existing software do not encounter problems caused
by the update. So, I added [[ Notes in draft: If this update is
rejected, ...]]  in section 3.

> MIME header fields in Internationalized Email Messages is given in
> [RFC 6532]."

updated.

> paragraph refers to. Please explain or reword.

I will update the part to refer related documents.

> nit: I'd change "NO_EXISTING_ADDRESS" to "NON_EXISTING_ADDRESS"

updated

> name. But this should be done in a way that doesn't cancel the
> original display name. So instead of

Do you mean that removing brackets "<>" from <angel-addr> and put it
in a comment ?

It is reasonable and I will update.

> this is that although often there is overlapping information in
> address and display text, it's usually only some part that's
> overlapping, and the rest is helpful, too.
> 
> "@imap.example.com": I prefer the idea of using .invalid. The clearer
> it is that this isn't a real address (both to humans and software),
> the better.

Arnt's .invalid usage is also useful for NON_EXISTING_ADDRESS of this
draft in [[ Notes in drafts ]].

> Section 5
> 
> The draft should be extremely clear on the fact that the
> "Downgrading-" prefix isn't a general convention, but is reserved for
> exactly those header it is used with in the spec.
> 

Moved 5.1.1 and Merged with 5.2.2.

>    a registry of header fields." (There are headers that are not listed

Updated

>    "and their field value are" -> "and their field values are"

updated

>    unclear. What "work" can be done?

I mentioned that the messages enable the receivers to know that they
received something.

I will try to update.

> References: Please order by RFC number, to make it easy to find each

updated.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 23 Mar 2012 15:30:18 +0900

Hello Kazunori,

Many thanks for your quick reply.

On 2012/03/22 18:27, [email-masked] wrote:
>> From: "Martin J. Dürst"<[email-masked]>

> Redefinition of From/Sender in RFC 5322 is a WG conclusion,

I see. There are many people on the WG who have more experience with 
this than me, so I think it's okay.

> but I'm

I suggest that somebody more familiar with the actual deployment 
situation helps you tweak that text. From the fact that there was WG 
consensus, it may be that your description read scarier than necessary.

>>    before:  From: Иван Грозный<[email-masked]>
>>    before:  From: Иван Грозный<[email-masked]>
> Do you mean that removing brackets "<>" from<angel-addr>  and put it
> in a comment ?
>

Ah, sorry, I forgot that parentheses are comments in these fields. A 
comment is fine, but something else would also be fine, e.g.

  (without RFC 2047 encoding):
              From: Иван Грозный: [email-masked]
                     <[email-masked]>

Regards,   Martin.