IESG Review: draft-ietf-fax-esmtp-conneg-10.txt

The IESG reviewed draft-ietf-fax-esmtp-conneg-10.txt during today's
telechat.  I've included the comments below and request that the authors and
WG chairs talk to the ADs that provided the comments.  The document will
definitely need to be revised to address the "Discuss" issues described by
Steve Bellovin, Ted Hardie, and Alex Zinin.  The actions to take with the
other comments will likely depend on the outcome of discussions with the
reviewers.

These comments can also be found in the I-D tracker.

-Scott-
----------
Steve Bellovin:
Discuss:
[2004-07-06] This scheme completely breaks S/MIME.  At the very least, there
needs to be discussion of that fact and its implications; ideally, there
should be some mention of the architecture for -- and the security
implications of -- a content-converting S/MIME gateway.

The CPU load of such conversions should also be discussed in the Security
Considerations section.  Is this another way to DoS a mail server?

Ted Hardie:
Discuss:
[2004-07-06] In general, this does not seem adequately specified for general
use.  A limited use
case might be made specifically for one class of devices using SMTP in a
specific
way, but this is not the approach the authors have taken.

Going through the draft point by point would be exhausting, and I'm not sure
it would help.  Among the issues are:  the document allows for the
conversions
to happen off the message path, but has not dealt with the issues raised
by the IAB in the context of OPES; the document allows for conversion 
and continuation of the use of CONPERM so that a later conversion may
take place--creating the classic "copy of a copy" syndrome; the document
permits a message intended for multiple recipients to be split according
to the capabilities of the recipients and fails to specify whether the
recipient
list is retained or split; the document punts completely how the SMTP
service
gets the CONNEG data in the first place, putting a critical part of the
security story out of reach.

Alex Zinin:
Discuss:
[2004-07-08] Gen-art reviewer Joel Halpern:

This draft is basically ready for publication, but has nits that should be 
fixed before publication.  This may be more positive than I really am, in 
that the long comment that follows is either me being confused or the 
comment is fairly significant.


Significant comments:

There is a consistent phrasing in this document which I think is just 
unfortunate.  The text says repeatedly that the conversion MUST be 
performed at the point where CONPERM meets CONNEG.
This would, as stated, result in avoidable delivery failures.
To elaborate, the client has sent the email, with CONPERM and permitted 
mandatory conversions, to server S1 which supports CONPERM and some 
conversions.  Server S2 happens to know the capabilities of target T, so it 
responds with CONNEG.  Let us assume that there is a non-empty intersection 
between the target acceptable forms and the sender specified 
transforms.  So, by the spec S1 is required to perform the transform or 
fail the request.  But it would seem likely, particularly if T is a limited 
device and S2 explicitly supports T, that S2 could perform the conversion 
even if S1 can not.
If the working group really intended to prohibit S1 from sending the 
request on to S2 without conversion, I really think some explanatory text 
is required.
(This is particularly odd since if S2 simply chose not to tell S1 that it 
know the targets capabilities, the S2 would get the message, and could 
perform the conversion.)

Related to this is the requirement that a server only offer CONPERM if it 
is able to perform conversions.  But CONPERM is a generalized capability, 
not a statement of specific conversions relevant to the specific 
message.  Thus, the requirement is vacuous.  (If the server is able to 
convert useless format A to useless format B, and it preserves CONPERM 
information, then it can advertise CONPERM.  But if it does not happen to 
have any conversion that it supports, then it can not advertise this?  It 
is even more vacuous since it is vacated if the server somehow magically 
knows that someone down the line can perform the conversion.
It seems to me that CONPERM ought to be offered if the server is prepared to
a) carry CONPERM forward
b) do the right thing if the next neighbor does not support CONPERM
c) do the right thing relative to a client, including failing the request 
if a mandatory conversion can not be performed


Maybe my usage of English is odd, but as I read this spec, the 
"Content_Conversion_Permission" service extension is used not to give 
permission to convert, but rather to mandate conversion.  permission is 
given by the presence of the Content-Convert header.  Shouldn't this be 
called the "Content_Conversion_Required" service extension?


I got confused in section 4.2.  To backtrack, reading everything else, 
CONPERM indicates that conversion is required before delivery.  Earlier 
text indicates that in the absence of CONPERM, message delivery continues 
even if conversion can not be performed.  Then, in the Client Action 
portion of 4.2 on CONNEG, the text says that if the intersection of 
conversion goals is empty:
          (1)  If the message is subject to CONPERM, the Client MAY
                continue to transmit the original content, according to
                CONPERM.

          (2)  Otherwise, the Client MUST treat the conversion as
                failed.
I am not sure what either bullet actually means.
I am guessing that bullet 1 is trying to say that even if CONPERM was 
indicated for the whole message, the failure response depends upon whether 
the conversion of the specific body part was mandatory.  If so, it just 
does not say that.
I am guessing that bullet 2 really means "just let the message proceed 
without recording any conversions" since that is what the rest of the spec 
says to do if one can not convert.  However, the words do not say that.


I believe the following is typographic, but it leaves the reader guessing:
The list of features refers to "Content-Convert, Content-Converted, and 
Content-Features.  The general overview indicates that the conversions are 
recorded into the Content-Converted and Content-Features MIME 
headers.  However, the description of the "Intermediary Actions" says that 
the record of conversions is placed in the "Content-Previous" headers 
(rather than the "Content-Converted" headers.)
Section 6 always describes this extensively as the Content-Previous header 
rather than the Content-Converted Header.
Could we have just one name for this header?

Minor:
There is no citation of an RFC defining the ABNF format used in this 
document.  And I would not be surprised if the existing document does not 
support <<[ref] or [ref]>> for inclusion by reference.

The phrasing of the IANA considerations section is odd.  I believe what is 
desired is that IANA record the new parameters in the registries (I assume 
those exist) but that no new registries or opportunities for other folks to 
create entries are created by this document.

[CONMSG] is either a normative reference or an informative reference.  If 
(as I suspect) it is used normatively some of the time, it should appear in 
the normative list and not in the informative list.

There is no IPR disclosure.