Subject: PNDN (draft-ietf-vpim-pndn-00.txt)

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 04 Sep 2000 15:24:01 +0900 (JST)

Folks,

W.R.T. PNDN issue, from the minutes at Pittsburgh,

FAX:
> Some members commented that PNDN issue should also be discussed in FAX
> WG. Whether to take it and add in WG charter will be discussed in ML.
> AD agrees to it.

VPIM:
> Clarification: The chair emphasised that we had proposed the deletion of
> IMPORTANT in Critical Content, and so we no longer need PNDNs for this
> purpose, but that no consideration had yet been given to whether we still
> progress Partial Delivery Notifications (and develop Partial Message
> Disposition Notifications) anyway.

To FAX WG people:
Please discuss it, if you're interested in it.

To Eric:
Some FAX WG people do not follow it well.
Could you please explain PNDN briefly?

To VPIM WG people:
Please say somthing in [email-masked],
if you have comments about it.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email-masked]

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 04 Sep 2000 15:24:01 +0900 (JST)

Folks,

To FAX WG people:

To Eric:

To VPIM WG people:

Regards,

---

From: Graham Klyne <[email-masked]>
Date: Tue, 12 Sep 2000 20:07:57 +0100

Tamura-san,

I am going through some _old_ e-mails, catching up on review comments for 
FFPIM.

I think that your comments (copied below, with my responses) have been 
addressed in the -02 version of the content negotiation draft.

If you notice I have missed anything, please let me know.

#g
--

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.

At 05:31 PM 4/12/00 +0900, Hiroshi Tamura wrote:
> > For content negotiation, see the slide headed "The big issue: receiver
> > state management".
>
>If there is a state in receiver, receiver wants to know
>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
>for this purpose.

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"

>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.

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.

>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 ?

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.

>In fact, "State" in receiver is necessary for real implementation,
>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.

>Some should be described. Others remain implementation matter.

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.

--end--

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

---

From: Hiroshi Tamura <[email-masked]>
Date: Wed, 13 Sep 2000 19:30:33 +0900 (JST)

Graham,

Thank you for your mail.

> addressed in the -02 version of the content negotiation draft.

Most of my comments has already been addressed there,
though some may be necessary to modify or add.

<snip>

I think it is better to separate the minimum things for content-negotiation
and the implementation issues such as "state". The implementatios issues
are not normative but informative.
But I think they should be better to describe in the document.

BTW, from the minutes of VPIM WG at Pittsburgh,

> Fax, CONNEG & RESCAP WGs update (Graham Klyne)

<snip>

> The first area covered is content negotiation (which could also be
> applicable to VPIM), which allows a recipient to request an alternative
> form of a message it received.

<snip>

> Action: Fax WG chair to take this discussion to the VPIM and FAX lists.

<snip>

> Work Group Focus - Glenn Parsons
> --------------------------------
> 
> To close, Glenn reiterated the Work Groups focus areas:
> 
> 1. Progress VPIMv2 to draft
> 2. IVM
> 3. The VPIM addenda items including: addressing, directory, IMAP, content
> negotiation

I could not attend the 2nd VPIM meeting. I do not know exactly.
But, the one think I can say is that the idea of content-negotiation
mechanism can also be used for VPIM.

So, for the time being, I recommend you to post in VPIM WG ML
as well as FAX WG ML, for this issue.

Glenn,
is it OK?

Regards,

---

From: Graham Klyne <[email-masked]>
Date: Wed, 13 Sep 2000 13:50:17 +0100

Tamura-san,

>But I think they should be better to describe in the document.

OK, I'll try and ensure some separation in the next revision.
We have many comments to work through!

FYI, I'm hoping to get an updated timely delivery draft out very soon.

>BTW, from the minutes of VPIM WG at Pittsburgh,

[...]

>as well as FAX WG ML, for this issue.

Yes, I think it would be good to cross-post announcements

But I also think it would be better to have any ongoing technical 
discussion in a single place -- and I think the fax WG list is it.

#g

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

---

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 14 Sep 2000 09:27:28 +0900 (JST)

Graham,

<snip>

> FYI, I'm hoping to get an updated timely delivery draft out very soon.

Thanks!

> discussion in a single place -- and I think the fax WG list is it.

OK, I see.
I think there is a large change in the next content-negotiation I-D,
including the chapter structure. I would like the editors to judge
when the discussion should be cc'ed to VPIM ML.

Any other suggestions?

Regards,