RE: any comments to esmtp-conneg-00 draft?

> Have you any comments to esmtp-conneg-00 draft? 
> This draft will be expired on 12/01. So, I would like to submit
> a new draft as esmtp-conneg-01 until 11/21. If there is no comment,
> I will submit it as it is.

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:


Section 3 says:

          If the client issues the CONNEG parameter with
     RCPT-TO, then it MUST honor the capabilities specified
     in the CONNEG RCPT-TO reply, and transform data that is
     sent, so that the target can accept the data. The
     client SHOULD transform the data to the "highest" level
     of capability of the server.
     
Please maintain consistency of terms by changing last
line to:

     of capability of the target.


Also, for the same reason, please change:

          If the client specifies CONNEG in the RCPT-TO, but
     the server does not support the CONNEG parameter, the
     server MUST reject the RCPT-TO command with a 504
     reply.

to:

          If the client specifies CONNEG in the RCPT-TO, but
     the target does not support the CONNEG parameter, ...


and change from:

          If the server does support the CONNEG parameter,
     then it MUST issue a 250 reply, followed by its
     capabilities of the target that is specified by the
     RCPT-TO address.

to:

          If the target does support the CONNEG parameter,
     then it MUST issue a 250 reply, followed by its
     capabilities of the target that is specified by the
     RCPT-TO address.
     




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 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."




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.


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?

-d