Subject: [EAI] AppsDir review of draft-ietf-eai-popimap-downgrade-05

From: Claudio Allocchio <[email-masked]> (by way ofS Moonesamy <[email-masked]>)
Date: Tue, 01 May 2012 02:42:19 -0700

Hello all,

I have been selected as the Applications Area Directorate co-reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-eai-popimap-downgrade-05
Title: Post-delivery Message Downgrading for Internationalized Email
        Messages
Reviewer: Claudio Allocchio
Review Date: April 30th 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary: This document is requires a major decision about 
updating/non updating RFC 5322 before it can go to publication. Once 
this is done, other minor changes are listed below and it can be 
published. Another issue to clarify/fix is its relationship with 
draft-ietf-eai-simpledowngrade-03 specification (and also in that 
document, of course, with respect to this one).

Major Issues:

3. Updating RFC 5322

this is a big major issue in this specification.

I do not believe that stating something like "It is anticipated that 
when existing implementations encounter a downgraded field from this 
set, many will tolerate the appearance of a group" is a possible 
thing into a Standards Track specification.  Th "update" to RFC 5322 
is a big major one, and cons should be carefully evaluated here, too. 
As the "Notes in Draf" itself states, there is an alternate, much 
safer mechamism which can be used, and convey the same information to 
the user. This isse must be clarified before this specification can 
be publisehd, and a decision taken.

Minor Issues:

there is not cross-reference at all with

draft-ietf-eai-simpledowngrade-03!

many implementers could ge confused about the releationship between 
these specifications. In the Summary this should be explicitly 
described and clearly stated.

Security Considerations

this section describes quite well the possible scenarios which this 
specification introduces (and can also be a good example for re-writing
the same secrion in draft-ietf-eai-simpledowngrade-03); I'd just 
suggest a further review by the Security area folks, too. Just in case...

  Nits:

1.1 Problem statement

I'd suggest removing "Discussions leading to this specification 
concluded that " and just start with "There are four...'

5.1.1 until 5.1.9

in the titles you use the defintions without the <...> surrounding them.
e.g.

   5.1.5 GROUP Downgrading.

I'd suggest changing them all using the < and > ... e.g.

   5.1.5 <GROUP> Downgrading.

etc.

IANA Considerartions:

... to be fixed with IANA before publication!

All over the document (and expecially in the A.1 example):

this document uses a different convetion than 
draft-ietf-eai-simpledowngrade-03 for non ASCII elements in 
addresses/fields. Please unify the used convetion with the other 
draft (whichever of the 2 convetion is better) before publication.

Here you write "NON-ASCII-something..." there you just use UPPERCASE.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: [email-masked]
Date: Wed, 02 May 2012 18:49:09 +0900 (JST)

I will update the draft after next iterim meeting.

People who attend the iterim meeting should read this comment.
It contains two discussion points.

  1. updating RFC 5322 (or not)
  2. how to rewrite NON-ASCII elements (different from draft-ietf-eai-simpledowngrade)

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

> From: Claudio Allocchio <[email-masked]> (by way ofS Moonesamy <[email-masked]>)
> Hello all,
> 
> Summary: This document is requires a major decision about updating/non
> updating RFC 5322 before it can go to publication. Once this is done,
> other minor changes are listed below and it can be published. Another
> issue to clarify/fix is its relationship with
> set, many will tolerate the appearance of a group" is a possible thing
> into a Standards Track specification.  Th "update" to RFC 5322 is a
> big major one, and cons should be carefully evaluated here, too. As
> the "Notes in Draf" itself states, there is an alternate, much safer
> mechamism which can be used, and convey the same information to the
> user. This isse must be clarified before this specification can be
> publisehd, and a decision taken.
> 
> Minor Issues:
> 
> addresses/fields. Please unify the used convetion with the other draft
> (whichever of the 2 convetion is better) before publication.
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 May 2012 14:14:41 +0200

I suppose there's no reasonable way around it. I really, really didn't
want to publish my opinion of popimap-downgrade in RFC form, but there
seems to be no way around it.

Please help me rewrite the text below so noone will think I'm flaming
Kazumori. The editor of a WG document deserves no blame if WG members
ask him to add complexity, and he does so. The result may suffer from
rampant featuritis, but that's the WG's fault, not the editor's.

Arnt

Appendix X. Comparison with [RFC-popimap-downgrade]

The EAI working group has also produced another downgrade description,
[RFCxxxx]. The two descriptions share some traits, but also have some
important differences.

This appendix is opinionated, and the author does not expect readers to
share his opinion.

While the prose below discusses IMAP, the same issues apply to POP.

The most important common traits is that most conventional MUA will
display the subject and main body text of most downgraded messages
correctly, and that they generally cannot reply.

The two documents take very different positions on the appropriate
balance between implementation complexity and accuracy of presentation.

Where this document allows the server to discard many things, [RFCxxxx]
often/always[?] preserves all message content. An unextended IMAP client
may not be able to see the content, but a skilled human debugger can.
If, for instance, a Received header field contains unicode text, this
document suggests that the server not show that field to the client.
[RFCxxxx] preserves its content, which may require the server to know
the syntax of many more header fields than this document does, and
requires implementation work in the client to derive full advantage.

[RCCxxxx] specifies enough detail that an IMAP client can read and
display internationalized mail accurately using either [RFC5738] or
[RFCxxxx]. In contrast, this document is based on a stance that there
should be only one IMAP extension to read internationalized mail, and
it's [RFC5738]. (It follows from that difference that [RFCxxxx]
specifies exactly how to downgrade addresses and this document doesn't.)

One might say that [RFCxxxx] is appropriate for a world where
conventional and internationalized clients coexist for a long time, and
where it's appropriate to put a great deal of effort into downgrading,
while this document is appropriate for a quick transition, where it's
more appropriate to put effort into implementing [RFC5721] and [RFC5738]
and skimp on transition support.