[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CAP 10: 10.1. CAP Commands (CMD)
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: 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...