Subject: Re: CAP-11 is out

From: "G. Barnes" <[email-masked]>
Date: Fri, 1 Aug 2003 16:41:22 -0700 (PDT)

Here are a few problems I've found with the latest CAP draft
(draft-ietf-calsch-cap-11.txt):

The ABNF for a few components (e.g., VAGENDA) specifies a 'last-modified'
element.  I assume this is the same as RFC 2445's 'last-mod' element.  The
old name should be used.

The DECREED property should be included in the ABNF of the property list
for VCAR (section 9.3), but is not.

Similarly, MAXDATE and MINDATE should be included in the ABNF of the
property list for VCALSTORE, but they are not.

ATT-COUNTER should be included in the property list for one or more components,
but I can't figure out whether it belongs in VCALENDAR, VEVENT, or what.

The 'Conformance' section of the MULTIPART property (section 8.22)
says 'This property can be specified in a component', but the rest of
the section makes it seem like the only component it can be used in is
a VREPLY.  If this is so, the Conformance section should read the
same as that for, CAP-VERSION, for example.

I'm mystified as to the meaning of the ITIP-VERSION property.  How does
a CAP server 'support' ITIP?  From what I can read, CAP servers hold
ITIP objects, but it is CUAs that do all the ITIP work.  This property
makes it sound like CAP servers do a lot more to ITIP objects than just
storing, searching and deleting.

Finally, it would be nice if the ABNF for VREPLY listed the properties
that can only be in VREPLY components.  As near as I can read, these are:

  CAP-VERSION
  CAR-LEVEL
  COMPONENTS
  ITIP-VERSION
  MAX-COMP-SIZE
  MULTIPART   [? see above]
  QUERY-LEVEL
  RECUR-ACCEPTED
  RECUR-LIMIT
  RECUR-EXPAND
  STORES-EXPANDED

			Greg Barnes
			Computing and Communications, University of Washington
			[email-masked]
			(206) 685-3295

---

From: Doug Royer <[email-masked]>
Date: Fri, 01 Aug 2003 19:36:46 -0600

> element.  I assume this is the same as RFC 2445's 'last-mod' element.  The

Thanks - fixed.

> for VCAR (section 9.3), but is not.

Thanks - fixed.

> property list for VCALSTORE, but they are not.

Thanks - fixed.

> but I can't figure out whether it belongs in VCALENDAR, VEVENT, or what.

Thanks - I'll update the text to say that it goes into any iTIP
object that is METHOD:COUNTER. (VEVENT and VTODO) at the
same level as METHOD.

I'll also supply updated 2445 ABNF for 'eventc' and 'todoc' for [iCAL]
and updates for related sections in 2446.

> same as that for, CAP-VERSION, for example.

It only goes in a GET-CAPABILITY VREPLY.

I updated the conformance section to look like the CAP-VERSION conformance.

> storing, searching and deleting.

The CS processes VFREEBUSY in CS's that have RECUR-EXPAND=true.

And what if 2446 is updated and it effects VFREEBUSY or some
new component that the CS is supposed to process? That is why it exists.

> that can only be in VREPLY components.  As near as I can read, these are:

replyc           =  "BEGIN" ":" "VREPLY" CRLF
                     any-prop-or-comp
                     "END" ":" "VREPLY" CRLF
any-prop-or-comp = ; Zero or more iana or experimental
                    ; properties and components, in any order.

It would be nice, but the ABNF would be impossible as almost anything
in any order in or out of layers of components can be returned
for a QUERY.

Potentially EVERYTHING and I think ANYTHING can be in a VREPLY.
Some of the VREPLY's can be defined and they are. Others like
the QUERY reply can not be defined.

-- 

  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: "G. Barnes" <[email-masked]>
Date: Mon, 4 Aug 2003 14:51:35 -0700 (PDT)

> new component that the CS is supposed to process? That is why it exists.

Thanks for your reply, Doug.  (Un)fortunately, they only lead to
more questions.

I'm assuming by your reply above that you're referring mostly to
Section 10.8.1, Searching for VFREEBUSY, and the recent VFREEBUSY
mailing list discussion that ended with this message:

  Re: free-busy QUERY - summary (I think)
  http://www.imc.org/ietf-calendar/mail-archive/msg07848.html

It's unclear to me how much of the message made it into the draft,
and how much was meant to.  For example:

In the message, you propose that if RECUR-EXPAND=true, then
VFREEBUSY PUBLISH messages should be thrown away after sending a success
reply.  I don't know if that is in the draft, or if it was supposed to
be.

In the message, you also propose that if RECUR-EXPAND=true, the server
should immediately reply to a CMD:CREATE/METHOD:REQUEST for VFREEBUSY
with the freebusy info in a VREPLY.  I don't know if that's a requirement,
a suggestion, or what.

Anyway, on to less weighty matters:

In the discussion in Section 10.8.1, it is specified what to do if
searching for STATE()='BOOKED' and STATE()='UNPROCESSED when RECUR-EXPAND
is true.  What if STATE is unspecified?  Normally, I gather, this would
search both BOOKED and UNPROCESSED objects.  But it seems to me that in this
case, the semantics for these two states are so different this can only be
an error.  [Alternatively, it could be that one must specify STATE in all
queries, but I don't see that requirement anywhere, and there's probably
a case I haven't thought of where it's handy to be able to do so.]

Section 8.32 RECUR-EXPAND refers repeatedly to the "EXPAND" parameter.
But EXPAND is a property, not a parameter.

Section 5 first says CAP URLs must begin with 'cap', then says they
don't (i.e., they can be relative).  The ABNF also requires absolute
URLs, when it should allow both.

Shouldn't CAP URL be listed as a new property value data type (and be
used as the type of the TARGET property instead of URI)?

Given the object model in Section 3.2, it seems that there should be
restrictions on the TARGET properties for certain component/command
combinations.  For example, VEVENTS can only appear in VAGENDAs, so
you shouldn't be able to CREATE a VEVENT with the target
cap://cal.example.com . But apart from 3.2, I don't see any such discussion
elsewhere.  For example, in the description of the TARGET property or the
CREATE command, or just a general reference back to 3.2 in the description
of CMD (Section 10.1).  It seems to me that the diagram in 3.2 is important
enough that it needs to be reinforced somewhere in Section 10.1

			Greg Barnes

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Aug 2003 16:56:56 -0600

>   http://www.imc.org/ietf-calendar/mail-archive/msg07848.html

I was referring to your question which was:

	I'm mystified as to the meaning of the ITIP-VERSION property.
	How does a CAP server 'support' ITIP?  From what I can read,
	CAP servers hold ITIP objects, but it is CUAs that do all the
	ITIP work.  This property makes it sound like CAP servers
	do a lot more to ITIP objects than just storing, searching
	and deleting.

> reply.  I don't know if that is in the draft, or if it was supposed to

Please read the draft before posting comments on it:-)
It really could not take that long in a text viewing tool
to search for text or produce diff files :-)

> with the freebusy info in a VREPLY.  I don't know if that's a requirement,

When you read CAP-11 (The subject of your email you posted) did
you find it?

> a case I haven't thought of where it's handy to be able to do so.]

If you do not specify STATE() you get both.

The objects returned must comply to RFC-244[46], so each unique METHOD
would be in a separate VCALENDAR object. As that is an RFC-2445
restriction that was fought over and was a big debate, I did not want
to reopen old wounds.

I'll add to "6.1.1.5 STATE()":

   If not specified in a query then both "BOOKED" and "UNPROCESSED"
   data is returned. Each unique "METHOD" property must be in a
   separate MIME object per the [iCAL] section 3.2 restriction.

> But EXPAND is a property, not a parameter.

Fixed - thanks.

> URLs, when it should allow both.

I'll change:

    ...There is no implied structure in a Relative CALID. ...

    Relative CAP URLs are permitted and are resolved according to the
    rules defined in Section 5 of RFC 2396.

To:

    ...There is no implied structure in a Relative CALID (relcalid) ....

    A 'relcalid' is permitted and is resolved according to the
    rules defined in Section 5 of RFC 2396.

I do no see why it would be a new value type.

> used as the type of the TARGET property instead of URI)?

I'll change:

    target   = "TARGET" other-params ":" capurl CRLF

To:

    target   = "TARGET" other-params ":" ( capurl / relcalid ) CRLF

> enough that it needs to be reinforced somewhere in Section 10.1

3.2 says:

    Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s,
    "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar
    properties.

Seems clear to me. I have removed several text sections in CAP
that seem redundant - at the request of this WG and to reduce
the draft down to 141 pages.

With the RECURRENCE-ID debate going on, it seems to me that
not replicating data, text, and information will reduce the
chance of misunderstandings later.

I'll change (10.1.4):

    Formal Definition: A "CREATE" command is defined by the following
    notation:

To:

    Formal Definition: A "CREATE" command is defined by the following
    notation and the hierarchy restrictions as defined in Section 3.2:

--

---

From: "G. Barnes" <[email-masked]>
Date: Mon, 4 Aug 2003 21:39:32 -0700 (PDT)

> >>The CS processes VFREEBUSY in CS's that have RECUR-EXPAND=true.

Having read any text in the draft that appears near the word 'RECUR-EXPAND'
numerous times now, I can see no such requirement in CAP.  Could you please
tell me what you're referring to?

> to search for text or produce diff files :-)

I see now that this proposal made it into the draft, in the last
sentence of the first paragraph of 10.8.1:

    For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "TRUE" and
    have the "VFREEBUSY" component in the "COMPONENTS" value in the
    "CAPABILITY" reply, the CS MUST dynamically create the results of a search
    for the "VFREEBUSY" component at search time when searching for STATE() =
    'BOOKED' items. If searching for STATE() = 'UNPROCESSED' items then the
    [iTIP] object are returned. For these CSs it is the the CS is
    responsibility and not the CUAs responsibility to provide the correct
    "VFREEBUSY" information for a calendar. If a CUA performs a "CREATE"
    "VFREEBUSY" the CS MUST return success and not store the "VFREEBUSY"
    component.

But I'm still confused.  If such a CS does not store VFREEBUSY components,
which "[iTIP] objects are returned" when searching for STATE()='UNPROCESSED'
items?  It can't be VFREEBUSY objects, as there are none to return.

			Greg Barnes

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Aug 2003 11:18:43 -0600

> items?  It can't be VFREEBUSY objects, as there are none to return.

For CS's that have EXPAND=TRUE and this WG wants the VFREEBUSY 'BOOKED'
results to be dynamic. Correct?

When *ever* would the VFREEBUSY 'UNPROCESSED' *EVER* be used?

--

---

From: "G. Barnes" <[email-masked]>
Date: Tue, 5 Aug 2003 11:30:37 -0700 (PDT)

> When *ever* would the VFREEBUSY 'UNPROCESSED' *EVER* be used?

I'm just trying to understand the draft, so I'm hardly an expert.  But that
search doesn't make a lot of sense to me.  I can't say whether it should
return 'no matches', or return an error.

Assuming it doesn't make sense, the paragraph is pretty
misleading and should be changed:  it implies that something is returned
when such a search is done.  I'll take a stab at fixing it:

    If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains
    the "VFREEBUSY" component in the "COMPONENTS" value in a reply
    to the "GET-CAPABILITY" command, then it is the CS's responsibility
    and not the CUA's responsibility to provide the correct "VFREEBUSY"
    information for a calendar.  Therefore,

       If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return
       success and not store the "VFREEBUSY" component.

       Such a CS MUST dynamically create the results of a search for
       "VFREEBUSY" components at search time when searching for STATE() =
       'BOOKED' items.

       If a CUA searches for "VFREEBUSY" components with STATE() =
       'UNPROCESSED', such a CS MUST return a "VREPLY" with no components.

       If a CUA searches for "VFREEBUSY" components without specifying
       the STATE, such a CS MUST return the same result as if
       STATE()='BOOKED' had been specified.

--------------------------------------------------------

I'm a little unclear as to whether a 'VREPLY with no components' is
the proper way to return 'no matches', and I may have violated a formatting
convention or two, but otherwise that seems to cover everything.
Alternatively, if the UNPROCESSED search should cause an error, the third
clause could be changed to:

       If a CUA searches for "VFREEBUSY" components with STATE() =
       'UNPROCESSED', such a CS MUST return REQUEST-STATUS with code
       6.3 (bad args).

I don't know if 6.3 would be the proper return status; it's
the closest fit I could find from Section 10.11.

I assume you will answer my first question later?

			Greg Barnes

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Aug 2003 14:53:26 -0600

Thank you. If there are no objections I'll use the text you supplied.

--

---

From: [email-masked]
Date: Tue, 5 Aug 2003 16:50:33 -0400

> When *ever* would the VFREEBUSY 'UNPROCESSED' *EVER* be used?

2 cases come to mind:

1: Some CUA did a CMD:CREATE of a VFREEBUSY into your queue (much like 
they CREATE an METHOD:REQUEST VEVENT to invite you)
2: If there is iMIP delivery into the users queue then you have to get 'em 
out somehow. 

I suspect that anything that can be CREATEd in your queue needs to be able 
to get searched for so you can remove 'em, process 'em, etc.  Although we 
dont have iMIP -> CAP designed now, it may be possible in the future (CAP 
creation is not the only way to get 'em into your queue essentially).

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.