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-simpledowngrade-03
Title: EAI: Simplified POP/IMAP downgrading
Reviewer: Claudio Allocchio
Review Date: April 30th 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary:

This specification needs some revision before it can be published. Some of 
them are just clarifications and better text, but in the case of the 
Security Considerations section, it might even need a revision, set of 
suggestions, from the Security area folks, in order to find the best 
possible way to explain involved risks.

I also suggest further thinking about the "Proposed Standards" track 
publication. I do see a good number of pros in doing this, but I'm not 
confident this is the completely correct way to go.

Major Issues:

2.3 Subject

adding or non adding a "DOWNGRADED" or equivalent to the subject is a 
major decision which also impacts on the way the security failure which 
are introduced by this specification are perceived by the user. This issue 
shall be fixed and a decision taken ASAP, in order to publish this.

5. Security Considerations

this section is way too short and simplified, compared to the issues that 
this specification introduces against secure e-mail mechanisms.

This section should give an exaustive list of caveats, and possible 
actions in various cases, in order to make clear that this specification 
breaks explicilty most of the existing security anchors where users should 
rely nowadays. It should also list that, while it is clear that in most of 
the cases where downgrading and/or gatewaying is involved, possible 
security leaks are introduced, and user's security mechanisms become 
invalid. "as is" is not enough.

  Minor Issues:

Abstract:

given the quite invasive action on messages presentation that such a 
specification describes, such a short and "optimistic" abstract is, IMHO, 
misleading. At least insert a sentence to describe the scenario, and what 
this specification is trying to accomplish, what problems it tries to 
solve, and what issues are left open and voluntarily not solved here.

1 Overview:

I disagree on the way the overview present "phylosophically" the problem 
to the reader. This is a technical specification intended for Standards 
Track, not an informational document. Thus, it should not focus on the way 
implementerss spend their time, os users' behaviours. It should state the 
problem and the proposed solutions: (dot)!

Here is my suggested version of this paragraph:

---

1. Overview

It may happen that a conventional IMAP or POP client opens a mailbox 
containing internationalized messages, or even attempt to read 
internationalized messages, for instance when a user has both 
internationalized and conventional MUAs.

When this mismatched sitation happens, various strategies are possible:

  a) the server can hide the existence of such messages entirely, but
     doing that can be both tricky to implement and gives a false mailbox
     status to the user;

  b) the server attempts to present at least some information about these
     messages to the user. It shall be clear that what the user is being
     presented is not the original message, and information is dropped;

  c) the server does nothing, possibly creating problems to the client, and
     providing a bad user's experience.

This document specify a way to implement strategy b), which enables the 
best compromise between a) and c), and promotes a simple to implement 
solution which conveys a better-than-nothing information service to the 
user. Accuracy of information and Security featues of the message will, 
however, not be preserved, and users should rely on an internationalised 
client as much as possible.

The server is assumed to be internationalized internally. When it
needs to present an internationalized message to a conventional
client, it synthesizes a conventional message containing most of the
information and presents that (the "synthetic message").

----

2.1 Email addresses

At lease one sentence clearly stating that this will make impossible to 
reply to such a synthetic message should be present here. Too obvious? 
no... never suppouse that.

Nits:

1 Overwiew

"It may happen that a conventional IMAP or POP client (MUA) opens..."
                                                       ^ add the definition

I suggest coherent use also in other parts of the specification.

6. Acknowledgments

well... clean it up from the call, before publishing!

7. IANA Considerations

ADD the name of the correct registry!

----------------------------

Ok... now I can go and read my co-reviewer report :-)

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         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