Subject: CAP 10: 10.1. CAP Commands (CMD)

From: [email-masked]
Date: Wed, 22 Jan 2003 16:48:17 -0500

In looking at the ABNF in the latest draft (nice job Doug) I noticed 
something I consider to be a problem w/the ABNF in the draft.  See:

10.1. CAP Commands (CMD)
...
Description: All of the command to the CS are supplied in this property. 
The "OPTIONS" parameter is overloaded and its meaning is dependent on the 
CMD value supplied. 

Formal Definition: The property is defined by the following notation: 

cmd              = "CMD" (
                 / abort-cmd
                 / continue-cmd
                 / create-cmd
                 / delete-cmd
                 / generate-uid-cmd
                 / get-capability-cmd
                 / identify-cmd
                 / modify-cmd
                 / move-cmd
                 / reply-cmd
                 / search-cmd
                 / set-locale-cmd
                  ) CRLF

The concern I have is that there is no room for any future commands.  That 
is, there is no iana-token (or x-token??) in the CMD value.  As such there 
is no possibility to allow new commands so that older CSs will react 
consistantly to them.

I think we should be allowing iana-token (or iana-cmd if you prefer to 
define it) and clearly state what the Receivers response MUST be to 
unknown command (or unsupported commands!).

Currently several commands are flagged as "MUST BE implemented by all CSs
".  This list in draft-10 is:

CREATE
DELETE
GENERATE-UID
GET-CAPABILITY
IDENTIFY
MODIFY
MOVE
REPLY (although this is technically NOT a command!)
SEARCH
SET-LOCALE

I find it someone odd that not every CS MUST support ABORT and CONTINUE. 
If all of the CAP 1.0 defined commands are MUST to support then a single 
line of text in Section 10.0 is probably the way to go instead and any 
command that is NOT mandatory to support should be required to expressly 
define itself that way (and iana-cmds are that by default!).

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: Wed, 22 Jan 2003 20:51:08 -0700

> something I consider to be a problem w/the ABNF in the draft.  See:

Thanks! :-)

> The "OPTIONS" parameter is overloaded and its meaning is dependent on 
> the CMD value supplied.
> 
> The concern I have is that there is no room for any future commands. 
>  That is, there is no iana-token (or x-token??) in the CMD value.  As 
> such there is no possibility to allow new commands so that older CSs 
> will react consistantly to them.

Good point. I'll add x-cmd and iana-cmd.

--

  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

---

From: Doug Royer <[email-masked]>
Date: Wed, 22 Jan 2003 20:54:22 -0700

[email-masked] wrote:
 > ...
> 
> Currently several commands are flagged as "MUST BE implemented by all 
> CSs".  This list in draft-10 is:
> ...
>  If all of the CAP 1.0 defined commands are MUST to support then a 
> single line of text in Section 10.0 is probably the way to go instead 
> and any command that is NOT mandatory to support should be required to 
> expressly define itself that way (and iana-cmds are that by default!).

I seem to recall objections that all CS's must support bounded
latency. When we merged iRIP and CAP we agreed that we would
add bounded latency to CAP and not make it required. A palm
pilot for example I do not think can do bounded latency.

Do we need a new CAPABILITY?  SUPPORTS-LATENCY / boolean ?

--

---

From: [email-masked]
Date: Fri, 24 Jan 2003 10:53:49 -0500

> Do we need a new CAPABILITY?  SUPPORTS-LATENCY / boolean ?

Ill have to do some searching to check on that (Vacation induced 
relaxation is not totally worn off yet). 

If a CUA does not support latency then just how would it be able to 
control/stop a command it issued?  That is, if the Palm CUA sent a search 
that was taking a long time (a very busy and impatient exec) and the CU 
wanted to stop the action then just how would the CU/CUA be able to do 
that if they didnt support at least ABORT?  (Clearly CONTINUE is irrelvant 
to this discussion).  The only way if ABORT is not supported by all 
implementations is to disconnect from the CS and then reconnect back... 
Ack!

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Fri, 24 Jan 2003 18:03:39 +0100

> implementations is to disconnect from the CS and then reconnect back... 

For that matter, since we're using BEEP, it can simply close the
channel and open a new one, no need to drop the session.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
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

---

From: Doug Royer <[email-masked]>
Date: Fri, 24 Jan 2003 10:40:50 -0700

[email-masked] wrote:
> control/stop a command it issued?

My email said that the CS might not support LATENCY, I
describe both:

Many PDAs for example have a time out or alarm then they simply
assume the remote end is not responding. That seems to
be inherent to some implementations. They do not want the
user to have to wait for another time out period sending
an ABORT that may also time out because the other endpoint
is down.

Any CUA may send an ABORT. As CELL based CUA's use air time
(like my Kyocera), I do not want to wait for a few more minutes
to see if the other end is responding. Simply disconnect.
As a user I would be happy if the PDA asked me if I wanted
to wait longer. But many cell-PDAs are not that smart.

And some CS's might not support LATENCY. If my cell-PDA contacts
your cell-PDA - one will be a CS and it might not be able to
do timed calculations. That is I can set the time out on the cell-PDA
but that aborts the transaction and connection and no way to
send an ABORT or TIMEOUT.

 > That is, if the Palm CUA sent a
> search that was taking a long time (a very busy and impatient exec) and 
> the CU wanted to stop the action then just how would the CU/CUA be able 
> to do that if they didnt support at least ABORT?  (Clearly CONTINUE is 
> irrelvant to this discussion).  The only way if ABORT is not supported 
> by all implementations is to disconnect from the CS and then reconnect 
> back...  Ack!

In some PDAs that is the only option.

--

---

From: [email-masked]
Date: Mon, 27 Jan 2003 16:06:40 -0500

> channel and open a new one, no need to drop the session.

Sure thats just as valid. 

It does however have the undesirable side effect of keeping the unwanted, 
unbounded, uncontrollable command going since the CUA is still connected. 
(And the CS may refuse to drop the erant BEEP channel if there is an 
active command on it or at least it should if I grok BEEP prose well 
enough...)

I would expect that a good CS would take steps to make sure to detect CUA 
disconnect and deal with it like aborting in progress commands, doing 
session related cleanup, etc.  Having the CUA create a new channel though 
would NOT cause the same to happen so the unbounded command would continue 
its rampage...

Bruce

---

From: [email-masked]
Date: Mon, 27 Jan 2003 16:34:07 -0500

...
> assume the remote end is not responding. 

Ok, Im trying to not be dense but your PDA w/alarms CAN do latency since 
it obviously has the ability to deal with time outs, etc.  Is there a real 
case where a CUA does NOT have this ability and is it a likely candidate 
for hosting something as robust as CAP?  (Ok I digress a bit but it helps 
me think sometimes...)

>                                      They do not want the

Umm, network disconnects were not part of this discussion so far; lets 
keep it simple and just focus on the case of controlling unbounded 
commands.

> to see if the other end is responding. Simply disconnect.

I havent seen any text/requirement that a CS must support multiple 
concurrent commands on the same BEEP channel.  As such, if the unbounded 
command is going on then when would/should/can/MUST(?) the CS do any 
command polling for new commands on the same channel to detect the ABORT 
command?  (Is this something in BEEP that Ive just overlooked or forgotten 
over the holidays?)

> send an ABORT or TIMEOUT.

Is it really likely that a PDA that has no ability to do timers or alarms 
is going to really host a CS??  Doesnt sound like it to me.  Sure, there 
will be someone out there who may want to write one to prove me wrong but 
they wont be anywhere near the majority I bet.

Hmm, your last bit sounds like it agrees with my question about about 
being able to send an ABORT to a CS who is going unbounded.  But I think 
its slightly different too.  One case is a CS cannot support latency (and 
Ive yet to see an example of a 'server' CS that would not be able to 
support latency) and the other flavor is that both sides DO support 
bounded latency but the command was NOT bounded.  Just how is the latter 
case controlled short of disconnecting?

> In some PDAs that is the only option.

Thats like telling a user they have to reboot their computer to exit from 
their mail reader.  Ugh!! 

Still, if that is the only option then I think we should put that into the 
draft as a big cavat to bounded latency so its perfectly clear what the 
consequences are of unbounded commands.

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Mon, 27 Jan 2003 23:57:37 +0100

> unbounded, uncontrollable command going since the CUA is still connected. 
[...]
> would NOT cause the same to happen so the unbounded command would continue 

I agree opening a new channel wouldn't cancel outstanding commands -
but closing one had better! I'm not talking about forcefully
dropping a connection; rather, about sending the other party a
notification that we're about to close (or that we'd like to close
it, if you prefer; a BEEP peer could still deny the request, as you
mentioned).
Do you have in mind a specific BEEP implementation which doesn't
allow you to do clean shutdown? The one I'm using most surely does,
and my CS is taking advantage of that (even the very dumb one I
am going to release as part of libical).
Of course, once your server is notified of the channel shutdown,
there's still the problem of actually stopping the runaway
process - but this depends solely on your server architecture.

Anyway - I'm not advocating that we should go this way. It's just
that any alternative gets complicated pretty quickly. After all,
it seems to me aborting a command should be an exceptional event
(like the CU pressing a cancel button on a 'wait' dialog, or
outright quitting the app) and less common than use of bounded
latency.
For instance, imagine we add a CANCEL command. First of all, if
there are multiple channels open, where do we send it? On the
same channel I guess, but what if the CS was stuck in a state
where it doesn't react on that channel only (quite possible in
a multithread server)? Or do we introduce the concept of a control
channel (I hope not, and forget I mentioned the possibility)?
Should we put a latency on CANCEL as well?
Also, what if we have several outstanding commands on the channel?
We would need to use the ID parameter together with CANCEL - but
then if a CUA wants to be able to cancel all commands it needs
to keep a list of them (ok, it probably needs to keep the list anyway)...

OTOH, if you see this as a non-exceptional mechanism - that is,
a peer might opt to use CANCEL commands as an alternative or in
addition to LATENCY in normal operations - then we have two ways
of doing the same thing (since you can always transform a timed
abort into an immediate cancel or viceversa).

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Mon, 27 Jan 2003 16:15:35 -0700

[email-masked] wrote:
> it obviously has the ability to deal with time outs, etc.  Is there a 
> real case where a CUA does NOT have this ability and is it a likely 
> candidate for hosting something as robust as CAP?  (Ok I digress a bit 
> but it helps me think sometimes...)

It disconnects on alarm. Too late to send ABORT.

> keep it simple and just focus on the case of controlling unbounded 

My point is that they do not have that kind of control. You
have no choice - on alarm the BEEP connection is terminated
and you can not get in side of it and send an ABORT.

--

---

From: [email-masked]
Date: Wed, 29 Jan 2003 16:41:57 -0500

> it, if you prefer; a BEEP peer could still deny the request, as you

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.

which means that the CUA can try to close the session after the CS 
acknowledges the unbounded command.  However just below that is:

   Otherwise, before accepting the request to close the channel, and
   sending an "ok" message in a positive reply, it must:

   o  finish sending any queued "MSG" messages on that channel of its
      own;

   o  await complete replies to any outstanding "MSG" messages it has
      sent on that channel; and,

   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.

So I still think the only way to terminate an unbounded command is to drop 
the connection to the CS.  Ugh!!  Thats painful and costly...

> allow you to do clean shutdown? 

No, just my reading of the BEEP RFC...

>                                  The one I'm using most surely does,

Ok, then how does that not violate the BEEP RFC cited text above? 

> process - but this depends solely on your server architecture.

You cannot shutdown cleanly if there is an outstanding command so Im at a 
loss to see how you did this w/o violating BEEP.  Is there a BEEP 102 
class I can take??

> Should we put a latency on CANCEL as well?

IF (a BIG IF) we added a CANCEL command then Id say NO (KISS!).  You 
cannot unclick the Cancel button in the GUI can you?  You cannot unpress 
Cmd-. can you?  You cannot intercept the signal to die, etc...

> to keep a list of them (ok, it probably needs to keep the list 
anyway)...

Realistically speaking would you pipeline 2 unbounded commands on the same 
channel??  I would think that you'd do them on separate channels to get 
concurrency instead of serialization...

Sighh.... Taking a big step back here to refocus on the overall picture.

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. 
 In doing a search I found a discussion in relation to alarms or the lack 
of them on some platforms so the context was NOT in processing commands 
but in dealing w/stuff like triggering alarms. 

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.

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

Arrgh!  My head hirts!  %^|

Bruce

---

From: [email-masked]
Date: Wed, 29 Jan 2003 16:51:52 -0500

> It disconnects on alarm. Too late to send ABORT.

If the alarm code just does the disconnect then it can just as easily do 
an ABORT can't it?  What am I missing here?

> and you can not get in side of it and send an ABORT.

This sounds like poor design if some coded alarm system triggers 
terminating the transport layer session rather than the application 
command in progress. 

Also, since there is network latency involved here I find it a bit 
irregular that the PDA would use an internal alarm to do some action 
instead of dealing w/the returned VREPLYs and the possible TIMEOUT command 
from the CS. 

The previously mentioned Palm owner questioned why the PDA app would have 
any timer set since there is network latency involved and the time 
actually starts when the CS begins to process the command NOT when the PDA 
sends it.  (Dumb design to use a local timer that matches the requested 
design when you can pipeline commands and there is latency involved he 
says.)

Besides, if the PDA can do some alarm of some kind then how does that 
justify the use of unbounded commands?  Ill keep searching the archives 
for some more justification since it must have made sense at some point...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 29 Jan 2003 15:27:56 -0700

> terminating the transport layer session rather than the application 

It's a failsafe alarm that can be used by an application
to keep the connection from being held open ($$$) on a pay
by the minute cell phone.

You get -  time out - your app is dead and we did
            a favor and closed the connection even
            if that is not what you want.

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 29 Jan 2003 18:04:21 -0500

From: [email-masked]
   Date: Wed, 29 Jan 2003 16:41:57 -0500
[...]
   So I still think the only way to terminate an unbounded command is to drop 
   the connection to the CS.  Ugh!!  Thats painful and costly...

This is what almost every other IETF application protocol
does. Establishing connections really isn't that costly if it's only
going to happen to what should be "rare" circumstances.

[...]

The addition of "cancel" and "bounded latency" commands are more
complicated than what's present in CAP's peer protocols (SMTP, IMAP,
LDAP, for instance).

Larry

---

From: Andrea Campi <[email-masked]>
Date: Thu, 30 Jan 2003 11:16:54 +0100

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

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

[...]
> use Palm as an example platform when considering building a real CS given 

*nod*

> 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

---

From: [email-masked]
Date: Thu, 30 Jan 2003 14:46:41 -0500

>             if that is not what you want.

So essentially the app has to reset the alarm timer every time it gets 
data from the CS so that the timer does not consider the app dead when in 
fact its just waiting for the CS to return more data?  If it does this 
then it still has no way to terminate the unbounded command on the CS 
short of actual disconnecting.  Right?

Also why wouldn't the Palm, or any CUA for that matter want the command on 
the CS to eventually time out?  I can't think of any scenario where this 
is useful.  Help me!...

Bruce

---

From: [email-masked]
Date: Thu, 30 Jan 2003 15:04:14 -0500

Larry noted on 01/29/2003 06:04:21 PM:
>       Establishing connections really isn't that costly if it's only

Disconnecting and restablishing a connection (and thus reauthentication, 
etc) is much more costly than being able to simply abort the command on an 
existing connection.   Then again unbounded commands should be rare if not 
useless in our world view...

What is a good justification for having a command that is unbounded in how 
long it can take AND has no means for aborting or cancelling it short of 
actual disconnection from the CS?  Getting my head around that would make 
swallowing this much easier...

> complicated than what's present in CAP's peer protocols (SMTP, IMAP,

Adding a CANCEL command does not at first glance appear to be that hard 
really.  It could be as simple as using BEEP channel 0 to send a CANCEL 
command with some info needed like the BEEP channel to cancel on.  We 
could include info like the CMDID to uniquely identify the command w/in 
that channel if we had to.

Still, why invent more stuff if unbounded commands do not make sense given 
our current model?...  Or if we are going to keep unbounded commands then 
we really should expreslly codify the way that a CUA terminates them so we 
have consistant behaviour among all implementations.

I can go with the crowd on most any solution here as long as I can at 
least see the rationale for the answer...

Bruce

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 30 Jan 2003 15:56:37 -0500

Date: Thu, 30 Jan 2003 15:04:14 -0500

It simplifies implementations. (You do want people to implement this,
right?) What happens if you submit a bounded command (3 seconds,
say), wait 3 seconds, and the server doesn't come back? What if it
doesn't come back in 30 seconds?

What if you submit an unbounded command, wait 1 second, submit a
CANCEL, and the server still hasn't replied in 30 seconds?

What if the network is down or tremendously slow?

[...]

How am I, as a client, suppose to know how long something is going to
take the server? Maybe the server is really loaded. Maybe it affects a
lot of data on the server.

The last thing I want, as a server, is for clients to try an operation
for 5 seconds, then try it for 10, then 20, etc., until it's done.

Larry