Subject: Re: I-D ACTION:draft-ietf-fax-content-negotiation-00.txt

From: Graham Klyne <[email-masked]>
Date: Thu, 09 Mar 2000 11:40:48 +0000

Tamura-san,

I am reviewing the comments you made some time ago concerning the fax 
negotiation draft.

At 04:35 AM 10/26/99 +0000, Hiroshi Tamura wrote:
>Hi,
>
>1 3.3
>
>There are the following sentences.
>"
>   If the sender is no longer able to send message data for any
>   reason, it MUST send a message to the receiver indicating a failed
>   transfer.  It SHOULD also generate a report for the sender
>   indicating the failure.
>
>   [[[Discuss this last paragraph.]]]
>"
>
>In this case, what kind of messages do SENDER send to RECEIVER ?

This is a very good question.  At first, I had thought that an ordinary 
text or image message simply saying something like "The alternative data 
you have requested is no longer available".  But on reflection, I wonder if 
this is enough:

(a) an ordinary message conveys no information that the receiver might be 
able to use to print the data originally received (assuming it was 
buffered), or to otherwise indicate failure.

(b) the failure information would not be available in a language neutral 
form for ocalized presentation of the problem.

So now, I am thinking that it might be reasonable to define a 
multipart/report based format for carrying diagnostic information from 
sender to receiver.  The general format would be very like DSN or MDN, but 
I think a different report-type would be needed.

So my question to everyone is:  would this be a reasonable thing to define, 
or is it introducing additional complexity for insufficient gain?

If a new report type is to be introduced for this purpose, I do think it 
should be introduced sooner rather than later, as recognition would then 
become part of the specification for content negotiation and hence avoid 
backward-compatibility issues of introducing it later.  NOTE:  this new 
report type would be sent only after the receiver has indicated 
understanding of the negotiation protocol elements, so it wouldn't impact 
"legacy" receivers.

>2 "Content-alternative" and 'Alternative-preferred'
>
>I think more than two "alternative"s cat be described
>in the first Sender's message,
>by using of more than "Content-alternative" headers.

You are correct -- I have added a NOTE to my working copy to clarify this 
point.  See also section 3.1.3 of the current (-00) draft.

>Receiver cannot specify the exact one that it wants.
>'Alternative-preferred' disposition modifier is only defined.

This is intentional, and quite fundamental to the negotiation design.  Some 
rationale is set out at the start of section 3, but this might need to be 
clarified.  Speifically:

(a) This more closely matches the style of T.30 content negotiation.

(b) This approach provides for clean integration with the current extended 
mode specification.

(c) It builds upon existing e-mail mechanisms in a consistent fashion.

(d) It allows for cases (e.g. dynamically generated content) where it is 
not feasible to enumerate the alternatives available.

I shall add an additional clarifying NOTE in the document.

>Another sub-modifier(?) is necessary for it.

... for the reasons given above, I think this is something to be avoided.

>And,
>
>Receiver cannot judge whether the message from Sender is
>the first one or the second one.

In section 3.3, the specification says that 'alternative-available' should 
not be indicated when the sender is responding to 
'alternative-preferred'.  This is stated so that the negotiation process 
does not loop.

Does this adequately address your concern?

>Sometimes, Receiver may want to know the message is the
>second one. When Receiver returns 'Alternative-preferred',
>it waits for the 'Alternative' of the first message.
>
>In some implementation, if Receiver do not receive
>the second one within some fixed time, it may print
>the first message.
>
>Some new header or something will solve it.

Or, is this to suppress double-printing of a message?

If so, I would suggest introducing another disposition request modifier, 
say 'alternative-resend', to be used by the sender when responding to 
'alternative-preferred'.  Then, a receiver, if it cannot match the 
'alternative-resend' to an outstanding 'alternative-preferred' might assume 
that the original message was printed after all and (maybe) discard the 
alternative.

(NOTE:  the specification could define 'alternative-resend', or similar, 
but I think the receiver's handling of this information would be an 
implementation issue, not part of the specfication.)

In the final analysis, I think multiple message printing cannot be 
completely prevented (e.g. see RFC 1047).  While it is desirable to avoid 
frequent duplicate message displays, I think it is less harmful than 
avoidable loss of messages.

>On the whole, there are lots of matters to fix, as in [[[]]].
>There may be other matters that are not descibed here.

Yes, indeed.  My feeling is that many of these issues will drop out quite 
easily when we have finalized some key outstanding issues.

Thank you very much for your comments.

#g

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

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 10 Mar 2000 10:28:21 +0900 (JST)

Klyne-san,

<snip>

> >   transfer.  It SHOULD also generate a report for the sender

<snip>

> form for ocalized presentation of the problem.

OK. I understand you.

> I think a different report-type would be needed.

Yes

> or is it introducing additional complexity for insufficient gain?

I prefer the simple method.

<snip>

> >'Alternative-preferred' disposition modifier is only defined.

<snip>

> I shall add an additional clarifying NOTE in the document.

OK.

<snip>

> >the first one or the second one.

I mean,
the first try message or the second try message after responding
with 'alternative-preferred'.

> Or, is this to suppress double-printing of a message?

Yes, one reason.

> that the original message was printed after all and (maybe) discard the 

One idea.

> implementation issue, not part of the specfication.)

You may be right. Unfortunately, I do not cover the all cases.
There are lots of cases, I think. Some should be included in it and
Others should not be included(to be implementation issue). I cannot
separate now.

Anyway, I look forward to the updated version.

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