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

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

Folks,

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.

[email-masked] wrote:
>Subject: I-D ACTION:draft-ietf-fax-esmtp-conneg-00.txt
>Date: Wed, 27 Jun 2001 07:03:00 -0400
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Internet Fax Working Group of the IETF.
>
>	Title		: SMTP Service Extension for Content Negotiation of 
>                          Internet Fax
>	Author(s)	: K. Toyoda, D. Crocker
>	Filename	: draft-ietf-fax-esmtp-conneg-00.txt
>	Pages		: 
>	Date		: 26-Jun-01
>	
>This document defines a content negotiation SMTP
>service extension [ESMTP1, ESMTP2] whereby an SMTP
>client may request information about content
>capabilities of the target device or system that is
>serviced by an SMTP server.  The SMTP server may report
>the target's content capabilities back to the client.
>This process emulates a classic facsimile start-of-
>session capabilities negotiation.  This service
>extension is primarily intended for 'direct' SMTP
>transfers, although relayed scenarios are permitted.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-00.txt
>

Kiyoshi Toyoda

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Nov 2001 17:45:28 -0800

> 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

---

From: Graham Klyne <[email-masked]>
Date: Thu, 15 Nov 2001 11:47:47 +0000

>(RFC2879)?  I thought CONNEG would allow wrapping anywhere

Well, almost anywhere.  But not in the middle of a token, for example.

The relevant text from RFC 2533, section 4.1, is:

    (Subject to constraints imposed by the protocol that carries a
    feature predicate, whitespace characters may appear between any pair
    of syntax elements or literals that appear on the right hand side of
    these productions.)

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Nov 2001 07:57:42 -0800

>     of syntax elements or literals that appear on the right hand side of

Thanks.  I assume tokens aren't limited in length, but certainly no sane
defintion of tokens would exceed 1024 bytes, yes?

Anyway, the "\" line-continuator should be removed from esmtp-conneg.

-d