Subject: draft-ietf-fax-esmtp-conneg-02.txt

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Thu, 20 Jun 2002 13:42:23 +0900

Freed-san,

I found that I made a mistake about draft in the e-mail which I 
sent on 14th June. I attached a premature draft in that e-mail.  
So, my comments below "--Original Message--" was inconsistent 
with the attached draft. I am sorry to bother you.

Please review the draft which I attached in this e-mail with
my comments below. It is the correct one.

-----Original Message-----
From: "Toyoda, Kiyoshi" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Revised draft -02 according to AD review comments on 
draft-ietf-fax-esmtp-conneg-01.txt
Date: Fri, 14 Jun 2002 17:10:18 +0900

Freed-san,

Dave-san and I revised a ESMTP-CONNEG draft according to your suggestion.
I comment in the following text and attach the revised draft.
Would you comment and suggest us?

[email-masked] wrote:
>Let's start with an obvious document issue, easily fixed: The IANA
>considerations section. It currently says "This memo is not intended to create
>any new issues for IANA." However, the document's primary goal is to define an
>ESMTP extension, and registration of ESMTP extensions is an IANA activity. As
>such, I suggest this section be changed to read "On publicatioj of this
>document by the RFC Editor the IANA shall register the Content_Negotiation
>ESMTP extension defined in section 2."

We changed this section according to the suggestion above .

>
>Another minor document issue is that the RFC Editor has a new policy that
>references must be separated into normative and informative groups. In this
>case I think there is effectively no separation: All three of the references
>here appear normative to me. So the thing to do is change the title of section
>9 to "NORMATIVE REFERENCES".

We changed the title of this section according to the suggestion above .

>
>Another document issue is that this document begins with a SUMMARY but has no
>ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and
>INTRODUCTION section in all new RFCs. I would suggest keeping the current
>SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the
>ABSTRACT but adding some additional background information if possible.

We kept SUMMARY as the ABSTRACT and wrote a new INTRODUCTION.

>
>On to security considerations. What's there seems entirely appropriate.
>However, there's are two other security considerations I believe deserve
>mention: The possibility that a vulnerability will be disclosed by the
>mechanism and the possibility of tampering with the result the mechanism
>returns.
>
>The first specific case that concerns me is that of a capability that is
>typically handled by, say, a plugin that has been found to contain a security
>vulnerability. Disclosure of support for this capability becomes tantamount to
>disclosing a vulnerability.

We added some text for this section.

>
>The second case is one where a man in the middle changes the capabilities
>associated with a given recipient. Here's a somewhat fanciful example: Suppose
>the sender knows the recipient has the ability to view color documents so they
>mark some things in red in what is otherwise a black and white document. But
>someone interferes with the returned capabilities, making them say the
>recipient only supports black and white. The document is duly downgraded, with
>the result that the recipient doesn't see what the sender marked. (Of course
>the man in the middle could have tampered with the document itself, but
>modifying a document on the fly is a much more difficult proposition.)

We added the paragraph above into the security considerations section.

>
>I'm not suggesting that this facility be changed to address these issues,
>merely that they be mentioned in the security considerations section.
>
>Next up is failure modes. The model defined here seems simple enough: Client
>asks server for capabilities for a given recipient and the server either
>returns those capabilities or fails with a CONNEG-specific error code.
>
>I wonder, however, if this isn't too simple. A server may have no trouble
>delivering mail to a given recipient but might be unable to return that
>recipient's capabilities. And this could be either a temporary or permanent
>failure: The directory containing this information could be offline, or it
>could be the case that this information simply isn't available for this
>particular recipient.
>
>Of course a client that receives a 504 can always retry the recipient without
>the CONNEG parameter if it is willing to operate in the absence of capability
>information. But it may want to take different actions depending on whether the 
>failure is temporary or permanent: I could easily see sending some sort of
>default for a permanent failure while waiting to retry in the even of a
>temporary failure.
>
>I therefore suggest that an additional 404 status code be defined that can be
>returned when the server experiences a temporary failure getting capability
>information.

We defined 404 status code in the first paragraph of chapter 4.3. 

>
>The unconditional use of a failure code when capabilities aren't available also
>concerns me. While it is true the client can simply reissue the RCPT TO without
>the CONNEG parameter, handling this case effectively stalls the SMTP dialogue.
>(That is, the client has to wait for the response to the RCPT TO before it
>knows how to proceed.) And dialogue stalls are a significant operational issue
>in practice. I therefore suggest that the mechanism be changed to allow a
>CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL.
>The REQUIRED value would result in the same behavior currently described in the
>document. The OPTIONAL case, however, would instruct the server to proceed
>normally and return a _success_ status when the capabilities aren't available.
>A corresponding 2xx code would need to be defined for this case.

We defined "REQUIRED" and "OPTIONAL" as the parameter value in chapter 4.1.

In the case of "OPTIONAL", I defined the target action as below. This is the
third paragraph in chapter 4.3. 

     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.

>
>This document also fails to specify what enhanced status code should be
>returned in the event the server is unable to return capabilities information.
>Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not
>capable of selected feature. I also note in passing that there are no examples
>of CONNEG failures in the examples section. Some examples of this sort need to
>be added.

We defined enhanced status code in the case of false return to RCPT-TO CONNEG.
The paragrapg below is the fifth one in chapter 4.3.

     If the SMTP server supports ENHANCEDSTATUSCODES, the response 
     strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5 
     CONNEG". The response strings for indicating a permanent 
     failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG". 
     The response strings for a temporary failure are "404-4.3.3 
     CONNEG" and "404 5.3.3 CONNEG".

And some examples of CONNEG failure are added to chapter 6.

>
>Another interesting case that could arise in practice is where a server is
>configured to require authentication, integrity, or privacy services before
>capability information can be returned. I think the document needs to discuss
>this case, saying that if such requirements have not been met the CONNEG
>extension should not be offered in the EHLO response. (Note that successful
>security negotiation already involves repeating EHLO.)

We added the paragraph above into the security considerations section.

>
>Although several examples of returned capabilities are shown, the document
>isn't very specific about how capabilities have to be formatted. In particular,
>I'd expect to see capabilities often stored as a single string without any line
>breaks. Some advice on how to take such a string and format it for inclusion in
>the reponse seems warranted.

We defined how capabilities have to be formatted in the sixth paragraph
of chapter 4.3. Line breaks should not been inserted if CONNEGFAX lines is 
less than 512. I changed the sample according this rule.

>
>According to this document the only capabilities that can be returned are those
>defined in RFC 2879, which is FAX-specific. I realize this document is a
>product of the FAX WG, but is this really appropriate? Should more general
>capabilites return be allowed? And if not, shouldn't this extension be called
>FAXCONNEG or something similar?

We believe that the mechanisms is quite general and that we should encourage 
its use for more than facscimile over the Internet.  So we changed the 
requirement in section 4 for more general use of SMTP CONNEG as below.

      The contents of the capability listing MUST conform to
      [RFC2506], [RFC2533] and [RFC2534], and MAY be used to emulate
      services, such as the  facsimile start-of-session capabilities
      negotiation as described in "Content Feature Schema for
      Internet Fax".  [RFC2879]

>
>Finally, this document makes passing reference to "use in relay scenarios". I
>think some elaboration of this might be in order. In particular, I see at least
>two scenarios that involve relaying: One where a server knows it will
>subsequently relay the message but offers up capability information by proxy,
>and another where the client is an intermediary service with message
>downgrading capabilities.

We've added a small amount of text to the last sentence in the abstract 
and the last sentence in section 1.
 
The text describes "direct" use.  This should make the idea of relaying 
work as an extension to direct exchange. We believe that the document 
does not need more about "use in relay scenarios".

Best regards,

Kiyoshi Toyoda

---

From: [email-masked]
Date: Thu, 20 Jun 2002 10:39:51 -0700 (PDT)

> with the attached draft. I am sorry to bother you.

That's OK -- it was still on my to-do list.

> my comments below. It is the correct one.

I've reviewed it, and I believe all the technical points I raised have
been addressed. There are some wording changes I'd like to see done but
that can be handled during the last call.

So please go ahead a post the revised draft. I will then ask for it
to be last called.

				Ned

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Mon, 24 Jun 2002 13:05:21 +0900

Freed-san,

Thank you very much for your review.
I posted the revised draft just now.

Kiyoshi Toyoda