Subject: [IETF-FAX] Addition to Adelaide meeting (ITU-T issue)

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 03 Apr 2000 11:36:30 +0900 (JST)

Dear Colleagues,

At Adelaide, unfortunately, we had no time to introduce ITU-T matters,
which were scheduled. As I said at Adelaide, I introduce them briefly, here.

Specifically, for our plan for ITU-T, any suggesions are welcome.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-------------- Begin ------------------

1 Report of SG8 February Meeting

1.1 T.37

There were no proposals at the meeting. IETF-FAX WG draft charter
was introduced. Q4/SG8 confirmed the cooperation between IETF-FAX WG
and Q4/SG8, and agreed to continue it. Q4/SG8 proposed the plan
for T.37 extension. The plan was as follows.

- Support for Full Mode enhancements
- Support for new image compression capabilities
- Support for new image transmission capabilities
- Support for Group 4
- T.37 Gateway functionality
- T.37 over mobile packets networks
- T.37 quality of service

But Q4/SG8 did not discuss them in detail.

1.2 Re-organizing SGs in ITU-T

February SG8 meeting was the final SG8 one in this study period
(1996-2000). ITU re-organizes itself every 4 years.
There is a WTSA(Plenary conference) in October. According to the results,
SG8 will be merged with other SGs. Anyway, Q4/SG8 will continue
as one of questions in a re-organized SG.

2 Our plan for ITU-T

2.1 Notice of our WG Status and other related matters

IETF-FAX WG has started again. So, I believe it is necessary
to notify our WG status. The items are as follows.
- Our fixed charter itself
- Discussion matters(e.g. Internet drafts)
- Other WGs information

2.2 Input of Internet drafts

We have the four Internet drafts that we should consider
to input to ITU-T. But the three drafts related to FFPIM
are not TECHNICALLY mature. With regard to Implementers-draft,
it is an informative one. In fact, there are some issues that
we should modify. But this draft is meant for Simple mode and Eifax,
which we have already made. I believe it is better to input
to ITU-T, because the contents are very useful for T.37 implementers
as well as Simple/Eifax ones.

2.3 Can we agree to send a letter and one draft to Q4/SG8 ?

Q4/SG8 interim meeting will be held in June.
Can we agree to send them there ?

If agreed, I will write a draft letter and circulate it here.

-------------- End ------------------

Again, any comments are welcome.

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

---

From: Ryuji Iwazaki <[email-masked]>
Date: Wed, 05 Apr 2000 16:29:03 +0900

> 2.3 Can we agree to send a letter and one draft to Q4/SG8 ?

I agree to send them to ITU-T.
I would like to solve the open issues in the draft through discussion
on this mailing list.
And also I would like to discuss about three drafts regarding FFPIM.

Ryuji Iwazaki
TOSHIBA TEC Corporation

---

From: Graham Klyne <[email-masked]>
Date: Wed, 05 Apr 2000 09:50:31 +0100

At 04:29 PM 4/5/00 +0900, Ryuji Iwazaki wrote:

> > ... But the three drafts related to FFPIM
> > are not TECHNICALLY mature.

>And also I would like to discuss about three drafts regarding FFPIM.

I agree.

Further, for key issues relating to the content negotiation and the timely 
delivery drafts, I note that there were some additional slides that I did 
not show in Adelaide at the end of the presentation sets used.  I assume 
these will show up in the proceedings for the IETF meeting, but I also 
attach them (in PDF form) for present company.

For content negotiation, see the slide headed "The big issue: receiver 
state management".

For timely delivery, see the final three slides headed "The unresolved 
challenge" and "Strawman proposal...".

I would welcome discussion of the matters raised there.

#g

------------
Graham Klyne
([email-masked])

---

From: MAEDA toru <[email-masked]>
Date: Mon, 10 Apr 2000 19:55:13 +0900

Dear Tamura-san,

I request to send a follow-on communication
which will reply to the ITU-T communication
"Communication form SG8 on the use of  Extended Internet Fax for ITU-T T.37 
Full Mode"
dated 04-Apr-1999 from Mr. Silbiger.

Issues in the ITU-T communication are open.

Regards,

Toru MAEDA

>Specifically, for our plan for ITU-T, any suggesions are welcome.

************************
前田　徹
キヤノン(株)　映事第3技推部
************************

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 12 Apr 2000 17:31:19 +0900 (JST)

Klyne-san,

Just comments.

> For content negotiation, see the slide headed "The big issue: receiver 

If there is a state in receiver, receiver wants to know
whether incoming message is the first received message or the second one.

I think identifier or something in sending message is necessary
for this purpose.

State: Idle, In-Negotiation, .....  for each id or something.

In some implementations, receiver may keep the first received
Profile S data during state:In-Negotiation, and if a timer expires
receiver may print it.

There may be no memory case in Negotiation, as your slides say.
In this case, some methods in which receiver notify sender of
receiver state may solve this situation. But difficult ?

In fact, "State" in receiver is necessary for real implementation,
irrespective of whether "State" is described in draft or not.

Some should be described. Others remain implementation matter.

But, I do not have specific ideas now.

> challenge" and "Strawman proposal...".

I do not understand well why "Compliance(Conformance ?)-required" is necessary.
"DeliveryBy" and "DSN" ESMTP extensions are not enough to realize it ?

And, What about the status of the referenced "draft-newman-deliver-..." ?

Regards,

---

From: Graham Klyne <[email-masked]>
Date: Wed, 12 Apr 2000 12:01:51 +0100

Tamura-an,

Thank you for your comments.  I think that I maybe need to clarify some 
aspects of what I meant to say.

The issue of receiver state information is raised because it has 
implications for the design and capacity of a receiving system.  By 
receiver state, I mean that a receiver needs to remember that it has 
received an initial message AND that it has requested an alternative form 
of data.  Without this, there is a possibility that message data may be 
silently lost, which is very much to be avoided.

Receiver state MUST contain, as a minimum:
- the fact that message data was received, and alternative data has been 
requested.
- a unique message identifier
- the time at which alternative
This allows the receiver to re-issue a request for an alternative data 
format, or to report an error, if the requested data does not arrive in a 
reasonable time.

It MAY also include:
- a copy of the data originally received.  This would allow the receiver to 
display the original data if alternative data is not received.
- details of the data format supplied, and alternatives offered.  This may 
allow improved diagnostics in the event that the alternative data requested 
is not received.

>whether incoming message is the first received message or the second one.

This information should be implicit in the form of message, so this should 
not need to be explicitly part of the state maintained by a receiver.  Only 
the _first_ message should contain the message disposition request 
indicating the sender's willingness to send alternative forms.

In practice, a receiver would have implicit information about first- and 
subseqent- messages, because it would establish state information only in 
response to the first message.

>I think identifier or something in sending message is necessary

Yes, I agree.  This should be added in section 3.1 of the proposal.

>State: Idle, In-Negotiation, .....  for each id or something.

I think the only meaningful state here is "in negotiation"

>Profile S data during state:In-Negotiation, and if a timer expires

I agree this is the ideal situation.  But I think we must recognize that 
some receivers may be unable to store message content for extended periods, 
so we have tried to avoid making this an absolute requirement.

>receiver state may solve this situation. But difficult ?

I'm not sure what you mean by "no memory case".

Do you mean that the receiver has insufficient memory to store state?  In 
which case, I'd suggest that the receiver simply displays the received data 
and respond per "extended mode".

Or do you mean that the receiver runs out of memory after entered 
negotiaton.  I think the exact recovery path here would depend upon a 
number of factors:  preferably, the receiver should display any data 
received;  at least, it must display a diagnostic, and try to notify the 
sender of failure.

I don't think there's any reason for the receiver to notify the sender of 
its internal state;  I think that all the sender needs to know is:
(a) that the receiver has asked for something different,
(b) that the transfer has completed successfully,
(c) that the transfer has failed, or
(d) that it is waiting for one of the above responses from the receiver.

>irrespective of whether "State" is described in draft or not.

In a sense, I agree.  But prior to e-mail based negotiation, the state 
information is very transient (e.g. for T.30, it is maintained only for the 
duration of a connection, when receiving an extended-mode fax, it exists 
only between receipt and disposition (e.g. printing) of the data.  These 
are all characterized by having clear upper bounds on the "amount" of 
receiver state maintained at any instant in time.

With e-mail based content negotiation, the number of outstanding messages a 
any time is not theoretically bounded.  For a typical computer system, this 
is not really a problem as disk capacity is generally sufficient to deal 
with "arbitrary" amounts of state information (the capacity limits are so 
much greater than normal expected requirement that they don't normally 
represent a practical constraint).  But for a "fax machine" style of 
receiver, memory is a scarce resource, so there is some conflict with the 
requirements of e-mail based content negotiation.

I agree.

In talking about receiver state, what I am really raising is the issue of 
how to maintain bounds on the amount of receiver state that must be 
kept.  I believe we have some reasonable ideas in this regard, but I want 
to be clear about the issue so that implementers can judge for themselves.

>"DeliveryBy" and "DSN" ESMTP extensions are not enough to realize it ?

Your observation is very pertinent.  For the purposes of SMTP transfer, the 
"compliance required" feature is not required and  think there is a strong 
case for pursuing this proposal without that part.

But consider the following scenario:

+--------+     +-------+     +-----------+     +-----------+
| Sender |-->--| Relay |-->--| Receiving |-->--| Disposing |
|  MTA   |     |  MTA  |     |   MTA     |     |   agent   |
+--------+     +-------+     +-----------+     +-----------+

           <------SMTP------->             <-?->

The (possibly enhanced) DELIVERBY proposal concerns itself ONLY with the 
SMTP transfers.  But for the purposes of timely delivery, the goal is not 
satisfied from a user perspective unless the disposition also completes in 
"timely" fashion.

The thinking behind the "conformance required" idea is that the receiving 
MTA communicates with the disposing agent (in some unspecified way), and 
confirms final delivery of the message only if the disposing agent confirms 
that it will dispose of the message in timely fashion.  Simply putting the 
message into a POP mailbox would not meet this criterion.  This is all 
consistent with the fundamental strategy of given the sender total control 
over the whole process:  if the disposing agent cannot communicate the 
required guarantee, delivery is not completed and the sender is duly notified.

>And, What about the status of the referenced "draft-newman-deliver-..." ?

I'm not certain, but I understand it is close to approval.

#g

------------
Graham Klyne
([email-masked])

---

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 13 Apr 2000 19:59:17 +0900 (JST)

Klyne san,

Thank you for your clarification.

<snip>

> format, or to report an error, if the requested data does not arrive in a 

I agree.
But, can the receiver re-issue the request again in the current draft ?

> allow improved diagnostics in the event that the alternative data requested 

I see.

> indicating the sender's willingness to send alternative forms.

Does it mean,
whether the mesaage from the sender includes
"Disposition-Notification-Options:Alternative-available ..." or not ?

<snip>

> I think the only meaningful state here is "in negotiation"

Yes.

> so we have tried to avoid making this an absolute requirement.

Right. I agree to the avoiding.

> I'm not sure what you mean by "no memory case".

<snip>

My intension is,
The receiver has enough memory when the first message comes.
It requests an alternative to sender with "alternative-preferred".
But, when the subsequent message comes, it may have little memory
due to some reasons.

> (d) that it is waiting for one of the above responses from the receiver.

OK, I see.
So, the sender possibly may do 3rd try(transmission) after 2nd MDN
from the receiver is not good.... Am I right ?

<snip>

> requirements of e-mail based content negotiation.

Right.

> to be clear about the issue so that implementers can judge for themselves.

I hope it in the next version.

> >"DeliveryBy" and "DSN" ESMTP extensions are not enough to realize it ?

<snip>

> But consider the following scenario:

I see the background.
A question. In reality, what should MTA do in order to
meet "Compliance-required" ?

---

From: Graham Klyne <[email-masked]>
Date: Thu, 13 Apr 2000 11:39:41 +0100

>But, can the receiver re-issue the request again in the current draft ?

Yes, I believe that is allowed (but not required).  I must check the draft 
wording.

>"Disposition-Notification-Options:Alternative-available ..." or not ?

Yes, this would indicate a sender's initial "offer to negotiate"

I shall look at the wording to make this clearer.

>But, when the subsequent message comes, it may have little memory

Ah, I see.

I think that the receiver must (almost) _always_ reserve enough memory to 
process an arbitrary incoming message -- including a response to 
"alternative-preferred".  (This is not the same as being able to *store* an 
arbitrary incoming message.)  I imagine a system will be able to (a) 
save-to-disk, or (b) print data as it arrives.  (I am assuming that disk 
overflow is not a concern.)

>from the receiver is not good.... Am I right ?

I would say that this is possible, but not expected behaviour.

>meet "Compliance-required" ?

(1) It must be able to communicate with the "disposing agent" at the time a 
message is delivered.  (In a fax machine style of device, I assume this 
functionality would be integrated in a single unit, so noi problem.)

(2) The "disposing agent" must recognize the requested "conformance 
required" (whatever that may be), and indicate that it can satisfy the 
stated requirement (e.g. to print or display the message within a given 
time interval, or indicate failure to do so).

The actual mechanism of communication between the MTA and disposing agent 
is not defined (and I believe cannot be defined at this level).

#g

------------
Graham Klyne
([email-masked])