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

[Gregory Neil Shapiro <[e-mail]>]

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:<[e-mail]> 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-<[e-mail]> 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-<[e-mail]> 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<[e-mail]> 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:<[e-mail]>
     S: 250 <[e-mail]> sender ok
     C: RCPT TO:<[e-mail]> 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:<[e-mail]> CONNEG = REQUIRED
     S: 404 <[e-mail]> 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?