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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Andrea wrote on 01/30/2003 05:16:54 AM:
> >    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?

I think that the bit about not actually
having to complete the command is a bit suspect but Ill leave that to other
BEEP savy folks to comment on.

Besides the case in question is not
a failure, its where the CS is told just keep processing while the CUA
waits.

On the bright side, Im finally able
to put a better spin on the question I raised about unbounded commands
now that Ive had a weekend to chew on it.  

As Larry noted (but I didnt absorb until
I was home), the current peer protocols (IMAP, POP3, etc) use a mode where
ALL calls are unbounded and the requestor MUST wait for them to complete
(or the net to disconnect, etc.)  As such those UAs have no real recourse
but to just drop the network connection when the user clicks on Cancel
or takes some action.  This is implicit in their designs and implementations.
 In CAP we have taken the philosophy that commands are generally timed
so that the CUA can be more interactive w/controlling the CS.  As
such I had totally blanked out the need for an unbounded command and I
think that PDAs are not related to that discussion as some suggested.

Ok, so now I grok the scenario for it
(ie: I built a CUA that acts like older UAs and only does unbounded commands)
but Im not sure that preserving that behaviour is a necessary/cool idea.
 If we plan to keep unbounded commands in then we really should devise
a way to issue a CANCEL command so we dont have to basically drop everything
else that is going on on other sessions and reconnect, reauthenticate,
etc.  The command can be pretty simple, have it take the channel and
CMDID as inputs and then it just cancels the current command on that channel
(presumably the unbounded one instead of one that is bounded and thus easily
ABORTable).  Also, given that we allow unbounded commands and bounded
commands I think a couple lines in the draft to the effect of "If
you use unbounded commands then you either MUST wait for them to complete
or you have to do ... " would be nice.  At a minimum we should
probably have a suggestion about the benefits of bounded vs unbounded and
why...  (After all there have to be other folks out there who step
in it just like I did...)

Given that we are building entirely
new UAs and a new protocol here, does anyone see a pressing need to have
unbounded commands?  If we made all commands unbounded then that would
remove the need for an explicit cancel mechanism and some prose in the
draft.  Im flexible either way now but applying the KISS mantra makes
me lean towards no unbounded commands in CAP...  Others??

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

I would expect that a CUA would NOT
set timeouts so high as to be essentially unbounded.  I would also
expect them to not be too low so as to generate lots of excessive traffic
(CONTINUE;LATENCY=1 is a BAD idea...).   Since (nearly?) all of the
responses so far have been "Well I may want to cancel the command
because the user pressed Esc or clicked on Cancel or..." I think that
nearly all of us view the SOP as being bounded commands.    With
current peer protocols like POP3 or IMAP the UA simply terminates the connection
and considers the task done.  This is still an option but not as gentle
as a CANCEL command.

If you think we need a CANCEL command
even for bounded commands Id at least be open to hearing more on that...

Bruce
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...