Subject: [FAX] Status of WG Last Call on -eifax

From: James Rafferty <[email-masked]>
Date: Fri, 09 Oct 1998 10:36:19 -0400

Folks,  

Based on the comments that have been received, we are making good 
progress on getting a fully stable version of the -eifax draft.  

However, there are still a few open items, mainly related to 
references, so I would like to extend the WG Last Call comment period until
this Friday, October 9, in the hope we can get them resolved soon.  

The items still under review are:  

1)  Section 2.1

>2.2.   Recipient Requirements
>
>   Recipients in compliance with this document SHOULD implement MDN
>   [RFC2298], and SHOULD implement Offramp Gateway Extensions for DSN
>   and MDN [REPORT-EXTENSIONS].

We need to decide whether the Offramp related extensions in the
reporting-extensions draft are sufficiently stable to be reference in the
-eifax draft.   Please
see my separate Query on this point.  

2)  Section 2.2.2

There have been comments received on the second sentence here; 
a tightened up version has been suggested by Ned Freed.   This text
just serves to clarify normal behavior for email recipients.  

Current text is:  

>2.2.2.  Recipients using Mailbox Access Protocols
>
>   A recipient using [POP3] or [IMAP4] to retrieve its mail MUST NOT
>   generate a Delivery Status Notification message [RFC1894].
>
>   The recipient MUST NOT use the RFC822 "To:" field to determine the
>   ultimate destination mailbox or addressee, and SHOULD NOT use other
>   RFC822 or MIME fields for making such determinations.

Proposed revised text for second sentence:  

>   The recipient MUST NOT use RFC822 "To:" fields, "Cc:" fields,
>   "Bcc:" fields, or any other fields containing header recipient
>   information to determine the ultimate destination mailbox or
>   addressee, and SHOULD NOT use other RFC822 or MIME fields for
>   making such determinations.
>

3)  Section 3.3

>3.3.  Capabilities Returned in MDN or DSN
>
>   As outlined in section 2 of this document, a sender may request a
>   positive DSN or an MDN.
>
>   If the recipient implements [REPORTING-EXTENSIONS], the DSN or MDN
>   that is returned can contain information describing the recipient's
>   capabilities.  The sender can use this information for subsequent
>   communications with that recipient.
>
>   The advantage of this approach is that additional infrastructure is
>   not required (unlike section 3.2), and the information is acquired
>   automatically (unlike section 3.1).

We have discussed this a lot in the WG, but need to get confirmation from our
ADs on the acceptability of this MDN/DSN extension related to capabilities.   

It would be highly desirable to have at least one mechanism for
capabilities identification that could be implemented right away, without
requiring substantive email infrastructure upgrades,  and it appears this
approach would satisfy that criteria.   However, this will also require
buy-in/concurrence from the more general email community, either now or
during the IETF Last Call.   

4.  Section 5.2

Dan Wing has been checking with the RFC 1893 author Greg Vaudreiul  and Ned
Freed  about getting a new status code defined.   If this will not be
available in time, the fallback will be to use an existing RFC 1893 status
code.  

Current text is:  

>5.2.  Recipient Recommendations
>
>   To provide a high degree of reliability, it is desirable for
>   the sender to know that a recipient could not process a message.
>   The inability to successfully process a message may be detectable
>   by the recipient's MTA or MUA.
>
>   If the recipient's MTA determines the message cannot be processed,
>   the recipient's MTA is strongly encouraged to reject the message with
>   a [RFC1893bis] status code of 5.6.--???-TBD-????--.  This status code
>   may be returned in response to the end-of-mail-data indicator if the
>   MTA supports reporting of enhanced error codes [RFC2034], or after
>   message reception by generating a delivery failure DSN ("bounce").
>

If you have any comments on these items, please submit them to the list
this week.   

Regards, 

James Rafferty
Chair, Internet Fax WG

*------------------------------------------------*
James Rafferty			
President, Human Communications 	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email:  [email-masked]
	 [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------

---

From: James Rafferty <[email-masked]>
Date: Wed, 14 Oct 1998 14:09:24 -0400

>The items still under review are:  
Since I wrote this note, I've spent some time reviewing one of the 
referenced documents in -eifax, the new draft-ietf-fax-feature-schema-00.   
As noted below, some of the proposals in that draft may have a ripple effect
on the -eifax draft.   

So, I am noting one additional open item here, along with some related
comments
on proposed additions to -eifax to address the point raised.     

Some of the text in the initial "schema" draft attempts to define rules 
on the behavior of an -eifax system as it related to feature tags.  My belief
is that these kind of rules belong in the protocol draft.   

So, I have these additional related comments on section 3 of -eifax-06:  

>3. Additional document capabilities
>
>   Section 4 of [RFC2305] only allows sending only the minimum subset of
>   TIFF for Facsimile "unless the sender has prior knowledge of other
>   TIFF fields or values supported by the recipient."
>
This sentence says what is not allowed, but does not go on to talk about
the use of other RFC2301 TIFF profiles in extended Internet fax.   So, I
would suggest adding the following as the second sentence of the section:     

"RFC 2301 defines additional profiles of TIFF for Facsimile that may be
used within  extended Internet fax operations, if support for these
profiles is provided by the recipient Internet fax system."

>   A recipient SHOULD indicate which features and values from among
>   those available in [FAX-SCHEMA] are supported using one of the
>   mechanisms defined below.
>
I think this is still fine as is.   

>   Three methods for the sender to acquire such knowledge are
>   permitted:
>
>     1.  Sender manual configuration
>     2.  Capabilities in Directory
>     3.  Capabilities returned in MDN or DSN
>
>   An implementation may cache capabilities locally and lose
>   synchronization with the recipient's actual capabilities.  A
>   mechanism should be provided to allow the sender to override the
>   locally-stored cache of capabilities.  Also note section 4.1 of this
>   document.

In addition to the text above in Section 3, I think we need to say more about
minimum levels of conformance on how extended Internet fax systems will use
the feature tags.  The -schema draft has started to define some of these
rules, but I 
think they would be better to include them within -eifax, so that the
-schema draft
defines the feature tags, but the related behavior of eifax systems is
included within this, the protocol draft.   

So, at the end of section 3, just before section 3.1, I would propose the
addition of the following sentence:

"Extended Internet fax systems SHOULD/MUST (?) be able to recognize and
process the feature tags as defined in [SCHEMA] when reviewing the
capabilities presented for a potential Internet fax recipient, but should
ignore any additional capabilities tags which it does not understand."    

So, the first part of this sentence specifies a minimum requirement on the
need for extended Internet fax systems to be able to recognize and process
the tags defined in [SCHEMA].   This sets a ground floor for
interoperability among eifax systems as it relates to capabilities.
Ideally, I'd like this to be a MUST condition, to ensure interoperability.
 However, its not clear to me at this time if there will be interactions
between the eifax systems and the expression rules for  one of directory
mechanisms, such as LDAP or DNS (if agreed), which would make this
requirement difficult to meet, in which case making this a SHOULD condition
may be the best we can do considering the current state of the mechanism
work .  

The second part of the sentence is intended to allow for the possibility
that there may additional tags which are registered in the future, but were
not in the original schema draft.   Existing systems will have to ignore
the new tags.   

That's the end of my comment on proposed additions to section 3.   Other
comments, as always, are welcome.   

James