ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
Date: Wed, 03 Jul 2002 20:56:21 -0700 (PDT)
I'm afraid I'm coming to a very different conclusion. I think these discussions
have conflated a bunch of different things: (1) Specification bugs that
definitely need to be fixed, (2) A single protocol change that definitely
should be made -- that of making conneg information and status identifiable as
such in the command response, (3) A bunch of concerns about protocol details
that aren't standing up to close inspection and which absent a clear consensus
for change can remain as-is, and (4) A general concern about the many possible
uses for this mechanism that has all of us engaging in futile speculation and
which cannot possibly be dealt sensibly with in a specification without actual
implementation and use experience.
Of course (1) and (2) need to be fixed before proceeding. As for (3) and (4),
well, this is why we have a standards process and not a rubber stamp.
We have revised the specification to fix (1) and (2), and have put a copy at:
<http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt>
Significant points which we changed are as blow.
1. Changed the expression of SYNTAX because the suggesitions below.
Dan Wing wrote:
Further, your ABNF in section 5 does not permit any text
after the "504" -- it only permits <CRLF>.
Keith Moore wrote:
it's not appropriate to put literal response codes in the grammar,
particularly the extended status codes which might actually need to
vary more than is indicated here.
much better to have something like:
reply: initial-reply *(conneg-reply/other-reply) final-reply
initial-reply: reply-code "-" [ status-code ] CRLF
conneg-reply: reply-code "-" [ status-code " " ] "CONNEG" capability CRLF
other-reply: reply-code "-" [ status-code ] *char CRLF
final-reply: reply-code " " [ status-code ] CRLF
2. Changed the Example because the ploblem below.
Dan Wing wrote:
Section 6, the examples, do not clearly show that the
server isn't sending CRLF between the lines.
3. Changed the the last statement of section 4.2 because the
problem below. Also, changed SYNTAX and REFERENCES to
make RFC2534, RFC2879 and RFC2305 non-normative.
John C Klensin wrote:
(iii) I can't reconcile the last statement of section 4.2:
If the server returns an EHLO 250 code without CONNEG
capabilities, the client MUST work as "a Simple Mode of
Facsimile Using Internet Mail" [RFC2305].
With the assertion that this is a general facility, not limited
to fax. If it is a duck, let's call it a duck and be done with
it. And, if fax is sufficiently special that we need things
like this, perhaps it is time to add something like NORELAY, or
a FAX extension, to make it clear that what is happening is not
normal SMTP.
4. Changed the word "target" to "server" in section 4.2 and 4.3.
because the suggestion below.
Gregory Neil Shapiro wrote:
- It became increasingly difficult to understand as the draft inconsistently
refers to the server as both "server" and "target", at times in the same
section. It makes it look like there is a third party ("client",
"server", and "target"). "server" should be used throughout.
Most points which I changed are inline below. They are also responses
to Wing-san, Shapiro-san, Moore-san and Klensin-san.
Dan Wing wrote:
Please explain why you require a space in the RCPT
modifier; that is, why is the ABNF:
"CONNEG ="
instead of
"CONNEG" "="
or simply
"CONNEG="
I changed it to "CONNEG=".
In section 5, your the word "OPTIONAL" is mispelled.
corrected
In section 5, is the only valid destination address supposed
to be "Postmaster"? The example in section 6 contradicts
that.
No, it is not. There is "Forward-Path".
I add the following definition.
domain = <<as per [ESMTP2]>>
Forward-Path =<<as per [ESMTP2]>>
The text throughout the document uses
"CONNEG = REQUIRED"
and
"CONNEG = OPTIONAL"
but section 5 says there isn't a space after "=".
I eliminated space.
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).
Yes, I changed as below.
"404 5.3.3 CONNEG" -> "404 4.3.3 CONNEG"
In section 5, your failure example is:
C: RCPT TO:<June(_at_)ifax1(_dot_)jp> CONNEG = REQUIRED
S: 504 <June(_at_)ifax1(_dot_)jp> recipient ok
I believe the text "recipient ok" is inappropriate here. Perhaps
more appropriate would be "recipient okay, but CONNEG unavailable".
I changed it as below.
C: RCPT TO:<June(_at_)ifax1(_dot_)jp> CONNEG=REQUIRED
S: 504 <June(_at_)ifax1(_dot_)jp> conneg permanent failure
Further, your ABNF in section 5 does not permit any text
after the "504" -- it only permits <CRLF>.
I changed the expression of Reply syntax as below.
Reply:
initial-reply *conneg-reply final-reply
initial-reply = reply-code "-" [ status-code ] [text] CRLF
; text is usually intended for human users.
conneg-reply = reply-code "-" [ status-code " " ] "CONNEG"
capability CRLF
final-reply = reply-code " " [ status-code ] CRLF
reply-code = 250/504/404
status code = 2.1.5/5.3.3/4.3.3
text = 1*<any character other than CR or LF>
capability = <<as per [RFC2506], [RFC2533], [RFC2534]
and [RFC2879] >>
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?
I added the text blow to SYNTAX section.
5. SYNTAX
The syntax for a "Command with CONNEG" and "Reply", using the
ABNF notation of [RFC2234], is:
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 ?
No, it does not.
I changed the expression of Reply syntax.
Section 5 doesn't define the meaning of <domain>.
I added the definition.
domain = <<as per [ESMTP2]>>
Forward-Path =<<as per [ESMTP2]>>
I am very unclear on the difference between a client
specifying CONNEG=OPTIONAL versus a client specifying no CONNEG
parameter at all.
The text "but the target does not support the CONNEG parameter" got
deleted in the paragraph below during revision.
If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the
target MUST process the address and message as if the requested
CONNEG capabilities had not been specified.
The correct paragraph is below.
If the client specifies "CONNEG=OPTIONAL" in the RCPT,
but the server does not support the CONNEG parameter or can not
return the recipient's capability temporarily, the server MUST
process the address and message as if the requested CONNEG
capabilities had not been specified.
You should cite the ENCHANCEDSTATUSCODES RFC.
I cited it.
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-<June(_at_)ifax1(_dot_)jp> 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:<May(_at_)ifax2(_dot_)jp>
7 S: 250 <May(_at_)ifax2(_dot_)jp> sender ok
8 C: RCPT TO:<June(_at_)ifax1(_dot_)jp> CONNEG = REQUIRED
9 S: 250-<June(_at_)ifax1(_dot_)jp> 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.
I adopted the example which Wing-san recomended above.
Gregory Neil Shapiro wrote:
- It became increasingly difficult to understand as the draft inconsistently
refers to the server as both "server" and "target", at times in the same
section. It makes it look like there is a third party ("client",
"server", and "target"). "server" should be used throughout.
I changed the word "target" to "server" in section 4.2 and 4.3.
- Section 4.3 states:
If the target support the CONNEG parameter, but it can not return
the recepient's capability temporarily, the target MUST reject the
"recipient's" is spelled incorrectly.
corrected.
- Section 4.3 states:
Regardless of the value of the parameter, if the target does
support the CONNEG parameter, then it MUST issue a 250 reply,
followed by the capabilities of the target that is specified by
the RCPT-TO address.
I think this should be changed to:
Regardless of the value of the parameter, if the target does
support the CONNEG parameter and the address is acceptable,
then it MUST issue a 250 reply, followed by the capabilities of
the target that is specified by the RCPT-TO address.
Note the addition of "and the address is acceptable". The draft should not
specify that the command "MUST issue a 250 reply" as there may be other
reasons outside of the scope of CONNEG not to do so.
I adopted the recomendation above.
- Section 5 states:
Command with "CONNEG":
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>"
/ Forward-Path) (SP "CONNEG =" ("REQUIRED" /
"OPTIOANL") CRLF
* Why is postmaster specifically listed in the syntax?
* "OPTIONAL" is spelled wrong in the syntax
corrected
- Section 6 states:
An example of succssful RCPT-TO response when CONNEG-capable
server supports ENHANCEDSTATUSCODES.
"successful" is spelled incorrectly.
corrected
- Section 6 states:
An example of ESMTP sequence with parmanent failure RCPT-TO
response.
"permanent" is spelled incorrectly.
corrected
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
C: MAIL FROM:<May(_at_)ifax2(_dot_)jp>
S: 250 <May(_at_)ifax2(_dot_)jp> sender ok
C: RCPT TO:<June(_at_)ifax1(_dot_)jp> CONNEG = REQUIRED
The comment above should probably indicate that this is a broken client.
The client shouldn't be sending the "CONNEG = REQUIRED" since CONNEG was
not given in reply to the EHLO command.
I corrected as below.
An example of ESMTP sequence with permanent failure RCPT
response.
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
S: 250 CONNEG
C: MAIL FROM:<May(_at_)ifax2(_dot_)jp>
S: 250 <May(_at_)ifax2(_dot_)jp> sender ok
C: RCPT TO:<June(_at_)ifax1(_dot_)jp> CONNEG=REQUIRED
S: 504 <June(_at_)ifax1(_dot_)jp> conneg permanent failure
C: QUIT
S: 221 goodbye
- Section 7 states:
On publicatiom of this document by the RFC Editor, the IANA
shall register the Content_Negotiation ESMTP extension defined
in section 3.
"publication" is spelled incorrectly.
corrected
- Section 12 states:
Copyright (C) The Internet Society (2001). All Rights
Reserved.
Should this be updated to include 2002?
changed it to 2002
Keith Moore wrote:
Reply:
( ("250-" CRLF) *("250-CONNEG" capability CRLF)
("250 CONNEG" capability CRLF) )/
( ("250-2.1.5" CRLF)
*("250-2.1.5 CONNEG" capability CRLF)
("250 2.1.5 CONNEG" capability CRLF) )/
("504" CRLF) /
("504 5.3.3" CRLF) /
("404" CRLF) /
("404 4.3.3" CRLF) /
it's not appropriate to put literal response codes in the grammar,
particularly the extended status codes which might actually need to
vary more than is indicated here.
much better to have something like:
reply: initial-reply *(conneg-reply/other-reply) final-reply
initial-reply: reply-code "-" [ status-code ] CRLF
conneg-reply: reply-code "-" [ status-code " " ] "CONNEG" capability CRLF
other-reply: reply-code "-" [ status-code ] *char CRLF
final-reply: reply-code " " [ status-code ] CRLF
capability = <<as per [RFC2506], [RFC2533], [RFC2534]
and [RFC2879] >>
I cahnged Syntax of Reply as below.
Reply:
initial-reply *conneg-reply final-reply
initial-reply = reply-code "-" [ status-code ] [text] CRLF
; text is usually intended for human users.
conneg-reply = reply-code "-" [ status-code " " ] "CONNEG"
capability CRLF
final-reply = reply-code " " [ status-code ] CRLF
reply-code = 250/504/404
status code = 2.1.5/5.3.3/4.3.3
text = 1*<any character other than CR or LF>
capability = <<as per [RFC2506], [RFC2533], [RFC2534]
and [RFC2879] >>
also TIFF-FX is not the name of the content-type,
presumably it's application/tiff-fx or some such.
I changed TIFF-FX to image/tiff.
C: <<RFC 2822 message with MIME Content-Type:image/tiff
John C Klensin wrote:
(iii) I can't reconcile the last statement of section 4.2:
If the server returns an EHLO 250 code without CONNEG
capabilities, the client MUST work as "a Simple Mode of
Facsimile Using Internet Mail" [RFC2305].
With the assertion that this is a general facility, not limited
to fax. If it is a duck, let's call it a duck and be done with
it. And, if fax is sufficiently special that we need things
like this, perhaps it is time to add something like NORELAY, or
a FAX extension, to make it clear that what is happening is not
normal SMTP.
I changed the phrase to below.
If the server returns an EHLO 250 code without CONNEG
capabilities, the client MUST work as if it had not issued CONNEG
parameter with RCPT.
(v) Just as an editorial matter, but, in order to avoid
unnecessary confusion, it would probably be helpful if the
document adopted terminology consistent with RFC 2821 (and 821).
E.g., there is no such command as "RCPT-TO", the name of the
relevant command is "RCPT".
I changed RCPT-TO to RCPT.
Kiyoshi Toyoda