Subject: Bunch of CAP comments

From: John Stracke <[email-masked]>
Date: Tue, 12 Dec 2000 19:21:56 -0500

I just reviewed the CAP draft for the first time in a while, so
I have a bunch of comments.  I grouped all the typo-level stuff
together at the end.

"The hierarchical calendar feature is not a storage relationship
of
the calendars within the CS." -- perhaps "not necessarily"?
Storage
is, of course, an implementation issue, and an implementation
might
choose to use hierarchical storage for hierarchical calendars.

"A CU's UPN MUST never be deliverable to a different person." --
this
is not an appropriate MUST for CAP, since (a) it has nothing to
do
with CAP interoperability and (b) it's unenforceable anyway.

"For Calendaring and Scheduling Systems that are integrated
with a directory system, the CS MUST support the ability to
configure which schema attribute stores the UPN. The CS MAY
allow one or more attributes to be searched for the UPN." --
again,
this strikes me as an odd requirement; I can't see how it's
relevant
to achieving interop.

"CAP implementations MUST support anonymous authentication," --
admins
may want to be able to turn this off.  Given that, implementors
may
want to leave it out altogether, if none of their customers use
it.

"VCARs specified in a calendar or a sub-calendar override all
inherited VCARs." -- does this mean that there is no attempt to
merge
them at all, so that, if a subcalendar specifies any VCAR, no
inheritance occurs?

"<csid> is the Calendar Store ID. It is the network address
of the computer on which the CAP server is running." -- or
hostname,
right?

"<relativeCALID> [...] is an arbitrary string of 7 bit ASCII
characters." -- except that it can't contain any character which
is
not legal in a URI.

    cap://calendar.example.com/user1
    ://calendar.example.com/user1
    user1

All these are equivalent.  Do we really want this level of
flexibility? It's not like HTML, where there's a need for
relative
URLs so that documents can be moved around together.  CAP is
strictly
an on-the-wire protocol, generated and consumed by software, not
humans.  The more options there are, the more opportunity there
is to
get things wrong.

    Once the STARTTLS command has been
    successfully executed from either the Connected or
    Authenticated state, it must not be executed again.

    If an AUTHENTICATE command is successful, the connection
    enters the Authenticated state and then immediately goes to
    the IDENTIFIED state.

So, if the connection moves immediately from Authenticated to
Identified, how can STARTTLS be used in the Authenticated state?
Come
to that, what *is* the Authenticated state if you leave it as
soon as
you enter it?

    When the server is unable to complete the command
    in the maximum latency time, it issues an appropriate reply
    code and waits for the CUA to tell it how to proceed.

Does "wait" mean it suspends working on the request? Also, it
strikes
me that supporting these latency limits may turn out to be very
difficult for some styles of implementation (e.g., one
single-threaded
process per connection); can we get a capability to let the CUA
know
that latency limits will be ignored?

"When a timeout occurs, the server drops the connection to
the CUA." -- perhaps there should be some way of telling the CUA
that
it's hit the idle timeout, so it can distinguish between a
timeout and
a server crash?

       (3) There is no ORDERBY.  Sorting will take place in the
    order the columns  are supplied in the command.

       (4) The CS MUST sort at least the first column.
    The CS MAY sort additional columns.

What if the CUA doesn't need sorting on some of those columns? I
don't
want to waste CS computrons on sorting that won't help anybody.

     QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
      WHERE VALARM.TRIGGER >= '20000101T030405Z'
      AND VALARM.TRIGGER <= '20001231T235959Z'

This syntax looks like it would have trouble with events that
have
multiple VALARMs (permitted in iCalendar: see Section 4.5.1 of
RFC-2445).  I don't think it's a legal subset of SQL, either,
since
you're using VALARM.TRIGGER although you aren't selecting FROM
VALARM.  (I could be wrong about that, though; my SQL knowledge
is
somewhat narrow.)

    responseCode [sep transportDescr sep [applicationDescr]]
    CRLF "." CRLF

I think you left out the ABNF for the body of the response.

    If CMDID is not supplied then the fist command that is still
    pending is aborted.

(a) "first", not "fist"

(b) If there was one command pending, and ABORT reached the
server
after that command was already completed, then the "the first
command
that is still pending" will be the ABORT itself.  The ABORT will
be
aborted, and no response will be sent.  This in itself is kind of
a
silly objection, but it does point up:

(c) If there was more than one command pending, and the CUA
wanted to
cancel the earliest one, it can't safely use ABORT without a
CMDID,
because the earliest one might complete before the ABORT reaches
the
server, in which case it'll cancel the wrong one.  For this
reason, I
believe that ABORT without a CMDID should be disallowed; its
results
are too unpredictable to be safe.

    The CUA may not issue the "AUTHENTICATE" command multiple
    times, even if the first attempt was aborted. If a CUA
    attempts to do this the CS must terminate the session.

Does this mean that, if AUTHENTICATE is aborted, the session must
be
terminated immediately?

       S: BEGIN:VCALENDAR
       S: PRODID:-//ACME/CAPserver//EN
       S: VERSION:2.1
       S: IDENTITY=[email-masked]
       S: CAPVERSION=1.0
       S: ITIPVERSION=1.0
       S: AUTH=KERBEROS_V4
       S: AUTH=DIGEST_MD5
       S: CAR=CAR-FULL-1
       S: MINDATE=19700101T000000Z
       S: MAXDATE=20370201T000000Z
       S: END:VCALENDAR

Um...those "FOO=bar" lines don't look like iCalendar to me.
Should
they be "FOO:bar", maybe?

       C: CALIDEXPAND cap://cal.example.com/calid14
       S: 2.0 cap://cal.example.com/calid14
       S: cap://cal.example.com/calid2
       S: cap://cal.example.com/calid5
       S: cap://cal.example.com/calid66
       S: .

The response doesn't seem to be properly terminated; 4.3
seems to say that there should be two more <CRLF>.<CRLF>
sequences, on
every response.

       C: CALIDEXPAND cap://cal.example.com/calid76
       S: 2.0 cap://cal.example.com/calid76
       S: cap://cal.example.com/calid3
       S: cap://cal.example.com/calid12
       S: cap://cal.example.com/calid21
       S: cap://cal.example.com/calid33
       S: 2.3 Expansion resulted in too much data
       S: .

This is using a syntax which doesn't seem to meet 4.3: inserting
an
extra status code later in the response.  It's not clear how the
CUA
is meant to recognize it as a status code rather than part of the

arguments.

      BEGIN:VCOMMAND
      [VQUERY]
      OLD-VALUES
      NEW-VALUES
      END:VCOMMAND

Why is OLD-VALUES needed? What if I want to change a bunch of
events
(selected by the VQUERY), but the OLD-VALUES are different for
each
one?

    [EDITORS NOTE: This section needs to be completed by
    adding the restriction tables for each of these iTIP
    methods. The basis for the text is to be taken from
    [iTIP].]

Wouldn't it be better just to reference iTIP?

    7.2.2.2. PUBLISH

    [...]

    This method is used to move a calendar within the CS's
    hierarchy of calendars. If the CU wishes to keep the

I think you have a copy-and-paste error; this is the same text as

MOVE.

      the list or elsewhere have not been addressed. The Method
    Reviewers
      decision to reject a proposal can be appealed by the
    proposer to the
      IESG, or the objections raised can be addressed by the
    proposer and the
      proposal resubmitted.

      [EDITORS NOTE: John Stracke to review any updates]

I think this suffers the same bug as the iCalendar text: the
Method
Reviewer has the power to accept any proposal without possibility
of
appeal.

Editorial nits:

"In it's simplest form it looks like" -- "its", not "it's".

"In this mo del, VSCHEDULE" -- "model".

">From RFC-2459, section 4.1.2.6 (Subject):" -- you sent this by
email, didn't you? :-) Delete the ">".  Also, I would indent the
block
quotation which follows; it's hard to tell where it ends.

"The CS SHOULD not preserve UG expansions across operations." --
SHOULD NOT.

The examples of user groups at the end of 2.4.3 appear again at
the
end of 2.4.5, where they make rather less sense.

"The CUA may have issued the SENDATA command" -- left out a D in
"SENDDATA".

"This section describes CAPs selecting" -- left out the
apostrophe in
"CAP's".

    This query selects the entire contents of every booked
    VEVENT that has an instance less than or equal to July 31st,
    2000 23:59:59 Z and greater than or equal to July 1st, 2000
    00:00:00 Z

     BEGIN:VQUERY
     EXPAND:TRUE
     QUERY:SELECT *
         FROM VEVENT
      WHERE RECURRENCE-ID >= '20000801T000000Z'
      AND RECURRENCE-ID <= '20000831T235959Z'
      AND METHOD = 'CREATE'
     END:VQUERY

Should that be "August" rather than "July"?

"In the examples below, lines preceded with "S:" refer to the
sender and lines preceded with "R:" refer to the receiver." -- in
the
actual examples, "S:" seems to mark lines from the server, while
"C:"
marks lines from the client.

"5  TLS not supported" -- looks like that should be "6.5".

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |I will not buy this .signature, it is scratched.|
[email-masked]|                                                |
\=================================================================/