Subject: I-D ACTION:draft-ietf-fax-implementers-guide-00.txt

From: [email-masked]
Date: Tue, 26 Oct 1999 07:41:06 -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		: Implementers Guide for Facsimile Using Internet Mail
	Author(s)	: V. Cancio, M. Moldovan
	Filename	: draft-ietf-fax-implementers-guide-00.txt
	Pages		: 10
	Date		: 25-Oct-99
	
This document provides guidelines to follow for the implementers of
facsimile communications using Internet Email described in RFCs
listed in the Reference section of this document. References [1-5].
This guidelines do not supersede the referenced documents and its
intention is only to clarify.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fax-implementers-guide-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-fax-implementers-guide-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-fax-implementers-guide-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 27 Oct 1999 10:01:00 +0900 (JST)

Hi,

My comments are below.(after "- End quote -")

-- Begin quote --
   3.1.1 Multipart-alternative

   Legacy (old) email client implementations may not be capable of
   processing 'multipart-alternative'. If a sender is unsure if the
   recipient complies with the MIME requirements, the sender should
   assume the worst and not use content-types which have known
   problems with such non-compliant implementations.  Specifically,
   multi-part/alternative SHOULD be avoided in situations where the
   recipient is not known to properly support multipart/alternative.

   [[[Note: How does a sender's client application know this information?]]]
- End quote -

If we add something, maybe,
"The mechanism or something is beyond the scope of this document."

We sometimes see the expressions like "beyond the scope" or "out of scope".

But I don't think it is necessary.
In fact, it cannot be done without capability exchange.

-- Begin quote --
   3.2.1 Multipart-alternative and Storage Capacity

   Devices with little storage capacity are unable to cache previous
   parts of a multipart/alternative message.  To maintain the required 
   MIME compliance when receiving multipart/alternative, such devices with
   little storage capacity MAY choose to simply use the first processable
   part of a multipart/alternative message and ignore subsequent parts
   even if they were processable by the device.

   [[[Note: Is this a warning? or the MAY is acceptable behaviour?]]]
- End quote -

"MAY" is acceptalbe, I think.

-- Begin quote --
   4.2 Precautions for implementers of RFC 2301 [4]
- End quote -

There are lots of important informations in this section,
for implementation. But I wonder what is guided here
as this Implementers Guide. Information itself is useful,
I know.

-- Begin quote --
   5.2 Internet Fax Offramp Addresses Per RFC 2303/3204

   TBD

   [[[Note: Status codes to use in MDN or DSN?
	   a) Sender not authorized to used of offramp?
	   b) Error in phone number - fatal or temporary, etc?]]]
- End quote -

Could you explain what you intend here ?
Do you recommend some status codes or disposition-types,
when offramp cannot be done ?

Offramp/Onramp matters may be difficult to include at the first stage.
Because fax protocols have to be considered.

If it is not neccessary to consider fax protocols,
we may describe something.

This is also the discussion item.

-- Begin quote --
   6.2.2.1 Discrepancies in MDN [7] Interpretation

   The value of receiving an acknowledgement of 'processability' from 
   a Extended Mode recipient is the success or failure to process the
   TIFF file attachment. The attachment constitutes the facsimile
   message and not the body-content of the message. Therefore a
   Extended Mode sender would expect, and it is recommended, that the
   Extended Mode receiver responds with a MDN to indicates the success
   or failure to decode and process the TIFF-FX file attachment.

   An Extended Mode sender must be aware that RFC 2298 [7] does not make
   this distinction and consequently MDNs may be received which do not
   associate the feedback information to the attached TIFF-FX file but
   to the body-content part of the message.
- End quote -

This may apply to DSN. The receiver that can understand SMTP with DSN
can behave like this.

-- Begin quote --
   In the future, new reply codes for DSN and MDN may be created to
   clearly communicate the distinction between acknowledging the
   body-content of the message and the attachment to the message.
- End quote -

This is the very important points for manufacturers.

-- Begin quote --
   6.2.2.2 Extended Mode Receivers which are MTAs (or ESMTP servers)

   <snip>

   b) Receiver determines that attachment was not process-able:
     - A Positive Completion [RFC 821] reply is returned to MTA 
       (Reply Code 250 after receiving CRLF+, CRLF). Action: Failed
     - A DSN is generated and returned with Enhanced Error Code: Status 5.6.1

   [[[ Another status code may be possible?
      X.6.0 Other undefined Media error
      X.6.1 Media not supported
      X.6.2 Conversion required but not supported
      X.6.3 Conversion with loss performed
      X.6.4 Conversion with loss performed
      X.6.5 Conversion failed
      Any Diagnostic-Codes?
   ]]]
- End quote -

"CRLF+, CRLF" -> "CRLF + '.' + CRLF"
I'm not a native English speaker. Maybe, Mail experts know
the better expressions.

About the status code, only 5.x.x can used. Because, if the receiver
returns 4.x.x, the sender will retry.

For the time being, 5.6.1 is the best code.

-- Begin quote --
   6.2.2.3 Extended Mode Receivers which are POP3/IMAP4

	After receiver determines that attachment was process-able it
	may respond with:
	disposition-type = "displayed", "dispatched", or "processed"

	a) For embedded devices or software mail clients which are 
	   RFC 2532 compliant recipients, the following response MAY
	   apply to the TIFF-FX attachment itself: "dispatched" or
	   "processed".
	   [[[Note: Can we advise "processed"]]]

	b) For embedded devices or software mail clients which are 
	   RFC 2532 compliant recipients, the following response MAY
	   apply to the body-content itself: "dispatched" or "processed".
	   [[[Note: Can we advise "dispatched"]]]
- End quote -

If the receiver wants to return the above two disposition-types ?
what happens ? I think only one disposition-type is used in one MDN.

I think the important point is,
irrespective of that senders receives either "dispatched" or "processed",
the sender do not recognise that the message is not decoded in receivers.
Maybe, senders recoginise successful transfer or communication, or ...
, for the time being.

In fact, in the future, new disposition-types will be necessary.

-- Begin quote --
   7.1 Email and Traditional Facsimile Headers
- End quote -

There is a word "CSID". I think this is "CSI" in T.30.

I look forward to other comments.

And,
if specific examples(DSN/MDN itself, sequeces) can be described, it is better.
After we have some agreements, shall we prepare ?

One more.
Japanese manufactures will have communication-test in December
for simple-mode(RFC2305). One of the test items is the error notice
to the sender. I may input something from the results.

Finally,
BTW, is it necessary to describe about "unsolicited response" ?

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
Mail: [email-masked]
Tel: +81-46-228-1743  Fax: +81-46-228-7500 (SUB/F-code 5727)