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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug replied on 02/04/2003 05:25:05 PM:
>     CMD: ABORT
> 
>     Purpose: The "ABORT" command is sent to request
that the named or
>     only in process command be aborted.  Latency MUST
not be supplied
>     with the "ABORT" command.
> 
> Use ABORT as it has no restriction that it can only be sent after
> a timeout.

Hmmm.  From Section 10.1.1 Bounded
Latency:

If the command is unable to be completed in the specified
amount of time (as specified by the "LATENCY" parameter value),
then a "TIMEOUT" command MUST BE sent on the same channel to
which there MUST BE a an "ABORT" or a "CONTINUE" command
reply. If the CUA initiated the original command, then the CS would issue
the "TIMEOUT" command and the CUA would then have to issue an
"ABORT" or "CONTINUE" command. [Snip]

Upon receiving an "ABORT" command, the command
must then be terminated. 

The first bit implys (correctly or not)
that the ABORT command is sent in response to the TIMEOUT command.  

Also since the ABORT command only applys
to the channel it is sent on, and the CS is already busy with an unbounded
command, I dont see that the ABORT will effect the unbounded command that
the CS is processing.  I dont find any requirement that the CS process
pipelined commands out of order or concurrently.  That is, if the
SEARCH is unbounded and then the sends an ABORT on the same channel, I
see no text/requirement that the ABORT command get acted on until the SEARCH
is done.  Catch-22, the ABORT command wont be seen (since no TIMEOUT
command was sent by the CS and then waited for) until after the unbounded
command is done thus negating the need for ABORT..

I see that in Section 10.1.2 it says:

Purpose: The "ABORT" command is sent to
request that the named or only in process command be aborted. 

so Im wondering if "only in process
command" is meant to refer to the current command on that channel
or to a command that has no ID (or both?)?...  

Also, it talks of "the named...command"
so checking ABNF shows:

abortparam   = *(
                
     ; the following are optional,
                
     ; but MUST NOT occur more than once

                
       id-param
                
     / localize-param

                
     ; the following is optional,
                
     ; and MAY occur more than once

                
     / other-params
                
     )

However, the definition
of id-param is:

id-param        
= ";" "ID" "=" unique-id
                 ; The text value
supplied is a unique value
                 ; shared between
the CUA and CS to uniquely
                 ; identify the
instance of command in the
                 ; the current
CUA session. The value has
                 ; no meaning to
other CUAs or other sessions.

Its intended use is to
sync up replys to commands (mainly in the event of multiple commands at
the same time but not even for single command cases too).  In the
ABORT case it is NOT identifying the ABORT command but rather the other
command that the sender is trying to abort.

Some prose to this effect
should be added to the ABORT command so that its clear that CMD;ID="FizBin1":ABORT
is trying to indicate "Terminate the command named FizBin1 on this
channel" rather than identifying the ABORT command so that a response
can be matched up to it.  This though is overloading id-param and
prevents the sender from being able to match up the proper XXX-reply to
the command..  

After all, its possible
that the unbounded command FizBin1 completes before the ABORT command is
received.  So then the ABORT sender has to decipher the responses:

BEGIN:VCALENDAR
TARGET:relcalid
CMD;ID=FizBin1:REPLY
VERSION:2.0
PRODID:-//someone's prodid
BEGIN:VREPLY
BEGIN:VEVENT
REQUEST-STATUS:4.1;Im sorry Dave\, I cant do that...
END:VEVENT
END:VREPLY
END:VCALENDAR

from

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//someone's prodid
TARGET:relcalid
CMD;ID=FizBin1:REPLY
BEGIN:VREPLY
REQUEST-STATUS:2.0.3;I did as you requested.
X-IBM-WIDGET:Command was
processed by CS1 within 10 seconds.
END:VREPLY
END:VCALENDAR

as belonging to the ABORT
command or the command that was asked to be aborted or to the command itself.
 Can you match them up quickly and correctly?

> Minimum latency - no. 20 years ago 56K direct
internet was screaming fast.
> In 10 years 5 seconds may be too long. The CS can always send an
> error back when it can not handle the command.

Larrys case is not an issue with the
CS not being able to handle the command; its a desire to avoid having clients
just keep pecking at it with tiny CONTINUE values resulting in the CS spending
more time doing more TIMEOUT/ABORT/CONTINUE handling than actual CREATE/SEARCH/etc
command handling.  

As the CS has to scale up to handle
thousands of users concurrently (ie: Enterprise sites) then having CUAs
all do CAP commands with tiny expected response times becomes a burden
to the CS.  There is only so far that relying on very very beefy MP
boxes to efficiently handle lots of threads can take us.  

I was merely asking Larry if he thought
that the needed to be some way for the CS have some say in the process
instead of letting the CUA be the sole source of control when deciding
acceptable latency values.  I could see this as a useful GET-CAPABILITY
response.  

For example, under light loads the CS
would send back "I should be able to process commands with a latency
value of 2 seconds just fine." but under peak loads it would send
back"I should be able to process commands with a latency value of
40 seconds just fine."  That way the requesting CUA can at least
indicate to the CU that operations may take longer or even better, adjust
their "Continue for 10 seconds", "Continue for 30 seconds",
"Continue for 60 seconds" algorithms that Larry mentioned to
accomoate the CS's load.

All this is not unreasonable to consider,
especially if we plan to implement this on larger scale systems...  I
am merely asking Larry if he thinks its something CAP needs.

> > Or perhaps you are thinking that bounded
> > latency is too much to do and that it should be optional entirely
(ie: 
> > All CAP commands follow the existing POP3/IMAP/LDAP/etc model
of 'Its 
> > done when its done and if you dont want to wait then leave.")??
> 
> Adding latency is optional.

Yes it is and if the CS is busy processing
the unbounded command then its not going to be able to process the ABORT
command (see above).  Thats why the peer protocols cited have no ABORT
analogs, they simply drop the link and reestablish it.

FMI: Can ABORT be used to cancel commands
that have no id-param?   For example, if the CREATE command in Section
10.1.4 has no LATENCY or ID property parameters:

BEGIN:VCALENDAR
PRODID:-//someone's prodid
VERSION:2.0
CMD:CREATE
TARGET:cal.example.com
BEGIN:VAGENDA
CALID:relcalz1
NAME;LANGUAGE=en_US:Bill's Soccer Team
OWNER:bill
CALMASTER:mailto:bill@xxxxxxxxxxx
TZID:US/Pacific
END:VAGENDA
BEGIN:VAGENDA
CALID:relcalz2
NAME;LANGUAGE=EN-us:Mary's personal calendar
OWNER:mary
CALMASTER:mailto:mary@xxxxxxxxxxx
TZID:US/Pacific
END:VAGENDA
END:VCALENDAR

Just how would my CUA ABORT it?  CMD:ABORT
on the same channel?  Without requireing some form of command concurrent
processing or pipelining in the CS, this isnt doable.  The only simple
solution is the one used in peer protocols (Disconnect/reconnect/reauthenticate)...

Bruce
PS: In
answer to my examples: The former response is the CS's response to the
unbounded command and then latter response is the response to the ABORT
command; both were taken from draft 10 12Jan2003 examples with just minor
tweaks...
==========================================================================
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...