[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: CORRECTION: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard
From: Dan Wing [mailto:dwing@xxxxxxxxx]
Sent: Monday, July 01, 2002 7:20 PM
To: ktoyoda@xxxxxxxxxxxxxxxxxxx; Dave Crocker; iesg@xxxxxxxx
Subject: FW: CORRECTION: Last Call: SMTP Service Extension for Content
Negotiation to Proposed Standard
Please explain why you require a space in the RCPT
modifier; that is, why is the ABNF:
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
The text throughout the document uses
"CONNEG = REQUIRED"
"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:<June@xxxxxxxx> CONNEG = REQUIRED
S: 504 <June@xxxxxxxx> 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
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
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 CONNEG
are shown exactly like lines that aren't separated by CRLF such
S: 250-<June@xxxxxxxx> recipient ok
S: 250 CONNEG (&(image-file-structure=TIFF-minimal)
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: (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
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:<May@xxxxxxxx>
7 S: 250 <May@xxxxxxxx> sender ok
8 C: RCPT TO:<June@xxxxxxxx> CONNEG = REQUIRED
9 S: 250-<June@xxxxxxxx> 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
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.>>
From: owner-ietf-fax@xxxxxxxxxxxx [mailto:owner-ietf-fax@xxxxxxxxxxxx]On
Behalf Of The IESG
Sent: Monday, July 01, 2002 2:34 PM
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
iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by July 29, 2002.
Files can be obtained via