Subject: Re: any comments to esmtp-conneg-00 draft?

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Fri, 16 Nov 2001 14:57:57 +0900

Wing-san,

Thank you very much for the comments and suggestions.
I comment in the text below and attached revised draft.

Dave-san, would you check the revised draft?

regards,

Dan Wing wrote:
>There is inconsistency between the term "target", which I
>believe means the identity specified in the RCPT TO, and
>the "server", which has to be the MTA which is listening 
>on TCP port 25.
>
>This should be clarified.  Specific changes are below:
>

I agree. I will change the text as your suggestion.

>
>I found this wording very difficult:
>
>
>          The response to a CONNEG RCPT-TO request will be
>     multi-line.  For successful (250) responses, at least
>     the first line of the response is for RCPT-TO
>     information other than CONNEG.  Additional response
>     lines are for CONNEG.    In order to avoid problems due
>     to variations in line buffer sizes, the total
>     parametric listing must be provided as a series of
>     lines, each beginning with "250-CONNEG" except for the
>     last line, which is "250 CONNEG".
>          
>
>better would be:
>
>           Successful responses to CONNEG RCPT-TO 
>     requests will always be multiple SMTP lines.  The
>     first line is the normal RCPT-TO response, and 
>     subsequent lines beginning with the exact string
>     "250-CONNEG " and "250 CONNEG " are the CONNEG responses,
>     and if the SMTP server supports ENHANCEDSTATUSCODES,
>     the exact strings are "250-2.5.0 CONNEG " and 
>     "250 2.5.0 CONNEG ".
>   
>Perhaps a combination of the wording of the original paragraph
>and my changes would be even better.
>

I merged the word of the original paragraph regarding "last line"
and changed the response for ENHANCEDSTATUSCODES from "2.5.0" to
"2.1.5" according to fax implementoer's guide.

           Successful responses to CONNEG RCPT-TO 
     requests will always be multiple SMTP lines.  The
     first line is the normal RCPT-TO response, and 
     subsequent lines beginning with the exact string
     "250-CONNEG " and "250 CONNEG " are the CONNEG responses.
     The last line begins with "250 CONNEG ".  if the SMTP 
     server supports ENHANCEDSTATUSCODES, the exact strings 
     are "250-2.1.5 CONNEG " and "250 2.1.5 CONNEG ".

>
>
>I think the backslash idea is risky, and unnecessary:
>
>          An alternative approach for lengthy CONNEG data
>     would be to fit the entire parameter list into one,
>     very long virtual line, using backslash ("\") escapes
>     at the end of each physical line.  This risks the
>     buffer overflow problem, cited above.
>          
>Is it really necessary per the definitions of CONNEG 
>(RFC2879)?  I thought CONNEG would allow wrapping anywhere
>you want.
>
>How about simply saying "All CONNEG-capable clients and
>CONNEG-capable servers MUST be able to successfully process
>CONNEG lines that are up to 1024 characters long, as required
>by RFC2821."

It is a good idea. I adopt your suggestion. But, I think RFC2821 
requires that client and server MUST be able to process lines 
that are up to 512 characters.

>
>Section 4 needs to contain ABNF syntax for this extension,
>especially the rules for how the text is supposed to be 
>interpreted.  VERY few aspects of SMTP use more than the
>three-character response code and the ENHANCEDSTATUSCODES.

I made syntax. Please check the attached file.

>
>
>An example showing a CONNEG-capable server that also 
>supports ENHANCEDSTATUSCODES needs to be added, or at 
>least discussed.  Which goes first -- the CONNEG text
>or the ENHANCEDSTATUSCODES tuples?

I added the sample for ENHANCEDSTATUSCODES in the draft.

Kiyoshi Toyoda