Subject: Minutes of NY CAP editors meeting

From: [email-masked]
Date: Tue, 23 Feb 1999 16:42:16 -0500

CAP EDITORS Meeting 

– New York

Attendees:
=========
Frank Dawson, Steve Mansour, Doug Royer, Alexander Taler, Paul Hill, Tony
Small, David Madeo, Pat Egen (Note: Paul Hill  will help provide additional
security expertise)

General minutes comments
========================
These minutes are a summary of activities and decisions from the CAP
editors session held in New York City on February 9 and 10.

One of the goals of this meeting is to take the work that has been done to
date, summarize it and then breakdown what issues are still outstanding.
There is a concern about the time running out for publishing the draft.  It
is critical that we get the draft done and submitted at the July IETF
meeting.

The following key areas were discussed:
=======================================
Calendaring addressing and properties (including fan-out)
Searching and filtering
Protocol syntax (XML/MIME)
Transport (HTTP/TCP/UDP)
Component management
Administration
Access rights/security
Exception handling
Session management.

Deferred discussion items:
==========================
Resource groups and pools
Notification.

General discussion
==================
There will be small breakout sessions at the IETF in Minneapolis to
continue working on refinement of the draft.  Pat Egen will set up these
sessions on the list.

Doug Royer will send out his component management document and Steve
Mansour will work on and send out the CAP model and cal addressing document
to the editors for review.

A posting will be sent to the list for last call on comments regarding
using an XML versus ICalendar protocol syntax.  That posting will appear by
the end of the week of 2/12/99.  There will be a two week limit on
discussion so that a decision can be reached and the list notified.

Pat Egen will check up on the status for the last call for the CAP
requirements document.

Calendaring addressing and properties (including fan-out)
=========================================================
General concensus was reached that the CSID and CALID are both persistent.

The graphic below represents a CALID and CSID

                     |-----------------|Relative CalId
      |--------------|CSID
|--------------------------------------|CalId
cap://cal.example.com/xdjdi3920isd09k2l

Regarding sub-calendars, we need to make a command that understands
parent/children designations.  If we define it so that names have
structure, then a vendor can do whatever they want. The question was raised
to consider using paths.

Note, CALID's are not meant to be seen by a user.

The following is an example of calender CSID's and sub-calendar
representation.

Cal name: = bill/soccer
CALID: = xxxxxxxx (persistent, ascii string)
Persistent CALID drive

Cal name is a "pretty" or displaya name meant for human consumption and
localizable.

Fan-out:
===============
There was general concensus (with one person opposed) that there should be
a protocol requirement to do fan- outs.  We will need to have a definition
of what a calendar fan-out packet should look like.  The calendar store
will handle what it has trusted relationships for.

The valid items stated as opposition to this were:
-We had agreed in the fall to not have it as a must in the requirements.
If we look at combining IRIP and CAP, then
 this is a moot point as IRIP handles fan-out.
-It would certainly add to the complexity of the draft (and hence, the time
it would take to move it towards an rfc)

There must be a calendar store to calendar store protocol in place in
addition to IMIP in order to handle group calendaring.  It needs to be
defined in CAP.  A question is should IRIP and CAP be merged. Should it be
mandatory to do both.  These questions are still outstanding.

Things to consider are:  will most people want to set up guest accounts;
will they take invitations.  Can you look at busy time? Will you allow it.

It was determined that if you implement CAP, you have to implement IMIP so
that you can use underlying email.  It ought to be up to the client.  The
CAP server needs to be able to see the addresses.  When we do the CAP
implementation, we need to be able to put in a IMIP address.

Search and filtering
====================
The next topic discussed was the Search suggestion posted by Frank Dawson
on the list.  The recommendation is to use SQL language because it is a
standard and vendors can get access to code to do SQL.

Here's an example of psuedo code to do a lookup by UID using SQL command
structures.

BEGIN:COMMAND
METHOD: QUERY
BEGIN:VQUERY
SCOPE: VEVENT
QUERYNAME: FETCH BY UID
QUERY SELECT=”UID DTSTART DTEND”
  WHERE (UID EQ123)
   ORDERBY = UID
END:VQUERY

It was determined that in order to use this, we will need better
specifications for MODIFY.

Protocol syntax (XML/MIME/Icalendar)
====================================
Because of the growing interest in XML, we spent quite some time in
discussion about protocol syntax.

Key items from that discussion:

XML usage is growing
The CAP protocol should move towards XML
XML is still evolving and the next version will not support items such as
DTD
Do we offer both XML and Icalendar based protocols
Do we do an addendum that shows how to implement XML, using Icalendar base
as MUST
Timing is a critical factor - the draft must be finished in July
A spin off process to look at the next version of CAP should start soon

As noted above in the minutes, a posting will appear on the list by the end
of the week of 2/12 with a two week deadline on comments.

It was decided that CAP version 1 will have appendix that talks about an
alternate coding in XML.  If there is not a large noise on the list about
XML, then no problem.

Transport (HTTP/TCP)
===================

We need to do an apples to apples comparison of TCPIP and HTTP. We will
work on this during the next several weeks.

It was decided to not consider UDP as a transport consideration (because of
complexity in authentication when packets broken up with little gain).

One of the cons of HTTP is if your protocol involves a lot of short
sequences of text for send and receive, it’s a bit of an overhead to create
a session each time.

Key tranport issues are: Port 80 and HTTP. We can not use the default port
80. We would have to request a specific port address.  The document of IRIP
should be what our transport should look like.

We will refer to IMIP for TCPIP requirements. It was determined we need
someone to write a 6-7 page proposal on using TCPIP.

When doing the HTTP/TCP Proposal we will need to consider the following:

It was decided we need an authentication model and it should contain:
-connection chapter (port number 5229)
- Authentication chapter (framework that is SASL RFC 2222)
- must/mandatory mechanism
- CAN clear–text
- Query examples … shows CUA/CS interactions
- Connect, auth, CAP create
- Fanout example
- Act of behalf of/Proxy issue
- state diagram
- hooks for notification – guidance to implementers – non-normative
appendix

-Needed scenarios
 -Create component
 -Modify Property
 -Create a calendar
 -Create a (1) root cal
          (2) sub cal
 -Delete one of a multi category prop (ie, attendee)
 -Delete one multi-valued props (ie. Categories)

Component management (Commands)
===============================
Here's what is the current component command list:
- Create
- Read
- Modify(updates/cancels/reinstates)
- Delete

Other ADMIN commands are below.

To cancel a group scheduled component in CAP, you use the <MODIFY to go
into the calendar component and change STATUS value to CANCELLED.  The
actual deletion of the calendar component is done by a DELETE CAP command.

Are we going to require sequence numbers like ITIP?  It was determined to
start with it as a base. Doug Royer will look at IRIP to get examples of
exception handling

Example: S  cal/bill  cal/xyz

Do we want to validate a remote address right away.  The protocol needs to
deal with remote handling. Question, how does a referral come back in a
format that can be parsed by code. Using the coding example above, how does
code know that address billybob replaces bob.

Create Command
==============
Discussed was the minimum set of properties required to create a component.
When working with VEVENTS, it was decided that a UID was required.  It may
be appropriate taht CAP include a command (CreatenewUID?) to generate and
return a new UID for use by the client.  This led to further discussions on
multi-threading and labels.  It was generally agreed that CAP commands and
responses should have labels.

It was asked are we going to require every client to know how to generate a
unique id. ICAL states here are the things you can have.

Modify command
===============
Here is an example of the Read/Delete/Modify commands using some psuedo
code.

BEGIN:COMMAND
METHOD: READ / DELETE / MODIFY
BEGIN:VQUERY
SCOPE: VEVENT
QUERYNAME: FETCH BY UID
QUERY SELECT=”UID DTSTART DTEND”
  WHERE (UID EQ123)
   ORDERBY = UID
END:VQUERY
QUERY:

MODIFY (create is always required)

BEGIN:COMMAND
METHOD: MODIFY
BEGIN:VQUERY
…… SET FILTER SELECT=UID  Choice: UID UID UID
END:VQUERY
BEGIN:VOLD
END:VOLD
BEGIN:VNEW
END:VNEW

On the Modify command , we agreed that to cancel events we would not use a
special command "MarkForDelete/Delete", but instead use modify to change
the "STATUS" property of the event.

Exception Handlers
===================
It was suggested that the format on a 10.1 should be 10.1
<oldaddr><newaddr> vs. code;title;helpful text.  We will need to determine
a good standard for exception handling or referrals.  We could use ;
x-lotus-abc;blahblahblah so we can add text, or add new exception.  We pick
a 99 and this is a vendor or user supplied error.

It was decided there will be no non-standard exceptions.

Note: there should be no gratuitous wording like OK – need real response
codes - buffer overflow, Japanese issues, 
banners, etc because of text
required after response. It was found in IRIP there were times you wanted
responses to come back from referrals. This needs to be considered as part
of exception handling.

Administration
==============
A decision had been made previously that CAP would not have anything about
administering servers.  Not everyone wants to do all the admin tasks.  Is
there anything the end user can do.  Moving calendaring is an example of a
key adminstrative issue.

There is some admin commands that we want to have in the documents.  The
user should be able to add sub calendars. We will need to put in a special
check as to whether it is a root level or sub calendars.  Using a Create
command we should be able to create root calendars versus sub calendars.
We need to make it a run level option.   The issue is a root calendar is
like another user or id.  We should not dictate how policy is stated.

The Create command has to have a path command associated with it.  The CAP
requirement needs to provide the capability to create root calendars,
however the vendor chooses to implement the code.

All calendars are identified by their CALIDs.  A possible solution is to
put together a list of calendars to form the path.  All you need is the
parent CALID.

If we come up with a new ADMIN CREATE, we won't need anything else.  In the
body of the command we have parent calendar name and the new calendar name.

Example:

10 CREATE csid(cap://cal.foo.com)  csid/bob(cap://cal.foo.com/bob)
10 2.0
10 Fix cap://barium.foo.com
10 ICALDATA
     Cont-type
     Cr/lf
     ….
     METHOD:CREATE CAL
     BEGIN:VCAL
     Cal properties here: CALID: NAME: PATH:
     BEGIN:VEVENT

So it looks like this (with a small command set)

BEGIN:VCALENDAR
METHOD:CREATE  CAL
RCALID:BILL
NAME: /BILL   = display name, localizable
BEGIN:….
END:….
END:VCALENDAR

Notes: CS creates: path to root and parent:

You will need to connect to a store first. This code will have the parent
and you will get back an error if calendar already exists.  This handles
the admin area.  Using the search methods, we can then do some more
properties, names, etc.

It was again stressed that we need to say that CALID is persistent.
We need to say MODIFY is not used to move calendars or change read only.
Do we need a MOVE function? Or can we stand up to the ADMIN function.

It was decided that Version 1 will allow creation of root calendars. If we
stick with moving calendars around in a single store, you can move
calendars around as long as we don’t put the path in the CALID.  This means
the CALID has to be unique.

We will need to make sure CREATE is CREATE COMPONENT or CREATE CALENDAR in
order to keep syntax simple and brief.  So when you add timezones it is a
CREATE not a MODIFY.

Do we need another parameter that specifies scope.  Example: VCALENDAR,
PROPERTIES, etc. In fan-out situations, it would be more beneficial to know
more info up front.

We need parent in the properties of a calendar.  Path is a generated
display text.  It is really important that we keep parent as a property.

General Discussion of Move function
===================================
Example of a calendar Move function:

1.   Change B’s children to C
2.   Change C’s parent to be B
3.   Change A’s child to remove C

The operation needs to be atomic. Therefore we need a MOVE verb and
optional.

Pseudo-code example:

10 MOVE CALID CSID/CALID
Verb definition: move =  label wsp “Move” wsp from-CALID
(/to-csid/to-CALID)

REFFERALS discussion:
=====================
Do we consider Referrals to be a must in CAP? If we ask for a calendar, it
is not explicit that we get a referral.  However, we could say that we need
to force a referral address.

If an implementation supports moving a calendar between calendar stores
then it must also provide support referral exception messages to any CUA
that tries to access the moved calendar, providing the CUA a referral csid
of where the calendar now exists

A vendor can/should allow a user to configure a server to not respond with
a referral or with a fixed referral for all users.

Access rights discussion:
========================
Frank: There are no rights granted a user authentication unless there is a
VCAR property set to give rights.

Code example:

BEGIN:VCAR
GRANT: CALUSER=FRANK;ACTION=READ;POLICY=BUSYTIMEINFO
END:VCAR

Policies will provide more granular control. If we use the policies to
ensure interoperability we must make sure what the minimum semantics are
when you support this policy.

How do we implement ACTIONBEHALFOF. We keep track of organizer and
attendee;

Currently the ICAL spec does not provide audit trail capability. It
resurfaces again now during the discussion of ACTIONBEHALFOF.  If someone
goes in and changes a calendar property, there is no record.  We need to
know who modified the record.  We may need a parameter added on a modify –
last modified and a last modified by. It is at least reasonable to state
who was the last person.  This is still an outstanding area.

You might want to set the caluser to a default of all.  If no caluser is
specified, the answer is none.  We need to say something other than ALL. It
may mean something else in another language.

It was decided we do want multiple owners.  CAP must allow this.

Another concern is if we say we support VCAR grammar, we need to specify a
minimum level of what to support.  Example: I support the grammar; however,
I only deliver blahblablha. You ought to be able to determine what you have
based on the grammar on a CAR statement.  Example: if there are two
different ways to do something, we don’t want to restrict what a vendor
does.  Also, an issue is some discrete levels of CAR support.

Four possible levels are:
1) no CAR (implementation does not support CAR at all
2) Policies only, implementation only supports policies from CAP document
3) partial grammar
4) Full grammar, implementation supports grammar and creation of new
policies.  The distinction between partial and full was not discussed.

Number 1 and 2 are reasonable options as the minimum level to be supported
but there was no concensus on this.

We need to specify grammar for each policy if more than one stated. We need
some more examples in the verbiage.

With regards to proxy or designate issues, it is up to the calendar store
to identify what it means to be acting on someone's behalf.  Using the SASL
model for security, it is authentication not authorization.

The following pseudo code shows how this would appear:

R: <listen>
S: <connect>
R: OK
S: 10 authenticate through SASL:
S: (WhoAMI) (WhoDoIWannaBe)(Credentials)
R: OK (it knows who we are)
S: 20 Create:uid
R: 20 abc123xy3
S: 30 Create (OR Read) Bill/Tony mailto:[email-masked]
S: 40 Create [email-masked]
R: 30  OK bill
R: 30  OK [email-masked]
S: 40 ICALDATA

Once authenticated, ICalendar formats the message as a designate.

Using the above code as an example it appears we do not want to use the
SASL “whodoIwannabe". If we use the ICalendar protocol, the message line
saying sendto would identify that the calendar is being scheduled by a
proxy.   For example:  Organizer: bill;sent-by=sue:bill. So, if the
calendar store knows what Sue has access rights to, the authentication will
know how to handle the calendar request.

With regards to security, the framework for connective protocols and
authentification should be SASL.  In the case of ssl, SASL will use ssl.
It will not not prevent us from using HTTP.

It was determined we need a way to bracket commands so we don’t have to
shove everything like this into a IMIP message since we are building a
command structure separate from ICalendar data.

There may be some other way outside of CAP to handle access rights or
CAR’s.  No CAR says you can’t set user rights while using CAL.  Qe should
not allow the “No Car” option.

CAPABILITY ”car policy”; “car grammar partial”, “car full”  You’ll get a
message of non-supported function when you try to do something.

Steve would like to see ViewCalendar added as a policy. Could be
ReadNonConfidential and make sure it’s against only certain modules

Exception handling
==================

There is already exception handling in ITIP. It is also in IRIP.  Rather
than recreate the wheel it may be appropriate to use what is in those two
protocols.

Session management:
===================

HTTP is not session oriented.  Calendar access requires sometimes needing
to see alarms, who has responded, etc.  What are issues where session
management is required.  Does it assume we have a session.  Need to define.
We will collect examples to include in the draft.

At the end of the two days, Alex from CS&T asked to show some things he's
uncovered.

How do we do a counter in CAP? Alex brought up an example and it reflects
an implementation concern that may cause some problems.  The same for
DECLINE COUNTER, CANCEL COUNTER, PUBLISH, REQUEST, REFRESH, ADD

Create cap://foo.com/foo      create cap://foo.com/bar
B:vev                          b:vev
Uid:xxx                       uid:xxx
Dtstart:0z                     dtstart:0z
Description:111               Description:333
Dtend:2z                  dtend:3z

Alex talked about a timezone problem.  He suggested that since iCal has
several ways of representing times, some clients might have preferences as
to how they receive their time data. In particular it would be nice for
small devices not to have to include full timezone implementations.  He
also suggested that clients be able to register a timezone component and
request that all transactions take place using local time in that timezone.
Doug pointed out that this could be rough on the server when there are lots
of clients.

Alex has agreed to post something on the list to talk about this.