Revised draft -02 according to AD review comments on draft-ietf-fax-esmtp-conneg-01.txt
"Toyoda, Kiyoshi" <[email protected]>
| Newsgroups | gmane.ietf.fax |
|---|---|
| Message-ID | <[email protected]> |
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 protected] 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
draft-ietf-fax-esmtp-conneg-02.txt
(application/octet-stream, 16.3 KB)
Network Working Group K. Toyoda, MGCS
Internet Draft D. Crocker, Brandenburg
DRAFT-IETF-FAX-ESMTP-CONNEG-02.TXT June 2002
Expires: December 2002
SMTP Service Extension
for Content Negotiation of Internet Fax
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of
RFC2026. Internet-Drafts are working documents of the
Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or
obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/shadow.html.
COPYRIGHT NOTICE
Copyright (C) The Internet Society (2001). All Rights
Reserved.
ABSTRACT
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.
1. INTRODUCTION
The voice over IP in Intranet of enterprise can communicate
directry each other. Internet Fax can also directry communicate
each other in such a network environment. But, Internet Fax
can not negotiate capabilities because there are no method in
SMTP service currently.
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.
2. CONVENTIONS
In examples, "C:" and "S:" indicate lines sent by the
client and server respectively.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted
as defined in "Key words for use in RFCs to Indicate
Requirement Levels" [KEYWORDS].
3. CONTENT NEGOTIATION SERVICE EXTENSION
(1) The name of the SMTP service extension is
"Fax_content_Negotiation"
(2) The EHLO keyword value associated with this extension
is "FAXCONNEG"
(3) A parameter using the keyword "FAXCONNEG" is added to the
RCPT-TO command
(4) The server responds with a report of the content
capabilities of the device or system that embodies the
target RCPT-TO address.
4. FAXCONNEG PARAMETER TO RCPT-TO
4.1 Parameter
Keyword:
FAXCONNEG
Argument:
REQUIRED
The client need the capability.
the target does not support the FAXCONNEG parameter, the
target MUST reject the RCPT-TO command with a 504 reply.
If the target can not return the capability by temporary
failure, it MUST reject the RCPT-TO command with a 404
reply.
OPTIONAL
The client would like to get the capability.
If the target can not return the capability by temporary
or parmanent failure, the target MUST return 250 code
wtithout FAXCONNEG capabilities.
If the argument does not exist, the default is "REQUIRED".
4.2 Client Action:
If the server issued a 250-FAXCONNEG, as part of its
EHLO response for the current session, the client MAY
issue the FAXCONNEG parameter with RCPT-TO.
If the client issues the FAXCONNEG parameter with
RCPT-TO, then it MUST honor the capabilities specified
in the FAXCONNEG 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 target.
If the server rejects the RCPT-TO command with a 404
reply, the client may reissue the RCPT-TO with the FAXCONNEG
parameter after getting a 404 reply by the target.
If the server returns 250 code wtithout FAXCONNEG capabilities,
the client MUST work as "a Simple Mode of Facsimile Using
Internet Mail" [RFC2305].
4.3 Server Action:
If the client specifies "FAXCONNEG = REQUIRED" in the RCPT-TO,
but the target does not support the FAXCONNEG parameter, the target
MUST reject the RCPT-TO command with a 504 reply. If the target
support the FAXCONNEG parameter, but it can not return the
receipient's capability temporarily, the target MUST reject the
RCPT-TO command with a 404 reply. For example, if the target get
the capability information from a directory, but its connection
is offline, the target MUST reject the RCPT-TO command with a
404 reply.
If the client specifies "FAXCONNEG = OPTIOANL" in the RCPT-TO,
the target MUST return 250 code wtithout FAXCONNEG capabilities
nevertheless the failure is temporary or parmanent.
Regardless of the value of parameter, if the target does
support the FAXCONNEG parameter, then it MUST issue a 250 reply,
followed by its capabilities of the target that is specified by
the RCPT-TO address. Successful responses to FAXCONNEG 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-FAXCONNEG " and "250 FAXCONNEG " are the
FAXCONNEG responses. The last line begins with "250 FAXCONNEG ".
if the SMTP server supports ENHANCEDSTATUSCODES, the exact
strings of successful responses are "250-2.1.5 FAXCONNEG " and
"250 2.1.5 FAXCONNEG ". The exact strings of parmanent failure
responses are "504-5.3.3 FAXCONNEG" and "504 5.3.3 FAXCONNEG".
The exact strings of temporary failure responses are
"404-4.3.3 FAXCONNEG" and "404 5.3.3 FAXCONNEG".
All FAXCONNEG-capable clients and FAXCONNEG-capable servers MUST
be able to successfully process FAXCONNEG lines that are up to 512
characters long, as required by RFC2821. If the length of FAXCONNEG
lines is greater than 512 characters, the server MUST insert
line breaks and make next FAXCONNEG line.
The contents of the capability listing MUST conform to
the specifications in "Content Feature Schema for Internet Fax".
[RFC2879]
5. SYNTAX
Command with "FAXCONNEG":
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>"
/ Forward-Path) (SP "FAXCONNEG =" ("REQUIRED" /
"OPTIOANL") CRLF
Reply:
( ("250-" CRLF) *("250-FAXCONNEG" capability CRLF)
("250 FAXCONNEG" capability CRLF) )/
( ("250-2.1.5" CRLF)
*("250-2.1.5 FAXCONNEG" capability CRLF)
("250 2.1.5 FAXCONNEG" capability CRLF) )/
("504" CRLF) /
("504 5.3.3" CRLF) /
("404" CRLF) /
("404 4.3.3" CRLF) /
capability = <<as per [RFC2879]>>
6. EXAMPLE
An example of ESMTP sequence with succeseful RCPT-TO response
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
S: 250 FAXCONNEG
C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> sender ok
C: RCPT TO:<[email protected]> FAXCONNEG = REQUIRED
S: 250-<[email protected]> recipient ok
S: 250 FAXCONNEG (&(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) )
C: DATA
S: 354 okay, send data
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
Per:
( image-file-structure=TIFF-minimal
dpi=400
image-coding=JBIG
size-x=2150
)
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye
An example of succeseful RCPT-TO response when the length of
capability is greater than 512 characters.
S: 250-2.1.5<[email protected]> recipient ok
S: 250-2.1.5 FAXCONNEG (&(image-file-structure=TIFF-minimal) ...
S: 250-2.1.5 FAXCONNEG .....
S: 250 2.1.5 FAXCONNEG (color=Binary)
An example of succeseful RCPT-TO response when FAXCONNEG-capable
server supports ENHANCEDSTATUSCODES.
S: 250-2.1.5<[email protected]> recipient ok
S: 250 2.1.5 FAXCONNEG (&(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) )
An example of ESMTP sequence with parmanent failure RCPT-TO
response.
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> sender ok
C: RCPT TO:<[email protected]> FAXCONNEG = REQUIRED
S: 504 <[email protected]> recipient ok
C: QUIT
S: 221 goodbye
An example of ESMTP sequence with temporary failure RCPT-TO
response@when the value of parameter is "REQUIRED"
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
S: 250 FAXCONNEG
C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> sender ok
C: RCPT TO:<[email protected]> FAXCONNEG = REQUIRED
S: 404 <[email protected]> recipient ok
C: QUIT
S: 221 goodbye
.
.
.
retry according to implementation
An example of ESMTP sequence with temporary failure RCPT-TO
response when the value of parameter is "OPTIONAL"
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
S: 250 FAXCONNEG
C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> sender ok
C: RCPT TO:<[email protected]> FAXCONNEG = OPTIONAL
S: 250 <[email protected]> recipient ok
C: DATA
S: 354 okay, send data
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
Per "A Simple Mode of Facsimile Using Internet Mail"
RFC2305
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye
7. IANA CONSIDERATIONS
On publicatioj of this document by the RFC Editor the IANA
shall register the Content_Negotiation ESMTP extension defined
in section 3.
8. SECURITY CONSIDERATIONS
This ESMTP option calls for a respondent to disclose
its capabilities. Mechanisms for determining the
requestor's authenticated identity are outside the
scope of this specification. It is intended that this
mechanism permit disclosure of public information;
hence there is no particular need for security
measures.
However there is nothing to prevent disclosure of
sensitive information that should receive restricted
distribution. It is, therefore, the responsibility of
the disclosing ESMTP server to determine whether
additional security measures should be applied to the
use of this ESMTP option.
A man in the middle might change the capabilities associated
with a given recipient. Here's a somewhat 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. But modifying a document on the fly is a much more
difficult proposition.
9. ACKNOWLEDGEMENTS
Graham Klyne provided useful suggestions to an earlier
draft.
10. NORMATIVE REFERENCES
[ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud,
E. and D. Crocker, "SMTP Service Extensions",
RFC 1869, November 1995
[ESMTP2] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2879] McIntyre, L. and G. Klyne, "Content Feature
Schema for Internet Fax", RFC 2531, August
2000
[RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing,
"A Simple Mode of Facsimile Using Internet Mail",
RFC 2305, March 1998.
11. AUTHORS' ADDRESSES
Kiyoshi Toyoda
Matsushita Graphic Communication Systems,Inc
2-3-8 Shimomeguro, Meguro-Ku
Tokyo 153 JAPAN
+81.3.5434.7161
[email protected]
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
+1.408.246.8253
[email protected]
12. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2001). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment
on or otherwise explain it or assist in its
implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and
derivative works. However, this document itself may
not be modified in any way, such as by removing the
copyright notice or references to the Internet Society
or other Internet organizations, except as needed for
the purpose of developing Internet standards in which
case the procedures for copyrights defined in the
Internet Standards process must be followed, or as
required to translate it into languages other than
English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.