Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE)

[Andrea Campi <a.campi@xxxxxxx>]

On Wed, Jan 29, 2003 at 04:41:57PM -0500, Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:
> My take on BEEP was that the Listener side would reject the BEEP session 
> close if there was still outstanding I/O on it.  From BEEP, Section 
> 2.3.1.3 The Close Message:
> 
>    A BEEP peer may send a "close" message for a channel whenever all
>    "MSG" messages it has sent on that channel have been acknowledged.

Well, this text is the only real block to clean shutdown, since the
CS doesn't acknowledge the message until it start replying:

   (Acknowledgement consists of the first frame of a reply being
   received by the BEEP peer that sent the MSG "message".)

However, this could easily worked around by a clever implementation
by sending an empty ANS message, so let me ignore this for now. I can
get it back to this later if you so desire.

>    o  finish sending complete replies to any outstanding "MSG" messages
>       it has received on that channel, and ensure that the final frames
>       of those replies have been successfully delivered, i.e.,
> 
> which tells me that the CS wont accept the session close attempt until it 
> finishes dealing w/the unbounded query; there may be outstanding response 
> messages to send back still as the command progresses!.  Im still no BEEP 
> guru so Ill defer to them when Im slapped and corrected otherwise.

This is implementation independent really. Nothing here says you have
to complete processing the query, you only need to send a failure
ANS or RPY to each outstanding command for the channel, before accepting
the shutdown request.

Do you agree or do I have to get into more details?

> The big motivation for not requiring bounded latency was described by Doug 
> as being related to some platforms like Palm not being able to support it. 
[...]
> I went and got 2 others here including a Palm owner and did some marker 
> board presentation about CAP and bounded latency and tried to figure out 
> if this was really an issue for Palms.  Then we realized that the issue of 
> timing out a command is really a CS side issue and NOT a CUA side issue 
> per se.  We also could not think of any realistic case where we would want 
> a command to be attempted possibly forever given we have no way to abort 
> it.  We could find none.  We also agreed that its totally unrealistic to 
> use Palm as an example platform when considering building a real CS given 
> its constraints.

*nod*

> So I must therefore question the CAP design and the rationale for 
> unbounded commands.  If there is no way to terminate an unbounded command 
> short of actual termination of the connection and there is no real world 
> case where an unbounded command is actually useful then why are we putting 
> them into CAP (and not clearly creating an in-protocol means to cancel 
> them)??  If we must put unbounded commands into CAP then there must be 
> some easy way in CAP to terminate them (ie: CANCEL). 

I can understand your points, I can't really question their validity,
however no matter what you do, you will still have to deal with
interactive CUAs which need to deal with a user. A CU might decide
to cancel a command before the latency expires, so we still need a
mechanism for that, right? So this is orthogonal to bounded / unbounded,
don't you agree?


Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@xxxxxxx
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy