FW: CORRECTION: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard

-----Original Message-----
From: Dan Wing [mailto:[email protected]]
Sent: Monday, July 01, 2002 7:20 PM
To: [email protected]; Dave Crocker; [email protected]
Subject: FW: CORRECTION: Last Call: SMTP Service Extension for Content
Negotiation to Proposed Standard


Several issues.

Please explain why you require a space in the RCPT
modifier; that is, why is the ABNF:

  "CONNEG ="

instead of 

  "CONNEG" "="

or simply

  "CONNEG="


In section 5, your the word "OPTIONAL" is mispelled.



In section 5, is the only valid destination address supposed
to be "Postmaster"?  The example in section 6 contradicts
that.


The text throughout the document uses
  "CONNEG = REQUIRED" 
and
  "CONNEG = OPTIONAL" 

but section 5 says there isn't a space after "=".


The text says:

     The response strings for a temporary failure are 
     "404-4.3.3 CONNEG" and "404 5.3.3 CONNEG".

which looks like a cut-and-paste error (4.3.3 -> 5.3.3).




In section 5, your failure example is:


     C: RCPT TO:<[email protected]> CONNEG = REQUIRED
     S: 504 <[email protected]> recipient ok

I believe the text "recipient ok" is inappropriate here.  Perhaps
more appropriate would be "recipient okay, but CONNEG unavailable".

Further, your ABNF in section 5 does not permit any text
after the "504" -- it only permits <CRLF>.


I'm guessing section 5 is supposed to be ABNF, but as Dave
is the author of ABNF and section 5 doesn't claim to be ABNF,
I can't tell what it's supposed to be.  Can the document
make this clearer?


Section 5 seems to prohibit multiline 504 and multiline
404 responses, but such multiline responses are permitted
by the underlying RFC2822 specification.  Is your specification
purposely prohibiting multiline 504 and 404 responses by CONNEG-
capable SMTP servers that receive CONNEG=REQUIRED or
CONNEG=OPTIONAL ?

Section 5 doesn't define the meaning of <domain>.




I am very unclear on the difference between a client 
specifying CONNEG=OPTIONAL versus a client specifying no CONNEG
parameter at all.



You should cite the ENCHANCEDSTATUSCODES RFC.


How is this supposed to work with relaying?  This needs to
be discussed.  Is a mail submission agent supposed to 
open TCP connections to the MX host for the recipient
to hope to learn the information, or is it via some
other means, or is this not expected to yet work for
relaying?



Section 6, the examples, do not clearly show that the
server isn't sending CRLF between the lines.  Lines that are
separated by CRLF such as 


     S: 250-ifax1.jp
     S: 250-DSN
     S: 250 CONNEG
     

are shown exactly like lines that aren't separated by CRLF such
as


     
     S: 250-<[email protected]> recipient ok
     S: 250 CONNEG (&(image-file-structure=TIFF-minimal)
     S: (MRC-mode=0)(color=Binary)(|(&(dpi=204)
     S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200)
     S: (dpi-xyratio=[200/100,1]) )(&(dpi=400)
     S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR])
     S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85)
     S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4])
     S: (ua-media=stationery) )
     
While this is described in the text of the document,
the example isn't nearly clear enough.

Please add text indicating that the example is broken into
multiple lines for clarity in the document, but that the
Server transmits only two CRLF lines for the above example:
one CRLF at the first line and another CRLF at the last line
and no CRLFs are sent in between.

This is a serious interoperabilty issue.  The ABNF (or
whatever is in section 5) isn't clear on this either.

The unique way you have separated the Client and Server
lines (using blank lines) doesn't help show that CRLF isn't
sent on each line (which I'm guessing was the intent of
this extra blank line, but the extra blank line was never
explained in the document).



My specific recommendation is that you change the
example to:

  6.   EXAMPLE

     An example of ESMTP sequence with successful RCPT-TO response

       1  S: 220 ifax1.jp IFAX
       2  C: EHLO ifax1.jp
       3  S: 250-ifax1.jp
       4  S: 250-DSN
       5  S: 250 CONNEG
       6  C: MAIL FROM:<[email protected]>
       7  S: 250 <[email protected]> sender ok
       8  C: RCPT TO:<[email protected]> CONNEG = REQUIRED
       9  S: 250-<[email protected]> recipient ok
      10  S: 250 CONNEG (&(image-file-structure=TIFF-minimal)
      11  S: (MRC-mode=0)(color=Binary)(|(&(dpi=204)
      12  S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200)
      13  S: (dpi-xyratio=[200/100,1]) )(&(dpi=400)
      14  S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR])
      15  S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85)
      16  S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4])
      17  S: (ua-media=stationery) )
      18  C: DATA
      19  S: 354 okay, send data
      20  C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
             Per:
             (  image-file-structure=TIFF-minimal
                dpi=400
                image-coding=JBIG
                size-x=2150
              )
             >>
      21  S: 250 message accepted
      22  C: QUIT
      23  S: 221 goodbye

      Note that line 9 is terminated with CRLF, but lines 10
      through 16 are not terminated by CRLF -- they are only shown
      wrapped in this document for clarity.  The next line that
      has a CRLF is line 17.

Or, if you prefer, add this text above that specific line (which
eliminates the need to number them).

   <<The following line contains only two CRLF pairs -- one
   CRLF on the line beginning with "250-", and another CRLF
   at the end of the string "(ua-media=stationery) )".  There
   are no other CRLF pairs in the string below.  If wrapping
   is desired, it must be implemented by the technique 
   described in section X.Y of this document.>>


-d

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of The IESG
Sent: Monday, July 01, 2002 2:34 PM
To: IETF-Announce:
Cc: [email protected]
Subject: CORRECTION: Last Call: SMTP Service Extension for Content
Negotiation to Proposed Standard




[Please note the corrected four week last call date, due to the 
upcoming 54th IETF.  Sorry for any confusion.]

The IESG has received a request from the Internet Fax Working Group to 
consider SMTP Service Extension for Content Negotiation 
<draft-ietf-fax-esmtp-conneg-02.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[email protected] or [email protected] mailing lists by July 29, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-02.txt