Subject: CALSCH working group minutes

From: Pat_R_Egen/Egen_Consulting/[email-masked]
Date: Mon, 22 Apr 2002 13:16:34 -0400

FYI, below is a copy of the minutes sent to the IETF minutes list.  Thought the list might be interested in seeing them before the proceedings came out.

-----Forwarded by Pat R Egen/Egen Consulting/01 on 04/22/2002 10:16AM -----

To: [email-masked]
From: Pat R Egen/Egen Consulting/01
Date: 04/08/2002 08:12AM
Subject: CALSCH working group minutes

IETF 52 CalSched Working Group Meeting
Thursday 21-Mar-02
Minneapolis, MN

Introductions (Pat / Bob):
Quick poll of those in the room: 5 are "new" to the WG: several already on the list and
2 were "Curious Users"

Agenda:
Agenda Bashing
Guide to Internet Calendaring status
CalConnect status
CAP status

Bruce Kahn graciously steps up to be scribe.

Guide to Internet Calendaring (Pat):
The Guide has been approved for release as an RFC; in the queue for the actual number. The guide is intended to be used by implementers of the C&S standards.

CalConnect III (Pat):
The one scheduled for next week was cancelled due to several factors (proximity to IETF, travel concerns,
etc). Novell still wants to host the next non-virtual CalConnect in Provo, UT. The next CalConnect will be a 'virtual' one and is slated for the June timeframe, probably before the next IETF in Japan. The goals/benefits of having it virtual are:
Decreased participation costs (supplemented by scheduled conference calls to keep things moving)
We should be able to do this in a "virtual environment" given our design criteria.
We will rely on secure instant messaging and regularly scheduled conference calls between participants.

Virtual event will have the following:
- Virtual environment will have the following:
-  POP/IMAP/SMTP/FTP/HTTP servers
-  A Secure collaborative environment for instant messaging, electronic conferencing, and discussion
–  All dialogs will be encrypted
-  Timed periodic conference calls with all attendees
-  Expectation is you are available for the duration of the two days
-  A set of scenarios to test and a table/matrix with items to test and "check off" as complete/broke/needs more
testing

Currently there are 7+ vendors interested in participating; no word on any Open Source interest yet. Tentatively
targeting August/September 2002 as the timeframe for the next "in person" event.

Calendar Access Protocol (CAP):
Steve Mansour went over the CAP items

Steve went over major items since the last meeting review.  They were:
-  Information inconsistency between transport layer and application layer - there is no clear separation between application and transport layers.

-  A review VCARS and Queries is in order

-  We need to add iCalendar extensions to draft

-  Scheduling restriction tables need more work

-  Obtaining the UPN after authentication in BEEP - Getting UPNs from BEEP; Need UPN information to
properly resolve other identity/security aspects in CAP but unclear how/if BEEP can provide this.

Next Steve went over the status of version 7 of the draft.

Slide items:
- Mixing of Transport and Application Data
- Fixed issues from last time
- A few things remain (ex: get-capability)
- Obtaining the UPN after authentication in BEEP
- Proposed Security Model Change:
- Current: deny unless explicitly granted
- Proposed: grant unless explicitly denied

We still have some mixing of the Transport and Application layers.   This is due to lack of a clear definition of what each layer really is (it varies by reader so we must nail down the distinction and resolve the layering).

Getting UPNs from BEEP. Paul Hill, our security guy, went over this topic.  Paul is working with the BEEP and SASL folks to see what can be bubbled up for CAP to get/use. Currently, only WebMail is known to support it. We want to build BEEP and SASL on Windows (not only on Unix as is currently the case);  Currently Paul is working on the port (as we have the WG meeting even). The model as it exists should work;  He will look at it again to be sure once we have some more information.

The next topic was the proposal to change the security model: We want to go from an implicitly Deny w/explicit
Grants to an implicit Grant model w/explicit Denys. This scales better and is easier to evaluate.
Essentially the evaluation of access is done from the CS -> Calendar -> Entity levels where any Deny at any
point prevents access "below" that point.

Steve, Paul and others will put together and propose some actual text pending tentative agreement on the conceptual change.

Slide items:
-  SCHEDULE is gone, CREATE to cover it
- METHOD value verb or status (STATE)?
- BOOKED versus CREATED
- DELETED  (remember tombstoning?)
- What properties MUST be maintained?
-  iTIP method
-  Abort versus bounded latency
- Do we need abort capability other than latency
-  Reorder the draft so that it's easy to follow
- iCal extensions are currently at the end draft

The SCHEDULE command is gone.  Reusing the CREATE command instead.   This leads to some confusion about
the use of METHOD in 'booking'; is METHOD a verb or a state?

DELETED is a new METHOD value added to codify the "Tombstone" concept we previously had [explicitly or
implicitly at some points -BK].  We need to clearly define what the CS behavior is with respect to
deleted entries (ie: exactly what MUST be preserved for sync and other reasons, etc and what MAY be
preserved, etc).

ABORT vs Bounded Latency - Do we need to have an ABORT command?

WE need to reorder the draft to make it easier to follow.  The layout is more than a bit hard to read [especially the ABNF that appears in the back after its used elsewhere

Slide items:
- UIDs for components:
- VCARs (Default, Predefined, Decreed)
- VALARMs
- Querys
- Stored Queries – do we need them?
- Scoping
- component.prop
- USING_PROPERTIES
- USING_COMPONENTS
- Querying for floating time events

It is unclear how UIDs for some components should be added and how to deal with uniqueness.  Also, it was questioned how some of the VCARs function (ie: predefined ones: Are they 'templates' for creating instances in each VAGENDA or are they copied.  If they are templates, thats a new concept.  If they are copied then the UIDS are no longer unique.)

Regarding queries, how useful are stored queries given that the majority of queries used in C&S are 'time sensitive'
and we have no ability to macro substitute values into saved queries.  For example: Give me all my events
that have an alarm that triggers in the next hour requires that the CUA send an explicit UTC time for
the bounds.   As such, tomorrow the query would be basically useless.

There are questions/issues regarding the scoping of queries: The design currently restricts them to COMPONENT.PROPERTY [without any clear reason apart from some apparently implicit assumption about the
underlying actual search engine like SQL.

There is no clear definition for the use/need of USING_PROPERTIES and USING_COMPONENTS.  They appear to
be used as a form of shorthand at best without any functional need/description for them.

There is no way to query for "floating time" entries.  The query code expressly declares that all queried time must be in UTC but thats not possible for the "Every morning I go jogging from 6AM - 7AM no matter where I am" case.  "Floating time" (aka Local only) entries have no associated time zone and as such cannot be converted and stored in UTC.

Going forward:
Slide items:
- Post all issues to the list
– Analyses for all
– Recommendations for many
- Targeting getting issues posted by end of the month
- Work through the issues one at a time

All issues will be taken to the list.  There should be an analysis of each one and preferably a
recommendation for resolving them as well (in the interest of time). Target posting all of the issues is by the end of March 2002 to the WG list. We will work thru the issues 1 at a time instead of "flailing" on several at once and seemingly resolving none.

Pat will be the Keeper of Order.  TBD will be the Keeper of Issues. Pat noted that there exist WG chair tools to aid in this process and she will investigate them and get the relevant parties up to speed on them.

The cochairs/editors want more WG feedback on postings (ie: more than just 2 people going back and forth on a topic).  Pat suggests that the "techies" take care to put the painful technical details/explainations into Plain English (TM) for the rest of the WG so that "less techie folks" are more inclined to participate.

A quick poll shows that we may not have sufficient people to have a WG meeting in Japan.  As such we want
to get more progress done on the list before then.

We will deal with the layer issue first.  Much of this is due to the BEEP changeover.  We want to finish
off the concerns of "XML creep" and the layer bleeding before we get back to the actual protocol details.

Pat put out a call for "anyone" with BEEPCOREC and SASL implementations to get engaged in dealing with
this.

Larry noted that SASL is lightweight in design.  MD5 is "heavy duty" as the minimum base for CAP authentication.  There are lots of SASL implementations and they mostly interoperate. Larry asked why not just adopt XML now with the new work the WG is doing.  He finds it confusing to have both XML and iCalendar in the draft.  This gets back
to the prior issue about XML creep that we need to finally resolve.

Steve responded that we could do the change but we need to make changed to xcal (which is expired now).  Also, its odd to mix XML and iCalendar data but the mix is an artifact of the BEEP changeover.  One example is the SEARCh command that is in XML but it has no data.

Larry pointed out the mix of data dn commands/actions (ie: search) in 1 blob is still confusing.

Steve: we need to better explain the mix in the design text and descriptions.

Wrapup (Pat):

The WG site calsch.org (or www.calsch.org) is up and has the drafts, texts and relevant links.

Meeting adjourned.

Respectively submitted by Pat Egen.

---

From: "ericp" <[email-masked]>
Date: Tue, 23 Apr 2002 06:39:35 -0400

Good Morning,
 
regarding the minutes... a small correction should be noted,
the xCal draft has not expired. The draft will expire on August 16th,
2002.
 
Regards,
Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Pat_R_Egen/Egen_Consulting/[email-masked]
Sent: Monday, April 22, 2002 1:17 PM
To: [email-masked]
Subject: CALSCH working group minutes

FYI, below is a copy of the minutes sent to the IETF minutes list.
Thought the list might be interested in seeing them before the
proceedings came out.

-----Forwarded by Pat R Egen/Egen Consulting/01 on 04/22/2002 10:16AM
-----

To: [email-masked]

Introductions (Pat / Bob):
Quick poll of those in the room: 5 are "new" to the WG: several already
on the list and 
2 were "Curious Users"

Agenda:
Agenda Bashing

Guide to Internet Calendaring (Pat):
The Guide has been approved for release as an RFC; in the queue for the
actual number. The guide is intended to be used by implementers of the
C&S standards.

CalConnect III (Pat):
The one scheduled for next week was cancelled due to several factors
(proximity to IETF, travel concerns,
etc). Novell still wants to host the next non-virtual CalConnect in
Provo, UT. The next CalConnect will be a 'virtual' one and is slated for
the June timeframe, probably before the next IETF in Japan. The
goals/benefits of having it virtual are: 
        Decreased participation costs (supplemented by scheduled
conference calls to keep things moving)
        We should be able to do this in a "virtual environment" given
our design criteria.
        We will rely on secure instant messaging and regularly scheduled
conference calls between participants.

Virtual event will have the following:
 - Virtual environment will have the following:
-  POP/IMAP/SMTP/FTP/HTTP servers
-  A Secure collaborative environment for instant messaging, electronic
conferencing, and discussion
-  All dialogs will be encrypted 
-  Timed periodic conference calls with all attendees
-  Expectation is you are available for the duration of the two days
-  A set of scenarios to test and a table/matrix with items to test and
"check off" as complete/broke/needs more 
   testing 

Currently there are 7+ vendors interested in participating; no word on
any Open Source interest yet. Tentatively 
targeting August/September 2002 as the timeframe for the next "in
person" event.

Steve went over major items since the last meeting review.  They were:
-  Information inconsistency between transport layer and application
layer - there is no clear separation between application and transport
layers.

-  Obtaining the UPN after authentication in BEEP - Getting UPNs from
BEEP; Need UPN information to
properly resolve other identity/security aspects in CAP but unclear
how/if BEEP can provide this.

Slide items:

We still have some mixing of the Transport and Application layers.
This is due to lack of a clear definition of what each layer really is
(it varies by reader so we must nail down the distinction and resolve
the layering).          

Getting UPNs from BEEP. Paul Hill, our security guy, went over this
topic.  Paul is working with the BEEP and SASL folks to see what can be
bubbled up for CAP to get/use. Currently, only WebMail is known to
support it. We want to build BEEP and SASL on Windows (not only on Unix
as is currently the case);  Currently Paul is working on the port (as we
have the WG meeting even). The model as it exists should work;  He will
look at it again to be sure once we have some more information.

The next topic was the proposal to change the security model: We want to
go from an implicitly Deny w/explicit
Grants to an implicit Grant model w/explicit Denys. This scales better
and is easier to evaluate. 
Essentially the evaluation of access is done from the CS -> Calendar ->
Entity levels where any Deny at any
point prevents access "below" that point.
                                                          
Steve, Paul and others will put together and propose some actual text
pending tentative agreement on the conceptual change.

Slide items:

The SCHEDULE command is gone.  Reusing the CREATE command instead.
This leads to some confusion about
the use of METHOD in 'booking'; is METHOD a verb or a state?

DELETED is a new METHOD value added to codify the "Tombstone" concept we
previously had [explicitly or
implicitly at some points -BK].  We need to clearly define what the CS
behavior is with respect to
deleted entries (ie: exactly what MUST be preserved for sync and other
reasons, etc and what MAY be
preserved, etc).

WE need to reorder the draft to make it easier to follow.  The layout is
more than a bit hard to read [especially the ABNF that appears in the
back after its used elsewhere

Slide items:
- UIDs for components:
 - VCARs (Default, Predefined, Decreed)
 - VALARMs
- Querys
  - Stored Queries - do we need them?
  - Scoping 
  - component.prop
    - USING_PROPERTIES
    - USING_COMPONENTS
  - Querying for floating time events
       
It is unclear how UIDs for some components should be added and how to
deal with uniqueness.  Also, it was questioned how some of the VCARs
function (ie: predefined ones: Are they 'templates' for creating
instances in each VAGENDA or are they copied.  If they are templates,
thats a new concept.  If they are copied then the UIDS are no longer
unique.)

Regarding queries, how useful are stored queries given that the majority
of queries used in C&S are 'time sensitive'
and we have no ability to macro substitute values into saved queries.
For example: Give me all my events
that have an alarm that triggers in the next hour requires that the CUA
send an explicit UTC time for
the bounds.   As such, tomorrow the query would be basically useless. 

There are questions/issues regarding the scoping of queries: The design
currently restricts them to COMPONENT.PROPERTY [without any clear reason
apart from some apparently implicit assumption about the
underlying actual search engine like SQL.

There is no clear definition for the use/need of USING_PROPERTIES and
USING_COMPONENTS.  They appear to
be used as a form of shorthand at best without any functional
need/description for them. 

There is no way to query for "floating time" entries.  The query code
expressly declares that all queried time must be in UTC but thats not
possible for the "Every morning I go jogging from 6AM - 7AM no matter
where I am" case.  "Floating time" (aka Local only) entries have no
associated time zone and as such cannot be converted and stored in UTC.

Going forward:
Slide items:
- Post all issues to the list
- Analyses for all
- Recommendations for many
- Targeting getting issues posted by end of the month
- Work through the issues one at a time
                                                  
All issues will be taken to the list.  There should be an analysis of
each one and preferably a
recommendation for resolving them as well (in the interest of time).
Target posting all of the issues is by the end of March 2002 to the WG
list. We will work thru the issues 1 at a time instead of "flailing" on
several at once and seemingly resolving none.  
                        
Pat will be the Keeper of Order.  TBD will be the Keeper of Issues. Pat
noted that there exist WG chair tools to aid in this process and she
will investigate them and get the relevant parties up to speed on them.

The cochairs/editors want more WG feedback on postings (ie: more than
just 2 people going back and forth on a topic).  Pat suggests that the
"techies" take care to put the painful technical details/explainations
into Plain English (TM) for the rest of the WG so that "less techie
folks" are more inclined to participate.

A quick poll shows that we may not have sufficient people to have a WG
meeting in Japan.  As such we want
to get more progress done on the list before then.

We will deal with the layer issue first.  Much of this is due to the
BEEP changeover.  We want to finish
off the concerns of "XML creep" and the layer bleeding before we get
back to the actual protocol details.

Pat put out a call for "anyone" with BEEPCOREC and SASL implementations
to get engaged in dealing with
this.
       
Larry noted that SASL is lightweight in design.  MD5 is "heavy duty" as
the minimum base for CAP authentication.  There are lots of SASL
implementations and they mostly interoperate. Larry asked why not just
adopt XML now with the new work the WG is doing.  He finds it confusing
to have both XML and iCalendar in the draft.  This gets back
to the prior issue about XML creep that we need to finally resolve. 

Steve responded that we could do the change but we need to make changed
to xcal (which is expired now).  Also, its odd to mix XML and iCalendar
data but the mix is an artifact of the BEEP changeover.  One example is
the SEARCh command that is in XML but it has no data.

Larry pointed out the mix of data dn commands/actions (ie: search) in 1
blob is still confusing.

Steve: we need to better explain the mix in the design text and
descriptions.

Wrapup (Pat):

The WG site calsch.org (or www.calsch.org) is up and has the drafts,
texts and relevant links. 

Meeting adjourned.