revisions to draft-ietf-fax-esmtp-conneg-02.txt

["Toyoda, Kiyoshi" <[e-mail]>]

[e-mail] wrote:
Date: Wed, 03 Jul 2002 20:56:21 -0700 (PDT)
>
>I'm afraid I'm coming to a very different conclusion. I think these discussions
>have conflated a bunch of different things: (1) Specification bugs that
>definitely need to be fixed, (2) A single protocol change that definitely
>should be made -- that of making conneg information and status identifiable as
>such in the command response, (3) A bunch of concerns about protocol details
>that aren't standing up to close inspection and which absent a clear consensus
>for change can remain as-is, and (4) A general concern about the many possible
>uses for this mechanism that has all of us engaging in futile speculation and
>which cannot possibly be dealt sensibly with in a specification without actual
>implementation and use experience.
>
>Of course (1) and (2) need to be fixed before proceeding. As for (3) and (4),
>well, this is why we have a standards process and not a rubber stamp.
>

We have revised the specification to fix (1) and (2),  and have put a copy at:

 <http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt>


Significant points which we changed are as blow.

1. Changed the expression of SYNTAX because the suggesitions below.

Dan Wing wrote:
>Further, your ABNF in section 5 does not permit any text
>after the "504" -- it only permits <CRLF>.

Keith Moore wrote:
>it's not appropriate to put literal response codes in the grammar,
>particularly the extended status codes which might actually need to
>vary more than is indicated here.
>
>much better to have something like:
>reply: initial-reply *(conneg-reply/other-reply) final-reply
>initial-reply: reply-code "-" [ status-code ] CRLF
>conneg-reply: reply-code "-" [ status-code " " ] "CONNEG" capability CRLF
>other-reply: reply-code "-" [ status-code ] *char CRLF
>final-reply: reply-code " " [ status-code ] CRLF


2. Changed the Example because the ploblem below.

Dan Wing wrote:
>Section 6, the examples, do not clearly show that the
>server isn't sending CRLF between the lines.
>


3. Changed the the last statement of section 4.2 because the
   problem below. Also, changed SYNTAX and REFERENCES to
   make RFC2534, RFC2879 and RFC2305 non-normative.

John C Klensin wrote:
>(iii) I can't reconcile the last statement of section 4.2:
>
>	If the server returns an EHLO 250 code without CONNEG
>	capabilities, the client MUST work as "a Simple Mode of
>	Facsimile Using Internet Mail" [RFC2305].
>
>With the assertion that this is a general facility, not limited
>to fax.   If it is a duck, let's call it a duck and be done with
>it.  And, if fax is sufficiently special that we need things
>like this, perhaps it is time to add something like NORELAY, or
>a FAX extension, to make it clear that what is happening is not
>normal SMTP.


4. Changed the word "target" to "server" in section 4.2 and 4.3.
   because the suggestion below.

Gregory Neil Shapiro wrote:
>- 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.



Most points which I changed are inline below.  They are also responses
to Wing-san, Shapiro-san, Moore-san and Klensin-san.


Dan Wing wrote:
>Please explain why you require a space in the RCPT
>modifier; that is, why is the ABNF:
>
>  "CONNEG ="
>
>instead of
>
>  "CONNEG" "="
>
>or simply
>
>  "CONNEG="

I changed it to "CONNEG=".

>
>
>In section 5, your the word "OPTIONAL" is mispelled.

corrected


>
>In section 5, is the only valid destination address supposed
>to be "Postmaster"?  The example in section 6 contradicts
>that.

No, it is not. There is "Forward-Path".
I add the following definition.

     domain = <<as per [ESMTP2]>>
     Forward-Path =<<as per [ESMTP2]>>


>
>
>The text throughout the document uses
>  "CONNEG = REQUIRED"
>and
>  "CONNEG = OPTIONAL"
>
>but section 5 says there isn't a space after "=".
>

I eliminated space.

>
>The text says:
>
>     The response strings for a temporary failure are
>     "404-4.3.3 CONNEG" and "404 5.3.3 CONNEG".
>
>which looks like a cut-and-paste error (4.3.3 -> 5.3.3).
>

Yes, I changed as below.
"404 5.3.3 CONNEG"  ->  "404 4.3.3 CONNEG"


>
>
>
>In section 5, your failure example is:
>
>
>     C: RCPT TO:<[e-mail]> CONNEG = REQUIRED
>     S: 504 <[e-mail]> recipient ok
>
>I believe the text "recipient ok" is inappropriate here.  Perhaps
>more appropriate would be "recipient okay, but CONNEG unavailable".

I changed it as below.

     C: RCPT TO:<[e-mail]> CONNEG=REQUIRED
     S: 504 <[e-mail]> conneg permanent failure

>
>Further, your ABNF in section 5 does not permit any text
>after the "504" -- it only permits <CRLF>.

I changed the expression of Reply syntax as below.

     Reply:
      initial-reply *conneg-reply final-reply

      initial-reply = reply-code "-" [ status-code ] [text] CRLF
                      ; text is usually intended for human users.
      conneg-reply = reply-code "-" [ status-code " " ] "CONNEG"
                     capability CRLF
      final-reply = reply-code " " [ status-code ] CRLF

      reply-code = 250/504/404
      status code = 2.1.5/5.3.3/4.3.3
      text = 1*<any character other than CR or LF>
      capability = <<as per [RFC2506], [RFC2533], [RFC2534]
                    and [RFC2879] >>


>
>
>I'm guessing section 5 is supposed to be ABNF, but as Dave
>is the author of ABNF and section 5 doesn't claim to be ABNF,
>I can't tell what it's supposed to be.  Can the document
>make this clearer?

I added the text blow to SYNTAX section.

5.   SYNTAX
     The syntax for a "Command with CONNEG" and "Reply",  using the
     ABNF notation of [RFC2234], is:


>
>
>Section 5 seems to prohibit multiline 504 and multiline
>404 responses, but such multiline responses are permitted
>by the underlying RFC2822 specification.  Is your specification
>purposely prohibiting multiline 504 and 404 responses by CONNEG-
>capable SMTP servers that receive CONNEG=REQUIRED or
>CONNEG=OPTIONAL ?

No, it does not.
I changed the expression of Reply syntax.


>
>Section 5 doesn't define the meaning of <domain>.

I added the definition.
     domain = <<as per [ESMTP2]>>
     Forward-Path =<<as per [ESMTP2]>>

>
>
>I am very unclear on the difference between a client
>specifying CONNEG=OPTIONAL versus a client specifying no CONNEG
>parameter at all.


The text "but the target does not support the CONNEG parameter" got
deleted in the paragraph below during revision.

     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.

The correct paragraph is below.

     If the client specifies "CONNEG=OPTIONAL" in the RCPT,
     but the server does not support the CONNEG parameter or can not
     return the recipient's capability temporarily,  the server MUST
     process the address and message as if the requested CONNEG
     capabilities had not been specified.

>
>
>You should cite the ENCHANCEDSTATUSCODES RFC.

I cited it.


>
>
>Section 6, the examples, do not clearly show that the
>server isn't sending CRLF between the lines.  Lines that are
>separated by CRLF such as
>
>
>     S: 250-ifax1.jp
>     S: 250-DSN
>     S: 250 CONNEG
>
>
>are shown exactly like lines that aren't separated by CRLF such
>as
>
>
>
>     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) )
>
>While this is described in the text of the document,
>the example isn't nearly clear enough.
>
>Please add text indicating that the example is broken into
>multiple lines for clarity in the document, but that the
>Server transmits only two CRLF lines for the above example:
>one CRLF at the first line and another CRLF at the last line
>and no CRLFs are sent in between.
>
>This is a serious interoperabilty issue.  The ABNF (or
>whatever is in section 5) isn't clear on this either.
>
>The unique way you have separated the Client and Server
>lines (using blank lines) doesn't help show that CRLF isn't
>sent on each line (which I'm guessing was the intent of
>this extra blank line, but the extra blank line was never
>explained in the document).
>
>
>
>My specific recommendation is that you change the
>example to:
>
>  6.   EXAMPLE
>
>     An example of ESMTP sequence with successful RCPT-TO response
>
>       1  S: 220 ifax1.jp IFAX
>       2  C: EHLO ifax1.jp
>       3  S: 250-ifax1.jp
>       4  S: 250-DSN
>       5  S: 250 CONNEG
>       6  C: MAIL FROM:<[e-mail]>
>       7  S: 250 <[e-mail]> sender ok
>       8  C: RCPT TO:<[e-mail]> CONNEG = REQUIRED
>       9  S: 250-<[e-mail]> recipient ok
>      10  S: 250 CONNEG (&(image-file-structure=TIFF-minimal)
>      11  S: (MRC-mode=0)(color=Binary)(|(&(dpi=204)
>      12  S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200)
>      13  S: (dpi-xyratio=[200/100,1]) )(&(dpi=400)
>      14  S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR])
>      15  S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85)
>      16  S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4])
>      17  S: (ua-media=stationery) )
>      18  C: DATA
>      19  S: 354 okay, send data
>      20  C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
>             Per:
>             (  image-file-structure=TIFF-minimal
>                dpi=400
>                image-coding=JBIG
>                size-x=2150
>              )
>             >>
>      21  S: 250 message accepted
>      22  C: QUIT
>      23  S: 221 goodbye
>
>      Note that line 9 is terminated with CRLF, but lines 10
>      through 16 are not terminated by CRLF -- they are only shown
>      wrapped in this document for clarity.  The next line that
>      has a CRLF is line 17.
>

I adopted the example which Wing-san recomended above.



Gregory Neil Shapiro wrote:
>- 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.

I changed the word "target" to "server" in section 4.2 and 4.3.


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

corrected.


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


I adopted the recomendation above.


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

corrected

>
>- Section 6 states:
>
>     An example of succssful RCPT-TO response when CONNEG-capable
>     server supports ENHANCEDSTATUSCODES.
>
>"successful" is spelled incorrectly.

corrected

>
>- Section 6 states:
>
>     An example of ESMTP sequence with parmanent failure RCPT-TO
>     response.
>
>"permanent" is spelled incorrectly.

corrected

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

I corrected as below.

     An example of ESMTP sequence with permanent failure RCPT
     response.

     S: 220 ifax1.jp IFAX

     C: EHLO ifax1.jp

     S: 250-ifax1.jp
     S: 250-DSN
     S: 250 CONNEG

     C: MAIL FROM:<[e-mail]>

     S: 250 <[e-mail]> sender ok

     C: RCPT TO:<[e-mail]> CONNEG=REQUIRED

     S: 504 <[e-mail]> conneg permanent failure

     C: QUIT

     S: 221 goodbye


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

corrected

>
>- Section 12 states:
>
>     Copyright (C) The Internet Society (2001).  All Rights
>     Reserved.
>
>Should this be updated to include 2002?

changed it to 2002




Keith Moore wrote:
>
>>
>>      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) /
>
>it's not appropriate to put literal response codes in the grammar,
>particularly the extended status codes which might actually need to
>vary more than is indicated here.
>
>much better to have something like:
>
>reply: initial-reply *(conneg-reply/other-reply) final-reply
>
>initial-reply: reply-code "-" [ status-code ] CRLF
>
>conneg-reply: reply-code "-" [ status-code " " ] "CONNEG" capability CRLF
>
>other-reply: reply-code "-" [ status-code ] *char CRLF
>
>final-reply: reply-code " " [ status-code ] CRLF
>
>>
>>       capability = <<as per [RFC2506], [RFC2533], [RFC2534]
>>                     and [RFC2879] >>

I cahnged Syntax of Reply as below.

     Reply:
      initial-reply *conneg-reply final-reply

      initial-reply = reply-code "-" [ status-code ] [text] CRLF
                      ; text is usually intended for human users.
      conneg-reply = reply-code "-" [ status-code " " ] "CONNEG"
                     capability CRLF
      final-reply = reply-code " " [ status-code ] CRLF

      reply-code = 250/504/404
      status code = 2.1.5/5.3.3/4.3.3
      text = 1*<any character other than CR or LF>
      capability = <<as per [RFC2506], [RFC2533], [RFC2534]
                    and [RFC2879] >>


>
>also TIFF-FX is not the name of the content-type,
>presumably it's application/tiff-fx or some such.

I changed TIFF-FX to image/tiff.

     C: <<RFC 2822 message with MIME Content-Type:image/tiff



John C Klensin wrote:
>
>(iii) I can't reconcile the last statement of section 4.2:
>
>	If the server returns an EHLO 250 code without CONNEG
>	capabilities, the client MUST work as "a Simple Mode of
>	Facsimile Using Internet Mail" [RFC2305].
>
>With the assertion that this is a general facility, not limited
>to fax.   If it is a duck, let's call it a duck and be done with
>it.  And, if fax is sufficiently special that we need things
>like this, perhaps it is time to add something like NORELAY, or
>a FAX extension, to make it clear that what is happening is not
>normal SMTP.

I changed the phrase to below.

     If the server returns an EHLO 250 code without CONNEG
     capabilities, the client MUST work as if it had not issued CONNEG
     parameter with RCPT.

>
>(v) Just as an editorial matter, but, in order to avoid
>unnecessary confusion, it would probably be helpful if the
>document adopted terminology consistent with RFC 2821 (and 821).
>E.g., there is no such command as "RCPT-TO", the name of the
>relevant command is "RCPT".

I changed RCPT-TO to RCPT.

Kiyoshi Toyoda