Subject: CAP: Last Call By March IETF: Need Volunteers!

From: George Babics <[email-masked]>
Date: Thu, 10 Jan 2002 14:15:32 -0500

Hello,

We would very much like to have a last call for CAP
that we can present at the next IETF meeting (March 17-22, 2002).
To do so, we would have to have complete the CAP draft by mid
February, since there is a cut-off period for submissions of
drafts before each IETF meeting.

Note that once we submit CAP to the IETF for last call, it may
take many months before it gets accepted as an RFC. Thus, the sooner
we submit it, the better.

There are a few remaining items for the CAP draft. We need
volunteers who will have time to look at these items and who will
be able to complete them by mid February. Do not volunteer
if you may not have the time to do it in this time frame.

Here is a list of the remaining list of to-dos and issues for CAP:

1) VCAR:
--------
   
   Review and possibly fix VCARs. There is probably much text missing
   in CAP that defines the VCARs. May need add text for decreed VCARs
   (Paul made a proposition on the list on the 7th August 2001.)

2) VQUERY:
----------

   Review VQUERYs. Do they work? Is there missing text/explanation?

3) Extensions To iCalendar:
---------------------------

   Finish adding the definition of new components, properties, 
   parameters, and value types.

4) Response Codes:
------------------

   Make sure all the response codes are consistent and are all defined.
   In section 7 of the draft there is a table of the response codes.
   However, the table may not be complete.

   Furthermore, iCalendar, iMIP, iTIP, and CAP each have their own error
   codes. Do we want them all in a central location?

5) Synchronization:
-------------------

  Investigate if there is enough in CAP to allow for synchronization?
  I believe this is in the requirements doc.

6) How to Get UPN From An Authentication:
-----------------------------------------

  We need one or more examples for getting the UPN from
  an authentication.  Also, we need an example for the "identify" command
  (6.1.3). Paul has initially volunteered to do this. Paul?

7) Security Considerations Section:
-----------------------------------

  Finish the "Security Considerations" section.
  Paul, can you handle this one?

8) Specifying CUA iTIP Handling:
--------------------------------

  Do we need to add text specifying how each iTIP method
  should be handled by a CUA? Is the text in iTIP enough
  or are there things we need to add, otherwise there will
  be problems with interoperability?

  I think Doug has addressed this in a recent post.

  Furthermore, can we properly handle all methods?
  For instance, if the CUA is replying to a COUNTER,
  where is the address of the person to reply to stored?
  (This may have ben discussed on the list before. Yet,
  I am not sure if any consensus was reached.)

9) Transparency Of Scheduled Components:
---------------------------------------
   
  What should be the default TRANS for scheduled components?
  Should it be TRANSPARENT? However, a user may want to allow
  events scheduled by certain users, such as a boss, to be
  automatically set to OPAQUE. (This may also have already been
  discussed on the list. Has a consensus been reached sometime
  in the past?)

10) Fixing the calid:
---------------------

  What format should we use for the CALID? Should it be utf8?

11) To Do List:
---------------

  There are also a few smaller issues on the to do list at:
  http://calsch.org/ietf/cap-ToDo.html.

12) Currently Being Discussed:
------------------------------

  There are a number of other issues currently being discussed,
  such as "RELATED-TO vs CHILD/PARENT." Hopefully, we will close
  them very soon.

13) VFREEBUSY Components:
-------------------------

  Can they be stored on the server? Should they always only
  be computed and never stored? Is there enough in the draft
  to detail how they should be handled?

If there are things that I have missed please let me know.

Thus, we need volunteers who can come up with a proposals
very soon, and who are sure they have time to dedicate in the near
future.

George

---

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 16:17:35 -0700

>    (Paul made a proposition on the list on the 7th August 2001.)

As in "what are decreed VCARS?" I read the draft and understood
them. What are the questions?

> 2) VQUERY:

Also, we need to pull back out from the dust cap-requirements
and make sure that SQL-MIN meets those requirements. I think
(based on recent input) that it may need some tweaking. 

And we may need to add text that says SQL-MIN is only designed
to do the following "list" of things. For everything else, the CUA
must do the work or you have to implement SQL-92.

> 4) Response Codes:

No we can't. That would imply that all documents must
be in sync with each other. And that will never happen.

> 5) Synchronization:

It is. I think it does meet the synchronization requirements.
And we limited synchronization to a bare minimum. That is
that you must be able to upload and download an entire calendar
and what ever it takes to make two calendars look the same.

> 6) How to Get UPN From An Authentication:

A UPN may be the same as the authentication id, or could
be something generated by the system. I thought we left
it vague as the system and system administrator assign id's,
not CAP.

>   should be handled by a CUA?

Just the opposite. CAP is not iTIP. CAP just stores the objects
CAP itself does not do scheduling.

> Is the text in iTIP enough

:-)

> 9) Transparency Of Scheduled Components:

I think that falls into the category of bots doing things
for you on your CS (yet another CUA). So I say that it gets
stored "as is", and the CUA (bot or not) does its thing.
If the bot says it is OPAQUE, then it is OPAQUE. But until
it is booked, it is NOT scheduled and it is only a pending
schedule request sitting in your server.

> 10) Fixing the calid:

Do you mean eight bit clean? I would say yes.
However we also list it as a URI, and they are not.
How about we state that it is a URI and implementations
SHOULD accept 8-bit CALIDs so that when URI's are 8-bit
ready - they will not have to change their implementations.

A problem is copy/paste. How do I email you an 8-bit URI
if no one can handle them at this time? How would you
cut it from your email and paste it into your CUA?

We should make the implementator aware that 8-bit URI's are
hopefully on their way.

>   Can they be stored on the server?

Yes - they can. 

> Should they always only  be computed and never stored?

Only the CU/CUA knows the answer. We have not generated
any requirement that a CS MUST o SHOULD be able to do this.
We have not specified any way for a CU/CUA to tell a CS
or to tell if a CS is doing this - lets do an add on
draft on this topic only?

> Is there enough in the draft

It is vague, I think we have to keep it vague until
we add a way tell when, how, if, it is done (later add
on draft).

---

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 19:26:06 -0700

>   I am not sure if any consensus was reached.)

How about we allow the 2445 paramater 'SENT-BY' to be
stored with the METHOD:

	METHOD;SENT-BY=[email-masked]:COUNTER

Then: SENT-BY and allow non-MAIL-TO

(from 2445)
4.2.18  Sent By

   Parameter Name: SENT-BY

   Purpose: To specify the calendar user that is acting on behalf of the
   calendar user specified by the property.

   Format Definition: The property parameter is defined by the following
   notation:

     sentbyparam        = "SENT-BY" "=" DQUOTE cal-address DQUOTE

   Description: This parameter can be specified on properties with a
   CAL-ADDRESS value type. The parameter specifies the calendar user
   that is acting on behalf of the calendar user specified by the
   property. The parameter value MUST be a MAILTO URI as defined in [RFC
   1738]. The individual calendar address parameter values MUST each be
   specified in a quoted-string.

   Example:

     ORGANIZER;SENT-BY:"MAILTO:[email-masked]":MAILTO:[email-masked]

---

From: George Babics <[email-masked]>
Date: Mon, 14 Jan 2002 11:55:16 -0500

Doug Royer wrote:
> them. What are the questions?'

  There were issues about not being able to differentiate them
from regular VCARs.

> be in sync with each other. And that will never happen.

  Thus someone needs to go through CAP and make sure that all
  the response codes are documented and consistent.

> and what ever it takes to make two calendars look the same.

  Have we gone through the exercise of making sure that we
support synchronization? If we limit support to a bare minimum
can it hurt performance of synchronization?

  A CUA is able to query on the last modified LAST-MODIFIED
property to find all the components that have changed the last
time a sync was done. Using the METHOD:DELETE it can find all
components that have been deleted. Is this sufficient?

  Should we add a small section or sub-section on CAP
describing how synchronization can be done?

> it vague as the system and system administrator assign id's,

  From my understanding, BEEP does not clearly specify how an
  application can get a UPN from the BEEP server after authentication
  has been done. Paul?

> CAP itself does not do scheduling.

  We do need to be careful if there is anything we need to specify
in how CAP should handle scheduling. We needed extra specification
to describe how to do iTIP with e-mail, i.e., iMIP. Do we need the
same for CAP?

> schedule request sitting in your server.

  I'm good with this. Other opinions?

> >   Can they be stored on the server?

  Currently, the restriction tables for the create and other
commands do not allow us to store a VFREEBUSY. We should fix
this, unless anyone has objections to storing VFREEBUSY
components.

---

From: Doug Royer <[email-masked]>
Date: Mon, 14 Jan 2002 12:50:40 -0700

>   There were issues about not being able to differentiate them

Proposal:

	As decreed VCARs are hard coded or appear to be hard coded
	in the CS implementation, they can easily be expressed in
	one single VCAR. Such decreed VCARs MUST BE named 'decreed'
	(the CARID).

		BEGIN:VCAR
		CARID:decreed
		GRANT...
		DENY...
		END:VCAR

>   the response codes are documented and consistent.

Yes - right before the next draft push. Else, they have to
do it over and over. George - I assume you will be pushing the
next (07), when you think it is otherwise ready, let me know
and give me a week or so, I volunteer. I don't however want
to do it several times for each push.

> describing how synchronization can be done?

I think that we had agreed that this was an implementation
specific thing for now. At the very least we specified that
a CUA must be able to upload an entire calendar and do the
diff work it self.

No one has opposed a synchronization specification. I say we
need one - AS A SEPARATE DRAFT. For now a CUA can get it done
by uploading the entire calendar - or by guessing from any
VQUERYs it can make.

>   application can get a UPN from the BEEP server after authentication

Why does it need to? That is always going to be an implementation
specific thing.

> to describe how to do iTIP with e-mail, i.e., iMIP. Do we need the

Not for any reason that I can think of, iTIP 'is' how you schedule,
so CAP and any CUA or CS implementation MUST conform to it.
A CS just stores and fetches iTIP data. Only a CUA or CUA-bot (as
I call them) uses the data.

We do need to make sure that the iTIP data is not moved from
the iTIP objects in CAP. (part of the don't move data to commands
debate).

---

From: George Babics <[email-masked]>
Date: Wed, 16 Jan 2002 14:11:21 -0500

> by uploading the entire calendar - or by guessing from any

  However, if there is something that we can easily add to
CAP that can help synchronization, we may want to add it. On the
other hand, what I described earlier, on how a CUA can have
basic synchronization, by using query on last modified time
and METHOD:DELETE, should be enough.

  Thus, if there are no objections, I will close the issue.

George