Subject: draft-ietf-fax-smtp-session-04.txt

From: Graham Klyne <[email-masked]>
Date: Wed, 09 Sep 1998 18:47:14 +0100

Dan,

More belated comments...

#g

>3.2.1.  Excessive Delays with Multiple MTAs
>
>   The cumulative delays of going through many MTAs will cause Session
>   delivery to fail (by falling back to normal store-and-forward).

Why?  What timeout is being contemplated here?

>   Proper configuration and deployment of SMTP servers will prevent this
>   problem.

[...]
>4.  New SMTP Verb STAT
>
>   One new SMTP verb is introduced with this extension.  The STAT verb
>   causes the SMTP server to respond with the Session delivery status of
>   all Session recipients.
>
>   An SMTP client MAY send the STAT command if it used the esmtp-keyword
>   SESSION on one of its RCPT commands, but the SMTP client is not
>   required to use the STAT verb.  SMTP servers which implement the
>   SESSION extension MUST implement the STAT verb.
>
>   The SMTP client MUST NOT send the STAT command unless all of the
>   following are true:  (1) the SMTP client sent a RCPT command with the
>   esmtp-keyword SESSION; (2) the SMTP server sent a positive response
>   to that RCPT command; (3) the SMTP client has finished sending the
>   message body and sent the end of mail data indicator ("." or BDAT
>   LAST).  If the SMTP client sends the STAT command when not all of the
.........^ ", and received a response from the server"?

>   above conditions are met, the SMTP server MUST send a response code
>   of 503.

[...]
>4.1.  Format of STAT Response
>
>   The SMTP server's positive response to the STAT command is a
>   multiline SMTP response.  Each line contains information on each
>   Session recipient, in the order specified by the SMTP client.
>
>   If the SMTP server is making a negative response to the STAT command
>   the response should be a 5xx response code and follow the normal SMTP
>   rules for multiple line responses.  There is no specific format of
>   5xx responses.
>
>   The syntax of the positive response must be parsable by an SMTP
>   client.  Using the notation described in [RFC2234], the syntax is:
>
>      stat-response  = *( "250-" [cmd-status SP] resp-line CR LF )
>                          "250 " [cmd-status SP] resp-line CR LF
..............................................<>
Should these be SP or LWSP ?  (Also below.)

>
>      resp-line      = forward-path SP session-status
>                       [SP "by=" mta-hostname]
>
>      session-status = "delivered" terminal /
>                       "in-progress" SP prog-value /
>                       "queued" terminal /
>                       "failed" terminal
>
>      terminal       = SP trans-status [SP trans-id]
>
>      trans-status   = "status=" status-code
>
>      trans-id       = "trans=" transaction
>
>      status-code    = <"status-code" from [RFC1893], with
>                        extensions defined in [REPORT-EXTENSIONS]>
>
>      prog-value     = sent-count "/" total-count
>
>      sent-count     = 1*DIGIT
>
>      total-count    = 1*DIGIT
>
>      mta-hostname   = *( ALPHA / DIGIT / "." / "-" / "_" )
........................^
>
>      transaction    = *( ALPHA / DIGIT / "." / "-" / "_" )
........................^
I think the above should be "1*(...", not just "*(...".

>      cmd-status     = "2.5.0" <only present if SMTP server supports
>                                [RFC2034]>
.................................<------->
This reference is missing fro the references section.

>
>      forward-path   = <forward-path as specified in the RCPT command,
>                        including "<" and ">" characters>
>
>   The <session-status> can be spelled in any combination of uppercase
>   and lowercase letters.  The meaning of the various values are
>   as follows:

I think this is redundant, in that case insensitivity is implied by
RFC2234.  (It may still be a good thing to mention it, though.)

>   "delivered"    Session delivery was successful.  Message was
>                  delivered to the recipient immediately.  This is a
>                  terminal value.  This can optionally be followed
>                  with <trans-id>.
>
>   "in-progress"  Session delivery has not yet completed.  A STAT
>                  command issued later will show final status of this
........................................<-------> "may show the" ?

>                  message.  This is the only non-terminal value.  This
>                  must be followed by <prog-value>.
>
[...]
>   <trans-id> is used to provide the client with a unique transaction
>   number to associate with each delivery.  This can be useful for
>   accounting or tracing messages.  This number need only be unique
>   for that MTA, it doesn't need to be world-unique.
........<------>  Which MTA?

[...]
>   If an SMTP client sends a STAT command and the SMTP server has
>   already informed the SMTP client (in the response to a previous
>   STAT command) that all recipients had terminal values, the SMTP
>   server MAY return a 503 reply.
...........................^
I suggest inserting a brief description of the meaning of '503' here.

[...]
>4.3.  Timing Considerations
>
>   The SMTP server SHOULD respond to a STAT command no later than 60
>   seconds after a STAT command is received.  After 120 seconds an SMTP
>   client MAY assume the connection to the SMTP server is broken.
>
>   To prevent excessive network activity by an SMTP client querying
>   delivery status "too often", the SMTP server may delay responding to
>   a client's STAT command.  Such a delay MUST NOT exceed 10 seconds.

I would strengthen this somewhat.  Maybe something like:
"To prevent excessive network activity by an SMTP client querying delivery
status "too often", the SMTP server should delay responding to a client's
STAT command if it follows too soon after a previous STAT command for the
same message.  ..."

>   Due to the delays inherent in establishing connections with each MTA
>   in the SMTP "path", SMTP servers that implement the Session extension
>   SHOULD also implement [RFC2197], and SMTP clients SHOULD use
.........................^ "command pipelining"

>   pipelining if available.
>
>5.  Security Considerations
>
>   This section describes new security vulnerabilities that are
>   introduced with this SMTP extension.  Security vulnerabilities
>   that are inherient to SMTP itself are not described.
..................# (typo)

[...]
>8.  References
[...]
>   [RFC2197] N. Freed, "SMTP Service Extension for Command Pipelining",
>   RFC 2197, September 1997.  .in -5
...............................<---->  Typo, I think.

------------
Graham Klyne
([email-masked])