Subject: Minutes of 44th IETF CALSCH sessions

From: Pat Egen <[email-masked]>
Date: Mon, 05 Apr 1999 17:02:37 -0400

CALSCH Working Group minutes:
Session on 15-Mar-99, 3:30PM - 5:30PM

Agenda:
   Assign Volunteer Scribe: Alex Taler of CS&T and Bruce Kahn of Iris
   CAP Requirements: WG last call status
   XML/ICAL syntax resolution
   iRIP Update
   iTIP Identified issues/defects
   CAP Design Group status update

As of now, rough consensus on XML vs iCal is to stick w/iCal for
syntax.  In the future we may consider moving to XML.
After delta changes to CAP Requirements are in, it will not go to RFC
but kept for historical reasons
IRIP discussion: Steve Manseur & Andre Courtemanche.
Issues from IETF 43:
- Resolved queuing issues in new draft
- Editorial fixes
- Revised draft to list

Remaining issues:
- Overlap between iRIP and CAP:
- Keep similar syntaxes so can sub/super set features.  Uses are still
semi-disparate. Need to get feedback from Steve M on how to best
differentiate them!
- Request & responses are now tagged so can do > 1 request/response at a
time
- Fan out response in multiple MIME blocks so data won’t have to be
merged into 1 block.  Now each CalID will return separate MIME block(s)

Authentication/security Issues:
- Trusted relationship between iRIP servers not sufficient. Will want to
borrow CAP authentication info/schema to reuse it.
- May need to authenticate users as opposed to calendars; a new concept
for us.
- Others to be posted to the list

New Editorial issues based on new draft
- Will try to keep CAP and iRIP similar features in sync as they
progress

Next steps:
- New draft by next IETF and one by 15-Apr-99.
- Track CAP progress

iTIP & iMIP Defects:  Steve M. & Frank Dawson
- These solutions will be submitted to revise iTIP drafts.

Overloading iTIP REQUEST:
- Current method used for invite, reschedule, update, confirm, reply to
refresh.  A reschedule and/or update are semantically different than
confirm or Reply to REFRESH
- Propose: New CONFIRM method to be used to (a) reply to a REFRESH and
(b) notify participants of any changes to ATTENDEE or ORGANIZER.  All
other “reschedule” or “update” changes MUST use REQUEST method.

Identify sender of iTIP COUNTER:
- Can’t identify who COUNTER came from because all of the ATTENDEEs will
appear in the method.
- Propose: Only specify ORGANIZER and countering ATTENDEE in method.
- Caveat: Can still forward or delegate a REQUEST to change
participants. However, only the ORGANIZER can remove a participant.;
This removes functionality and can be done w/an iMIP header but won’t
work for all iTIP.  Will revisit how to best do this on the list.

Intolerant iMIP receiver:
- iMIP specifies numerous MIME encapsulations for iCal/iTIP msgs.  It
doesn’t   require that an implementation MUST be able to receive each of
them.  This is leading to interop problems w/different CUAs.
- Propose: A conforming iMIP implementation MUST be able to receive each
of the MIME encapsulations shown in the iMIP examples.;  It does not
have to GENERATE them, just RECEIVE them!  Why not just use multipart
alternative instead of multipart mixed.  A minimal MIME compliant mailer
must grok multipart mime so this may be moot.

Adding/deleting ATTENDEE:
- If ORGANIZER adds or deletes an ATTENDEE, do they really have to send
the reschedule to all of the other ATTENDEEs?
- Propose: No, they can send the REQUEST w/the new ATTENDEE info to just
the new ATTENDEE.  It is up to the CUA.  It is an implementation
dependent issue if the SEQUENCE number needs to be incremented when you
add/delete an ATTENDEE.;  iCal does not require SEQUENCE rev if a new
ATTENDEE is added so this wont break iCal or cause a revision there.

CAP Design Group: Frank Dawson

Tomorrows session will be tutorial on what the design group and the list
have been working on.

Topics:
     Status of interim work
     Proposed schedule for work in 99
     CAP design summary (Continued tomorrow)
Design Goals:
     Leverage iCal and iTIP work
     Design to CAP Reqs doc
     Validate reqs wherever possible;
     Some deferred stuff was pulled in (ie VCARs) based on WG list
feedback.
     Keep list active in providing feedback and consensus (instead of
“telling”
      them what the WG will accept)
     Submit draft for July IETF mtg

Activities:
- 2 interim meetings: NYC 2/99 @ Morgan Stanley & Menlo Park 3/99 @ Sun
- Identified design approach for CAP data model, addressing, system
model, state diagram, query, calendar access rights and command set
- Changes to reqs doc (moving in access rights, server fan out, the
concept of a ‘user’)
- Need to gain closure on transport
- Poll of audience shows about 25% to 33% of the folks are new to
CalSched so we went over the data and system model.

Data Model:
     CS (calendar Store):
        vTZs (timezones)
        Properties (CS owners authids, CS’s local time or time info,
etc)
        vCARs (access rights)
        Calendar(s):
          Calendar(s)
          Calendar Properties ()
          vCARs
          vEvents
             vAlarms
          vTodos
             vAlarms
          vJournals

Questions from the floor and answers:
Calendars can have Calendars within them and the “parent” of the ‘top’
one has the CS as its parent. CS is what the CUA connects to. What is
meaning of “sub calendars”?:  Use inheritance of vCARs from parents, etc
to see what access a user has.

Does naming imply hierarchy (ie: subcalendars vs parents):  Calendars
addresses) have opaque names and hierarchy is NOT based on any schema of
the CALID format so no, no implications!  Names are just pretty human
readable indicators for reference.

What is use of “sub calendars”: To emulate how people organize their
time, or other info.  For example, my “soccer” calendar and my “work”
calendar can be subcalendars of my main calendar.  Other examples are
parent calendar of a building and then subcalendars of resources in it.
This model is a relationship model, not a storage model for data.

vCARs are inherited down but info is NOT inherited up!!  There are lots
of client side and undiscovered issues to consider still. Needs to be
thought out more and covered on the list!

Should multi-value PARENT properties be allowed?  There are inheritance
issues to consider WRT vCARs before just saying yes.  There are also
issues of having ‘split’ or disparate stores that contain the sub
calendars (ie: Kids store on the ISP and my store at work!)

Would aliases for calendars be useful?  What about mulitple personas?
This can have/require multiple authIDs and names, etc to pull together.

Can CAP be used by 1 CUA to access > 1 CS at a time?  Yep.

Is Group calendar support something to pull into initial release too? Is
it necessary in the protocol or can it be done by CUA?  Group Calendar =
aggregate > 1 calendar into 1.  VCARs could be used to emulate this but
its ugly!  An aggregate calendar could be an actual calendar instead of
just an aggregate one... This needs to be taken to the list too.

CAP Addressing Model:
     A CalUID conforming to RFC 1738:
        caluid = [<scheme>://[csid][:<port]/]<relativeCalUID>
        <scheme> = “cap”
        <relativeCalUID> = < any 7bit UIS-ASCII identifier>
     Examples:
        cap://calendar.example.com/user1
        user1 (relative to the CS; equivalent to the one above)
        cap://calendar.example.com/conferenceRoomA
        cap://calendar.example.com/923345346-foo
     RFC 1738 obsoleted by ~RFC 2368 CAP System Model:

Internet SMTP/MIME + iTIP is really CUA <-> CUA but it could be CS->CUA
as well. iMIP could be used between CS1 and CS2 but then its addressing
CS2, not CUA 2 Need to clarify what is mandatory and what is not in the
model.

Fan out IS a requirement of CAP now.

CAP between CS1 and CS2: If CS acts as CUA then is it Fan out or not?
Isn't this just a requirement for a fatter CS?  If iMIP is a requirement
then why is CAP between CS’s of any use (if there is no authentication
between all CS’s)?

There was lots of discussion on this that will be brought up on the
list.

The State Diagram was drawn.

Questions from the floor and answers:

What good is CAPABILITY in RTS state?  Why not...  Its nonsensical in
this mode as a CUA should have up front checks not ‘spur of the moment’.

What is the use of CONTINUEs?  To handled bounded latency issues.
Latency is not that bad on low latency intranets but can be larger on
internet due to routers, etc.  Clients on high latency connections will
want to avoid the RTS state.

Missing assorted links in diagram from last revision.  Frank to revise
based on notes from last 2 interim meetings.

Need comment on how to handle tagging and multithreading, etc. Could be
problems w/queued requests and reauthentcation, etc.

Next, there was a description of a Query:

     Based on SQL clause/statements
     Specified in a VQUERY component
     Example:
        BEGIN:VQUERY
        QUERYID:Read today’s event
        QUERY: Select=UID,DTSTAT,DTEND,SUMMARY;FROM=VEVENT;Where=DTEND
>=
          19990315T143000Z and DTSTART <= 19990315233000Z;
orderby=dtstart
          asc, dtend, summary, uid
        END:vQUERY

Question/Answers:

Why is it not just SQL?  We already have concept of name=value so use
it.  Still, why just not use SQL?? Don't want to get raw SQL data that
doesn't map 100% to iCal.  Stuff in SQL may not be desirable now (ie:
weighting of results) but may want later.  If we use SQL syntax then we
gain an already understood behavior;  We just didn't want to get the
mods that we’d have to make to avoid non-doable stuff (ie: “today”);
There could be problems w/vendor extensions of SQL that dont interop so
a strict separate syntax prevents that. Revisit on the list (did in Dec
98 but no responses). Pat asked for feedback on the list.

Calendar Access Rights:

Need to decide on the granularity of the CARs; property level, entry
level, etc.

Specified calendar access for: Given authenticated calendar user
(PRINCIPAL) and either: Particular calendar access policy (POLICY) or;
Particular set of calendar operations (ACTION), Relation to a set of
calendar components, calendar properties, component properties, property
parameters (OBJECT), Particular property or parameter values (VALUE).

Specified in vCAR calendar component
No rights assumed; must be given them!  There is no way to revoke rights
(yet?)  Need feedback on  how to manage this.

Can I set VCARs that say “Frank can only edit my calendar between 3/15
and 3/19”?  You can filter based on property values but not for this
case in particular.  Suggestion was it could be attempted using ROLEs.

Example:
        BEGIN:VCAR
        CARID:Read public events
        GRANT: PRINCIPAL=foo;ACTION=READ;OBJECT=VEVENT
        DENY:PRINCIPAL=foo;ACTION=READ;OBJECT=CLASS;VALUE=Private,
        Confidential
        END:VCAR

This example grants public R access to all docs and revokes access to
Private or Confidential CLASS valued items How can I create a VCAR that
prevents FOO from reading the CLASS: property?

How about: DENY:PRINCIPAL=foo;ACTION=*;OBJECT=CLASS

Can a properties value be used to govern a vCAR?  Yes.  Unclear how this
is
different from above except the missing VALUE=;

What about adding a new SCOPE parameter to target the scale to filter
out: property, doc, etc

How about a SCOPE property for the right (all components, etc)??

Do we want to add expressions to build “Give Frank Access from 3/15/to
3/19” to the VCARs?  What about adding ranges of values, etc.??.. Take
to list as we need more input on this.  This will be done by Tony Small.

Policy support is mandatory, Grammar is optional. Assorted proposals
will be posted to list with indicator as to status within the WG (ie:
draft, proposed for CAP v1, etc).

CAP Command Format:
     CUA command request format:
        <label> <command> [<command data>]
     CS command response format:
        <label> <response code> [<response data>]
     Example
        C: 10 Create VCALENDAR cap://cal.foo.com/
        S: 10 2.0

Are labels required??  Take to list about tagging.

Proposed Sched of Work for 1999:
     2 final interim mtgs (will be announced on the list)
        4/27 & 28 Lotus (Atlanta)
        6/8 & 9 CS&T (Montreal)

Produce CAP draft by 45th IETF cut off date Next IETF mtg and later.
Review/comment on CAP v1

The Area Director informed us to be careful with our interim meetings.
All discussions should also be on the list.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Tuesday, 16-Mar-1999, 1:15PM - 2:15 PM

Agenda:
   CAP Design Status continuation
   Transport issues

Recap of yesterday: Frank D. & Pat Egen

Several design examples were presented. The command list was shown:
abort, authenticate, capability, continue, create, delete (permanent
(tombstone properties are available)) disconnect, generatedUID (server
generates (globally?) unique id for a client), modify, move (optional)
move a calendar,      NOOP, READ, senddata

There are lots of latent issues w/tombstones and/or not...  Need to
request additional feedback from list on their use or not.

CREATE Sample (on cal.example.com):
     Example #1:
     C: 10 CREATE VCALENDAR cap://cal.example.com/ relcal4
://bobo.ex.com
     relcalBoo
     S: 10 6.0 cap://cal.example.com/
     S: 10 2.0 cap://cal.example.com/relcal4
     S: 10 3.1.4 cap://bobo.ex.com/
     S: 10 6.2 cap://cal.example.com/relcalBoo
     C: 10 CREATE VCALENDAR cap://cal.example.com/relcal8 relcal9
     S: 10 3.1.5 cap://cal.example.com/relcal8
     S: 2.0 cap://cal.example.com/relcal9
     C: 10 SENDATA
     S: 10 2.0.1
     C: Content-Type: text/calendar; method=create; component=vCommand
C: Content-Transfer-Encoding: 7bit C:
     C: BEGIN: vCalendar
     C: VERSION:2.1
     C: METHOD: CREATE
     C: BEGIN:vCommand
     C: BEGIN:vCalendar
     C: RELCALUID:relcalZ
     C: NAME;CHARSET=US-ascii;Language=en-us:Bill’s Soccer Team
     C: OWNER:CAPCAR:bill
     C: OWNER:CAPCAR:mary
     C: CALMASTER:mailto:[email-masked]
     C: PREFERRED-TZID: US_PST
     C: BEGIN:VCAR
     C: CARID:12345
     C: GRANT;cn=”Bill
Jones”:principal=capcar:bill;action=all;object=all
     C: GRANT;cn=”Mary
Jones”:principal=capcar:mary;action=read;object=all
     C: END:VCAR
     C: END:VCOMMAND
     C: END:VCALENDAR
     C: .
     S: 10 6.0 cap://cal.example.com/
     S: 10 2.0 cap://cal.example.com/relcal4
cap://cal.example.com/recalZ
     S: 10 3.1.4 cap://bobo.ex.com
     S: 10 6.2 cap://cal.example.com/relcalBoo
     S: 10 3.1.5 cap://cal.example.com/relcal8
     S: 10 7.0 cap://cal.example.com/relcal9

Questions:

Is there a problem w/a variable length entry line (ie: denial of service
attacks)?  Not really if you use CRLF delimitation.  However this
approach is not condusive to tagged data and multithreading in some
ways.

Are numeric response codes good or bad?  The dot notation is good for
expansion but not good for users.  Then again what does 3.6.1.2.6.2.2
mean if I don't grok it??   Using character strings avoids < or >
comparison of values that DRUMS had hassles with.  Some like human
readable formats ie: forbidden.no_auth.  This can be useful for some but
iTIP has a code;explain text;opt arg text format.  Perhaps the response
needs to be more iTIPish.  Use of numbers is consistant w/RFCs for iCal,
iTIP, iMIP.  Take back to list for continued dialog.

Why have tagged commands?  To allow pipelining or batching further down
the line in case we want to add it some day.  There are still some
issues (like w/SWITCH) to be worked out.  Also, the tag is used to match
data w/prior commands (ie SENDATA to all CREATEs).

What about problems like C: 10 CREATE and then C: 10 DELETE and then
C: 10 SENDATA?  Its a problem w/tagging and will revisit.  (Its not IMAP
like tagging, its different!). There are concerns about SENDATA being
atomic and not allowing tagged data to be sent.  Tagging data (unlike
IMAP) could be a performance issue/boost.  Also avoid CRLF.CRLF for data
deliniation so tagging wont crash something else.

The new OWNER property is a TBD propety for handling naming of users.
Paul Hill will be sending draft to list on naming users.

Why use MIME headers that duplicate the actions encoded in the SENDATA?
Its duplication of info so why do it?  Design is just like iTIP that has
info in MIME header and in the data.

The CREATE command does not do the actual creation; its just a probe to
see if it is possible so the CUA can do it or not.  The actual create is
done in the iCal data.  Is this iTIP overhead necessary?  What worked
for iTIP may not be necessary now.  Perhaps rename CREATE to something
more apropo.  Let the list discuss further.

Second BEGIN: VCALENDAR is to indicate what we are creating...  Will
this toss base iCal parsers that do parsing before parameter matching,
checking etc??  Why not use a simple new property like ITEM-TYPE:...??
(Otherwise we violate iCal RFC!)

The reply codes do not jive before and after for some cases like it now
exists when it didnt before.  The intent was to do this.  Add mandatory
“S: final msg” line so client knows when server is done.

What about having a SIZE indicator of some time for the SENDATA command
so CUA can tell CS what is coming so it can allow/reject w/o wasting
time/bandwidth.  Good idea.

What about a different EOD than CRLF.CRLF??  Possible. Ask the list.

Example #2: (Same as #1 but no RELCALID)
     C: 10 CREATE VCALENDAR cap://cal.example.com/ relcal4
://bobo.ex.com
     relcalBoo
     S: 10 6.0 cap://cal.example.com/
     S: 10 2.0 cap://cal.example.com/relcal4
     S: 10 3.1.4 cap://bobo.ex.com/
     S: 10 6.2 cap://cal.example.com/relcalBoo
     C: 10 CREATE VCALENDAR cap://cal.example.com/relcal8 relcal9
     S: 10 3.1.5 cap://cal.example.com/relcal8
     S: 2.0 cap://cal.example.com/relcal9
     C: 10 SENDATA
     S: 10 2.0.1
     C: Content-Type: text/calendar; method=create; component=vCommand
C: Content-Transfer-Encoding: 7bit C:
     C: BEGIN: vCalendar
     C: VERSION:2.1
     C: METHOD: CREATE
     C: BEGIN:vCommand
     C: BEGIN:vCalendar
     C: NAME;CHARSET=US-ascii;Language=en-us:Bill’s Soccer Team
     C: OWNER:CAPCAR:bill
     C: OWNER:CAPCAR:mary
     C: CALMASTER:mailto:[email-masked]
     C: PREFERRED-TZID: US_PST
     C: BEGIN:VCAR
     C: CARID:12345
     C: GRANT;cn=”bill
jones”:principal=capcar:bill;action=all;object=all
     C: GRANT;cn=”Mary
Jones”:principal=capcar:mary;action=read;object=all
     C: END:VCAR
     C: END:VCOMMAND
     C: END:VCALENDAR
     C: .
     S: 10 6.0 cap://cal.example.com/
     S: 10 2.0 cap://cal.example.com/relcal4
     S: 10 3.1.4 cap://bobo.ex.com
     S: 10 6.2 cap://cal.example.com/relcalBoo
     S: 10 3.1.5 cap://cal.example.com/relcal8
     S: 10 7.0 cap://cal.example.com/relcal9
        cap://cal.example.com/rand1234
   READ Command:
     C: 10 READ VEVENT relcal2 ://bobo.ex.com/relcal3
     S: 10 2.0 cap://cal.example.com/relcal2
     S: 10 2.2 cap://bobo.ex.com/relcal3
     C: 10 SENDATA
     S: 10 2.0.1
     C: Content-Type: text/calendar; method=read; compoent=vcommand C:
     C: BEGIN:V
     C: VERISON:2.1
     C: METHOD:READ
     C: BEGIN:VCOMMAND
     C: BEGIN:VQUERY
     C: MAXRESULTS:20
     C: MAXSIZE:17000000
     C: QUERYNAME:MyViewRange
     C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID);
     C:  FROM VEVENT;
     C:  WHERE (DTEND >=1999-310T080000Z AND DTSTART <=
19993010T190000Z);
     C:  ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY)
     C: END:VQUERY
     C: END:VCOMMAND
     C: END:VCALENDAR
     C: .
     S: 10 2.0 cap://cal.example.com/relcal2
     S: Content-Type: text/calendar; method=response; component=vdata;
        optinfo=version 2.1 S: C-T-E: 7bit S:
     S: BEGIN:vCalendar
     S:..
     S: end:VCALENDAR
     S: .
     S: 10 2.0 cap://bobo.ex.com/relcal3
     S: Content-Type: text/calendar; method=response; component=vdata;
        optinfo=version 2.1 S: C-T-E: 7bit S:
     S: <MIME data from relcal3>
     S: .

Questions:

Need suggestion on how to get “next 20” if just get 1st 20.  Could add
FIRSTRESULT: to the query and then resubmit it.  Send suggestions to
list (ie LDAPs ways, etc).

Can use same QUERYNAME to reissue w/o resending the QUERY info.  Need to
be careful about namespace collision and possbible security holes.
There are also QUERY permanance issues to consider like how to keep
them.  Are the values persistent or not?  Will follow-up to list.

Is the MAXSIZE per component or for the entire data?  TBD, poll the
list.

The QUERY mechanism is SQL like but not SQL-92.  They are not 100%
interchangeable and SQL is not appropriate so its a mishmash.

Searchings are parametric, not content search.;  Will raise the query
mechanism on the list.  Need to look at the LDAP searching.

Is content searching a requirement of CAP or not?  No but perhaps we
should consider adding it as its an existing feature in C&S apps.

Need to add some way to indicate end of all responses.  Will add
something

Access Rights Notes (Proposal):

Access to some requested properties of an event but not all.  For
example, requestor does not have access to VEVENT.SUMMARY: ... Query
SELECT (DTSTART, DTEND, SUMMARY, UID); ... Responses: ....
RESPOSE-CODE:3.8

We have no way to differentiate between No access to the prop vs No prop
of that name and also what property it applies to. Isn't the opt arg or
format text parts of the reply code suitable to convey this (using > 1
RESPONSE-CODE in a response then).

Meeting adjourned.

Thanks to Co-scribes: Bruce Kahn ([email-masked]) and Alex Taler
([email-masked])

Respectfully submitted:
Pat Egen