Subject: Call for Discussion on Response to Communication 1 from the ITU

From: James Rafferty <[email-masked]>
Date: Fri, 03 Sep 1999 11:57:21 -0400

Folks,   

At the July meeting, we had some discussion on the 2 communications from the 
ITU.  We agreed at that meeting that we would respond to the communications
in time for the responses to be reviewed at the September ITU Question 4
rapporteur
meeting, which will take place on Sept 20-23.   

I will start this thread to work toward consensus on the response to the
1st communication and 
do a separate thread for the second one.   

Ideally, I'd like to complete the drafting of the response by Sept 10th.   

The original communication reads:   

>The Question 4 Rapporteur’s meeting of Study Group 8 met on 24 March - 1
>April and reviewed several Internet Drafts from the IETF Fax working
>group for in realising the "Full Mode" of T.37 Recommendation.  We
>welcomed the participation of representatives from ISOC/IETF in
>presenting the latest RFCs for Internet Fax and had a productive
>meeting.  We have reviewed following documents RFC2530, RFC2531 and
>RFC2532 and would like to make the following observations:
>
>
>1.   The existing text in RFC2530, RFC2531 and RFC2532 meets our
>requirements at the present time and they will be referenced in the
>amended version of T.37.
>
>
>2.   In the future in order to meet evolving requirements, we would
>like to request the addition of some features.  Details are as follows:
>
>
>2.1    In RCC2532, the MDN/DSN request has no means to indicate
>precisely to the receiver, that the sender desires to have capabilities
>returned with MDN/DSN response.  This situation is difficult for the
>facsimile application, since the capabilities of the receiver is
>required for the Full Mode sender before transmitting a TIFF-FX file.
>Since the existing capabilities exchange mechanism uses MDN and DSN
>facilities, further enhancements to this method are high priority for

>us.
>
>
>2.2    The fax processed status information in RCF2530 needs to be
>enhanced. We need a facility to enable the total number of pages and
>pages in error to be returned to the sender in a MDN to indicate
>successful processing.  We need further precision on the fax status
>information using DSN and/or MDN.
>
>
>2.3    Similary the specification within RFC2298 for the value processed
>need to be enhanced. We need further precision to ensure that the
>specific MDN response that is generated clearly indicates that the MIME
>body part(s) has been successfully processed (i.e. printed or
>displayed).
>
>
>2.4   We request further study and a more complete solution on
>mechanisms for capabilities request and indication that can be used to
>meet  the Internet fax requirements for capability exchange.
>

We can just acknowledge point 1. and then respond to the other points.  

Below, I will note the related parts of the minutes from the Oslo WG meeting
and then add my comments on related action items, etc.:   

>A discussion on a response was  led by James Rafferty:
>(2.1) there is no specific mechanism for DSN/MDN to explicitly request 
>capabilities as well as confirmation.
>
>It was noted that the current specification indicates an extended mode fax
>receiver SHOULD send capability information in response to a request for 
>confirmation, and that SHOULD is a very strong requirement, and should
>not be disregarded without a very good reason.  However, the chair noted
>that the ITU is asking the WG to strengthen the request requirement.
>
OK, I think we can note that SHOULD is a strong requirement in the response

to ITU to start things and then review possiblities for strengthening the 
request requirement as per below.   
>Ryuji Iwasaki-san provided a brief presentation on a capabilities
exchange... 
>He noted that  if a sender does not know receiver's capability, it must
>send TIFF-FX Profile S. If a sender needs to send higher capability, the
>message must be sent (and printed) twice (first time TIFF-S, then higher
>capability). 
>
>His proposal is to  send a new "request header" with the image AND request
>capabilities.    -- IF a receiver is capable of handling extended
>capabilities they can choose NOT to print the TIFF-S, and instead request
>the enhanced document.
>
>Graham Klyne also had some ideas along the lines of having the receiver
>initiate content negotiation in response to an indication from the sender.
>It was suggested that Iwazaki-san and Klyne should cooperate on a
>joint proposal.
>
Iwasaki-san and Graham are both suggesting methods to build upon the
current request/capabilities identification method, but in somewhat different
ways.   

Iwazaki-san and Graham, have you been able to work on a joint proposal?   
Are there any key discussion points to review here on the list in advance of
that (or in parallel)?
>
>(2.2) need a more complete (i.e. universally available) mechanism for 
>confirmation
>
>It was concluded that MDN message extensions should be discussed on the list.
>
Hmm.  To date, we have not really had these discussions on the list.  There
was 
some ad-hoc activity at IETF on ideas for extending MDN, but the focus of
these 
was more targeted to addressing the points in 2.3 below.   However, the
door seems 

to be open to proposing MDN extensions.  We could initiate some here, but
they should also be reviewed with the mail and possibly the VPIM
communities.   
These MDN extensions are not currently on our charter milestones as
reviewed at
Oslo, so that they 
would probably go forward as individual draft submissions if they firm up.   

So, the response to the ITU on this item would seem to be that 1) the issue 
has been raised and further discussion and contributions are encouraged.
Resulting
IDs would be individual submissions, since they are not currently part of
our charter. 
>
>(2.3) MDN response to indicate status of attachment processing. Require to 
>indicate status of body part or parts vs message as a whole.
>
>
>In discussion, it was suggested that the likely route is some kind of
>extension of MDN response. This is feasible, 
>but might make MDN responses quite long so probably any extensions should 
>be sent only if explicitly requested. There is a need to work with VPIM on
>this, as they are looking at addressing some similar issues.  This is
>another topic for the small ad-hoc with Keith, as well as for followup on
>the list.   
>
We had some ad-hoc activity on this at Oslo and Keith among others was 
receptive to the idea of improving the granularity of MDNs.  This also 
seems to tie into ideas about processing of different message types in 
multi part messages, etc.   

This would have impact on email, fax and voice, so some collaborative
effort is needed.   
If anyone is aware of any further work that has been done on this, please
let me know.   

Further discussion on the list on this item is also welcome.   

My thinking is that the response on this item will be along the lines that
"that experts from the 
mail, fax and voice communities in the IETF are reviewing potential ways to
extend MDN
to provide better clarity and granularity on the results in processing
messages with one or
more attachments."   

Item 2.4 was not discussed directly at Oslo, but is related to item 2.1.
Basically, the
request is for a more complete solution on mechanisms for capabilities
request and indication.  
The potential work from Iwasaki/Klyne addresses this to a degree.   I had
hoped
that we would start to see some results from Rescap activity by now (at
least in 
proposal form), but there seems to be very little happening there.   So,
unless 
this changes, a more complete solution would be based on enhancements to the 
current approach.    

That completes the review of the communication and the related actions that
have been taken to date.   Further discussion would be good; if folks are
planning 
related drafts that I have not mentioned here, please let me know.  

So, let's discuss for a few days and by Wed 9/8, I will try to do the
initial draft
of the response.   

James Rafferty
Chair, IETF Internet Fax WG

*------------------------------------------------*
James Rafferty			
President, Human Communications LLC
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Fax to email:  +1-603-925-5753  (Current Preferred Fax Number)
Email/Internet Fax:  [email-masked]
Alternate email : [email-masked],
 [email-masked] (chg from csi.com)

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