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

From: [email-masked]
Date: Tue, 4 Feb 2003 15:57:23 -0500

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: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Tue, 04 Feb 2003 15:15:21 -0700

[email-masked] wrote:

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

Yes. That was my argument the PDA is just an example.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards