Subject: Atlanta Minutes - WARNING Large document

From: [email-masked]
Date: Thu, 20 May 1999 11:49:08 -0400

These are the minutes from the Atlanta meeting.  Note: at the bottom is a
summary page with key decisions, todo's etc.
-------------
Attendees:
Pat Egen - Patricia Egen Consulting
Steve Mansour - Netscape
Frank Dawson - Lotus/IBM
Lisa Lippert - Microsoft
Doug Royer - Sun
Alex Taler - CS&T
Dave Crocker - Brandenburg Consulting
Andre Courtemanche - CS&T
Mario Bonin - CS&T

Agenda:
Define set of Examples
Select and work thru examples
Define dates and deliverables
Go over Quoting/terminator
Go over Minimum properties
Go over Timezone - recommended practice
Go over optional CMDS
Go over optional Query support

Outstanding issues:
Transport (Andre and Doug will build some kind of statement regarding
generic "reliable" method)
Terminator - crlf.crlf  - follows SMTP Model
Security (see details below) - Andre
Need to revisit SQL like query - Doug to work on this
Conditional VCARS based on time (ex read light between 16:00 and 18:00)
VCARs ownership issues
Labels on commands - proposed that we drop them (put on list)
Tombstones expiry issues (see LDUP) - Doug todo
Response codes (numerical, textual, hierarchical ) - Alex/Andre to write up
something on this.
Query issues: iteration on result, searching (parametric/content), clarify
maxresult semantic (Doug)

New Issues:
Relationship of CAP to ITIP in relation to CALID vs Cal Address - Alex to
write up example of this and the following item - "How do you schedule with
CAP when you have an ITIP address"

Examples  step through:

Dave Crocker brought up a valid point.  Once we have established our
"format" or structure, a lot of our final issues and questions resolve
themselves.  In other words, once we pick how we want the structure look
like, our format is built.

CREATE EVENT
Stuffing inside the method - cleaned up a bunch of stuff.  You may still
want to do a permissions check.  I am not actually sending down 5 meg - do
I have permission check to do this?

May want to use another command rather than SENDDATA

Step through starts now:
Client sends down data
Server responds with non-hierarchical response
Finish all the way down to the crlf.crlf

Question is do we want the initial response. Are we adding latency.  We
know we want to get rid of it - what is the rationale for keeping it?  We
don't think we need the interim command because you will get the bad state
at the end of the transmission anyway. No, we don't need the interim
response.

Regarding the crlf "dot" - use the SMTP model for how to handle what to do
this.  Reason for using the dot is simple and you can do real time
generation and not precomputation, argument is not pretty - too bad.
Counting is cleaner, but more complex, fragile and you must precompute.
This proposed decision will go to the list.

You don't have labels till the very end.  If we want to tag them and have
multiple commands.  Maybe we don't want to have them until you reach the
dot.   We want our model to be asynchronous data.  We dont' have to tag the
data through termination.  Senddata and attach mime data are atomic.  That
means that when the server sends replies it is the same thing.

One thing talked about in hallway discussions was the concept of
encapsulation of data between events.

The methods have to correlate and have to match the content commands
inside.  It would have to buffer commands in order to look at other items.
Lisa is wondering if we can prioritize the order of commands.  No, the
problem is it the commands will not always match.  The thing that you put
at the top is not exactly what you want inside.  You could put a comment
right after the method to state that the after the VEND and before
VCALENDAR.  The VCOMMAND is a container for a certain number of things. We
are not going to specify the order of what the commands are going to be.
Method statement needs to be in the scope of the VCOMMAND, in other words
at the top level, not embedded in a VCAL event.

A general discussion centered around whether we can put multiple vevents
inside a vcalendar or multiple vcalendars in a vcommand when storing
multiple VEVENTs in a single call .  It is important to keep it simple.  It
looks like it belongs inside the VCALENDAR property.  We have here a
multipart event like MIME multipart.   It is complicated to do it
multipart.

We have three solutions right now; that may be too many. The three
solutions are multiple VEVENTS in a VCALENDAR, multiple VCALENDARDS in a
VCOMMAND, and multiple VCALENDARS in different MIME bodies. We need to
settle on one method. We have an async model. Our discussion today may be
what we want to do as transaction in the future. Keep protocol the same;
however, a client may choose to not to a multithread and instead wait on a
response.  This could make implementations of a client quite simple.
SENDDATA is our simplest synchronous construct. Possibly we have everything
atomic underneath SENDDATA.  We may want to do VEVENT, VEVENT, VEVENT under
a VCALENDAR.  Looks like what we want to implement is multiple vevents
inside a vcalendar.

Proposed Decision: One vevent or vtodo or vjournal and any associated vtz
or valarms per mime entity.  There should be only one vcalenda
On the method, we don't want to have the calid.  So we set up a parameter
called TARGET where we define the name for the calendar entry. It is the
relative CALID.  We also need to make sure that we limit the ascii set on
the CALID, so commas are not legal.

Dave says the maximum pervasive layer is mime.  The interactive part
outside of mime - it's here it is, now do with it what you want.  So like
for email it should be 2.0 2.0 then a mime object. If it is text/something
it becomes very simple. General discussion ensued.

Proposed Decision: Multipart CAP.  Order is not important.  Extending
properties. Just put the needed properties.  I.E. gotten rid of vcommand
component and we've extended what you can do in the vcalendar with
properties to fully express a command.

Properties added are CMDID, Target
BEGIN:VCALENDAR
VERSION:2.1
CMDID:abcde
METHOD:CREATE

(note: we split the Method and added a Target (they are CALID) - we put
them between " ".  ONLY ONE TARGET PER TARGET LINE.)

TARGET:cap://cal.foo.com/relcall
TARGET:relcal2
BEGIN:VEVENT
DTSTART:19990307T180000Z
DTEND:19990307T190000Z
UID:abcd12345

NOTE:  UID is compulsory

SUBJECT:Important Meeting
END: VEVENT
END:VCALENDAR
.
20. 2.0.11

NOTE:  The server response was changed to send MIME format.  No tag after
the first line because the rest is sent atomic.

Content-type:text/calendar;method=response;optinfo="CMDID:abcde"
BEGIN:VCALENDAR
VERSION:2.1
CMDID:abcde
METHOD:RESPONSE
BEGIN:VEVENT
REQUEST-STATUS:2.0;cap://cal.foo.com/relcal1 abcd12345
REQUEST-STATUS:2.0;cap://cal.foo.com/relcal2 abcd12345
END:VEVENT
END:VCALENDAR

Each calendar event will be in a separate mime type ending with a "."
This copies the ITIP model.  We got rid of tags/labels. This is a more
transport independent model.

Another issue: If we removed DTEND, UID, SUBJECT - would that create an
event.  No, looks like we must have a table for each method - perhaps a
table similar to those in iTIP for each method and component type.

The question of labels was discussed. If we imbed the command in the
VCALENDAR component, do we now need labels? Each side submits transport
requests.  A response is a SENDDATA. Transport mechanism has no semantics.
When server sends down a "clump" here's the 2.0 and the stuff. Fine, now we
crack it open and digest it.  We have the CMDID to correlate it to what we
need.

Doing a discussion of tags, we found that GENERATEUID may be a calendar
specific and not protocol specific. If we move capability and generateuid
into the ICALENDAR realm, it may be better.

Using CALID is better than what to do with a "user string".

We're not sure about tags. We need to revisit later as we go through
Query Example:

Issue regarding whether we allow a default scheme on CALID throughout
protocol or do we want to be very explicit.

Query Example:

10 SENDDATA
Content-type:text/calendar; Method=Read; Component=VQUERY
BEGIN:VCALENDAR
VERSION:2.1
METHOD:READ
CMDID:xyz12345
TARGET:relcal2
TARGET: ://bobo.ex.com/relcal3
BEGIN:VQUERY

MAXRESULTS:20
RESULTSTART:10
MAXSIZE:1700000000

Proposed decision: the three lines above will be removed: if the server
sends too big a buffer, the client aborts.

QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID);
  FROM VEVENT;
  WHERE (DTEND >= 19990310T080000Z AND
                     DTSTART <= 19990310T1900000Z);
  ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY)
END:VQUERY
END:VCALENDAR

NOTE: The query is based on SQL spec SQL92 but smaller than SQL.  See
example below.  There will be a capability query: SQL full or SQL light.
Example:  C:Queryname:MyviewName in full SQL RFC.

Dave brought up a point that do we need to have searching in the initial
protocol.  Doug, Steve, Pat and Frank stated that yes we did, particularly
what's in my calendar today and what are my alarms.  What are our
pre-defined queries.

Here's an example of pre-canned queries:
- events that overlap a range of time
- events/alarms that have alarms that trigger over a range of time
- a specific event
- todos that are not completed- todos that are overdue
- todos that are completed in a particular time range

predefined calendar queries:
- calendars owned by a principal

Based on these, which we need for read/modify/etc then we need to do it.
If we use a base level of SQL 92 then the developer just needs to make sure
that their engines support this level of query language.

We can do uid's when you wanting to get back listme events listme todos.
If you want to do the alarms you need to get back the uids of the alarms,
then do a read of the trigger functions that go with that.  If you have an
event with three alarms, you need to read the event, get all alarms and
then read thru them all to get what you want.  If the uid was in the alarms
it could help tie it to an event.  However, uids need to be outside so it
can be called by other events.

Next we talked about maxsize and how much information we pull in.  Lisa
talked about some server cache issues.  Then we talked about the ABORT
command.

The client aborts if the server sends too much information. The reason to
nuke it is it adds a lot of complexity it's too complex.

Doug: On the SQL option, we can say use a specific version, or we can
define queries, or we can define a list of SQL commands here are the
parameters that work.

Doug suggests doing this sample subset of SQL commands - it's not the
predefined list and not the entire SQL library.   He said he would be
willing to put together a subset strawman and submit it to the list.  We
could have FROM Vevent/whatever

Now we went through what comes back from a query.

10 2.0.11 cap://cal.example.com/relcal2
Content-type:text/calendar;Method=RESPONSE;Component=VCALENDAR;

Change VDATA to VCALENDAR
Remove  BEGIN VDATA from code

Then decided that we did not really need to "component="

ALARM example:

QUERY:SELECT (VEVENT.DTSTART,VEVENT.DTEND,VEVENT.SUMMARY,UID,VALARM.*);
  FROM VEVENT,VTODO;
  WHERE (VALARM.TRIGGER >=  19990310T080000Z AND
                     VALARM.TRIGGER <= 19990310T1900000Z);
  ORDERBY (VALARM.TRIGGER ASC)                (needs to be in the mimimal
set)
END:VQUERY
END:VCALENDAR

Need to be able to get requeststatus (a component property in VEVENT)

BEGIN:VEVENT
REQUEST-STATUS:2.0
END:VEVENT
END:VCALENDAR

Wednesday:

Transport - we want a reliable exchange mechanism as a transport layer.

Probably should document SENDDATA effort as an independent effort because
of its value.  It is a simple basic transaction layer that could help very
powerful.

Lisa would like to see where a server can close a transaction at the end.
What is left over goes away if there is anything left in the pipe if a
connection closes before it's done.

Steve went through a Scheduling Example:

A discussion started about the concept of an inbox for scheduling items.
It is really a queue to hold items such as ITIP - that queue could be on a
mail database or on a calendar store.  The scheduling function uses a
scheduling inbox.  CAP will be the way to get ITIP into the CAL Store.  The
CREATE command puts the entry into the Calendar Store.  Lisa put up a good
example of what goes on during a schedule. She also provided some examples
of responses  back to requests and rsvps.

Proposed decision: All finally agreed on Numeric error number, followed by
text (what text and which language was not decided)...

Proposed decision: there will be text after the error number. Client must
not depend on the text so it can be localized. Text is not for the display
other then log. Might be localized.

1.2.3; text error; [param: add text]  -> both text  msg can be localized
(order might switch??) The error number is the only FIX value that
represents uniquely the error.

Proposed decision: Not going to allow principal and callIDs to be used
interchangeably (Steve). Alex will put an example in the list

Steve went thru a Invite 4 people to an event. Relcal1, relcal2, relcal3,
relcal4

Assume this server can do Fan out and that this server supports irip.  If
it does not do a fanout then it is a CREATE.

Method = schedule.  Does this mean we can do cap, irip, mailto, cap
METHOD:SCHEDULE: TARGET:CAP://CAL.FOO.COM/RELCAL1
In working through the schedule example, it was decided we don't need a
SCHEDULE method.  It was decided we don't need this.

Use CREATE and targets will govern whether it's a fanout.  Note: Right now
the ABNF requires a specific order of entries.  WE may need to fix this
ICalendar.

A CREATE is a write to a target.  The "surprise party attendee."
Each message has only one organizer - but the organizer can have multiple
addresses.

Comment: organizer property value should be the calid with the preferred
scheme.

Example:
ORGANIZER;
ALTREP="mailto:[email-masked]";ALTREP="irip:/cal.foo.com/relcal1":cap:
//cal.foo.com/relcal1

This handles how to enable people to respond back using different protocols
after executing a CREATE.

The CREATE response code can have up to N types of response where N is the
number of target (local, fanout, CAP, IRIP, ...).

A CREATE might be converted to a request for an IRIP request.

Coding Example:

C: 20 senddata
C: content-type:text/CALENDAR; METHOD=CREATE; CHARSET=us-ASCII
C: CONTENT-TRANSFER-ENCODING:7BIT
C:
C: BEGIN:VCALENDAR
C: VERSION:2.1
C: CMDID:ABCDE
C: METHOD:CREATE
C: TARGET:CAP://CAL.FOO.COM/RELCAL
C: TARGET:IRIP://CAL.FOO.COM/RELCAL2
C: TARGET:MAILTO:[email-masked]
C: TARGET:CAP://CAL.BOBO.COM/RELCAL4
C: BEGIN:VEVENT

#ORGANIZER PROPERTY VALUE SHOULD BE THE CALID WITH THE PREFERED SCHEME
C: organizer:CAP://CAL.FOO.COM/RELCAL1

NOTE: We added ALTREP in the next line.

C: ATTENDEE;ATLREP=MAILTO:[email-masked];
ALTREP="IRIP://CAL.FOO.COM/RELCAL1" :CAP://CAL.BOBO.COM/RELCAL4
C: ATTENDEE: :IRIP//CAL.FOO.COM/RELCAL2
C: ATTENDEE: MAILTO:[email-masked]
C: DTSTART:1999...Z
C: UID:LEWKHFLDSA
C: DTEND:19999.....Z
C: SUBJECT:IMPORTANT
...

The propagation of replies is the responsibility of the organizer
ATLREP was added to the Organizer and is also available for the Attendee

Summary - Assigned Task List, proposals and deadlines:
------------------------------------------------------
Transport (generic, reliable method) (Doug and Andre) - 2 wks

Proposed decision: Terminator will be crlf.crlf following smtp model

We should use SMTP rules for quoting.

Proposed Decision: Capability is atomic.  Response to a connect and to a
successful authentication.  Capabilities are not "options".  This follows
the SMTP model.

We need to take the response codes issue to the list.  Locale and text -
Look at Andre's prior comment on the list.

Security and authentication (Andre) - 2 wks to deliver scope
- Authentication id
-User definition
- URI of principles
-How does it tie to the VCAR
-Required authentication and encryption - minimum
-Multi-server operation issues
-Transport level encryption
-Boiler plate considerations/threats
-Re-authentication and impact on commands and connection state

Need to revisit SQL/SQL like query issues (Doug) - 2 wks
- Iteration on result
- Searching (parametric/content)
- Clarify maxresults semantics

Conditional VCARs (read rights between 16:00 and 1800) based on times

VCAR ownership issues

Labels on commands (looks like we have dropped them)

Tombstones expiry issues (Doug) - 1 week (see LDAP LDUP)

Response Codes (numerical, textual, hierarchial) (Andre) - 2 wks
- Andre will repost his suggested position

Relationship of CAP to ITP in regards to CALD vs cal address and
How do you schedule with CAP when you have ITIP calendar (use mailto and
this should work) - (Alex) - 2 wks to develop examples.

Time Zones: (Alex) - 4 weeks
- Alex will write up something on timezones.

Proposed decision: Rep reconfirm responsibility of organizer - updated
event info is included with Attendee participation status.

Additional Whiteboard items:

Select (VALARM TRIGGER)
  From (VEVENT)
  Where 9VALARM.DTSTART > '...')
       And (VEVENT.UID = '...')

Error numbers only

ICAL language says:

- error number
- some text
- machine useable only
- predefined set
- client must not depend on text

Andre stated that we should look at 3 digit5 codes, optional text (non
displayable middle text) and drop the middle text.  We should change ICAL
to match this.

Example:

Old: 12.3.5;Disk Full];Can't write C: (text at end is optional)

New: q12.3.5;Can't write to disk because it's full

Lisa suggestion:
3.5;"Bad parameter";DTSTART
3.5;"The value was wrong";DTSTART
3.5; *;dtstart
3.5;"La valeur etait faux";dtstart

All should work.  Need to make changes to CAP draft.

Calid becomes calendar add.  We are not going to allow principles and
calids to be used interchangeably.  Need an example. Alex will do an
example.  See task list above

Reference 2446:

VEV
Att: Steve
Att;Role=Chair:Alex
Org:Alex
Att:Pat

Uses:

ITIP reply
Allow ITIP methods in CAP to use authentication.
Allow SENDDATA to send ICAL objects using ITIP methods

Go to this URL for a copy of Lisa's excellent scheduling example and an
example of the Calendar System model we used during the course of the two
days:

http://www.egenconsulting.com/ietfdocs.htm

Schedule/Create camps (no due date assigned)
- Alex/Lisa/Frank persuading Steve/Andre

Need to continue sequence number bump.

Attendee representative can be on attendee as well as Org.  Text value and
URI value type (CALID).  May need to have a way to determine best way to
reply.