Some comments regarding draft-ietf-fax-esmtp-conneg-02.txt:
- 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.
- 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.
- Section 4.3 states:
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.
If the server MUST ignore the CONNEG capabilities, then why should the
client even both sending it? I think this MUST should be a MAY.
- 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.
- Section 4.3 states:
If the SMTP server supports ENHANCEDSTATUSCODES, the response
strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5
CONNEG". The response strings for indicating a permanent
failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG".
The response strings for a temporary failure are "404-4.3.3
CONNEG" and "404 5.3.3 CONNEG".
^^^^^
That last enhanced status code should be 4.3.3, not 5.3.3.
- 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
* Why are spaces required around the CONNEG, the =, and the REQUIRED or
OPTIONAL? In all other ESMTP RCPT extensions, spaces separate
extensions. As an implementor, I would prefer "CONNEG=REQUIRED", not
"CONNEG = REQUIRED".
- Section 5 states:
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) /
The syntax shown for replies does not allow for any text after the SMTP
code. E.g., this would be illegal according to the draft syntax:
250-Recipient Ok
250 CONNEG ....
As the only thing the syntax allows to follow the 250- is a CRLF.
This applies for all of the replies, not just the 250 case.
Note that all of draft examples below break the rules set out by the
syntax for replies.
- Section 6 states:
C: RCPT TO:<June@ifax1.jp> CONNEG = REQUIRED
Again, the spaces make this difficult to parse given that all other ESMTP
arguments will not have spaces between the key and value.
- Section 6 states:
S: 250-<June@ifax1.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) )
That makes it look like the CONNEG response spans 8 lines. If that's the
case, any SMTP client should reject it as it doesn't use proper SMTP
continuation. This should be:
S: 250-<June@ifax1.jp> recipient ok
S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
S: 250-CONNEG (MRC-mode=0)(color=Binary)(|(&(dpi=204)
S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) )(&(dpi=200)
S: 250-CONNEG (dpi-xyratio=[200/100,1]) )(&(dpi=400)
S: 250-CONNEG (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR])
S: 250-CONNEG (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85)
S: 250-CONNEG (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4])
S: 250 CONNEG (ua-media=stationery) )
- Section 6 states:
An example of succssful RCPT-TO response when CONNEG-capable
server supports ENHANCEDSTATUSCODES.
"successful" is spelled incorrectly.
S: 250-2.1.5<June@ifax1.jp> recipient ok
S: 250 2.1.5 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) )
Again, the same comment as above.
- Section 6 states:
An example of ESMTP sequence with parmanent failure RCPT-TO
response.
"permanent" is spelled incorrectly.
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
C: MAIL FROM:<May@ifax2.jp>
S: 250 <May@ifax2.jp> sender ok
C: RCPT TO:<June@ifax1.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.
Also, this is invalid -- the reply to the EHLO command doesn't end the
continuation. It should be:
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250 DSN
Note the DSN line is "250 DSN" instead of "250-DSN" as shown in the
example.
- Section 6 states:
An example of an ESMTP sequence with temporary failure RCPT-TO
response when the value of parameter is "REQUIRED":
...
C: RCPT TO:<June@ifax1.jp> CONNEG = REQUIRED
S: 404 <June@ifax1.jp> recipient ok
Should the text for a '404' be 'recipient ok'? Perhaps, it should be
'conneg temporary failure'.
- 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.
- Section 12 states:
Copyright (C) The Internet Society (2001). All Rights
Reserved.
Should this be updated to include 2002?