Subject: [EAI] Last Call question about encoding of <mailbox> in popimap-downgrade

From: John C Klensin <[email-masked]>
Date: Mon, 23 Jul 2012 19:29:34 -0400

Hi.

This is another "are we sure?" question.    I'm happy if the
answer is "yes" or "makes no difference", but am obligated to
ask.

The current text of Section 4.1.7 of popimap-downgrade-06
requires that any <mailbox> that contains and <addr-spec> that
contains non-ASCII characters be rewritten into a Group with
encoded words.  In the spirit of the rest of popimap-downgrade,
that is certainly the right thing to do if the <addr-spec> has
non-ASCII characters in the local-part, e.g.,
    non-ASCII@ASCII-FQDN
or
    non-ASCII@non-ASCII-FQDN

but, suppose the <addr-spec> were 
    ASCII-local-part@non-ASCII-FQDN

A clever downgrader could rewrite the non-ASCII-FQDN into
A-labels if needed and thereby avoid the Group stuff and
preserve a deliverable address.

Do we want to explicitly allow that option?  My personal guess
is that any IMAP or POP server implementation that decides to go
to the trouble of this downgrading model will figure out that
possibility and ignore us if we do not, but I could be wrong.

best,
   john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 24 Jul 2012 10:14:56 +0900

I agree with John's conclusion that a clever implementer will ignore the 
document.

I'm not sure what John is implying, document change or no document 
change. I'd probably favor a document change unless this affects the 
schedule too much.

Regards,    Martin.

On 2012/07/24 8:29, John C Klensin wrote:
> requires that any<mailbox>  that contains and<addr-spec>  that
> that is certainly the right thing to do if the<addr-spec>  has
> but, suppose the<addr-spec>  were
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Jul 2012 23:08:57 -0400

--On Tuesday, July 24, 2012 10:14 +0900 "\"Martin J. Dürst\""
<[email-masked]> wrote:

> I agree with John's conclusion that a clever implementer will
> ignore the document.
> 
> I'm not sure what John is implying, document change or no
> document change. I'd probably favor a document change unless
> this affects the schedule too much.

As you will see when you go through the review notes, I don't
think it makes any schedule difference unless we have to spend a
lot of energy getting the wording right.  I see no reason why
that should happen, but I've been wrong about that sort of thing
before.

Personally, I always prefer to have things worded so that
implementers don't have to ignore us.  I believe that it weakens
our credibility, however slightly, each time someone does have
to ignore a standards-track document.  I'd be arguing strongly
for a change if the text outright prohibited making the
conversion to A-labels.  But it doesn't do that.  Instead, what
it says is, IMO, slightly fuzzy.  So, while I'd personally
prefer to see it changed, I don't believe that it will have any
real effect on quality implementations one way or the other, so
I can't feel really strongly on the subject.

I think that probably puts the two of us in agreement.

best,
   john

>> encoded words.  In the spirit of the rest of
>> popimap-downgrade, that is certainly the right thing to do if
>> the<addr-spec>  has non-ASCII characters in the local-part,
>> e.g.,
>>      non-ASCII@ASCII-FQDN
>...

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 24 Jul 2012 10:21:18 +0200

I don't think popimap-downgrade should regulate that, at least not too 
closely.

   Cc: a@B, c@F, E@f

Suppose the server can downgrade two of those, the third not. Anyone 
doing a group reply may then reply to some people, not all. Is that 
better than nothing or dangerously misleading? I can see sense in both 
viewpoints and neither is much better than the other, and so I think 
it's bad to disallow one of them.

RFC should not contain rules with which a sensible implementer can/will 
strongly disagree. I realise that's not always possible.

Arnt

---

From: Joseph Yee <[email-masked]>
Date: Mon, 30 Jul 2012 14:18:08 -0400

> possibility and ignore us if we do not, but I could be wrong.

I see this has no harm, or in the "make no difference" category.  The
deployment and configuration of the whole mail infrastructure matters
more than the address format display in order for non SMTPUTF8 MUA to
make use (mostly reply) without fail.

Joseph