From owner-ietf-calendar@mail.imc.org Sun Jul 8 23:36:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20517 for ; Sun, 8 Jul 2001 23:36:41 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f693J1P12188 for ietf-calendar-bks; Sun, 8 Jul 2001 20:19:01 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f693J0m12184 for ; Sun, 8 Jul 2001 20:19:00 -0700 (PDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA07139 for ; Sun, 8 Jul 2001 23:19:03 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3+Sun/8.9.3) id XAA17969; Sun, 8 Jul 2001 23:19:02 -0400 (EDT) Date: Sun, 8 Jul 2001 23:19:02 -0400 (EDT) Message-Id: <200107090319.XAA17969@ind.cs.columbia.edu> X-Authentication-Warning: ind.cs.columbia.edu: lennox set sender to lennox@ind.cs.columbia.edu using -f From: Jonathan Lennox To: ietf-calendar@imc.org Subject: Bugs(?) in RFC 2445 RECUR examples Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just improved my RECUR parser to honor the 'Z' parameter of Date-Time properly, and I discovered that my code was no longer generating the same results as RFC 2445 specifies. On investigating, I think this is actually an error in RFC 2445. The two (or three, one is a double) problematic examples are: Everyday in January, for 3 years: DTSTART;TZID=US-Eastern:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 ==> (1998 9:00 AM EDT)January 1-31 (1999 9:00 AM EDT)January 1-31 (2000 9:00 AM EDT)January 1-31 Every 3 hours from 9:00 AM to 5:00 PM on a specific day: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z ==> (September 2, 1997 EDT)09:00,12:00,15:00 The problem arises because DTSTART is specified in US-Eastern, but UNTIL is specified in UTC (Zulu), as the spec requires. For the first (two) examples, 20000131T090000Z is before 2000 9:00 AM EST January 31 -- it corresponds to TZID=US-Eastern:20000131T040000. Thus, the last occurence of this event should be 2000 9:00 AM EST January 30. (Note also that the time zone abbreviation is wrong for these examples.) Similarly, 19970902T170000Z is TZID=US-Eastern:19970902T130000, so the last occurence of the final recurrence should be September 2, 1997 EDT 12:00. Unless, of course, the intent of the spec is that UNTIL is specified with a Z, but it should nonetheless be interpreted as the same TZID as DTSTART. (I find this ... unlikely.) Comments? What was the motivation behind UNTIL-is-always-UTC, anyway? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Jul 9 11:53:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19332 for ; Mon, 9 Jul 2001 11:53:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69FRQh17610 for ietf-calendar-bks; Mon, 9 Jul 2001 08:27:26 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69FRPm17602 for ; Mon, 9 Jul 2001 08:27:25 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA32652 for ; Mon, 9 Jul 2001 11:27:21 -0400 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f69FRLv21787 for ; Mon, 9 Jul 2001 11:27:21 -0400 (EDT) Message-ID: <0af301c1088b$680c08a0$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <200107090319.XAA17969@ind.cs.columbia.edu> Subject: Re: Bugs(?) in RFC 2445 RECUR examples Date: Mon, 9 Jul 2001 11:25:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jonathan Lennox" To: Sent: 08 July, 2001 23:19 Subject: Bugs(?) in RFC 2445 RECUR examples > > I just improved my RECUR parser to honor the 'Z' parameter of Date-Time > properly, and I discovered that my code was no longer generating the same > results as RFC 2445 specifies. On investigating, I think this is actually > an error in RFC > 2445. [snip] > Comments? What was the motivation behind UNTIL-is-always-UTC, anyway? Looks like a couple of incorrect examples. Probably the UNTIL part should be fixed. As for having UNTIL in UTC, a value in UTC always represents one single instant; if local time were used, then due to daylight shifts, a particular value could represent 1, 2, or a non-existant instant. Graham From owner-ietf-calendar@mail.imc.org Mon Jul 9 12:39:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20989 for ; Mon, 9 Jul 2001 12:39:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69GIwi22563 for ietf-calendar-bks; Mon, 9 Jul 2001 09:18:58 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69GIvm22559 for ; Mon, 9 Jul 2001 09:18:57 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA25779 for ; Mon, 9 Jul 2001 12:18:58 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id MAA27247; Mon, 9 Jul 2001 12:18:58 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15177.55665.578445.463701@grandcentral.cs.columbia.edu> Date: Mon, 9 Jul 2001 12:18:57 -0400 (EDT) To: Subject: Re: Bugs(?) in RFC 2445 RECUR examples In-Reply-To: <0af301c1088b$680c08a0$092e0165@in.steltor.com> References: <200107090319.XAA17969@ind.cs.columbia.edu> <0af301c1088b$680c08a0$092e0165@in.steltor.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, July 9 2001, "Graham Gilmore" wrote to "" saying: > Looks like a couple of incorrect examples. Probably the UNTIL part > should be fixed. Yes, that's what I thought. > As for having UNTIL in UTC, a value in UTC always represents one > single instant; if local time were used, then due to daylight shifts, a > particular value could represent 1, 2, or a non-existant instant. But the same thing's true for every other DATE-TIME in a recurrence (DTSTART, DTEND, etc.) -- and indeed in a calendar object. Why is UNTIL special? I proposed some wording to this list a month or so ago saying that a DATE-TIME value with a TZID SHOULD NOT specify an ambiguous time, and MUST NOT specify a non-existent time; COS-interpreting applications MAY interpret an ambiguous time as any of the possibile occurences of it. I feel this is a better general solution to this problem. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Jul 9 12:49:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21322 for ; Mon, 9 Jul 2001 12:49:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69GHBb22511 for ietf-calendar-bks; Mon, 9 Jul 2001 09:17:11 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69GH9m22506 for ; Mon, 9 Jul 2001 09:17:09 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA01081; Mon, 9 Jul 2001 12:16:29 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f69GGSv26444; Mon, 9 Jul 2001 12:16:28 -0400 (EDT) Message-ID: <3B49D8CA.B1033DAC@steltor.com> Date: Mon, 09 Jul 2001 12:16:10 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: alex@elea.dhs.org, bobmah@mit.edu Subject: [Fwd: New Version Of Guide To Calendaring] Content-Type: multipart/mixed; boundary="------------71A698A449A9484418008FB9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------71A698A449A9484418008FB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is the latest version of the guide. I have made changes based on the many comments I've received. The changes made include: - Use rfc 2629 to write the document in xml. This make generating the draft in the correct text format easy. Furthermore, it also allows one to generate an easy to read html document. - Made some clarifications to the analogies with e-mail. - Removed the iCalendar, iMIP, iTIP, and CAP examples. They were not very useful, made to doc much longer and invited syntax errors, which would have made the doc counterproductive. - Clarified many sections. - A few grammatical and spelling error fixes. - Removed a few redundant sections. We are making another last call. Thus, comments are encouraged. I will resubmit the draft, with changes, if needed, by the deadline for the next IETF. George --------------71A698A449A9484418008FB9 Content-Type: text/html; charset=us-ascii; name="draft-ietf-calsch-inetcal-guide-00.html" Content-Disposition: inline; filename="draft-ietf-calsch-inetcal-guide-00.html" Content-Transfer-Encoding: 7bit Guide to Internet Calendaring
 TOC 
Network Working GroupB. Mahoney
Internet-DraftMIT
Expires: November 1, 2001G. Babics
 Steltor
 A. Taler
 May 3, 2001

Guide to Internet Calendaring
draft-ietf-calsch-inetcal-guide-00

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 1, 2001.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

This document describes the various internet calendaring and scheduling standards and drafts and the relationships between them. It's intention is to provide a context for these documents, assist in their understanding, and potentially help implementers in the design of their standards based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The draft addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and could be targets for future work.


 TOC 

Table of Contents

    1.  Introduction
     1.1  Terminology
     1.2  Concepts and Relationships
     2.  Requirements
     2.1  Fundamental Needs
     2.2  Protocol requirements
     3.  Solutions
     3.1  Examples
     3.2  Systems
     3.2.1  Standalone single-user system
     3.2.2  Single-user systems communicating
     3.2.3  Single-user with multiple CUA
     3.2.4  Single-user with multiple calendars
     3.2.5  Users communicating on a multi-user system
     3.2.6  Users communicating through different multi-user systems
     4.  Important Aspects
     4.1  Timezones
     4.2  Choice of Transport
     4.3  Security
     4.4  Amount of data
     4.5  Recurring Components
     5.  Open Issues
     5.1  Scheduling people, not calendars
     5.2  Administration
     5.3  Notification
     6.  Security considerations
     6.1  Access Control
     6.2  Authentication
     6.3  Using email
     6.4  Other issues
     §  Authors' Addresses
     A.  Acknowledgements
     B.  Bibliography
     §  Full Copyright Statement


 TOC 

1. Introduction

The calendaring and scheduling protocols are intended to provide for the needs of individuals attempting to obtain calendaring information and schedule meetings across the internet, organizations attempting to provide calendaring information on the internet, as well as organizations looking for a calendaring and scheduling solution to deploy internally.

It is the intent of this document to provide a context for the calendar standard and draft documents, assist in their understanding, and potentially help implementers in the design of their internet calendaring and scheduling systems.

Problems not solved by these protocols, as well as security issues to be kept in mind, are discussed at the end of the document.

1.1 Terminology

This memo uses much of the same terminology as iCalendar [RFC-2445], iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following definitions are provided as introductory, the definitions in the protocol specifications are the canonical ones.

Calendar

A collection of events, todos, journal entries, etc. A calendar could be the content of a person or a resource's agenda; it could also be a collection of data serving a more specialized need. Calendars are the basic storage containers for calendaring information.

Calendar Access Rights

A set of rules for a calendar describing who may perform which operations on that calendar, such as reading and writing information.

Calendar Service

A running server application which provides access to a collection of calendars.

Calendar Store (CS)

A data store of a calendar service. A calendar service may have several calendar stores, and each store may contain several calendars, as well as properties and components outside of the calendars.

Calendar User (CU)

An entity (often a human) that accesses calendar information.

Calendar User Agent (CUA)

Software used by the calendar user that communicates with calendar services to provide the user access to calendar information.

Component

A piece of calendar data such as an event, a todo or an alarm. Information about components is stored as properties of those components.

Delegator

Is a calendar user (sometimes called the delegatee) who has assigned his or her participation in a scheduled calendar component (e.g., VEVENT) to another calendar user (sometimes called the delegatee).

Delegate

Is a calendar user (sometimes called the delegatee) who has been assigned participation in a scheduled calendar component (e.g., VEVENT) by one of the attendees in the scheduled calendar component (sometimes called the delegator). An example of a delegate is a team member told to go to a particular meeting.

Designate

Is a calendar user who is authorized to act on behalf of another calendar user. An example of a designate is an assistant.

Local Store

A CS which is on the same platform as the CUA.

Property

A property of a component, such as a description or a start time.

Remote Store

A CS which is not on the same platform as the CUA.

1.2 Concepts and Relationships

iCalendar is the language used to describe calendar objects. iTIP is a way to use the language to do scheduling. iMIP is how to do iTIP with email. CAP is a way to use the language, to access a calendar store in real-time.

The relationship between the calendaring protocols is similar to that between the email protocols. In those terms iCalendar is like RFC 822, iTIP and iMIP are like SMTP, and CAP is like POP or IMAP.


 TOC 

2. Requirements

2.1 Fundamental Needs

The following examples illustrate people's and organizations' basic calendaring and scheduling needs:

a] A doctor wishes to keep track of all his appointments.

Need: Read and manipulate one's own calendar with only one CUA.

b] A busy musician wants to maintain her schedule with different devices, such as with an internet-based agenda or with a PDA.

Need: Read and manipulate one's own calendar, possibly with solutions from different vendors.

c] A software development team wishes to share agenda information by using a group scheduling product in order to more effectively schedule their time.

Need: Share calendar information with users using the same calendar service.

d] A teacher wants his students to be able to schedule calendar entries during his office hours.

Need: Schedule calendar events, todos and journals with users using the same calendar service.

e] A movie theater wants to publish its schedule so that prospective customers can easily access it.

Need: Share calendar information with users using other calendar services, possibly from different vendors.

f] A social club wants to be able to schedule calendar entries effectively with its members.

Need: Schedule calendar events and todos with users using other calendar services, possibly from different vendors.

2.2 Protocol requirements

Some of the needs can be met with proprietary solutions (a, c, d), but others can not (b, e, f). From these needs we can establish that protocols are required for accessing information in a calendar store, and for scheduling calendar entries. In addition these protocols require a data format for representing calendar information.

These roles are filled by the following protocol requirements.

- iCalendar [RFC-2445] is the data format

iCalendar [RFC-2445] provides data format for representing calendar information which the other protocols can use. iCalendar [RFC-2445] can also be used in other contexts such as a drag and drop format or an export/import format. All the other protocols depend on iCalendar [RFC-2445], so all elements of a standards-based calendaring and scheduling systems will have to interpret iCalendar [RFC-2445].

- iTIP [RFC-2446] is the scheduling protocol

iTIP [RFC-2446] describes the messages used to schedule calendar events. These messages are represented in iCalendar [RFC-2445], and have semantics that include such things as being an invitation to a meeting, an acceptance of an invitation or the assignation of a task.

iTIP [RFC-2446] messages are used in the scheduling work flow, where users exchange messages in order to organize things such as events and todos. CUAs generate and interpret iTIP [RFC-2446] messages at the direction of the calendar user. With iTIP [RFC-2446] one can create, modify, delete, reply to, counter, and decline counters to the various iCalendar [RFC-2445] components. Furthermore, one can also request the freebusy time of other people.

iTIP [RFC-2446] is transport-independent, and has one specified transport bindings: iMIP [RFC-2447] is a binding to email. In addition [CAP] will provide a real-time binding of iTIP [RFC-2446], allowing CUAs to perform calendar management as well as scheduling over a single connection.

- [CAP] is the calendar management protocol

[CAP] describes the messages used to manage calendars on a calendar store. These messages use iCalendar [RFC-2445] to describe various components such as events and todos. With these messages one can do the operations in iTIP [RFC-2446] and other operations relating to a calendar store, such as search, creating calendars, specifying calendar properties, and being able to specify access rights to one's calendars.


 TOC 

3. Solutions

3.1 Examples

Returning to the examples of section 2.1, they can be solved using the protocols in the following ways:

a] The doctor can use a proprietary CUA with a local store, and perhaps use iCalendar [RFC-2445] as a storage mechanism. This would allow the doctor to easily import his store into another application that supports iCalendar [RFC-2445].

b] The musician who wishes to access her agenda from anywhere can use a [CAP] enabled calendar service accessible through the internet. She can then use whichever [CAP] clients are available to access the data.

A proprietary system could also be employed which provides access through a web-based interface, but the use of [CAP] would be superior in that it would allow the use of third party tools, such as PDA synchronization tools.

c] The development team can use a calendar service which supports [CAP] and then each member can use a [CAP]-enabled CUA of their choice.

Alternatively, each member could use an iMIP [RFC-2447]-enabled CUA, and they could book meetings over email. This solution has the drawback that it is difficult to examine the other agendas, making organizing meetings more difficult.

Proprietary solutions are also available, but they require that all people use clients by the same vendor, and disallow the use of third party applications.

d] The teacher can set up a calendar service, and have students book time through any of the iTIP [RFC-2446] bindings. [CAP] provides real-time access, but could require additional configuration. iMIP [RFC-2447] would be the easiest to configure, but may require more email processing.

If [CAP] access is provided then determining the state of the teacher's schedule is straightforward. If not, this can be determined through iTIP [RFC-2446] free-busy requests. Non- standard methods could also be employed, such as serving up ICAL, HTML, XML over HTTP.

A proprietary system could also be used, but would require that all students be able to use software from a specific vendor.

e] For publishing a movie theater's schedule [CAP] provides the most advanced access and search capabilities. It also allows easy integration with its customer's calendar systems.

Non-standard methods such as serving data over HTTP could also be employed, but would be harder to integrate with customer's systems.

Using a completely proprietary solutions would be very difficult since it would require every user to install and use proprietary software.

f] The social club could distribute meeting information in the form of iTIP [RFC-2446] messages. This could be done over email using iMIP [RFC-2447]. Meeting invitations, as well as a full published agenda could be distributed.

Alternatively, the social club could provide access to a [CAP] enabled calendar service, however this solution would be more expensive since it requires the maintenance of a server.

3.2 Systems

The following diagrams illustrate possible example systems and usage of the protocols.

3.2.1 Standalone single-user system

A single user system that does not communicate with other systems need not employ any of the protocols. However, it may use iCalendar [RFC-2445] as a data format in some places. 

       -----------       O
      | CUA w/    |     -+- user
      |local store|      A
       -----------      / \

3.2.2 Single-user systems communicating

Users with single-user systems may schedule meetings with each other using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use is iMIP [RFC-2447], since it messages can be held in their mail queue, which we assume to already exist. [CAP] could also be used. 

       O   -----------                    -----------   O
      -+- | CUA w/    | -----[IMIP]----- | CUA w/    | -+- user
       A  |local store|     Internet     |local store|  A
      / \  -----------                    -----------  / \

3.2.3 Single-user with multiple CUA

A single user may use more than one CUA to access his or her calendar. The user may use a PDA, a web client, a PC, or some other device, depending an accessibility. Some of these clients may have local stores and others may not. If they do, then they need to ensure that the data on the CUA is synchronized with the data on the CS. 

                 -----------
                |   CUA w   | -----[CAP]----------+
                |local store|                     |
           O     -----------                    ----------
          -+-                                  |   CS     |
           A                                   |          |
          / \                                   ----------
                 -----------                      |
                |  CUA w/o  | -----[CAP]----------+
                |local store|
                 -----------

3.2.4 Single-user with multiple calendars

A single user may have many independent calendars. One may be work related, another for personal use. The CUA may or may not have a local store. If it does, then it needs to ensure that the data on the CUA is synchronized with the data on both of the CS. 

                                                ----------
                      +------------[CAP]------ |   CS     |
                      |                        |          |
           O     -----------                    ----------
          -+-   |  CUA      |
           A    |           |
          / \    -----------
                      |                         ----------
                      +------------[CAP]------ |   CS     |
                                               |          |
                                                ----------

3.2.5 Users communicating on a multi-user system

Users on a multi-user system may schedule meetings with each other using [CAP]-enabled CUA and service. The CUA may or may not have a local store. If they do, then they need to ensure that the data on the CUA is synchronized with the data on the CS. 

           O     -----------
          -+-   |   CUA w   | -----[CAP]----------+
           A    |local store|                     |
          / \    -----------                    ----------
                                               |   CS     |
                                               |          |
                                                ----------
           O     -----------                      |
          -+-   |  CUA w/o  | -----[CAP]----------+
           A    |local store|
          / \    -----------

3.2.6 Users communicating through different multi-user systems

Users on a multi-user system may need to schedule meetings with user on a different multi user system. The services can communicate using [CAP] or iMIP [RFC-2447]. 

          O     -----------                    ----------
         -+-   |   CUA w   | -----[CAP]-------|   CS     |
          A    |local store|                  |          |
         / \    -----------                    ----------
                                                   |
                                             [CAP] or [iMIP]
                                                   |
          O     -----------                    ----------
         -+-   |  CUA w/o  | -----[CAP]-------|   CS     |
          A    |local store|                  |          |
         / \    -----------                    ----------


 TOC 

4. Important Aspects

There are a number of important aspects of these calendaring documents of which people, especially implementers, should be aware of.

4.1 Timezones

The dates and times in components can refer to timezones. These timezones can be defined in some central store, or they may be defined by a user to fit his or her needs. Any user and application should be aware of timezones and timezone differences. New timezones may be added, and others removed. Two different vendors may describe the same timezone differently (such as by using a different name).

4.2 Choice of Transport

There are issues to be aware of in choosing a transport mechanism. The choices are a network protocol, such as CAP, or a store and forward (email) solution.

The use of a network ("on-the-wire") mechanism may require some organizations to make provisions to allow calendaring traffic to traverse a corporate firewall on the required ports. Depending on the organizational culture, this may be a challenging social exercise.

The use of an email-based mechanism exposes innately time sensitive data to unbounded latency. Large or heavily utilized mail systems may experience an unacceptable delay in message receipt.

4.3 Security

See the "Security Considerations" section below.

4.4 Amount of data

In some cases a component may be very large. For instance, some attachments may be very large. Some applications may be low- bandwidth or be limited in the amount of data they can store. The size of the data may be controlled in [CAP], by specifying maximums. In iMIP [RFC-2447] it can be controlled, by restricting the maximum size of the email that the application can download.

4.5 Recurring Components

In iCAL [RFC-2445] one can specify complex recurrence rules for VEVENTs, VTODOs, and VJOURNALs. There is the danger that applications interpret these rules differently. Thus, one must make sure that one is careful with recurrence rules.


 TOC 

5. Open Issues

Many issues are not currently resolved by these protocols, and many desirable features are not yet provided. Some of the more prominent ones follow.

5.1 Scheduling people, not calendars

Meetings are scheduled with people, however people may have many calendars, and may store these calendars in many places. There may also be many routes to contact them. These protocols do not attempt to provide unique access for contacting a single person. Instead, 'calendar addresses' are booked, which may be email addresses or individual calendars. It is up to the users themselves to orchestrate mechanisms to ensure that the bookings go to the right place.

5.2 Administration

These protocols do not address the issues of administering users and calendars on a calendar service. This must be handled by proprietary mechanisms for each implementation.

5.3 Notification

People often wish to be notified of upcoming events, new events, or changes to events. These protocols do not attempt to address these needs in a real-time fashion. Instead, the ability to store alarm information on events is provided, which can be used to provide client-side notification of upcoming events. To organize notification of new or changed events clients will have to poll the data store.


 TOC 

6. Security considerations

6.1 Access Control

There has to be reasonable granularity in the configuration options for access to data through [CAP], so that what should be released to requesters is released, and what shouldn't isn't. Details of handling this are described in [CAP].

6.2 Authentication

Access control must be coupled with a good authentication system, so that the right people get the right information. For [CAP] this means requiring authentication before any data base access can be performed, and checking access rights and authentication credentials before releasing information. [CAP] uses SASL for this authentication. In iMIP [RFC-2447], this may present some challenges, as authentication is often not a consideration in store-and-forward protocols.

Authentication is also important for scheduling, in that receivers of scheduling messages should be able to validate the apparent sender. Since scheduling messages are wrapped in MIME [RFC-2045], signing and encryption is available for free. For messages transmitted over mail this is the only available alternative. It is suggested that developers take care in implementing the security features in iMIP [RFC-2447], bearing in mind that the concept and need may be foreign or non-obvious to users, yet essential for the system to function as they might expect.

The real-time protocols provide for the authentication of users, and the preservation of that authentication information, allowing for validation by the receiving end-user or server.

6.3 Using email

Because scheduling information can be transmitted over mail without any authentication information, email spoofing is extremely easy if the receiver is not checking for authentication. It is suggested that implementers consider requiring authentication as a default, using mechanisms such as are described in Section 2 of iMIP [RFC-2447]. The use of email, and the potential for anonymous connections, means that 'calendar spam' is possible. Developers should consider this threat when designing systems, particularly those that allow for automated request processing.

6.4 Other issues

The current security context should be obvious to users. Because the underlying mechanisms may not be clear to users, efforts to make clear the current state in the UI should be made. One example is the 'lock' icon used in some web browsers during secure connections. With both iMIP [RFC-2447] and [CAP], the possibilities of Denial of Service attacks must be considered. The ability to flood a calendar system with bogus requests is likely to be exploited once these systems become widely deployed, and detection and recovery methods will need to be considered.


 TOC 

Authors' Addresses

  Bob Mahoney
  MIT
  E40-327
  77 Massachusetts Avenue
  Cambridge, MA 02139
  US
Phone:  (617) 253-0774
EMail:  bobmah@mit.edu
  
  George Babics
  Steltor
  2000 Peel Street
  Montreal, Quebec H3A 2W5
  CA
Phone:  (514) 733-8500 x4201
EMail:  georgeb@steltor.com
  
  Alex Taler
EMail:  dissent@elea.dhs.org
 TOC 

Appendix A. Acknowledgements

Thanks to the following who have participated in the development of this document:

Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn.


 TOC 

Appendix B. Bibliography

[RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998.

[RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998.

[RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-Based Interoperability Protocol - iMIP", RFC 2447, November 1998.

[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[CAP] Mansour, S., Royer, D., Babics, G., and Hill, P. "Calendar Access Protocol (CAP)" draft-ietf-calsch-cap-04.txt


 TOC 

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

 --------------71A698A449A9484418008FB9 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-calsch-inetcal-guide-00.txt" Content-Disposition: inline; filename="draft-ietf-calsch-inetcal-guide-00.txt" Content-Transfer-Encoding: 7bit Network Working Group B. Mahoney Internet-Draft MIT Expires: November 1, 2001 G. Babics Steltor A. Taler May 3, 2001 Guide to Internet Calendaring draft-ietf-calsch-inetcal-guide-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 1, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes the various internet calendaring and scheduling standards and drafts and the relationships between them. It's intention is to provide a context for these documents, assist in their understanding, and potentially help implementers in the design of their standards based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The draft addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and could be targets for future work. Mahoney, et. al. Expires November 1, 2001 [Page 1] Internet-Draft Guide to Internet Calendaring May 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 6 2.2 Protocol requirements . . . . . . . . . . . . . . . . . . . 6 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1 Standalone single-user system . . . . . . . . . . . . . . . 9 3.2.2 Single-user systems communicating . . . . . . . . . . . . . 9 3.2.3 Single-user with multiple CUA . . . . . . . . . . . . . . . 10 3.2.4 Single-user with multiple calendars . . . . . . . . . . . . 10 3.2.5 Users communicating on a multi-user system . . . . . . . . . 11 3.2.6 Users communicating through different multi-user systems . . 11 4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 12 4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 12 4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 12 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Scheduling people, not calendars . . . . . . . . . . . . . . 14 5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security considerations . . . . . . . . . . . . . . . . . . 15 6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 15 6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 15 6.3 Using email . . . . . . . . . . . . . . . . . . . . . . . . 15 6.4 Other issues . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 B. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 Mahoney, et. al. Expires November 1, 2001 [Page 2] Internet-Draft Guide to Internet Calendaring May 2001 1. Introduction The calendaring and scheduling protocols are intended to provide for the needs of individuals attempting to obtain calendaring information and schedule meetings across the internet, organizations attempting to provide calendaring information on the internet, as well as organizations looking for a calendaring and scheduling solution to deploy internally. It is the intent of this document to provide a context for the calendar standard and draft documents, assist in their understanding, and potentially help implementers in the design of their internet calendaring and scheduling systems. Problems not solved by these protocols, as well as security issues to be kept in mind, are discussed at the end of the document. 1.1 Terminology This memo uses much of the same terminology as iCalendar [RFC-2445], iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following definitions are provided as introductory, the definitions in the protocol specifications are the canonical ones. Calendar A collection of events, todos, journal entries, etc. A calendar could be the content of a person or a resource's agenda; it could also be a collection of data serving a more specialized need. Calendars are the basic storage containers for calendaring information. Calendar Access Rights A set of rules for a calendar describing who may perform which operations on that calendar, such as reading and writing information. Calendar Service A running server application which provides access to a collection of calendars. Calendar Store (CS) A data store of a calendar service. A calendar service may have several calendar stores, and each store may contain several calendars, as well as properties and components outside of the Mahoney, et. al. Expires November 1, 2001 [Page 3] Internet-Draft Guide to Internet Calendaring May 2001 calendars. Calendar User (CU) An entity (often a human) that accesses calendar information. Calendar User Agent (CUA) Software used by the calendar user that communicates with calendar services to provide the user access to calendar information. Component A piece of calendar data such as an event, a todo or an alarm. Information about components is stored as properties of those components. Delegator Is a calendar user (sometimes called the delegatee) who has assigned his or her participation in a scheduled calendar component (e.g., VEVENT) to another calendar user (sometimes called the delegatee). Delegate Is a calendar user (sometimes called the delegatee) who has been assigned participation in a scheduled calendar component (e.g., VEVENT) by one of the attendees in the scheduled calendar component (sometimes called the delegator). An example of a delegate is a team member told to go to a particular meeting. Designate Is a calendar user who is authorized to act on behalf of another calendar user. An example of a designate is an assistant. Local Store A CS which is on the same platform as the CUA. Property A property of a component, such as a description or a start time. Remote Store A CS which is not on the same platform as the CUA. Mahoney, et. al. Expires November 1, 2001 [Page 4] Internet-Draft Guide to Internet Calendaring May 2001 1.2 Concepts and Relationships iCalendar is the language used to describe calendar objects. iTIP is a way to use the language to do scheduling. iMIP is how to do iTIP with email. CAP is a way to use the language, to access a calendar store in real-time. The relationship between the calendaring protocols is similar to that between the email protocols. In those terms iCalendar is like RFC 822, iTIP and iMIP are like SMTP, and CAP is like POP or IMAP. Mahoney, et. al. Expires November 1, 2001 [Page 5] Internet-Draft Guide to Internet Calendaring May 2001 2. Requirements 2.1 Fundamental Needs The following examples illustrate people's and organizations' basic calendaring and scheduling needs: a] A doctor wishes to keep track of all his appointments. Need: Read and manipulate one's own calendar with only one CUA. b] A busy musician wants to maintain her schedule with different devices, such as with an internet-based agenda or with a PDA. Need: Read and manipulate one's own calendar, possibly with solutions from different vendors. c] A software development team wishes to share agenda information by using a group scheduling product in order to more effectively schedule their time. Need: Share calendar information with users using the same calendar service. d] A teacher wants his students to be able to schedule calendar entries during his office hours. Need: Schedule calendar events, todos and journals with users using the same calendar service. e] A movie theater wants to publish its schedule so that prospective customers can easily access it. Need: Share calendar information with users using other calendar services, possibly from different vendors. f] A social club wants to be able to schedule calendar entries effectively with its members. Need: Schedule calendar events and todos with users using other calendar services, possibly from different vendors. 2.2 Protocol requirements Some of the needs can be met with proprietary solutions (a, c, d), but others can not (b, e, f). From these needs we can establish that protocols are required for accessing information in a calendar store, Mahoney, et. al. Expires November 1, 2001 [Page 6] Internet-Draft Guide to Internet Calendaring May 2001 and for scheduling calendar entries. In addition these protocols require a data format for representing calendar information. These roles are filled by the following protocol requirements. - iCalendar [RFC-2445] is the data format iCalendar [RFC-2445] provides data format for representing calendar information which the other protocols can use. iCalendar [RFC-2445] can also be used in other contexts such as a drag and drop format or an export/import format. All the other protocols depend on iCalendar [RFC-2445], so all elements of a standards- based calendaring and scheduling systems will have to interpret iCalendar [RFC-2445]. - iTIP [RFC-2446] is the scheduling protocol iTIP [RFC-2446] describes the messages used to schedule calendar events. These messages are represented in iCalendar [RFC-2445], and have semantics that include such things as being an invitation to a meeting, an acceptance of an invitation or the assignation of a task. iTIP [RFC-2446] messages are used in the scheduling work flow, where users exchange messages in order to organize things such as events and todos. CUAs generate and interpret iTIP [RFC-2446] messages at the direction of the calendar user. With iTIP [RFC- 2446] one can create, modify, delete, reply to, counter, and decline counters to the various iCalendar [RFC-2445] components. Furthermore, one can also request the freebusy time of other people. iTIP [RFC-2446] is transport-independent, and has one specified transport bindings: iMIP [RFC-2447] is a binding to email. In addition [CAP] will provide a real-time binding of iTIP [RFC- 2446], allowing CUAs to perform calendar management as well as scheduling over a single connection. - [CAP] is the calendar management protocol [CAP] describes the messages used to manage calendars on a calendar store. These messages use iCalendar [RFC-2445] to describe various components such as events and todos. With these messages one can do the operations in iTIP [RFC-2446] and other operations relating to a calendar store, such as search, creating calendars, specifying calendar properties, and being able to specify access rights to one's calendars. Mahoney, et. al. Expires November 1, 2001 [Page 7] Internet-Draft Guide to Internet Calendaring May 2001 3. Solutions 3.1 Examples Returning to the examples of section 2.1, they can be solved using the protocols in the following ways: a] The doctor can use a proprietary CUA with a local store, and perhaps use iCalendar [RFC-2445] as a storage mechanism. This would allow the doctor to easily import his store into another application that supports iCalendar [RFC-2445]. b] The musician who wishes to access her agenda from anywhere can use a [CAP] enabled calendar service accessible through the internet. She can then use whichever [CAP] clients are available to access the data. A proprietary system could also be employed which provides access through a web-based interface, but the use of [CAP] would be superior in that it would allow the use of third party tools, such as PDA synchronization tools. c] The development team can use a calendar service which supports [CAP] and then each member can use a [CAP]-enabled CUA of their choice. Alternatively, each member could use an iMIP [RFC-2447]-enabled CUA, and they could book meetings over email. This solution has the drawback that it is difficult to examine the other agendas, making organizing meetings more difficult. Proprietary solutions are also available, but they require that all people use clients by the same vendor, and disallow the use of third party applications. d] The teacher can set up a calendar service, and have students book time through any of the iTIP [RFC-2446] bindings. [CAP] provides real-time access, but could require additional configuration. iMIP [RFC-2447] would be the easiest to configure, but may require more email processing. If [CAP] access is provided then determining the state of the teacher's schedule is straightforward. If not, this can be determined through iTIP [RFC-2446] free-busy requests. Non- standard methods could also be employed, such as serving up ICAL, HTML, XML over HTTP. A proprietary system could also be used, but would require that Mahoney, et. al. Expires November 1, 2001 [Page 8] Internet-Draft Guide to Internet Calendaring May 2001 all students be able to use software from a specific vendor. e] For publishing a movie theater's schedule [CAP] provides the most advanced access and search capabilities. It also allows easy integration with its customer's calendar systems. Non-standard methods such as serving data over HTTP could also be employed, but would be harder to integrate with customer's systems. Using a completely proprietary solutions would be very difficult since it would require every user to install and use proprietary software. f] The social club could distribute meeting information in the form of iTIP [RFC-2446] messages. This could be done over email using iMIP [RFC-2447]. Meeting invitations, as well as a full published agenda could be distributed. Alternatively, the social club could provide access to a [CAP] enabled calendar service, however this solution would be more expensive since it requires the maintenance of a server. 3.2 Systems The following diagrams illustrate possible example systems and usage of the protocols. 3.2.1 Standalone single-user system A single user system that does not communicate with other systems need not employ any of the protocols. However, it may use iCalendar [RFC-2445] as a data format in some places. ----------- O | CUA w/ | -+- user |local store| A ----------- / \ 3.2.2 Single-user systems communicating Users with single-user systems may schedule meetings with each other using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use is iMIP [RFC-2447], since it messages can be held in their mail queue, which we assume to already exist. [CAP] could also be used. Mahoney, et. al. Expires November 1, 2001 [Page 9] Internet-Draft Guide to Internet Calendaring May 2001 O ----------- ----------- O -+- | CUA w/ | -----[IMIP]----- | CUA w/ | -+- user A |local store| Internet |local store| A / \ ----------- ----------- / \ 3.2.3 Single-user with multiple CUA A single user may use more than one CUA to access his or her calendar. The user may use a PDA, a web client, a PC, or some other device, depending an accessibility. Some of these clients may have local stores and others may not. If they do, then they need to ensure that the data on the CUA is synchronized with the data on the CS. ----------- | CUA w | -----[CAP]----------+ |local store| | O ----------- ---------- -+- | CS | A | | / \ ---------- ----------- | | CUA w/o | -----[CAP]----------+ |local store| ----------- 3.2.4 Single-user with multiple calendars A single user may have many independent calendars. One may be work related, another for personal use. The CUA may or may not have a local store. If it does, then it needs to ensure that the data on the CUA is synchronized with the data on both of the CS. ---------- +------------[CAP]------ | CS | | | | O ----------- ---------- -+- | CUA | A | | / \ ----------- | ---------- +------------[CAP]------ | CS | | | ---------- Mahoney, et. al. Expires November 1, 2001 [Page 10] Internet-Draft Guide to Internet Calendaring May 2001 3.2.5 Users communicating on a multi-user system Users on a multi-user system may schedule meetings with each other using [CAP]-enabled CUA and service. The CUA may or may not have a local store. If they do, then they need to ensure that the data on the CUA is synchronized with the data on the CS. O ----------- -+- | CUA w | -----[CAP]----------+ A |local store| | / \ ----------- ---------- | CS | | | ---------- O ----------- | -+- | CUA w/o | -----[CAP]----------+ A |local store| / \ ----------- 3.2.6 Users communicating through different multi-user systems Users on a multi-user system may need to schedule meetings with user on a different multi user system. The services can communicate using [CAP] or iMIP [RFC-2447]. O ----------- ---------- -+- | CUA w | -----[CAP]-------| CS | A |local store| | | / \ ----------- ---------- | [CAP] or [iMIP] | O ----------- ---------- -+- | CUA w/o | -----[CAP]-------| CS | A |local store| | | / \ ----------- ---------- Mahoney, et. al. Expires November 1, 2001 [Page 11] Internet-Draft Guide to Internet Calendaring May 2001 4. Important Aspects There are a number of important aspects of these calendaring documents of which people, especially implementers, should be aware of. 4.1 Timezones The dates and times in components can refer to timezones. These timezones can be defined in some central store, or they may be defined by a user to fit his or her needs. Any user and application should be aware of timezones and timezone differences. New timezones may be added, and others removed. Two different vendors may describe the same timezone differently (such as by using a different name). 4.2 Choice of Transport There are issues to be aware of in choosing a transport mechanism. The choices are a network protocol, such as CAP, or a store and forward (email) solution. The use of a network ("on-the-wire") mechanism may require some organizations to make provisions to allow calendaring traffic to traverse a corporate firewall on the required ports. Depending on the organizational culture, this may be a challenging social exercise. The use of an email-based mechanism exposes innately time sensitive data to unbounded latency. Large or heavily utilized mail systems may experience an unacceptable delay in message receipt. 4.3 Security See the "Security Considerations" (Section 6) section below. 4.4 Amount of data In some cases a component may be very large. For instance, some attachments may be very large. Some applications may be low- bandwidth or be limited in the amount of data they can store. The size of the data may be controlled in [CAP], by specifying maximums. In iMIP [RFC-2447] it can be controlled, by restricting the maximum size of the email that the application can download. 4.5 Recurring Components In iCAL [RFC-2445] one can specify complex recurrence rules for VEVENTs, VTODOs, and VJOURNALs. There is the danger that Mahoney, et. al. Expires November 1, 2001 [Page 12] Internet-Draft Guide to Internet Calendaring May 2001 applications interpret these rules differently. Thus, one must make sure that one is careful with recurrence rules. Mahoney, et. al. Expires November 1, 2001 [Page 13] Internet-Draft Guide to Internet Calendaring May 2001 5. Open Issues Many issues are not currently resolved by these protocols, and many desirable features are not yet provided. Some of the more prominent ones follow. 5.1 Scheduling people, not calendars Meetings are scheduled with people, however people may have many calendars, and may store these calendars in many places. There may also be many routes to contact them. These protocols do not attempt to provide unique access for contacting a single person. Instead, 'calendar addresses' are booked, which may be email addresses or individual calendars. It is up to the users themselves to orchestrate mechanisms to ensure that the bookings go to the right place. 5.2 Administration These protocols do not address the issues of administering users and calendars on a calendar service. This must be handled by proprietary mechanisms for each implementation. 5.3 Notification People often wish to be notified of upcoming events, new events, or changes to events. These protocols do not attempt to address these needs in a real-time fashion. Instead, the ability to store alarm information on events is provided, which can be used to provide client-side notification of upcoming events. To organize notification of new or changed events clients will have to poll the data store. Mahoney, et. al. Expires November 1, 2001 [Page 14] Internet-Draft Guide to Internet Calendaring May 2001 6. Security considerations 6.1 Access Control There has to be reasonable granularity in the configuration options for access to data through [CAP], so that what should be released to requesters is released, and what shouldn't isn't. Details of handling this are described in [CAP]. 6.2 Authentication Access control must be coupled with a good authentication system, so that the right people get the right information. For [CAP] this means requiring authentication before any data base access can be performed, and checking access rights and authentication credentials before releasing information. [CAP] uses SASL for this authentication. In iMIP [RFC-2447], this may present some challenges, as authentication is often not a consideration in store- and-forward protocols. Authentication is also important for scheduling, in that receivers of scheduling messages should be able to validate the apparent sender. Since scheduling messages are wrapped in MIME [RFC-2045], signing and encryption is available for free. For messages transmitted over mail this is the only available alternative. It is suggested that developers take care in implementing the security features in iMIP [RFC-2447], bearing in mind that the concept and need may be foreign or non-obvious to users, yet essential for the system to function as they might expect. The real-time protocols provide for the authentication of users, and the preservation of that authentication information, allowing for validation by the receiving end-user or server. 6.3 Using email Because scheduling information can be transmitted over mail without any authentication information, email spoofing is extremely easy if the receiver is not checking for authentication. It is suggested that implementers consider requiring authentication as a default, using mechanisms such as are described in Section 3 of iMIP [RFC- 2447]. The use of email, and the potential for anonymous connections, means that 'calendar spam' is possible. Developers should consider this threat when designing systems, particularly those that allow for automated request processing. Mahoney, et. al. Expires November 1, 2001 [Page 15] Internet-Draft Guide to Internet Calendaring May 2001 6.4 Other issues The current security context should be obvious to users. Because the underlying mechanisms may not be clear to users, efforts to make clear the current state in the UI should be made. One example is the 'lock' icon used in some web browsers during secure connections. With both iMIP [RFC-2447] and [CAP], the possibilities of Denial of Service attacks must be considered. The ability to flood a calendar system with bogus requests is likely to be exploited once these systems become widely deployed, and detection and recovery methods will need to be considered. Authors' Addresses Bob Mahoney MIT E40-327 77 Massachusetts Avenue Cambridge, MA 02139 US Phone: (617) 253-0774 EMail: bobmah@mit.edu George Babics Steltor 2000 Peel Street Montreal, Quebec H3A 2W5 CA Phone: (514) 733-8500 x4201 EMail: georgeb@steltor.com Alex Taler EMail: dissent@elea.dhs.org Mahoney, et. al. Expires November 1, 2001 [Page 16] Internet-Draft Guide to Internet Calendaring May 2001 Appendix A. Acknowledgements Thanks to the following who have participated in the development of this document: Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn. Mahoney, et. al. Expires November 1, 2001 [Page 17] Internet-Draft Guide to Internet Calendaring May 2001 Appendix B. Bibliography [RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998. [RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998. [RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-Based Interoperability Protocol - iMIP", RFC 2447, November 1998. [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [CAP] Mansour, S., Royer, D., Babics, G., and Hill, P. "Calendar Access Protocol (CAP)" draft-ietf-calsch-cap-04.txt Mahoney, et. al. Expires November 1, 2001 [Page 18] Internet-Draft Guide to Internet Calendaring May 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mahoney, et. al. Expires November 1, 2001 [Page 19] --------------71A698A449A9484418008FB9-- From owner-ietf-calendar@mail.imc.org Mon Jul 9 22:22:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04600 for ; Mon, 9 Jul 2001 22:22:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6A22Nq06639 for ietf-calendar-bks; Mon, 9 Jul 2001 19:02:23 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6A22Cm06629 for ; Mon, 9 Jul 2001 19:02:12 -0700 (PDT) Received: (qmail 154381 invoked from network); 10 Jul 2001 01:58:30 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 10 Jul 2001 01:58:30 -0000 Message-ID: <3B4A6084.77FAE423@kasey.umkc.edu> Date: Mon, 09 Jul 2001 20:55:16 -0500 From: "David L. Nicol" Organization: University of Missouri - Kansas City supercomputing infrastructure X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: cap-talk@mail.eros-os.org, ietf-calendar@imc.org, bobmah@mit.edu Subject: Is there a capability RFC? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Reading the open issues of http://www.normos.org/ietf/draft/draft-ietf-calsch-inetcal-guide-00.txt (section 5.1 and 5.2) and the bits about Security, which seem "tacked on," it occurs to me that a Standard Capability Protocol (capabilities are 1024 bits long, they include time-stamps and encooded origin info in a standard way, etcetera) would be a very good thing, if it doesn't exist already, and it would allow interoperability in much more interesting ways that the complex mutual trust relationships that the state-of-the art seems to require. For instance, the "ability to flood a calendar system with bogus requests" could be greatly mitigated by use of capabilities in the basic archtecture. If every event is persistently tagged with the capability under which it was posted, removing (and submitting for re-moderation) all events posted under a compromised capability becomes trivial. Using capabilities, all the iTIP (rfc 2446) activities could be safely delegated. In fact, anything restricted to any RFC-defined entity could be safely delegated. For now, rfc 2445 does define X-* extensions, reserved for experimentation, so a suite of calendaring products that went ahead and implemented some kind of X-CAPABILITY field that could cause a CS to eliminate or skip over certain administrative checks could exist, but compliant release, in light of ; Reservered for experimental use. Not intended for use in ; released products. would require CAPABILITY to be promoted to a listed element of something. Perhaps CAPABILITY would be best inserted as part of MIME rather than this particular MIME-encapsualted application? And there remains the big-picture problem of where are all the laid-off personal secretaries supposed to do once it becomes possible to give someone a capability code and have a reasonable expectation of the recipient being able to leverage it into a meeting appointment with no further human interaction? -- David Nicol 816.235.1187 Series EE bonds can be exchanged for Series HH savings bonds. From owner-ietf-calendar@mail.imc.org Tue Jul 10 12:20:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06800 for ; Tue, 10 Jul 2001 12:20:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AG3YL23104 for ietf-calendar-bks; Tue, 10 Jul 2001 09:03:34 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AG3Wm23100 for ; Tue, 10 Jul 2001 09:03:32 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6AG3nf04507; Tue, 10 Jul 2001 12:03:50 -0400 Message-ID: <3B4B2763.2C616214@ecal.com> Date: Tue, 10 Jul 2001 12:03:47 -0400 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "David L. Nicol" CC: cap-talk@mail.eros-os.org, ietf-calendar@imc.org, bobmah@mit.edu Subject: Re: Is there a capability RFC? References: <3B4A6084.77FAE423@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "David L. Nicol" wrote: > it occurs to me > that a Standard Capability Protocol (capabilities are 1024 bits long, > they include time-stamps and encooded origin info in a standard way, Can you define "capability" better, please? I don't follow what you want it for. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |The light at the end of the tunnel is a terawatt| |francis@ecal.com|laser cannon. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Jul 10 13:05:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09062 for ; Tue, 10 Jul 2001 13:05:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AGpaQ25911 for ietf-calendar-bks; Tue, 10 Jul 2001 09:51:36 -0700 (PDT) Received: from srvr3.ralden.com ([63.76.230.130]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AGpYm25904 for ; Tue, 10 Jul 2001 09:51:34 -0700 (PDT) Received: by SRVR3 with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 09:51:39 -0700 Message-ID: <8010EBF31AD5D01194A100C0F0163317521633@SRVR3> From: "Roland H. Alden" To: "'John Stracke'" , "David L. Nicol" Cc: cap-talk@mail.eros-os.org, ietf-calendar@imc.org, bobmah@mit.edu Subject: RE: Is there a capability RFC? Date: Tue, 10 Jul 2001 09:51:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Can you define "capability" better, please? I don't follow > what you want it for. Capabilities are one of the seminal building blocks of computer science, dating back to the Cambridge Ring and Multics, if not even earlier. A capability is a hard-to-forge/tamperproof "pointer like" "token" which provides the bearer with a certain set of rights ("capabilities") over a resource. Some pioneering hardware architectures, like the Symbolics Lisp Machine and Intel 432 actually gave memory pointers capability-like characteristics (like read or execute only) and made them tamperproof and unforgeable through hardware. The Cambridge Ring had a distributed file system addressed by capabilities that were tamper resistant through early cryptographic means (randomness). Capabilities can be interesting in certain security architectures because they combine an access path with implicit (bearer) permission, and since they offer indirection they can be revoked and expired. With today's cryptographic science it is relatively easy to implement secure capabilities in software and the application space of capabilities is certainly wide/varied and interesting. From owner-ietf-calendar@mail.imc.org Tue Jul 10 14:02:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12023 for ; Tue, 10 Jul 2001 14:02:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AHnj627866 for ietf-calendar-bks; Tue, 10 Jul 2001 10:49:45 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AHnim27862 for ; Tue, 10 Jul 2001 10:49:44 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6AHo1f04893; Tue, 10 Jul 2001 13:50:02 -0400 Message-ID: <3B4B4048.E458C6D1@ecal.com> Date: Tue, 10 Jul 2001 13:50:00 -0400 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "David L. Nicol" CC: cap-talk@mail.eros-os.org, ietf-calendar@imc.org Subject: Re: Is there a capability RFC? References: <3B4A6084.77FAE423@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "David L. Nicol" wrote: > and the bits about Security, which seem "tacked on," it occurs to me > that a Standard Capability Protocol (capabilities are 1024 bits long, > they include time-stamps and encooded origin info in a standard way, > etcetera) would be a very good thing, if it doesn't exist already, > and it would allow interoperability in much more interesting ways > that the complex mutual trust relationships that the state-of-the > art seems to require. (Thanks for explaining what capabilities are, Ronald. I have doubts that a generic capabilities protocol would work well first try; better to try using special-purpose versions in a few IETF protocols first, then build on that experience.) Could you expand on how capabilities would let us do away with mutual trust relationships? It seems to me that a capability actually encodes a mutual trust relationship. > For instance, the "ability to flood a calendar system with bogus > requests" could be greatly mitigated by use of capabilities in the > basic archtecture. How? You still need to examine each request to determine whether it's authenticated. > If every event is persistently tagged with the > capability under which it was posted, removing (and submitting for > re-moderation) all events posted under a compromised capability becomes > trivial. (a) How is this different from removing events posted by a particular user during a particular time range? (b) What about events posted by the legitimate user of the capability? > And there remains the big-picture problem of where are all the laid-off > personal secretaries supposed to do once it becomes possible to give > someone a capability code and have a reasonable expectation of > the recipient being able to leverage it into a meeting appointment > with no further human interaction? I'm not sure that this is a desirable goal. A meeting *is* human interaction; it necessarily involves investing humans' time. Better to invest a small amount of time deciding whether to go than to waste time going because you delegated your decision-making to a cryptographic token. Ultimately, there will always have to be a human-level intelligence deciding whether to accept a meeting invitation, because my calendar does not encode my entire life. I have no events scheduled on Saturday; that doesn't mean I'm willing to accept meeting invitations on Saturdays. I spend most of each work day on programming and so forth, which doesn't show up in my calendar; that doesn't mean that people are free to fill up my calendar with invitations. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Te audire no possum. Musa sapientum fixa est in| |francis@ecal.com|aure. | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Jul 10 15:03:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15117 for ; Tue, 10 Jul 2001 15:03:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AIoLk29832 for ietf-calendar-bks; Tue, 10 Jul 2001 11:50:21 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AIoJm29827 for ; Tue, 10 Jul 2001 11:50:20 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id NAA15434; Tue, 10 Jul 2001 13:49:18 -0500 From: "Shannon J. Clark" To: "George Babics" , Cc: , Subject: RE: [Fwd: New Version Of Guide To Calendaring] Date: Tue, 10 Jul 2001 13:49:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3B49D8CA.B1033DAC@steltor.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Small but amusing typo found Section 2.2, paragraph 3 (on iTIP), uses the word "assignation", which means an appointment between lovers. I think "assignment" was intended. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of George Babics Sent: Monday, July 09, 2001 11:16 AM To: ietf-calendar@imc.org Cc: alex@elea.dhs.org; bobmah@mit.edu Subject: [Fwd: New Version Of Guide To Calendaring] Here is the latest version of the guide. I have made changes based on the many comments I've received. The changes made include: - Use rfc 2629 to write the document in xml. This make generating the draft in the correct text format easy. Furthermore, it also allows one to generate an easy to read html document. - Made some clarifications to the analogies with e-mail. - Removed the iCalendar, iMIP, iTIP, and CAP examples. They were not very useful, made to doc much longer and invited syntax errors, which would have made the doc counterproductive. - Clarified many sections. - A few grammatical and spelling error fixes. - Removed a few redundant sections. We are making another last call. Thus, comments are encouraged. I will resubmit the draft, with changes, if needed, by the deadline for the next IETF. George From owner-ietf-calendar@mail.imc.org Tue Jul 10 17:22:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25164 for ; Tue, 10 Jul 2001 17:22:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AL1F905432 for ietf-calendar-bks; Tue, 10 Jul 2001 14:01:15 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AL1Dm05427 for ; Tue, 10 Jul 2001 14:01:13 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id QAA15590 for ; Tue, 10 Jul 2001 16:00:41 -0500 From: "Shannon J. Clark" To: Subject: SKiCal - draft - any new version? Date: Tue, 10 Jul 2001 16:01:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3B4B4048.E458C6D1@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I was looking at the SKiCal draft document recently and realized that it expired as of June 28th, 2001 - has a new version been prepared and submitted? Thanks, Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Tue Jul 10 19:35:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29783 for ; Tue, 10 Jul 2001 19:35:34 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6ANQNl08965 for ietf-calendar-bks; Tue, 10 Jul 2001 16:26:23 -0700 (PDT) Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ANQMm08961 for ; Tue, 10 Jul 2001 16:26:22 -0700 (PDT) Received: from caplet.caplet.com (sdn-ar-016carcorP331.dialsprint.net [63.180.67.109]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA20169; Tue, 10 Jul 2001 16:22:28 -0700 (PDT) Message-Id: <5.1.0.14.2.20010710161719.0457d7b0@shell9.ba.best.com> X-Sender: erights@shell9.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jul 2001 16:18:59 -0700 To: "David L. Nicol" From: "Mark S. Miller" Subject: Re: [Cap-Talk] Is there a capability RFC? Cc: cap-talk@mail.eros-os.org, ietf-calendar@imc.org, bobmah@mit.edu, Tyler Close Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Apologies to those who get this twice. I'm sending it again because of a problem at ietf-calendar@imc.org that should now be cleared up. I'm keeping the rest of you on the addressee list so that replies to this resent message will still go to the right places. --MarkM] At 06:55 PM Monday 7/9/01, David L. Nicol wrote: >[...] it occurs to me that a Standard Capability Protocol [...] The rest of you message shows that you're not thinking of a protocol, but rather a standard representation for distributed capabilities that can be carried or stored in conventional non-capability media. Let's call this an off-line capability representation. For off-line capabilities in support of off-line protocols, start with SPKI: * SPKI http://www.ietf.org/rfc/rfc2693.txt is approximately a capability system, as explained at http://www.erights.org/elib/capability/ode/ode-pki.html . It fall short of being a capability system in the ways explained at http://www.capcert.org/ , especially http://www.eros-os.org/pipermail/e-lang/2000-October/003886.html . HP's E-Speak system started as a capability system (actually, a "split capability" system, an interesting variant). But starting with E-Speak 3.0, they are using SPKI certificates as if there are capabilities. * If you're looking for a SPKI-like system, but not broken, keep your eye on http://www.capcert.org/ . But don't expect to see anything happen there for at least a year. For off-line capability representations in support of on-line capability protocols, there are two. * Take a look at E's "cap://..." URI string. E ( http://www.erights.org/ ) is already a very well functioning prototype or better, and should be ready for production use within a year. The corresponding on-line protocol it supports is Pluribus http://www.erights.org/elib/capability/ode/ode-protocol.html , http://www.erights.org/elib/distrib/vattp/index.html , and http://www.erights.org/elib/distrib/captp/index.html . * Waterken ( http://www.waterken.com/ ) has a very clever way to encode essentially the same information as E's "cap:.." URI into an "https:.." string, and then to layer their protocol on top of https. It looks solid to me, and all the critical parts are open sourced. Cheers, --MarkM From owner-ietf-calendar@mail.imc.org Tue Jul 10 21:51:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03985 for ; Tue, 10 Jul 2001 21:51:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6B1cqV12133 for ietf-calendar-bks; Tue, 10 Jul 2001 18:38:52 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6B1cnm12129 for ; Tue, 10 Jul 2001 18:38:50 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id UAA15881; Tue, 10 Jul 2001 20:38:11 -0500 From: "Shannon J. Clark" To: "Greg FitzPatrick" , Subject: RE: SKiCal - draft - any new version? Date: Tue, 10 Jul 2001 20:38:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C10980.510301E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <000d01c1099f$0108f9a0$d5e297d4@metaacer> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C10980.510301E0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id f6B1cqV12133 Content-Transfer-Encoding: quoted-printable Greg, Looks cleaner - like the fairly new HTML formatting of RFC - much easier = to navigate and read. In quickly skimming the new draft I was struck by one interesting point - while SKiCAL references RFC 2445 - iCalendar - it does not reference RFC 2446 or RFC 2447 (iTip and iMip) nor does it reference the CAP Draft document - is this deliberate? The reason I ask is I am looking at SKiCal in the light of the interrelat= ed nature of these standards - does SKiCal require changes to any of these standards? Suggest changes to any of them? Assume functionality/features from any of them? Off the top of my head I would figure that there may be a number of chang= es needed/suggested by SKiCal to some aspects of CAP - especially related to the vQuery proposal in that draft - SKiCAL extends significently the numb= er of fields that are designed for computer facilitated (even automated) querying) - just having the data structure is perhaps not enough without systems for easy access to the data in a useful and functional manner (or else all the information belongs in one large text block - if there aren'= t any means to sort, order, and query against the fields... Shannon -----Original Message----- From: Greg FitzPatrick [mailto:greg.fitzpatrick@metamatrix.se] Sent: Tuesday, July 10, 2001 7:17 PM To: 'Shannon J. Clark'; ietf-calendar@imc.org Subject: RE: SKiCal - draft - any new version? Shannon wrote: >I was looking at the SKiCal draft document recently and realized that = it >expired as of June 28th, 2001 - has a new version been prepared and >submitted? Thanks for the reminder Shannon. We have been so involved with the last-call version that we had forgotten the previous version had expired. Following the discussions on this list there are some changes in this version (which I am enclosing in HTML) =96 such as the renaming of LANGUE= and the compromise on SKIROLE. We did not go all the way with Bruce=92s suggestion for using 2445 ROLE, since we felt it broke iCal, but we did g= et rid of all the individual roles for each property (like THING-ROLE). Though we have a couple of days left before submission, it would be gre= at to even now get some reaction to the 1.. optimeset of property parameters. 2.. the choice of creating a new calendar component =93VOPTIMES=94 as opposed to trying to do DTOPEN within the VEVENT component. 3.. the NAMESPACE property and the NSREF property parameter Greg ------=_NextPart_000_0002_01C10980.510301E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greg,
 
Looks = cleaner - like=20 the fairly new HTML formatting of RFC - much easier to navigate and=20 read.
 
In = quickly skimming=20 the new draft I was struck by one interesting point - while SKiCAL = references=20 RFC 2445 - iCalendar - it does not reference RFC 2446 or RFC 2447 (iTip = and=20 iMip) nor does it reference the CAP Draft document - is this=20 deliberate?
 
The = reason I ask is=20 I am looking at SKiCal in the light of the interrelated nature of these=20 standards - does SKiCal require changes to any of these standards? = Suggest=20 changes to any of them? Assume functionality/features from any of=20 them?
 
Off = the top of my=20 head I would figure that there may be a number of changes = needed/suggested by=20 SKiCal to some aspects of CAP - especially related to the vQuery = proposal=20 in that draft - SKiCAL extends significently the number of fields that = are=20 designed for computer facilitated (even automated) querying) - just = having the=20 data structure is perhaps not enough without systems for easy access to = the data=20 in a useful and functional manner (or else all the information belongs = in one=20 large text block - if there aren't any means to sort, order, and query = against=20 the fields...
 
Shannon
-----Original Message-----
From: Greg FitzPatrick=20 [mailto:greg.fitzpatrick@metamatrix.se]
Sent: Tuesday, July = 10, 2001=20 7:17 PM
To: 'Shannon J. Clark';=20 ietf-calendar@imc.org
Subject: RE: SKiCal - draft - any new=20 version?

Shannon=20 wrote:

 

>I=20 was looking at the SKiCal draft document recently and realized that=20 it

>expired=20 as of June=20 28th, 2001=20 - has a new version been prepared and

>submitted?

 

Thanks=20 for the reminder Shannon.  = We have=20 been so involved with the last-call version that we had forgotten the = previous=20 version had expired.

 

Following=20 the discussions on this list there are some changes in this version = (which I=20 am enclosing in HTML) – such as the renaming of LANGUE and the = compromise on=20 SKIROLE.  We did not go = all the=20 way with Bruce’s suggestion for using 2445 ROLE, since we felt = it broke iCal,=20 but we did get rid of all the individual roles for each property (like = THING-ROLE).

 

Though=20 we have a couple of days left before submission, it would be great to = even now=20 get some reaction to the

 

  1. optimeset=20 of property parameters.=20
  2. the=20 choice of creating a new calendar component “VOPTIMES” = as opposed to trying=20 to do DTOPEN within the VEVENT component.=20
  3. the=20 NAMESPACE property and the NSREF property = parameter=20

 

Greg=20  

 

 

 

 

------=_NextPart_000_0002_01C10980.510301E0-- From owner-ietf-calendar@mail.imc.org Wed Jul 11 11:01:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06416 for ; Wed, 11 Jul 2001 11:01:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BElOB20112 for ietf-calendar-bks; Wed, 11 Jul 2001 07:47:24 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BElNm20108 for ; Wed, 11 Jul 2001 07:47:23 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6BEnLl07433; Wed, 11 Jul 2001 10:49:21 -0400 Message-ID: <3B4C6770.C93D14E7@ecal.com> Date: Wed, 11 Jul 2001 10:49:21 -0400 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: calsch WG CC: cap-talk@eros-os.org Subject: Re: Is there a capability RFC? References: <3B4A6084.77FAE423@kasey.umkc.edu> <3B4B2763.2C616214@ecal.com> <3B4B7C43.BBAE309D@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "David L. Nicol" wrote, on a separate list but CC:ed to me: > John Stracke wrote: > > > > "David L. Nicol" wrote: > > > > > it occurs to me > > > that a Standard Capability Protocol (capabilities are 1024 bits long, > > > they include time-stamps and encooded origin info in a standard way, > > > > Can you define "capability" better, please? I don't follow what you want it > > for. > > "capability" is a robust method for delegating (and rescinding, and > tracking) > authority or all kinds. > > Not Authenticity, but Authority. > > X session cookies are a good example. Another is the random codes that > prevent > fake mailing list subscriptions. CGI session cookies too -- they are > random > strings of characters that give one the capability to use a particular > shopping > cart object. > > If iCal (or MIME, for that matter) had a standard CAPABILIT[Y|IES]: header > built > into it, I, as an operator of a calendar, could ask my calendar for some > posting > capabilities which would expire at the end of the year, and distribute > these > capabilities (they would look like PGP signatures -- you know, binary > garbage) > to the people who are authorized to list events on the calendar, and they > would > use capability-aware tools to submit the items to the calendar, which would > include the capability, associated with the event they are sending in, and > the > calendar would check the capability, and if it is good, go ahead and list > the event, and if it is not, the calendar would pass it on for moderating. > > I believe this is desired functionality which is not currently addressed by > the standard, in fact it is explicitly delegated to the implementors. And for good reason: the IETF generally avoids trying to do things that don't have wide experience yet; it makes for working groups that trail off into death spirals. Implementers of the various iCalendar protocols can experiment with capabilities on their own; if they turn out to be useful, then they can be standardized. > Capabilities could become a framework for authorization interoperability. > > I am not suggesting that any of the flexiblity in designing arbitrarily > complex authorization systems be taken from the implementors; I am merely > suggesting that specifying a place for such information to go, if it is > used in an implementation, would ease interoperability. > > Since a general purpose authority delegation scheme is larger than > calendaring > (standardizing VERPs comes to mind as another possibility -- a VAriable > Envelope > Return Path could be considered as a Capability that allows a MTA, > "exercising > it" by bouncing a mail to the address, to unambiguously report a problem > with > a particular address) I think an RFC on incorporating them into MIME, which > would then get inherited by all projects that rely on MIME, would be a > better > solution than including them in the iCalendar project. > > Including them in the iCalendar project, and expecting them to get > back-ported > into MIME, makes sense too. > > -- > David Nicol 816.235.1187 > "Perl was born in downtown Hell!" -- Matt Youell -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |We want forty million helicopters and a dollar!| |francis@ecal.com|--"Dinosaurs" | \================================================================/ From owner-ietf-calendar@mail.imc.org Wed Jul 11 12:34:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10300 for ; Wed, 11 Jul 2001 12:34:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BGMuT27796 for ietf-calendar-bks; Wed, 11 Jul 2001 09:22:56 -0700 (PDT) Received: from smtp2.mail.iamworld.net (smtp2-out.mail.iamworld.net [204.91.241.117]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BGMtm27791 for ; Wed, 11 Jul 2001 09:22:55 -0700 (PDT) Received: from cp158611-a (cp158611-a.alngtn1.va.home.com [65.14.217.249]) by smtp2.mail.iamworld.net (8.9.3/8.9.3) with SMTP id MAA2178436 for ; Wed, 11 Jul 2001 12:22:57 -0400 (EDT) Message-Id: <200107111622.MAA2178436@smtp2.mail.iamworld.net> X-Sender: 10003479@pop.iamdigex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 11 Jul 2001 12:33:05 -0400 To: calsch WG From: Al Gilman Subject: Re: [Cap-Talk] Re: Is there a capability RFC? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id f6BGMuT27796 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10300 [Copy for info. Re-sent because of antiSpam provisions on ietf-calendar. Has been sent earlier to John Stracke , cap-talk@eros-os.org. Primarily addressed to the last group. If you wish to comment on these ideas you may wish to include them in your distribution. -Al] It is possible that capability advocates will find a more receptive audience in the Global Grid Forum Security Working Group. http://www.gridforum.org As I have indicated earlier, here is a community that knows it has a problem of restricted delegation, which I have at least once suggested to them should be viewed as a matter of communicable categorized authorization.  Smells something like a capability? The excuse for the fact that the Grid Forum isn't just an anonymous cluster of IETF Working Groups is to achieve focus on some domains of metacomputing and create a climate that is a notch more open to risk taking and innovation, while still targeting universal standardization as the end state of practice.  One view is that it can serve as a lab in which to prepare technologies for IETF consideration.  So consider it as an alternative to either MIME or CalSch as your stepping stone and you may discover a path to daylight. No guarantees.  I am a lurker there as here.  But from afar, it looks like a possible fit. Al At 10:49 AM 2001-07-11 , John Stracke wrote: >"David L. Nicol" wrote, on a separate list but CC:ed to me: > >> John Stracke wrote: >> > >> > "David L. Nicol" wrote: >> > >> > > it occurs to me >> > > that a Standard Capability Protocol (capabilities are 1024 bits long, >> > > they include time-stamps and encooded origin info in a standard way, >> > >> > Can you define "capability" better, please? I don't follow what you want it >> > for. >> >> "capability" is a robust method for delegating (and rescinding, and >> tracking) >> authority or all kinds. >> >> Not Authenticity, but Authority. >> >> X session cookies are a good example.  Another is the random codes that >> prevent >> fake mailing list subscriptions.  CGI session cookies too -- they are >> random >> strings of characters that give one the capability to use a particular >> shopping >> cart object. >> >> If iCal (or MIME, for that matter) had a standard CAPABILIT[Y|IES]: header >> built >> into it, I, as an operator of a calendar, could ask my calendar for some >> posting >> capabilities which would expire at the end of the year, and distribute >> these >> capabilities (they would look like PGP signatures -- you know, binary >> garbage) >> to the people who are authorized to list events on the calendar, and they >> would >> use capability-aware tools to submit the items to the calendar, which would >> include the capability, associated with the event they are sending in, and >> the >> calendar would check the capability, and if it is good, go ahead and list >> the event, and if it is not, the calendar would pass it on for moderating. >> >> I believe this is desired functionality which is not currently addressed by >> the standard, in fact it is explicitly delegated to the implementors. > >And for good reason: the IETF generally avoids trying to do things that don't >have wide experience yet; it makes for working groups that trail off into death >spirals. > >Implementers of the various iCalendar protocols can experiment with capabilities >on their own; if they turn out to be useful, then they can be standardized. > >> Capabilities could become a framework for authorization interoperability. >> >> I am not suggesting that any of the flexiblity in designing arbitrarily >> complex authorization systems be taken from the implementors; I am merely >> suggesting that specifying a place for such information to go, if it is >> used in an implementation, would ease interoperability. >> >> Since a general purpose authority delegation scheme is larger than >> calendaring >> (standardizing VERPs comes to mind as another possibility -- a VAriable >> Envelope >> Return Path could be considered as a Capability that allows a MTA, >> "exercising >> it" by bouncing a mail to the address, to unambiguously report a problem >> with >> a particular address) I think an RFC on incorporating them into MIME, which >> would then get inherited by all projects that rely on MIME, would be a >> better >> solution than including them in the iCalendar project. >> >> Including them in the iCalendar project, and expecting them to get >> back-ported >> into MIME, makes sense too. >> >> -- >>                                            David Nicol 816.235.1187 >>                    "Perl was born in downtown Hell!" -- Matt Youell > >-- >/================================================================\ >|John Stracke    | http://www.ecal.com |My opinions are my own.  | >|Chief Scientist |===============================================| >|eCal Corp.      |We want forty million helicopters and a dollar!| >|francis@ecal.com|--"Dinosaurs"                                  | >\================================================================/ > > > >_______________________________________________ >cap-talk mailing list >cap-talk@mail.eros-os.org >http://www.eros-os.org/m ailman/listinfo/cap-talk > From owner-ietf-calendar@mail.imc.org Wed Jul 11 12:42:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10653 for ; Wed, 11 Jul 2001 12:42:06 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6BGUpp28032 for ietf-calendar-bks; Wed, 11 Jul 2001 09:30:51 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6BGUom28027 for ; Wed, 11 Jul 2001 09:30:50 -0700 (PDT) Received: (qmail 188911 invoked from network); 11 Jul 2001 16:27:04 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 11 Jul 2001 16:27:04 -0000 Message-ID: <3B4C7D8C.84F293A@kasey.umkc.edu> Date: Wed, 11 Jul 2001 11:23:40 -0500 From: "David L. Nicol" Organization: University of Missouri - Kansas City supercomputing infrastructure X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: cap-talk@mail.eros-os.org, ietf-calendar@imc.org Subject: Re: Is there a capability RFC? References: <3B4A6084.77FAE423@kasey.umkc.edu> <3B4B4048.E458C6D1@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > Could you expand on how capabilities would let us do away with mutual trust > relationships? It seems to me that a capability actually encodes a mutual > trust relationship. The overview draft defers encoding of trust relationships to the implementations. Providing a standard encoding method for them would increase interoperability. "To post to the calendar, use the attached key" could be given, without verifying that the CUA that will be used uses the same vendor-extended key protocol. > > For instance, the "ability to flood a calendar system with bogus > > requests" could be greatly mitigated by use of capabilities in the > > basic archtecture. > > How? You still need to examine each request to determine whether it's > authenticated. a capability could, for instance, be associated with an upper limit of number of posts can be made with it. This can be done with user accounts as well, certainly, and the complexity is about equal, and associating a capability with a user account would be a reasonable way to implement the limit. > > If every event is persistently tagged with the > > capability under which it was posted, removing (and submitting for > > re-moderation) all events posted under a compromised capability becomes > > trivial. > > (a) How is this different from removing events posted by a particular user > during a particular time range? "By a particular user" is more vague, as it doesn't address how we know it was them. > (b) What about events posted by the legitimate user of the capability? "... and submitting for re-moderation" Anyway, what about entities that are not individual people? Wedging them into "user accounts" is standard practice, yes, but that doesn't make it elegant. From owner-ietf-calendar@mail.imc.org Wed Jul 11 13:14:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11962 for ; Wed, 11 Jul 2001 13:14:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BH58V29125 for ietf-calendar-bks; Wed, 11 Jul 2001 10:05:08 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BH57m29121 for ; Wed, 11 Jul 2001 10:05:07 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6BH4ui00963 for ; Wed, 11 Jul 2001 12:05:09 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 11 Jul 2001 12:04:40 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 11 Jul 2001 12:04:40 -0500 Message-ID: <30F2DED23724D311902D0008C7EABAFB03F34E00@daeis06nok> From: Frank.Dawson@nokia.com To: david@kasey.umkc.edu Cc: ietf-calendar@imc.org Subject: RE: Is there a capability RFC? Date: Wed, 11 Jul 2001 12:04:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David: The semantics that you are referring to as AUTHORITY has other meanings and is implemented differently in many of the calendaring and scheduling systems. For example, it can be implemented as a DELEGATION OF OWNERSHIP for the calendar. I delegate ownership for viewing my calendar, scheduling /responding to/rescheduling/cancelling events and tasks, as well other capabilities to my administrative assistant. This I do, not in a particular transfer of a scheduling method but out-of-band within the calendaring system. You have thought of another method for providing some subset of these capabilities, but with a different paradigm for action. There is no current accepted-practice for this, as such as John indicated, there is no common basis for standardization. Of course, this wouldn't stop the IETF from specifying a standard method for some of these capabilities ;-) -- Frank From owner-ietf-calendar@mail.imc.org Wed Jul 11 13:55:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13509 for ; Wed, 11 Jul 2001 13:55:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BHjpY00613 for ietf-calendar-bks; Wed, 11 Jul 2001 10:45:51 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BHjom00609 for ; Wed, 11 Jul 2001 10:45:50 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6BHjxl08183; Wed, 11 Jul 2001 13:45:59 -0400 Message-ID: <3B4C90D7.1B060EF2@ecal.com> Date: Wed, 11 Jul 2001 13:45:59 -0400 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "David L. Nicol" CC: cap-talk@mail.eros-os.org, ietf-calendar@imc.org Subject: Re: Is there a capability RFC? References: <3B4A6084.77FAE423@kasey.umkc.edu> <3B4B4048.E458C6D1@ecal.com> <3B4C7D8C.84F293A@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "David L. Nicol" wrote: > > > For instance, the "ability to flood a calendar system with bogus > > > requests" could be greatly mitigated by use of capabilities in the > > > basic archtecture. > > > > How? You still need to examine each request to determine whether it's > > authenticated. > > a capability could, for instance, be associated with an upper limit > of number of posts can be made with it. Then you still need to do a database lookup to decide whether that limit's been reached. There is simply no way for an access control mechanism to prevent DoS attacks, because an effective attack can be mounted just by making lots of bogus requests, to force the access control system to come into play. A more sophisticated access control system may actually be a liability, if it requires more computrons to evaluate each request. > > (b) What about events posted by the legitimate user of the capability? > > "... and submitting for re-moderation" Uh...that's not trivial. Technically simple, yes; but it requires vast amounts of time from the legitimate user. > Anyway, what about entities that are not individual people? Wedging > them into "user accounts" is standard practice, yes, but that doesn't > make it elegant. Elegant? You want elegant? Have you *looked* at the syntax of iCalendar? :-) Or MIME, or LDAP? These things are not elegant at all; that's not the design goal. But they work, where some more elegant proposals have died away. If you want the IETF to spend time on capabilities, elegance won't be enough of a reason. In any case, I don't think this WG can afford to take on more work right now. Maybe in another year. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Help stamp out vi in our lifetime! | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jul 11 14:11:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14104 for ; Wed, 11 Jul 2001 14:11:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BHsAw00880 for ietf-calendar-bks; Wed, 11 Jul 2001 10:54:10 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6BHs9m00876 for ; Wed, 11 Jul 2001 10:54:09 -0700 (PDT) Received: (qmail 190683 invoked from network); 11 Jul 2001 17:50:24 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 11 Jul 2001 17:50:24 -0000 Message-ID: <3B4C9114.24125579@kasey.umkc.edu> Date: Wed, 11 Jul 2001 12:47:00 -0500 From: "David L. Nicol" Organization: University of Missouri - Kansas City supercomputing infrastructure X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: Is there a capability RFC? References: <3B4A6084.77FAE423@kasey.umkc.edu> <3B4B2763.2C616214@ecal.com> <3B4B7C43.BBAE309D@kasey.umkc.edu> <3B4C6770.C93D14E7@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > the IETF generally avoids trying to do things that don't > have wide experience yet; it makes for working groups that trail off into death > spirals. Wide experience: SPKI "CERTIFICATES" X MIT-MAGIC-COOKIE HTTP-COOKIE to list just three, which are in use. > Implementers of the various iCalendar protocols can experiment with capabilities > on their own; if they turn out to be useful, then they can be standardized. I am not suggesting standardizing the full range of what they might be used for, simply requesting that the standard include a place to put them if an implementation includes them. Otherwise, interoperabilty is difficult, in light of the no-extensions-allowed-in-releases nature of the standard. I'm also repeating myself to a fault, so I'll stop now. From owner-ietf-calendar@mail.imc.org Wed Jul 11 14:44:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15517 for ; Wed, 11 Jul 2001 14:44:22 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6BIYNG02316 for ietf-calendar-bks; Wed, 11 Jul 2001 11:34:23 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6BIYMm02312 for ; Wed, 11 Jul 2001 11:34:22 -0700 (PDT) Received: (qmail 191512 invoked from network); 11 Jul 2001 18:30:37 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 11 Jul 2001 18:30:37 -0000 Message-ID: <3B4C9A81.D1A01453@kasey.umkc.edu> Date: Wed, 11 Jul 2001 13:27:13 -0500 From: "David L. Nicol" Organization: University of Missouri - Kansas City supercomputing infrastructure X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke , ietf-calendar@imc.org Subject: Re: Is there a capability RFC? References: <3B4A6084.77FAE423@kasey.umkc.edu> <3B4B4048.E458C6D1@ecal.com> <3B4C7D8C.84F293A@kasey.umkc.edu> <3B4C90D7.1B060EF2@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > "David L. Nicol" wrote: > > > (b) What about events posted by the legitimate user of the capability? > > > > "... and submitting for re-moderation" > > Uh...that's not trivial. Technically simple, yes; but it requires vast amounts > of time from the legitimate user. Right. This problem is still there with tradional authenticion implying authority, and it is worse, because it is not fine-grained. If I want to let Jeff post to my calendar and I loan him my calendar password, maybe that password does other things too. If I can have my calendar create a one-time-use certificate, I can give that away and I don't have to change my password or worry. > > a capability could, for instance, be associated with an upper limit > > of number of posts can be made with it. > > Then you still need to do a database lookup to decide whether that limit's been > reached. > > There is simply no way for an access control mechanism to prevent DoS attacks, > because an effective attack can be mounted just by making lots of bogus > requests, to force the access control system to come into play. A more > sophisticated access control system may actually be a liability, if it requires > more computrons to evaluate each request. Now you're just being difficult. As a DoS perpetrator, I am sure there are more resource-intensive things I can do to your box than forge a gazillion bogus CUA requests. For instance, forge a gazillion SMTP requests. > > Anyway, what about entities that are not individual people? Wedging > > them into "user accounts" is standard practice, yes, but that doesn't > > make it elegant. > > Elegant? You want elegant? Have you *looked* at the syntax of iCalendar? :-) Or > MIME, or LDAP? These things are not elegant at all; that's not the design goal. > But they work, where some more elegant proposals have died away. If you want > the IETF to spend time on capabilities, elegance won't be enough of a reason. > > In any case, I don't think this WG can afford to take on more work right now. > Maybe in another year. Fair enough. When I have a working calendar with a full-blown delegation system, I'll tell you about it. -- David Nicol 816.235.1187 "Perl was born in downtown Hell!" -- Matt Youell From owner-ietf-calendar@mail.imc.org Wed Jul 11 15:24:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16965 for ; Wed, 11 Jul 2001 15:24:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BIrNT03087 for ietf-calendar-bks; Wed, 11 Jul 2001 11:53:23 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BIrLm03083 for ; Wed, 11 Jul 2001 11:53:21 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6BIsFl08476; Wed, 11 Jul 2001 14:54:15 -0400 Message-ID: <3B4CA0D5.E665EAAC@ecal.com> Date: Wed, 11 Jul 2001 14:54:13 -0400 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "David L. Nicol" CC: ietf-calendar@imc.org Subject: Re: Is there a capability RFC? References: <3B4A6084.77FAE423@kasey.umkc.edu> <3B4B4048.E458C6D1@ecal.com> <3B4C7D8C.84F293A@kasey.umkc.edu> <3B4C90D7.1B060EF2@ecal.com> <3B4C9A81.D1A01453@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "David L. Nicol" wrote: > Right. This problem is still there with tradional authenticion implying > authority, True. > and it is worse, because it is not fine-grained. See below. > If I want to let Jeff post to my calendar and I loan him my calendar > password, > maybe that password does other things too. Existing calendar systems handle this by supporting proxy users, or access control lists. Rather than give Jeff your calendar password, you tell the system that he has certain rights on your calendar, and then he logs in as himself. Then, if Jeff abuses his privileges, it's known which events came from him, just as well as with capabilities. > > There is simply no way for an access control mechanism to prevent DoS attacks, > > Now you're just being difficult. Not at all. You claimed that capabilities solved the DoS problem; I'm just showing that that's not possible. > As a DoS perpetrator, I am sure there > are more resource-intensive things I can do to your box than forge a > gazillion > bogus CUA requests. For instance, forge a gazillion SMTP requests. That's if my CS box is running an SMTP server, and permits access to it. For large installations, this is unlikely; servers are likely to be single-function, for effiency and ease of administration. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"You're nothing but a pack of ringleaders!" | |francis@ecal.com|--_Wyrd Sisters_, Terry Pratchett | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jul 11 16:30:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19231 for ; Wed, 11 Jul 2001 16:30:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BKIu706014 for ietf-calendar-bks; Wed, 11 Jul 2001 13:18:56 -0700 (PDT) Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BKItm06010 for ; Wed, 11 Jul 2001 13:18:55 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-d10.mx.aol.com (mail_out_v30.22.) id 7.3.1a83ace (16245) for ; Wed, 11 Jul 2001 16:18:41 -0400 (EDT) Received: from netscape.com (aimmail01.aim.aol.com [205.188.144.193]) by air-in03.mx.aol.com (v78_r3.8) with ESMTP; Wed, 11 Jul 2001 16:18:41 -0400 Date: Wed, 11 Jul 2001 16:18:41 -0400 From: rogerdox14@netscape.net (Roger D) To: ietf-calendar@imc.org Subject: ABNF for Section 4.2.19 Mime-Version: 1.0 Message-ID: <3C0C78B4.00EEF9C5.10749803@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is the CRLF in the ABNF of section 4.2.19 of RFC 4556 a typo? On the face of it, it seems to be specifying an extra blank line. I note it's still there in the Jun 4th draft for the revised iCal RFC. --Roger __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From owner-ietf-calendar@mail.imc.org Wed Jul 11 21:01:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26283 for ; Wed, 11 Jul 2001 21:01:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6C0ovD12871 for ietf-calendar-bks; Wed, 11 Jul 2001 17:50:57 -0700 (PDT) Received: from beast.uwillsee.com (h223239.ppp.asahi-net.or.jp [61.114.223.239]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C0osm12867 for ; Wed, 11 Jul 2001 17:50:55 -0700 (PDT) Received: from tom by beast.uwillsee.com with local (Exim 3.22 #1) id 15KUdS-0007GC-00 for ietf-calendar@imc.org; Thu, 12 Jul 2001 09:47:18 +0900 Date: Thu, 12 Jul 2001 09:47:18 +0900 From: "Thomas O'Dowd" To: ietf-calendar@imc.org Subject: RFC2445 comments on section 4.3.10 Message-ID: <20010712094718.N1168@beast.uwillsee.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I'd been reading section 4.3.10 "Recurrance Rule" and I've some questions on the meanings of BYSETPOS and also on some of the proposed revisions which I found at the following url. http://softwarestudio.org/iCal/ProposedChanges.txt I. BYSETPOS I wasn't aware of this mail lists existance until today but was thinking a lot about the proper usage of BYSETPOS over the past week. I came to the following conclusions. BYSETPOS only makes sense (to me at least) if it only applies to ByRules of a date nature and those which expand the event set. This is because BYSETPOS is limited to values between 1..366 and -366..-1 and therefore cannot access sub-day events in the case of something like the following rule... RRULE:FREQ=YEARLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;BYHOUR=8,9,10;BYSETPOS=-1 I see two ways, to deal with this rule given the BYSETPOS range. a) evaluate BYSETPOS before time rules meaning that the rule will be evaluated as 3 events, Dec 31st at 8, 9 and 10am, every year. b) Disallow, BYSETPOS where a time ByRule is given. Personally I think that a) makes sense and it is the way that I've implemented it. How are other people doing it? In summary I think that the RFC could be clearer around the BYSETPOS defination. I would think the following should apply. 1) The paragraph about multiple BYxxx rules should be changed to specify an order which makes a) above happen. ie. move BYSETPOS from after BYSECOND to before BYHOUR. BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYSETPOS, BYHOUR, BYMINUTE and BYSECOND ; then COUNT and UNTIL are evaluated. 2) BYSETPOS makes no sense (if time ByRules are disallowed) if FREQ=DAILY as the max events per set is 1 at the time BYSETPOS is evaluated. 3) BYSETPOS be disallowed for time frequencies ie, HOURLY, MINUTELY, and SECONDLY. I'm looking forward to hearing other peoples thoughts on the above. I'd also like to comment on some of the proposed changes to this sections that I found at the url I mentioned above. Namely the following: A rule may not not have a BYxxx rule part that conflicts with the recurrence interval. A SECONDLY recurrence may not have both a BYSECOND >rule part and an INTERVAL that is greater than 1 An HOURLY recurrence may not have both a BYHOUR rule part and an INTERVAL that is greater than 1 A MINUTELY recurrence may not have both a BYMINUTE rule part and an INTERVAL that is greater than 1 A WEEKLY recurrence may not have both a BYWEEKNO rule part and an INTERVAL that is greater than 1 A MONTHLY recurrence may not have both a BYMONTH rule part and an INTERVAL that is greater than 1 While these rules elimate the possibility of there being no valid events where the interval causes the rule never to hit a match on a byrule limitation, I think this should be handled by the software itself so that valid rules like the following should be allowed to be expressed. DSTART:20000110T200000Z RRULE:FREQ=HOURLY;UNTIL=20000125T080000Z;INTERVAL=5;BYHOUR=8,11 Mon Jan 10 20:00:00 2000 Thu Jan 13 11:00:00 2000 Sat Jan 15 08:00:00 2000 Tue Jan 18 11:00:00 2000 Thu Jan 20 08:00:00 2000 Sun Jan 23 11:00:00 2000 Tue Jan 25 08:00:00 2000 Which is what I have also implemented from my reading of the RFC. Sure it prevents ugly rules like DSTART:20000110T200000Z RRULE:FREQ=HOURLY;INTERVAL=2;BYHOUR=11 But I don't see why the RFC should restrict that just like it doesn't restrict setting something like. RRULE:FREQ=YEARLY;BYMONTH=2;BYMONTHDAY=30 ie. the implementing software can find it pretty easily and you don't block potentially useful rules in the process. Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com tom@nooper.com - Testing - http://nooper.co.jp/labs From owner-ietf-calendar@mail.imc.org Wed Jul 11 21:24:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26610 for ; Wed, 11 Jul 2001 21:24:21 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6C1E9W13515 for ietf-calendar-bks; Wed, 11 Jul 2001 18:14:09 -0700 (PDT) Received: from imo-m08.mx.aol.com (imo-m08.mx.aol.com [64.12.136.163]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C1E7m13511 for ; Wed, 11 Jul 2001 18:14:07 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-m08.mx.aol.com (mail_out_v30.22.) id 7.2c.1a2b57f (16225) for ; Wed, 11 Jul 2001 21:14:02 -0400 (EDT) Received: from netscape.net (host-192-125-18-192.iplanet.com [192.18.125.192]) by air-in02.mx.aol.com (v78_r3.8) with ESMTP; Wed, 11 Jul 2001 21:14:02 2000 Message-ID: <3B4CF9AE.40405@netscape.net> Date: Wed, 11 Jul 2001 18:13:18 -0700 From: Roger D User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010530 Netscape6/6.5b0 X-Accept-Language: en-GB,en,en-US MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Section 4.8.1.5 contradicts Section 4.6.3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 4.8.1.5 it states: Property Name: DESCRIPTION ... Conformance: The property can be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar components. The property can be specified multiple times only within a "VJOURNAL" calendar component. This allows multiple DESCRIPTION properties on a VJOURNAL. Yet in section 4.6.3 the ABNF reads: Formal Definition: A "VJOURNAL" calendar component is defined by the following notation: journalc = "BEGIN" ":" "VJOURNAL" CRLF jourprop "END" ":" "VJOURNAL" CRLF jourprop = *( ; the following are optional, ; but MUST NOT occur more than once class / created / description / dtstart / dtstamp / last-mod / organizer / recurid / seq / status / summary / uid / url / which states that the description property MUST NOT occur more than once in VJOURNAL. Which of these is correct? This contradiction still exists in the Jun 4th draft. Something that sounds like it could be this issue is listed in the issues attached to the Jun 4th draft, but the link to the message where it is discussed is broken. --Roger From owner-ietf-calendar@mail.imc.org Wed Jul 11 21:26:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26628 for ; Wed, 11 Jul 2001 21:26:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6C1Ej013527 for ietf-calendar-bks; Wed, 11 Jul 2001 18:14:45 -0700 (PDT) Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C1Ehm13523 for ; Wed, 11 Jul 2001 18:14:44 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-d06.mx.aol.com (mail_out_v30.22.) id 7.b3.7c0446 (16229) for ; Wed, 11 Jul 2001 21:14:35 -0400 (EDT) Received: from netscape.net (host-192-125-18-192.iplanet.com [192.18.125.192]) by air-in02.mx.aol.com (v78_r3.8) with ESMTP; Wed, 11 Jul 2001 21:14:35 -0400 Message-ID: <3B4CF9CF.6030902@netscape.net> Date: Wed, 11 Jul 2001 18:13:51 -0700 From: Roger D User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010530 Netscape6/6.5b0 X-Accept-Language: en-GB,en,en-US MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: ABNF for Section 4.3.10 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In the ABNF of section 4.2.19 of RFC 4556 I suspect the lines: weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, ;FRIDAY, SATURDAY and SUNDAY days of the week. should actually read: weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, ;FRIDAY, and SATURDAY days of the week. This is still in the Jun 4th draft. --Roger From owner-ietf-calendar@mail.imc.org Wed Jul 11 21:27:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26639 for ; Wed, 11 Jul 2001 21:27:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6C1F4213547 for ietf-calendar-bks; Wed, 11 Jul 2001 18:15:04 -0700 (PDT) Received: from imo-m07.mx.aol.com (imo-m07.mx.aol.com [64.12.136.162]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C1F3m13542 for ; Wed, 11 Jul 2001 18:15:03 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-m07.mx.aol.com (mail_out_v30.22.) id 7.b1.7c7402 (16227) for ; Wed, 11 Jul 2001 21:14:55 -0400 (EDT) Received: from netscape.net (host-192-125-18-192.iplanet.com [192.18.125.192]) by air-in02.mx.aol.com (v78_r3.8) with ESMTP; Wed, 11 Jul 2001 21:14:55 -0400 Message-ID: <3B4CF9E2.4020401@netscape.net> Date: Wed, 11 Jul 2001 18:14:10 -0700 From: Roger D User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010530 Netscape6/6.5b0 X-Accept-Language: en-GB,en,en-US MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: No example in Section 4.2.20 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I notice that of all the 4.2.x sections in iCal, only 4.2.20 lacks an example. This is still true in the Jun 4th draft for the revised iCal RFC. --Roger From owner-ietf-calendar@mail.imc.org Thu Jul 12 03:13:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06954 for ; Thu, 12 Jul 2001 03:13:34 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6C6uI500720 for ietf-calendar-bks; Wed, 11 Jul 2001 23:56:18 -0700 (PDT) Received: from beast.uwillsee.com (h221068.ppp.asahi-net.or.jp [61.114.221.68]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C6uGm00710 for ; Wed, 11 Jul 2001 23:56:16 -0700 (PDT) Received: from tom by beast.uwillsee.com with local (Exim 3.22 #1) id 15KaKl-0007Tp-00 for ietf-calendar@imc.org; Thu, 12 Jul 2001 15:52:23 +0900 Date: Thu, 12 Jul 2001 15:52:23 +0900 From: "Thomas O'Dowd" To: ietf-calendar@imc.org Subject: Further thoughts on BYSETPOS Message-ID: <20010712155223.A1168@beast.uwillsee.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I'd like to comment further on my earlier posting and BYSETPOS. I'd still like comments on my earlier posting as this posting is just adding to earlier issues. After thinking about BYSETPOS a little more with regards to weekly freqencies, and after a little confusion initially, here are some thoughts for you all. First lets look at a simple weekly rule. RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU This means every week on Wed, Fri and Sun there is an event. Lets add BYSETPOS to the rule. RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU;BYSETPOS=1 Here it seems is another example of where the value of WKST comes into play. The default is MO, so this rule will evaluate to every Wed in the year. If I use WKST=SU, this changes however as below. RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU;WKST=SU;BYSETPOS=1 The rule this time evaluates to every Sunday in the year. I'm not sure if BYSETPOS is really useful when used with WEEKLY like this as a week is more of a fixed time unless a constricting rule applies. The only byRule that might constrict a WEEKLY frequency somehow would be BYWEEKNO which won't effect the valuation of things as per above. If BYMONTHDAY was allowed in a WEEKLY rule though it might change the value of what BYSETPOS evaluated to, week by week. The proposals are for BYMONTHDAY to not be allowed with a weekly rule frequency though as per the following text. For WEEKLY recurrences (FREQ=WEEKLY) neither BYMONTHDAY nor BYYEARDAY may appear. So how useful is BYSETPOS for a weekly rule? I'm not sure that it is useful in my current understanding. It is very useful though where the rule is MONTHLY and probably YEARLY although I've yet to really think about YEARLY rules and BYSETPOS. Cheers, Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com tom@nooper.com - Testing - http://nooper.co.jp/labs From owner-ietf-calendar@mail.imc.org Thu Jul 12 13:11:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21331 for ; Thu, 12 Jul 2001 13:11:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CGvWZ02099 for ietf-calendar-bks; Thu, 12 Jul 2001 09:57:32 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CGvVm02094 for ; Thu, 12 Jul 2001 09:57:31 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA21967; Thu, 12 Jul 2001 12:57:00 -0400 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f6CGuev27728; Thu, 12 Jul 2001 12:56:50 -0400 (EDT) Message-ID: <0c3001c10af3$6a4ebbc0$092e0165@in.steltor.com> From: "Graham Gilmore" To: , "Eric Busboom" References: <3C0C78B4.00EEF9C5.10749803@netscape.net> Subject: Re: ABNF for Section 4.2.19 Date: Thu, 12 Jul 2001 12:54:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Is the CRLF in the ABNF of section 4.2.19 of [RFC 2445] a typo? On the > face of it, it seems to be specifying an extra blank line. I note it's > still there in the Jun 4th draft for the revised iCal RFC. > > --Roger Definitely looks like a mistake. In any of the examples including date-time with a TZID parameter, you'll see that none of them insert a CRLF after the parameter value. Graham From owner-ietf-calendar@mail.imc.org Fri Jul 13 16:24:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05148 for ; Fri, 13 Jul 2001 16:24:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6DK4fC02668 for ietf-calendar-bks; Fri, 13 Jul 2001 13:04:41 -0700 (PDT) Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DK4dq02664 for ; Fri, 13 Jul 2001 13:04:39 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-m03.mx.aol.com (mail_out_v31.7.) id 7.b1.7e34e6 (16218) for ; Fri, 13 Jul 2001 16:04:34 -0400 (EDT) Received: from netscape.com (aimmail02.aim.aol.com [205.188.144.194]) by air-in01.mail.aol.com (v79.27) with ESMTP id MAILININ16-0713160434; Fri, 13 Jul 2001 16:04:34 -0400 Date: Fri, 13 Jul 2001 16:04:34 -0400 From: rogerdox14@netscape.net (Roger D) To: ietf-calendar@imc.org Subject: Examples in Section 4.2.10 (LANGUAGE parameter) Mime-Version: 1.0 Message-ID: <44EDFAE3.39C72E91.10749803@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Section 4.2.10 on the LANGUAGE parameter currently contains: Example: SUMMARY;LANGUAGE=us-EN:Company Holiday Party LOCATION;LANGUAGE=en:Germany LOCATION;LANGUAGE=no:Tyskland The following example makes use of the Quoted-Printable encoding in order to represent non-ASCII characters. LOCATION;LANGUAGE=da:K=F8benhavn LOCATION;LANGUAGE=en:Copenhagen The SUMMARY example is fine. The LOCATION examples are illegal: the ABNF in sections 4.6.1 and 4.6.2 clearly state that neither as VEVENT not a VTODO can have more than one LOCATION parameter. They are also misleading: they suggest that the intended purpose of the LANGUAGE property parameter is to allow multiple versions of a human-readable text string to be given translated into multiple languages. This is clearly not the case, since for many of the properties which have human-readable text string values (such as SUMMARY, DESCRIPTION, LOCATION, and the CN property of an ATTENDEE) the property cannot occur more than once, and for those (like CATEGORIES and RESOURCES) that can occur more than once, no provision is made for distinguishing which property is a translation of which: if there are multiple LANGUAGE=en and LANGUAGE=da CATEGORIES, and I change or delete one of the English ones, my CUA would have no way of knowing which of the Danish ones needed to be changed or delet! ed! . [Had the intention of the writers of the RFC been to allow multiple versions of a human-readable text string to be given translated into multiple languages, they would presumably have added a property parameter to do so along the following lines: LOCATION;TRANSLATION="no:Tyskland";LANGUAGE=en:Germany with ABNF translationparam = "TRANSLATION" "=" DQUOTE translation DQUOTE *("," DQUOTE translation DQUOTE) translation = language ":" *QSAFE-CHAR It would also be necessary to specify that for properties like CATEGORIES and RESOURCES whose value can be a comma separated list, the TRANSLATION property parameter must contain a comma-separated list containing the same number of entries, each being the translation of the corresponding entry in the property value. However, I am NOT proposing this addition, since I suspect very few CUAs could implement it, particularly the user interface required to enter it.] Presumably the intention of the RFC is simply to allow the attachment of metadata specifying what human language a piece of humen readable text is in, to facilitate operations such as filtering, indexing, or attempts at machine translation by not requiring that they first guess what language the human-readable text is in. In addition, the second LOCATION example in section 4.2.10 uses Quoted-Printable encoding. Since the standard and recommended encoding for iCal is UTF-8, whould it not be better for the example to use UTF-8? --Roger __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From owner-ietf-calendar@mail.imc.org Fri Jul 13 17:56:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17628 for ; Fri, 13 Jul 2001 17:56:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6DLhg604691 for ietf-calendar-bks; Fri, 13 Jul 2001 14:43:42 -0700 (PDT) Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DLheq04686 for ; Fri, 13 Jul 2001 14:43:40 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-d06.mx.aol.com (mail_out_v31.7.) id 7.b5.7e34f3 (16214) for ; Fri, 13 Jul 2001 17:43:34 -0400 (EDT) Received: from netscape.com (aimmail02.aim.aol.com [205.188.144.194]) by air-in01.mail.aol.com (v79.27) with ESMTP id MAILININ12-0713174333; Fri, 13 Jul 2001 17:43:33 -0400 Date: Fri, 13 Jul 2001 17:43:33 -0400 From: rogerdox14@netscape.net (Roger D) To: ietf-calendar@imc.org Subject: Adding more unique identifiers Mime-Version: 1.0 Message-ID: <1DE0D43E.01CFEF87.10749803@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id f6DLhg604691 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA17628 The change management component properties in section 4.8.7 seem to be designed for doing data merging at the component level. This is normally adequate, given that an individual VEVENT or VTODO has an ORGANIZER, but it will fail if the ORGANIZER grants permission for someone else to act on their behalf, or if the ORGANIZER uses multiple CUAs (perhaps on multiple desktop machines, or a desktop and a PDA) and changes made in multiple places arrive at the server out of order. As a result, a server and one or more CUAs might wish to implement a more ambitious aim, that of doing data merging at an individual property level. To do this, the first thing that is necessary is to give each component and property a unique identity. The only component that currently cannot have a unique identifier is a VALARM sub-component (assuming that a TZID on a VTIMEZONE is a globally unique identifier, which is not an entirely safe assumption, and that STANDARDC and DAYLIGHTC sub-components in a VTIMEZONE can be uniquely identified by their DTSTART). I propose that we allow a UID property to be added (as an optional property that can occur only once) to any sort of VALARM, and we may wish to consider allowing this on a VTIMEZONE, STANDARC, and DAYLIGHTC as well. We also might wish to strengthen the language of section 4.8.4.7 to at least RECOMMEND that calendar systems generating VALARM component give it a UID. For properties that can only occur once, no unique identifier is required: their identity is implicitly specified by the uid of the component they are a property of. However, for those properties that can occur more than once in a component (ATTACH, ATTENDEE, CATEGORIES, COMMENT, CONTACT, DAYLIGHTC, EXDATE, EXRULE, FREEBUSY, RSTATUS, RELATED, RESOURCES, RDATE, RRULE, STANDARDC, TZNAME and X-PROP, and possibly also DESCRIPTION for VJOURNALs), and do not already have a unique identifying value (ATTENDEE has the CAL-ADDRESS which must be unique, and arguably EXDATE and RDATE do since their values must be unique), we would need to allow the addition of a disambiguating property parameter. I hereby formally propose the following: To: ietf-calendar@imc.org Parameter Name: PUID Purpose: To specify a unique identifier for a property that may occur more than once in a component, to facilitate property level change management. Format Definition: This property parameter is defined by the following notation:    puidparam = "PUID" "=" DQUOTE puid DQUOTE        puid = <*QSAFE text forming a unique identifier> Description: This parameter can be specified on properties that are allowed to exist more than once in a component (even if there is currently only one such property in the component). The value of the "puid" property parameter MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [5] addr-spec. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of the "@", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts should be using the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can gua! rantee the uniqueness of the left hand side within the scope of that domain. For those properties (CATEGORIES and RESOURCES) whose value can be a comma separated list, the PUID applies only to the first element in the comma separated list, and the other elements in the list have no unique identities specified. If a calendar system uses PUID parameters, it should list each individual category as a separate CATEGORIES property and each resource as a separate RESOURCES property, avoiding the use of comma separated lists, thus allowing each category or resource to have its own PUID. This parameter is an important method for group scheduling applications to match properties in requests with those in later replies, modifications or deletion requests. To assure interoperability with other group scheduling applications, calendaring and scheduling applications receiving a component that has PUID parameters on one or more of its properties MUST persist and return this parameter in a reply, modification or deletion request on all properties where it is already present, and SHOULD generate this parameter on all additional properties they create for the component in a reply, modification or deletion request. This identifier is normally created by the calendar system that generates an iCalendar property, but if it is absent any calendar system that receives the iCalendar property MAY generate a PUID for it. Implementations MUST be able to receive and persist values of at least 255 characters for this parameter. The following is an example of this property parameter:      RESOURCES;PUID="200007131T231132Z-3428F374523-0042@host2.com":VCR --Roger P.S. We might also wish to suggest the use of BASE64 encoded 128-bit MD5 hashes of a suitable amount of entropy (certainly including the current date and time and the machine's IP address) as a UID, like the Microsoft GUID, as an alternative approach to generating a UID. __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From owner-ietf-calendar@mail.imc.org Sat Jul 14 00:09:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02285 for ; Sat, 14 Jul 2001 00:09:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6E3wOJ15966 for ietf-calendar-bks; Fri, 13 Jul 2001 20:58:24 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6E3wNq15958 for ; Fri, 13 Jul 2001 20:58:23 -0700 (PDT) Received: (qmail 241491 invoked from network); 14 Jul 2001 03:54:36 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 14 Jul 2001 03:54:36 -0000 Message-ID: <3B4FC1A1.52F8C379@kasey.umkc.edu> Date: Fri, 13 Jul 2001 22:50:57 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Take two: Where would a SPKI/SDSI authorization certificate go? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here are two proposed additions to draft-ietf-calsch-cap-04.txt followed by a discussion of the process of writing them. BEGIN PROPOSAL 1 2.4.4.3 Authority Certificates A UPN can be granted additional VCARs by presentation of [RFC2692/RFC2693] SPKI authority certificates. The scope of such grants is implementation-specific. The grants persist for the duration of the session in which the certificate is presented only. END PROPOSAL 1 BEGIN PROPOSAL 2 7.1.11. AUTHORIZE Command Arguments: a [RFC2692/RFC2693] SPKI Authorization Certificate Data: None Result: 2.0 7.1 Certificate does not signify anything 7.2 Certificate expired 7.3 Certificate VCAR denied 7.4 Too many bad certificates The "AUTHORIZE" command allows the UPN to acquire additional VCARs for the duration of the current session. This command may only be called in the Identified State. The CS determines through an internal mechanism if the credential supplied permits the granting of any VCAR. If it does, the UPN may acquire the new VCAR for the current session, otherwise a security error is returned. END PROPOSAL 2 DISCUSSION: SPKI authorization certificates are exactly what I was asking about earlier. (for simplifying limited, anonymous delegations.) "Delegate" is defined in the glossary but never used in draft-ietf-calsch-imp-guide-02.txt outside of the definition. The question remains, what would be a standard way to associate one with a CUA->CS instruction? With SMTP/MIME, it seems that the certificate could be in its own attachment in the same message, instead of being a proper iCalendar component. for iRIP, there is not (please correct me?) a specified way to include something else with the message. There's no declared or obvious out-of-band standard way to shoehorn in a piece of arbitrary additional info like a SPKI certificate. Throwing BEGIN:CERTIFICATE .... END:CERTIFICATE into the iRIP stream would certainly do it, but it's not clear that this would be allowed by the current specification. CAP-04 says: > The method by which a server composes and validates an > authorization identity from the authentication credentials > supplied by a client is implementation-specific. For maximizing interoperability, we could reserve a designated anonymous name -- perhaps the empty string, 'ANONYMOUS, or 'GUEST' -- which would be the same everywhere, like anonymous in FTP. ... Oh, I see that anonymous is already in sec. 7.1.3.1 So I suppose certificates would be presented during the SASL phase of the the iCalendar session... Skimming the documents referred to by http://www.iana.org/assignments/sasl-mechanisms does not suggest any that lend themselves to allowing anything other than username/password pairs to get sent through them, except for Kerberos, which is concerned with presenting a kerberos token for validation. Aha! rfc2245 not only includes the 'trace information ... string' but says A server which permits anonymous access will announce support for the ANONYMOUS mechanism, and allow anyone to log in using that mechanism, usually with restricted access. (initially) leading me to conclude that, for iRIP, the appropriate way to present one or more SPKI authority certificates would be, included in an extended rfc2245 trace information string: in iMIP, the appropriate way to present one or more SPKI authority certificates is to include them as seperate MIME sections. In iRIP, the appropriate way to present one or more SPKI authority certificates is to include them in an extended rfc2245 trace information string. This scheme was later abandoned. But what if you need to augment a real log-in with a certificate? Also, rfc2245 only allows the strings to be 255 chars long. And stuffing data in the password field is a really really ugly hack. RFC2222 also provides: > 7.4. External mechanism > > The mechanism name associated with external authentication is > "EXTERNAL". > > The client sends an initial response with the authorization identity. > > The server uses information, external to SASL, to determine whether > the client is authorized to authenticate as the authorization > identity. If the client is so authorized, the server indicates > successful completion of the authentication exchange; otherwise the > server indicates failure. > > The system providing this external information may be, for example, > IPsec or TLS. Maybe a SPKI certificate could be presented as an External mechanism, and a compliant CUA would set up a second, parallel session with a CS for using a certificate based authority rather than an identity-based authority. CAP-04 includes this: > 12 Security Considerations > > For the mandatory SASL mechanism that CAP specifies, the > mechanism support is: > > MUST authentication > MUST authorization > MAY impersonation This is the only place "impersonation" appears in the document. This term does not appear in rfc2222 either. I assume that impersonation means, there is a way for a session to switch to a second impersonated identity, within the bounds of an established session. Clients specify their authentication method with the AUTHENTICATE keyword, as in cap-04's example > C: AUTHENTICATE KERBEROS_V4 > S: AmFYig== > C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT > S: or//EoAADZI= > C: DiAF5A4gA+oOIALuBkAAmw== > S: 2.0 > S: IDENTITY=bill@example.com > S: CAPVERSION=1.0 Maybe a proper way to present a SPKI certificate to a CS could be C: AUTHENTICATE EXTERNAL C: < SPKI CERTIFICATE HERE > C: . S: . No, that is explicitly ruled out by the nature of the AUTHENTICATE command. Specifically, that there can be only oneper session. See below for proposal for new AUTHORIZE command suitable for inclusion into draft-ietf-calsch-cap-04.txt. Or maybe the TLS credential exchange mechanism already covers it. No, TLS is concerned with establishing a secure channel, and using it for a path for out-of-band data would be ugly. I propose extending section 2.4.4, VCalendar Access Rights, to include a section that says: BEGIN PROPOSAL 1 2.4.4.3 Authority Certificates A UPN can be granted additional VCARs by presentation of SPKI authority certificates. The scope of such grants is implementation-specific, but they are expected to persist for the duration of the session in which the certificate is presented only. END PROPOSAL 1 Ah, the state diagram. Rather than attempting to allow AUTHENTICATE commands to be issued from the IDENTIFIED state, which would be incorrect, I would propose a fourth primitive, AUTHORIZE, valid in the IDENTIFIED state, and optional for a CS to implement, which would be followed by a SPKI authorization certificate, to grant additional VCARs to the current UPN for the duration of the session. Did anyone notice there is no section 7.1.9? Also, 7.1.10 conflicts with the state diagram. Do you start TLS before, after, or during authentication? This is not clear. According to the state diagram you issue STARTTLS from the IDENTIFIED state, but according to 7.1.10 you can only issue STARTTLS from the CONNECTED state. I think this can be rectified by correcting the state diagram, and offering STARTTLS as an alternate path, but I do not know. Oh. SENDDATA is 7.1.9, but is mis-numbered. BEGIN PROPOSAL 2 7.1.11. AUTHORIZE Command Arguments: None Data: a [rfc2692] SPKI Authorization Certificate Result: 2.0 7.1 Certificate does not signify anything 7.2 Certificate expired 7.3 Certificate VCAR denied 7.4 Too many bad certificates The "AUTHORIZE" command allows the UPN to acquire additional VCARs for the duration of the current session. This command may only be called in the Identified State. The CS determines through an internal mechanism if the credential supplied permits the granting of any VCAR. If it does, the UPN may acquire the new VCAR for the current session, otherwise a security error is returned. END PROPOSAL 2 -- David Nicol 816.235.1187 From owner-ietf-calendar@mail.imc.org Sat Jul 14 00:38:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05426 for ; Sat, 14 Jul 2001 00:38:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6E4SJB20810 for ietf-calendar-bks; Fri, 13 Jul 2001 21:28:19 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6E4SHq20801 for ; Fri, 13 Jul 2001 21:28:17 -0700 (PDT) Received: (qmail 241938 invoked from network); 14 Jul 2001 04:24:31 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 14 Jul 2001 04:24:31 -0000 Message-ID: <3B4FC8A4.76383FA4@kasey.umkc.edu> Date: Fri, 13 Jul 2001 23:20:52 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: cap-talk@eros-os.org Subject: Take two: Where would a SPKI/SDSI authorization certificate go? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here are two proposed additions to draft-ietf-calsch-cap-04.txt followed by a discussion of the process of writing them. BEGIN PROPOSAL 1 2.4.4.3 Authority Certificates A UPN can be granted additional VCARs by presentation of [RFC2692/RFC2693] SPKI authority certificates. The scope of such grants is implementation-specific. The grants persist for the duration of the session in which the certificate is presented only. END PROPOSAL 1 BEGIN PROPOSAL 2 7.1.11. AUTHORIZE Command Arguments: a [RFC2692/RFC2693] SPKI Authorization Certificate Data: None Result: 2.0 7.1 Certificate does not signify anything 7.2 Certificate expired 7.3 Certificate VCAR denied 7.4 Too many bad certificates The "AUTHORIZE" command allows the UPN to acquire additional VCARs for the duration of the current session. This command may only be called in the Identified State. The CS determines through an internal mechanism if the credential supplied permits the granting of any VCAR. If it does, the UPN may acquire the new VCAR for the current session, otherwise a security error is returned. END PROPOSAL 2 DISCUSSION: SPKI authorization certificates are exactly what I was asking about earlier. (for simplifying limited, anonymous delegations.) "Delegate" is defined in the glossary but never used in draft-ietf-calsch-imp-guide-02.txt outside of the definition. The question remains, what would be a standard way to associate one with a CUA->CS instruction? With SMTP/MIME, it seems that the certificate could be in its own attachment in the same message, instead of being a proper iCalendar component. for iRIP, there is not (please correct me?) a specified way to include something else with the message. There's no declared or obvious out-of-band standard way to shoehorn in a piece of arbitrary additional info like a SPKI certificate. Throwing BEGIN:CERTIFICATE .... END:CERTIFICATE into the iRIP stream would certainly do it, but it's not clear that this would be allowed by the current specification. CAP-04 says: > The method by which a server composes and validates an > authorization identity from the authentication credentials > supplied by a client is implementation-specific. For maximizing interoperability, we could reserve a designated anonymous name -- perhaps the empty string, 'ANONYMOUS, or 'GUEST' -- which would be the same everywhere, like anonymous in FTP. ... Oh, I see that anonymous is already in sec. 7.1.3.1 So I suppose certificates would be presented during the SASL phase of the the iCalendar session... Skimming the documents referred to by http://www.iana.org/assignments/sasl-mechanisms does not suggest any that lend themselves to allowing anything other than username/password pairs to get sent through them, except for Kerberos, which is concerned with presenting a kerberos token for validation. Aha! rfc2245 not only includes the 'trace information ... string' but says A server which permits anonymous access will announce support for the ANONYMOUS mechanism, and allow anyone to log in using that mechanism, usually with restricted access. (initially) leading me to conclude that, for iRIP, the appropriate way to present one or more SPKI authority certificates would be, included in an extended rfc2245 trace information string: in iMIP, the appropriate way to present one or more SPKI authority certificates is to include them as seperate MIME sections. In iRIP, the appropriate way to present one or more SPKI authority certificates is to include them in an extended rfc2245 trace information string. This scheme was later abandoned. But what if you need to augment a real log-in with a certificate? Also, rfc2245 only allows the strings to be 255 chars long. And stuffing data in the password field is a really really ugly hack. RFC2222 also provides: > 7.4. External mechanism > > The mechanism name associated with external authentication is > "EXTERNAL". > > The client sends an initial response with the authorization identity. > > The server uses information, external to SASL, to determine whether > the client is authorized to authenticate as the authorization > identity. If the client is so authorized, the server indicates > successful completion of the authentication exchange; otherwise the > server indicates failure. > > The system providing this external information may be, for example, > IPsec or TLS. Maybe a SPKI certificate could be presented as an External mechanism, and a compliant CUA would set up a second, parallel session with a CS for using a certificate based authority rather than an identity-based authority. CAP-04 includes this: > 12 Security Considerations > > For the mandatory SASL mechanism that CAP specifies, the > mechanism support is: > > MUST authentication > MUST authorization > MAY impersonation This is the only place "impersonation" appears in the document. This term does not appear in rfc2222 either. I assume that impersonation means, there is a way for a session to switch to a second impersonated identity, within the bounds of an established session. Clients specify their authentication method with the AUTHENTICATE keyword, as in cap-04's example > C: AUTHENTICATE KERBEROS_V4 > S: AmFYig== > C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT > S: or//EoAADZI= > C: DiAF5A4gA+oOIALuBkAAmw== > S: 2.0 > S: IDENTITY=bill@example.com > S: CAPVERSION=1.0 Maybe a proper way to present a SPKI certificate to a CS could be C: AUTHENTICATE EXTERNAL C: < SPKI CERTIFICATE HERE > C: . S: . No, that is explicitly ruled out by the nature of the AUTHENTICATE command. Specifically, that there can be only oneper session. See below for proposal for new AUTHORIZE command suitable for inclusion into draft-ietf-calsch-cap-04.txt. Or maybe the TLS credential exchange mechanism already covers it. No, TLS is concerned with establishing a secure channel, and using it for a path for out-of-band data would be ugly. I will propose extending section 2.4.4, VCalendar Access Rights, to include a section about getting new ones from a certificate. Ah, the state diagram. Rather than attempting to allow AUTHENTICATE commands to be issued from the IDENTIFIED state, which would be incorrect, I would propose a fourth primitive, AUTHORIZE, valid in the IDENTIFIED state, and optional for a CS to implement, which would be followed by a SPKI authorization certificate, to grant additional VCARs to the current UPN for the duration of the session. Did anyone notice there is no section 7.1.9? Also, 7.1.10 conflicts with the state diagram. Do you start TLS before, after, or during authentication? This is not clear. According to the state diagram you issue STARTTLS from the IDENTIFIED state, but according to 7.1.10 you can only issue STARTTLS from the CONNECTED state. I think this can be rectified by correcting the state diagram, and offering STARTTLS as an alternate path, but I do not know. Oh. SENDDATA is 7.1.9, but is mis-numbered. -- David Nicol 816.235.1187 From owner-ietf-calendar@mail.imc.org Mon Jul 16 15:32:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23745 for ; Mon, 16 Jul 2001 15:32:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GJD3F24293 for ietf-calendar-bks; Mon, 16 Jul 2001 12:13:03 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6GJD1q24288 for ; Mon, 16 Jul 2001 12:13:02 -0700 (PDT) Received: (qmail 286478 invoked from network); 16 Jul 2001 19:08:57 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 16 Jul 2001 19:08:57 -0000 Message-ID: <3B533AF3.4026BED0@kasey.umkc.edu> Date: Mon, 16 Jul 2001 14:05:23 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org, cap-talk@eros-os.org Subject: Re: Take two: Where would a SPKI/SDSI authorization certificate go? References: <3B4FC8A4.76383FA4@kasey.umkc.edu> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f6GJD2q24290 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id f6GJD3F24293 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA23745 > BEGIN PROPOSAL 2 > > 7.1.11. AUTHORIZE Command > > Arguments: a [RFC2692/RFC2693] SPKI Authorization Certificate > > Data: None > > Result: 2.0 > 7.1 Certificate does not signify anything > 7.2 Certificate expired > 7.3 Certificate VCAR denied > 7.4 Too many bad certificates > > The "AUTHORIZE" command allows the UPN to acquire additional > VCARs for the duration of the current session. This command > may only be called in the Identified State. > > The CS determines through an internal mechanism if the > credential supplied permits the granting of any VCAR. If it > does, the UPN may acquire the new VCAR for the current session, > otherwise a security error is returned. > > END PROPOSAL 2 The text following a 2.0 response code SHOULD be a human-readable, localized to the UPN's preference, describing the access right granted, such as "você pode editar descrições do evento no quarto de reunião #4 em quarta-feira de 2 a 4 PM." VCARs acquired through SPKI certificate MAY persistently associate with the UPN, or not, according to the CS. All VCARs acquired by the Anonymous UPN MUST be associated with the particular session only, and MUST be released on session end. From owner-ietf-calendar@mail.imc.org Tue Jul 17 11:22:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28901 for ; Tue, 17 Jul 2001 11:22:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HF6xV12266 for ietf-calendar-bks; Tue, 17 Jul 2001 08:06:59 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HF6vq12262 for ; Tue, 17 Jul 2001 08:06:57 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6HF6pv20815 for ; Tue, 17 Jul 2001 08:06:52 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGMHZG00.5DJ for ; Tue, 17 Jul 2001 08:06:52 -0700 Message-ID: <3B545465.B89CDD4E@netscape.com> Date: Tue, 17 Jul 2001 08:06:13 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP - Mutual Trust Model Content-Type: multipart/mixed; boundary="------------BFBF8908DE5CB9D8A35EE802" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BFBF8908DE5CB9D8A35EE802 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, One of the issues we need to nail is a question about whether or not there is a mutual trust model between CAP servers. My recommendation is that we to NOT try to put anything like this in the first pass of CAP. First, it will be complicated. Second, a CAP server is a *very* useful thing even in the absence of a mutual trust model. Finally, if you are a cap server vendor, you could implement your own version of mutual trust (then you could even put together a draft to propose how we should implement it :-). Any objections to excluding a mutual trust model in CAP? -Steve --------------BFBF8908DE5CB9D8A35EE802 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------BFBF8908DE5CB9D8A35EE802-- From owner-ietf-calendar@mail.imc.org Tue Jul 17 11:50:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05582 for ; Tue, 17 Jul 2001 11:50:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HFQiY12869 for ietf-calendar-bks; Tue, 17 Jul 2001 08:26:44 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HFQhq12864 for ; Tue, 17 Jul 2001 08:26:43 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6HFS7819736 for ; Tue, 17 Jul 2001 11:28:07 -0400 Message-ID: <3B545985.6080203@ecal.com> Date: Tue, 17 Jul 2001 11:28:05 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP - Mutual Trust Model References: <3B545465.B89CDD4E@netscape.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: >One of the issues we need to nail is a question about whether or not >there is a mutual trust model between CAP servers. My recommendation is >that we to NOT try to put anything like this in the first pass of CAP. >First, it will be complicated. > Also risky. I think you're right; we should put it off. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"The avalanche has already started. It is too| |francis@ecal.com|late for the pebbles to vote." --Kosh | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Jul 17 13:37:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29026 for ; Tue, 17 Jul 2001 13:37:23 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6HHJMm08761 for ietf-calendar-bks; Tue, 17 Jul 2001 10:19:22 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HHJKq08757 for ; Tue, 17 Jul 2001 10:19:20 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA11466; Tue, 17 Jul 2001 13:19:16 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6HHJGv19523; Tue, 17 Jul 2001 13:19:16 -0400 (EDT) Message-ID: <3B547391.4E76DC47@steltor.com> Date: Tue, 17 Jul 2001 13:19:13 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP - Mutual Trust Model References: <3B545465.B89CDD4E@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. We should exclude it, and perhaps mention in the draft that CAP does not specify a mutual trust model between CAP servers and it is left to the implementors to come up with their own model. George Steve Mansour wrote: > > Folks, > > One of the issues we need to nail is a question about whether or not > there is a mutual trust model between CAP servers. My recommendation is > that we to NOT try to put anything like this in the first pass of CAP. > First, it will be complicated. Second, a CAP server is a *very* useful > thing even in the absence of a mutual trust model. Finally, if you are a > cap server vendor, you could implement your own version of mutual trust > (then you could even put together a draft to propose how we should > implement it :-). > > Any objections to excluding a mutual trust model in CAP? > > -Steve From owner-ietf-calendar@mail.imc.org Tue Jul 17 16:38:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08165 for ; Tue, 17 Jul 2001 16:38:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HKN0w13054 for ietf-calendar-bks; Tue, 17 Jul 2001 13:23:00 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6HKMxq13049 for ; Tue, 17 Jul 2001 13:22:59 -0700 (PDT) Received: (qmail 308915 invoked from network); 17 Jul 2001 20:18:56 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 17 Jul 2001 20:18:56 -0000 Message-ID: <3B549CD4.10190B46@kasey.umkc.edu> Date: Tue, 17 Jul 2001 15:15:16 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: CAP - Mutual Trust Model References: <3B545465.B89CDD4E@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > Folks, > > One of the issues we need to nail is a question about whether or not > there is a mutual trust model between CAP servers. My recommendation is > that we to NOT try to put anything like this in the first pass of CAP. > First, it will be complicated. Second, a CAP server is a *very* useful > thing even in the absence of a mutual trust model. Finally, if you are a > cap server vendor, you could implement your own version of mutual trust > (then you could even put together a draft to propose how we should > implement it :-). > > Any objections to excluding a mutual trust model in CAP? > > -Steve If we accept the AUTHORIZE primitive, it would work very nicely for a mechanism for a CS to authorize itself to another CS. My suggestion is therefore to suggest this as an example of the kind of thing you can do with an AUTHORIZE primitive. -- David Nicol 816.235.1187 "Your plastic pal who's fun to be with" From owner-ietf-calendar@mail.imc.org Wed Jul 18 09:49:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25681 for ; Wed, 18 Jul 2001 09:49:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IDbXN16773 for ietf-calendar-bks; Wed, 18 Jul 2001 06:37:33 -0700 (PDT) Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IDbWq16763 for ; Wed, 18 Jul 2001 06:37:32 -0700 (PDT) Received: from metaacer ([212.151.236.165]) by fep01-svc.swip.net with ESMTP id <20010718133835.NRJO21692.fep01-svc.swip.net@metaacer> for ; Wed, 18 Jul 2001 15:38:35 +0200 From: "Greg FitzPatrick" To: Subject: mixing mimedirectiory ABNF and XML Date: Wed, 18 Jul 2001 15:36:59 +0200 Message-ID: <000001c10f8e$bebe4dc0$a5ec97d4@metaacer> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f6IDbXq16768 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id f6IDbXN16773 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA25681 I have a question to the list. For some time now the SkiCal group has been working on our “Opening Times” properties. In the updated draft v.04 you can see how we solved some of the problems involved, using primarily property parameters. It is now apparent to us that the best solution is to forgo property or property parameter constructions and put together the Opening Times package using value types. I assume this is also what happened to Frank et al some years back when trying to put together the iCal Reoccurrence set. The authors of 2445 probably found that the logical models possible using properties and property parameters were not sufficient, so they used value-types with their own syntax logic. As delimiters between those value-types, they reused the colon, semicolon and equal sign. I remember when first reading 2445 that it took a while to understand that the Reoccurrence set was a property value and not a construct of properties and property parameters. Now we are doing the same. There is an ABNF snippet of such a property value-type declaration included below and as you can see we are using “(“ and “,” as separators. But please don't get involved in picking apart the snippet, since it is not the purpose of this message. During our work it struck us that since a Property value could be formed pretty much any way we wished, why create a new syntax when XML already exists. Why not use an XML DTD or Schema declaration for our “optimeset” property value. Instead of creating this optimeset = ”OPTIMESET “=” “(” (optimeparam) ”)” we could do this optimeset = “<” ”OPTIMESET” “>” optimemaram so that an object might look like this... DTOPEN;language=”XML1.0”: 20020101/20021231 instead of this… DTOPEN;language=”something Niklas made up”: OPTIMESET;ID=123(OPTERM=20020101/20021231) *** Note: the language parameter is used in jest Basically we would be using an ABNF to describe what was actually a DTD or SCHEMA. This seems rather unconventional. Combining an XML value type with iCal Mime-directory has many positive outcomes. It means that we can reuse the same DTD/SCHEMA in our XML/RDF calendaring work as for our iCal extension, we can adhere to an acknowledged standard, we can use any number of validating tools to help us when designing and our logical model comes to a great extent ready-made. We would like to get some opinion on this. Do angle brackets in SkiCal value-types cause allergic (or kneejerkic) reactions for anyone? Though it is possible to define the DTD/SCHEMAS in ABNF it would certainly save effort to do them in their natural habitat. Would ABNF and XML-SCHEMA in the same RFC be problematic? Would we have to define the optimeset as an XML-SCHEMA in a separate draft and then refer to it? Love to hear some opinion on this? Greg optimeset = ”OPTIMESET=(” (optimeparam) ”)” optimeparam = (opterm / opseason / opday / ophour / opminute) opterm = ( “OPTERM “ / “NOPTERM” ) “=“ optermvalue *( “,” optermvalue ) / *1( “(“ optermparam ) optermvalue = optermexplicitvalue / optermperiodvalue optermexplicitvalue = DQUOTE (date / date-time) “/” ((date / date-time) / term-text ) DQUOTE date-time = date ”T” time date = date-value date-value = date-fullyear date-month date-mday date-fullyear = 4DIGIT date-month = 2DIGIT ; 01- 12 date-mday = 2DIGIT ; O1-28, 01-29, 01-30, 01-31 time = time-hour time-minute time-second [time-utc] time-hour = 2DIGIT ;00-23 time-minute = 2DIGIT ;00-59 time-second = 2DIGIT ;00-60 [time-fraction] ; The ”60” value is used to ; account for ”leap” seconds. time-fraction = 1*DIGIT ; as many digits as desired may ; may be used. time-utc = ( ”Z” ) / (( ”+” / ”-”) time-hour [ ”:” time-minute] )) term-text = “THISANDFUTURE” / “THISANDPRIOR” optermperiodvalue = DQUOTE (date / date-time) “/” termperiod DQUOTE termperiod = ([”+”] / ”-”) ”P” (dur-year / dur month / dur-week / dur-day / dur-time ) dur-year = 1*DIGIT ”Y” dur-month = 1*DIGIT ”M” dur-week = 1*DIGIT ”W” dur-day = 1*DIGIT ”D” dur-time = ”T” (dur-hour / dur-minute / dur-second) dur-hour = 1*DIGIT ”H” [dur-minute] dur-minute = 1*DIGIT ”M” [dur-second] dur-second = 1*DIGIT ”S” optermparam = ( opseason / opday / ophour / opminute ) opseason = ( “OPSEASON “ / “NOPSEASON” ) “=“ opseasonvalue *( “,” opseasonvalue ) / *1( “(“ opseasonparam ) From owner-ietf-calendar@mail.imc.org Wed Jul 18 09:55:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27405 for ; Wed, 18 Jul 2001 09:55:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IDYuZ16159 for ietf-calendar-bks; Wed, 18 Jul 2001 06:34:56 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IDYsq16147 for ; Wed, 18 Jul 2001 06:34:54 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA23059; Wed, 18 Jul 2001 09:34:49 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6IDYmv05048; Wed, 18 Jul 2001 09:34:48 -0400 (EDT) Message-ID: <3B559078.AB08DD9B@steltor.com> Date: Wed, 18 Jul 2001 09:34:48 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Last Call For "Guide To Internet Calendaring" Content-Type: multipart/mixed; boundary="------------2A41B6753C0D0F0CEFB5EF75" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2A41B6753C0D0F0CEFB5EF75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've submitted the latest version to the ietf. This is a last call for the working group. It gives you two weeks for your comments. If all goes well it will be submitted to the IESG as an informational RFC. Here it is. (I've made changes based on your comments.) --------------2A41B6753C0D0F0CEFB5EF75 Content-Type: text/html; charset=us-ascii; name="draft-ietf-calsch-inetcal-guide-01.html" Content-Disposition: inline; filename="draft-ietf-calsch-inetcal-guide-01.html" Content-Transfer-Encoding: 7bit Guide to Internet Calendaring
 TOC 
Network Working GroupB. Mahoney
Internet-DraftMIT
Expires: January 16, 2002G. Babics
 Steltor
 A. Taler
 July 18, 2001

Guide to Internet Calendaring
draft-ietf-calsch-inetcal-guide-01

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 16, 2002.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

This document describes the various Internet calendaring and scheduling standards and works in progress and the relationships between them. It's intention is to provide a context for these documents, assist in their understanding, and potentially help implementers in the design of their standards based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and could be targets for future work.


 TOC 

Table of Contents

    1.  Introduction
     1.1  Terminology
     1.2  Concepts and Relationships
     2.  Requirements
     2.1  Fundamental Needs
     2.2  Protocol Requirements
     3.  Solutions
     3.1  Examples
     3.2  Systems
     3.2.1  Standalone single-user system
     3.2.2  Single-user systems communicating
     3.2.3  Single-user with multiple CUA
     3.2.4  Single-user with multiple calendars
     3.2.5  Users communicating on a multi-user system
     3.2.6  Users communicating through different multi-user systems
     4.  Important Aspects
     4.1  Timezones
     4.2  Choice of Transport
     4.3  Security
     4.4  Amount of data
     4.5  Recurring Components
     5.  Open Issues
     5.1  Scheduling people, not calendars
     5.2  Administration
     5.3  Notification
     6.  Security considerations
     6.1  Access Control
     6.2  Authentication
     6.3  Using email
     6.4  Other issues
     §  Authors' Addresses
     A.  Acknowledgments
     B.  Bibliography
     §  Full Copyright Statement


 TOC 

1. Introduction

The calendaring and scheduling protocols are intended to provide for the needs of individuals attempting to obtain calendaring information and schedule meetings across the Internet, organizations attempting to provide calendaring information on the Internet, as well as organizations looking for a calendaring and scheduling solution to deploy internally.

It is the intent of this document to provide a context for the calendar standards and works in progress, assist in their understanding, and potentially help implementers in the design of their Internet calendaring and scheduling systems.

Problems not solved by these protocols, as well as security issues to be kept in mind, are discussed at the end of the document.

1.1 Terminology

This memo uses much of the same terminology as iCalendar [RFC-2445], iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following definitions are provided as introductory, the definitions in the protocol specifications are the canonical ones.

Calendar

A collection of events, to-dos, journal entries, etc. A calendar could be the content of a person or a resource's agenda; it could also be a collection of data serving a more specialized need. Calendars are the basic storage containers for calendaring information.

Calendar Access Rights

A set of rules for a calendar describing who may perform which operations on that calendar, such as reading and writing information.

Calendar Service

A running server application which provides access to a collection of calendars.

Calendar Store (CS)

A data store of a calendar service. A calendar service may have several calendar stores, and each store may contain several calendars, as well as properties and components outside of the calendars.

Calendar User (CU)

An entity (often a human) that accesses calendar information.

Calendar User Agent (CUA)

Software used by the calendar user that communicates with calendar services to provide the user access to calendar information.

Component

A piece of calendar data such as an event, a to-do or an alarm. Information about components is stored as properties of those components.

Delegator

Is a calendar user (sometimes called the delegatee) who has assigned his or her participation in a scheduled calendar component (e.g., VEVENT) to another calendar user (sometimes called the delegate or delegatee).

Delegate

Is a calendar user (sometimes called the delegatee) who has been assigned participation in a scheduled calendar component (e.g., VEVENT) by one of the attendees in the scheduled calendar component (sometimes called the delegator). An example of a delegate is a team member told to go to a particular meeting.

Designate

Is a calendar user who is authorized to act on behalf of another calendar user. An example of a designate is an assistant.

Local Store

A CS which is on the same platform as the CUA.

Property

A property of a component, such as a description or a start time.

Remote Store

A CS which is not on the same platform as the CUA.

1.2 Concepts and Relationships

iCalendar is the language used to describe calendar objects. iTIP is a way to use the language to do scheduling. iMIP is how to do iTIP with email. CAP is a way to use the language, to access a calendar store in real-time.

The relationship between the calendaring protocols is similar to that between the email protocols. In those terms iCalendar is like RFC 822, iTIP and iMIP are like SMTP, and CAP is like POP or IMAP.


 TOC 

2. Requirements

2.1 Fundamental Needs

The following examples illustrate people's and organizations' basic calendaring and scheduling needs:

a] A doctor wishes to keep track of all his appointments.

Need: Read and manipulate one's own calendar with only one CUA.

b] A busy musician wants to maintain her schedule with different devices, such as with an Internet-based agenda or with a PDA.

Need: Read and manipulate one's own calendar, possibly with solutions from different vendors.

c] A software development team wishes to share agenda information by using a group scheduling product in order to more effectively schedule their time.

Need: Share calendar information with users using the same calendar service.

d] A teacher wants his students to be able to schedule calendar entries during his office hours.

Need: Schedule calendar events, to-dos and journals with users using the same calendar service.

e] A movie theater wants to publish its schedule so that prospective customers can easily access it.

Need: Share calendar information with users using other calendar services, possibly from different vendors.

f] A social club wants to be able to schedule calendar entries effectively with its members.

Need: Schedule calendar events and to-dos with users using other calendar services, possibly from different vendors.

2.2 Protocol Requirements

Some of the needs can be met with proprietary solutions (a, c, d), but others can not (b, e, f). From these needs we can establish that protocols are required for accessing information in a calendar store, and for scheduling calendar entries. In addition these protocols require a data format for representing calendar information.

These roles are filled by the following protocol specifications.

- iCalendar [RFC-2445] is the data format

iCalendar [RFC-2445] provides data format for representing calendar information which the other protocols can use. iCalendar [RFC-2445] can also be used in other contexts such as a drag and drop format or an export/import format. All the other protocols depend on iCalendar [RFC-2445], so all elements of a standards-based calendaring and scheduling systems will have to interpret iCalendar [RFC-2445].

- iTIP [RFC-2446] is the scheduling protocol

iTIP [RFC-2446] describes the messages used to schedule calendar events. These messages are represented in iCalendar [RFC-2445], and have semantics that include such things as being an invitation to a meeting, an acceptance of an invitation or the assignment of a task.

iTIP [RFC-2446] messages are used in the scheduling workflow, where users exchange messages in order to organize things such as events and to-dos. CUAs generate and interpret iTIP [RFC-2446] messages at the direction of the calendar user. With iTIP [RFC-2446] one can create, modify, delete, reply to, counter, and decline counters to the various iCalendar [RFC-2445] components. Furthermore, one can also request the free/busy time of other people.

iTIP [RFC-2446] is transport-independent, and has one specified transport bindings: iMIP [RFC-2447] is a binding to email. In addition [CAP] will provide a real-time binding of iTIP [RFC-2446], allowing CUAs to perform calendar management as well as scheduling over a single connection.

- [CAP] is the calendar management protocol

[CAP] describes the messages used to manage calendars on a calendar store. These messages use iCalendar [RFC-2445] to describe various components such as events and to-dos. With these messages one can do the operations in iTIP [RFC-2446] and other operations relating to a calendar store, such as search, creating calendars, specifying calendar properties, and being able to specify access rights to one's calendars.


 TOC 

3. Solutions

3.1 Examples

Returning to the examples of section 2.1, they can be solved using the protocols in the following ways:

a] The doctor can use a proprietary CUA with a local store, and perhaps use iCalendar [RFC-2445] as a storage mechanism. This would allow the doctor to easily import his store into another application that supports iCalendar [RFC-2445].

b] The musician who wishes to access her agenda from anywhere can use a [CAP] enabled calendar service accessible through the Internet. She can then use whichever [CAP] clients are available to access the data.

A proprietary system could also be employed which provides access through a web-based interface, but the use of [CAP] would be superior in that it would allow the use of third party tools, such as PDA synchronization tools.

c] The development team can use a calendar service which supports [CAP] and then each member can use a [CAP]-enabled CUA of their choice.

Alternatively, each member could use an iMIP [RFC-2447]-enabled CUA, and they could book meetings over email. This solution has the drawback that it is difficult to examine the other agendas, making organizing meetings more difficult.

Proprietary solutions are also available, but they require that all people use clients by the same vendor, and disallow the use of third party applications.

d] The teacher can set up a calendar service, and have students book time through any of the iTIP [RFC-2446] bindings. [CAP] provides real-time access, but could require additional configuration. iMIP [RFC-2447] would be the easiest to configure, but may require more email processing.

If [CAP] access is provided then determining the state of the teacher's schedule is straightforward. If not, this can be determined through iTIP [RFC-2446] free/busy requests. Non- standard methods could also be employed, such as serving up ICAL, HTML, XML over HTTP.

A proprietary system could also be used, but would require that all students be able to use software from a specific vendor.

e] For publishing a movie theater's schedule [CAP] provides the most advanced access and search capabilities. It also allows easy integration with its customer's calendar systems.

Non-standard methods such as serving data over HTTP could also be employed, but would be harder to integrate with customer's systems.

Using a completely proprietary solutions would be very difficult since it would require every user to install and use proprietary software.

f] The social club could distribute meeting information in the form of iTIP [RFC-2446] messages. This could be done over email using iMIP [RFC-2447]. Meeting invitations, as well as a full published agenda could be distributed.

Alternatively, the social club could provide access to a [CAP] enabled calendar service, however this solution would be more expensive since it requires the maintenance of a server.

3.2 Systems

The following diagrams illustrate possible example systems and usage of the protocols.

3.2.1 Standalone single-user system

A single user system that does not communicate with other systems need not employ any of the protocols. However, it may use iCalendar [RFC-2445] as a data format in some places. 

       -----------       O
      | CUA w/    |     -+- user
      |local store|      A
       -----------      / \

3.2.2 Single-user systems communicating

Users with single-user systems may schedule meetings with each other using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use is iMIP [RFC-2447], since since the messages can be held in their mail queue, which we assume to already exist. [CAP] could also be used. 

       O   -----------                    -----------   O
      -+- | CUA w/    | -----[IMIP]----- | CUA w/    | -+- user
       A  |local store|     Internet     |local store|  A
      / \  -----------                    -----------  / \

3.2.3 Single-user with multiple CUA

A single user may use more than one CUA to access his or her calendar. The user may use a PDA, a web client, a PC, or some other device, depending an accessibility. Some of these clients may have local stores and others may not. If they do, then they need to ensure that the data on the CUA is synchronized with the data on the CS. 

                 -----------
                |   CUA w   | -----[CAP]----------+
                |local store|                     |
           O     -----------                    ----------
          -+-                                  |   CS     |
           A                                   |          |
          / \                                   ----------
                 -----------                      |
                |  CUA w/o  | -----[CAP]----------+
                |local store|
                 -----------

3.2.4 Single-user with multiple calendars

A single user may have many independent calendars. One may be work related, another for personal use. The CUA may or may not have a local store. If it does, then it needs to ensure that the data on the CUA is synchronized with the data on both of the CS. 

                                                ----------
                      +------------[CAP]------ |   CS     |
                      |                        |          |
           O     -----------                    ----------
          -+-   |  CUA      |
           A    |           |
          / \    -----------
                      |                         ----------
                      +------------[CAP]------ |   CS     |
                                               |          |
                                                ----------

3.2.5 Users communicating on a multi-user system

Users on a multi-user system may schedule meetings with each other using [CAP]-enabled CUA and service. The CUA may or may not have a local store. If they do, then they need to ensure that the data on the CUA is synchronized with the data on the CS. 

           O     -----------
          -+-   |   CUA w   | -----[CAP]----------+
           A    |local store|                     |
          / \    -----------                    ----------
                                               |   CS     |
                                               |          |
                                                ----------
           O     -----------                      |
          -+-   |  CUA w/o  | -----[CAP]----------+
           A    |local store|
          / \    -----------

3.2.6 Users communicating through different multi-user systems

Users on a multi-user system may need to schedule meetings with user on a different multi user system. The services can communicate using [CAP] or iMIP [RFC-2447]. 

          O     -----------                    ----------
         -+-   |   CUA w   | -----[CAP]-------|   CS     |
          A    |local store|                  |          |
         / \    -----------                    ----------
                                                   |
                                             [CAP] or [iMIP]
                                                   |
          O     -----------                    ----------
         -+-   |  CUA w/o  | -----[CAP]-------|   CS     |
          A    |local store|                  |          |
         / \    -----------                    ----------


 TOC 

4. Important Aspects

There are a number of important aspects of these calendaring documents of which people, especially implementers, should be aware.

4.1 Timezones

The dates and times in components can refer to time zones. These time zones can be defined in some central store, or they may be defined by a user to fit his or her needs. Any user and application should be aware of time zones and time zone differences. New time zones may be added, and others removed. Two different vendors may describe the same time zone differently (such as by using a different name).

4.2 Choice of Transport

There are issues to be aware of in choosing a transport mechanism. The choices are a network protocol, such as CAP, or a store and forward (email) solution.

The use of a network ("on-the-wire") mechanism may require some organizations to make provisions to allow calendaring traffic to traverse a corporate firewall on the required ports. Depending on the organizational culture, this may be a challenging social exercise.

The use of an email-based mechanism exposes innately time sensitive data to unbounded latency. Large or heavily utilized mail systems may experience an unacceptable delay in message receipt.

4.3 Security

See the "Security Considerations" section below.

4.4 Amount of data

In some cases a component may be very large. For instance, some attachments may be very large. Some applications may be low- bandwidth or be limited in the amount of data they can store. The size of the data may be controlled in [CAP], by specifying maximums. In iMIP [RFC-2447] it can be controlled, by restricting the maximum size of the email that the application can download.

4.5 Recurring Components

In iCAL [RFC-2445] one can specify complex recurrence rules for VEVENTs, VTODOs, and VJOURNALs. There is the danger that applications interpret these rules differently. Thus, one must make sure that one is careful with recurrence rules.


 TOC 

5. Open Issues

Many issues are not currently resolved by these protocols, and many desirable features are not yet provided. Some of the more prominent ones follow.

5.1 Scheduling people, not calendars

Meetings are scheduled with people, however people may have many calendars, and may store these calendars in many places. There may also be many routes to contact them. These protocols do not attempt to provide unique access for contacting a single person. Instead, 'calendar addresses' are booked, which may be email addresses or individual calendars. It is up to the users themselves to orchestrate mechanisms to ensure that the bookings go to the right place.

5.2 Administration

These protocols do not address the issues of administering users and calendars on a calendar service. This must be handled by proprietary mechanisms for each implementation.

5.3 Notification

People often wish to be notified of upcoming events, new events, or changes to events. These protocols do not attempt to address these needs in a real-time fashion. Instead, the ability to store alarm information on events is provided, which can be used to provide client-side notification of upcoming events. To organize notification of new or changed events clients will have to poll the data store.


 TOC 

6. Security considerations

6.1 Access Control

There has to be reasonable granularity in the configuration options for access to data through [CAP], so that what should be released to requesters is released, and what shouldn't isn't. Details of handling this are described in [CAP].

6.2 Authentication

Access control must be coupled with a good authentication system, so that the right people get the right information. For [CAP] this means requiring authentication before any database access can be performed, and checking access rights and authentication credentials before releasing information. [CAP] uses SASL for this authentication. In iMIP [RFC-2447], this may present some challenges, as authentication is often not a consideration in store-and-forward protocols.

Authentication is also important for scheduling, in that receivers of scheduling messages should be able to validate the apparent sender. Since scheduling messages are wrapped in MIME [RFC-2045], signing and encryption is available for free. For messages transmitted over mail this is the only available alternative. It is suggested that developers take care in implementing the security features in iMIP [RFC-2447], bearing in mind that the concept and need may be foreign or non-obvious to users, yet essential for the system to function as they might expect.

The real-time protocols provide for the authentication of users, and the preservation of that authentication information, allowing for validation by the receiving end-user or server.

6.3 Using email

Because scheduling information can be transmitted over mail without any authentication information, email spoofing is extremely easy if the receiver is not checking for authentication. It is suggested that implementers consider requiring authentication as a default, using mechanisms such as are described in Section 3 of iMIP [RFC-2447]. The use of email, and the potential for anonymous connections, means that 'calendar spam' is possible. Developers should consider this threat when designing systems, particularly those that allow for automated request processing.

6.4 Other issues

The current security context should be obvious to users. Because the underlying mechanisms may not be clear to users, efforts to make clear the current state in the UI should be made. One example is the 'lock' icon used in some web browsers during secure connections. With both iMIP [RFC-2447] and [CAP], the possibilities of Denial of Service attacks must be considered. The ability to flood a calendar system with bogus requests is likely to be exploited once these systems become widely deployed, and detection and recovery methods will need to be considered.


 TOC 

Authors' Addresses

  Bob Mahoney
  MIT
  E40-327
  77 Massachusetts Avenue
  Cambridge, MA 02139
  US
Phone:  (617) 253-0774
EMail:  bobmah@mit.edu
  
  George Babics
  Steltor
  2000 Peel Street
  Montreal, Quebec H3A 2W5
  CA
Phone:  (514) 733-8500 x4201
EMail:  georgeb@steltor.com
  
  Alex Taler
EMail:  dissent@elea.dhs.org
 TOC 

Appendix A. Acknowledgments

Thanks to the following who have participated in the development of this document:

Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn.


 TOC 

Appendix B. Bibliography

[RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998.

[RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998.

[RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-Based Interoperability Protocol - iMIP", RFC 2447, November 1998.

[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[CAP] Mansour, S., Royer, D., Babics, G., and Hill, P. "Calendar Access Protocol (CAP)" draft-ietf-calsch-cap-04.txt


 TOC 

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

 --------------2A41B6753C0D0F0CEFB5EF75 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-calsch-inetcal-guide-01.txt" Content-Disposition: inline; filename="draft-ietf-calsch-inetcal-guide-01.txt" Content-Transfer-Encoding: 7bit Network Working Group B. Mahoney Internet-Draft MIT Expires: January 16, 2002 G. Babics Steltor A. Taler July 18, 2001 Guide to Internet Calendaring draft-ietf-calsch-inetcal-guide-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 16, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes the various Internet calendaring and scheduling standards and works in progress and the relationships between them. It's intention is to provide a context for these documents, assist in their understanding, and potentially help implementers in the design of their standards based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by Mahoney, et. al. Expires January 16, 2002 [Page 1] Internet-Draft Guide to Internet Calendaring July 2001 these protocols, and could be targets for future work. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 6 2.2 Protocol Requirements . . . . . . . . . . . . . . . . . . . 6 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1 Standalone single-user system . . . . . . . . . . . . . . . 9 3.2.2 Single-user systems communicating . . . . . . . . . . . . . 9 3.2.3 Single-user with multiple CUA . . . . . . . . . . . . . . . 10 3.2.4 Single-user with multiple calendars . . . . . . . . . . . . 10 3.2.5 Users communicating on a multi-user system . . . . . . . . . 11 3.2.6 Users communicating through different multi-user systems . . 11 4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 12 4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 12 4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 12 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Scheduling people, not calendars . . . . . . . . . . . . . . 14 5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security considerations . . . . . . . . . . . . . . . . . . 15 6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 15 6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 15 6.3 Using email . . . . . . . . . . . . . . . . . . . . . . . . 15 6.4 Other issues . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 B. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 Mahoney, et. al. Expires January 16, 2002 [Page 2] Internet-Draft Guide to Internet Calendaring July 2001 1. Introduction The calendaring and scheduling protocols are intended to provide for the needs of individuals attempting to obtain calendaring information and schedule meetings across the Internet, organizations attempting to provide calendaring information on the Internet, as well as organizations looking for a calendaring and scheduling solution to deploy internally. It is the intent of this document to provide a context for the calendar standards and works in progress, assist in their understanding, and potentially help implementers in the design of their Internet calendaring and scheduling systems. Problems not solved by these protocols, as well as security issues to be kept in mind, are discussed at the end of the document. 1.1 Terminology This memo uses much of the same terminology as iCalendar [RFC-2445], iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following definitions are provided as introductory, the definitions in the protocol specifications are the canonical ones. Calendar A collection of events, to-dos, journal entries, etc. A calendar could be the content of a person or a resource's agenda; it could also be a collection of data serving a more specialized need. Calendars are the basic storage containers for calendaring information. Calendar Access Rights A set of rules for a calendar describing who may perform which operations on that calendar, such as reading and writing information. Calendar Service A running server application which provides access to a collection of calendars. Calendar Store (CS) A data store of a calendar service. A calendar service may have several calendar stores, and each store may contain several calendars, as well as properties and components outside of the Mahoney, et. al. Expires January 16, 2002 [Page 3] Internet-Draft Guide to Internet Calendaring July 2001 calendars. Calendar User (CU) An entity (often a human) that accesses calendar information. Calendar User Agent (CUA) Software used by the calendar user that communicates with calendar services to provide the user access to calendar information. Component A piece of calendar data such as an event, a to-do or an alarm. Information about components is stored as properties of those components. Delegator Is a calendar user (sometimes called the delegatee) who has assigned his or her participation in a scheduled calendar component (e.g., VEVENT) to another calendar user (sometimes called the delegate or delegatee). Delegate Is a calendar user (sometimes called the delegatee) who has been assigned participation in a scheduled calendar component (e.g., VEVENT) by one of the attendees in the scheduled calendar component (sometimes called the delegator). An example of a delegate is a team member told to go to a particular meeting. Designate Is a calendar user who is authorized to act on behalf of another calendar user. An example of a designate is an assistant. Local Store A CS which is on the same platform as the CUA. Property A property of a component, such as a description or a start time. Remote Store A CS which is not on the same platform as the CUA. Mahoney, et. al. Expires January 16, 2002 [Page 4] Internet-Draft Guide to Internet Calendaring July 2001 1.2 Concepts and Relationships iCalendar is the language used to describe calendar objects. iTIP is a way to use the language to do scheduling. iMIP is how to do iTIP with email. CAP is a way to use the language, to access a calendar store in real-time. The relationship between the calendaring protocols is similar to that between the email protocols. In those terms iCalendar is like RFC 822, iTIP and iMIP are like SMTP, and CAP is like POP or IMAP. Mahoney, et. al. Expires January 16, 2002 [Page 5] Internet-Draft Guide to Internet Calendaring July 2001 2. Requirements 2.1 Fundamental Needs The following examples illustrate people's and organizations' basic calendaring and scheduling needs: a] A doctor wishes to keep track of all his appointments. Need: Read and manipulate one's own calendar with only one CUA. b] A busy musician wants to maintain her schedule with different devices, such as with an Internet-based agenda or with a PDA. Need: Read and manipulate one's own calendar, possibly with solutions from different vendors. c] A software development team wishes to share agenda information by using a group scheduling product in order to more effectively schedule their time. Need: Share calendar information with users using the same calendar service. d] A teacher wants his students to be able to schedule calendar entries during his office hours. Need: Schedule calendar events, to-dos and journals with users using the same calendar service. e] A movie theater wants to publish its schedule so that prospective customers can easily access it. Need: Share calendar information with users using other calendar services, possibly from different vendors. f] A social club wants to be able to schedule calendar entries effectively with its members. Need: Schedule calendar events and to-dos with users using other calendar services, possibly from different vendors. 2.2 Protocol Requirements Some of the needs can be met with proprietary solutions (a, c, d), but others can not (b, e, f). From these needs we can establish that protocols are required for accessing information in a calendar store, Mahoney, et. al. Expires January 16, 2002 [Page 6] Internet-Draft Guide to Internet Calendaring July 2001 and for scheduling calendar entries. In addition these protocols require a data format for representing calendar information. These roles are filled by the following protocol specifications. - iCalendar [RFC-2445] is the data format iCalendar [RFC-2445] provides data format for representing calendar information which the other protocols can use. iCalendar [RFC-2445] can also be used in other contexts such as a drag and drop format or an export/import format. All the other protocols depend on iCalendar [RFC-2445], so all elements of a standards- based calendaring and scheduling systems will have to interpret iCalendar [RFC-2445]. - iTIP [RFC-2446] is the scheduling protocol iTIP [RFC-2446] describes the messages used to schedule calendar events. These messages are represented in iCalendar [RFC-2445], and have semantics that include such things as being an invitation to a meeting, an acceptance of an invitation or the assignment of a task. iTIP [RFC-2446] messages are used in the scheduling workflow, where users exchange messages in order to organize things such as events and to-dos. CUAs generate and interpret iTIP [RFC-2446] messages at the direction of the calendar user. With iTIP [RFC- 2446] one can create, modify, delete, reply to, counter, and decline counters to the various iCalendar [RFC-2445] components. Furthermore, one can also request the free/busy time of other people. iTIP [RFC-2446] is transport-independent, and has one specified transport bindings: iMIP [RFC-2447] is a binding to email. In addition [CAP] will provide a real-time binding of iTIP [RFC- 2446], allowing CUAs to perform calendar management as well as scheduling over a single connection. - [CAP] is the calendar management protocol [CAP] describes the messages used to manage calendars on a calendar store. These messages use iCalendar [RFC-2445] to describe various components such as events and to-dos. With these messages one can do the operations in iTIP [RFC-2446] and other operations relating to a calendar store, such as search, creating calendars, specifying calendar properties, and being able to specify access rights to one's calendars. Mahoney, et. al. Expires January 16, 2002 [Page 7] Internet-Draft Guide to Internet Calendaring July 2001 3. Solutions 3.1 Examples Returning to the examples of section 2.1, they can be solved using the protocols in the following ways: a] The doctor can use a proprietary CUA with a local store, and perhaps use iCalendar [RFC-2445] as a storage mechanism. This would allow the doctor to easily import his store into another application that supports iCalendar [RFC-2445]. b] The musician who wishes to access her agenda from anywhere can use a [CAP] enabled calendar service accessible through the Internet. She can then use whichever [CAP] clients are available to access the data. A proprietary system could also be employed which provides access through a web-based interface, but the use of [CAP] would be superior in that it would allow the use of third party tools, such as PDA synchronization tools. c] The development team can use a calendar service which supports [CAP] and then each member can use a [CAP]-enabled CUA of their choice. Alternatively, each member could use an iMIP [RFC-2447]-enabled CUA, and they could book meetings over email. This solution has the drawback that it is difficult to examine the other agendas, making organizing meetings more difficult. Proprietary solutions are also available, but they require that all people use clients by the same vendor, and disallow the use of third party applications. d] The teacher can set up a calendar service, and have students book time through any of the iTIP [RFC-2446] bindings. [CAP] provides real-time access, but could require additional configuration. iMIP [RFC-2447] would be the easiest to configure, but may require more email processing. If [CAP] access is provided then determining the state of the teacher's schedule is straightforward. If not, this can be determined through iTIP [RFC-2446] free/busy requests. Non- standard methods could also be employed, such as serving up ICAL, HTML, XML over HTTP. A proprietary system could also be used, but would require that Mahoney, et. al. Expires January 16, 2002 [Page 8] Internet-Draft Guide to Internet Calendaring July 2001 all students be able to use software from a specific vendor. e] For publishing a movie theater's schedule [CAP] provides the most advanced access and search capabilities. It also allows easy integration with its customer's calendar systems. Non-standard methods such as serving data over HTTP could also be employed, but would be harder to integrate with customer's systems. Using a completely proprietary solutions would be very difficult since it would require every user to install and use proprietary software. f] The social club could distribute meeting information in the form of iTIP [RFC-2446] messages. This could be done over email using iMIP [RFC-2447]. Meeting invitations, as well as a full published agenda could be distributed. Alternatively, the social club could provide access to a [CAP] enabled calendar service, however this solution would be more expensive since it requires the maintenance of a server. 3.2 Systems The following diagrams illustrate possible example systems and usage of the protocols. 3.2.1 Standalone single-user system A single user system that does not communicate with other systems need not employ any of the protocols. However, it may use iCalendar [RFC-2445] as a data format in some places. ----------- O | CUA w/ | -+- user |local store| A ----------- / \ 3.2.2 Single-user systems communicating Users with single-user systems may schedule meetings with each other using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use is iMIP [RFC-2447], since since the messages can be held in their mail queue, which we assume to already exist. [CAP] could also be Mahoney, et. al. Expires January 16, 2002 [Page 9] Internet-Draft Guide to Internet Calendaring July 2001 used. O ----------- ----------- O -+- | CUA w/ | -----[IMIP]----- | CUA w/ | -+- user A |local store| Internet |local store| A / \ ----------- ----------- / \ 3.2.3 Single-user with multiple CUA A single user may use more than one CUA to access his or her calendar. The user may use a PDA, a web client, a PC, or some other device, depending an accessibility. Some of these clients may have local stores and others may not. If they do, then they need to ensure that the data on the CUA is synchronized with the data on the CS. ----------- | CUA w | -----[CAP]----------+ |local store| | O ----------- ---------- -+- | CS | A | | / \ ---------- ----------- | | CUA w/o | -----[CAP]----------+ |local store| ----------- 3.2.4 Single-user with multiple calendars A single user may have many independent calendars. One may be work related, another for personal use. The CUA may or may not have a local store. If it does, then it needs to ensure that the data on the CUA is synchronized with the data on both of the CS. ---------- +------------[CAP]------ | CS | | | | O ----------- ---------- -+- | CUA | A | | / \ ----------- | ---------- +------------[CAP]------ | CS | | | ---------- Mahoney, et. al. Expires January 16, 2002 [Page 10] Internet-Draft Guide to Internet Calendaring July 2001 3.2.5 Users communicating on a multi-user system Users on a multi-user system may schedule meetings with each other using [CAP]-enabled CUA and service. The CUA may or may not have a local store. If they do, then they need to ensure that the data on the CUA is synchronized with the data on the CS. O ----------- -+- | CUA w | -----[CAP]----------+ A |local store| | / \ ----------- ---------- | CS | | | ---------- O ----------- | -+- | CUA w/o | -----[CAP]----------+ A |local store| / \ ----------- 3.2.6 Users communicating through different multi-user systems Users on a multi-user system may need to schedule meetings with user on a different multi user system. The services can communicate using [CAP] or iMIP [RFC-2447]. O ----------- ---------- -+- | CUA w | -----[CAP]-------| CS | A |local store| | | / \ ----------- ---------- | [CAP] or [iMIP] | O ----------- ---------- -+- | CUA w/o | -----[CAP]-------| CS | A |local store| | | / \ ----------- ---------- Mahoney, et. al. Expires January 16, 2002 [Page 11] Internet-Draft Guide to Internet Calendaring July 2001 4. Important Aspects There are a number of important aspects of these calendaring documents of which people, especially implementers, should be aware. 4.1 Timezones The dates and times in components can refer to time zones. These time zones can be defined in some central store, or they may be defined by a user to fit his or her needs. Any user and application should be aware of time zones and time zone differences. New time zones may be added, and others removed. Two different vendors may describe the same time zone differently (such as by using a different name). 4.2 Choice of Transport There are issues to be aware of in choosing a transport mechanism. The choices are a network protocol, such as CAP, or a store and forward (email) solution. The use of a network ("on-the-wire") mechanism may require some organizations to make provisions to allow calendaring traffic to traverse a corporate firewall on the required ports. Depending on the organizational culture, this may be a challenging social exercise. The use of an email-based mechanism exposes innately time sensitive data to unbounded latency. Large or heavily utilized mail systems may experience an unacceptable delay in message receipt. 4.3 Security See the "Security Considerations" (Section 6) section below. 4.4 Amount of data In some cases a component may be very large. For instance, some attachments may be very large. Some applications may be low- bandwidth or be limited in the amount of data they can store. The size of the data may be controlled in [CAP], by specifying maximums. In iMIP [RFC-2447] it can be controlled, by restricting the maximum size of the email that the application can download. 4.5 Recurring Components In iCAL [RFC-2445] one can specify complex recurrence rules for VEVENTs, VTODOs, and VJOURNALs. There is the danger that Mahoney, et. al. Expires January 16, 2002 [Page 12] Internet-Draft Guide to Internet Calendaring July 2001 applications interpret these rules differently. Thus, one must make sure that one is careful with recurrence rules. Mahoney, et. al. Expires January 16, 2002 [Page 13] Internet-Draft Guide to Internet Calendaring July 2001 5. Open Issues Many issues are not currently resolved by these protocols, and many desirable features are not yet provided. Some of the more prominent ones follow. 5.1 Scheduling people, not calendars Meetings are scheduled with people, however people may have many calendars, and may store these calendars in many places. There may also be many routes to contact them. These protocols do not attempt to provide unique access for contacting a single person. Instead, 'calendar addresses' are booked, which may be email addresses or individual calendars. It is up to the users themselves to orchestrate mechanisms to ensure that the bookings go to the right place. 5.2 Administration These protocols do not address the issues of administering users and calendars on a calendar service. This must be handled by proprietary mechanisms for each implementation. 5.3 Notification People often wish to be notified of upcoming events, new events, or changes to events. These protocols do not attempt to address these needs in a real-time fashion. Instead, the ability to store alarm information on events is provided, which can be used to provide client-side notification of upcoming events. To organize notification of new or changed events clients will have to poll the data store. Mahoney, et. al. Expires January 16, 2002 [Page 14] Internet-Draft Guide to Internet Calendaring July 2001 6. Security considerations 6.1 Access Control There has to be reasonable granularity in the configuration options for access to data through [CAP], so that what should be released to requesters is released, and what shouldn't isn't. Details of handling this are described in [CAP]. 6.2 Authentication Access control must be coupled with a good authentication system, so that the right people get the right information. For [CAP] this means requiring authentication before any database access can be performed, and checking access rights and authentication credentials before releasing information. [CAP] uses SASL for this authentication. In iMIP [RFC-2447], this may present some challenges, as authentication is often not a consideration in store- and-forward protocols. Authentication is also important for scheduling, in that receivers of scheduling messages should be able to validate the apparent sender. Since scheduling messages are wrapped in MIME [RFC-2045], signing and encryption is available for free. For messages transmitted over mail this is the only available alternative. It is suggested that developers take care in implementing the security features in iMIP [RFC-2447], bearing in mind that the concept and need may be foreign or non-obvious to users, yet essential for the system to function as they might expect. The real-time protocols provide for the authentication of users, and the preservation of that authentication information, allowing for validation by the receiving end-user or server. 6.3 Using email Because scheduling information can be transmitted over mail without any authentication information, email spoofing is extremely easy if the receiver is not checking for authentication. It is suggested that implementers consider requiring authentication as a default, using mechanisms such as are described in Section 3 of iMIP [RFC- 2447]. The use of email, and the potential for anonymous connections, means that 'calendar spam' is possible. Developers should consider this threat when designing systems, particularly those that allow for automated request processing. Mahoney, et. al. Expires January 16, 2002 [Page 15] Internet-Draft Guide to Internet Calendaring July 2001 6.4 Other issues The current security context should be obvious to users. Because the underlying mechanisms may not be clear to users, efforts to make clear the current state in the UI should be made. One example is the 'lock' icon used in some web browsers during secure connections. With both iMIP [RFC-2447] and [CAP], the possibilities of Denial of Service attacks must be considered. The ability to flood a calendar system with bogus requests is likely to be exploited once these systems become widely deployed, and detection and recovery methods will need to be considered. Authors' Addresses Bob Mahoney MIT E40-327 77 Massachusetts Avenue Cambridge, MA 02139 US Phone: (617) 253-0774 EMail: bobmah@mit.edu George Babics Steltor 2000 Peel Street Montreal, Quebec H3A 2W5 CA Phone: (514) 733-8500 x4201 EMail: georgeb@steltor.com Alex Taler EMail: dissent@elea.dhs.org Mahoney, et. al. Expires January 16, 2002 [Page 16] Internet-Draft Guide to Internet Calendaring July 2001 Appendix A. Acknowledgments Thanks to the following who have participated in the development of this document: Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn. Mahoney, et. al. Expires January 16, 2002 [Page 17] Internet-Draft Guide to Internet Calendaring July 2001 Appendix B. Bibliography [RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998. [RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998. [RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-Based Interoperability Protocol - iMIP", RFC 2447, November 1998. [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [CAP] Mansour, S., Royer, D., Babics, G., and Hill, P. "Calendar Access Protocol (CAP)" draft-ietf-calsch-cap-04.txt Mahoney, et. al. Expires January 16, 2002 [Page 18] Internet-Draft Guide to Internet Calendaring July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mahoney, et. al. Expires January 16, 2002 [Page 19] --------------2A41B6753C0D0F0CEFB5EF75-- From owner-ietf-calendar@mail.imc.org Wed Jul 18 10:46:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08583 for ; Wed, 18 Jul 2001 10:46:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IEUQC23000 for ietf-calendar-bks; Wed, 18 Jul 2001 07:30:26 -0700 (PDT) Received: from komarr.local.thibault.org (65-85-145-218.client.dsl.net [65.85.145.218]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IEUPq22996 for ; Wed, 18 Jul 2001 07:30:25 -0700 (PDT) Received: from ecal.com (sergyar.local.thibault.org [192.168.10.20]) by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id KAA30460 for ; Wed, 18 Jul 2001 10:32:40 -0400 Message-ID: <3B559EC2.1020600@ecal.com> Date: Wed, 18 Jul 2001 10:35:46 -0400 From: John Stracke Organization: eCal Corp. User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: mixing mimedirectiory ABNF and XML References: <000001c10f8e$bebe4dc0$a5ec97d4@metaacer> Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f6IEUPq22997 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id f6IEUQC23000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA08583 Greg FitzPatrick wrote: > so that an object might look like this... > > DTOPEN;language=â€XML1.0â€: > > 20020101/20021231 > Yeah, but that's not compatible with how iCalendar is formatted--you've got a property value spanning lines. If you can avoid that, it might work. You'll probably need to subset the XML so that you don't get anything that's not permitted in a property value (not sure what that might be, though). -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Reality is what refuses to go away when I stop| |francis@ecal.com|believing in it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jul 18 17:32:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08211 for ; Wed, 18 Jul 2001 17:32:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IL98t15399 for ietf-calendar-bks; Wed, 18 Jul 2001 14:09:08 -0700 (PDT) Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IL96q15394 for ; Wed, 18 Jul 2001 14:09:06 -0700 (PDT) Received: from metaacer ([212.151.242.202]) by fep03-svc.swip.net with ESMTP id <20010718211029.EFKT25333.fep03-svc.swip.net@metaacer>; Wed, 18 Jul 2001 23:10:29 +0200 From: "Greg FitzPatrick" To: "'John Stracke'" , Subject: RE: mixing mimedirectory ABNF and XML Date: Wed, 18 Jul 2001 23:08:24 +0200 Message-ID: <000001c10fcd$cf004be0$caf297d4@metaacer> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B559EC2.1020600@ecal.com> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f6IL97q15395 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id f6IL98t15399 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA08211 Thanks for pointing that out John. The example should of course look like this: (and the second line should be indented with one white-space which my stupid Outlook refuses to let me do at this time of night. DTOPEN;language=”XML1.0”: 20020101/ 20021231 John wrote: Yeah, but that's not compatible with how iCalendar is formatted--you've got a property value spanning lines. If you can avoid that, it might work. You'll probably need to subset the XML so that you don't get anything that's not permitted in a property value (not sure what that might be, though). -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Reality is what refuses to go away when I stop| |francis@ecal.com|believing in it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jul 18 17:56:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14100 for ; Wed, 18 Jul 2001 17:56:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ILSLr16105 for ietf-calendar-bks; Wed, 18 Jul 2001 14:28:21 -0700 (PDT) Received: from komarr.local.thibault.org (65-85-145-218.client.dsl.net [65.85.145.218]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ILSKq16099 for ; Wed, 18 Jul 2001 14:28:20 -0700 (PDT) Received: from ecal.com (sergyar.local.thibault.org [192.168.10.20]) by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id RAA12498 for ; Wed, 18 Jul 2001 17:30:36 -0400 Message-ID: <3B5600B8.9060703@ecal.com> Date: Wed, 18 Jul 2001 17:33:44 -0400 From: John Stracke Organization: eCal Corp. User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: mixing mimedirectory ABNF and XML References: <000001c10fcd$cf004be0$caf297d4@metaacer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg FitzPatrick wrote: > Thanks for pointing that out John. The example should of course look > like this: [...] > > DTOPEN;language="XML1.0": 20020101/ > 20021231 > OK, then. Yeah, that might be reasonable--take the property value and pass it through an XML parser. 'Course, I might be biased, because I'm already using an XML parser in my app, so it doesn't seem like any particular burden to me. ;-) You might consider going for a simplified subset of XML--e.g., forbidding the internal DTD subset, the doctype, etc. That'll make it easier for people who don't have any need for a full-power XML parser. An XML parser isn't a large hit in a desktop or server app; but I could see SKiCal being used in some kind of embedded system--say, to turn on the Open sign during opening hours. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Reality is what refuses to go away when I stop| |francis@ecal.com|believing in it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jul 18 19:22:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03272 for ; Wed, 18 Jul 2001 19:22:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6IMrcu18527 for ietf-calendar-bks; Wed, 18 Jul 2001 15:53:38 -0700 (PDT) Received: from server1.egenconsulting.com (nbppp5-254.gtnetworks.net [216.143.5.254]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IMrZq18515 for ; Wed, 18 Jul 2001 15:53:35 -0700 (PDT) To: John Stracke Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: CAP - Mutual Trust Model X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: pregen@egenconsulting.com Date: Wed, 18 Jul 2001 18:53:28 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 07/18/2001 06:53:36 PM, Serialize complete at 07/18/2001 06:53:36 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 007DD43785256A8D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007DD43785256A8D_= Content-Type: text/plain; charset="us-ascii" Anything that will hold up finishing this first draft should be considered "back burner" unless the draft won't work without it. So, I vote for excluding the trust model till the next flavor of the draft. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 John Stracke Sent by: owner-ietf-calendar@mail.imc.org 07/17/01 11:28 AM To: CalSched IETF cc: Subject: Re: CAP - Mutual Trust Model Steve Mansour wrote: >One of the issues we need to nail is a question about whether or not >there is a mutual trust model between CAP servers. My recommendation is >that we to NOT try to put anything like this in the first pass of CAP. >First, it will be complicated. > Also risky. I think you're right; we should put it off. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"The avalanche has already started. It is too| |francis@ecal.com|late for the pebbles to vote." --Kosh | \==============================================================/ --=_alternative 007DD43785256A8D_= Content-Type: text/html; charset="us-ascii"
Anything that will hold up finishing this first draft should be considered "back burner" unless the draft won't work without it.  So, I vote for excluding the trust model till the next flavor of the draft.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


John Stracke <francis@ecal.com>
Sent by: owner-ietf-calendar@mail.imc.org

07/17/01 11:28 AM

       
        To:        CalSched IETF <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: CAP - Mutual Trust Model




Steve Mansour wrote:

>One of the issues we need to nail is a question about whether or not
>there is a mutual trust model between CAP servers.  My recommendation is
>that we to NOT try to put anything like this in the first pass of CAP.
>First, it will be complicated.
>
Also risky.  I think you're right; we should put it off.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"The avalanche has already started. It is too|
|francis@ecal.com|late for the pebbles to vote." --Kosh        |
\==============================================================/

--=_alternative 007DD43785256A8D_=-- From owner-ietf-calendar@mail.imc.org Thu Jul 19 00:40:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06234 for ; Thu, 19 Jul 2001 00:40:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6J4MWv00482 for ietf-calendar-bks; Wed, 18 Jul 2001 21:22:32 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6J4MVq00478 for ; Wed, 18 Jul 2001 21:22:31 -0700 (PDT) Received: (qmail 338534 invoked from network); 19 Jul 2001 04:18:38 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 19 Jul 2001 04:18:38 -0000 Message-ID: <3B565EBB.6A355883@kasey.umkc.edu> Date: Wed, 18 Jul 2001 23:14:51 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5 i586) X-Accept-Language: en MIME-Version: 1.0 To: George Babics , ietf-calendar@imc.org Subject: Re: Last Call For "Guide To Internet Calendaring" References: <3B559078.AB08DD9B@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit If the AUTHORIZE primitive would be accepted, "A calendar store may implement anonymous designation with SPKI Authorization Certificates." might be added to the definition of Designate George Babics wrote: > > I've submitted the latest version to the ietf. > > This is a last call for the working group. It gives > you two weeks for your comments. If all goes well > it will be submitted to the IESG as an informational > RFC. > > Here it is. > (I've made changes based on your comments.) > > Designate > > Is a calendar user who is authorized to act on behalf of > another calendar user. An example of a designate is an > assistant. From owner-ietf-calendar@mail.imc.org Thu Jul 19 13:33:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17894 for ; Thu, 19 Jul 2001 13:33:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JH0S526706 for ietf-calendar-bks; Thu, 19 Jul 2001 10:00:28 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JH0Qq26702 for ; Thu, 19 Jul 2001 10:00:26 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6JH0LB08699 for ; Thu, 19 Jul 2001 10:00:21 -0700 (PDT) Received: from netscape.com ([205.217.228.91]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGQCKK00.5FM for ; Thu, 19 Jul 2001 10:00:20 -0700 Message-ID: <3B5711E9.7AA8A254@netscape.com> Date: Thu, 19 Jul 2001 09:59:21 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP issue: Fallback/fanout to iTIP Content-Type: multipart/mixed; boundary="------------8890439AB7CCB50661D70E1C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8890439AB7CCB50661D70E1C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit - "Fallback/fanout to iTIP" concerns: If a CAP request must get turned into iTIP then some extra coding must occur (ie: rewriting the proper ATTENDEE and ORGANIZER values from cap://... to mailto:.. ). Since this may happen anywhere down stream from the originating CS, it is not guaranteed that the mapping/rewrites are accurate or correct; they are 'assumed' to be usable ("or the request is bounced back."). Unfortunately correctness is only positively done at the starting point and not @ Yahoo on the way to Lotus. There are also cases like signed or encrypted data that would prevent this from being either doable or run the risk of voiding the signature. (from Bruce) I think that, in general, it is too difficult of a problem for us to provide instructions in CAP as to how a given implementation can guarantee a correct mapping between an email address (a mailto: calid) and a CAP calid. That responsibility lies at some point between a messaging server and a calendar server and will likeley involve a directory server. I think we should explicitly not attempt solve that problem in CAP and leave this to implementations. Thoughts on this? -Steve --------------8890439AB7CCB50661D70E1C Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------8890439AB7CCB50661D70E1C-- From owner-ietf-calendar@mail.imc.org Thu Jul 19 13:57:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25187 for ; Thu, 19 Jul 2001 13:57:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JHHhA27547 for ietf-calendar-bks; Thu, 19 Jul 2001 10:17:43 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JHHfq27543 for ; Thu, 19 Jul 2001 10:17:41 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6JHHbB13814 for ; Thu, 19 Jul 2001 10:17:37 -0700 (PDT) Received: from netscape.com ([205.217.228.91]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGQDDB00.8CJ for ; Thu, 19 Jul 2001 10:17:35 -0700 Message-ID: <3B5715F8.322A4506@netscape.com> Date: Thu, 19 Jul 2001 10:16:40 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP issue: workflow path may not be a true path Content-Type: multipart/mixed; boundary="------------DA6ECF6EC67EF6C37C5C3856" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DA6ECF6EC67EF6C37C5C3856 Content-Type: multipart/alternative; boundary="------------46FA3CD04F016C171B29AD48" --------------46FA3CD04F016C171B29AD48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here are the issues: The workflow path may not be a true path: The iTIP workflow path was a just that; a path (msg flow out followed same logical flow back). In CAP, if 'rerouting' over iTIP occurs then the path is now a loop (CUA1->CS1->iTIP to MUA2/CUA2->MUA1/(CUA1?). The last leg of getting iTIP/iMIP replies from the MUA1 to CUA1 so it can stuff them into CS1 in the "proper place" is just handwaved (or "left up to the user or their tools to do"). There is no clear why/how CUA1 would stuff in iTIP/iMIP messages into own queue instead of having CUA1 watch the incoming MUA1 queue for iTIP msgs and pulling them in or having CS1 rewrite the address so that msgs return to it directly. Users may be confused (at best) or not aware of (at worse) any kind of signature msgs / warnings that they may see on their receiving end. Email may still be ok in that if my MUA can see the sig then it tells me "This msg was signed by Doug Royer and its valid". He does not think there is any usefulness in seeing "This request was signed and I, your trusted CS says its valid!" (esp. if we allow downstream servers to sign 'on your behalf' or 'at your behest' via some TBD mechanism). Is data integrity within the CS necessary? Do we trust the CS to enforce integrity or not. In the interest of moving CAP along, I'm going to recommend that the CS does not attempt to do this sort of data integrity checking. I think it's a great idea. I think it's a good goal. My gut tells me * we will be spending a *long* time trying to nail it in the first version of CAP * I think trying to work out the signing and identity mapping between different vendors and even between the same vendors tools but at different company sites is going to be a difficult thing to nail. * as a practical matter, we all receive many email messages that are not authenticated and that affect how we schedule our time. I just got one, "sman, we need to review your department budget. Let's meet Monday at 11:30...". I think CAP will be extremely useful even in the absence of this data integrity checking. Implementations can do it on their own and maybe even write up supplemental drafts to tell us how to do it for CAP. I think we should just acknowledge this as a possible security problem and move forward. Thoughts? -Steve --------------46FA3CD04F016C171B29AD48 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Here are the issues:

    The workflow path may not be a true path:

The iTIP workflow path was a just that; a path (msg flow out followed same logical flow back).  In CAP, if 'rerouting' over iTIP occurs then the path is now a loop (CUA1->CS1->iTIP to MUA2/CUA2->MUA1/(CUA1?).  The last leg of getting iTIP/iMIP replies from the MUA1 to CUA1 so it can stuff them into   CS1 in the "proper place" is just handwaved (or "left up to the user or their tools to do"). There is no clear why/how CUA1 would stuff in iTIP/iMIP messages into own queue instead of having CUA1 watch the incoming MUA1 queue for iTIP msgs and pulling them in or having CS1 rewrite the address so that msgs return to it directly.
Users may be confused (at best) or not aware of (at worse) any kind of signature msgs / warnings that they may
see on their receiving end.  Email may still be ok in that if my
MUA can see the sig then it tells me "This msg was signed by Doug Royer and its valid".  He does not think there is any usefulness in seeing "This request   was signed and I, your trusted CS says its valid!" (esp. if we allow downstream servers to sign 'on your behalf' or 'at your behest' via some TBD mechanism).  Is data integrity within the CS necessary? Do we trust the CS to enforce integrity or not.
In the interest of moving CAP along, I'm going to recommend that the CS does not attempt to do this sort of data integrity checking. I think it's a great idea. I think it's a good goal.  My gut tells me
  • we will be spending a *long* time trying to nail it in the first version of CAP
  • I think trying to work out the signing and identity mapping between different vendors and even between the same vendors tools but at different company sites is going to be a difficult thing to nail.
  • as a practical matter, we all receive many email messages that are not authenticated and that affect how we schedule our time. I just got one, "sman, we need to review your department budget. Let's meet Monday at 11:30...".
I think CAP will be extremely useful even in the absence of this data integrity checking. Implementations can do it on their own and maybe even write up supplemental drafts to tell us how to do it for CAP.

I think we should just acknowledge this as a possible security problem and move forward.

Thoughts?

-Steve --------------46FA3CD04F016C171B29AD48-- --------------DA6ECF6EC67EF6C37C5C3856 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------DA6ECF6EC67EF6C37C5C3856-- From owner-ietf-calendar@mail.imc.org Thu Jul 19 14:10:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29645 for ; Thu, 19 Jul 2001 14:10:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JHd7G28473 for ietf-calendar-bks; Thu, 19 Jul 2001 10:39:07 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JHd5q28467 for ; Thu, 19 Jul 2001 10:39:05 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6JHd1v07922 for ; Thu, 19 Jul 2001 10:39:02 -0700 (PDT) Received: from netscape.com ([205.217.228.91]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGQED100.KM4 for ; Thu, 19 Jul 2001 10:39:01 -0700 Message-ID: <3B571AFE.4555B54B@netscape.com> Date: Thu, 19 Jul 2001 10:38:06 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP issue: JIT signing/encryption Content-Type: multipart/mixed; boundary="------------DB1ED965B709372BF41F9A4D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DB1ED965B709372BF41F9A4D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit - JIT signing/encryption: For some cases we may wind up having signing/encryption done by 'downstream' CS's as the request routes thru. ie: Paul @ MIT sent a REQUEST to his CS w/your CalID as 1 TARGET. He sends the data unsigned/encrypted to his CS. It sees your TARGET and by some TBD CS policy it decides that the data must be signed/encrypted so that it can go over, say, iMIP. His CS does not have his key so it simply uses its own. (Additionally, if his server fanned it out to outside the firewall before this happens, the signer/encryptor is not even his CS). So the first CS that can sign it does and then that is trackable all the way to you [after resigning by each subsequent CS in the flow path is done] I meant to include this in my last message. Again, my recommendation is that CAP version 1 does not address this problem. Bruce is probably ready to shoot me at this point. Just to be clear, I think these are great scenarios to consider, they are great things to solve going forward, but I feel like trying to deal with a complex issue such as this is just too much for CAP 1. Do others feel this way? Does anyone feel like this is an issue we MUST solve in CAP 1? -Steve --------------DB1ED965B709372BF41F9A4D Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------DB1ED965B709372BF41F9A4D-- From owner-ietf-calendar@mail.imc.org Thu Jul 19 14:10:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29726 for ; Thu, 19 Jul 2001 14:10:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JHWXa28234 for ietf-calendar-bks; Thu, 19 Jul 2001 10:32:33 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JHWVq28230 for ; Thu, 19 Jul 2001 10:32:31 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6JHWRv06563 for ; Thu, 19 Jul 2001 10:32:27 -0700 (PDT) Received: from netscape.com ([205.217.228.91]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGQE2000.IOU for ; Thu, 19 Jul 2001 10:32:25 -0700 Message-ID: <3B571971.94819265@netscape.com> Date: Thu, 19 Jul 2001 10:31:29 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP issue: CS does not preserve data integrity on multipart/signed Content-Type: multipart/mixed; boundary="------------DDFA452426B85FA7D9F51D8E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DDFA452426B85FA7D9F51D8E Content-Type: multipart/alternative; boundary="------------B69C7E50D51DDD7420C19A77" --------------B69C7E50D51DDD7420C19A77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit - CS does not preserve data integrity on multipart/signed. Explanation/example: someone can store a multipart/signed vEvent on their own calendar via CAP but when the owner goes to read it back the sig is gone (or its been 'resigned' by the CS). For multipart/encrypted, CS's may decrypt and later reencrypt data back but it data security/preservation is not available. A by-product of this is that when an invite arrives in your calendar scheduling queue all you will be able to tell is that your server says the data got there in some safe manner; no info as to the original signature, etc. As such anyone with a valid signature can send the calendar owner entries and the CAP server will say this was signed and CAP verified it was". In eMail you can see the senders signature (somewhere in the UI); with CAP you have no visual way to see _WHO_ signed it. Another way to look at this is: you sign and save an entry. Your AA or someone else w/access to it comes in and modifies it. You later go back and reopen the entry but you will have no visual clue as to its been changed by someone else since _I_ signed and saved it since my CAP server only says "This was really signed when it was saved". Is this OK? At the risk of sounding like a broken record... again, I think it is a good goal to try to solve this, but not for the first release of CAP. I think the lifetime of a VEVENT is very different from that of a mail message. A when a mail message leaves the senders CUA, it arrives at a recipient's inbox. Once there, the recipient may move it into different folders or delete it or reply to it. But the sender never resends a mail message that literally replaces the one they sent you earlier. However, when an Organizer sends you a VEVENT, it is very likely that it will change over time -- it may get updated with Attendees partstat values, the Organizer may change the time or location, etc. So it is common to re-write and update a VEVENT. For me, this fundamental difference makes it much less clear how to store signed calendar events into a calstore -- especially since the event will commonly be updated by admins and potentially other people with write access to the vevent. At the very least, I would say: * storing a vevent as a signed calendar, component, or parameter entity is going to be an edge case * to describe how this should be handled in CAP is going to very hard (at best) or next to impossible (my bet). If someone has an enlightened idea on how to solve this problem --AND you feel that it is something that MUST be done in the first version of CAP, please speak up. Otherwise, I propose that we acknowledge this is an issue with the first version of CAP to be addressed at some point in the future, then move on. -Steve --------------B69C7E50D51DDD7420C19A77 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit - CS does not preserve data integrity on multipart/signed.

  Explanation/example:  someone can store a multipart/signed vEvent on their
  own calendar via CAP but when the owner goes to read it back the sig is
  gone (or its been 'resigned' by the CS).  For multipart/encrypted, CS's may
  decrypt and later reencrypt data back but it data security/preservation is
  not available.  A by-product of this is that when an invite arrives in your
  calendar scheduling queue all you will be able to tell is that your server
  says the data got there in some safe manner; no info as to the original
  signature, etc.  As such anyone with a valid  signature can send the
  calendar owner  entries and the CAP server will say this was signed and CAP
  verified it was".  In eMail you can see the senders signature (somewhere in
  the UI); with CAP you have no visual way to see _WHO_ signed it.

  Another way to look at this is: you sign and save an entry.  Your AA or
  someone else w/access to it comes in and modifies it. You later go back and
  reopen the entry but you will  have no visual clue as to its been changed
  by someone else since _I_ signed and saved it since my CAP server only says
  "This was really signed when it was saved".  Is this OK?

At the risk of sounding like a broken record... again, I think it is a good goal to try to solve this, but not for the first release of CAP.  I think the lifetime of a VEVENT is very different from that of a mail message. A when a mail message leaves the senders CUA, it arrives at a recipient's inbox. Once there, the recipient may move it into different folders or delete it or reply to it. But the sender never resends a mail message that literally replaces the one they sent you earlier.  However, when an Organizer sends you a VEVENT, it is very likely that it will change over time -- it may get updated with Attendees partstat values, the Organizer may change the time or location, etc. So it is common to re-write and update a VEVENT.  For me, this fundamental difference makes it much less clear how to store signed calendar events into a calstore -- especially since the event will commonly be updated by admins and potentially other people with write access to the vevent.

At the very least, I would say:

  • storing a vevent as a signed calendar, component, or parameter entity is going to be an edge case
  • to describe how this should be handled in CAP is going to very hard (at best) or next to impossible (my bet).
If someone has an enlightened idea on how to solve this problem --AND you feel that it is something that MUST be done in the first version of CAP, please speak up.

Otherwise, I propose that we acknowledge this is an issue with the first version of CAP to be addressed at some point in the future, then move on.

-Steve --------------B69C7E50D51DDD7420C19A77-- --------------DDFA452426B85FA7D9F51D8E Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------DDFA452426B85FA7D9F51D8E-- From owner-ietf-calendar@mail.imc.org Thu Jul 19 17:48:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21978 for ; Thu, 19 Jul 2001 17:48:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JKmTj05946 for ietf-calendar-bks; Thu, 19 Jul 2001 13:48:29 -0700 (PDT) Received: from amsmta02-svc.chello.nl (mail-out.chello.nl [213.46.240.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JKmSq05942 for ; Thu, 19 Jul 2001 13:48:28 -0700 (PDT) Received: from khazad-dum.copa.nl ([212.187.86.233]) by amsmta02-svc.chello.nl (InterMail vK.4.03.02.00 201-232-124 license dd4a379df8e387594186908c65258374) with ESMTP id <20010719204749.OTUB10337.amsmta02-svc@khazad-dum.copa.nl> for ; Thu, 19 Jul 2001 22:47:49 +0200 Received: from martijn by khazad-dum.copa.nl with local (Exim 3.22 #1 (Debian)) id 15NKkt-0003FS-00 for ; Thu, 19 Jul 2001 22:50:43 +0200 Date: Thu, 19 Jul 2001 22:50:43 +0200 From: Martijn van Beers To: CalSched IETF Subject: Re: CAP issue: Fallback/fanout to iTIP Message-ID: <20010719225043.A12481@khazad-dum.copa.nl> Mail-Followup-To: Martijn van Beers , CalSched IETF References: <3B5711E9.7AA8A254@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B5711E9.7AA8A254@netscape.com> User-Agent: Mutt/1.3.18i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jul 19, 2001 at 09:59:21AM -0700, Steve Mansour wrote: > - "Fallback/fanout to iTIP" concerns: > > If a CAP request must get turned into iTIP then some extra coding must > occur Shouldn't that be iMIP, not iTIP, or am I misunderstanding all of this completely? Martijn From owner-ietf-calendar@mail.imc.org Thu Jul 19 20:29:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04485 for ; Thu, 19 Jul 2001 20:29:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JNwLJ12029 for ietf-calendar-bks; Thu, 19 Jul 2001 16:58:21 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JNwJq12024 for ; Thu, 19 Jul 2001 16:58:19 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6JNwFv21384 for ; Thu, 19 Jul 2001 16:58:15 -0700 (PDT) Received: from netscape.com ([205.217.228.123]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGQVX100.JIL; Thu, 19 Jul 2001 16:58:13 -0700 Message-ID: <3B5773DB.720F619@netscape.com> Date: Thu, 19 Jul 2001 16:57:15 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Martijn van Beers CC: CalSched IETF Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> Content-Type: multipart/mixed; boundary="------------516CC62DD43111FB04C6D855" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------516CC62DD43111FB04C6D855 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martijn van Beers wrote: > On Thu, Jul 19, 2001 at 09:59:21AM -0700, Steve Mansour wrote: > > - "Fallback/fanout to iTIP" concerns: > > > > If a CAP request must get turned into iTIP then some extra coding must > > occur > > Shouldn't that be iMIP, not iTIP, or am I misunderstanding all of > this completely? yes. Sometimes we use those two interchangeably. It should be something like a CAP request gets translated into an iTIP equivalent and sent via iMIP. But I think you get the idea. -Steve --------------516CC62DD43111FB04C6D855 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------516CC62DD43111FB04C6D855-- From owner-ietf-calendar@mail.imc.org Thu Jul 19 20:32:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05456 for ; Thu, 19 Jul 2001 20:32:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6K0BgQ12461 for ietf-calendar-bks; Thu, 19 Jul 2001 17:11:42 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K0Beq12457 for ; Thu, 19 Jul 2001 17:11:40 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6K0BYv24551 for ; Thu, 19 Jul 2001 17:11:34 -0700 (PDT) Received: from netscape.com ([205.217.228.123]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGQWGK00.3IL for ; Thu, 19 Jul 2001 17:09:56 -0700 Message-ID: <3B57769A.D06440A7@netscape.com> Date: Thu, 19 Jul 2001 17:08:58 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP Issue: Decreed VCARs Content-Type: multipart/mixed; boundary="------------6A2AE88EECCDF81D5A30A952" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6A2AE88EECCDF81D5A30A952 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All, I'm trying to determine if there is any detectable difference between a decreed vcar versus any other vcar. If there is no difference between them, I'm wondering how we would know a vcar is decreed. Are they declared differently than any others? Is there anything about their data content that distinguishes them from any other vcar? What does a query for the decreed vcars look like? If you have an idea about how they work, please reply and help me out. If no one has good answers to these questions, and since decreed vcars are a "MAY" implement, I think we should we drop them. Any comments on that? -Steve --------------6A2AE88EECCDF81D5A30A952 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------6A2AE88EECCDF81D5A30A952-- From owner-ietf-calendar@mail.imc.org Thu Jul 19 20:33:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05779 for ; Thu, 19 Jul 2001 20:33:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6K06ed12275 for ietf-calendar-bks; Thu, 19 Jul 2001 17:06:40 -0700 (PDT) Received: from amsmta04-svc.chello.nl (mail-out.chello.nl [213.46.240.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K06cq12270 for ; Thu, 19 Jul 2001 17:06:38 -0700 (PDT) Received: from khazad-dum.copa.nl ([212.187.86.233]) by amsmta04-svc.chello.nl (InterMail vK.4.03.02.00 201-232-124 license dd4a379df8e387594186908c65258374) with ESMTP id <20010720000651.PGWI7440.amsmta04-svc@khazad-dum.copa.nl> for ; Fri, 20 Jul 2001 02:06:51 +0200 Received: from martijn by khazad-dum.copa.nl with local (Exim 3.22 #1 (Debian)) id 15NNqk-0003VZ-00 for ; Fri, 20 Jul 2001 02:08:58 +0200 Date: Fri, 20 Jul 2001 02:08:58 +0200 From: Martijn van Beers To: CalSched IETF Subject: Re: CAP issue: Fallback/fanout to iTIP Message-ID: <20010720020858.A13480@khazad-dum.copa.nl> Mail-Followup-To: Martijn van Beers , CalSched IETF References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B5773DB.720F619@netscape.com> User-Agent: Mutt/1.3.18i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Jul 19, 2001 at 04:57:15PM -0700, Steve Mansour wrote: > Martijn van Beers wrote: > > > If a CAP request must get turned into iTIP then some extra coding must > > > occur > > Shouldn't that be iMIP, not iTIP, or am I misunderstanding all of > > this completely? > yes. Sometimes we use those two interchangeably. It should be something like > a CAP request gets translated into an iTIP equivalent and sent via iMIP. But > I think you get the idea. Hmm, does that mean CAP scheduling messages aren't (encapsulated) iTIP messages? Martijn From owner-ietf-calendar@mail.imc.org Fri Jul 20 05:50:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11729 for ; Fri, 20 Jul 2001 05:50:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6K9YQS18904 for ietf-calendar-bks; Fri, 20 Jul 2001 02:34:26 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K9YOq18899 for ; Fri, 20 Jul 2001 02:34:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04699; Fri, 20 Jul 2001 05:33:27 -0400 (EDT) Message-Id: <200107200933.FAA04699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-inetcal-guide-01.txt Date: Fri, 20 Jul 2001 05:33:26 -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Guide to Internet Calendaring Author(s) : B. Mahoney, G. Babics, A. Taler Filename : draft-ietf-calsch-inetcal-guide-01.txt Pages : 19 Date : 19-Jul-01 This document describes the various Internet calendaring and scheduling standards and works in progress and the relationships between them. It's intention is to provide a context for these documents, assist in their understanding, and potentially help implementers in the design of their standards based calendaring and scheduling systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-inetcal-guide-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-inetcal-guide-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-inetcal-guide-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719145501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-inetcal-guide-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-inetcal-guide-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Fri Jul 20 10:26:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18299 for ; Fri, 20 Jul 2001 10:26:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KECkS29569 for ietf-calendar-bks; Fri, 20 Jul 2001 07:12:46 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KECjq29565 for ; Fri, 20 Jul 2001 07:12:45 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6KEEE827766 for ; Fri, 20 Jul 2001 10:14:15 -0400 Message-ID: <3B583CB5.9040401@ecal.com> Date: Fri, 20 Jul 2001 10:14:13 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP issue: CS does not preserve data integrity on multipart/signed References: <3B571971.94819265@netscape.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: > Otherwise, I propose that we acknowledge this is an issue with the > first version of CAP to be addressed at some point in the future, then > move on. > I agree. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"It takes a special kind of guy to rig an | |francis@ecal.com|election and then lose." --Cecil Adams | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Jul 20 12:25:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18698 for ; Fri, 20 Jul 2001 12:25:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KFvEq09001 for ietf-calendar-bks; Fri, 20 Jul 2001 08:57:14 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KFvDq08997 for ; Fri, 20 Jul 2001 08:57:13 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA09352; Fri, 20 Jul 2001 11:57:03 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6KFuxv22991; Fri, 20 Jul 2001 11:56:59 -0400 (EDT) Message-ID: <3B5854CB.790AF4AD@steltor.com> Date: Fri, 20 Jul 2001 11:56:59 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: pregen@egenconsulting.com, sman@netscape.com Subject: Updated CAP Draft Content-Type: multipart/mixed; boundary="------------8561EC5753705279E5D42DF4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8561EC5753705279E5D42DF4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Here is the latest version of CAP. It is the one that was submitted to the IETF. The changes that we made were: - Use rfc2629 to write the draft using xml. It permits us to easily generate the text format and also an HTML format of the document. (The HTML version should make CAP much easier to read.) - Added a few examples - Clarified some sections - Fixed some errors - Moved GENERATEUID and CALIDEXPAND to "Transfer Protocol Commands" section George --------------8561EC5753705279E5D42DF4 Content-Type: application/zip; name="draft-ietf-calsch-cap-05.zip" Content-Disposition: inline; filename="draft-ietf-calsch-cap-05.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAGhU9CoqeHVjDtUAAEwdBAAdAAAAZHJhZnQtaWV0Zi1jYWxzY2gtY2FwLTA1 Lmh0bWzsXFtz28aSfk+V/8MUTu2JVStRIkVRki+qokkqZlaiFJJy1pU6D0NgSOIYBBBcJPNs 7X/f7p4BMANCAK04W3k4qsTiBf1Nd09f56J362TjXb1bC+5cvUvcxBNXA+4J3+ER69u2iGN2 HwVJYAceez3o3x+8O5ZPvfrh3Wz++WbEkm0o3v+YiK/JsR3HP8IXDH5a9BT7HwaEQfSG/e3y 8gR+3rJl4CdHsfsv8YZ1OuHXt8xzfXG0Fu5qnWQf0TNP6qNF4DlvGeIfcc9d+W9YhF+8lePk P0Sz5BvX275ha+E9isS1+SHjkcu9QxZzPz6KReQu2f8qDpcuyMk3OpM9+jGYbF/sMnnxUiZf xmnYsoNwS4AarycnOwptnwBjjUM+isjhPgxor3lkBzjmXlzA2BserVz/yBNLVIPYvM0+iZRm 8CP1vOeWCU7x2+xrsKdvw0u9Fur3G6nCSFSykWnxlH70MQK7QsnG/Ld7u2r+Hhr+eKqNLBkz p7e3Y4ryo2+2qI/dBkPqvgh2PmxhIBGRhr6kn10zNdEVpDYIoEvwt+xRuVQShNpIPE3WQXSk bOIlXvGdpi3n5Tk2zCBh2GIXbbFeNS/kqv8GDOVLfQCWo1HUSiJAWAbR5g1Lw1BENo9FFft1 Zn87YzNAYTPk4/DljD+6sZsI5zlnMNX5DeLs2sCfwn4pp/wpvP8JjLfQXjo546bjVuQ5R9hB xBM3AM/0A7+exU3gczvQWVoJXzwCPyXmNU6BJsDiQpOo4LpyNKnKy/BrLtP0elBIZGT3b5bo /1OeZ6RZB8lcD3fVc+SD6XBvz1kqyVXIk0n4neepSrZ3x3GylSXlMRWi8GIROFu2WJGc7y0l qIUiwTsZXS3G0WS194/qvZxoi6m3MvJZCJvwBVSliyCCJPXeAhJbeF7IHcf1V/n7OOQ2ve9Y 7Ml1kvV76xS+kjn3vdU+o5FX/nuLCg4LCucI/nc0ftWQ2XO28BMRPYd29Y6zdSSWQAfVh8UG N/3Z7L1F/ghfosLYktvivZVNijEZFitpiaF2ARloF1d/9xdx+HZ+N5Av3h0vrt4dIyT84vAA cH6cOPgPvUL9FIpS/PZ6/2HtrbSTXB9XJkr75KQGplOCacv5ilT2f29B9rdIy5kSTxEt13g2 57bH4/i9JesQ62oikqcg+sJ+hX8Al/0UBWkoJf5WqFmL3YLSgzQqNPY9WByjbfgiORpGfJm8 jDcQM7Y5+qB773EA+74sjr6GbiTiN+xn7qc82kJXdMg6Jyedl3E7bLFpsBXfWY+Zgb+EI532 r8DPTy32gS9cO/7rsDRLhJcEf6E5u2+xj67n/XUYuoV33F6nsUiSmI39OHGTNBEsWP51eJwL e+3DI6vtX4enn1NvC9GEIkrbYEvlo+Kzd0WGctzHchreP1Nm+Vlmyv88pVRJyRASkJ8xSGtY VuOCGJJcGYkVePvDLGbKUix2JIs6e9kClnXlYOY4ckWyPLK5F9tr+BUenZzV8KYxkpdtdW1C xkgH8zLQr08hIvAkjcG8WbJ2Y3YrNgEUcKeIHsI/c/zQCex0A9UPg9fAuZnr4BMHv3B9tkw9 D0T3se/hvo1FQ7IG5XksjAJsCAOfRpoJG4tZ6JfwHZT3nZNOr/XuOMxGNUeAQSPAUsk/Y0bx LHJ22MiHnlyAnP4KGOfxF3YdRMDF6/Fofn0AWVUi8fhQ8gxvM9AVVhRx69UPkwB8PVnzhAWA HakvoN/fghxxwBw3TiJ3gRFhlyEe77DeJBVNugaBDuxAeR0xDoN+dTfpBuWM3a9YoidrGAF5 R34WAlpLh0OTfcgiEXpgBvAKKINFHHgCm+/FVomh8YgTtmWJuxEg7jiRU8dDmKEQzAWlDxhE P7bDbQyjLEUkcGI38CAaFw4Hz9vQ6r/6AUbaqPFAgz5SWFS3gWkA/AqKj7hlaQqZw+x5oFCU 0E6jCE2sPKwNQCApJ68FkXgCxKrU/nGdJOGb4+Onp6cW+k0riFbH+OK47TpHfAFTxW2Yg+Rr 8uPV/s9iTd16hs2S7c/W3Ame2BAKKxvyqitewHBMGC1cw6/mUntglzU3LvP0BPmUCSr2GDhZ udpT5NL7B/maNBi+awvd9YvvXg8O2Fz3tFlgA3db9hqD/UGL9WHEKT4as6mASPMoHGOYvlKv glcDSM3WB+ZSyEE7kt+iuYEthyLakF8XOA/AABA/HJAlJ64HIW/n+1c/9FdobvBcnx6U84Vj /eYO+jf/YAuOs5dTzWB6IZQMZiCu0vsGYiVzxBKCTkyRCBhmcShsdwnhFyMcPooZMNwRGp4k SpcCIYDJ4eB1JH5PYeqkt7oO/AI46cs4RhFG9HjHdsJdzjl+iyHj1Q8zey2c1MMPQLc3s8HH A7Olgt4IhXRlACfO+CJIk2xgwGWS0KQD5SXuI4hSmP8ySH0ShyL07QDIn8SC4ZoghqC8Wdbt fWPnTokZkLi3rpqeQJdA+bhkk5jUhiqcr2os9KkWrpeASuPjLO3K9+RwVqVHNpKRn4IvQLwE Qw2Iszx6xpQXXV9mXLIiDPjLNKLYqasf/lsHTwShDBQegeD8CPMapEVmjnVLA4GxosAq0LZk QbSO8vUEhuFEyBYfuHz17/WUvddTIHjNSVeQCAbwNCo+i5gpVj4bUFKSF56offhmoYkCvhsF Tkrlj3XVbuFwkgfy6/w7ycKiTA5F1TqI2kjZ1kmvyWASdEjg6xFjBpRatSAdBOnoIFPhYTHB hplN1dKfIv2pTj/M49lzlEMRw8xbVx1DboyF8pvaAbtIZ0g928YJVBy3gSO8WtIzIi2pDGLs E5SmMQXHa+5DnKsF6SGIobBSbrhb/BOKgD3YOUckQ3V5zmsmvkDirqEGAbWTC9m4mfiSiE1F 9FMIKX6iMtYhG0SCkg4ENVknj+ltsq23yRMJXa0gSrmI9XA/qTerdlvhmEwiHQEMRJTI9Coa gDoZkMFS3w/87QZDJ/IkMU0N1KOeZqjG/E1lznZYMRfQonPfjTcNXHYzPGNK5zczNnBDyAZx 6jZKeiYxDI5I45ScG4h7ktgYXlViqqI7YrN0s4ESsh7oXAGZE/epXN5NZUX5adCfHtQDXmSA xgQOhR0J0DQCNIimrP3MDLKgVDfB7rQ+PCp77pUj1QyEwMy8l1d0yJoNBqbQmjVEZrJcc+Bc iY6DXVQTAlnpuY4w+grZSjbgUEu4GWA9DBnnxU6OQJS1G6renXW63R4UnfPxPRXSoKR6VDDX UyMB4BKEgB6KryK+qacFa+0atHnkvAZagd1mPcA5ArTLk9oPQ0+5P7vhuKhdC3KBIJ0yyJy2 fMHtMp7qQS4RxMwCbiigvpFZHDzOdxpS8AlCmJ6bJsGRF6ywaJ9Di18vyGkbAQzz/IB1O7jX DUyJb9db92kHyQ1DHfKEs5En9qgfwEbPjKmkIsbLRGezrZ/wr/UYXcQwawLBI3ud9TzXrpdQ f1QPc0YwJtBPYE8Q9LCnYhK0iOn1aD2JZtjH7Jebo9vxhPlBUzQ/PZfkp2Xyy84+1BeS2jCK 0Ve+CT1xyH5JRbTFRvJhPKyHuZQwhmnk1DDJ4giti4HFr+rjaPdEIvV2kWiRy/PYJPCPPgTB F7C6EZTAboOI3bZEPN9FpOXGWbqIBa3VgB+GWC5Aw6W4Pkau69E7Et2IemCSYeBTQ/4rDtH3 eLTBdRfWZ9NmFYCl9wxLN/JrPW0XaUsZtT9l+6ax7hnSdyoGx/4lgriJbjK5G9xNrm/Gg3k9 GFj2eaukGApThDIVMWipKTd1zxHEkGgncO4X/roXhGRijbEDoSji+6K5lepeSgxTQx/upvOM h1rysxNJbjhr/2H+cTSZjwf9+Wg/lLZCKRXmOk5/cjf5fHv3MKtH6kgkw/0H/ZvxcPTf9/3J cD92TiXImQly3/8wvhnPP++H0ZUYZhVzB9JMHvZUyplEMNx8OJ4ByGQ0yKeH1YP0JIjhzaAM 4OP6854Q0l5bl0Y8Hk2Gw/68vydEZqgnBsa8P51Tob8XhjLUdrktUhN7K5J10IDRU9baNqx9 cnd3v9eM9MhMTU/R6qYd521ghky11Obpa5Z7wpwqGBMIYhFkErnLREs2TTDdDMYs66YjdL69 lHuWI5RkigSnlZmJeMoXZZvY6RVgnUowznyA+/TLw2j6uR7qPIMyF2tGN6N9JbvIEIyw8tNo MpqCdqCW2A/mMoMxAsvt3RB9cR+E85MMoWcifNpPkPN2Rm8EFZjj/SQ47+T05hTL6kOWBnIx yJG1Vj2cMl2zUCzW6PdzgHNluZ2yA3BcvmUmXlbF1COeZYgGZ/cPH27Gs48NtL2M1lwfGYGh zuYNtOcZbdekvb/53EB5kVEaptUfDhvoLjO6Ups/GYxu6kkvTjLSki1dT0dNSrpoZ7RmlXn3 MJmPpg20nYzWSEjD0eBmDHlxLwhld8YMudC+M9UoNNjHhbK4Urkyg8CW9V1TYQv3Ub5jBI27 WhCTG5DPMmTD8j4CpGeCLSMRrxvAehnY6XNs4pZKmOjINrS/0DE2IJ9nyIahDoWtuvdvQwPj vTCq6qyQBo91Gqrpi0skNuYhm8RaussToqtbCd7TGi7bCsnEuglWrs8eYlTHf4loIaIgZp+6 DVidDMuY/1EUYRNuCx93vZr4OUWM0sYGd/aVpkvUu7GUXUfBBqM7CORpm9b1aGcSbZcbQrtN vcQNNbQm5noSzrBn7GiDtCmmX55LUsNg5ezcczp3QYvra9dz4J3eOdfDXkjYinWCT6NPUGa3 hnOqcwn+U/+mP73NP6pHBsO+NLfHcPpwXUla5ziO0yb22nhgvH1SXjDcS7T2SZtoK+tTteOz P1aHsKo3R/ZHwT03c88w32+Afjd2HSFvCTQCgZW3dzfhxribNhUrPOIkldwAc0YwJV/RyIMl Fb0497eBI48x4EAjXDnfQ94e4Xea8PeFO5dwJsO0aynk0QGUvwHjQmGYpVEQy8MHLiJo5zoa wC4VmLl84HkB6Ax3k+nMHdiG21SZtnH7rb1TOs3SxcaVnOHxriDmnlx1w9Nej/CmAbRNoOWd SjRWMLg1Lnzly0gNSGj/5qL/uD/p72m10dJWl/Ni6+rvf2v3zt+W0xZ89eOemyNt3MPrl9bj vvjBkyccsdpj5bqNm3YfDIAP7sJzg1XEw/VzNT8Kkd8ArhLjGg9PFmeuaFMEmdHwjlOPYCNm e4JH7y3uedYVHfzIjnyYBwyI9t9nP77T2Y92S5IYBzVKJ9qKK1LmyVl1LAyC1Jq829wa18+i 6RguagmPJaqTtFXH0XDPDfpEDs6YHYkqYeTHiVq4ZB1yyDV26vEIT8SWGAOs3zF9HzIbVxrE oQG1wSC+lacCHIFHTIudRDr9otrL16K1ah0ygQdR4kMAPXKC2ISCKORw19uyfwZp5EMoEnLp /wB4TPKjUDvMxXInRkeigPYIWNKS01gebjXlrjiGVyDQTOUHC8tn8aBrOY6yihwhMe04uM+V QpQviRXjPC6xuIMA7rn4DiaVzhcWs0MHJKMWHanMhyVEHYrQmQdKjHBuMYjHCUcAR9O6lDE7 s4i60DFsPAy0peZ/BsLI8z3PK2bdvcoDiYp1paNGzxw0OgbKZ1Qr2BexxbPSTsys24fZ3DqU v9nkjl7j2sB4Ohri69nH/s1N/sIQRT09+3j3cDMsXhUog7vb29FkKIFu+58tdeqxgLDu7ufj u0n/xmLZ4bvcP/EsNszSQkifCyM6P83hCRHbkbsQJhTQ/4bn1tvty380WFf5HGZcrMhEeBaA ho7wbCAuG+HmvA8+GMDwR4ZlJYggD73j9VEKCGgUSzeC6gMPH0KgAJ+BBwQHH0GVIxZdPzat Asy7RRubItsZtO6iFfchSkJMJl5iabPIISJyZg2qggtGL0sets3PNOpGTcWVOruqzjq2WCWS Fj40KmXXZRWR8DYP3YTj6V7HdEKlvZLG5ClluyJcgVtFmkJ1KIhxqFPrk1VWmOxvdG0hLYW8 6jicD4jE87vhXZmWwmQFg7t2/Onnu4cp2bGJYEbUXaSWAZNPgzpZuqEl0Lhy0g7RFZ6gFMDf hlkW1lxB/xsug/zjsHr+TJPU5vK5+TMnQK7NWwaMqQ7JEAVFu1g3r1AwnnMusSOfocDSH5b1 rAFHap21fsrjhhihtYBV2v8u+jsEfrG1KI6SU4QwDCtU1f2Otffnc4ytoO7skZJKjOCYW1b+ cBpLxmVCIopcY1yW7TLMGOwYRRLwlDcfUMNAksLD18/ra8cudN2hHiIKhHuoS0fSVWflbOzo C5qrVFgFn5m2dCiluQptFWSZ3gKoAiLolHZ0DeLz1Etk+YAX+NXdoRyLOGlBjwx5LqL8T5/E ZZQ9jU4zNKUmHUe4VLZxD6weS7xKi1PKqXAJAwtKVSq+sYAEUmOWZAoERrMC0SHu8NQTPWdK B1mJ+huqlKE13+CFEIq4VDKC9lfJurEUKh+Y3j0u/WwVlC9doQnQ9RxfSJ3iTQn8qw0uTD/p N6Z6z1PXqHAeSkaz5qBzVPAqy1igBlD3YV6pyLWM7JJI5maoNR2oVIpkpWVMZSlUutqNsUi8 qQ9fKku/xoqo2z2DWmDtQgVSVO/IUUDHo2E2c1Mt1c5hEQSRuV1viKU7lIqMEoqhGpEnJRmr oazDCj0rxYRvBxS94cnNYZOMmMoyGXu7MuKiPyodueYLmFJkvbitVCAhK5rmFyJ5EsJn0FrR /RCwa2OlU85IXr0bbvtNc3Sr8X9eyX9uNGIDlQRbuHKrpNxVSFU0pLTfxrf3aBN0wfEYVz9a rWxQvNPFVinFs6AQNzuPbUYmadTShoQ6WShzhW7aMd0FOJR94hpSjBkAZBstzYKqY/Iv7fHS I8BFiufDS7YFHyuKwmEyY5XGSFETzXSfnlNeIAtAOD+AMg9KzU2YoErAUoW6z2TcJ0O5zQLD xx2smNrp4vqF7EAT8mMtkLTYr/DazB9hEMfuAnNWVFxPQhk2XM6OdKJNwOR1O7zHC3OyYxOV rEoOnmGyMeCWb5jo90uMUFvatxoP2Wv8aDw8YKbSsx9cQ/MC+wvlivy6DqQUSwNlSRrK5gct ARlDHXFvI9c/uDlo1TAy9hzKqKUyYLGAI6JH11btJpTrULiDtqtg1B3ALVh8nFKpjvestzoH al09lmfTUbO5Xo8LSa92LFIdu/wjWsJ1G3QfvbJec0pJZAJPQWYAKfcq5YtxpTOmdR/M6DIy 4vpLhOtTuBxDXLYY62vfViFJXnD0BUbUWJ7EUPmiWH6hpbMF1ArrUjOT/aA3EgJ21LQQtNjq 8qFBIHvmB1VIfEVtV1/JgCvvAcy4dple8kzOheysebVoruxTcSJo4d2RPp5pGeRTCUrLLM/b pOru0WZUL4M32uRhpwpRq4B2xCdRVYCHNAtFqdS9A0GBbkw8Y95fhAhlcM8saXe29rdobW3h 5TYNgdxTf6IA9OIFK/Ax9LgsB6tSBnUgsr2nSnukTLNUSlF39mHIwHYJRy3q5rLiZf5qM8IU IyO1Wt2kNchtVqzlXNhUhdhe6lQDyWyQD6iVXPp8an3ruDq04QaBvC6msb+hjQsQce1CLsVj +KbaqoCwtyGe4nSRX+mN0WNyWLd8Dfo5/0h99/dUM52cSq21qjI1u7FdBVOhmcPKNaNynZID 5IsKmm7Juzf8C/7BBmnd8vLobstb5uMFhl99jf7l7jDXip2Ke/ilW/hVoxhtvNrrSLQb9/jn LHw3TNFKGvSBkcWlopTWbIps+sIoYd50e42X0v6gqjbZJRFZ51NJtFU9BgVc6g9kmVY1zmur P8BV6pl1IHXLtR2bUsh9bT3cT6yDShys4VYR9xOZScEV0HtoouIsHMM7uaFRXv/KflbuI2TB wqFwe/u1dffh59Fgbh1Ir8q/VfNZhRNJ/SJPZsdOWrHwSoNVvYSW/WiupxaaOe5poPH8AV8Z FIH+++WLDB0ix1TgX5qzhf4ZsPx/7b35dxvHsTD68/M5/h/mQ877JCYAJJJa6avEEAjJSLgF AL3ERy9nCAzJicAZXAwgmjn+419tvU4PFhKk7ESTe2UCmN6qq6trryd5xZ1KlDAwOyCIQunN UEVJy6We5JdJTEFciufsyyG74eOTKD0NrIwIdMV0EMjAoPzCDCrJ7WgZI3SShCc3PDG9B+Ht V3e6AZPchefpL4KeN8Bgp0PSc3FumttspiK9d9jLjJFc45hBrn4O1y6pLShdzYrIqi5j3xYq SnrEBwomqgc7oqv+33kmKpHzaZKQgRO3wrkjh9baQ/PJirRgsTl4QTn8BWNhqB+6oy2dtqPz RFQh6wfuLV5wMeNPkDjhml27xK0329Kd32nfQfyWxE50K4eIrjVhwoaFN1UY0HBkYw6aQNVj BUtsVEFlfKuEf6gj5WqHooYzKluv6hEZouA/YlBacUUw9LHLSNqcUQVVsiaQZyztErM6Sj+l I5QNSXu98tHyVj/4x2nvICJVKIrGS0H8/aB72PnH8VEnvLy18bGreU3gIuLxXXUPF+P8jEiz 8LSGlQ3ID4sZSH31KOJv3Z+Ax0kS/R2gz1fyQu7NWiL7eGMo+Kck9MItAHiSw47d3AloDncF CDW1goAkE5HwKBUXnmZD5Sa3yb9r32FyHpEfQ6gnuNuMqgKN8BmqMpB5/gREH/tGyf0SLoHa bWB1PyTPLBavdPMjnaakqDpKtrhOduIYBN587LsYUOKo1kEnfLM4pgJ9JAv8S7kTve913h/3 uq2jrZL20Z4KjX0XplBp5u7GRbjeygRfMwJpoEQqRM+tMNskRrQrfFkzWLdZkPEVu/2aECXI ckOGIwHRFWacsR1e2fioRw4NJuC99TocStu/G6HFRS0gtbQa545CkhkaDIgPTMVhtBAXL9Ex mJmr6Yz+SSUFZphq1zDmK7cMMRi+BYwG50Ige7IoDeC2q/u+GOqxHTDgvQ+3BrUVMXZ7GFud XAFLiGwh00QS4ERARnsQJqshyf48uCpDFHBujWu8yhxXtrbzQrgPM5ehl6ZxTsEQcIXcGlob ocpWJyVoucMtZJNWhJHFmQ4rWPVNwchkZbwTXU0o6U70OD+fJbCBaS7aWVGWzAtksjVsqrTg bC287Spcb9270B70DU3lzmNv0diKqBb1T/sUb4HT98GVSH7LYpFC7fZ3oTKUW1GkknTtbuvG czifidaXN8OzLyJI5JYJEzmizbRgmFXdYt0sZ6zC93JYSFduxf9bGaHuhNdwDjOcwRXcQrL9 qEfM4HpVDgJsr0GUIftjcDH0Rn+N+XOajIQCdO7E8gAvcJaO1daSPyD2eE0W55nBddYcjcNa /KGejlie11nLfjJOLtiCcttVdG3iITrWAiR91MMgiRwjO4/zGslYSVj5CjyoMUPCQOkFUnFW KaQT3l6i6YvtmWXUVLwwy+9blODZmABDfaBXQTZKkkJp4cyQge5DPSyEQD7F9L+ZYvOrWRsF MXb+mCXxFboVnJFX1pj2+yJnq6SleQl1dJUkiF7r4AXCf+OIgXuMa6HoI/aHQxJM3qRnyWU8 DrMxCKDMM8Nhf2Uojqx5l/th6zHiFhpn1lCh7afF8GFOfUxnXhitIE7YU5GoCTzxP1wmmUsz zHthRVcqecwZNe1ucT6rA+cdTPZ4fhcNsq0NV9endQPBBUeXNBxctgovsXdpfUZE/2exfYgA mJFejDgVJCQnrez0xrf8GjOMAE0PFBZw2F8pvtEKbUdO93VSg1bvfSesGdFtlH/f6pvznWVW ttRad0FfkEDOk3g2nxqc1RO8jD/hZ9uYHVzR1M6JyCo5/4ALjBG3BxV0epZPGlcoLvqNnPGd sULd4K0zE5tPQVbxCcV308Dk1kWGlysVeo7DBqmsPZWCLyu2BtIBVSpE/io4kapp1ynpm2Pu V6BeiC+i7Kzxemo4c464LI0QxuBuZnktuMMjUGQKSwEc3mDtvwMTHGIUfa1qkyvn7MzPQsPg 7lRMuJgPL3kutu5oEVg17Gto/AEKtQiw1QCxqQHjuLP/ejHqsFXcaOQGSbIphrw5QwuLY+Yt auwgmOWsYfUezLbAt0OsRycIsVdKschsPZTgZjFfz5zoHPbgKHvvLoa2RQnKYFoKa0dN6/q/ S8e1k1aP4pKqHFRq7e+6B/vwjmVwN2qAdYjxxWX0FkahEF4r396d6LEjARVKHsBei/mE9Gdw h17i0DOVNDBIknFnvzHv0GfqnMxDXJxA20EOWkerr/sAbeaigrnjzaOdocU4UWDN0QmgADll KEJ+2lpnctefaU8KTFpw9z1JMeb2Cmez4FjOdPmr1SFzDEzQOJ5M4KSg0ysrA24Pkwlbq2QH sxEnJEcegu4FoLxIyo5PWn8/7Yjtv4IwZOTzAFMjki0Xi8UCy0jKglvtRmcThln1nLBPciug IlQkjdyEekzIG/OxZygmJ37fRdNehOo+1KU1orCjie3ySehvLhEGgVo0WYuDt4ZRzlNv9YWr 94Z+VASBqcHjriyelUZrrox/11lyF6fUY+s+b58WrBEsFN8BN3jt+IejzjIvKjlUcp+xsca9 tnOap3OzhKHOt40/qA7aibNR1UtB1LDV0Wsca2O6bqsp2PYh5+e72uSpCxETznJhev7vePZN QUaa/3sx+4aWjV8Ni3TEX1QwOxKJtPpKexh6cEc6bnup6S1j5+0h5Sor6iu42sYSiy4cDFXK Fu6M4iO0F4aK1gp1ggUdiOfVkXnxpzwdUW+YbgRVCtk5kL5Z3eo51JPkAThDUlnM2KNMmPTI Lmu2f9SPRjkaVYLd4MDN6HFysUfjnef5WTyVYQE24xGOMGT9V6g9N2iKBqcJ99rWOptb7UsR PbZ/vSMSZ4vNm+YGqfII1W+IXz4HbYjptOQ1Z7z3yz1xy2kypDxHo0TFQ3r2WHRz0wAI9cPH 0re8iq1VfazxGSXdYq3KwhhHHr2Q+FXtvatWpbi/che2CwypTMS6Q3ebcHQ19FSaxLPL2iK9 7VJTsFngfVmDe8yJbZbXxVt4Y/xuyb8WDkv7blQ+y7PG5fwKzoXqs152uQqTkJxzaFjuRzQ5 pXqhxUcF7h9Q4WF4s0SMhCVps08W9dpi8lFTWh1CfrmSO8EGiHbA/cyJPGupP6MLoLRhjIwV FUI+4ZzNgCquzYurq9aX6R5SExYMpOQszVhdSpPDVPkzrNE3Q7/3rMJCIoXVcvZvsST0lYHs aJNuD+G27sPwdUahtAFFJNdAVSq01RdoqglFj0/f3+2AhZ3lTTkmdI63qhc1o+BaB+QNL9VZ kcla7vQe6qbsCJ9WO72HD6zrCE8zEssW7YPv6R7s5Pbe7wSpo/jqbgSaeDgm0XCsclKLeWE7 +m4nlmiBkSAtbDelkzVUKzTOCbCWaCMd86oeQw+b43joWJkVCtvSPkW6hcSNjWqhsbDQ0aud HTJ0jdM4UzHykrykLnHjv1BC4arYHiwiixiaAFNRVyKSaNrRcYX1lKNknGISiAXey3xREv+M xlmnOS8XaYSyoZ8+Ck+H8vlg5sPMXQxF2lIrhAn04vwKGD0hPy10fg1y0mhwQpz3VxJbWlKQ 84o8k0tfXY6olNXFT2mzKhZ/w/m6hIeA+SI3abOACk+1pHouidtirrBcp5jKUO+ME3VbXODj wTewoIwKCW+SXQEgD8AqyOcTNhPHCl5ZM0CBPP9YACJ8BD4QO/nWEhhcgoz/gb6HIBDjJHiL 6URJChEKUi4jZvhosjJFF7/zotflDqXq0eal4GUp5m7d7ixBXBAmk2U1Uh0A/uFUa9+GLSG0 hDOVKoFn587pal7M1Bt1Cteu3i7DDahW+VkxnE+xJYNMOG1Cg1A/38J+N3i/G7TdqsI2zW9p oEXN28fTAg0YuUqBoCAi57TCo0mSHqL5el5YmU48wFRp9t2tKVSUWC6V3VWykNXosUrFoEp2 fskkuslMojuSSdQqfarziJYTYTzzKp86dU+dTBjIgYg7nXLNttOnkOEEM0qObU9YcdkxMjt3 EJtkJ6X0KDqDSoli4YoUR06ZBNwkXuw7WTNlt4sEIzhVpQsudAzfTKmAAKp9pKaUcg8x3Ykf eU1qcrOcgA4jk2mCDC4Sy58Pu4edD5jnJ54U5A5p587kMP5IYtXYJBCrydRpanSpal+0uj03 q/+vv1o8AtmF1VKUOEg32DXe73DgZ8D0mKBqMhMazw927ST6XkjCJ2A0KA0Ewh9XXi6hpTYB Gl8BXymEyMxTmBTLuVA7Fio3hWB1H7veOSCNmEE5KADgBlRK62B8OBScHlUNiRXcEz3s7FL5 R1i0So+m9a0DY2LSU1LNQ/MNXan47oirTWpejNWg5D4MM9omW6+2eyUiTfa3oTfLCXog86dL x07HwqtxEJ9cn4s8krr1Rug0gmOe0RDiMCXG5zHeP2ogdtLGcaJPaXJtsvQmo3Tm5OXVvVrp C77+ys5qEGchD8ACXSMIaQXrtR2OjQbBA19QQttC2QOBomI15aZUVUZ/j/y6EBTzAPv1V6JF QKiOSWyzAtMtxykrbJ5aGIJFgNMOLe1+gfBCWw0uEr2nCaDAdyF3o7wf8cyyWe5xjupnjMrd Ih8rzukYBX4lEuSN67tVoa4MJ1A6snXRlHz9FUMrmsUfE2X6hZNJuWD3CKxLhZo/Ep4ctn5C 7RmLuyZRqzpQcywgAgMax3DYrP7ON/4GSmcYyYa+/niJL+lVUokRsTYpz9QpkSD209YqzgTq vgSaTd/+P8jI/KmBz58MZ6O+kN9/jdS/uL7SF8gb4RmmRo1faXm/NvSDX+xYX+C7O+Wu5Sl9 AaLR6u/+ept3K5cfeNfqogubEgUe690/NZY8f+Idg82wWSPA1lGcxXVgrMafEqRwmNEV+Fm4 I4EaNwpmlZg12rHw9OuvjvKZuNsgOjFd0G44cMkJu4C3LmaTTknzOVMpRUkXzHYCpAjsN07y G9ku1PWBGF4U8yuVHVNu2lSS8OGrMnJ6jvf5NZzJxKYSGqGv4JhQOB5bfMi/EkM58Sqi06/u BsSZEilkYqjzuenQpgwO0xSvCObJ1P2HeIlHCtCxGbnVTQqYCimuSBoG8NjtUSD/BVgGYhK0 9cxQG0M0zfVuj+Xw+WVuk6qJu0m/YQ7XQMQ5nIKJuvCd7vm10a7B/6Oni0WpjjqDMNLRi1HZ C1Fj9q8haaeEy3+q+F5+DfXxa9RPAT9P5mfAN+DV8yvabvF1tN3+KkHu/jvhnuABRrRxsmV9 of9Dv+xsmdfvZUX/n/6jGpbN0k+fqn+KqicVfFngqfCFh9WIwNBEbyvsJ7TjUWi88lq8bxh9 3EcGqXp4StVQWoR83gz/FPqGXqNpRQq94X+lpfwKwh/qSvHcN7ZxTOebHfeWaNL/pGW5K3gA y7b1R/XNjvWC6gq+znTL+1rgBi8S9H5xYiMKxDP6R/yjjI2e2euxrigBZNJb4UiD2GK+qVl0 zT7SU8zVRwUP23X+7lNKaTKFX/M6TJWNlqTXG04dyj1eg+yn0jAZnh/JQdO7PdCnWt9TGfJg Q4yahzeja76NfAHDjMs+HCWFJqbeowhQtrm5IekqWydM8aYeifafOgIihwRrm0bfqXudIu5s 8fji5q+532hyeVOkbEqhK4qyNg5QXGGpSdZXp168fk8ikbiJ8ZRygZYwgkmiyO8pBemBlU30 XV9uZgQUvOf1ip3xdiiL0Fk8/GhU48A9XE7z+cUl70nE/WhkAkwDbPDV0CBG/XLj71+LpdBp Ip7MKEYUeWa4n1k8vbASMusc0HyZzzO4yQOTP1fEVO6QumRPUb2CvEMCjoMdWkvjdSg6G8qt jXI2bD0dFYYQmXeUzls4oMkkiYnBIGj4gFBraeJRRNUnHG1Oz0bdEj2y4JvpxLQadf17BKFI bJf0Q+s8R80T/0lA0KkUAWMwO/QskWn709MitLIKss8BEY54hLnAqZZYjpbHgrf+MR8E0r3O p+UeESqjXB1UlIBASoTrZqu5kKt6gVyVlT3c8yU5ZjSvUOlZCVSZBXQ998R7Dp32LtGYQzoN pRHzXhJlV2ErCHQuHPwbT1lddMxe2wo3cdICaDqqMj+x42ghnqOFyTGEf1IhQDPa1185ygh7 HNPxFeFqkesRVJ4qvRIzK58t9aDNm/qr/BduNyEu5rMTy69f0nByWx50jva5+f+jxS34SSBg xC/6kpduXiLoLHlHQc5809bjwSdrsla/eq7Wl/32d539U8rBIt9QAWn1SYPJTOdXb2pmTUpW dWar39PLWvyauzL9tVme+qq0RjOSv1D9i7ta/bVZsvrKXreI6/JXsylItSlOxuCzScPkIifq hV0nTMDzFOdm/ABbB939sGYTiACRCDhbevkkYMN9OifmyanYIuKuKCXJ4QRF15tEJUA27tdI PjW9p1qJBTt3moFw6o71ityVR8mMsskzVVpIJV8ilbRSfmsVb4AwtqKLJAMwD3VIQWMc32BS d8dEACSirBz/+iu4TQcncJn6anJyAVLq6rJyfHapPIOwvTFc4Mpt6756OUWdMpoCXQU5EDwC zLnK7iHWuuhlc3uBwc4ma5F5nDuK5tU2BhXrp8btH28M7l5/3icr00QiTe5jxNbb497A+gxH ZRJpW00zOkmml/EEd2wYo4qSSqcBX5ANwz7M+iFffx2qj/4byYiT91svtU4H3wHZ67YxPzZ+ tnkt7eRiNWgfw9tHpx39GbYtzebMtie/JMO58d2UNWA8eRF2UtLPgaxopUl393HK735Sn/sJ xtZlybUxliMboW9dlk68Tva7fVjLUactwB+QH52kFTGBQDoGsJDSdk4nfbgf91uDlpkJmZms oxY01C0EhbYt+WNhvsPBQV99Pkou8hn5fxOVIPMEW0ALVTqXRZOFo/0MPX5wWdWj42NH3bqf I+W8dEwVbovlOF/5uLPb4HVkmcwa2jBsSJomjSadDO9aJqpWl0MknvMmTAyde0GuhK+/ckjf TpjSuScLE5zIoGSH2zCle3BC5w3IOfjNZ7LvybnVwM6dVKTuge0cdOwO9tkcGK/U+H3nqNOD 8U+7+/wZL1gc344m1h43Pq04PN63yE2kKgSvNvTh8ffWrOFz/slPXWT9ikXZ7LeppnockiCc Mf0ZL9+dqmfzB3Ihxlv5l8II/7hV2OwE14LY2tRqF5+K+7/9SRPX/05/RF184VROSLiKRr40 7l09jtBofY/VSDt9zWr0lbm4NBbbOu882smBdWJ6qswsOUvahUJZHeazJfvOIWiNRs6EQMqf xVTPh9SSrGdadtW5q/TZmtZRu3NgPmLv43ses9d51+uYvW9p1aCyAFIU/yxCBwTNU91+hcen aKtSH93RYqm9Ej1G5meOGqwGUhqsq761aMhZXsKfEtluH3SBzZLh95PhGMMV9DiRGmdjFOx+ eIqySPcKRTqrKn1fsV0hkc51dNR+V9pb1OS6Yabt536r70U0UT9kgDUOlOSjYrvFCc+BPhmf YE0JTIdiwhRL+wknWAyTDH7MmRVShbLEQ4mtrRxjzKyQ5id5CPJGHpHzs1TMjiP0zyRdqKr5 h6+LN8vM6PkKDowj2y9riLOC7eVuebnSut/GBYrDl8g0qBI/Fq+Ekyhn8pOEPlI+bqnvyePt reg0s7JeeeEzn1Lm7BvnyWzossOk6XMm/HinsrNpAoIzKvlVYkQXNyLkHXViS9SSXOVZCkwo jYiaweKR9FYedXfxEtbr7JnXGRVJV9PMuVR4udVzrxU5GFM2w0/EdmNLFUBWRI+xfAdWhTyP InYgSofJllLTuj2/2Ir6kzw/p7mfw+nZiwbTdEgpD2IFTUAl9GyAD5+0lt0D6RA15fhonT2F 8SWUuY408ukMuPoRtoPTVlexNAS9kRQ90RFVKHzB+7BMeP0qLThuRkVW8qwe2cklHOReGDYy EHwHzKxHsB3wD0AXQYOwIEXLnK5UzMabaoyiu1i33RFoIm4EmlBxK52oA4M3I+NcoTA0G4n8 S370QDAI5AWZKZRYXPKdE28/dP3khGValjbBp4a0qOIyq3qK4WltBw8QblMSZ9pZEympVbyG 0Aw2VVeFQLOZsaOghD0E6oQdYkJz5Y9Ku6s6CR53azbGWd2ejBxGlXsHg68IxwT2ciHn00dO FAMSe1FrBM/7PiPiLLmYqsKcInf6gMClKUdcGneqsFg1dkEVJgknZoCYIiFnUZHlOQXOhEaM yDmTB1UjJtlwejOhQ7J0SMB4HQw7Tq/SWQCwxuCFRIbeKgSyQlIU1Itq0sIq1SXI5MCQz7y7 gpXzZnSv8BxpbZmDG3BsHTQqtih8CvlRSl2gp6SNWhRhh56z5FLGuWY1l6AUEcCuNJ99/RW6 Ap1fo7v3OWVyYCNVLLoLaEaRvL/4PaleXkTlDjz+hvy4J2Od4lm0IlYnOJXt0FQW6NBfE8Nl +2+5w9ZRqaAOLu+zCg52ubH3rF5Ha37d33D77KtQrARhkFHifHQEHov1ArcD/S2k4ocUXgVi lUw1/dcaSeLCaDOwB7pCuC3lPY3YTXtL597kiqnUC3pWA12IRTTMdKCyo59km6F0ObuZiLNC HCm3XMxmWtolovmSuBFmeMFqkRTzDsNs8WqDo8SfEZyfkDNWNb+wZpMNLLILzBXTqBc+I8UZ AYUygfoBWla0M7bMOOJTsogkkiHcDFS6agY65uAKPVTwmmeiULmvbECWgClSBI6SSYKah/lE 34M6U6sfvKUvEmAOlApW3x7UDq27VlzVXvRj8/nT1xTvxvwT14f+WzI9A64Xlg08TIIZSjjO zgohzzC1blFQcfFJnKKUTX6nytW+HFqmZye1ipAopm6gIBz34BagTomgQTiVzkqQJkJHPhoT lcw6tsrl5ZGGB3x/NUerPmVDRto2Yb+Wquk2+R4Asp2Mz42jKcktsgS8O9LhTLkIqdXg39Xr kf2dGcf78vvOOstUZ/spk52Qi8OpeCdR0hffiOe8RUESHISrz0U8UzySc92TYzAcIJSUnGOA TFVcKLOMjuul00/Jjfx4J2XXU75G5p5RIQ94ELAbdC2WsTRtSDM+FvBdBaDts8DnaM7imH1+ 2qetJ8BfqzirlFMfpAWHWLJR6+uvEIBGMS8WZLrdABw8OMWHJmRd1NNS2vqqiaEcjL2Ie4tE lko8LTQg/Ew+xeM5Qx6jg+nokKCS2UUPry+RXWbpHH9BwynHbhKIkWxZbe2I4Eqokcyh4m7s FtA3cdo8phId4CWJFbNzMmKEfwmNhTCy15v2LyEruI4nIZCj9gcVBRgVO5lPgSUJ+MC4vu7i pcYu6IIYOI5EVSsPJhCRk09k7DpTlig848LcWpG22mbHzvPN6PGA9lRfP8moqomMZVUVA8j6 F5CQPy2JLbgYtljvUqdLkxmV3Q+MrSojsVQDha3GS982l/IaZ+LSgO5KQ5sdQc8DpXOjs8Qn cTJNP8Emo69Cfu5P/ZxxgFKfivmJPPQUMAFhYVr1lcj7TWTzLrFmjCliG9laBKYiulOONNDu EYQripQCa0fh8kr6Q5iqOBwl3LDzal2UPYzf/HZDu2eqcHsS2KEt8rdMkqR0s5VKWkKLyOBB 4eLIjWC8BOmpKHisCq2UkL+A0XP5OqNLKDzXUj330hHB+36pRko8Z2PReF1MxRosgWI644ao 9HhfgXZSCJMKQaOlyOkj3hDTiaUXnOgZgUUJoWKryhWHbql9lJi7PkVZAdRQFHc03bphITtT JJicJTGhKX7ui8CluS2Xps2tM40HwLQtTsi9NX8wHrVlponGV0SKNEAUE+Xua13fFcWl7eip qIDpD5dwimqh2Rzt/uR6amUzSilqj44CXJ0X8xRzPmSJdSa//uo8TWAEGUh574UgRCiCiNh7 127sPHv+uq4lIRBoAEwvosd9vqW3VtVXwrWoLnZMsgIgs5VcJLzRhc4sW6roYqRatcazBmUi wZQwGZkYpAZDHH0EanNGeUtVRUNsGHvpNChXY6+7RTDPHFaD2HhdRA7vA2w7QSqENBCFKY87 gel4s8GWKnpvOE1xhwNRr254kfYxUieVoYG4jtfyjMQW7BgpCRxV9GOezseM60oSmmdKjW2d ImzERSsfp80EoISIQMuE65yCrLea6qqgqFBskHqzswZxMFtU5VFwaFPgwgJuGRB2lm2sSIG5 Vb3h2SFb8sEzgFWWDVoJyu1XZ8nI1h3ImBzKDceguEzYgyWTzG/QUQexoiVIoectiYNcECKv xYfIaZTyzmGhzG7reZ/SMArbDjcuwxLV+coSRmf5MkaOEq6FR98+qruJ2FSiHtq1y4SS75AI Il2btkUCko4zF0J1PWmaMPOm2DEmukB3flTdfNIV/LBJ7TzOzpNkhPrEb+FyKfJfKGeG4tFV pjx6913r6F2ns/+21f7bt73Ofv/4x2b7+LC2VdrWdk6Hmo63t5tGWicnCsLqElIlmJJqmmd0 35qjm0iJx7kcB5zg9HwImECH0Nv8eExJo2jFtO1M+LDh4yIhBVMzImrffBn9DGBHrEIy94FS IahcDZzFnfZSi2gg+aXIksZZgjxoaZPx7TB6rYihML66OitOBarWUPoZaucs5OsZ82bsfbaa Sq+fIl0zl4ewMbASNkUppRAJbqX7KEJGYDyOQNr/SFqPsaRVqXMwqTfrElMAN6FhC2ymQPh2 xW4pk6NJJwYt7ZCBUswmkU81lJYfVH/AuOkyiQWTRZ1RRq1W5QpTqbDFosLTXoxlJAh5/dhE SmnVQkiwAokKiDp7KHFSDb98qgq1CK+ZKsuPpMoYkVUQg2zrGILLc6kd9963jrr/wNTA0EOt NRh0jvY7nZpJIlzE6YhpB7qy6De+aR+9+WueRD24G4FZQMXB3r9QtnKS8Jjblm9j3D5el3Ai eF9eJmTVUCp6AWBd37ptzSAhD8jRwNLIyOcFc/+hFZBAnT1C0nyGQmV2wcIBlVQi6+hVWoyT mJCes0KVVpkOZ5SMqWqdOFeSWdMZ6cH0Lmgdwtdfma8YsWktgJAJloogJBNdKu46Bc6czwtf XA4wsDuKgbX0Pi2dQOq0kJx+nk7V0wGZrFQsH9Eth+X9sAISZQ9zNIXqTlaPnXaTUH8i/kFa w2NzfJwCzqjOTD862jq78Y1QJP+nCRnjckwXeJFiMUWMWZ8WCenHna60QuGa0j/k1Bi4FlWR OBmFJ2f3gfcShhhNk09JPDZCsxLZgtbEheSvKv1X3U8dG3BMt0wQ6KTe3PUNEZUzsIhiZf4x zdipByRtmtUqM2nuLDeKbO8qRLWiC3rKxcL4pGgLWzkIy5hjvUDKIfMe6PZk568rRIJ11kVR nXvOV6sIMWjGfUceSJibpIHSRp3RHEPS6wt21t1WZjCWgHObwCk613nhXe00nZ2t0uXHyu6U DDasi2+w6dY10trzkUPm4qiLGCzk7qcXcHAEIdQa7J7C64F1RNHPCSk0kz0ReOQ19J6XSBe7 I3KoF6RrRifxfEyAuMnnsHUJMrWYwC8i94l09pcP30SKwpo+tNo/7Lnin3HbFq3uIQQh3u8J kPViBJcJsRBAooFpLsrJ8DQ5k6FDXaJS+ZP4EF0lIxCd3MgI6by817sK9eCmx5BVnInK8WuP k40WIh/ekP0ZyhuoRSPxFVkT7RzEd67F8YiZx5mjp5u6zFE1J4wPmUY6P2KmidaBo9uelvJo nmnX9gsqD4EhsR4+S1p5hZcLpiF6KW2CcrA0gJnunXOu6wZ4I4ZHsTnhEtVefLxpoGggS66L lI/ordDGPVLK3UF5749z8kKz9hyFD0v9zJ5O7DhQCS1oE/CXMZy/1b3TywI0DqFupQQSuBue qbvBclNEJG2nE3T9mqclBZx7Hwyt9xwvbJLvdp69+MA07uh4wCpcsyzCQgrDQUlENK2egwpA TOFWoXxD1r9CYEH/PDo9OPjnD93Bd/wX/uMfd3yt129Zbx3uP1/+Uv+71krQvxXwAhUkh1N2 RwKSnI5vosdj8t9Ds0YcXSfJR9J7npxypBRSpwj9koHdGtHX3t2x/fr1yy3Rw5SQU53LIdCR 8znaapVrp5a81cNaGxHJNT1Q7jycKdU4ep0l5xRPUQo/koNpAeZ2241b1Pnx5Lg34J3qtZ/9 89nTRRvqvr3zz/bb9hot9jt9eBnbeOigGuzDO/3+2m1uMU7nNgN1brUi5L3WAHOoReUwtz1H eOV9mo8zk3sZ2NNGmjUAtRpX6WjkX6yKs7DuIaFW2jOA8dYlRXYfRtvH98A8k0OZANswI3WN UrfwTYDcmK5X6LMKI/QmFFt9ee48X1IZ5mNe5O2OyO33T7+6vfNqI3sdHADeXvndXXy5s99Z G5FaiujlU0XzaE+EEymIY3O5dNQSxsXstkDn43n7WQcu8ed8iVviHbmdcBEB3+nE/GQHgGvn DuSz3CoFXHFLZZwwS9Y1uOSOgiuCy3fQHUbpacgH5X1UdlSx+3GdVvBkS7pP5OotbZ0Vkk65 2f2jo4cQ6zsx7qfvS1w9ztupmoDiUILiGDJUWudprKC4++yh5Kk6cJ52kAwslTotmKcfoxLj 4lLpUEUz6VzlSgcre8AaEs5rr9P/OuZYnjQtzOnpseEis4TCT2GZpFrPz8jmGFNYKm6ozvxf ePUl9ucS1hFpX5vzFDWuifbb0cvD/PsUB5LM3CXpNyxV44wiOUe8y+dxOp5Py3pVxlYFJZqx Ze4WVwRxPCvQnSlqtQ8k4IRMxpL+Uj0yvNj0An2xn4JAE63BJt9SiSKXGntKMpOaxueLXBVA hfpKNlimzNJsQuTIwSnUEk5ztKrqsJIm5eQ0w8HrnD1RldIh7g+G19sv9TlIaZ7O5G11+J2Z 69oc2LQZdSjztc7MLFflhYqTVbsSRobUyteIda8usvTficSUkdETJ64rh3iI+V1+nZCoJFh4 jt7MnIFIMq72C7Yk5NP0gqrgwFtktjCdyHzVlo/HRMBIf+0mqYJ2Os012bbdQx86RrrcFfIK lD3XqJHZhwuzXWO6KrunUc65Mi/tgg4ICLvwilVkxUMaJ+EmSw+RjmBHVw2yLbFPBHwZXyBQ YM2ljvpXDI1b3GgwaQwjoUJZIFwXKsF3qkBHoL6Ob/CqwPdirkPpjBSRc8l6tV8OcK9uPefD 7gAz043mjCn0Iu4pCEOvzW46R2f1qe3Lqbnt5LqdwTu7io62WgMJp1UjUOnksOGE0dGDqLRf fdZH6ta43aSPiCjE4+hdns+whl10kMQXWEzkKh4BJ62LWLfecUGvo3ftuj9pceWaYuyV1Ww3 wiJ9TAAxsZtOTLRkWQFO6QVzSpayo8WEvMdlQRtRfw4naOqFA7Sc2qF2dgjKb0jnNDGmk5kT 82qv8Zy1iadNuq5UhndJcaBC9dnJYcj1FuPo+2BP9ryjx8htgRTfVy4tHLfAjq00Rab3GErH ruWmI7rrcWdodUyfMaMA7NH1FJPFmRQCdSu5QFnZhdnorrDaGMWK6bBvK9lTP3jx0SSlZINW 5s6ZTiiWiHhRFaoi3kEeG6m9IHXlgUxHN1obx1njR3aedO/OIvJdLvVmOSzzjAlcZ7pHpxPR b+BuU5E3nFY8pCx21DjV+h4qZGTccnz2gd7GlXD2scgY0ssTUN4OHB9h+ijXZJCoAUsLzAyX dmmT1ELebrXGuh688roijBopgbew8E+l/vzGnYspuMmZzlRHoaZ0kDxdqMNO4UEKYJTsOh82 a98sd3i4vVm8QVLFJ4Tedzk/wBDyKUizudcMuR0+TcvMxC+F5Nh+jt/rHQkc40WkR84SiUzT xCpUrKN8atiHW3dI0w99kutRrdd9/92gXxO9HVEcZfivve+1jgY1l0zU9jtHP7HBvQYjdPdr FsEyZKG0HycmHYkiBFkAI5GkZsQhau8CstM7uMN7QP5VitXWcw3Mz52V6ecg/ZhcpwU7n2h3 TjS5ICRpEniz6ih01lHrIhF2V6SjCcGS+VJxNo9n1k6JgOnQ8rdH75rRz5397uC496iP6qcO Ti7VofB0+ed00QN/mSbXzegH5BnT7GMZZakhUmPA68mlkajEU7UZffA36R3dDRiBp+N8ifBI mJ+Y/8SPy9hW8uk1apXtCawUprf9Sp0Jy3ViPwE6BvAhslCKlGHpFxrnnCJE26GFxUQXZayr xkEbVp5cn5iSoCAu1pb4bVydWrajU1078ppeMC8gB/SNx9Y1p6+nYLgzV/li5wjtboK6SQoX R1nLWj4ekWQ6zafaE8sFMSZnxfJeUuqd/SNEiKER0MKbZsX8HAhqWpLrHC/4mRv4ZPJ3hQgr 0h0dzuXLHrx6leZPMUgu8U/RxoNmBJXbyV62OvdurO4sLkjb6Rw7YA+oriWNOcwn2vJgz7C0 BM+RxvNlUIZex9PNeLI4xyxXixYei/Nds3cRSTuMkUyuFKnDCKzChwl5L6FtxWIeZ+TsQvEh JnkOaYGI2hkXK2db2acYh6Si8zSH6PHx27922oM3f9xa2L8LXU4BKUMiXTUjjtJClbTJblBs wyKV2LsUiDG9sMlH6eClNA8ClDGeiBTvutql6oIK0dvO++7RHoHa+4Vo/R57W+0n5/F8PFOX qvcmwW4Pp0vw+UZBRv0h/znsDL473v/m+9bBaefNH/1OEBrUh26Gk1J/02S+8dtE3FctNMly hcBvnHnUuS2nNqtLmjGvSedovwya/9lcojyHMmuGDaUELnt3E8BznzvXJkiaKHt9LeOcJJr7 ubkjuhncqillWXJviLYmwym/IpNVoT0pBT6TXkZnVTNt7IlyKkp5WTgOza1wltrwEE4vbosS IeKWhicg5tsAEAlRYdVVptD9KdI7PNIuRaWpqM1ZAtEdCVR9YQWqYoa1xK2TXbp8TZFrulms APMELcUcNlrt6eMEuRG4tEoDWa1PiWhghf5bXLqzVCtOXlF6mRXLopY1wxS9jsukQFhpxUHq 8t2h+w4LnGGYNCf4wNftaTj1v/EcoPQSsGhHNZWQtGZkq4GDWKJW5thpiSH0IWB0r+m5PfWF EYvE6FzkucumqcWL9SIZWa6VODHjl04ev8xh+L5eOE1eeuqHwZkIXPbYEh6UDSI67EI9ZBdQ zuIcwFq9HtQVnxwVKse76aUMZFN9TQTbtXAVRxKGk+ak3dpNaEI9skaxu9HvwohLcg0QJ2lK OJWl9yqfV/JM8/2HfRS10AR3qfZtrS7mDofosYojQzYEGUj2ioel0TdS9bol9XfNq3YXqhnv N0yrYdrW2dgd4/jnec6u21aRWfe85JRPhdQ/fohmPFMdagoC7YF7Mqo4B68c2Vk49nmh6z1c AO3JwstT8w8t0YOMtbqz/OzbWmRV0HCuQOVpO02Bo8U+bM+ooLMph4vgHnJACGUrK3jYyInl mznw9HjMC7w/LGaPSxp4ujG2LFHXcLi0yaXcD7F11W217l92BmgV+YyHdga5/U8gdcZ2cjkB HuWyUQU0pAqYhypisJ9Sbvg8I205XZ4oX+VT8o8bUhbBIHUPEAztv8q6o+sk/ihl7Z0j6dC6 ZvT2hmkAxTQsOflVxAazBbNGH+8vHa7O2IoCL72JomL5YmC7EcZuaJUVQJd7HqtTdJ6SFoFX g351ST7xSzojCGw8QihwA0+KAUjrqBs6d/6tl58HTh/3VdqLDotkt/D02qjlSkxXthRHVxa8 VI/ScAluXY3clKT9/ParsgErNPXPatSqL7FqVU3YMmD/dk1bocmTucvYtxZZt1Za1xpGrx2K tLekqB6WW/XkJ8saFbQb/5y2WwcfdHWI3CneYS9YCnkAGCQvXqC14j7tSP0ylVUkh+4bdEk1 yRKUJ5BbYLug2tpYytadUs3yhoJX0DFG2anJ8n6dR7oMNZWipfq0ZHA6c3Us6AvF6nflqETp uFibRYKRqLjEipRLAd0SWqTZJ3JWVAVjOVAeHZMKUg8C6yzT0IpFVY/WWdkxx38l05qakNXT R+YE2ACSTmITEFsGtjdfHNkfuNaSidUkx1TJA6uGr1I0M+nuY3HLn5AeT5sHRQNlxwzanShV EyY5IvZOHCuGGHF243SJ3jdwXgNmIjNXw5xhEP4ULQW9zt8bJ63eoNvunqDxgEIwj46P3LTA zhu4fxI2c6nu6Nwq/WBQ0+4CHT/Pl1d+2aFIQlso19YhFYod1nZYodqIyKe9rnjkEYlBiyqK 1mSAPO0dFNHP8O8H1xaCB3+OHeAyjEftucqRBn06lRxWIZo//4zWAUoykqAx4MPekyf4zbBI R/j55z38hM6U9OuTD/hxKgV+qL6Pb0JYSN4pWcH6pN2dIwlHw3hSYxOsUXLbgSUlEVg9cCXl JbbGXnKFJgkrGXW1mkm5CodG0Pk0JLFBfjWZ476Sf5EyfLd1PXJfYa6e6TxD/j04V7UhxMBP +M7jQzgSlSXbt+Dn5zs7r8sCuHokCLwg47TyLBPKAxiotBfWbEO9aPMCldMQ839qJkOjADh4 LoH1lDEqZRKt2GFx9WVHrnG4WI7FOxPcNRucuabloCJdPaZASMnaWIBcM1QVoeNIl7kKdSOl rxhhUEKenqUzknIKTlmBXL3KYhG9jM4qmNZWv93tmvwWBXWpvQYVeTZLrcoqT6amXF5QCZs1 vaUiOcoLcZrnV5K1rtyP0iiLR52YiZ05CAR56UHETlCES8ifV9vC3KJhOMTFOD+TnIPlPnj8 1flKyTrnERK8Kpyjzzm5+BQ4i1Jn2lsSRf7PKNy+9r/zeEwqYrhzsXQQxZRPdawtx9PP2SDp ncbwEcBTIy4M2ECmgNoPPVQYl63J6sGvVZYBZ73StV/yM9QZy7mFpd7JS7SBfTFZA+l7T4fd VJQ8iZ1hR3gvuvdD2dIEpB9uKW0csJIMPEE035bmq7xj/72gW3M6enA4WssbvHr98vWrxlP4 /3/fzG5mcTHakI2npFTkkz2cT1EFgV6cjtMNSfLWBvlKjcDcJf9cOqU8E+QHqjkXh+i45+DK HJZlLBTFuL80LFRH5Yhi5Ym6d10+qpuZDHOCdEoRRAnAgRpMddZB0fVW2hPyTNZgnFtYP4eJ vABOKBSoyF/zit2RErxIEjb+JpSSXYIDz8RwWmI4VpJkOU1bdD7PhjoKqexBpDIF+Y+ZNFWR lOkyG2B/AzBFsWVelMQV9Xj+jnXl68jlKUWLNVTVWn28UI9aDYUo8DSMR5Ik8GQNnNL7V63M OArtRZ0fgePfr0eHrR/73X906I9ep396MOjXZZnBJcGe0a9HrcOOrMDxi3DmKil6y91QOx6F YsB10mNuyb8rQ5ednifQFdwMlNqJXqIozLmUIGPT8h5WkqqrD1x9qx7sSl5h67NuITZpUtSz HMs/6EkGuTpBZJjdnJKg8mIVYDxq1HKjLBx8pTtG0NWgZshFgB6NGkFVsOlA1qAdHvgMm4qD 88mo5O2pHjpCOB/OCFZejjdZ6wR83z4+PCTE0yPFo3JhQ3nU20wcMiqBSBtO0LmxKVl5Ft9T qpJCn0I6ZglRK0YTtX9WfHsQ5QudQy3WM/Jhy1XS9WgarBaTp5ou2zZk/tjhCaiLw0kRjTdi UEU/bBGkJJ6FD5P24T4wiDTNtrzZNYiszo1Zpm9hUY+WJbS6PrIqdfZUSBffoQsXTpplO2Ek 5w/GeS7mUAOXIwX5v7KTv9gGk3PJxfbsRfS4O+ieUNQY4Ih7V3JZNS0PF24tXb64eAvgXkf5 LM1ouyg3pnPLqXqKwoYOS6ehYO941WsoQ4P0u1Jf3Uzf7iE+RaxhUjk4VCFYXAWlDLknPHzE sEBdip0YWSaGwbkozbxSztg96QvYFBWmwsW2tm2mNftmQi50eRnE27O/OS4Pq/Aq/05czTg5 5/rtbuIPl9ggXWS3/FRVV5+kGIrEVqW4EH1RsTQdqVO79+uv/lSqx/W9KiRe+qXR+BO0+DVa 5/mVW9jD/Ml81NC1fpQWv6rK7dQJ/J8qvqdRQY9gWnC1b9VC1dBb1EIX/pYWWAfPf99pYX8J /4e178rvL2ohxetKjapbqNJzC9bhjyH121Zv4RV+0w11i4odLD+8g9W/h54/MRXdiAC1LFWB MBV4jmJyd0JbLx94mzqoiosuXbBEgTPUciTRWZ6jbt/6QUviMpIKrLT7YceaLEIar1h1EVlI mhM6Ib8wP9iMKAGS3Y3O3Bhb7DZ7zZll1uQckDGgUMsq0xfTAy+tUGvzFwTd8JpKzg01nul+ rew9IWKXHp/KD+LtLxHrcrMCA62dwciSzlesM9MbdQsUOacUlynydJvRMbW/EeUMllMflV1i ebCgI4+GanpOGbeojAFcap9ilVAKv2XnCHIZjjWpcUbIxXwEv18lyUzbzgQUzL2KEzDcJ/JO M/opn7vbjK5v12Y4aECFZ2EJV+R+rRQ1fUniAihE4WEl8Rhb1C2PPJ1tFAQBup7w3pTeJBpE ahjYvagShIgxZxThyzc+aSrSjOPFyH/jYhpfYZVEdDoZkliYlTdBLw4TK6EGVi0GWR+uQ8wM q6BjQnVPvZMg3rixVeoz4fqW7+hiTCRXvNQlzjnYiJfqlTvPMMP62LFximteYbAUVYCJ1Ldl bl2udLunPCNV7PiT44wijazu5Sg4yOixjc9rf/6fs+mf/+dyKvRuu4bByiP46yn8BOwktGFl 8xlFzeD30TAZjycY0JZd6M/FJB7S550aUL3R7PJNbRd+ukxQdQL9Pq8BaNKL7E2NlCnQ+QzG nQH8Lob5OIeO//D69VN49HvDBLNgVfWGHPDlNDmHdrN8WIvaB61+/00NFv4RaLZN76/yLB7m INP2oz5WzOozfVejntNT0+sHgKgkWcdt/gOo/58VgwMgIYg9mY3wH/oL4YOAutz9825T6oAS zu+nGKBzBWz2rn1bpCZRn2G2iTbN6Ogq9aou6T40tehtRDDZMhDbSfbRWS340I14Aoa9o4rl LunjqSJaMOfIL9LNxeq8cTKbEbc7SWewN/9GYtgO1WlWjmkFNB6aZB6yKtN3Ziy68XSauxob q9CJAYnW/Zji7VKCPVU5kmlyTk88b9J8Q6ccfhlJOhMyiMYCJTQ9s/uvhpPnzIZHHSGAGRJV r+pUOayveaB5H2TjAWaXeYKfgHy23nYPuoOfLEbGZn2rWGCf6VFtXN6pdTr4Dn3d2lRh3e9L mCfU3v+KmV0zTtL1q9sz/9xydMG/CiA8Ts3rvTxa+BfzhFa1rE2kXljjVXz+pGa9crvv6V9+ 7Vd3H61fQk95XdGvygtxheYlUKLhZSXg4C9dZcscqZZLQKtnW95C+U9lU/1FYMXy+/K2/hdy xK2235de3e/228dHIFUM7LZDSVVThBBWZrVsHqopCC5pMTSnhCHpY31V68DApefXPgjD+61B SzVtvT3uuYxe1Ao1VE/F2OFf3ceDaKipD+LKLXaaBqUz6q/H2VaojerBaRp8wmdhpaahCf+6 Qjvv+VX+Wbvhn1Zdo/sA0Afdo9NOtDHBVcmnFgtxllwoo4u5CfgmvL7U7IQ08Dh91zAo13I8 4aIDqeFdMMiS5CTkX5JSQjB8RWW/siswA1/NH/AixhnVNTOPAl1aFPOk1JGFrEoHjMIPCSN0 vTvLLydgMBdzXV/Z5PrsXKlG2X6c6RrW1V0ZdfRML+dCOboZUYlYHE475+kEqgrGFdb7Yh5S m3GsQgnsfvTlpSakrQ/FnGwvnPUz+SUZzmdKpJVExT6kDbogdBw2QXYrFbcgKbKne3VWhslu SyIyllvIgiAnrkzPte7tp9M1iQyM2oHpEYuM32LwOGbXpYJPFzlLy/5i5dLudva5dTP6gSrx ibBmXbUWprrIcAB9kLGRRj49OZJPmpEVLYUCk6C/3Qk5FNlnwP6RzwP9WkK84Nk8T6Y+2rgd ZpWwqyqzl3tyrpJlPcoyyyVgWulhUKx/pAJd2BcmFCjkZt8RQ32hXGEZJOSKOpcscCVeCx+L LlQE+qkp2TniAp4AYqdU8ohGwilW4ciKKuRw8V/niwmQC83GuEs0O233tB7l4x414xGCj5UW n63LJFPqioWcOKjOWYPqEuftGpRppygQnAyN+cKUCS0NCT2rEpWilY9WPPSKz1C3GZ5XdXji 65jKNmYjWkUR+bFb4os0Gd+gPWZ6xSmWrJMCmDMaKzdBnmedYOTiSMydmPgHyrakTPkiqXvr 4YwPQToUOIwGN/BUcnUUAyaEZdUGS/DbVfxLejW/isbQWTa8kcxsbLrK2DO4gkJozzscPfll QixCbC5zy+rrD+J0k2IcIbqkK19RPUMpXaAOwgjpbpJVzQdtt5lKQaDaOB1WzIZn4HQ1Yyiy 5+UEDdlTKmTM2znMR3yDMB4pOoZw8HctGY+xt0vMDyHF3igN1LluoQYyHJ+arr/9hSp6iRFY 2EY0sEpBovmMMlLZXXkEyjkooZkR5pVkEk1lzMTQNUFVZ9DxqWZSQLPn05nPTCw+AfiLT0HL vsgB4qcvgzN9IDRz6a24Wif64otOdLM60WeiEz1RHvfvMEwE/eCNYjTg0vCy9mcnoxaKHa0J 569FhDmIbxLP24+oIibOsl4b42vaxUOdWt+tYOYhl++WrPWdfH0oJw8KLrJqRCiVZ4lxFqpP NbAprQ0m8TqBjZxiaVJUJwY1qqQz1f5QEheq8/DHUY1tZ6YkVzlnnzvZhZ2JuakBIsPgtF8V s9PKdOxAVCNvFTfSGw6w8pFxqKtyl9GClHUEA9v/Crd/x93+AYIafUkVKoW3f6Zes2I8OPAN VyzuXrBk4lCcrQpsZexc2QHbXnhER1dt96srRDsjz9Hxe0w1nbXan0mesQKwjxJeGoP2yZMu COH58GPiut44Yj4vwMY/tQTs2ImyCGapB2zlyIxCFfGQviliDWZCTYPRGYfK0l+w5bc8FdEQ 8G7MEkkdHbpszm1TG6bgNJlJVLGQsiZegnO4C3Ja/9n6ghpSaFK0UU1LXzGR6syJk6oOoGAm SbMSuBznlOkEm1WrYq9/hW+NMbBQY91xAzvmxeqv4ulF8SH6+RvY77P5RYOi6T5EqqN27+Ad NmjaH+hXApdFSBs2yBY33rDqylmK4ysNzExfsP2VQmq9SM899XIOG9/QKY3s1AqI3BapgB4u lFXd60QTPvlNZUFgl/kU8Ar3AyllQUISmc37RYkowyGQcHR7xhQlI5oTya4ykhBVbOAr0TKS USIqFhTLuRT+viIPq5m+t69KJyjiGhnosNB1sBeNxqjMUrKm5V1eJGhuczAkqjVrUQnF1KPy veLdclNup35W3oduMe8q+k3LUiFq5LhDBARL1PHm6pSseI813dvOJljOfBQRhQZO1UYJf9DR laHlkXLUxGSpBdjMyiJ6FkVst202d+S/zd3NHjY8WgIp1/WvYjpqPmZCm5xRgCd4jTyBVQPj JJ1gPXY6ZXLfeuEfWhutxIs4OumedNApDQ7QHNMMRBcU2018YUZ5yiMsSBiLWItXZH7uMGW2 3kbfUtxc3XAoiZD2ZD5B0qDHRK7P7usx5gNQp1YnnEem6onyHd6KVK1MFDwldFcti1QyqLHw zimH0c0zK/jjknzc4exkRktPMjwKp8Ib0Y0PB2gxbwZix5/dDNvzWd4Y5xc4yQHI1X4QDgdo iA6FxGugGVjqjAqwWY1RKJ9KbAX97RwkFUWIl6mUaIm2n1PuXiqvNXdyZ+lATGZxHTJ+jorm 44Pj98eng0H3sBOpjJuWw5i1yaIUGnjkhuLWJnS5t46MCk+LnFJ3RkoasKs5EutPnqMC5j3F 6EFWrATgYekk/eyVXsKuHEgJ8uhaOUQq22KYz9HzT+ZmZycdkeZ0XHbpginL/QZvfUySCS/J 8Jcgkn4qXxA6kStppYy22IO3FFTnW44CW8vUHJPc5CqJGWqJBWspj5w3rCRfRXiR69pwOJ8W jvIO60wW/hpm5Zg0AJzTewD9txH9rWwbb7GiNQD3gFVL5bwbKdVMBAketRlWOQpFKcTcouq4 WPYJD99si5nRy6LOFfcYl6lTsVuS3hXmR/IPANWO0zNRXQ11eZKzxKjgQnetySsn/UuflrqO 1EmULYP8fypUXDIDpefiokBak2fpE82KqjWKVk+a4vvKPIsJN4pUd05K71yorbEUdWj6IsWY NrRQJ9XKMtvYpPklV0+WZuzX6B/D1GjBkAmkEJblujO7h6D2mFftax6Vo2Q5Hk8gShpWVkNW aSHdCZfOVim2JXC6dvB0Waky9pGR63AQQ6BQJfF5ifxMV2NbUqf/fAiU5kMEmBJPCtT1JFVh mTodrjUzb1a7X7SCm9UKPhet4DuWYoR/i/qUj3yRYnD3WQ0aW4rBPkVeKontHcUZwicfVYJe l4ArjwqJolQ9nKseuJZT6jnZawobTl3AZaHlOuurnLh/pzhju5uDOLuYo0vA4/7fD7ZskfZn +OLDslPynIBgg+E9ekXDbFAqYZBEuuC3wMLj4CVkFZ83UU0SMFO0JmAJSDzOfPH5mUsrfYh+ vop/Yd644A+IEx84mhpJd6lljTIYu33DO1KqSWbA1vFaVNurRY+j2qB32qlFT6Lau9ZBv1Pb 8jr9A0FYabEA8tx8j97m7nEqDcrniN1z5A/1SCE9/JeE6vhZmukloB//OD7iSXzfOmj1DvnP d71O5+1p/6dQozbWZngSpSDv8NBPol/4D5qSARxOyUQe86qpLDFxvfwqglWAI9HKgfcM1OG9 xxLSvgXjyt80uPnWfGdaaxjpAGcYhHQS5h1eonqHtoi+b8CFprptvN6JaJ/+wP8cHQ86e9Zr ioPXUWmM8e0+B6ZJq8h0Btt6fHTwk+g+z12mnC89OC34prQUtTbN8QA2/EBpuKfY3Po6ZTOj NDPMhZ6IWjdNXNaONwnRCvoSPiEnpv6mLEX0gZHPeRcB1+8cdNqAgPALfNUAuloAcveOD62v ribhqOraD991eh3zIp0xHkX6kin+gZQoOgqXdvYcGVRylc60s0NokKEVqeT1XnDvj+0Bn9gf avVa2E/O7mPL6xZXK93qo/rE+ru6U3jFdOF1iydBdzumjob8OgIFvyuLhPw8Wdxg0fooGCUe 25NQ05Iu5cFp8SZBp6kV4+VuWjM4vdofa7pba4bSbQ2xjF6L/g/+hX+g+kr9eWH+hG/p3eAg 9Cb+7AJWLZGHQkcm7uy4Z17VJ5cf+8jAl+rE8J98YPDdCrgSI3V2w8fbOVI0wBsHjnRtRpIn icQK8uxKM886r5444vOIoaxAXgzGqxlGMgQWk3FRFnUmIPdjlkqM4I+QpYOhgsP8gXjRWJkw RLFI/DIWI8Pd0xc+j2/Ass4Swwmc/hAR3Sit0YLsBsY47u13em9/ska5Nx3g7gtmfCzLIF4A h90jJOd2Gr2l+VJQy3eUw8rGxHnJJtq7BTcG3hEif14IgxWf5QHFx+OdLSuK2z6cMXkmOCdI yys4mg/TYj6dikbhDB0z4yFm6EHFJE2RN9FXxp6CRPuIOZw6cTeP6jR39R1HMT+K9Lv7A/IM FUqwgwLFi6fPB9u7+L9/SGs9N/U6v11+vWk6JsLwiFb9CEmDmgh8zd/Sp+Peo+bG0MTZh90t Jw2b4CYIvX1MjEVBueMxp79EY4B26OTipaXdYOl2PL/KxII+n3BeN2mmtQD+PJ5tsZitikvb laWpJUdXcd9N9WrrJ36zNA/LWiHTKQ/5fAs9eZgPfsN8MAnl5/oOwsBduEIKGxRniZ8EVa1b 4YjwUHExZG1d+W4ywyLXvvqowWF7nfZpr9c5anca3f3Q2L7jsDeOdeBgdyibAnPvos/040Xx Ccxt0Ou+f9/psaYMdvv94WDBNB6/2IoUJQqwuc77K2T02H3JdG7XpXNArz0ypyhZy9SiTjl7 lOZpC6ZJyPwxdWd+Xpw9bUggm13n4tTCJnIDRfrSwjWBom6M6yB6hlKye1OpN9OAGX1A5E+Y iakQK5xh3/XjFZog64hh/IOUl9TOXjs8S6aIGI9Drm5UA0onnwyOrKbFqkAxzaqZJ3qjA3pR 7XF9o8wGiwX5V7zPljWlo0yKrDQATDzt7ge0GarOFYc5W5mgUG3BoewzumQwiDodbe/sluzQ uH5VLhmww9S/yAoqweNkI5UkPcpZ0O4HNagaoB8x1BlO/yMe9BG5dMaRcxHVdY6Mkvuw5FYx iZNoDyjI02RDcFToEhDhYqCuOqnotahkOBuVcWdyQMlVOkrR7TQK0Q49FK2C4MnrCpElbKmE fYr2R6vLDaITq9nJVZEqYdByHHjZM4iNZMCKJy0xWDUIY5kSQNCfUWXVLZcI2gog7ycW+YVf /mOEMmtkMxvCZQKeAjep1+H2YTRA3g8bdRfZzLngptbJqD4Q4s5PJQOZpLl36TThLIuYInU+ TlSGICHB9hQDp885Guf2ATB2Y5yNSWrBNdxVD7IQuxtJLSGmZveqlbXxuhNLNN0kLomajviE 3x+WBSj4a6bglkFQE+79eJY00CIeTTHqJEDEGQ8YA4oqLMXUHjcqUYWUCXZJlOSvI8u6bP2Y nbFjKnuYYO5XNOD8dQ5UbHe7ALqKTLzTzc7u3vPX8H/RP+hAGL+IUB/hLp4+3aP/gy4+L8Z4 L0aCOy6+s5rjEUkzr55uD57S8w8fpyISabymY6vp7vZgZ/f56+evK5pKhht4nzOPfH6kffaU kfaFj7RUFQfu2qM8a7xlhOtwHpEFHMgS9MX+KvLnP8YyTIzYW7JzfeOD4Tqq4tQkgM7jNknU qbNpPSlRXFPC5czQts9wOwoW/J/PhgbKZGrc1NQGnicz2B/eQCCvetfM7jgzUjnUiP2h7Gj3 Bk4k9r9ZgAbO1Tafq5f+uaKruj8/kzy1J6ZmtlwTT/CaCJwx4mONXIJWzPQqxYT0Yu1HxRCp pOpKL0mcqns/cIKXkZUHV0u6fHgTjiDCTZcNZ1VN1rA7CqQl83uRu4iYDKU/KKXJepec4QWC S6A/n84u7xOD6jKR+n6n3+51Twbd46N6//TwsAVNl18aWlVmXRc7y64LV78mjbafVl0UnwFV dxhVrayhbbOvPyC+tgDNrgpMr9mKehUMjE9CPEGNXRtRfounkgDewcxpenFB3tIhP5+Z5pwk x2eKIdNFEsZw3OhIdpXjYKztLiOquukC+K0uIguX1Qpsz2AqK4QcHs6zkgSujLUrsjm4TLVK e4HL8ZiVYE2l17LReRvReffps6fPK9DZb2uwGpjw3zj74+H9F1eeDbvyvBBXHsnl3aNs+W7S s5ZTKVAOu3LUCmSoFz8KGx3K2Xax0FP3/XfoPMFK4tnNRCd5iGpUDbzm6pdqWN2bNcQ1KuVd K9tf/Zx5pM3JsITbaE4GXlXcw1mT1jfxYoaUQZeyF3jM04wTnzl+ebpPSkHwOG0mzTr6uW59 QyRKFeH0jEWjJEOgzTMS9UIDl9ZxYt//4sdECdVVpESCkIwtn082i9jDSrZmt/PA/fKsBphh OSjROEvre3tgraqgLQVOPYiYYtmxKSNUsWFE/7Mb87PbES3eqyiuPL3QInydFknd7aC6coS3 imme29NC9Xlo4kHsDy8Ca4mbd4QzpGFCnVA9U6pPpFKPVnTvzNvuyateXrmEin7trvx9UNYK 6PIyTabk28dITckLmUXA5YZX5iH8mmhlyrB7arzFCzKl5hcs1CVzNG5FCfjspjyeA3137MXH 8DkeQ8tcLqS4nXPFBSSFR8ft46N3B932oOxfOwAq2j8xGmi0GqnageLF/5jfafWA9XDEBdNv PTo+acEV3zBfbfE+Q8eXKdaxYl02VSksyhIDAmcslVzSmShRQZgio52CXKEgw5l6qvO3UGgE 56PhUtmY7ETKWqpCiV75rzC2SX4qWVLfoEFu3VN6njiqS0l5rBSuMnZnE6MYLIc6wEDxF83d mr3F3vZ+SVewYW7mZVMLQybkX9d1cNmatlWFg95zo+3LpQULlYrHJ1MqYcb0Yk6eIXXPlb7W Ur+Q+6eyQZTiKXTxTIwGJYJZ96ZydqPLA7FnBnxRkNe1a9bHww8IOkR7J/8uJgh3ohLcYq/T vZPFwZsduysB0EebswYlJWjVHI0O4aHSJZTdQ8VrfYPDeRmo6DJygYcxBGW4lWHlQgBzMbNC UUJGnAbSman4obzLz3OflzChxmyELEyfRV0zrEFAla7KWXBbvE5L4MXNrPXIFrkQDhHV6gpG kuj83BhEMi8sVCfPMOlMamghS4K750W6UfgbzH5mJ94oyl1WnY9CUpXD1C6SjPKdI2yrY1T9 p5QUQONxs9n8sElFK3nxlcZL7Tgok8KYtAlEo8W5LJy9ScfVmVlHmi74kfH+/nEqcdbeybaf U3SWg/0O1J1qNsPSFhg98u02Q213G++5nwsMMVTJLvYRJSP8KtTwZytmmt788CH4HgUaYGx3 MJoBnw1ueJdBnqjShEJ8x5R4BE8slXAiCbfWh0NYXRUvwWQgEWNIoHHPb8z1Ezm/munmgNqm dvVY9jhDpS58N0vIndBEpDNy1v5QK4lVySjlojCEBIxsdAcknPlJakQxaeI8Csu40pc1uGgt 4bCU2iUQ0R3o5hV1Y3fUlfLcbR0e5/K05h5F95cs8XGergpZd+h3IaL0+07zaRQ1VHLKslec el41t+k9FUYHV9i8uPF7PoXDAO8UWNMQKeJ0Np84EY2cas7KIwIwxyl4Ds6qhBbz15TVDANo RzccLc5psNRpRlJj92d3hNM29bj8SM20MCuZcbLEyayEzHb6wa7JuVB3aPgwnEHWv9TtbLLO vexkkB3QjeJ0aXe0KI+lP4CrpHHOaCmLWAA5XzNy2rIXBYkKZlfj5c8UKPnhrqipMbMSMXea O/BWpok7bmrqxKKWuIiWHftK73OiNSu/IQtTE3PTNaPAhQZIPsccQRE7wZxRBj/u3VyRXHXG ztnn9KOzREoWAztZoNMotUX+QKy5ypmouRhBQVKLcfJNldZRiC4VGGE53u6IDohjwNC1l89M HyTZydHSfvb+nGB4KUgf3SQ6v14yEtyn8GsrE+Sc3YozTj9YmhMfWuBKZpdeKG9OLu3TcNnE cgJSFwHEr5SAbBKbLgCt2bOhDi8/m6PukfxITS1gN9ig7EtJd+55pOv6aUe/mcIAjaSBKGrP g4AAENCX2gPgRpQHOU/JiZtHUuUEi1nq7YHKc4B3bGCsMvV4/pSph+UA7CRHXkpEkPXst/oH JnU09W9yYaVyU3q5sML0RrDFpKlRKG3yAFRQIxsKX68QlsGUy45bN5hSpzI6qa8+D5G3MoXG /7ygzqN3zAm7Oba9+/sF3H4NDqAH3uffklpEpQwGBgydpQMDIEWVSt5qq72B6n5y7/L8gZ5x nuIhasrH4+BIuzjSaWbygbfcbnX4b6DtM2w7SK6gJZaXPweAYIn6x2fx8GOUZP6UwyAWsTy/ zrYCQzxX4LO6WWldLwINDRIj03GdxB8DDV9iw042nN4oYZbLmAdefYWvngD+RZPLKZqUk18m /CorPqxffHdc9QzzKZWoROqlW2NjMuKQvVkV1go3B+EdmsfOYAIeAe1kmubTqg7sHQoEJLxo vqY9VhMCysMRXjhf60oIOsKrRxm/E6qOVWaLFDXAqPdgB0plYciE2cnHSfOiWY/2u+8x62Sw +eH+8y2dnlbyc1tZ620yEN4kTrcYY6gPzh5DmhHc1/l0VDdEnLA+1BxPgj4SDATlSCBlggFh Ftd6VvmNORkQkPZcBOpzcrbBzis2ODBnH/bA3ReXJR9f9SScGZn2Tx8KTogK23KRUE7JaQMw MQx9kBdFb8UmGfQ1anDiGBTXuKIS3mjDcHuUCHAGAdzcJjp8ijsKkgMlkBmlBb681iHSp4gQ +gYQ7MrNj4QNaaUlvkQ/avxp0mCAlenFa74LTjPOeG2UKM6bS4tEVsg5QWlDKhZ4kvg6IlBJ 0nF5wliYJHtO0qtO3l8nYjHP1hGE1GKrSjnM7cLmLC3o3LD+HhESKIa7z0WDdQhGrBK4obNi 9W0lRYaZpSeGSFvKtbrWP1XlFDgT0rhMiX5hfyFOUZfaQGYxuchnnKRUE/FZBVTq3s5oYkE+ BZjaCVOIILWwVcnAW8x1UUO7A2dH2S3LmwTOUU2QGB8UzZ3VarsXg01nCTa8BkHy0FQlQd2k F01mMI8lAxxWc/8GQCFQxrJT6MqL7JbO4mya1UuQcsdeAWpBSLm7LlDD2TCYbNC4pD2ldK/n 6cUc0cQjWAI4E+ThsuYFlU7pf3d8erDPM6koC+OD/SyfXSrZieQxU1IhAEC7JxdJse0nVG3e RFoY5V1XMqgqzsoj+BgbGo1S+VvbzEZbLH5DRQMwAaBnuZkBLf9oqoxjkVUf5axCOJrmBQAd wFBUt5dwLSQI0ZVmZbnWWXllYnaVDN/YY01PrYJ40IhCM3icANH2ks4to6FuSuRF1E/ntVWc d10ReTwTnJcYVdp8IeGZuIQjk5RKC+PASK0tu9UkUazdOPmEVVqwyDwhj1vV0tkdZdLzJNOz BNm0oETVZkkhlUxj3lpV1QFJsoiVGSzK5iO8FyGqZ4OrQxwXhU4xzCc6ArbtVZV3bo8w7Vp4 Djj+7yqRnAoJ0MjhrIRHQqFIDcxxyTNbh5/D7Txz8t2GlS9k+GBElHyu9ArK2EYTxTY7nVXU y4a3eApWMRscCmCGWzDGGHeXb1E5g4MihELOppLeEkng66lpnAV7dmcm0YFDhHJOOmQPeEs3 RyxIWugT8oj+PEfHEVgF4aeHPTW4L2rN6OfOfndw3OtLdiOOtxb3uWlygUY9vAAIXN3WUcu9 3jlM6wbVt6OcKoBB85tk9peS+mVwqcJHFSqGyUE2HM/R96WUzt5RMFrljhgf9E0MogWnpgza osgcgdWdp6mueI1vaU2Yt5VDWDt+jMeFu3CY6xNhtXx9CuzHlHTExN+JBUTLpcT/uz2ZtQDj no413uKarEo4NRtgnjdpgH9XQFe5Uyn3h9Z7ep0p8OsL3cFTdAh369vwoZHUqxwSrfSAHJLu HTsvSSuhiRAFVvU6VZ4EaKXlfCeJMFAEFEd9Jvlaivb2byXrbXvPRcW/dXpvO73j/j+/fxZ5 r/bh1at3P6UXb974P0Evb1vD1t9Pn3dOP37/48HHo6Pv+8/f9d6dto7bLRBrXz37eHC0+6T7 16vp4fs/7TyPn+2XXNuh/3z65Eknb7X2/9ENjbGftt49bz27aP0pP+62DuZvP7ZaV9fl6UBP SBbL3zYD37U5vK0xuJkkeyihP1E+Yd+IgPBGqml8E2hNNtcimb057Tda/Xa3u2gEleofKGOO KuS96CW6y5VblL+RYAP/BuMfT3rH+939vcaTJ632YecJvMQKIQDmUeD17zu9fvf4aG8HROHy r1x1bfDTG2Cnx98KqjWHnhMfvwsjSWdvtoMA7w66S95A7HuzBOvwFVYt/fNw/3lwHr038P+N d6cHB43Qog67aLnovNl+/VIiJDjgJ/Rq60d6defp7ks7NijwKkU7hLekhGn/c0+h8VjkGgXo 85AefLMk4OHpQei8vlj5ZN/XHgQsPNti4bHdFxygto6Oj346PD7tu1Ye4LMbOzvPnkd2WZtW lmc3V/m88FhrcZVF3ryYldSkxK7XsL3hxaVmSSE3BZCcMf5MBV3CMpcIwMI/FHZtWP6FPRe0 QAVs3NB33Dciekk+odIdkS7dwbnJdHWcBT2JalTclYWjnybcd7GHt2IXPdKyBJO5wVlweopH IzSC11kWjDFdgqRFYwZKMyikg5RZP/rWjW4y3jXILIjkqN3gjCYsqLu0O8ptXQPwqqMcC7pR nVqYwyVBBFO/ToBPi4dooIoL2Eiavd2Pt2BZpAIVBdYp2ZY42AnyGcyR2d1oPEAVXdNxUHZQ lJLHoQI5j6RMaq2lsILBOC8Eg7GnR767NptY3Llijs8pZ+4ye62KJCS/oGuYd0Fai0DG7lOa j7WDjAwrcIOldEvqIrur60tVGDTh3OL63AFnlpNTf0KqcVJdcN5+MXS0XA7vKkmYN0dmkd29 cqbAxRZxsoAGOfyudhQr7XlORrU2QVJvH5moE/EndYG2Knxyy9aCc1KIcX4uch6fYt9XiMQB SoCS5bI7s/wjsL+NBrSaSykBGDzXOcOLfD6F17ruTag3ORP3iRJudQwji0yzKajVNqmXFHfu KUqcgfTG3e76s1LRlm+RICe5jPFZztUsZWroBX1tlH8v3W7tvfCNU25aqmbe3hvubN/E7w8D rHRg/RvkZSiOHovq6DtHqdbMLejZj3VhJE8oFT8ey8wk4W0SGIJaEcqHhhwbhsDwAWVaW4FO Q10Hk0JLkMio6EDf+IFahW9r/pywmUw4m8PU8DCS9oL0VPgNFcQwhrJHeBGR97jdEXZj15TS Cks6fQaG/tK882ayWor86WnRTA1aulowNdx8BARmnF8EmA107LeofQx0lLS1ONkQYXcx9js4 zJ+4RAyAjuEkyT2kLFTO9/A16VyDOjGFK8QnVVGBEhROC60RhB3j6aKDWjoeNdDSQHFI5/i9 Dq3EgMdy1CbV6Ugkos4ZQtUyQ500rP8a7RfT5JxKrNnvBljJHWYlrSxydvXxpb5C7Xjc3fen 47obGmUp6ZkYjcjkwZTWZwA8X8S+VcAdXzf+ANIdKydtQH29krPQdnRiLq99joj15oJejj09 XrsPS0WE4azYpXd3I567+BSiZetHhuNBl4xM3vvPosO0GDZVahoO3bLeWmgV7lEcS8QMOBoz tV1Yufjz3mD6UqOyEa2gDaybNBkji52RP98VmoNULFqhVG+wLr5y9S/Q7WHu4Sene4J+2thT rx2Z2kgYMWp7AjPacHq/djukC8e3jJU2BRa3sOFqIal4Y3C9LPcn5/BSF+wNLNOKx7nSTgtg AON2SxWx7Hx8SHdh51RuwQLrwerM6DJEYSJexOXDnocaHY2C1J1+maAD54W7oaZ2xJI4GMHo bneiH0diytTUSEvoACKqbsXqwCUFY12h0hQmjuq8S3rP7pNIP4sb1GasKk6QJMIaqEh5LKrA EbmblDbLYfEoQNLKIHPQOnp/2nrfYePQd61evzNo2i0wNasbsC1v4YjCrM7q2iFJ92fSHVKM Z91FT9gxep1PmhJMlVsOLFb3Iws/HbxrvFIrXjLB4Bz0TM3gKq3v0fGgjBYRucTithFWWohX OMN7KCqMbbFX8UP0h+09Rcjgds0/wmEhox0eQlVsPjYxqPZQbSCwOqJsNfbW3B/DeLL3BDWc TUuzh5/T0XZI9wYEv/zlup0seH9nvddDyr8Fr794EXj/PlVzent3Stsbl3a3RMQ3t595dh4C 1Tq7WdHFem8/CKx3DawtEIfvJufi38ixeRnCMeQ9OpifjngZJhjMKKLP6xXS+JKNL1qGzcGR Fry/u97r22uexZ2Qon3RdELzeRAEebZH5TBzKeNMXoZEzkcp6qRyStvJHrTse+CQWwsNHgJx nkUHeTFbMs/fEt485LkPyEu7LC89t+Ulrc5ZKi7dNW7Q8Ttz/Bg4xYnXFPlFa3pK4lIFkCrc 23y3FcaBi/STio6hJJkzcTRV6mVTVFC7e9i9sOaWFQ+S/UPz4ci6ssufW9dTxRzZ/XhjpWXX U1X6M1jA0O5qcKmYazUjTu5R5K73K/l5smtOgq5uBcr8Tk8YGCu/22GL3m60xdvPUYIUyncP +EHL5evGbLWUYrLHO0tuctLV5oUXuZ0WrpsRy8yU0P4iy6fl9DQ0dSk2h3kggXVNaXJjfwYg 8x1ZLzu9LGyndVjoCpv+ouwDuEdSKcx0VPuxUWuqDBLwsoIO7Yo4rOBmXKJLpDGRAGqO/OQJ 2kHELbcNI7w7Pm68bfXMyajVtXbLT1ypl1tzW9irVOKf2ljoqgZj1Hx0s5QeiGmCewbRhNMv Y7Q3oZlGw0o8l8hBApuMY3dSHrNUUNcpllt1A1mK8yg6ptq59P2+lRjCfr9xu8fpA9XO+sP2 n/SfiDSeS5HlU+nfEMFHu4ACAL1TWvITrnpMxlVdswUpgHnBK2hc3elTpGTb3CaLVOU+SViH 0rcp07HSzHBXddXDESocpD4JkK4czawr9wLsDUnNWFdc+RCv1JiqDTOB5HxFNA90YhUty0q9 tMlRnuPHeTaE66N/oXsTBpWtvpLYr5nNZSqcEkaLHu0VaLu7w+Ss6uIr9fP49dOnah+2MLRe O87/O5nm0eOnfhHL8GOC7ucZ1WNPRupGKsdAV3ZSqDpWHl/lnHxtkoIP2+b7XvIpVeZAeKcu aYgV5V4RrHxuatvNp0BEiasC4KA3tU8Nqx6+0BfM33IVck6aPX98p67iE4D0FcTBrDQ+4JA0 qOsqMHcAgg/7nvlgzb2rd3+cfErGvAU9RdVWnDk6NmGFmnwaGR+npjoUa50Jl+KseBLsQUtU eJUOvLzXsp6SiBB8SlTfqQS09vwrsc8qJ7psB/t/PzA7uMoEVIkh6NQqXbQ+RfN3T3V2O0C6 m7LOQgJogNuyEiXTA6rJV+7IYevHLkjSx2//2mkPsF7uA17MyLmM4+kFqpRwElJWnDZApK+V +qE7WdKpwLV+djNDEnjMNcpXpDk4DancQdKE0o5Pk38RL7ri/ocuMHM5rdSFvsHcYg4wp/Wu RMZ9t0yveTwcQF9M/mBtMg0PE6cbVK54ruomgthqu6OzKcmeDuOMzM+0YXRIV+rHWY1/SFfp 4DU8du7txRDxtZkPdyxwaVfxL+nV/MoyBbbRdCimxJW6Edc5rW1QThSW2mw1wq4c/0O4vRoq BrgzraCfXa7GnenNXozXocfbWZDwfkP7Sv4Pd95Vvab/xD119o9dzPnDYlqlY1F5XivvUSWZ ujsvsUrjp7q8AHvELwDGSfekc9A9Ymg8DLoOVVLDeEVMk9AgcrJULpVEh+CH1e4PELZRamZ1 JAfhOcH7K/XS9VCs7mzNSl1oIReV1Y+3A+LqKr3ACQucnQWbXPVs3oSziiOn8eMcdH1mNOjG GTBT9JeEtPSXRbT0lwa09JfFswSmdX/Gk2dsPLFqh7WPjwbdo9POUtOJm5TN6KweK2+XLb1p vl1lsVFFKUD1UVIqWjedXRR4YJMpaROfRdGfltT+SJH1MnXnfvo7lQogMx49M79uukqIhjAA 8iEp62L12RzMpRnryinrhNhXp62TCdo9VZbe0Yl3nF1Dz/RkHE8KT4fjZJhQlw4n7lJeSxps M228ckGjQKCBh+HJehoqbCDmCrB6FC/Vgk5sJ7HhwdGx/1FhTBh6a92ewkGiMB8ByUCSC9pa IhULHKNPGAcCqOurVP/IXGLh+0mdD3v5WmVrd6QNH2iKUeAjyHEC0JyjphlLVMJY6qbwHeOB nnNm4ATjAtJ8RJYRXKhJ5qT69wEj4qY201jzFo9PJ4FpOIMD7yoXvdzW+tTlZgwi5+pc7G37 ZLa9Ythma/8bQlzK3f8mWFGp7UdbthcEW/4hSmbD8vsVcYDtMiX/gzgyW7BoBi6hwFdM2lZ5 0/8KgSVHogzJdW5GgfgsAPHSy8APq03onxwf9TumItkbBFWgyTHcG9l5/qY6PLXv71W/eq9K Ly7slmTPvbCTwzQZw1c+7AkVAlCqwIUHvdWf861uVS7c7/YBB46w6Jjc61HlxV7tElF5ZTMK lS5Za1TrmlWBE7EdbKhD4N1bxDbed0HkGV/HNwWHvCc2HbFvdmDfSblJhFWnwuhbmTIwV0dW oHMAUfFB++SJF7r0mCUzrH9eqKA88ciAvd1Swq704ThAOPSPI64ugG+AiUv8ZvwpT0c6A4DV kjOnFLP58COHFJiOYIqNH1rdQUWSrvXYZGtbfJz2EmJgvMiejr00FwCm7tTg9S8Bu0//QtBX gj+wMlo69si/RH4y+DXIVeArjMYYTfNJYUGdsgSVQLTim/d3hF/wEbYqOnJc/ruflh/grsqo gfwqcI5XizycjhY7OAWiv/TTfGaGQhGWQg9ns3LUBh7Lmpq/ybcRmyw2Ktc0l08HWCTXJjGI g1C5E/6kbiCJ1GqWfTpUGKxDVTAvkk681zU5hfuVKfDgpGK2K6RSxOFN8/kFVcPUkVIm6lrS hDgjmlQqVrqVWSkFEkGQWtPGlf01xLPFqtFqssEo7vqGs4zoVCKCBH4EV+JAuc5Vm7AWmp32 iD3zU+Mb5kAngLhcDaD52iCuFm+WIu7PFiu+KIVxHP182D3sfMBcmCC9zMecjEm7UYu1ZiFW UxrIvqTS5sCza2OqmVCuxJkXRh54kFBguiSK7LI/IMxgepiOMgnlrUWk8gU/fTvSUcisYoKG 485cUU1rvbyI/RaxmRZppjzl+bks3dP4WYl28CSq6gQrQdkT2exJ4BpxGYS0MKT0p9JBYa6i eGwkbufmlJIzHNg4TBYAehlGqsISTy2UVOkdl6JkiDxuhHo+jzh3o2QiV+kBy3RTzbVmY0kw U7+pFlHO/tSWErgpSp0FFQjPTSYzU61FzNz6/HNItt3TzzCXD1qQR7qokieoxIiUN9PoBaQi ECGg3dGL5nO7G50MVJrTEosolGzPC1gnlN5Ry0/tJPyEzcy+kApBuTriGHYXTgrNY8Q3bO0l 14z4akE1iErVVOJl1KLxZ/fs4Sz9DeZTiitVmo3Adqt1CED8nQ0ns+LDR3GxIKn5N5Tkk7W7 IbojNxcHUissUWG+fmZVZVbxk2pzT1kIgosZdnS4VZouCw4pKT4o2dqYi58I9tuDApp4gECf z8DZUT65KssWZexyTgpMh1D6lnm6cEmmnJIIknBix+M5JQPRMdM6BtnMMkDZS1KXnSUeGq3I 82uKV2KKMbv7vXC1OKf+RqcqB92jqHgZzMZOssgAqx6SHEpvrCBG3B/LLzVmtq0UQsZ4ytqU 6nsKg9irr6m7xHyvVH6mKni74mU7iBtnbsdwVzQJxXK79vLKpiqs20CzFNnNa14awE0u2LeJ 3u7ug2xC8dkmJpsirrW53GHHrrzobMqOQLHZp+9DKmx8Z0FstgOnugTezicO25aXAfolQJvm +FsO0PbBrgWGLzHaKkY7pCirCL+WdC1W/PXpaleWoSzzSbYgZ2I/EIIL3y1ttEaw3v1dWQ78 yvHN7DFkQ+/0/brQu5jm88n68Fuh2XoQXBRSvtbb27vPVjDa3McG7ZY2aMHFuflN2o0OeNRV Y58feBtLbOTi10uxzkvm8plO5Z0Cnc0Obx4hVsKZW0Q+bxIlPqcjzgspEbdtVZg8Oj4+WeqF syR+eUn4ss/be4IsUHE2pWsdDyenBC5MGcCU/S6sDWGngxT17VKylCmSnYIMb3tySVD+d1WC tWebErUOzMMvaoMs0jyzSgWy1crdSuLWKAkpas4kNbgRiP7yYfHomMGR7CujUUQbpdxuKBh0 lMYX0/iq1Imy0y07YHC8sFNsZ74sX36Iofbn+0NPym9rVz81VZvLZX4tKTXQFeU327ET5SqN MhKkQB+Mi7ZSReoAWfn9kL3ODXeJL2nNuGdKbbdOmlE79OJj4m+p6y02TjELiGnbiQyNXVsU tEonpBZHW7b0WEJbrS+XZILT9OJyVqgDBGiSzRKTy48ERimmC5viKbm4B1l2SYDQK1miEX+x K1tgbwJQhdk0ZUP0AM+FvwV6Z1AgVOees/zjuS88M0FmWQrsNbDVoGhKsL/xZysSsxM4BEVK +33aPfmWCN2nWciMF+JWZ7f70CNytgaVvYHBig4rUhlNiat6yBIHIxvorIIyO5AoT77AJTXh CbmaYeHufDy/ykz+XIPqkgeBLbkgIDljqnQMsSM+qVKJdXIWU5Kt0iQbNYHdEyeuTSVGndMv Crh8MKNzMeICYkBAj6yRE6Z8Pp/S/IbjeKpqgk30mqcgtQMpCipQaeP0ppjU2AIOdVo8AJqu qgirbvA9eWZuOixeHqcrE4p7nKG8jPkLYAJWCgY6TE4THUPfUhHr+aptn+q/uvJ6oe1vGksO UZ2N6vaqTvQEDudSEyPVvbnht97gytP/lJL/bZs5l+dQ3c1yCC96nK42yGX/cJmOmTJYZEV8 G4fKuY3OmVojaTBSjyWaTyeYJET0HHi3EH4z9U/gSuHso5oCUa+514kMECQrU6OdiSMpXdHo D1qD0z4dnCQGCez7dusAnZd7IYuyDDqcJjE5ml4BD8ehCaNEivfm2iatwgGFsDi0/twf3080 ozAZukLtW26TKK+nQav3vjPoC6lySZlcAIpkDW0bmN2NUv2ZDCj5dEQpXLmmC1yoPAyrnuR+ pXdKFBN/kGFjy6nDn8KSq/iZuoot5qrd62Ag0TKV/0LW/7Yaf3uJX69c4tmp5CpoU8bgoeEH nKG5krNlPhgFc79yFWf0Qo3hvEwfA5NWmfuVazebm2tqn1CxIia/UGmEUkusxfw2HqHWv7B+ XFoSVLZNJCbLlYMBoryavOu0hFc3E0Is/K/KuyMUU1DTdTQf2vAIMCQyutRYuOFiaDL09RSv esTZIh1pe6TdiSYTT2R10lIso8oFBLrF4dmBUfbflZ0pMIJ+IU9KAoXGBxEGZ/mE3Q/Y2Zxy +XmOKlYg3vFMuSs5YLBoX5vT7ZYR3eUPlzINbYU6T07UVuCjeQnFDS25wuyvF19x/hacROVH 8wiEeqctEijIaWg+cdove3SonuZb12quIuesCI0VA/DUo+0xfiP7czMyyU2sRzNXip77Nt5m 9DMWbmuc9I5PPpivNYODpgN8IbLKva0zeX04nUbezNvHh4cUAWs97sxjm88zuLzOTB7rs1qn dOXwLyW1qK/VC8dIQNvB8f4x/Oevx6e9o9bBlrckkKAP97vuigz31z2Xn5UxRy7H9aYyk5Le wM+Q+0XGqe/X2h3JoCVSGBJjONyfUkwSv04/+jZfsMtBTLtfPMNBDzuD744XodaZupma5RnL jeI0VjNWjTUpzqccJrEYCIax1I8AwX8Ta0AfHLb6g45+14oULr991DrsRPaj3i6/evzDUcea gFpV+cVe54DXpF+Mwi8O/uFhuwxefrOEBfdMa4Jb4Cw+ojmEwN9zF1UN0P3O0U/2m2ZRGCJQ t4/pGeVTWmddhvK977WOBjgJGm+dPqzIR1x+M7AG7tx6HmINm17EQ2NXCbfoTnEaBnFL5Xww b1Xi1mHrx16nf3oAst0Kr3ImoOW90jxtklF1sksLqnrxs4OewxftJwj61mAABLhjoBR8q4+C +VHbekvRXl+7lJ6bOOZ1VnVBcoCkLnq63t3vKYdgCj5bR2s4Bb7K3jx987VZu04FdsrtTn3O ZXsx5AmmrbZJcllJUAed98e9bmc5JrcPWv1+ZD2V9wkyj86+L3jzCGZpvxmcJDEDFgAq+9vv 9Nu97slAc90aRRaDdx/xL7Ie3S7VSfii/dNei3peOY+nehboLdX4/UHr0BKagosbkJ/pkpfU JNUTXAktV3swr7OUhcvoWLmv6KkgtL3Tg6Vvve8cR85TuemAl4PG4fF+912XkaT6zeN2EDgB su3zqPqcou8u/v9kHA+Ty3w8wrARMUNc5Z/W4/aBu79KZnEDo4jRA7jkBcyzOe69bx3BLaJ5 pNCUT3pdOMgDQ1sqF9fzdim8Ab1O+7TXQ4Lb6NpgjThADdBpmpwnUzJIorEnW2vltpYdY34w Ibjv3rHssa2IrO7wvR8WP0Yfo9JrykFdpxM5DSHOB1h1pFuNgcLkCjg7+ubKt/og17Y1nTa7 MSjZKEQaj0rFGhY+ZBvIz5XCOzAF79hW3NJqGfqtyhtlAHxn39YUVWLsae8gcp7KN38kdqfT 0+cgOMnPzRgBa9Q6aPUOrVeC84RrvO0QrNCS4SXsy3AIJb5oG09rsFb8soenyeZtzdqsmBtZ PQWmnq84onoFLrdSAQzveq9EgtI1qCBi3YG9zglwFRpEayyo+v5rql7VExjX5SI2N7LHWS6A zaDXff9+8V1SOkcVG+KdI3WKQodo+cEojUAavch57kN82JD04AsPIhDcYnvXlR0s3jZ0uh5c dnBvJGSMbnUjLb2QftcSyTKBZHMCgauC1BPoVtGkNUWCxYJNlTjijN65Lff1Xy2KbFISuVdB JPhSB5jZo0EDTubJQQd26r6kFcKsDUgsGxBY7iivbEJcuQdpJfhShbDyUDfDHUUVubopIvI8 Uii6v5ZC8KjT2e83mH1fq2H3CBkqAF6/DlcsIPTBQWc/MPtVZKJAszsKSLdj7bjTh5B57izy bEDi+SLwfBF4bifwiO+C9cqKAk/gpRLnSXzDEllhc3znSqzCQ4smi3RldKnYXf3eRY9NssCr M7a/Lc35XVXd1dzjOpOljEBf9N3y1mq82TrG3rUWgNUZMcN88xYaGntQ7iMw89UV4CWNjl7k Emvwf5A6vDSd79/1Op23p30HLItbYBHEfxwf2V4Wvk+YtXF++dJlD5bCeELxnkQAOLRpPWIF jf/Nvu/mSwb9fuung+777ywOyp+5nZfF87xe9iQpnnjESHRvI3+4dZrruZWnjf9zbrYF7JfH MPB9EH7RIdcaEjYTS8Rj85brEmEKDk6zu5/BB/+wPH8WAnPwj+N37/riA7nspXe948OlLxG9 rnrJoSAVXLFHQe6XevCAqzMkGvvV87TCsxL/9wWno5Wfe8Dp3x66LkDBkoNtaE6Df3iX9YNe 1cHZbzDAULLR9vxIbJPEnGNw/AiudeJWTgjH1ghaKf1R8bjIbn+oDmBxNyTgOR5VOG6H/Nar J4AtAtEjWpSqih0pdbIo5kF1okMb03I01bJHpcdQASDr0fdY5ufPuqRkxlnLk3LxKSswywrS K43gP9sWCVzaRfn0lfzUKyhMaQFV3vzN6I9Of2adRzmnt+YxJyav2loAnlbR6Ci8PC/sZwl2 BTx8VwXInSDCg24cJrIkV0ttI54MfB0XbvzoOsMX8afVTomNquzof43/UFK7ArtZV30Qj+Pp VUiZFdogj9aFtt6X0x5k6/Wg66zcwpSq3Q8t0NfGPsgC1aAPsD4/juBB1seDbvjshlbnOw89 yOpo0I0sbl3SRCP/N1AmnzTdXwqp5zrTgZP7SbENR8m1jtf3Uw+p/HYmln52nTsh5EU0Ss/P AW6Z4Z6mRTPqul4JyJCVcnM7pc1SnUSi5eQUs3vhHF+Ung4L+Li55JbnoHFqm0WlX9Bwgb4c g59OOntRuLIZCwLf+KraNqZ+0OrsN5oBKY+RS/E0TPsPYGt0smGOkbJ7L8+8anRrVkhrLyq0 ZTWsmhkbPPZE0in9zIx/RaGuyte5gtezBcsQwaP0gooPlS7+HVgRSuV7kmj3zbxoxMUwTb9R iW3fdI4a82LvbToePyqifg7UZBoNkthPgAgdUdDq3lnqKal5w1Sk7N5VnI5nOb22IJ8irh0E 6r3T/j9PSuE19sIDa6aw0L3tnd1nfkZE+JGiG/dOT47e4Ay+YeeCN3/85vjtXzvtwZs/lltI QbTAQPJLFezX3hw/peeqm3MYT29gc+CWKShVVuhQhaUivWtX0MUKu4av3fuu+RlqnV3DGdzr rvHPVcd79UqJoXz9+OVKdR+l5GC5dRQdnwy6R++O39RIWN6Lz4ajpOa9+AfxrcIJSKYTUyCF c9ZJURNUwyS6+qhvx4B+sEpNE/+JHlM2s63ynCppaV+TQ7Wi8gvrEMT+nnf97wUhXF3B8E4z vdvQD5A918/U49iF73alL8dZdaOHaA9nUn9z2m+0+u1ud0H/D36dW4eoutf7uOuZ5Adm5Fz5 gRtBJhUoBVt6VYwSe6/hebr79OVg+xXVvS+/eSpAqLg0KULU6uZ1RTdiwd7rXiGliQG1DxMu uVx6lU5KRT3b/wQS3F+j1Cv+tri6ayWWrkK4qjHGIsBroWmIGr4uv1O5x0sntUrvpXdCtYEX TeGzEGvMdjU1dbVI0pNEaIpFe0xM4RbdzegSF0hrZpLBFZhy0CoWhlm0ruLZ8BLTaOGXYmoo VTbV3rAqCaBKe5dn5jc1J0wuzB0VW8uS874wcvJOQE7mu4kVP36OZCzzIdgXyXwKtAtQrY2R VlHRgrmCJNbUGkfzTLJ3JSNaYjG8TEbzMcnI2WzK+WtNQg2djYky6Cl5WUFKrblZeWlad6X6 vMYN6V+HpS6Cl6C8pV42pER9YxEQ3aMhG40d9aVzaakvV7mqvKEJnIu+0/Dee5/MWuNxOuie pNnf58k8cV7Z63cOsJQvojpZfCWFF+uwfviu0+soN8L/8yZ6xBN/pLqgQ+yMa468840FKs45 3jfpyNe9E4IXgPSkOvR2qB/ajjL1Vl+vRJW9oQwUgtzqN+onD2R9D0B9BaANUj0n+XwUNYhM SfEbcy69xJakQfywmNi8VMRm16oV3qEQos+SfjRy2bCvb5eBVLLUSmLIFTKQWrlHvV+USpJa 664q846qvKGlbpROsjJr6dL0orIt5fSivFrb7ppXOrUOzI1m6dV5q27cRJo4U+V4wEMEMnrS D57VdwPZPKNb5vMc3CGf59qeEatl83S6CbtCbCqVZzmT5xqNg3k812g/DWbx9DtwPt8uo6fX Rzi3pjtuwG/DOG5sJFnlzMtVuUZTSWsZSFW5RicTldUynKmyHEcQBSDNFMZvGvC1KSeJjNdJ ExmFssj5FkV4SjnkxEj3F//FUgY5a3sPUlVRvcjHc6ISVItvLfDCdXalizfSNXa1pt+z5qPL U3cz2lWt0Vzz+tEbeIQhcmc3UnuN5ve/c0xLv17OBXLIRhJYslsGtksPjkSLR/MaPaRnnFyO v0HPuOpjELoMPGts8Owt6DFAUNejpwsp5Z1d3Mr+bSGfNR9IZadA9RxLKJF+qWDb+coTUoyi 2yDgxOC98cfIfzRFNN4L7F5wG/cF23dhAWj8AODI8l/VoOGXNDu4xiwIlJuDUMC/494hVE6E G4AQvmTB53Nh0HJfxXidiS117AmkEw0Ah1+6f/RBuncLCN3ed3El56dA9JSZhc/UVKzKfmWl Nekx729Z5cjowNarlx5m8+1XVgKTmt79QSnMpPKjocQv/UZhVHIP3DSIyrGCARDpl34vUNo0 kEqJ10JAwpf8a2j1mdwvhHxHzLvfRIueTQgOLudvD72QW1/4OCu4L+3uXtTFYqSFa/9cRRHa iNrzKXpAAkahaCF1AAtj4JIKrapqelhnw54tzei7/Bprm9WNX2pM2g1l2jKoqouCOd1weVYc Fi0TVM3Rkh1QvnXUeA11DkXqRzFOCceTeAoS7gyjhUe5lIdPrihyeCIFJN2jwmrJPAuMgrHg qLmeF1pqpMK0lDMBjWE6ZQ1MQJMuAaI7CtsJ42gIpwKzXhRJPIUvVGFDKbkYo3pnnEuWLM+5 z0CxjpXkMtynfH5xWTWLDLdE7G6xS6jSbJSgEikhF1jV7V+i46naC7VsCvT86S+o+YLtuSF1 o93TWWK2FOB9rXaNNtMjKWxcTaca5N6cADzCpIEQWSS4k7NkfBPYmC73r+yX0BSR+Joxz2iX U41vBExf/nRQvIjYiauuShdHybhIAmP/kCgYiTZOFQZWuvXsxuLLbOgG8etaAbBsCQ420ccW dwh3A2eh1fpGBEZkKHIslUxkOYhIuhAx6oRctUiTvdrw7BTR8d+aUSu78ePo4UdarapvbMMi J9VSYAF9c9YtVZwOl8w1m6SPq31AzeA/8OrnnFPDgJ9ShmDvXKUvs4kPHbDSqXTKIn+wZ7zQ zmK5ghnwS5gSOvghJXukHX0e7emO788xjLfwm/Bm35eLt/2hvcDxxvptiZOXYGLp55Ll/DzP yUYb9oO2TbXlXxfZw8USjt++sfew3Iux71b89nldq0IIwY5VS9FiXaeqO7pGrezxeWcHo/s4 ZNT280dT3Nf5Opy+DZ6w+8bwe/INC/g2vFK+Dc+Mb8P7zlGn1xp0kAwsc3A40uVl4W0yyHFd djaEh/0eIvLOmqejkgeAcXAQuDi/2vNSvIudqoZ6zdL/xTzayOGh1Xwq9p6vv1KKeXkjzyxu /1FheCfyA2tG3RkbhqbJkEwdVK1byQjC6nHObrLsXYzzsxjdKvQESuuXe7PqPgT0sBeIXrnK ewj+Sx49RIxfvGzExei8Mf54eVnxE/z5nJuzf9k9yWBkQ1OsKPJCIJDn048Iu0dsJp7Ew4/x BUnc0/TicuYwGQFsfK2w8bnBRmbE7+Zp8zkr/aq60IQ4/zGONrIrgTq+l3F2gewxC2BU69aa tQ1Qy/3Gqdob8LEJuKcyXIcxcshNdrShr25W8rSxe1JeNxuom4ugAdQC9lpNWZnzMETmOo8I 7aaJ1WdhVRa2ZxUbtw397iq89MK78Gfm2T54Xx8f7DdAmAZGxPvhqPND+IcFN+AGCU4XMxcK m0lpNElJRjuYscCjHItJoKE8iUFL+5SOM+vk1IG8Nyepeyt67PQTdpP6bZc8XqeDsK9UtMCS +R9e/vgy/pS4NZDXmYShYXYN5HV6+N6pl6xqIK/Vwy3qJWvXio24oDHlmN3KB20zTmhLvNCa YWy8//x2q5RIlkvfb7pygeQvhZHVU5mS7Uth5C+Fkb8URv5SGHnzoP9SGFk/soYvhZHdN78U Rubx+18KI7tv/VYLIy+v77AWPKP/tOrIa62+qlzEWp1orZul21un/Zf6yPbzpT4yPl/qIztP RbUwcmVZ66j+JqqFOYnhb10ubME9WFkvrJqd2ODYv6WKYZ+lssrD1FO+N6njbvV6bi11hI7k g4sdmyqd+R9eVfnzl1Wurqu8zi4tF4wqxRln/FtXVv4vF2Y+R62632Fx5eje6+Ot1c/9CDzr 9GDO7CYFnuBLq8k793hR3FHe2UiVZa/M8lpNf9uFlr9IWu6zgbrMv6XCzF9ELfnff6iodf+V nPH5767m/IC6vS/1nn8fPPQD8bPrzPw+mdu1OviPLf+MFZ3XWkRl+eem/l/4sQZV5Z8Dc/9S ANo8t7k7f/MFoNckXPFvpgD0Om1hyC8FoKMvBaC/FID+gtPh5x5w+j8WXX8HxaLvvNJlzwZj kZam1xTveD+g8JYJlqNVg4fsJJuLEve4cLM/VCZcdrc3lGVy1crTS8TyctyOFulWysiJfZRj R0oM/B3KTq+WlZPIXymd1GYKSW+4jnQFnbp9bdINp2asUvbxE1qfG0C1BFtKDtGbhofJgLiZ ItJr1ZA2g6cbKSG9Yp1WjaImHdbdyrTeqUrrUgTwhL6HOBG3qSW92RMUAoSnOX4IQNwlMeV6 RZm9CI21F3er5d0+W+KdKk4/xM7dod70WjTMuTbvXmt61VLTK1WafjAadl/JO/rhDIrn0yQ5 mxc3UYM4i4nKFCd530Y3WXwFIyLo4d/hfIyFIHUjuydUmmMaBGSTKTeeZFHhHCo3+Rzj0jUz lNQld0MdWTa7H8kwZgYhVXSBKjEnmQhlC3CT41EpUc72UMzi6UzVISXVmErPwPkEKW+ZPSxl Y9S1CjFNCKW1GEm6wsR4/GixBF7iBIlWYoE7ZjybBZIxcR6UNyxshJIxabliQTKm0hf3Xao6 EDlsZ15aVoiysvvPnepsQW6vtqmNuY1FLZ/tbA+2X1QUteTil9Z7u+H3FNrt/TVPHhXRPgX0 h2e8OD3VKqU9H3pxlWnO7phxy/1Scm4tKnrmI+IGqXAL6EeaOamT6pSjUxnsCqRMtbfzdExJ Bl7USkwf5h2Isf7I2U1UO0quocF5OkyicX52dlPD3hmIxcYyL36hQyvSoQrk1afWbOt62L9i 9z4ybP6IbSzl3Wc4fuV8Yy+fqnxjL+x8Y98vr+unM2h1jaLv61KaO8o0FmMu3mI4Tc/wyCJP 4rfoqax39rK/XjfbmN/rTnMHfqSEVfFsllxNZhFyKsySSfY7ZFhmSVTeOO8RNtAbYYU8ZV61 Re+1qvxkJzGm+o1UL7fPUuam4lKa2bTYW0YYNR1ijaf9k6Yk33fsr5tNJ52uEBTgOy+SWQOR LtQ9H6cVBz5p9eDc7qF/Sz4eNSYEJHRKsV+Sg1huvVrHWXK9bsc2YVipwQZvU67mO87zjyCa pVcpiFps/XZ18U2YzS/DZCIVjPusEE6yYj6lcmUze3qotWRNSzHDw/MpHqeApuccFpSQHxF0 2BJBQPU2n6DNHr+yO2t/1z3YB+iyu5cqAoyJKhERI9jHiMFt5YNrlhAZS6mVEu1xLnaj/7XS f7T7j1yB8zKFgz8dXlKaaZ1l+wESoG0uA1rk7dHauc8WUzjvKSc/U/nM1urGSX42XSWh2W1z mPmd3Hc6MWMMWjCLYEIvO2qoIqHXWjOZeRm9JEvXevt0nym9SkB58PxepRmsluzr+06z3DSU 7Mtv6ha6XGf6t0sRVjJVEuqV04OVXwpkBSu/VMoHFo6OKeUCK78UyANWfum/2oT+/X9efcoy bfYRuKyNX3rsytjl3xt3t6Bvzn5etp6v3HRVM3sZhptA3CrcW4gti56Nz/DrYGru25ZH2t5S dUqQITgzdU18bjO/zlgDBQevgHP8ozNUmhEXXvn2T83ocZuqBMNxRQH2MqL84IXvHa1TMpNa Cznzv2xpwqAEXT3n60SXUHLmrd3Xi+h8ml+VmB09T0qbQ3auv0Q/oKFCEF2zzCQX6NXYfYzS cyoMPEMGHSvYPP4BjQrW0LnUrRkRaPLJjeQxdnphcweOmQNE0iweN0sL3t1CBhctU3ERfcJU x+N0NqNyQMboEp8ht0oElasEYY5sd8rYPJ1F8WiEpaZ+iAtho6h6zlX8Lzj9VOEGqXM6K5W0 ebal60QRlMtlfBgPeN381V8+rCq+tzJtyAGZBQYgu5uFU7ST0VEyHqfEsLWmSdx4vl19a1iq Tv3FGhrOsj5T9aJ7M9pL/ZWltNTflTQIRgHJyyl16I4XluXhexHk97GC1Ayvv8burv4xII/r rqp60jBd2EdZA2BpBPUXoh5RNQ3k7xXqjqjKKqqNbuuDu1yMRX/v6nfLPdgrChZl+Ub/FoBB 319uXy/3/nSX20p3+dLoLnud1vKSHfehu7TJyir3DGku7UbeY9dQ0DZX4SJgKlLCYQwTWkXv iTrIgMpzXa1mSF25kIZtXp/ym0oov2D/Ss+XbPL3IMR50/2SQj4gxEQraZzWmUKFwknpkNbD Sq1vWqxD+ixqo1U1RXTr+A2/JIXXL0bhF3/vSeGXbFo51Xc4gvxLpu+Vn9tn+i6/FEjMV34p kFKi/NKX2Fl6vsTO/ubjDDc6/Jfo2cDzJXp2yfMletZ/6Uv0rHnr/lkHq81DGvZIRNhQZOwt 4mKDP/NPDhDtDxXqkNXiYqvEg4BU5KFLqUlICyEi2B1iYzWqfubY2EiF+dwpNlbLlpuJja2k Q8uNjurNP7r9qVUuiY1dA+hhQs5PaIW+bmjd+NjoIYDyYAGykY13DxcgG9mIOnvgANk7hsc+ xP7/LsJjHwIQny089iEW95mCYx9iaQ8WHOvQrwcLjl2JfD0Q/dog+9pD+2DnE3lpeCa8UEwp B42iQ0d0iF7V0fbTOka3wa+z6yTJoqevypFwyPhuv+bvcavRJtmMuhIKNoyLhJNAPrPRB9nn JB66sakcssp9MM8GfOV17jmp2MXMsd+zPP/o7fHjT7Bnw8tkNB8no60Iep0qKjrLbZ6wSba/ 83RazOQ7d8uwsDlfon1yp+dq3OzuDp+Y6ZVI3AS4xBGa4+ZjF89Vx1zWO0vUtaxECGnJnT1E iC3KLI7bR0UMaOmL+w5iK9lbeEXIce/9cvNvjlku/b4sxE1+58Css/wsbya/WEFZu5XTXSX4 VnQvdQoFrUsOyvqpb/mhxw7SLf/KYbtcNQ9jVN5EjyiydHf76UDOnR/Diw/CUymAMNDFbibH sqqZmMCgBSfGXTNE2PaOqfr1ngLn+iviOTvL+EGc+BxPZuhU9qYabW0fnilQ2fNk2uhkwxxt oXvRy7N0Vm5Q+qLyxPQXnZiyv09lz0vDnfteQDOh0+tQQHPfCWgm/Hla8R7g9158Nqw4k/CC HIS9wySRJARRP51GnfEsz8pvd6qCNxeuM7i07d0Vl7YbitV2lvYKb75VVnY2Re8D/hdX2cvP 0jVXWXFa+ktOy3Jqtu5JKTeP/qMPSxiJnq2IRM8XnA86GS/iYuSbyiwk6s+vroC7fjsfXSQB CG0GYzYalqh4J5XenTiy+dm/kuEMeSvS/pyn41mCSbmRvUJf46KOfLU9K8vrTWnXCps/hK6u L1NgtfDF05OjaJQn7NpCnj52VzFJBsiE5UVi90GectgknkySeKqCFJ35u7DqnuvxLkHo4J7J cmp7Fmnden4uDHM9Opu724fNz5BjHiUZOnlbXcGkrEnCUQQeNUIXMJmf3Y2AqC4TF08vWphJ zo9OY+PEFyrsbkwql2wEm01KRGL+UbyxNgm/C+Cb5epNQ4uDC7sp0gH3ZAvPZ1+c2LENdINB z8Q9h0FtD9zwveYVM52M/mKS5FQzypW0sojLcuQSSmm/7FPN3yPNXEwSPT/h3ear3wF18o5v ltvHLrtR0i2gHmy/d6bsSRGSFynwoDcUcZFF6Gx7w865RTJjqVE35ShtkuT8UqVam0A6kBiO PKaWmqqZOFROOQFPDfGwu3IIySpS4iaRfwlDDa1/6+j+WRDyHdBbpQmSKPY4mmK+LcrcgJ48 qAQQDcZjLY/ZE2LRbEulvvmiHyiv6HepH6iL3rP5R68HfCxNQZ2VoOV3WF8gnajKT2sqDvzW v3/9weYlot8dqVsqDS08MP21D8RSZmKzQnqp0foS+4oCu6yKzRNlKPGhsWe78zy4KjWB1vgq BxkC6X4zgMRcFHBvv9s/OWj550VdYRWTeRDdwma1cF9OUgiga7HlJfeYzaHC/YX37ejwvua2 CfD7+xzDfSmyuBX1Zzm6gdF3brQf50UiBn06J+GXX5U7JiYLDMn3yFKLNQZaSKIsfq25lIWy L3jnB+1Uv8dz/J7m2Nh2XjKXnvP1RvUwGgznCVqkUKugnYIYKJaWoSnV/YxzpQAJxSJ33/HR fl/FckhZ+bdOvB9KEcL6sdg57xc+UI2ddOoHUVYdpfBsytCPXL4s+iMzWbDU/uC41/HerdhC nfzLX+vD7W15V/1NRVHXqGx+B1so1PDZHbfSi13Wz29tLx2S9bn2Z5SOroYPvD+Ve/DwmxO4 l3b5Xtoxd1KfXQhQW9pWwb3+dWSpQfFofkpHmE2kSCg3Y2E60NHBj73EUZwLoNjSySyifqBV jGOg9+kpKo1QjTtNhjNPjQOvphNOXW65iJ7dRHHxkfxGOQOIdAJUBJNqoHrL7sRPpQnsseqq Gb1Dtw2V3Ld92uCYaaXIhy/snt6S3m2ETrNXwHpL7U+3y29w2cn5OZoP0uxTSm9BP2+dOXEz 1Uspu19bLVXUfZJxZchlHy+Ab5xJso/QhtgDqWhsakN507ircxX3dJFkAJ4x4JLW6ZNE4Svu NfTVMKVJezpyohRFwi7mmJykEFcVpOSYOoXysgA0fT9K0WJq9/QZuqdbDjbM+WCh0kH3RGEb azDtbs7iIi20Swpy8lGqpjCLPyYZpyX5GXv50HQy1AfO0jM5SzaHh75IOHn3VCnDgpfUAXH0 CmGP4xNiJCMOYdNIINpeePEyHrG+VL3oLOwGjxVre9ER6EbZWaCh3iVl1tBOQ2WLDgVDk6Ku GfVzOootMTElPDfUA9tYloy055HdkQyvx0aeVbnHwQ9XCtthftBXPJ/lmPhm6J31UTJEUiM+ 7bRwPrV61xA9JwgN6EWyC9gZ/AXSHT7NJRMO4ock3xkn8cUcERHRiTJ0F4Ik8VWBS0ynBnKc Gcee6U0+t0nIQTJDh7obtgEllOXnAvXmDIcYsHiY4Cpyv/D0u2k6gnYZoQW+7fQMG3RNmnNy OyNkt067AzrKBbL82q0UG82t64tfcuuenL496Pa/i4L9hUQzKS7+DcbmvDntPzmJ0cVtuLeD epKdndeDbdLjhVr1BuFWu093w610+fE92tFveZebvMt43fvCoWgv1MEl3TXuWOFumduKLOCN FUeQAsV7pQWaYu17J2iATdj8yxt/mY5HkdgRz9NkXPLzZGkQszTjdTcG3AFi8GJy5cu6FJm2 9w6E6zc/dDp/O/jpm/bx6dHgzbY/n0rRukKu3iAn2ZoxYk/ylOkE5sH6pM21kvdBLAlAYpyz 4aaB6BJpF/uWplXNqMUkjWy1zK3SiDHZMMbiCGx3ZOicGCf4jnCPJV6PD5Gv/7/MaLGGCeKP Yiqw3Q9Fdf9/PrfufsO+KXxvtghn8X7n4j7APU2v0iwRY6t1LQC3gKa5xAuvAHIxTa7QuyJ3 L+tm1IndHrSgLYN5Dguc9o7uYM6jPWJ+0a3aAONxGR4aTPbG7obOldwqdaUFxD9ODn6qR639 feDGW0BBD/A7IGT4FtGwjpfHBoPpO23MV9SQ39kILWQUYMagaxFTxUxGmWnoZpxKD527Cw10 BoDNsIyYk7nOpx+pX07j54KaGgPxcbLi8R1eyKKI1xvm2Xl6MZ8yryUMjdOVwJTbYP4/npB8 vQ+HYdDh3dR7FmfVc4q0k4pQVdNMM5xDLGwyDkBoIDAh3YyaLPZlaKblVSMsYT4d+RQWfkZ2 E8s6TWbpVfpvZvI0ro0om+WN2gN0iTc+/XZPCM9zYKgUa4LbgZLiFDlZhpj2R0duzCy2VEJK v6Pu7SibX51BT3SOPBbaZpt9mQMBxEx+hnyg2goLEWcY8kipHAvF6oZ4K9wP7oJ2BUTjJP3E EtMo54hJFwsAhGe5tyzh1cvITtcl3Jb5dBZn5OWW5TNOrx/ezlHOSZguKaucGWE+wZ2mYl9k +4dFYUyYxDFcS/alG3IWEZwjt7eZB7dBr3XUP9k7PmkB/I1zF4ppIkvTZd7HSY8TDClmrDn0 rEpXMZxL4uRlNgO4GlqDLqbHHsgJxBPi9hJ7CdLiEdDWFARQ+BlTkl7mwA06UAwIiM+VgGip W9TOVub38zZmIzn90J74G6pH8vusSOIsycjl12lxyb6cH5NkQt9Gk/nZGL9m2fgG6014lyHd hHBonU6xrRKm5X6070Qcg/kY4V+FNNbpHIm7o9OhGv146pGGVE9/lI4IFrgMvpGs446cA4zq 9vmLqYVhq80WH4UX6ijs2uku6Yb/chR+h8V5kGja4Ad8YK0ZUU6NnlQWEj36/oWp9sbpR5fG 63v6jKqyLEahlwqFntkoBLzh/SNQ9JvGoN8dCgU295Xa3Odmc4Hj/0Ibfu8b+1ptrFWjTVjx yr39TJu7xrJePVXLctI3k1D6W8PZ1Zka5UDhU/ZVSbuQc69PIe6cgLhP/LktPlMuYjRHKfCp rKqf0jhKD7snKM6XTaQo552hgW6GEkVZ/JXeYNy38xlHJTt+6pkE/XvdqjSwZesGC44U7C2H TGKlbyJl2yMNgwzs9ctgo7WexcOPTeIgmQfrK72mKnqAALhRBhIDFTI/et3S4lF0hC7GybkO r7F0N9BsnkTzbJaOlQCtNEfaYlKUu+V2yLmyeoBVstcEP4aiBuN8hrVPXbB5HYqBkEEmwBCg MUXEFYsfU13D5YoMKLhCC2G8ngmkVidhsDW9VosP97Y63K8smiWKpN/L4Q4sa0ct67VZlujJ /gNWJ54NlnxB5jEx/S32aUjUS2oRgMhJFk/T3FiLQWAb0YHysoKmGSA3qVlxOIQG6fniCaos pin6KRT5dNZgvVepN7sr6NntDU712U1EfvS9ZDifTjGDWiMd1QHtAa/hQz0a4em7mrg6Z6Lj VrZ1PElnWr2GaiuqCiJFi7U+tRCdm90VZR0Uw2oEOzQr6Y5apEBRFRRzuS3qjBnacaAmOFZT xRClKn3lWBg+pATVvixXKeHQtDMDOrxEZnglJvpd20TfFxKP9KhHSjT+xCBXbh4uuqhEH0rp 2BIrfBG9ZWLqmO3r+C0ZpstqLeUkwq2mCcaUYh0XVhyqu4XRrlXX3fu5kdhksl2PlO2EzYDs uY5BW+hk8SkZ39TZtIW3Hpq3ytGXpORkRrMe1aB98zzP0X5ZQ/3aOJ8Z5wpzxGNyw3A10xT9 xe42rJWU24aNa3jB4RdUXgf/uirQ9CHxmHY/3GSaqKjRVmMIcGgMGRLwX3t5ZWS0FDKUSy6x PHMIGQWkcIZy7BtnVBAz7pn06WaZOXTCwRC6qUvAr6P9xVNLj/OLC+akoI0HYjX9O1noF+Qg VK5wv1z+qzHyjccLjXvassdaGvdHx4vOWlGFz7dj6PNDKxa4DEjUwyhkP3QDLp6+FEcAPzTB jrbAl4JZISx3gYoV+abR1gD77XS+6fW/P3kz6J12vjmB2aDP+pujTme/73iJSdTDquDaaOel SBZxdehqZf+hHA/3vSV+AEGceQAXgczckZxK6bHEexuiQ1Hvyhu+xnhcc6akzAlbzF9y7DyZ qMJHOuT9ZsjCmr42IZguPGy/51MQRk6vm+gOJ2HNATZ+GjaI2/YlR7VJioQSlJG73ZxSctmY z3cnGaAL9+qaF2INsJC0TSWTsL8NuYX5uLDaZVJ2E5HradoY+e5VC91D/oB6gVXulfCEFriW eH4ltkcJ+5iYkFA5r4/8sK9Kr5KltPMzkdVuFulQfxKhyVGXsI9wDDO3ID6xPxahX1MzZfas NO4SYR1O4+FH1IAy3ynBvtF5KqwVphDzezCeLFphg9YG0WhingIi+yXH7ZANP57hEMBb5+ym kRa8nHnhZff4rR8NP73OoqPxQKcA9w6OgL6YHkXl/q2jEvbA+t0dlB/Qh6CYX4lrBCIR46NS 4gmeagOp2iIvIkJIVkl+wTMF3MkVyo5vQZbIxT+J83uQUEmDKpFGJ8/xjxF2xAJQIQVLFUck 89W8TgV/U1MXbQ2TeoCUiH40GPMBE2m1252TQWdfaABWbUVxSfySaTDnILJS7nh6EWcA0Sk6 tCqGIi607C2eXuQnPv2krjCHutCJuJ9DukBO0kcUrY3Bg7gqw/T7lnU066X2f2WJZkNCx32e 7HZdqUfYCRhVdHX79MGfY7yWrONX1/yaPS0+CrGrkTbIT19gWAApwOt4AqQY5hfM/uyYLQrx asy+J3H6Xpk7up0mVE+LjUyIfoi1HEMduBR2Wf1qTwmDxi4u0dhk5X2jE4HBQtCRItilruxe Yq76WszPWIU9UyFbRRFfJCqsJ83gsoEJz8jncMphgL6KOwlfUUodUPg3NKbYBhjMQxFCrXNs OtXqYGylDJHkgxXUC7S8g886cFb6wm6RiT586W7jQtVMS9dcllxLIq10wq4DxSyezdehD/+J SobbXz+/hXO+SSUY4B3JV+qmQYSpUk6j7buucM2fL2Ke8tm36s8vs6s8V3YVy7P1O2XSMqaU c+DkLktRjxJxh2lNyDm7HrUpoO8yzTiC9wzdAZjXLdEUf/ITVXhVR+yiQzYnO7+OJf/c8DIZ shMwG9HcoEc8W4lzTklg1EKqasPvtZXJwD+0tOaaWNKUlatOW1TWxuj92b7fO38+akz8pD+a DLCJ3P3xYW792xOBlc+rRBsqcvRisPN0Z3d31ydHn/FaxlOMSFbIbcOnReQh2w7MXCZrKMQT xT8GdEmi/mak1YPN6Duu6MD+W+YUPSZxL3NVhhyagxFzaGbFl9HWq07VVqRJzidcTqpu1xDs U1KkA3Ao9KQ1m8EJSNwDRguiMz+XsH+OeLG7UaQsVqBpRo+7KlKpoP5i29Oa+kUiclG2S1JY OwYvjNlS0OQFTeLhR+Y69MTmE1siDc4nGwndTS06u3uv5zhafJBvYaH7zzLC/S44g+oI4DKp evbbIVWB6/+Fuv53w24V5u5WB2kINAg5bJcXEAKlQ5mY7Mw4X7avsGpbln17oWjLw6TYMZCm bG6KFlKruthC1DzECUVphF0yirF4KBQliiY/+H3973/ffPzXvz6Gz7ly0lrrnH8R0/lZ9ZAe HLdbZFA8iKO3yRj41BNMeJOVYv+lcu3e4Q0crk8g/c44RUk8x7Qq9aj7aDwGARkuePhlfBNd 5GjPSGeP3NsJVU2JHzD8GZkSOZIqUYctFFiHoM4HhTy4skcz0SN46yKpZJTM4nRsmdZ3KdCV uGiRO2xp2ePw1V4aqXtbRyw52jWhL+IOHEIBdjqlzArIXJFOwRV5ulkxw1JSbVLBkw46wOYH mtL0ruNUcuggwyKmNEt1sI3uVHZH6IjrRR2imx4HYuV6BkyX7NHsTmDMZHxeBz4NVp9RzmuB SLsfimhmL0TaSKK5JQJNTClrI6mbUrZvsQrGvFZWlWrXx7pIXlp20nys3YUoe+qAIL/Iu5jO jcpOGeu28mUeKvseIVlpUSUm1+2mHmHR3U9pIuuR28LVgyrmF/cxbG7x7g3ck7L6R1ziXf2P pfJ5fDa/mihZsHBdGrfc05NvRtUj4YK/Xzq/Lj/32783NBfoL/4zKI4QDxUVVvgas+VCq5FK IeQBTeg96zAmjUnu/XQPzon/HZLSf6y74t0PoCeGvRw8fQ5i2Ovfrhj2UolhVkTsPplklote b02xIYrdUvzaOB8anoYM+9LeUpK42VbeVohMOPj9Eob0qpH4jjFfZKVlitLbmub1AWvNo3YO bM1+Pn3T8VPRf07RJb9OPrE5QeO2xcJpEcHEEbB9j9ShbhY+ZeqXNp8Njf00Rmuhs7/RC9C5 TPpe7+48e+5j42ZV+utzQvePQyCUNc44oZFO5wGy/UUKslXkSGHXio1SDL2NX/b8ZsqFMaOM Tmcg8HHjLHc6TNE6zXW/lOjjbb+dY8O7Cl7V/vw/Z9M//8/lVBa1Dau7jEfw11P4Ca4HaENZ U4GhQxkQv4+GcE9OON2q/lxM4iF93qnByRjNLt/UduGnywRzGEG/z2twLaQX2ZsapY2Fzmcw 7mwUnV0M8zGQhNofXhMp0+8NE4RLVW94q11Ok3NoN8uHtah90Or339Tg+H2EjbE39SrP4mFe jw77UR82MerzJqpRz+mp6fUDQOROHBy3+Y//eXL2Z3WCASQEsSezEf5DfyF8EFCXu39+1VQJ XUWUb+cgFcIdumuQ5Wh+BVMYGnF/iO9Edm1n9HQjDhq3cybFHUq+evGEDROIBuP4JplyNJiE ZlEEFncNOILuC4gfJb6c8pQty8C7n0fXCRlGkbdXbrClgf7ywe9nQHc74qqJB9Nz8vKAtFsH H5jMolrCW6ubKeRnjPD+IBWqTUCF9FcQSyJQHY08qd34KQdiEsVd2Qfs4r0qa3t0KEmMpt2/ W3UpajqIhGfPb2LuRp3bze7IVCcsTOg8qYfIjkaKQhd+sLyr+GPZOQSutPxqEmc3RHhQg4Jh nXA2xuFoMtPS6QbxOYpO0G2m4G/2CeqTko6pcafH6QpzZ0Q/0733ASBWShtcfvpzqXyJMNZO PgU2vgn7rZYfk4FDxUJa5dWdpt5c4cbWs42suVBoIOu72FcdHQPK/uflBytXtXsH7/C/TfvD 4mnsONNoieoTfbr4/mliulMO3aVUdGTrbCyZiyTcVhkDFESi+AovMlW7zVdN+w/RKU5TErMK NI7ax0eD7tFpB32eW2+Pe/417j9Dzg7AGRBBbFH4zJUJmSwkvuei/2DicOaodNZsnWo159Kt wzxbBhSsNoow4J5EnUwKwD5zBRgqli2bCzXADpQyljeRt43tU/FsSR885yX4uesgRimIA2Pq U3ZOL+YiEy4elbdLNqTOZIynjfTS8q1bBgCsP8klOijxg/jQQD/zDLiPa1R0x8t6kRw753PE hBj4FrTcB5BkCWJYKLQISVbZjkgK0lahyOI+bARaiCKLu9EItBKKvHBpR2ZRQ0wvkBBacKoi WBXSSF+L6j/TpEEJjPjYSxZFjXhrocjMUA8uZjqLbpKZpB1d5bQOKexzTp4mKuGSynN/Beyv bywuP7SjQ86/SU6gzMsz2gaLlJYfzmBauQ27ze3mM2cb2vEkPkvHKfADlERzPpkIdld28gwv I7sPnadJrG9SqYFLqC7o6EUzcq+1qDVHHJ6xL+p5nI7n02QPDqqeVhTPl26F6oHsWAlaVNLi qo4hKCP8JR4jjizrBfF5yeThLnQmj34HePmcqZnaM6nrz8tGlpknv0iOYk56O14yGaC/LiQF BWc6+QDV1AB2z4pcW0r0LvlwAEay0TKH8zGOJ5EqbbJKN3CtJym9LU4Uli/DNcwunQ7nS1kE Tg9CbsfWt4vbPI63KD+v7btRcPlryem6rAfNKkuwEaeAbRwdA1/x7qDbHiBQl/TBI7V6naOB 1XDBXpafx2dbTk6OR0XUOjg4/qGhp7HqOlhGwaUcHS9Epx9//NHBJ094O8wleVUq6Uiukqs8 WraJWJyGVBBYYvVD9fAvbd6cnhZxgOiMi9uXD+kSlxTHQrWXX+LzTOW1GkqRF8IL6xYq5yQp P6pu9CjElNofXgVWISTNWYUaljPAeBmpyw8dSPQ1Jmx2F0BS3NJDPUwSZtUXTN2jy0jbZqwr wmpLnPIPCJPw+EvGRF8U5Rx5lgxjJeyj/qzPu4cemPmyCxJTOeOs3anueFM9LdiDs0gvUFUm DGDUBVlW8U6XS3EFqC9ASVxCGMMeFaTQicbplV8G053QbmnbgavrDLqHHRHNEVVxteN4epFI nMkypJtwyRpmjNhBTOW7XTSXZ6vO5TyeKkScoLvtEiSkOd96Vs/9WVksE8xHsUs6aw7qXpbM SHYWGTBcwzxL4ZhG6cgSJ2F2ywiUCZkFHG1G1Wt4XT7c0CabJsP8IqNyVYpx41gfditcAJRt EvGxInQ+HjWAUgJkC5LH8TsAQCOyv1RDL15PSxQ0qQgcAOYxeecgVLm3cpr48tPrtLsnXVSC G2BKziwS8DPhfpdKkrgzFymGc1XMY+kxOE+mUzjU0ojlGOYnqPNVhBYUHxdvxI7bwLpk8P68 nM/IJjXKr7PF/Twr92NotZIyzuxcVcsIoBBPzY8ZWgrgyOdTrBW1pI/HeFVPb+rRKC0+1tsn p/UomQ238Lwx0aPulh4Uss7Cy5gSL14MBu+0Ixi6VqSdEW0o0eOIyNHyy2Cc4xW2n4zxzrwx nWjp3G6+VDe48IlImXlPpvPXtT+/spPCqTSBxkhebvT6KTWym7UcaSOUbDDQzbZ0Y3d0kF8A +TslX+W/JdOzZJoX0ffPFne0ozqyorA60ylwx32dvnBhB7vYgdUYq9etuIhn1NQvfRe9Q16o FfVhHcD0aQl1cTY9kITH38oHtBdGeB+gvDCKb+D+vwbUohJ/wn3ZKEa8lzE4Wp08yScxoHY6 ev06rBd3Ef1LZSb9VH+wajYtg3nlfFcp5iQeFHVykaiLg0Idzc9OHhKfVHFeEmpEmvY30SMy aL/cfjZ4yj4Yfv6RiJKWyHh06ZtGz6saPVDZqD9EM0ezRhrYqwRNn1p5RiZFVNK4ylK/oxET bLlmOEmp+05/j4wz30QXucrJyy6Ax3+DL+FAlrvtl6fcX/GscKl5P2sStI6OMW7kPH+zsGS9 GmMgBtVGJwPgAM3Zi16e+WICNih9UXnq+otOXd86VbyE8gu3Ox/9JcXS4HfX/Bioy2iWFToe 8KvjmISHgmoolnyO6E3tm0TvbVe8hw4h8MuzZ89evXr1euf1652Sd9GedjB6O44vo7NxXH6j 0uFj6ZJ4ArvPXj179fT1q6e7r3Aer14/e1ZyIzTzuApHZ5VXvbtbBR0fjjsVby5aWAUhCJyq e2ODXj/nW9xnAegWP5yPZ+nEusX9HMoPe41vP90u+U0sa4FI8OXid350qMyL8u8rkS/ci6qW LvS9dxbzAN/328cnneCBqf6wIvOwmHeAPsrMg887BPKbtTEJuss9+MxDucVD8A5ynS8lLfZl ijh+RYc+ns6eXKW/JKPQDX2GkTbx9OZNrdF41+nsvnz9dL/9srP7fPvV63brxctauU3pC5Tv Qm2rZ3c7duK/g5soH7X+koPe3wQ78R95966Mqu3OTvsLunov3PL2WB9d0Rr+jWvyfsBdfjgG 7QUzaFac/YBNcmszY6LqLzj4EytAmchKezVKl49x+NlQiniiLnY+YXd5SXRZzM/P0yF5F6mI e7sbUd36Zj/t6rUeYxZgJb6wZg/Jmm2Cw1pRQYOACzX+DEqaA/hvy4+6CHNbL0l5Uk2/Ak3u iYoQNTiP3qIXlMmABZ2mmB0DRSg0BlkmVs6Oo865PSc2d6DzYGK7dcohXiUqBtFaNdteAKH7 XDvZJmzqQ0Cgoqdxym6K5/Mp+cosWn/mOkeuuHpuswgzVuXTH+7SecmXjhVVyIYJqQ9I8VOX 6XgEnzDIEp1c0mX2glfcp1Xe8e9ztCAxsWiqw419f986aPUO9VemW6/L119iXjYb8/JaYl66 blaKLuI/ba8V+7LdjH4gHw/JH4rlsa/mV3Tbc0n1icEM9H5CfXIqhe1tRHbcDRgb6tH36KvE yPDX49PeUevgL83opHd8ctxvHWghwI1DlXuIWlHSd3U+vw5EwkSPR9OtPbSK3rA5+8yKhJHc Fhyl4vWyI+tOJT2Gyh2I1ZXQtZnDOMza/2JN257tUa6DPppRH4tH/S+dB3Je5fQmGJWCg1zV JRP+TakMVJGMtcfk0sUeIqWjBCgwcAyCPjujFHWk7VxtTwa1hyCDgfO+GxzkHsrtp0+/nMrN nsrtp3IsXVK7W7HZhNRFwqFX6DFWPFHpTeDkpdokmyXls0jeRRzlNeNfgW/Az8pJvds6wuiT i7SYiUOF1GtzurGCmYqEKoVFL/GMcGRT00Gf8lUBHGwNF22ZlvWk++TpHLxzTJCa8nOlgmTm VXFI1UKPl06m6hY/QopgHtKPR9+TFxc+VUFT3nOMBUgjVLE5by3yf1j+OF0BaA9bfQwSpueI /j3tdeVnBE1yFafGi4dTFS2Ys/9IKGSKRxeAWmDOJEU7lwYNOA/OAzDqtHewwIel3QeBwjw/ 0b/ugugVFW2nN3admQgSAM9IMq1ytKpLTdV1urKvD/z7Mi9miNcreCs7z6d0OpvHY2pPB2MB jPY771qnB4N/gqwCx182fdD5ccA/tyLS5xLZHhl/5DUmg1J2zPkk7IsAx1sPOohtcMNjIBFd +EhdJtE4+ZSM1+pH7XLRjDrx8JLK85KH9XoYCPMH1OnOGIHTbDiejxJ0pVsTkYXrWecUgez/ 9rT/E3qDdo/eHddFs3V8hLUv1ujo9ASdSlWildM+R9yu04Ngz/EPR5jZqhLJDls/4kjqIx9E /KZBHq0D9ihInpAEKd6s5/MZelyvM5uz5CZHz83LlIsOKelUHJ7X6Uq7yIZO9npHOotewwOi 2/ZgZ/f56+evdXjROh1xyZhFnqiH3aO1gUwuw5NpuiaBGeS/PSCTIwLc/AP646kG8kZh3D7t YUDIP7UzNoLZwLit8nyL6pICDSi4bc2bwA4ojymjzpjVK+se0ME/WI6xvrI/9Dqwon+qFGmC NG+Pjw86LbwJ3ub5OIkz5XIuEJVIlHVm0TvtqEK8KuwDO5PcKmsBRhUxjqbzMWYr6M5udZ5k Ee9aB/3g1NboysoSE5je+VrTcg4BSlWnLQn65JJR60J96d53fjwhdanQC7P3MHGBEfbDRXZB xpOIvvXQmVjHXyZxpupZWHBaa/c1TO3t03NbpyvKiDnEIMoxSd80PcrEckd0ZEK2Fio+5H4f dA+7xNvhfnePBp33wu8TmcokHwkfeJNEY51pfCc+/ToqNxuN1+xinpGLQDKyALxapIHz8Cpg WVjAAj+lIzzqa/RAMOthiiHshgEsUd+3mshTlAo8B8z1qBbBVB9CA6g7Y20qBeiWhkw7z7+T aa5EnTia5EWKVbUjrL5zsTQkznms8iIIFSnTnq9HPlU9egGvuhiUwLBOV9cqKF9gzgSCEvvf FZUJ6jzAOl2dJ7MhhuJJzhdO0NsyJGONrlhTiBIVsoTRlLU7smQv78ySR+M2osIC8iNWT/UR yY8RM/mK+OQWPMLlrXvk90W8jCVBAp18kzpina76OnZdzQsWWdtpPq3hzbNOT5RPmKbD+isF C98es/C5N2PN9tMd0pbtBLRlZT3Z713J5QZg91nhYbgeugXPHLZ31XQUzvPDZTKj0PkpsQOO 2nAdeq8IPQfsoy51nA5ndBcujdpzHsw2fe1OCpX5+fqXWUVu7eHSzDDOIxkJypLf2vNxTAvq mqZLtuwmtvChK0ODmJS/UlhmkUQIHCia+dVnwidD2JB+6VfYy8VSNPqRqoufIKTU6tcUMN/3 Ou+Pe92WT4OcpX3X6vU7mkKHlqZGH17GU2TJz9dUJBygZEtht8UMq/8VOjHBOr0YcJbVCLfF JpjC6eBd49VC+HQP9oE5VJ9JgnLhM04LyoNVzM8aWu+41nzeJhgwmXIBEQ95WuvxD+i8dcNT YhY0w7pmbIVfDxNxadOkADgVZPQj9T15NazJzWI6NrxhFZxuNx1LjWvyX1IasdYBqj/WXZqF A5hyRYNtES5QmnxjbSBccJVvqL8B7vRq4tuRHq11s4i1G/m2FdX6+HnB2WVNvNGurzOZdkkT b2nX14I668hiVqs3nQmu05G+BBDAOvXiOj04kJNLDin44LjXWasjssAu2KKD1tH709b7RTeH gsAY+PM5hlyvS1/HTF9JybEZCjuwctHK9NY9YGkhO0NSy9Exmf/olC2EVn/QODze777r0jEj aFUdMC27rTGvk2o773WypiGCCt9JWYSmlkkEK9eikGINFPKyAD5HrcNOZD0hbEqLyRioNZkU NS9yy4tWJH4bwdZaGCGjvrAnmGh/hPf1muI1E2dXP63ugAXQIoNV33wmaBnLsFg9G0qdYFk+ 15mcp9LQ+JRfZ8mavF/oilPrXe/SPT05Uqf4al5QHgtge0HewRs4W+vIyDoqoczZs8xnD8rC GwcM8OthpTgVXsWpyqzISRpLvtcLH5WLsJU5SMWc0lp0395qOfO3s1RPaGHuZagvuGw9HYTq q3Kzep0D3gx5SkdCUvNY1COxCMJaN0DpCpFl+dGZS55bXiWD48O3aC1X9NJXAZCxio+uypO5 NqXUGhSd3+Qqnn5kg946/YwSyrFbgQPr9ESmkkVQ+YfjLBO6QNKRuhrxqv33mtSiVRT5MCV2 UbIuO8LMGj31k4Snq3Ndu/BZoysNyveHfm6/xc+G1HG+Km73i+/jhn0ft5uquuhwPsV0qW30 QBtJOiffEfKdEDb0z8fjfxP1W/0Dk46UyQFeLUrHUNRLnKZ5W/R3gGB79gsw2BlwTh8xCRNm WI6L4k0NI5CsIAS2ArrZgTwXXf1KPgUWLPhG6yesEEiudqUXnpg5yBcVDrnPviDlhpFyR5AS Eak7S66inu0R66LkgCsUDJWz7CcuLniZaM9ZvI0dl1qg0ugL71X51kUDcFTEKhR2mjZGhIwD AMRtL0uTO9IRjIQX96HdfUe699xr8V17dKmegB1Sbhlg3GhhWJN7qEfALJCdwTuXXZHkMrj2 dn6FsQbR49679lYzahtnZeYCU4Sw7/i+fNQIqz7aBino3umCa7MKd39FEYNLwfmCwLmzGJwV 0HMwgV2kC0aC0XwKf8I62C0LN1+D+HHaTJquP5UOsQDiZfyb61Z1hDq0R18ALuxHTvs+OmGp 2mnKkyHkLrbEI1jDHG0CZ84GB+stoE+4AzhClTxroPQFzMEIq5PCJFOKKBmbpUn/VNAEFn+W Ysgp5hm0e48vpgnFotS1mEkziA0/Yvl4424VdmpCu6vajw0kCRlaQFJ0Xu5jquXMmqnULAlN 1pkTICM2I294cxgwqAyd6iW/oAU3rkEdqgkypCSMHvAGijowYih3emK8cWygIEA9SXHHNg5B fh9L6FjFVKYRC6AqwmIfYTQrpejPndMUyeDqOoUXVxjagtfQiICiQgGktLFFsMw+lFbkH5NY T4QwDZURlDRTpau9KW2ecesHmE6WE76XfFJt0rdPcKSeiWq7x7PlTEfB/OxGxS8rSmHl0QZR ZSyK3GWRgIN8L0qT2bm2I3ybXg2b+bSUCWFOGVX3Ih9ienKYI9ptQ4vB1fuRzPTDZD7Fgrf+ b5ZJtxQADUNxWRO4Pi9uVHXc0GuYSQxvJlQdV79V3BQ4k8XvcaAJ6mvwjFo8nv/mO65CZPDP f0ElMPS/32CM6eAy0TZKdD9D/Q7cnmOdVlrhBqG2okieVn0VPtLaWxyT4wn4PkNsKB00d8uJ kPAHu1X0OGlewKXSoepMzI34+hYVKiuuehNYAFsZ8hnwCXzPFpTEtAmX9nsqJY3paaecDdjp apyAKD0yCFeatYOMreyG2fOYAuGQsp7lkpQAZw+7BRSPnZbKWZzxNuFp+YNUojUOKFn/8QIE npdlCyF0du/JL3AocdP9zpDwq+k4xYVKUwgdmZax5bOfm1ZYWhWPXGo4VTwkv7f6+FWH0X3R nEaYnexgMQeUmNJMcQcozTLdSZyCWhEoF14ShEYqHuDPWz/Vo/53x6cH+whriwNoWttQYlbg 9sESHbIhehOGFs2wriNiKnGlnCzZ7uiMPFnHMYddklZEd+3WYi9U79p4uwATBOLCfVpJmhFu cKPq+milHQkQM5xV6+3RO1oHUZaE56U9q0KQXg0BDGmkEg0S+p+ojK8wgPHBWzQa8Uk4NWyB noyUUrjQWWeXz6ZSfA1d5q/kMrcY7xOMjtIEzdr9ckSgvGFcmFTQGtBFCXPEjpAj4VfTYjjn ZPv2mtGGXA9f4ku5kdeyACuPS4sYt1jzach05iNv+vtmKnnmzlJH3klpI1wFlosD7B6i55wz d2xJVnpm8VXYEm7xNVYETD7C3YSqFTit80L3PcU9TtwjJPPQlOcMA0aFX01G1mnJsDQdMmvL oLP9VKBjJRwAPgjz/auR8iLm6yeeoBQAH1w4HSMJoHv3Om/gcnywoiI3GceTgq1UI6tnz9E1 pZNPhaNHxIkwSLQmWMHEggPOrqxHcmR6uxChoQ8FrdLCQU5c43TTI94dJmkvn2mXvK3fQF5j MslTKg0Q4KFb1iRasI5oP50Cs5lPWXhBaiw1YyQggjQTlOHf70pvir1KMr9w02Tkrt+s2ekF WB4GpczWX5Eddkwh+Riox96cZQTPKSERzIleZ4lezUKKNDpzktvH3TOuQMTANreyYfoBbAUg RTPa3oq6mZUEyWeeDPJ9E+1sWYeLg/sJib6JdreiQTK8zNKhJ/ciRcOOhyhaTuO0MCjH7jZw N4yLhC9gCupnsdOrVSXBvuq28+CLcs6QlSSzXG11bDbXWRNDC8uXAfUzahd1htRWdfrv65Gw J1wegm5TB8q8HNWjmmKpS/ecevNBDyY5PaVrzguI/2t+mUV92Pbhx4QXSuIw7i+b+YtlIenb 20SiLPJ9ougf66soUHaa+3SpY3MJvuKDmR2jHZDwYaUXPHMDdXXI3g17NBj1QhOHMy9+vYJY sU1+DUoaFubXh+JOM9K3bMUru3Dkw/eY9+Iz1LYsIemrcAf4n6OckolJAIauzsyq9EgdXKJj SAqnXDcIk1q6EMVtEFzD+fMKUaWSudwdY3FdMqPFMy7R5fQkbKtQOdKinGlEHmmPFtHfoFiZ z90zkV+ldM8T75tgEn/tpEvKHdKLYBGJMOn31yWFWUiJKitLTZQIEAo4C9eo8ULtBpDDs3FS LwluqSJWJnPLKI+KPChX8IiFxYoxomdYkx2hIcZQEwBBZDpwY97wTFSHjPisc6P6E9TdOIV+ R2EB8Hw+VmcMC7nHOPfjt/3jg86gQ94Fo5HWx1EBXaZdqQvGmi1L11i8d1bu04idL4aWDRta dlVCIsSUhZa/gS6HpjTrVqoS0sGafCjqqopnMxDK5n5sgKX609lS6qjEsdKa2DWuuZo1vRHq Bt9Gb8T9D80S+fSy9Oz3tvbQTLHzbOdF1MDj96kNZ1SCkFmmIoHNFUSB48+E/6LURKM8wZYw JDMGsxxOrTbal0t7B5O6EH2WPEjaHQKXi6vlrE+lo4dpPQwv6/K/F4mVKLLm5Gt0Ewb/fNg9 7HyghHWJpHesU86/w1b3YHBcoUal8kzmIrU7PLdE7KQyKU3oYE/Ph02+VYovR3uzR7vFYH0U tYT7K+Q8CxRlMa9f/7+1lSH6tEbtGVzC9/D2NZj9UbOEKeGL4Zf6M7hYMFcWVnYy099Az0fJ rBjGiM7pCRzZZLbR3p8/3Y460WE6Go1ZE93L49FGRzjEuuAxnJ/vgeeoA2sURa+fPX22u9FB TvtLu/NPyMllniV7K/X+p+3Gs6evGjsvXzSAxr5ae6jOIZC41YbS546THe0VV3H2bSYogClb a38ufUWnxp2Ti/LoYAQ/WxPwP25oG/bz+QVg0E2y/AhsEEY46rdTHJUB5H7+7UDnfZJjDcm3 8Vk6LDbaM1AfAMRm6Q5WeYlOkmSMMnCyYbJziHJvgvqvv8+Ts2QYRd/ttqKdH55vdJR2a200 XI8qPN9+1ni5u9t49Rxg9cuznafbaw/4Lv5l/eFevXxQInRBiHv2bcFoxqcs8OVv56idxCDM fZeOx5vFWvgqHl6CrDgDCbObgbA/m3MiT1LHkVFvoyP+8Hqnsf1yZ6N9vnwZuQtpfUqyebLZ kxdfnU3T0UWCxrsoerqzvft6owPc+4X/YvtlY+f5buPp9s6zez3UPNCrxquXuy8e8lBPLs++ vUpnzWQ0r/3Z+lA6xJoD/7qsvPjiurxpCWcyAQk1/SVqiRKjNfyY5dcgICcXZM4tfA2GbWYg wR3DGD6lozkK4qTzvYr/hVZzvHJRcWHpCB3NwzQ+J+UliuuWMVPF6aCaZG2H5u/iaQxCRWv8 CR0HoWcAI9p6o7d5lmb1qJWBHBe1QWaaJWiRvwSCsY+LsAdqT2GUZFqPTkAg71wk0O49kPak QKeeGXbz1+T8PPouB3pTQJ/j5Bf4MJlAh64L5NvpfJhEf4sv4fuDtIjhnwmq42nMdARTGyWw 0W/zM/gTqcUNf7D7OIRbD/s9wdoUx48Okhg1j70Uo+FHUR9oKjp44BuDPLuJ+ugHV2dbgt2N 2BUIHB+jH+LLMU8cQJRMo0E85iCr5apt/0Q++3Ii7+lEvpUT+TY9G6f5xTSeXN64h3GVEyGK qqMmYNY0ARYigbOIRw6+eQd8NpyQGr4SPeZKeuKHZeNOF6EIAmCExJ/dsUhDuYVRcTP00diL DlU4AivjdBO7n3088ZzxYOd59Nf5+AbLkL3wFX198sS4UaSBva7OlM5MXFGASphpSa1o5+jl ozQpanXyp95+vrNdxywH4yHAoA4ts7zIz+Ec9tEITEmgYCa7ZQvd4KD/IdpPk+lHOuhjpAU1 pIHwA0bzAuLkYxllZ+fZCzh5cTZH9yN7MlgEpNQ1alC3t19/iDCJfLNZHhuDQj6QohWeyrdO e/DSWwTEtGgcJLC6d6hXAXDhWS/ItARzPs1S1DBidmQqBe5u8AiNfudpwkGRzgCPT3vdrb3o fZJR0rb+TTaLf1Er3n0NK27NLzDGExb5qjw9zkW0H18XOYAO5MaM4kRgRnr7lN5WbXgfbc7z ceolVmmjSvmYDUZ9x5PpsVb9bqmJPXv2vB4d5Z94b729eFWeJeXQ76dwbWBRawIdadbqeupA 4HneRs9sdztQFW4bXaCoeIJRk0xrpLLuZ+kY44IUysCcYUg1XbsjmPoLa+rh6R7idNXM9FTt +VvTlOPReBsXnpPMoukdmul50AxOqf932ObafgyUDIaJDlQyAfgeemkd9btPuv3jJ91OO3r9 9OXzPexlpx7FH103bnwx+nG3ub37vGHeeJeewGk7fRtt7wDvGhq7fXz4ITAKdvFk0G5sY2ew hrATAxAFuFEAWPOraBvtAsGZjos8ikc5OY3EIMQAczS68l0qqLm1iCY2Lp/Zo277eB+oMlIS OJlUMhkNR8hezK+ExKgf+srtv+H180M+HY/gbkvQug/XO2xmpKqsRY1G9L2kFNtuPsU9gNsW 8KXxQ1KMkdGwp/19PsZEkEAkYb7wr3zeoc87TabZ7HAuLoLI0akJOudAQ7iXUFTaH54FaFa/ 0eq3u90PsGiMlDDT7yezRuNlAwvEtShLZJyZ9bf9wfimYcsJLpTwme3Idb0Lz2DvX70oT4Kt XYjgTaSrVMrDeifMADlGl2E+uVGsyBcWaIMs0Lv5eAy7LdBFBJiRLKKMLxPhdR7pHXj0Z/QG Vg0et7foaOkrpp8P0wTo2+Odp0+3t8gbBFhoeLXACxGD8kdN2eBw32TaHOXDuQ5WoZLmY7Hy kn+pylIEDSnPKrx0Pp9m7BMxy7/+ipw9CjbHAhakn2LKY3mdA3cRSWIw9k5BMWjKziHXaaG9 gWEQ6GWKUUXoXEVfFJ5HsJrFZIqJj5C94/nULQcNmMDXX43Q7EmGZawjkEXXl/mYnG3hb/RC qZMxFl3a7SAsipS7iT6C0Ff/+isr1kn8XOIzuCYiDTtyxB8m4iMFMERPcWJl0Tj79VeS0p6c xjCAh3xWaMJFEExNzPyKrhp16g5WofYEIJGMz2n1EtmkQxGJ4b2JrmOgejRATG5LUxAwP8Fp +/orch3yp0xehecJ54XVfmM+RqltwtKG8hMJbBIri7EHv5CTYsymcXHaY4cZFfIAy8C8DbBs INy6HxXuVfDuoHvJEO9WcU1ScVfQ3ddf6dk79n93xro75bolqTm+/ooFesQDQi7HlUbheUJu ORl8oxIFFeK9BHufff1VJ7tA7Fp2jNAv8ColTyeMSxBnIsAI8gZl7KGKKMl0klCBCXLgV+WG cLbT5FP+0fjhhbYEjwXsNK4StQ9yZC6yYu1Tfon6DXPDDHOV/gPdpFJK16kPAeIwQOL/4qXx TasPbAT/GQFLlDI+D77rUELk3lFnEPWP293O4CcqJej80Dl63z3qdHrdo/cwqVb/b9G74167 E+13+0Chu0CDWwcH0Q+tXq91NOh2+vWo8+NJr9PvR8e9qHt4ctDt7IOUc9Q+ON2nPt6ecuIK SszcgdGOYdCfVA8/weitAU3htN+Jjt/JbGDQw9age3z09VdYEbF7FP3QhXGxI/gRZ9ehbnrd 998NaGz8JONb04Mev/7qsNNrfwefW2+7B10YEt5+1x0c4aTfYUtM5DLotk8PWj1g9Xonx/2O 2iwUipVW6mKFi+DdnJNsq4OGPGxnlGKijfN5xnQM/ad1xla9g4xS1lkWnFIzUdfXWT66gf9c zq7G8PX/D1BLAQIUABQAAAAIAGhU9CoqeHVjDtUAAEwdBAAdAAAAAAAAAAEAIAC2gQAAAABk cmFmdC1pZXRmLWNhbHNjaC1jYXAtMDUuaHRtbFBLBQYAAAAAAQABAEsAAABJ1QAAAAA= --------------8561EC5753705279E5D42DF4-- From owner-ietf-calendar@mail.imc.org Fri Jul 20 14:30:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22513 for ; Fri, 20 Jul 2001 14:30:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KIBa213115 for ietf-calendar-bks; Fri, 20 Jul 2001 11:11:36 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KIBZq13111 for ; Fri, 20 Jul 2001 11:11:35 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6KIBUB23427 for ; Fri, 20 Jul 2001 11:11:30 -0700 (PDT) Received: from netscape.com ([192.18.124.76]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGSAJ600.7X6 for ; Fri, 20 Jul 2001 11:11:30 -0700 Message-ID: <3B5876C0.E0966AE7@netscape.com> Date: Fri, 20 Jul 2001 11:21:52 -0700 From: jsun@netscape.com (John Sun) Organization: Netscape Communications X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: RRULE Question: How to specify weird pattern Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would like to know if you can tell me the RRULE for the following recurrence pattern. Repeat every 30th of the month. However, if the month does not have 30 days, set the meeting to the last day of the month. Combining 2 RRULES like this might work: BYMONTHDAY=30;FREQ=MONTHLY BYMONTH=2,FREQ=YEARLY,BYMONTHDAY=-1 Is there a way to specify this in one RRULE? From owner-ietf-calendar@mail.imc.org Fri Jul 20 14:46:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27282 for ; Fri, 20 Jul 2001 14:46:05 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6KIW5a13721 for ietf-calendar-bks; Fri, 20 Jul 2001 11:32:05 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KIW4q13716 for ; Fri, 20 Jul 2001 11:32:04 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA16715; Fri, 20 Jul 2001 14:32:00 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6KIW0v13383; Fri, 20 Jul 2001 14:32:00 -0400 (EDT) Message-Id: <5.1.0.14.0.20010720143313.030d4f98@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 14:33:57 -0400 To: jsun@netscape.com (John Sun), ietf-calendar@imc.org From: Alan Davies Subject: Re: RRULE Question: How to specify weird pattern In-Reply-To: <3B5876C0.E0966AE7@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You could use bysetpos: FREQ=MONTHLY;BYMONTHDAY=28,29,30;BYSETPOS=-1 --Alan At 11:21 AM 20/07/2001 -0700, John Sun wrote: >I would like to know if you can tell me the RRULE for the following >recurrence pattern. > >Repeat every 30th of the month. >However, if the month does not have 30 days, set the meeting to the last >day of the month. > >Combining 2 RRULES like this might work: > >BYMONTHDAY=30;FREQ=MONTHLY >BYMONTH=2,FREQ=YEARLY,BYMONTHDAY=-1 > >Is there a way to specify this in one RRULE? From owner-ietf-calendar@mail.imc.org Mon Jul 23 15:30:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18054 for ; Mon, 23 Jul 2001 15:30:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6NJ2PN02607 for ietf-calendar-bks; Mon, 23 Jul 2001 12:02:25 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6NJ2Nq02603 for ; Mon, 23 Jul 2001 12:02:23 -0700 (PDT) Received: (qmail 424275 invoked from network); 23 Jul 2001 18:58:22 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 23 Jul 2001 18:58:22 -0000 Message-ID: <3B5C72CD.339C6501@kasey.umkc.edu> Date: Mon, 23 Jul 2001 13:54:05 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour , CalSched IETF , spki@c2.net Subject: AUTHORIZE again References: <3B57769A.D06440A7@netscape.com> <3B5782C3.53F97524@kasey.umkc.edu> <3B57D194.9861249@netscape.com> <3B585AB8.4774DF64@kasey.umkc.edu> <3B58B91F.BFB47DCA@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit to avoid getting distracted by an irrelevant discussion, please skip ahead to the line marked "PLEASE SKIP TO THIS POINT." Steve Mansour wrote: > > How do you feel about the AUTHORIZE suggestion? Nobody wrote back about > > it and I'm having Warnock's Dilemma. > > I'm scared of it. I think anything that deals with authentication is a difficult > point. It deals with authorization, not authentication. Authentication is dealt with thoroughly already. > I think for us to try to specify a generic way to make two servers establish > a trust model is a *hard* problem. That is not the problem AUTHORIZE was proposed to solve. The problem AUTHORIZE was proposed to solve is anonymous or partial delegation. There is language in the current draft standard dealing with delegation, but the mechanisms proposed (impersonation) are clumsy. I believe that striking all mention of impersonation and replacing all delegation systems with a SPKI-certificate based system would be a good step. > I think it will slow us down for a long time. I > think it is a solvable problem, but we have *SO* much going on in CAP already, I > feel like we need to focus on the absolute minimum subset. I think that we should > leave trust models up to server vendors, and when somebody comes up with a good > solution, they should write up a separate draft that covers the topic. The current draft standard has nowhere in it for presentation of an SPKI certificate. The AUTHORIZE command is proposed as How To Present An SPKI Certificate. How that certificate is to be obtained and what it might mean are deferred to implementors. > Don't get me wrong. I think it's an important problem to solve. I think it will be > awesome to have cap servers talking to each other using a trust model. I just > think we not focus on that problem now. Having calendar stores talking with each other (via something like nntp) may be difficult (I personally don't see it, having operatied a usenet server for several years) but that is ABSOLUTELY NOT the problem that the AUTHORIZE command is proposed to solve (although SPKI is general enough to solve it: have the CS peer present a certificate authorizing itself as a peer, then synchronization occurs. More likely might be a database system that already has synchronization (files in CODA, or recent Oracle releases, for instance) could be used as the storage for a distributed Calendar Store, making the synchronization entirely a vendor problem. But I am following your digression here. PLEASE SKIP TO THIS POINT The SPKI documents need not be read in their entirety to understand the theory of authentication certificates. Here is the relevant passage: > The authorization certificates that are envisioned for SPKI (and > needed to meet the demands of the list given at the end of this > document) should be generated by any keyholder empowered to grant or > delegate the authorization in question. Calendar editing rights are a problem domain where delegation happens all the time. An explicit anonymous delegation mechanism is not mentioned. Not for cs-cs data sharing. For delegation of very small access rights without needing to create dummy users. Creating dummy users is objectionable for these reasons: 1: it interferes with having identity checked by an outside server, or requires that the delegator have the authority to create accounts on the identity server 2: it may require switching the identity options on one's CUA, or "impersonating," which are both ugly things. 3: a standard CS would need to either have its own cache of fake users for use in delegation situations only write access to the indentity server. the AUTHORIZE command, as I suggested last week, would allow a calendar owner to create arbitrary rights and grant them to the bearer of a certificate. This would mean that the calendar owner could issue a certificate that allows the bearer of it to, for instance, edit the description of the event that occurs in conference room 3 every tuesday at 2 PM. I realize now that without a standard GENERATE command for specifying the scope of a bearer-certicicate authoirzation would be, the AUTHORIZE standard might be weaker. But Generating makes more sense to me as a CS-implementor issue. For interoperability, there needs to be a standard way to present your SPKI authenticaion certificates, no matter how they were generated. I looked through the whole standard trying to figure out where a good place to shoehorn them in would be, and there isn't one. GENERATE/AUTHORIZE is a cleaner solution to anonymous delegation than impersonation of fake users. It provides impersonation (ability to operate with someone else's authority) without the security problems of allowing someone to operate with someone else's full authority. It is even possible to restrict a generated certificate to only work when presented by a user who is already authorized to present it, for instance. These things can be arbitrarily complex, which is why I think the operation of the GENERATE primitive, if it is included as well, needs to be defined loosely enough to allow for arbitrary vendor extensions. -- David Nicol 816.235.1187 "Mary had a little chainsaw" -- Angus Oblong From owner-ietf-calendar@mail.imc.org Mon Jul 23 16:37:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21959 for ; Mon, 23 Jul 2001 16:37:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6NKDhY04418 for ietf-calendar-bks; Mon, 23 Jul 2001 13:13:43 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NKDgq04412 for ; Mon, 23 Jul 2001 13:13:42 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6NK9D809256; Mon, 23 Jul 2001 16:09:14 -0400 Message-ID: <3B5C8468.5000406@ecal.com> Date: Mon, 23 Jul 2001 16:09:12 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: "David L. Nicol" CC: CalSched IETF , spki@c2.net Subject: Re: AUTHORIZE again References: <3B57769A.D06440A7@netscape.com> <3B5782C3.53F97524@kasey.umkc.edu> <3B57D194.9861249@netscape.com> <3B585AB8.4774DF64@kasey.umkc.edu> <3B58B91F.BFB47DCA@netscape.com> <3B5C72CD.339C6501@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David L. Nicol wrote: >>>How do you feel about the AUTHORIZE suggestion? Nobody wrote back about >>>it and I'm having Warnock's Dilemma. >>> Nobody wrote back because we already turned you down. This is not the time for mission creep. >The current draft standard has nowhere in it for presentation of an SPKI >certificate. > (Side note: please learn the language--go read RFC-2026. Draft Standard is a reserved word in the IETF, and you're misusing it.) Can't you use TLS? IIRC, CAP uses SASL, SASL has STARTTLS, TLS has certs. (If the problem is that it doesn't have the right *kind* of certs, don't tell us; go talk to the TLS WG.) -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |If you're going to walk on thin ice, you might| |francis@ecal.com|as well *dance*! | \===============================================================/ From owner-ietf-calendar@mail.imc.org Mon Jul 23 18:51:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29089 for ; Mon, 23 Jul 2001 18:51:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6NMXKm08083 for ietf-calendar-bks; Mon, 23 Jul 2001 15:33:20 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6NMXIq08079 for ; Mon, 23 Jul 2001 15:33:19 -0700 (PDT) Received: (qmail 428228 invoked from network); 23 Jul 2001 22:29:18 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 23 Jul 2001 22:29:18 -0000 Message-ID: <3B5CA43C.519831C0@kasey.umkc.edu> Date: Mon, 23 Jul 2001 17:25:00 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: CalSched IETF , spki@c2.net Subject: Re: AUTHORIZE again References: <3B57769A.D06440A7@netscape.com> <3B5782C3.53F97524@kasey.umkc.edu> <3B57D194.9861249@netscape.com> <3B585AB8.4774DF64@kasey.umkc.edu> <3B58B91F.BFB47DCA@netscape.com> <3B5C72CD.339C6501@kasey.umkc.edu> <3B5C8468.5000406@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > Can't you use TLS? IIRC, CAP uses SASL, SASL has STARTTLS, TLS has > certs. (If the problem is that it doesn't have the right *kind* of > certs, don't tell us; go talk to the TLS WG.) Like I said before, TLS is about authentication, not authorization. > |eCal Corp. |If you're going to walk on thin ice, you might| > |francis@ecal.com|as well *dance*! | > \===============================================================/ -- David Nicol 816.235.1187 From owner-ietf-calendar@mail.imc.org Mon Jul 23 19:29:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00910 for ; Mon, 23 Jul 2001 19:29:07 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6NNF5b09258 for ietf-calendar-bks; Mon, 23 Jul 2001 16:15:05 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6NNF2q09252 for ; Mon, 23 Jul 2001 16:15:02 -0700 (PDT) Received: (qmail 428689 invoked from network); 23 Jul 2001 23:11:02 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 23 Jul 2001 23:11:02 -0000 Message-ID: <3B5CAE04.DD957ADE@kasey.umkc.edu> Date: Mon, 23 Jul 2001 18:06:44 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke , CalSched IETF Subject: Re: AUTHORIZE again References: <3B57769A.D06440A7@netscape.com> <3B5782C3.53F97524@kasey.umkc.edu> <3B57D194.9861249@netscape.com> <3B585AB8.4774DF64@kasey.umkc.edu> <3B58B91F.BFB47DCA@netscape.com> <3B5C72CD.339C6501@kasey.umkc.edu> <3B5C8468.5000406@ecal.com> <3B5CA43C.519831C0@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "David L. Nicol" wrote: > > John Stracke wrote: > > > Can't you use TLS? IIRC, CAP uses SASL, SASL has STARTTLS, TLS has > > certs. (If the problem is that it doesn't have the right *kind* of > > certs, don't tell us; go talk to the TLS WG.) > > Like I said before, TLS is about authentication, not authorization. Rather, TLS is about having an encrypted channel. SASL is about authentication. Neither one of them is about authorization. Trying to cram authorization certs into either one of them makes less sense than setting up limited dummy users, which is the solution in line with the current version of the draft of the document this mailing list is working on, whatever its proper name is. From owner-ietf-calendar@mail.imc.org Tue Jul 24 12:58:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02071 for ; Tue, 24 Jul 2001 12:58:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6OGHVr29846 for ietf-calendar-bks; Tue, 24 Jul 2001 09:17:31 -0700 (PDT) Received: from server1.egenconsulting.com (nbppp5-254.gtnetworks.net [216.143.5.254]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OGHTG29841 for ; Tue, 24 Jul 2001 09:17:29 -0700 (PDT) To: ietf-calendar@imc.org Subject: FW: 51st IETF - Calendaring and Scheduling WG (calsch) X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: pregen@egenconsulting.com Date: Tue, 24 Jul 2001 12:16:58 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 07/24/2001 12:17:15 PM, Serialize complete at 07/24/2001 12:17:15 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005976A685256A93_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005976A685256A93_= Content-Type: text/plain; charset="us-ascii" Note to the group. We will add CPL reconciliation to our agenda in London. I insured we were not up against their working group time when I scheduled our meeting. Let's see if we can come to a resolution in London or at least state publicly whether it can be resolved. ----- Forwarded by Pat R Egen/Egen Consulting/01 on 07/24/01 12:14 PM ----- Jonathan Rosenberg 07/24/01 11:49 AM To: "'pregen@egenconsulting.com'" cc: "'bobmah@mit.edu'" , "Lennox, Jonathan (E-mail)" Subject: FW: 51st IETF - Calendaring and Scheduling WG (calsch) Patricia, Bob, I noticed that CPL reconciliation was not on the agenda. Is that subsumed within one of the other items below? This issue is still holding up CPL and I would like to get it resolved. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: agenda@ietf.org [mailto:agenda@ietf.org] Sent: Friday, July 20, 2001 10:34 AM Subject: 51st IETF - Calendaring and Scheduling WG (calsch) Calendaring and Scheduling WG (calsch) Wednesday, August 09 at 0900-1130 ================================== CHAIRS: Pat Egen Bob Mahoney AGENDA: Agenda Bashing Guide to Internet Calendaring CalConnect Interoperability results - next plans iCalendar Updates Other drafts - SKICAL, CRISP CAP draft Update charter --=_alternative 005976A685256A93_= Content-Type: text/html; charset="us-ascii"
Note to the group.  We will add CPL reconciliation to our agenda in London.  I insured we were not up against their working group time when I scheduled our meeting.  Let's see if we can come to a resolution in London or at least state publicly whether it can be resolved.
----- Forwarded by Pat R Egen/Egen Consulting/01 on 07/24/01 12:14 PM -----
Jonathan Rosenberg <jdrosen@dynamicsoft.com>

07/24/01 11:49 AM

       
        To:        "'pregen@egenconsulting.com'" <pregen@egenconsulting.com>
        cc:        "'bobmah@mit.edu'" <bobmah@mit.edu>, "Lennox, Jonathan (E-mail)" <lennox@cs.columbia.edu>
        Subject:        FW: 51st IETF - Calendaring and Scheduling WG (calsch)



Patricia, Bob,

I noticed that CPL reconciliation was not on the agenda. Is that subsumed
within one of the other items below? This issue is still holding up CPL and
I would like to get it resolved.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


-----Original Message-----
From: agenda@ietf.org [mailto:agenda@ietf.org]
Sent: Friday, July 20, 2001 10:34 AM
Subject: 51st IETF - Calendaring and Scheduling WG (calsch)


Calendaring and Scheduling WG (calsch)

Wednesday, August 09 at 0900-1130
==================================

CHAIRS: Pat Egen <pregen@egenconsulting.com>
       Bob Mahoney <bobmah@mit.edu>

AGENDA:

Agenda Bashing
Guide to Internet Calendaring
CalConnect Interoperability results - next plans
iCalendar Updates
Other drafts - SKICAL, CRISP
CAP draft
Update charter
--=_alternative 005976A685256A93_=-- From owner-ietf-calendar@mail.imc.org Wed Jul 25 07:38:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11629 for ; Wed, 25 Jul 2001 07:38:35 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6PAoKU10745 for ietf-calendar-bks; Wed, 25 Jul 2001 03:50:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6PAoCs10740 for ; Wed, 25 Jul 2001 03:50:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07271; Wed, 25 Jul 2001 06:31:33 -0400 (EDT) Message-Id: <200107251031.GAA07271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cap-05.txt Date: Wed, 25 Jul 2001 06:31:33 -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendar Access Protocol (CAP) Author(s) : S. Mansour, D. Royer, G. Babics, P. Hill Filename : draft-ietf-calsch-cap-05.txt Pages : 124 Date : 24-Jul-01 The Calendar Access Protocol (CAP) is an Internet protocol that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). This memo defines the CAP specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-cap-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cap-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132027.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Wed Jul 25 17:53:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13047 for ; Wed, 25 Jul 2001 17:53:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6PLcYU01242 for ietf-calendar-bks; Wed, 25 Jul 2001 14:38:34 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6PLcXs01236 for ; Wed, 25 Jul 2001 14:38:33 -0700 (PDT) Received: (qmail 470251 invoked from network); 25 Jul 2001 21:34:29 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 25 Jul 2001 21:34:29 -0000 Message-ID: <3B5F3A57.F5424275@kasey.umkc.edu> Date: Wed, 25 Jul 2001 16:29:59 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: i know you don't want to hear it but Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 2.4.2 of http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-05.txt contains: The method by which a server composes and validates an authorization identity from the authentication credentials supplied by a client is implementation-specific. which is confusing. That "authorization identity" means UPN is a difficult interpretation of that sentence to arrive at. I suggest: The method by which a server selects a UPN from the authentication credentials supplied by a client is implementation-specific. to avoid misinterpretation. 2.4.2.1 so the "ATTENDEE" property couldn't be munged to something misleading s/couldn't/can't/ 2.4.6 The CUA may change the identity of a CAP session by calling the "IDENTIFY" command. The Calendar Service only permits the operation if the session's authentication credentials are good for the requested identity. The method of checking this permission is implementation dependent, but may be thought of as a mapping from authentication credentials to UPNs. The "IDENTIFY" command allows a single set of authentication credentials to choose from multiple identities, and allows multiple sets of authentication credentials to assume the same identity. I hope the defined syntax of IDENTIFY allow the CUA to present some additional credentials at IDENTIFY time. (also, the section listing examples of small, large, dynamic and nested groups is in here twice.) 7.1.8 7.1.8 IDENTIFY Command Arguments: Identity to assume Data: None Result: 2.0 .4 Identity not permitted The "IDENTIFY" command allows the CUA to select a new identity to be used for calendar access. This command may only be called in the Identified State. The CS determines through an internal mechanism if the credentials supplied at authentication permit the assumption of the selected the identity. If they do the session assumes the new identity, otherwise a security error is returned. says that it does not. Would it be possible to allow a second AUTHENTICATE following IDENTIFY? That would work for anonymous delegation, which is the use case I've been trying to get CAP to support with these endless harangues: the delegator could issue a special UPN, for instance nicold-conferenceroom6-6pm-wednesdays@umkc.edu and a password for it, which would be provided in an AUTHENTICATE state after the IDENTIFY fails. A way to do this that does not alter the state diagram might be to allow IDENTIFY to include credentials as its data. Thanks for your support David Nicol -- David Nicol 816.235.1187 "Hush!" said the little boy's mother. But it was too late. The emperor's agents had already heard his meek, innocent question and were rushing through the crowd. The emperor's agents took the boy away and he was never, ever, seen or heard from again. From owner-ietf-calendar@mail.imc.org Wed Jul 25 21:42:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00971 for ; Wed, 25 Jul 2001 21:42:19 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6Q1OQK05619 for ietf-calendar-bks; Wed, 25 Jul 2001 18:24:26 -0700 (PDT) Received: from imo-d02.mx.aol.com (imo-d02.mx.aol.com [205.188.157.34]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q1OOs05615 for ; Wed, 25 Jul 2001 18:24:24 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-d02.mx.aol.com (mail_out_v31.9.) id 7.2c.1b39d41 (16232) for ; Wed, 25 Jul 2001 21:24:19 -0400 (EDT) Received: from netscape.com (mow-d01.webmail.aol.com [205.188.138.65]) by air-in02.mail.aol.com (v79.27) with ESMTP id MAILININ28-0725212419; Wed, 25 Jul 2001 21:24:19 -0400 Date: Wed, 25 Jul 2001 21:24:19 -0400 From: rogerdox14@netscape.net (Roger D) To: ietf-calendar@imc.org Subject: RE: Re: mixing mimedirectory ABNF and XML Message-ID: <5B726731.34D5D2FE.10749803@netscape.net (Roger D X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Stracke wrote: > >Greg FitzPatrick wrote: > >> Thanks for pointing that out John. The example should of course look >> like this: [...] >> >> DTOPEN;language="XML1.0": 20020101/ >> 20021231 >> >OK, then. Yeah, that might be reasonable--take the property value and >pass it through an XML parser. 'Course, I might be biased, because I'm >already using an XML parser in my app, so it doesn't seem like any >particular burden to me. ;-) > >You might consider going for a simplified subset of XML--e.g., >forbidding the internal DTD subset, the doctype, etc. That'll make it >easier for people who don't have any need for a full-power XML parser. >An XML parser isn't a large hit in a desktop or server app; but I could >see SKiCal being used in some kind of embedded system--say, to turn on >the Open sign during opening hours. I don't have a strong opinion, since I'm not implementing SkiCal, but it does seem a bit wierd to use an XML-like syntax in just one place in a standard, requiring an implementer to include an XML parser just to parse that one field. There is an XML version of iCal being worked on, and I don't have a problem with it in that context, but in and RFC 2445 context I think it's a bit ugly to use a syntax as unlike the rest of 2445 as XML is. --Roger __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From owner-ietf-calendar@mail.imc.org Wed Jul 25 21:51:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01603 for ; Wed, 25 Jul 2001 21:51:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6Q1e9i06004 for ietf-calendar-bks; Wed, 25 Jul 2001 18:40:09 -0700 (PDT) Received: from imo-m02.mx.aol.com (imo-m02.mx.aol.com [64.12.136.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q1e7s06000 for ; Wed, 25 Jul 2001 18:40:07 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-m02.mx.aol.com (mail_out_v31.9.) id 7.ef.1b2cc8d (16243) for ; Wed, 25 Jul 2001 21:40:04 -0400 (EDT) Received: from netscape.com (mow-m01.webmail.aol.com [64.12.184.129]) by air-in03.mail.aol.com (v79.27) with ESMTP id MAILININ37-0725214004; Wed, 25 Jul 2001 21:40:04 -0400 Date: Wed, 25 Jul 2001 21:40:04 -0400 From: rogerdox14@netscape.net (Roger D) To: ietf-calendar@imc.org Subject: Proposed change to iCal (was RE: Adding more unique identifiers) Message-ID: <4FB1B360.201909CA.10749803@netscape.net (Roger D X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Did anyone have any opinion on the changes I proposed to iCalendar to add unique identifiers to those components that don't have them, and to those properties that can occur more than once in a component? I haven't seen any feedback on them; the 2 week discussion period is drawing to an end, and I'm not sure whether to interpret silence as concensus or as no-one wanting to take the time to shoot them down? As currently written, though using them is optional, they do have implementation consequences for all implementors, since even if a calendar system does not choose to add UIDs or PUIDs to things that don't have them in RFC 2445, it MUST store and return them if replying to a request which contained them. Are people happy with this extra requirement? --Roger __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From owner-ietf-calendar@mail.imc.org Wed Jul 25 22:14:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02912 for ; Wed, 25 Jul 2001 22:14:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6Q23Ne06531 for ietf-calendar-bks; Wed, 25 Jul 2001 19:03:23 -0700 (PDT) Received: from komarr.local.thibault.org (65-85-145-218.client.dsl.net [65.85.145.218]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q23Ms06527 for ; Wed, 25 Jul 2001 19:03:22 -0700 (PDT) Received: from ecal.com (sergyar.local.thibault.org [192.168.10.20]) by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id WAA23230 for ; Wed, 25 Jul 2001 22:05:37 -0400 Message-ID: <3B5F7BD1.9050509@ecal.com> Date: Wed, 25 Jul 2001 22:09:21 -0400 From: John Stracke Organization: eCal Corp. User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: i know you don't want to hear it but References: <3B5F3A57.F5424275@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David L. Nicol wrote: > I hope the defined syntax of IDENTIFY allow the CUA to present some > additional credentials at IDENTIFY time. We discussed this before, I think, and the conclusion (IIRC) was that it was better to say that each connection AUTHENTICATEd just once; it makes the security analysis easier, which makes it easier to be sure that there aren't leaks someplace. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Reality is what refuses to go away when I stop| |francis@ecal.com|believing in it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jul 25 23:34:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08126 for ; Wed, 25 Jul 2001 23:34:14 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6Q3DAV08013 for ietf-calendar-bks; Wed, 25 Jul 2001 20:13:10 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6Q3D9s08009 for ; Wed, 25 Jul 2001 20:13:09 -0700 (PDT) Received: (qmail 475168 invoked from network); 26 Jul 2001 03:09:06 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 26 Jul 2001 03:09:06 -0000 Message-ID: <3B5F88C3.2780A613@kasey.umkc.edu> Date: Wed, 25 Jul 2001 22:04:35 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: CalSched IETF Subject: Re: i know you don't want to hear it but References: <3B5F3A57.F5424275@kasey.umkc.edu> <3B5F7BD1.9050509@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > David L. Nicol wrote: > > > I hope the defined syntax of IDENTIFY allow the CUA to present some > > additional credentials at IDENTIFY time. > > We discussed this before, I think, and the conclusion (IIRC) was that it > was better to say that each connection AUTHENTICATEd just once; it makes > the security analysis easier, which makes it easier to be sure that > there aren't leaks someplace. Right. The connection authenticates once, and optionally sets up TLS, so subsequent communication is secure. Which means that from the protocol's point of view, optional credentials to include with an IDENTIFY command could be given in plain text, as data for that command. Something like C: IDENTIFY conferenceroom6-wednesday-6-9-PM@calendar.davidnicol.com C: petunia C: . S: 2.0 For assuming identities that you already have access to because of who you have already authenticated yourself as, the data would be optional: C: IDENTIFY conferenceroom6-wednesday-6-9-PM@calendar.davidnicol.com C: . S: 2.0 Altering the existing authentication standards to store alternative passwords for alternative phantom users that you aren't logging in as at the moment is a seriously vast request and I can't imagine anyone going for it. All existing authentication protocols seem to be about sharing username/password pairs without revealing them, with possible extensions geared towards continuing to validate the one authenticated identity. IMO this is good modularity. -- David Nicol 816.235.1187 "Hush!" said the little boy's mother. But it was too late. The emperor's agents had already heard his meek, innocent question and were rushing through the crowd. The emperor's agents took the boy away and he was never, ever, seen or heard from again. From owner-ietf-calendar@mail.imc.org Thu Jul 26 00:20:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10179 for ; Thu, 26 Jul 2001 00:20:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6Q4AKh08890 for ietf-calendar-bks; Wed, 25 Jul 2001 21:10:20 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q4AJs08885 for ; Wed, 25 Jul 2001 21:10:19 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6Q4AGB06563 for ; Wed, 25 Jul 2001 21:10:16 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GH2BL400.Q9Q; Wed, 25 Jul 2001 21:10:17 -0700 Message-ID: <3B5F97F0.167D290E@netscape.com> Date: Wed, 25 Jul 2001 21:09:20 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "David L. Nicol" CC: CalSched IETF , Paul Hill , George Babics Subject: Re: i know you don't want to hear it but References: <3B5F3A57.F5424275@kasey.umkc.edu> Content-Type: multipart/mixed; boundary="------------595948E4B5CFA36E7BD71FB3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------595948E4B5CFA36E7BD71FB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "David L. Nicol" wrote: > Section 2.4.2 of > http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-05.txt > contains: > > The method by which a server composes and validates an > authorization identity from the authentication credentials supplied > by a client is implementation-specific. > > which is confusing. That "authorization identity" means UPN is a > difficult interpretation of that sentence to arrive at. I suggest: > > The method by which a server selects a UPN from the authentication > credentials supplied by a client is implementation-specific. > > to avoid misinterpretation. I think I follow you. Paul, George, does this seem OK? > 2.4.2.1 > > so the "ATTENDEE" property couldn't be munged to something misleading > > s/couldn't/can't/ done. -Steve --------------595948E4B5CFA36E7BD71FB3 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------595948E4B5CFA36E7BD71FB3-- From owner-ietf-calendar@mail.imc.org Thu Jul 26 13:51:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26302 for ; Thu, 26 Jul 2001 13:51:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QEcsc15505 for ietf-calendar-bks; Thu, 26 Jul 2001 07:38:54 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QEcrs15501 for ; Thu, 26 Jul 2001 07:38:53 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA23658; Thu, 26 Jul 2001 10:38:17 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6QEcGv07312; Thu, 26 Jul 2001 10:38:16 -0400 (EDT) Message-ID: <3B602B56.A873A12F@steltor.com> Date: Thu, 26 Jul 2001 10:38:14 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour CC: "David L. Nicol" , CalSched IETF , Paul Hill Subject: Re: i know you don't want to hear it but References: <3B5F3A57.F5424275@kasey.umkc.edu> <3B5F97F0.167D290E@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > "David L. Nicol" wrote: > > > Section 2.4.2 of > > http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-05.txt > > contains: > > > > The method by which a server composes and validates an > > authorization identity from the authentication credentials supplied > > by a client is implementation-specific. > > > > which is confusing. That "authorization identity" means UPN is a > > difficult interpretation of that sentence to arrive at. I suggest: > > > > The method by which a server selects a UPN from the authentication > > credentials supplied by a client is implementation-specific. > > > > to avoid misinterpretation. > > I think I follow you. Paul, George, does this seem OK? Yes it does. It is much clearer. > > > 2.4.2.1 > > > > so the "ATTENDEE" property couldn't be munged to something misleading > > > > s/couldn't/can't/ > > done. > > -Steve From owner-ietf-calendar@mail.imc.org Thu Jul 26 13:51:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26314 for ; Thu, 26 Jul 2001 13:51:39 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6QETI515301 for ietf-calendar-bks; Thu, 26 Jul 2001 07:29:18 -0700 (PDT) Received: from komarr.local.thibault.org (65-85-145-218.client.dsl.net [65.85.145.218]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QETGs15295 for ; Thu, 26 Jul 2001 07:29:16 -0700 (PDT) Received: from ecal.com (sergyar.local.thibault.org [192.168.10.20]) by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id KAA15210 for ; Thu, 26 Jul 2001 10:31:28 -0400 Message-ID: <3B602AA3.1040009@ecal.com> Date: Thu, 26 Jul 2001 10:35:15 -0400 From: John Stracke Organization: eCal Corp. User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: i know you don't want to hear it but References: <3B5F3A57.F5424275@kasey.umkc.edu> <3B5F7BD1.9050509@ecal.com> <3B5F88C3.2780A613@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David L. Nicol wrote: > John Stracke wrote: > >> David L. Nicol wrote: >> >>> I hope the defined syntax of IDENTIFY allow the CUA to present some >>> additional credentials at IDENTIFY time. >> >> We discussed this before, I think, and the conclusion (IIRC) was that it >> was better to say that each connection AUTHENTICATEd just once; it makes >> the security analysis easier, which makes it easier to be sure that >> there aren't leaks someplace. > > > Right. The connection authenticates once, and optionally sets up TLS, > so subsequent communication is secure. Which means that from the > protocol's point of view, optional credentials to include with an IDENTIFY > command could be given in plain text, as data for that command. It's not a question of secure from eavesdroppers; it's a question of secure from abuse. If I AUTHENTICATEd with a particular set of credentials, then those credentials need to be checked for every operation I make. In some cases, that's an expensive operation, so the server-side state will include some sort of cache, distilled down from the credentials. (In the simplest case, this cache is the userid I authenticated with; but it could be more complex.) In some designs, there may be multiple caches (for example, in a layered architecture, to simplify the interaction between layers). If I present another set of credentials, the server has to be absolutely certain that every single cache gets cleared; if anything gets missed, then we have a security hole. Much simpler to permit only one set of credentials per connection; if you want to reauthenticate, reconnect. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Reality is what refuses to go away when I stop| |francis@ecal.com|believing in it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Jul 26 16:04:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08459 for ; Thu, 26 Jul 2001 16:04:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QJXbV28220 for ietf-calendar-bks; Thu, 26 Jul 2001 12:33:37 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QJXas28216 for ; Thu, 26 Jul 2001 12:33:36 -0700 (PDT) To: Graham Gilmore Cc: ietf-calendar@imc.org Subject: Re: RECAP & Questions of CPL RECUR Issues. MIME-Version: 1.0 X-Mailer: Lotus Notes Build M10_07192001 Beta 3 July 19, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 26 Jul 2001 15:36:23 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 07/26/2001 03:36:30 PM, Serialize complete at 07/26/2001 03:36:30 PM Content-Type: multipart/alternative; boundary="=_alternative 006B2E9C85256A95_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B2E9C85256A95_= Content-Type: text/plain; charset="US-ASCII" Graham wrote: > How many >vCalendar (1.0) implementations exist out there simply because iCalendar >was seen as too hard to implement? Just now getting back to CalSched backlog so excuse the lag here... vCalendar is very simple to do BECAUSE it has no workflow. Standalone PIM Calendaring (no Scheduling) IS very well understood and easily done. When you add the complexity of workflow (ie: Scheduling) then it is no longer easy to manage, especially if you want to do it in a heterogenous environment. If there were one clear, concise Calendaring and Scheduling model then we would not need to have this WG still arguing over trivial stuff like RSVP or very odd boundary cases for repeat grammars. This is partly why we still have pending questions on the table like Delegation chains, etc. You do not have to worry about that w/the much simpler Calendaring world. But we digress from the issue which I think (hope) should be resolved by now. I had asked Tom (Robert) Ransdell to take over the BYSETPOS thread for me when I got yanked off by mgmt... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B2E9C85256A95_= Content-Type: text/html; charset="US-ASCII"
Graham wrote:
>                                                               How many
>vCalendar (1.0) implementations exist out there simply because iCalendar
>was seen as too hard to implement?

  Just now getting back to CalSched backlog so excuse the lag here...

  vCalendar is very simple to do BECAUSE it has no workflow.  Standalone PIM Calendaring (no Scheduling) IS very well understood and easily done.  When you add the complexity of workflow (ie: Scheduling) then it is no longer easy to manage, especially if you want to do it in a heterogenous environment.  If there were one clear, concise Calendaring and Scheduling model then we would not need to have this WG still arguing over trivial stuff like RSVP or very odd boundary cases for repeat grammars.

  This is partly why we still have pending questions on the table like Delegation chains, etc.  You do not have to worry about that w/the much simpler Calendaring world.  But we digress from the issue which I think (hope) should be resolved by now.  I had asked Tom (Robert) Ransdell to take over the BYSETPOS thread for me when I got yanked off by mgmt...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006B2E9C85256A95_=-- From owner-ietf-calendar@mail.imc.org Thu Jul 26 16:19:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09352 for ; Thu, 26 Jul 2001 16:19:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QJrXK28557 for ietf-calendar-bks; Thu, 26 Jul 2001 12:53:33 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QJrWs28553 for ; Thu, 26 Jul 2001 12:53:32 -0700 (PDT) MIME-Version: 1.0 To: Jonathan Lennox Cc: Eric Busboom , ietf-calendar@imc.org, pregen@egenconsulting.com Subject: Re: Can we fix BYSETPOS? X-Mailer: Lotus Notes Build M10_07192001 Beta 3 July 19, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 26 Jul 2001 15:55:28 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 07/26/2001 03:56:26 PM, Serialize complete at 07/26/2001 03:56:26 PM Content-Type: multipart/alternative; boundary="=_alternative 006CE5F085256A95_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CE5F085256A95_= Content-Type: text/plain; charset="US-ASCII" Jonathan Lennox wrote on 20-Jun-2001: >We really need clear, formal semantics defined for all of the RRULE cases. >Ideally, a pseudo-code algorithm should be given for it. W/o waiting to read all the massive backlog I see I would simply ask if Toms postings helped clarify this better from my example? He was going to clarify my pseudo-algorigthm from my earlier examples. If not, then we can revisit this but I expect that his postings should be useful in providing some basis for the text you desire. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006CE5F085256A95_= Content-Type: text/html; charset="US-ASCII"
Jonathan Lennox wrote on 20-Jun-2001:
>We really need clear, formal semantics defined for all of the RRULE cases.
>Ideally, a pseudo-code algorithm should be given for it.

W/o waiting to read all the massive backlog I see I would simply ask if Toms postings helped clarify this better from my example?  He was going to clarify my pseudo-algorigthm  from my earlier examples.  If not, then we can revisit this but I expect that his postings should be useful in providing some basis for the text you desire.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 006CE5F085256A95_=-- From owner-ietf-calendar@mail.imc.org Thu Jul 26 17:35:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13846 for ; Thu, 26 Jul 2001 17:35:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QLGlj00281 for ietf-calendar-bks; Thu, 26 Jul 2001 14:16:47 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QLGis00277 for ; Thu, 26 Jul 2001 14:16:44 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA01701; Thu, 26 Jul 2001 17:16:34 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id RAA07632; Thu, 26 Jul 2001 17:16:33 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.34992.315762.676468@grandcentral.cs.columbia.edu> Date: Thu, 26 Jul 2001 17:16:32 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Graham Gilmore , hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, ietf-calendar@imc.org Subject: Additional RECAP and status of CPL RECUR Issues. In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thursday, July 26 2001, "Bruce_Kahn@iris.com" wrote to "Graham Gilmore, ietf-calendar@imc.org" saying: > Just now getting back to CalSched backlog so excuse the lag here... I've been ignoring things too. I apologize. > But we digress from the issue which I think > (hope) should be resolved by now. I had asked Tom (Robert) Ransdell to > take over the BYSETPOS thread for me when I got yanked off by mgmt... It should have been resolved, but I don't think it has been. We digressed pretty badly from the discussion. There are, I think, a few rather independent issues that came up. 1. The RECUR spec is confusingly-written, and has a lot of under-specified corner cases. This probably results in a fairly large amount of interoperability difficulty. I think there's consensus that this is a bad thing, but not much commitment to do anything about it; nor is there necessarily consensus on what the proper interpretation of all the corner cases should *be*. 2. The RECUR spec is general enough that it can give rise to "paradoxical" event descriptions -- that is, ones that can never occur. There was some effort to modify the spec to forbid certain "easy" paradoxical descriptions, but it's not clear that this will be sufficient. There was also some counter-pressure with the opinion that paradoxical recurrence descriptions shouldn't be forbidden, since their semantics are clear -- "this never happens" -- and they may add additional complexity to code to forbid them. I'm agnostic on this point. 3. Finally, the big point. There was a lot of concern over the fact that recurrence descriptions, in their full glorious generality, can require (nearly) arbitrarily large amounts of computing power to resolve. (Note that there were a few different definitions of "resolve" in play here.) This is directly contradictory to the requirements for CPL, which require that processing requirements for a CPL script to be predictable and bounded. There were a number of proposals for what to do about this, which turned out to be dependent on the resolution to point 1 (thus the digression). The classes of solutions could be summarized as follows: A. Re-define RECUR in the successor to RFC 2445, eliminating the problematic constructs. This will break backward compatibility, in theory (though it's not clear how much the problematic constructs are used in practice). B. Allow CPL, and other "consumers" of the iCalendar spec, to define subsets of the full RECUR specification. This will break interoperability between subset-consumers, which can no longer import full CPL RECUR statements. C. Declare that implementations of RECUR are free to implement as much or as little of the specification as they choose to, so long as they have some way to detect and report that a RECUR specification exceeds their implementation limits. This will make interoperability effectively entirely unpredictable. D. Define limits, at SHOULD strength, parameterizing the items that a RECUR interpreter ought to support. Similarly, say that RECUR generators SHOULD NOT exceed these limits unless they know through some out-of-band means that their interpreter will be able to process them correctly. This is effectively a version of option A which "walls off" the problematic constructs without removing them entirely. I'd also like to review what I saw as the problematic constructs in question. Since, as I mentioned before, the definition of "resolve" depends on what people are trying to do, I'll give one, the one that CPL needs: "Given a recurrence rule, and an instant in time, does the instant fall within some repetition of the recurrence rule?" (This is, incidentally, equivalent to the question "Given a recurrence rule, and an instant in time, is there a start time of the rule that falls in the period (instant - DURATION, instant)?" Thus, the general problem is roughly the "is there a start time that falls within this time period.) Most aspects of RECUR can be resolved using an amount of processing linearly proportional to the textual length of the rule. However, there are three exceptions to this: I. COUNT statements. It does not appear to be possible to resolve these other than by enumerating every instance of an event starting from DTSTART, until you satisfy the count. However, since this can be done off-line, and only needs to be done once, consensus was that this wasn't a huge problem. However, some sort of sanity bound on COUNT might still be helpful. II. Long DURATIONs. As I mentioned in my brief summary above, to find out if an instant falls within a repetition of a recurrence, you need to search for start times in a period of time that is DURATION before the instant. If DURATION is large, then this can be inefficient in most algorithms. (Specifically, it seems to be proportional to the duration divided by the smallest time unit mentioned; so a three-year DURATION in a YEARLY rule without expanding BY*rules is no problem, but a one-week DURATION in a SECONDLY rule with complex contracting BY*rules is.) III. BYSETPOS. In order to resolve a BYSETPOS, you (obviously) need to have some way of deteriming the set position of an otherwise-valid start time. I have not found any way of doing this other than by fully enumerating a set repetition. (This led to some huge amounts of digression about what a set repetition is.) A sufficiently complex rule can have up to 31 million set repetitions, which is too many for CPL's requirements. This is complicated additionally by the fact that RFC 2445 requires that BYSETPOS values be in the range -366 .. 366. It seems to have been the original intention that BYSETPOS would only be used with rules discussing periods of a day or more. There is not, I believe, any consensus on this point. My proposal for this point would be to go with my solution "D" above. Specifically, I'd say that calendaring clients SHOULD NOT generate rules with long COUNT values, long DURATION values, or BYSETPOS rules that mix with sub-day parameters of any sort, unless they know, through some out-of-band means, that the calendaring server they are communicating with is able and willing to interpret such things. That's my summary of the current situation. I will not be at the London IETF. It'd be good if we could have some discussion on this list, before that, so as to work out what should be done about this whole issue. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Thu Jul 26 19:01:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20029 for ; Thu, 26 Jul 2001 19:01:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QMcJM01933 for ietf-calendar-bks; Thu, 26 Jul 2001 15:38:19 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6QMcIs01928 for ; Thu, 26 Jul 2001 15:38:18 -0700 (PDT) Received: (qmail 493179 invoked from network); 26 Jul 2001 22:34:13 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 26 Jul 2001 22:34:13 -0000 Message-ID: <3B6099D0.C550F5A8@kasey.umkc.edu> Date: Thu, 26 Jul 2001 17:29:36 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox CC: Bruce_Kahn@iris.com, Graham Gilmore , hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, ietf-calendar@imc.org Subject: Re: Additional RECAP and status of CPL RECUR Issues. References: <15200.34992.315762.676468@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: ... > A. Re-define RECUR in the successor to RFC 2445, eliminating the > problematic constructs. This will break backward compatibility, in > theory (though it's not clear how much the problematic constructs are > used in practice). I hope I'm not alone in thinking that delivering a document with known weaknesses you are Hoping Will Get Rewritten In A Future Release stinks. (this also goes for anonymous delegation.) A possible solution which was not included in Mr. Lennox's list which comes to my mind would be to exchange a RECUR language for the ability to link to an event from multiple dates/times/locations, and have the CUA interpret its own implementation-specific RECUR language and tell the CS something like ALSOON August 4, 2001 September 4, 2001 October 5, 2001 January 4, 2002 . without the CS needing to make any overall sense of the logic of the dates listed at all. At that point, it would make sense to defer fully specifying a RECUR language that might get uploaded to the CS to future, since there would be experience with these various impl-specif client-side RECUR languages. in other words, CS MUST support list of dates/times/locations CS SHOULD support minimal subset of RECUR language CS MAY support arbitrary RECUR vendor-extensions (with a way for vendors to optionally register them written in.) -- David Nicol 816.235.1187 From owner-ietf-calendar@mail.imc.org Thu Jul 26 19:38:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22698 for ; Thu, 26 Jul 2001 19:38:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QNMTe02740 for ietf-calendar-bks; Thu, 26 Jul 2001 16:22:29 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QNMRs02733 for ; Thu, 26 Jul 2001 16:22:27 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA01553 for ; Thu, 26 Jul 2001 18:20:55 -0500 From: "Shannon J. Clark" To: Subject: RE: Additional RECAP and status of CPL RECUR Issues. Date: Thu, 26 Jul 2001 18:22:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3B6099D0.C550F5A8@kasey.umkc.edu> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Since I have in the past spoken up on this issue - a few comments and thoughts. One - the concept of a "simple" list of the other occurrences of an event - while seemingly simple - gets really really ugly fast if you have to deal with any of the following - events that recur "forever" (the Monday morning conference call); events that are LOCAL and REOCCURRING - thus the "time" of each reoccurrence might be dependant on a user's timezone settings (and further complicated by Daylight savings shifts that result in the possible case of events "reoccurring" on a non-existent time; Events with a large reoccurrence set - for a simple example an entry on a calendar intended to define my "work days" for the year - could be entered easily as an event that reoccurs from 9-5pm Mon-Fri having a set of exceptions mapped to my client's holidays - even bound to one year - this event could have a simple RRULE w/10 Exceptions - or if enumerated will over 200+ dates in a list - probably increasing the size considerably. Two - on the related concept of removing RRULES to a degree from RFC2445 - I think this is a GOOD idea - my suggestion would be to define the RRULES in a SEPARATE standards track - one that is very much tied to RFC2445 (but no solely defined therein) - this allows the RRULES to be applied in a clean fashion to other programs requiring Temporal Reoccurrences (such as Caches) - without adding the scheduling/meeting infrastructure and overhead of iCalendar. Furthermore - by increasing the number of applications utilizing the RRULE syntax - and by involving more applications (like CPL) that require near-realtime resolution of the RRULEs into a useful form - I suspect that the development of reference algorithms for efficient and accuracy expansion (or algorithms for programmatic resolution of questions of overlap/occurrence - will be sped up and developed more quickly. Anyway - just my quick thoughts on the subject Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of David L. Nicol Sent: Thursday, July 26, 2001 5:30 PM To: Jonathan Lennox Cc: Bruce_Kahn@iris.com; Graham Gilmore; hgs@cs.columbia.edu; jdrosen@dynamicsoft.com; ietf-calendar@imc.org Subject: Re: Additional RECAP and status of CPL RECUR Issues. Jonathan Lennox wrote: ... > A. Re-define RECUR in the successor to RFC 2445, eliminating the > problematic constructs. This will break backward compatibility, in > theory (though it's not clear how much the problematic constructs are > used in practice). I hope I'm not alone in thinking that delivering a document with known weaknesses you are Hoping Will Get Rewritten In A Future Release stinks. (this also goes for anonymous delegation.) A possible solution which was not included in Mr. Lennox's list which comes to my mind would be to exchange a RECUR language for the ability to link to an event from multiple dates/times/locations, and have the CUA interpret its own implementation-specific RECUR language and tell the CS something like ALSOON August 4, 2001 September 4, 2001 October 5, 2001 January 4, 2002 . without the CS needing to make any overall sense of the logic of the dates listed at all. At that point, it would make sense to defer fully specifying a RECUR language that might get uploaded to the CS to future, since there would be experience with these various impl-specif client-side RECUR languages. in other words, CS MUST support list of dates/times/locations CS SHOULD support minimal subset of RECUR language CS MAY support arbitrary RECUR vendor-extensions (with a way for vendors to optionally register them written in.) -- David Nicol 816.235.1187 From owner-ietf-calendar@mail.imc.org Thu Jul 26 19:54:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24116 for ; Thu, 26 Jul 2001 19:54:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QNf2R03025 for ietf-calendar-bks; Thu, 26 Jul 2001 16:41:02 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QNf0s03015 for ; Thu, 26 Jul 2001 16:41:01 -0700 (PDT) To: Jonathan Lennox Cc: Alan Davies , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build M10_07192001 Beta 3 July 19, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 26 Jul 2001 18:17:32 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 07/26/2001 07:43:56 PM, Serialize complete at 07/26/2001 07:43:56 PM Content-Type: multipart/alternative; boundary="=_alternative 0079F00785256A95_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079F00785256A95_= Content-Type: text/plain; charset="US-ASCII" Jonathan Lennox wrote on 11-Jun-01: >This also means that you need a clear distinction between "original-X" and >"extended-X." Having them shade vaguely into each other is a bad idea. Thats why we defined the ABNF to use iana-token and x-tokens so that an older parser would at least be able to parse the formalized extensions (iana-token) and the experimental or custom ones vendors add on for assorted reasons (x-token). That is also why we have VERSION that allows for minver and maxver. An older "2.0" client may not fully grok the new "2.5" objects intent but if that object says that minver is 2.0 then the 2.0 client should be able to take some reasonable action on that object. Any revisions or extensions to 2445 should (will??) be done is such a way as to minimize the possible disjoin. >> But the logic that "If my engine >> does not like Feature X of a protocol for some reason so it wont be able >> to interop with others that do" is simply a myth if the protocol plans >> ahead and provides ways for conveying this back (hence some of the >> REQUEST-STATUS values in iTIP). [Snip] >Are you saying I shouldn't be able to e-mail you an iCalendar object, or to >put it on my web page? Absolutely NOT. I fully expect to be able to receive iCalendar objects via eMail, Web site, FTP, etc. What I am saying is that claiming interoperability wont happen just because any particular engine cannot deal with a 'feature' of iCaledar is just a myth. If that were a trueism then MIME extensions would never have been possible. However MIME lays out expected behaviour for 'unknown' types and subtypes so that MUAs can still 'interoperate' just fine. >Oh, absolutely. I reached this point of view by worring about entries >generated by actively hostile adversaries, who want to launch a >denial-of-service attack on my server by feeding me input that makes me fall >over. If you're not worried about this case, things are not nearly so much >of a problem. (Though I would say that current experience in the Internet >seems to indicate that you *do* have to worry about this.) Well Id hope that you would have considered putting in some kinds of filters to prevent just anyone from randomly sending iCalendar objects that your CPL engine would just blindly accept and process. These could be anything from requireing authentication of the user to ECLs to quotas on the CPL that someone can send (assuming you want to prevent internal 'bombings' from leaving employees, etc). I have yet to be convinced that the data format is the place to put such kinds of controls/filters/security (pending CAP). I would suggest that these kinds of concerns/constraints are not iCalendar issues currently (again, pending CAP) and that the responsible parties should be dealing with it in an appropriate manner. >> For the CPL case the CUA / CS has some restrictions on what it will be >> able to accept (ie: no sub-day recurrences) but is that an "absurd" case >> like "repeating every second of every day of the year" or a more realistic >> case like "The walking tour of Boston begins at 9:00AM and again at 1:00PM >> EST". The CPL worlds requirements are such that it cannot accept >> (currently) some kinds of real world examples (not absurdities) and that >> is fine; its part of their model of things. In the future there will be >> other models that do not have those restrictions (ie: SKiCAL). > >My original model of CPL was to define a number of restrictions on what a >CPL script had to accept. This was where the IESG got all up in arms -- >"you're breaking interoperability with iCalendar!" Okay, I figured, >interoperability with iCalendar on (moderately) complex or pathological >cases is important, so we need a good definition of what's allowed and >what's too complex or pathological. But now I'm hearing that CalSch >*doesn't* want to define this, that each implementation is allowed to pick >its own definition of complex and pathological events. There is a fine line between having the standard define what is 'absurd' and leaving it to each implementation to decide that. Given that each implementation has its own underlying architecture as well as usage model there is some leeway between what is patently absurd for all C&S and what some apps may consider absurd. I do think that for the C&S world CalSched can define its own set of rules as to what we consider truely absurd while not precluding reuse or expansion in the future. In the case of recurrence grammars we have attempted to create a powerful and flexible grammar that can be reused. From what Ive heard so far I do not think its way off the mark; just some clarifications seem to be in order (along w/some better examples). Your restrictions were not necessarily ones that a C&S implementation would have used since it has a different focus. Your reuse of our format would have mandated changes that would prevent some existing CUAs from working w/other CUAs in addition to any CPL server. The WG had already considered that differences of architecture/implementation would happen and we created the REQUEST-STATUS property to help deal with it. Instead of ipTel considering that in its design from what I read initially, it appeared as if ipTel expected all implemenations to always be at the same 'level' of functionality. No apparent design was put into dealing with older CPL servers and newer clients (or visa versa) so there was no way to communicate this diversity. This is an overly optimistic view of the world... As systems get faster, CPL servers will presumably be able to do more processing of RRULEs in the same O(1) time so I would hope that the CPL draft would take that into account. So far Ive yet to hear why the CPL server cannot simply reject the iCalendar that it deems unable to be processed in O(1) and accept others. Even w/o a BYSETPOS subcomponent, it is still possible for me to generate ~31M instances using time BYxxx subcomponents. Unless you propose removing them entirely then the CPL server needs to be able to deal w/them and presumably reject the iCalendar object that contains any BYHOUR, BYMINUTE or BYSECOND. So why cant the same prefiltering be done by a CPL server for BYSETPOS instead of removing it entirely? This may be belaboring a point that has already been resolved and if so, great. However, if not then we can revisit BYSETPOS once we have some clearer points of discussion identified. > Compliant iCalendar CS or CUAs should not generate event descriptions > beyond the basic subset unless they know that all receivers of the event > can understand them correctly. You can nevery really claim this with MUAs or CUAs. I may suspect that, say, Steve Mansour is using the iPlanet CUA since hes its PM and that my friends at Microsoft are using Exchange/Outlook but I have absolutely 0 idea what Jonathans CUA/MUA is. Its not possible to tell that short of looking at the PRODID of an iCalendar you send me (and even then...). This is why we built VERSION to have a "minver;maxver" format so that a newer CUA could send an iCalendar object to any ATTENDEE and their CUA could detect if it can even deal with the iCalendar or not. If the recieving CUA is below the minver then it cannot really deal with it and it should 'fail gracefully' (thats a technical term). At one point we had an example of that in one of our drafts but its been 3+ years since I even looked for it. Perhaps Eric or Steve can confirm it and post the citation (no time to search if I want to get thru this backlog). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From: owner-ietf-calendar@mail.imc.org Date: 06/11/2001 07:10:33 PM AST Subject: Re: Can we fix BYSETPOS? On Monday, June 11 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Alan Davies, ietf-calendar@imc.org" saying: > Jonathan responded with: > >As we've discussed before on these lists, we have two choices when it > >comes to dealing with absurd statuses: > > > >1. Let each implementation decide what it isn't going to handle. > >2. Let the standard limit what implementations have to support. > > > >The problem with choice 1 is that it effectively abandons > >interoperability. > > Well unless you expect _every_ implementation to implement every > feature/option the exact same way then this is not really a problem. We > would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP > (or... ) since every implementation implements only a fixed set of > features and we would never have a migration case since the set never > grows w/o _every_ implemenation concurrently rolling it out... iCalendar COS isn't like IMAP4 or SMTP. iCalendar COS is like RFC822 or HTML. It's a data format. iTIP is like IMAP4 or SMTP. It's a transaction protocol. When RFC822 was extended with MIME you got "If you can see this, your mail reader doesn't understand MIME" blocks, and large unreadable blobs of base64-encoded text. When HTML was extended with frames, you got sections that were supposed to contain equivalent content, but actually contained "Netscape Now!" buttons. Or, in other words, extensibility in data formats is almost always painful. Now, mind you, sometimes you need to have your data formats be extensible. However, when you do this, experience seems to have shown that the right thing to do is to have the thing say, up front, "I'm an extended-X. I may look like an original-X, but I'm not, so if you don't know what an extended-X is, give up now." This also means that you need a clear distinction between "original-X" and "extended-X." Having them shade vaguely into each other is a bad idea. > Ok, the sarcasm was a bit heavy there but I got stuck in a 2.5 hour mtg > today for no reason so Im a bit punchy. But the logic that "If my engine > does not like Feature X of a protocol for some reason so it wont be able > to interop with others that do" is simply a myth if the protocol plans > ahead and provides ways for conveying this back (hence some of the > REQUEST-STATUS values in iTIP). If there's a protocol which is specific to your application, yes. > Before we accept that most CUAs are going to actually generate and use > some of these "absurd" entries I'd contest the fact that they would to > begin with. The existing C&S CUAs from CalConnect do a decent job of not > actually generating some of the overly complex, nasty or "absurd" entries > so is it realistic to think that the current or immediately pending crop > of CUAs are going to generate them? Probably not. Even if someone redid > an OpenSource C&S app to generate them; its not likely to be the SOP we > will find in day to day usage. Oh, absolutely. I reached this point of view by worring about entries generated by actively hostile adversaries, who want to launch a denial-of-service attack on my server by feeding me input that makes me fall over. If you're not worried about this case, things are not nearly so much of a problem. (Though I would say that current experience in the Internet seems to indicate that you *do* have to worry about this.) > For the CPL case the CUA / CS has some restrictions on what it will be > able to accept (ie: no sub-day recurrences) but is that an "absurd" case > like "repeating every second of every day of the year" or a more realistic > case like "The walking tour of Boston begins at 9:00AM and again at 1:00PM > EST". The CPL worlds requirements are such that it cannot accept > (currently) some kinds of real world examples (not absurdities) and that > is fine; its part of their model of things. In the future there will be > other models that do not have those restrictions (ie: SKiCAL). My original model of CPL was to define a number of restrictions on what a CPL script had to accept. This was where the IESG got all up in arms -- "you're breaking interoperability with iCalendar!" Okay, I figured, interoperability with iCalendar on (moderately) complex or pathological cases is important, so we need a good definition of what's allowed and what's too complex or pathological. But now I'm hearing that CalSch *doesn't* want to define this, that each implementation is allowed to pick its own definition of complex and pathological events. So I find myself in the situation that I'm told I have to be fully interoperable with a number of implementations which aren't fully interoperable with each other. This is ... challenging. Is this group willing to say, definitively: Every iCalendar CS or CUA implementation is allowed to pick its own definition, aribitrarily, of what event descriptions are too complex for it to handle, and refuse to handle such event descriptions. Such implementations are still fully compliant implementations of RFC 2445 and its successors. If so, I'll just resurrect the last CPL draft with some minor editorial changes, tell the IESG about the CalSch working group consensus, and be on my way to Proposed Standard. However, I suspect the IESG would have *serious* concerns with this statement. (And I don't think the group would be willing to say it, anyway.) As I mentioned in my earlier mail, I think the following statement would be much more generally acceptable: Every compliant iCalendar CS or CUA must be able to correctly understand a certain basic subset of event descriptions, defined by the specification. They may also understand more general event descriptions. Compliant iCalendar CS or CUAs should not generate event descriptions beyond the basic subset unless they know that all receivers of the event can understand them correctly. Profiles of iCalendar can declare that a larger subset of iCalendar is required for that profile. > Again this last bit assums that some to-be-written CUA will actually > generate internally (and use??) an absurd case and I challenge that > assumption. Sure, it is possible to build a CUA that is purposely nasty > but is that a realistic norm or a "what about" kind of exception to the > rule?? Some of both. If I'm writing a powerful CUA, I want to know what sorts of things I should *avoid* generating to prevent a CS from choking. (For instance, I know of calendaring applications that refuse to deal with events with more than 500 or so repetitions. I don't think these applications currently make any claim to iCalendar support -- they're just vCalendar, or something proprietary, I think -- but it's the sort of thing you have to worry about.) -- Jonathan Lennox lennox@cs.columbia.edu --=_alternative 0079F00785256A95_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Jonathan Lennox wrote on 11-Jun-01:</font> <br><font size=2 face="Courier New">&gt;This also means that you need a clear distinction between &quot;original-X&quot; and<br> &gt;&quot;extended-X.&quot; &nbsp;Having them shade vaguely into each other is a bad idea.</font> <br> <br><font size=2 face="sans-serif">Thats why we defined the ABNF to use iana-token and x-tokens so that &nbsp;an older parser would at least be able to parse the formalized extensions (iana-token) and the experimental or custom ones vendors add on for assorted reasons (x-token). &nbsp;</font> <br> <br><font size=2 face="sans-serif">That is also why we have VERSION that allows for minver and maxver. &nbsp;An older &quot;2.0&quot; client may not fully grok the new &quot;2.5&quot; objects intent but if that object says that minver is 2.0 then the 2.0 client should be able to take some reasonable action on that object. &nbsp;</font> <br> <br><font size=2 face="sans-serif">Any revisions or extensions to 2445 should (will??) be done is such a way as to minimize the possible disjoin.</font> <br> <br><font size=2 face="Courier New">&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;But the logic that &quot;If my engine <br> &gt;&gt; does not like Feature X of a protocol for some reason so it wont be able <br> &gt;&gt; to interop with others that do&quot; is simply a myth if the protocol plans <br> &gt;&gt; ahead and provides ways for conveying this back (hence some of the <br> &gt;&gt; REQUEST-STATUS values in iTIP).</font> <br><font size=2 face="Courier New">[Snip]</font> <br><font size=2 face="Courier New">&gt;Are you saying I shouldn't be able to e-mail you an iCalendar object, or to<br> &gt;put it on my web page?<br> </font> <br><font size=2 face="sans-serif">Absolutely NOT. &nbsp;I fully expect to be able to receive iCalendar objects via eMail, Web site, FTP, etc. &nbsp;What I am saying is that claiming interoperability wont happen just because any particular engine cannot deal with a 'feature' of iCaledar is just a myth. &nbsp;If that were a trueism then MIME extensions would never have been possible. &nbsp;However MIME lays out expected behaviour for 'unknown' types and subtypes so that MUAs can still 'interoperate' just fine.</font> <br> <br><font size=2 face="Courier New">&gt;Oh, absolutely. &nbsp;I reached this point of view by worring about entries<br> &gt;generated by actively hostile adversaries, who want to launch a<br> &gt;denial-of-service attack on my server by feeding me input that makes me fall<br> &gt;over. &nbsp;If you're not worried about this case, things are not nearly so much<br> &gt;of a problem. &nbsp;(Though I would say that current experience in the Internet<br> &gt;seems to indicate that you *do* have to worry about this.)</font> <br> <br><font size=2 face="Courier New">Well Id hope that you would have considered putting in some kinds of filters to prevent just anyone from randomly sending iCalendar objects that your CPL engine would just blindly accept and process. &nbsp;These could be anything from requireing authentication of the user to ECLs to quotas on the CPL that someone can send (assuming you want to prevent internal 'bombings' from leaving employees, etc).</font> <br> <br><font size=2 face="Courier New">I have yet to be convinced that the data format is the place to put such kinds of controls/filters/security (pending CAP). &nbsp;I would suggest that these kinds of concerns/constraints are not iCalendar issues currently (again, pending CAP) and that the responsible parties should be dealing with it in an appropriate manner.</font> <br> <br><font size=2 face="Courier New">&gt;&gt; For the CPL case the CUA / CS has some restrictions on what it will be <br> &gt;&gt; able to accept (ie: no sub-day recurrences) but is that an &quot;absurd&quot; case <br> &gt;&gt; like &quot;repeating every second of every day of the year&quot; or a more realistic <br> &gt;&gt; case like &quot;The walking tour of Boston begins at 9:00AM and again at 1:00PM <br> &gt;&gt; EST&quot;. &nbsp;The CPL worlds requirements are such that it cannot accept <br> &gt;&gt; (currently) some kinds of real world examples (not absurdities) and that <br> &gt;&gt; is fine; its part of their model of things. &nbsp;In the future there will be <br> &gt;&gt; other models that do not have those restrictions (ie: SKiCAL). <br> &gt;<br> &gt;My original model of CPL was to define a number of restrictions on what a<br> &gt;CPL script had to accept. &nbsp;This was where the IESG got all up in arms --<br> &gt;&quot;you're breaking interoperability with iCalendar!&quot; &nbsp;Okay, I figured,<br> &gt;interoperability with iCalendar on (moderately) complex or pathological<br> &gt;cases is important, so we need a good definition of what's allowed and<br> &gt;what's too complex or pathological. &nbsp;But now I'm hearing that CalSch<br> &gt;*doesn't* want to define this, that each implementation is allowed to pick<br> &gt;its own definition of complex and pathological events.<br> </font> <br><font size=2 face="sans-serif">There is a fine line between having the standard define what is 'absurd' and leaving it to each implementation to decide that. &nbsp;Given that each implementation has its own underlying architecture as well as usage model there is some leeway between what is patently absurd for all C&amp;S and what some apps may consider absurd. &nbsp;I do think that for the C&amp;S world CalSched can define its own set of rules as to what we consider truely absurd while not precluding reuse or expansion in the future. &nbsp;In the case of recurrence grammars we have attempted to create a powerful and flexible grammar that can be reused. &nbsp;From what Ive heard so far I do not think its way off the mark; just some clarifications seem to be in order (along w/some better examples).</font> <br> <br><font size=2 face="sans-serif">Your restrictions were not necessarily ones that a C&amp;S implementation would have used since it has a different focus. &nbsp;Your reuse of our format would have mandated changes that would prevent some existing CUAs from working w/other CUAs in addition to any CPL server. &nbsp;The WG had already considered that differences of architecture/implementation would happen and we created the REQUEST-STATUS property to help deal with it. &nbsp;Instead of ipTel considering that in its design from what I read initially, it appeared as if ipTel expected all implemenations to always be at the same 'level' of functionality. &nbsp;No apparent design was put into dealing with older CPL servers and newer clients (or visa versa) so there was no way to communicate this diversity. &nbsp;This is an overly optimistic view of the world...</font> <br> <br><font size=2 face="sans-serif">As systems get faster, CPL servers will presumably be able to do more processing of RRULEs in the same O(1) time so I would hope that the CPL draft would take that into account. &nbsp;So far Ive yet to hear why the CPL server cannot simply reject the iCalendar that it deems unable to be processed in O(1) and accept others. &nbsp;Even w/o a BYSETPOS subcomponent, it is still possible for me to generate ~31M instances using time BYxxx subcomponents. &nbsp;Unless you propose removing them entirely then the CPL server needs to be able to deal w/them and presumably reject the iCalendar object that contains any BYHOUR, BYMINUTE or BYSECOND. &nbsp;So why cant the same prefiltering be done by a CPL server for BYSETPOS instead of removing it entirely?</font> <br> <br><font size=2 face="sans-serif">This may be belaboring a point that has already been resolved and if so, great. &nbsp;However, if not then we can revisit BYSETPOS once we have some clearer points of discussion identified.</font> <br> <br><font size=2 face="Courier New">&gt; &nbsp; Compliant iCalendar CS or CUAs should not generate event descriptions<br> &gt; &nbsp; beyond the basic subset unless they know that all receivers of the event<br> &gt; &nbsp; can understand them correctly.</font> <br> <br><font size=2 face="sans-serif">You can nevery really claim this with MUAs or CUAs. &nbsp;I may suspect that, say, Steve Mansour is using the iPlanet CUA since hes its PM and that my friends at Microsoft are using Exchange/Outlook but I have absolutely 0 idea what Jonathans CUA/MUA is. &nbsp;Its not possible to tell that short of looking at the PRODID of an iCalendar you send me (and even then...).</font> <br> <br><font size=2 face="sans-serif">This is why we built VERSION to have a &quot;minver;maxver&quot; format so that a newer CUA could send an iCalendar object to any ATTENDEE and their CUA could detect if it can even deal with the iCalendar or not. &nbsp;If the recieving CUA is below the minver then it cannot really deal with it and it should 'fail gracefully' (thats a technical term). &nbsp;At one point we had an example of that in one of our drafts but its been 3+ years since I even looked for it. &nbsp;Perhaps Eric or Steve can confirm it and post the citation (no time to search if I want to get thru this backlog).</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> <br> <br> <br> <br><font size=2 color=blue face="sans-serif"><b>From: &nbsp; &nbsp; &nbsp; &nbsp;</b></font><font size=2 face="sans-serif">owner-ietf-calendar@mail.imc.org</font> <br><font size=2 color=blue face="sans-serif"><b>Date: &nbsp; &nbsp; &nbsp; &nbsp;</b></font><font size=2 face="sans-serif">06/11/2001 07:10:33 PM AST</font> <br><font size=2 color=blue face="sans-serif"><b>Subject: &nbsp; &nbsp; &nbsp; &nbsp;</b></font><font size=2 face="sans-serif">Re: Can we fix BYSETPOS?</font> <br> <br><font size=2 face="Courier New"><br> On Monday, June 11 2001, &quot;Bruce_Kahn@iris.com&quot; wrote to &quot;Jonathan Lennox, Alan Davies, ietf-calendar@imc.org&quot; saying:<br> <br> &gt; Jonathan responded with:<br> &gt; &gt;As we've discussed before on these lists, we have two choices when it <br> &gt; &gt;comes to dealing with absurd statuses:<br> &gt; &gt;<br> &gt; &gt;1. Let each implementation decide what it isn't going to handle.<br> &gt; &gt;2. Let the standard limit what implementations have to support.<br> &gt; &gt;<br> &gt; &gt;The problem with choice 1 is that it effectively abandons <br> &gt; &gt;interoperability.<br> &gt; <br> &gt; Well unless you expect _every_ implementation to implement every<br> &gt; feature/option the exact same way then this is not really a problem. &nbsp;We<br> &gt; would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP<br> &gt; (or... ) since every implementation implements only a fixed set of<br> &gt; features and we would never have a migration case since the set never<br> &gt; grows w/o _every_ implemenation concurrently rolling it out...<br> <br> iCalendar COS isn't like IMAP4 or SMTP. &nbsp;iCalendar COS is like RFC822 or<br> HTML. &nbsp;It's a data format.<br> <br> iTIP is like IMAP4 or SMTP. &nbsp;It's a transaction protocol.<br> <br> When RFC822 was extended with MIME you got &quot;If you can see this, your mail<br> reader doesn't understand MIME&quot; blocks, and large unreadable blobs of<br> base64-encoded text. &nbsp;When HTML was extended with frames, you got &lt;noframes&gt;<br> sections that were supposed to contain equivalent content, but actually<br> contained &quot;Netscape Now!&quot; buttons.<br> <br> Or, in other words, extensibility in data formats is almost always painful.<br> <br> Now, mind you, sometimes you need to have your data formats be extensible.<br> However, when you do this, experience seems to have shown that the right<br> thing to do is to have the thing say, up front, &quot;I'm an extended-X. &nbsp;I may<br> look like an original-X, but I'm not, so if you don't know what an<br> extended-X is, give up now.&quot;<br> <br> This also means that you need a clear distinction between &quot;original-X&quot; and<br> &quot;extended-X.&quot; &nbsp;Having them shade vaguely into each other is a bad idea.<br> <br> &gt; Ok, the sarcasm was a bit heavy there but I got stuck in a 2.5 hour mtg <br> &gt; today for no reason so Im a bit punchy. &nbsp;But the logic that &quot;If my engine <br> &gt; does not like Feature X of a protocol for some reason so it wont be able <br> &gt; to interop with others that do&quot; is simply a myth if the protocol plans <br> &gt; ahead and provides ways for conveying this back (hence some of the <br> &gt; REQUEST-STATUS values in iTIP).<br> <br> If there's a protocol which is specific to your application, yes.<br> <br> <br> &gt; Before we accept that most CUAs are going to actually generate and use <br> &gt; some of these &quot;absurd&quot; entries I'd contest the fact that they would to <br> &gt; begin with. &nbsp;The existing C&amp;S CUAs from CalConnect do a decent job of not <br> &gt; actually generating some of the overly complex, nasty or &quot;absurd&quot; entries <br> &gt; so is it realistic to think that the current or immediately pending crop <br> &gt; of CUAs are going to generate them? &nbsp;Probably not. &nbsp;Even if someone redid <br> &gt; an OpenSource C&amp;S app to generate them; its not likely to be the SOP we <br> &gt; will find in day to day usage.<br> <br> Oh, absolutely. &nbsp;I reached this point of view by worring about entries<br> generated by actively hostile adversaries, who want to launch a<br> denial-of-service attack on my server by feeding me input that makes me fall<br> over. &nbsp;If you're not worried about this case, things are not nearly so much<br> of a problem. &nbsp;(Though I would say that current experience in the Internet<br> seems to indicate that you *do* have to worry about this.)<br> <br> &gt; For the CPL case the CUA / CS has some restrictions on what it will be <br> &gt; able to accept (ie: no sub-day recurrences) but is that an &quot;absurd&quot; case <br> &gt; like &quot;repeating every second of every day of the year&quot; or a more realistic <br> &gt; case like &quot;The walking tour of Boston begins at 9:00AM and again at 1:00PM <br> &gt; EST&quot;. &nbsp;The CPL worlds requirements are such that it cannot accept <br> &gt; (currently) some kinds of real world examples (not absurdities) and that <br> &gt; is fine; its part of their model of things. &nbsp;In the future there will be <br> &gt; other models that do not have those restrictions (ie: SKiCAL). <br> <br> My original model of CPL was to define a number of restrictions on what a<br> CPL script had to accept. &nbsp;This was where the IESG got all up in arms --<br> &quot;you're breaking interoperability with iCalendar!&quot; &nbsp;Okay, I figured,<br> interoperability with iCalendar on (moderately) complex or pathological<br> cases is important, so we need a good definition of what's allowed and<br> what's too complex or pathological. &nbsp;But now I'm hearing that CalSch<br> *doesn't* want to define this, that each implementation is allowed to pick<br> its own definition of complex and pathological events.<br> <br> So I find myself in the situation that I'm told I have to be fully<br> interoperable with a number of implementations which aren't fully<br> interoperable with each other. &nbsp;This is ... challenging.<br> <br> <br> Is this group willing to say, definitively:<br> <br> &nbsp; Every iCalendar CS or CUA implementation is allowed to pick its own<br> &nbsp; definition, aribitrarily, of what event descriptions are too complex for<br> &nbsp; it to handle, and refuse to handle such event descriptions. &nbsp;Such<br> &nbsp; implementations are still fully compliant implementations of RFC 2445 and<br> &nbsp; its successors.<br> <br> If so, I'll just resurrect the last CPL draft with some minor editorial<br> changes, tell the IESG about the CalSch working group consensus, and be on<br> my way to Proposed Standard. &nbsp;However, I suspect the IESG would have<br> *serious* concerns with this statement. &nbsp;(And I don't think the group would<br> be willing to say it, anyway.)<br> <br> As I mentioned in my earlier mail, I think the following statement would be<br> much more generally acceptable:<br> <br> &nbsp; Every compliant iCalendar CS or CUA must be able to correctly understand<br> &nbsp; a certain basic subset of event descriptions, defined by the<br> &nbsp; specification. &nbsp;They may also understand more general event<br> &nbsp; descriptions.<br> &nbsp; Compliant iCalendar CS or CUAs should not generate event descriptions<br> &nbsp; beyond the basic subset unless they know that all receivers of the event<br> &nbsp; can understand them correctly.<br> &nbsp; Profiles of iCalendar can declare that a larger subset of iCalendar is<br> &nbsp; required for that profile.<br> <br> &gt; Again this last bit assums that some to-be-written CUA will actually <br> &gt; generate internally (and use??) an absurd case and I challenge that <br> &gt; assumption. &nbsp;Sure, it is possible to build a CUA that is purposely nasty <br> &gt; but is that a realistic norm or a &quot;what about&quot; kind of exception to the <br> &gt; rule??<br> <br> Some of both. &nbsp;If I'm writing a powerful CUA, I want to know what sorts of<br> things I should *avoid* generating to prevent a CS from choking. &nbsp;(For<br> instance, I know of calendaring applications that refuse to deal with events<br> with more than 500 or so repetitions. &nbsp;I don't think these applications<br> currently make any claim to iCalendar support -- they're just vCalendar, or<br> something proprietary, I think -- but it's the sort of thing you have to<br> worry about.) <br> <br> -- <br> Jonathan Lennox<br> lennox@cs.columbia.edu<br> </font><font size=2 face="sans-serif"> </font> <br> <br> --=_alternative 0079F00785256A95_=-- From owner-ietf-calendar@mail.imc.org Thu Jul 26 20:34:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26021 for <calsch-archive@odin.ietf.org>; Thu, 26 Jul 2001 20:34:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6R0E7e03576 for ietf-calendar-bks; Thu, 26 Jul 2001 17:14:07 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6R0E6s03572 for <ietf-calendar@imc.org>; Thu, 26 Jul 2001 17:14:06 -0700 (PDT) Received: (qmail 494603 invoked from network); 27 Jul 2001 00:10:02 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 27 Jul 2001 00:10:02 -0000 Message-ID: <3B60B045.61858315@kasey.umkc.edu> Date: Thu, 26 Jul 2001 19:05:25 -0500 From: "David L. Nicol" <david@kasey.umkc.edu> Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" <shannon@jigzaw.com> CC: ietf-calendar@imc.org Subject: Re: Additional RECAP and status of CPL RECUR Issues. References: <NEBBKFJICLIPPJJJBCFCCEFICPAA.shannon@jigzaw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit -- "Shannon J. Clark" wrote: > One - the concept of a "simple" list of the other occurrences of an event - > while seemingly simple - gets really really ugly fast if you have to deal > with any of the following - events that recur "forever" (the Monday morning > conference call); events that are LOCAL and REOCCURRING - thus the "time" of > each reoccurrence might be dependant on a user's timezone settings (and > further complicated by Daylight savings shifts that result in the possible > case of events "reoccurring" on a non-existent time; Events with a large > reoccurrence set - for a simple example an entry on a calendar intended to > define my "work days" for the year - could be entered easily as an event > that reoccurs from 9-5pm Mon-Fri having a set of exceptions mapped to my > client's holidays - even bound to one year - this event could have a simple > RRULE w/10 Exceptions - or if enumerated will over 200+ dates in a list - > probably increasing the size considerably. If you are going to be connecting to the CS regularly with the same CUA, or even with a cron job, you could do the forever thing client-side. Disk is cheap. With a lot of recurrence things happening, they just get exapnded to static entries anyway, so why not do it all client-side. > Two - on the related concept of removing RRULES to a degree from RFC2445 - I > think this is a GOOD idea - my suggestion would be to define the RRULES in a > SEPARATE standards track - one that is very much tied to RFC2445 (but no > solely defined therein) - this allows the RRULES to be applied in a clean > fashion to other programs requiring Temporal Reoccurrences (such as > Caches) - without adding the scheduling/meeting infrastructure and overhead > of iCalendar. Does "cron" have an RFC? > Furthermore - by increasing the number of applications > utilizing the RRULE syntax - and by involving more applications (like CPL) > that require near-realtime resolution of the RRULEs into a useful form - I > suspect that the development of reference algorithms for efficient and > accuracy expansion (or algorithms for programmatic resolution of questions > of overlap/occurrence - will be sped up and developed more quickly. Well said! From owner-ietf-calendar@mail.imc.org Fri Jul 27 02:08:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25706 for <calsch-archive@odin.ietf.org>; Fri, 27 Jul 2001 02:08:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6R5jAx08959 for ietf-calendar-bks; Thu, 26 Jul 2001 22:45:10 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6R5j9s08955 for <ietf-calendar@imc.org>; Thu, 26 Jul 2001 22:45:09 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: ietf-calendar@imc.org Subject: BYSETPOS: Fresh start MIME-Version: 1.0 X-Mailer: Lotus Notes Build M10_07192001 Beta 3 July 19, 2001 Message-ID: <OFB6DC0861.3AC24216-ON85256A96.001D4803@iris.com> From: Bruce_Kahn@iris.com Date: Fri, 27 Jul 2001 01:44:03 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 07/27/2001 01:48:05 AM, Serialize complete at 07/27/2001 01:48:05 AM Content-Type: multipart/alternative; boundary="=_alternative 001F51D685256A96_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 001F51D685256A96_= Content-Type: text/plain; charset="US-ASCII" Ok, Im totally overwhelmed by the backlog of WG traffic that I filed away so Im going to take a fresh start at this BYSETPOS concept again to see if I can summarize the latest thoughts on it. Here are my takes on how things stand with BYSETPOS based on emails and phone calls. 1: BYSETPOS is only of real use when the data set from the recurrence rule has a variable amount of data (ie: "All the Thursdays in the Month") For ALL other cases the recurrence rule can easily be rewritten to just select those desired data points. So I would agree that some prose in the updated draft could reflect this and possibly even mandate that BYSETPOS is only used for rules that generate variable sets of data. That is to say, in a FREQ=WEEKLY;BYDAY=MO,WE,FR rule that a BYSETPOS=2 on that should just cause the rule to be simplified down to FREQ=WEEKLY;BYDAY=WE. As far as we've seen so far, the only rule that will generate a variable length data set is the FREQ=MONTHLY;BYDAY=[MO,TU,WE,TH,FR,SA,SU] so this should not be that great an impact going forwards. Anyone know of other cases? 2: The concern about ~31M data points is orthogonal to the BYSETPOS issue since all the BYxxx subcomponents on a FREQ=DAILY rule w/o a BYSETPOS can generate that large data set size. As such it is unclear to me (at this late hour at least) why they are considered llinked. 3: iTIP / iCalendar define the use of REQUEST-STATUS properties to back application level statuses like "Grammar too complex", "Unsupported RRULE subcomponent", etc. Why cant this same kind of mechanism be reused in CPL when a rule uses a BYSETPOS or generates a data set too large for O(1) evaluation? 4: Much of the bitter back and forth seems to focus on very extreme cases (ie: "bombing" CS/CPL servers) rather than on the 'normal' usages that the vast majority of installations will deal with on a regular basis. Sure we have to deal with some DOS or other maliscious kinds of activity at various levels of design bug I suspect that these fringe cases have distracted us from the real technical work. So how about we refocus on the items above or if I left any off that we put them on the plate anew and try to get on the same page. I talked w/Tom (Robert) today before dinner and he seemed to think that we were all in basic agreement about how recurrence grammars get expanded. If this is not quite accurate then Im willing to try and restart that again too. Time to get some sleep... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 001F51D685256A96_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Ok, Im totally overwhelmed by the backlog of WG traffic that I filed away so Im going to take a fresh start at this BYSETPOS concept again to see if I can summarize the latest thoughts on it. &nbsp;Here are my takes on how things stand with BYSETPOS based on emails and phone calls.</font> <br> <br><font size=2 face="sans-serif">1: BYSETPOS is only of real use when the data set from the recurrence rule has a variable amount of data (ie: &quot;All the Thursdays in the Month&quot;) &nbsp;For ALL other cases the recurrence rule can easily be rewritten to just select those desired data points. &nbsp;So I would agree that some prose in the updated draft could reflect this and possibly even mandate that BYSETPOS is only used for rules that generate variable sets of data. &nbsp;That is to say, in a FREQ=WEEKLY;BYDAY=MO,WE,FR rule that a BYSETPOS=2 on that should just cause the rule to be simplified down to FREQ=WEEKLY;BYDAY=WE. &nbsp;</font> <br> <br><font size=2 face="sans-serif">&nbsp; As far as we've seen so far, the only rule that will generate a variable length data set is the FREQ=MONTHLY;BYDAY=[MO,TU,WE,TH,FR,SA,SU] so this should not be that great an impact going forwards. &nbsp;Anyone know of other cases?</font> <br> <br><font size=2 face="sans-serif">2: The concern about ~31M data points is orthogonal to the BYSETPOS issue since all the BYxxx subcomponents on a FREQ=DAILY rule w/o a BYSETPOS can generate that large data set size. &nbsp;As such it is unclear to me (at this late hour at least) why they are considered llinked.</font> <br> <br><font size=2 face="sans-serif">3: iTIP / iCalendar define the use of REQUEST-STATUS properties to back application level statuses like &quot;Grammar too complex&quot;, &quot;Unsupported RRULE subcomponent&quot;, etc. &nbsp;Why cant this same kind of mechanism be reused in CPL when a rule uses a BYSETPOS or generates a data set too large for O(1) evaluation?</font> <br> <br><font size=2 face="sans-serif">4: Much of the bitter back and forth seems to focus on very extreme cases (ie: &quot;bombing&quot; CS/CPL servers) rather than on the 'normal' usages that the vast majority of installations will deal with on a regular basis. &nbsp;Sure we have to deal with some DOS or other maliscious kinds of activity at various levels of design bug I suspect that these fringe cases have distracted us from the real technical work. &nbsp;</font> <br><font size=2 face="sans-serif">&nbsp; So how about we refocus on the items above or if I left any off that we put them on the plate anew and try to get on the same page. I talked w/Tom (Robert) today before dinner and he seemed to think that we were all in basic agreement about how recurrence grammars get expanded. &nbsp;If this is not quite accurate then Im willing to try and restart that again too.</font> <br> <br><font size=2 face="sans-serif">Time to get some sleep...</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> --=_alternative 001F51D685256A96_=-- From owner-ietf-calendar@mail.imc.org Fri Jul 27 12:50:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06115 for <calsch-archive@odin.ietf.org>; Fri, 27 Jul 2001 12:50:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RGVsP25625 for ietf-calendar-bks; Fri, 27 Jul 2001 09:31:54 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RGVps25621 for <ietf-calendar@imc.org>; Fri, 27 Jul 2001 09:31:52 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA02299; Fri, 27 Jul 2001 11:29:21 -0500 From: "Shannon J. Clark" <shannon@jigzaw.com> To: <Bruce_Kahn@iris.com>, "Jonathan Lennox" <lennox@cs.columbia.edu> Cc: <ietf-calendar@imc.org> Subject: RE: BYSETPOS: Fresh start Date: Fri, 27 Jul 2001 11:31:12 -0500 Message-ID: <NEBBKFJICLIPPJJJBCFCOEFLCPAA.shannon@jigzaw.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C1168F.A3ADDF20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <OFB6DC0861.3AC24216-ON85256A96.001D4803@iris.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C1168F.A3ADDF20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Re point 1 - it is a rare case - but in theory a BYHOUR rule could generate a variable number of hours twice a year (i.e. the two days a year for locations with Daylight Savings that do not have 24 hours) Even more obscurely, BYSECONDS could for the moments of leap seconds (but this is unlikely to managed by most systems in any case) Also a BYMONTHDAY or a BYYEARDAY could generate a variable number of values for a FREQ:YEAR due to leap years (i.e. some years have more instances of MONTHDAY=29, or YEARDAY=366. Though rules with this would be rather silly. Also a slightly complex case, but one that the standard is designed to allow: if you vary the WKST setting - then rules with weekly rules or a BYWEEKNO are applied could have variable results for a given FREQ of either MONTHLY or YEARLY. (to quote the standard on what WKST does) The WKST rule part specifies the day on which the workweek starts. Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule part is specified. This is also significant when in a YEARLY RRULE when a BYWEEKNO rule part is specified. The default value is MO. Hope this helps bring to light some other cases with variable result sets. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Bruce_Kahn@iris.com Sent: Friday, July 27, 2001 12:44 AM To: Jonathan Lennox Cc: ietf-calendar@imc.org Subject: BYSETPOS: Fresh start Ok, Im totally overwhelmed by the backlog of WG traffic that I filed away so Im going to take a fresh start at this BYSETPOS concept again to see if I can summarize the latest thoughts on it. Here are my takes on how things stand with BYSETPOS based on emails and phone calls. 1: BYSETPOS is only of real use when the data set from the recurrence rule has a variable amount of data (ie: "All the Thursdays in the Month") For ALL other cases the recurrence rule can easily be rewritten to just select those desired data points. So I would agree that some prose in the updated draft could reflect this and possibly even mandate that BYSETPOS is only used for rules that generate variable sets of data. That is to say, in a FREQ=WEEKLY;BYDAY=MO,WE,FR rule that a BYSETPOS=2 on that should just cause the rule to be simplified down to FREQ=WEEKLY;BYDAY=WE. As far as we've seen so far, the only rule that will generate a variable length data set is the FREQ=MONTHLY;BYDAY=[MO,TU,WE,TH,FR,SA,SU] so this should not be that great an impact going forwards. Anyone know of other cases? 2: The concern about ~31M data points is orthogonal to the BYSETPOS issue since all the BYxxx subcomponents on a FREQ=DAILY rule w/o a BYSETPOS can generate that large data set size. As such it is unclear to me (at this late hour at least) why they are considered llinked. 3: iTIP / iCalendar define the use of REQUEST-STATUS properties to back application level statuses like "Grammar too complex", "Unsupported RRULE subcomponent", etc. Why cant this same kind of mechanism be reused in CPL when a rule uses a BYSETPOS or generates a data set too large for O(1) evaluation? 4: Much of the bitter back and forth seems to focus on very extreme cases (ie: "bombing" CS/CPL servers) rather than on the 'normal' usages that the vast majority of installations will deal with on a regular basis. Sure we have to deal with some DOS or other maliscious kinds of activity at various levels of design bug I suspect that these fringe cases have distracted us from the real technical work. So how about we refocus on the items above or if I left any off that we put them on the plate anew and try to get on the same page. I talked w/Tom (Robert) today before dinner and he seemed to think that we were all in basic agreement about how recurrence grammars get expanded. If this is not quite accurate then Im willing to try and restart that again too. Time to get some sleep... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... ------=_NextPart_000_0006_01C1168F.A3ADDF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.3314.2100" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D600551816-27072001>Re = point 1 - it is a=20 rare case - but in theory a BYHOUR rule could generate a variable number = of=20 hours twice a year (i.e. the two days&nbsp;a year for locations with = Daylight=20 Savings that do not have 24 hours) Even more obscurely, BYSECONDS could = for the=20 moments of leap seconds (but this is unlikely to managed by most systems = in any=20 case)</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D600551816-27072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D600551816-27072001>Also a = BYMONTHDAY=20 or&nbsp;a BYYEARDAY could generate a variable number of values for a = FREQ:YEAR=20 due to leap years (i.e. some years have more instances of MONTHDAY=3D29, = or=20 YEARDAY=3D366. Though rules with this would be rather = silly.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D600551816-27072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D600551816-27072001>Also a = slightly=20 complex case, but one that the standard is designed to allow: if you = vary the=20 WKST setting - then rules with weekly rules or a BYWEEKNO are applied = could have=20 variable results for a given FREQ of either MONTHLY or=20 YEARLY.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D600551816-27072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D600551816-27072001>(to = quote the=20 standard on what WKST does)</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D600551816-27072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D600551816-27072001>&nbsp;&nbsp;&nbsp;=20 The WKST rule part specifies the day on which the workweek=20 starts.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Valid values are MO, TU, = WE, TH,=20 FR, SA and SU. This is = significant<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; when=20 a WEEKLY RRULE has an interval greater than 1, and a BYDAY=20 rule<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; part is specified. This is = also=20 significant when in a YEARLY = RRULE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; when=20 a BYWEEKNO rule part is specified. The default value is MO. = </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D600551816-27072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D600551816-27072001>Hope = this helps=20 bring to light some other cases with variable result = sets.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D600551816-27072001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D600551816-27072001>Shannon</SPAN></FONT></DIV> <DIV>&nbsp;</DIV> <BLOCKQUOTE> <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B>=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]<B>On Behalf Of=20 </B>Bruce_Kahn@iris.com<BR><B>Sent:</B> Friday, July 27, 2001 12:44=20 AM<BR><B>To:</B> Jonathan Lennox<BR><B>Cc:</B>=20 ietf-calendar@imc.org<BR><B>Subject:</B> BYSETPOS: Fresh=20 start<BR><BR></DIV></FONT><BR><FONT face=3Dsans-serif size=3D2>Ok, Im = totally=20 overwhelmed by the backlog of WG traffic that I filed away so Im going = to take=20 a fresh start at this BYSETPOS concept again to see if I can summarize = the=20 latest thoughts on it. &nbsp;Here are my takes on how things stand = with=20 BYSETPOS based on emails and phone calls.</FONT> <BR><BR><FONT = face=3Dsans-serif=20 size=3D2>1: BYSETPOS is only of real use when the data set from the = recurrence=20 rule has a variable amount of data (ie: "All the Thursdays in the = Month")=20 &nbsp;For ALL other cases the recurrence rule can easily be rewritten = to just=20 select those desired data points. &nbsp;So I would agree that some = prose in=20 the updated draft could reflect this and possibly even mandate that = BYSETPOS=20 is only used for rules that generate variable sets of data. &nbsp;That = is to=20 say, in a FREQ=3DWEEKLY;BYDAY=3DMO,WE,FR rule that a BYSETPOS=3D2 on = that should=20 just cause the rule to be simplified down to FREQ=3DWEEKLY;BYDAY=3DWE. = &nbsp;</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>&nbsp; As far = as we've seen=20 so far, the only rule that will generate a variable length data set is = the=20 FREQ=3DMONTHLY;BYDAY=3D[MO,TU,WE,TH,FR,SA,SU] so this should not be = that great an=20 impact going forwards. &nbsp;Anyone know of other cases?</FONT> = <BR><BR><FONT=20 face=3Dsans-serif size=3D2>2: The concern about ~31M data points is = orthogonal to=20 the BYSETPOS issue since all the BYxxx subcomponents on a FREQ=3DDAILY = rule w/o=20 a BYSETPOS can generate that large data set size. &nbsp;As such it is = unclear=20 to me (at this late hour at least) why they are considered = llinked.</FONT>=20 <BR><BR><FONT face=3Dsans-serif size=3D2>3: iTIP / iCalendar define = the use of=20 REQUEST-STATUS properties to back application level statuses like = "Grammar too=20 complex", "Unsupported RRULE subcomponent", etc. &nbsp;Why cant this = same kind=20 of mechanism be reused in CPL when a rule uses a BYSETPOS or generates = a data=20 set too large for O(1) evaluation?</FONT> <BR><BR><FONT = face=3Dsans-serif=20 size=3D2>4: Much of the bitter back and forth seems to focus on very = extreme=20 cases (ie: "bombing" CS/CPL servers) rather than on the 'normal' = usages that=20 the vast majority of installations will deal with on a regular basis.=20 &nbsp;Sure we have to deal with some DOS or other maliscious kinds of = activity=20 at various levels of design bug I suspect that these fringe cases have = distracted us from the real technical work. &nbsp;</FONT> <BR><FONT=20 face=3Dsans-serif size=3D2>&nbsp; So how about we refocus on the items = above or if=20 I left any off that we put them on the plate anew and try to get on = the same=20 page. I talked w/Tom (Robert) today before dinner and he seemed to = think that=20 we were all in basic agreement about how recurrence grammars get = expanded.=20 &nbsp;If this is not quite accurate then Im willing to try and restart = that=20 again too.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>Time to get = some=20 sleep...</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>Bruce</FONT> = <BR><FONT=20 face=3Dsans-serif=20 = size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D<BR>Bruce=20 Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = &nbsp;=20 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: = Bruce_Kahn@iris.com<BR>Iris=20 Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = &nbsp;=20 &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<BR>Westford, MA, USA = 01886=20 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = &nbsp;FAX: and=20 nothing but the FAX...<BR>Standard disclaimers apply, even where = prohibited by=20 law...</FONT></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0006_01C1168F.A3ADDF20-- From owner-ietf-calendar@mail.imc.org Fri Jul 27 13:21:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09564 for <calsch-archive@odin.ietf.org>; Fri, 27 Jul 2001 13:21:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RH0aw26230 for ietf-calendar-bks; Fri, 27 Jul 2001 10:00:36 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RH0Ys26226 for <ietf-calendar@imc.org>; Fri, 27 Jul 2001 10:00:34 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA02308; Fri, 27 Jul 2001 11:45:00 -0500 From: "Shannon J. Clark" <shannon@jigzaw.com> To: "David L. Nicol" <david@kasey.umkc.edu> Cc: <ietf-calendar@imc.org> Subject: RE: Additional RECAP and status of CPL RECUR Issues. Date: Fri, 27 Jul 2001 11:46:52 -0500 Message-ID: <NEBBKFJICLIPPJJJBCFCIEFMCPAA.shannon@jigzaw.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3B60B045.61858315@kasey.umkc.edu> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Well a few points about doing it all client-side OR via an outside scheduler (like cron). 1. - this does not resolve how my SERVER should handle incoming events in the future - i.e. say I expand a "forever" event for the next 100 instances (or any other arbitrary number) - if my FREEBUSY status is queried (which is a feature CS can and should - but not must - support) for a time past that arbitrary number then my server will return incorrect information. Admittedly this probably is far in the future - and may get corrected after my rule is expanded - but it changes the order of things in a strange (and probably confusing to an end user) manner. 2. - many CUA's will NOT have access to tools like cron - sure unix clients have cron access easily - but such tools are confusing even for sophisticated users - and do not help CUA cases for mobile devices, notebooks, etc. Furthermore - if the client application is responsible for expanding events - and then entering them into a calendar store - there still is a requirement for a method of DEFINING how to expand events - the purpose of a set of RRULES is to define a set of ALGORITHMS that can generate a set of future events - thus avoiding the requirement that a HUMAN "figure it out" Even simple cases if required to be entered by hand are cumbersome (imagine hand entering the future birthdays of all of the people in your address book - at some point you will make a typo and drop someone's birthday for a given year...) Now imagine a case of something that repeats every 25 hours - even given a small set of reoccurrences this would be obnoxious to generate by hand - and requires some form of algorithm to define. My point is that shifting from RRULES on the server - to RRULES on the client feels like a step backwards. Yes Disk space is "cheap" - BUT this is not true in all use cases - DISKs can be cheap on a server (but imagine a server designed to handle 1,000,000+ people) but in cases like mobile phones, PDAs etc storage can be a severely limiting factor. Finally not all systems expand recurrences to static entries - indeed came to this discussion because CPL and other systems were not planning on doing that - and there are many cases where it doesn't make much sense. (note on above, in the systems my company is designing we are indeed looking carefully at this issue - but still plan on having server side knowledge of the RRULES - even if we do some expansion of them in advance and cache it for performance) Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of David L. Nicol Sent: Thursday, July 26, 2001 7:05 PM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: Re: Additional RECAP and status of CPL RECUR Issues. -- "Shannon J. Clark" wrote: > One - the concept of a "simple" list of the other occurrences of an event - > while seemingly simple - gets really really ugly fast if you have to deal > with any of the following - events that recur "forever" (the Monday morning > conference call); events that are LOCAL and REOCCURRING - thus the "time" of > each reoccurrence might be dependant on a user's timezone settings (and > further complicated by Daylight savings shifts that result in the possible > case of events "reoccurring" on a non-existent time; Events with a large > reoccurrence set - for a simple example an entry on a calendar intended to > define my "work days" for the year - could be entered easily as an event > that reoccurs from 9-5pm Mon-Fri having a set of exceptions mapped to my > client's holidays - even bound to one year - this event could have a simple > RRULE w/10 Exceptions - or if enumerated will over 200+ dates in a list - > probably increasing the size considerably. If you are going to be connecting to the CS regularly with the same CUA, or even with a cron job, you could do the forever thing client-side. Disk is cheap. With a lot of recurrence things happening, they just get exapnded to static entries anyway, so why not do it all client-side. > Two - on the related concept of removing RRULES to a degree from RFC2445 - I > think this is a GOOD idea - my suggestion would be to define the RRULES in a > SEPARATE standards track - one that is very much tied to RFC2445 (but no > solely defined therein) - this allows the RRULES to be applied in a clean > fashion to other programs requiring Temporal Reoccurrences (such as > Caches) - without adding the scheduling/meeting infrastructure and overhead > of iCalendar. Does "cron" have an RFC? > Furthermore - by increasing the number of applications > utilizing the RRULE syntax - and by involving more applications (like CPL) > that require near-realtime resolution of the RRULEs into a useful form - I > suspect that the development of reference algorithms for efficient and > accuracy expansion (or algorithms for programmatic resolution of questions > of overlap/occurrence - will be sped up and developed more quickly. Well said! From owner-ietf-calendar@mail.imc.org Fri Jul 27 14:33:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17426 for <calsch-archive@odin.ietf.org>; Fri, 27 Jul 2001 14:33:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RI53q27761 for ietf-calendar-bks; Fri, 27 Jul 2001 11:05:03 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6RI52s27757 for <ietf-calendar@imc.org>; Fri, 27 Jul 2001 11:05:02 -0700 (PDT) Received: (qmail 509943 invoked from network); 27 Jul 2001 18:00:55 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 27 Jul 2001 18:00:55 -0000 Message-ID: <3B61AB44.42CC2B76@kasey.umkc.edu> Date: Fri, 27 Jul 2001 12:56:20 -0500 From: "David L. Nicol" <david@kasey.umkc.edu> Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" <shannon@jigzaw.com>, CalSched IETF <ietf-calendar@imc.org> Subject: Re: Additional RECAP and status of CPL RECUR Issues. References: <NEBBKFJICLIPPJJJBCFCIEFMCPAA.shannon@jigzaw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Well a few points about doing it all client-side OR via an outside scheduler > (like cron). > > 1. - this does not resolve how my SERVER should handle incoming events in > the future - i.e. say I expand a "forever" event for the next 100 instances > (or any other arbitrary number) - if my FREEBUSY status is queried (which is > a feature CS can and should - but not must - support) for a time past that > arbitrary number then my server will return incorrect information. > Admittedly this probably is far in the future - and may get corrected after > my rule is expanded - but it changes the order of things in a strange (and > probably confusing to an end user) manner. If your server supports this extended functionality, that's a good server! > 2. - many CUA's will NOT have access to tools like cron - sure unix clients > have cron access easily - but such tools are confusing even for > sophisticated users - and do not help CUA cases for mobile devices, > notebooks, etc. Tools like cron are very simple to write. My wristwatch has a tool like cron: I can program it to beep at a specified time in the future. > Furthermore - if the client application is responsible for > expanding events - and then entering them into a calendar store - there > still is a requirement for a method of DEFINING how to expand events - the > purpose of a set of RRULES is to define a set of ALGORITHMS that can > generate a set of future events - thus avoiding the requirement that a HUMAN > "figure it out" The problem is interoperabioty, and complete specification of corner cases. By delegating solving that problem explicitly outside the scope of the standard, the interoperability problem goes away. Recurring language is reclassified to MAY status, and a way to specify which dialect you are speaking is provided. The world might wind up with only one dialect, but it might wind up with many: by delegating the detail the standard can support any possibility. > Even simple cases if required to be entered by hand > [...] shifting from RRULES on the server - to RRULES on the > client feels like a step backwards. Shifting functionality from the server to the client does not mean entering by hand. The client will still be a complex piece of software. Allowing variety in the client means more rocust competition, to argue from a free-market perspective. > (note on above, in the systems my company is designing we are indeed looking > carefully at this issue - but still plan on having server side knowledge of > the RRULES - even if we do some expansion of them in advance and cache it > for performance) > > Shannon I'll stand by what I recall my reccomendation here was, which, with very slight improvement, was: CS MUST accept multiple dates/times/locations for same event CS MUST list what RRULES languages it knows in its CAPABILITY responses CS SHOULD accept a minimal standard RRULES language which is fully defined CS MAY accept an extended RRULES language, which the definition of which is beyond the scope of this document. From owner-ietf-calendar@mail.imc.org Sat Jul 28 20:49:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13709 for <calsch-archive@odin.ietf.org>; Sat, 28 Jul 2001 20:49:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6SM7K325918 for ietf-calendar-bks; Sat, 28 Jul 2001 15:07:20 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6SM7Js25914 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 15:07:19 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6SM7Fv18831 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 15:07:15 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GH7ERF00.2FA; Sat, 28 Jul 2001 15:07:14 -0700 Message-ID: <3B633730.4020100@netscape.com> Date: Sat, 28 Jul 2001 15:05:36 -0700 From: sman@netscape.com (Steve Mansour) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010713 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Mansour <sman@netscape.com> CC: Martijn van Beers <martijn@eekeek.org>, CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <20010728204435.B31282@khazad-dum.copa.nl> <3B63191F.80500@netscape.com> Content-Type: multipart/alternative; boundary="------------070501020806010407010506" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> --------------070501020806010407010506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit correction below... Steve Mansour wrote: > Martijn van Beers wrote: > >>On Sat, Jul 28, 2001 at 10:32:22AM -0700, Steve Mansour wrote: >> >>>Martijn van Beers wrote: >>> >>>... >>> BEGIN:VCOMMAND >>> METHOD:CREATE >>> >>... but to continue nit-picking, doesn't the CREATE here mean it's >>a calendaring command instead of a scheduling command? >> > yep > >>> TARGET:cap://a.b.com/sman >>> TARGET:mailto:bill@example.com >>> BEGIN:VEVENT >>> ... >>> ORGANIZER:cap://a.b.com/sman >>> ATTENDEE;<bla bla bla>:cap://a.b.com/sman >>> ATTENDEE;<bla bla bla>:mailto:bill@example.com >>> ... >>> >>>The intent of the the fanout capability in CAP is that when the target >>>mailto:bill@example.com is processed, the CREATE method is automagically transformed into an iTIP REQUEST method and that the VEVENT information is transformed as needed to become a valid iTIP message. >>> >> >>That sounds strange to me. CREATE is a command to put a component in >>a calendar, while REQUEST is like asking if you're available, right? >>How come they are considered to be interchangable then when the >>message uses several transports? >> > Is everyone concerned yet? REQUEST is the closest thing to in iTIP > to CREATE in CAP. That's what I was saying in my earlier message. The > mapping is probably not going to work out in all cases. That's why I'm > scared of this. I do not consider the commands to be interchangable > between passports. and, of course, by "passports" I mean "transports". -Steve --------------070501020806010407010506 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <html> <head> </head> <body> correction below...<br> <br> Steve Mansour wrote:<br> <blockquote type="cite" cite="mid:3B63191F.80500@netscape.com">Martijn van Beers wrote:<br> <blockquote type="cite" cite="mid:20010728204435.B31282@khazad-dum.copa.nl"> <pre wrap="">On Sat, Jul 28, 2001 at 10:32:22AM -0700, Steve Mansour wrote:<br></pre> <blockquote type="cite"> <pre wrap="">Martijn van Beers wrote:<br></pre> </blockquote> <blockquote type="cite"> <pre wrap="">...<br> BEGIN:VCOMMAND<br> METHOD:CREATE<br></pre> </blockquote> <pre wrap=""><!---->... but to continue nit-picking, doesn't the CREATE here mean it's<br>a calendaring command instead of a scheduling command?</pre> </blockquote> yep<br> <blockquote type="cite" cite="mid:20010728204435.B31282@khazad-dum.copa.nl"> <blockquote type="cite"> <pre wrap=""> TARGET:cap://a.b.com/sman<br> TARGET:<a class="moz-txt-link-freetext" href="mailto:bill@example.com">mailto:bill@example.com</a><br> BEGIN:VEVENT<br> ...<br> ORGANIZER:cap://a.b.com/sman<br> ATTENDEE;&lt;bla bla bla&gt;:cap://a.b.com/sman<br> ATTENDEE;&lt;bla bla bla&gt;:<a class="moz-txt-link-freetext" href="mailto:bill@example.com">mailto:bill@example.com</a><br> ...<br><br>The intent of the the fanout capability in CAP is that when the target<br><a class="moz-txt-link-freetext" href="mailto:bill@example.com">mailto:bill@example.com</a> is processed, the CREATE method is automagically transformed into an iTIP REQUEST method and that the VEVENT information is transformed as needed to become a valid iTIP message.<br></pre> </blockquote> <pre wrap=""><!----><br>That sounds strange to me. CREATE is a command to put a component in<br>a calendar, while REQUEST is like asking if you're available, right?<br>How come they are considered to be interchangable then when the<br>message uses several transports?<br></pre> </blockquote> Is everyone concerned yet? &nbsp; REQUEST is the closest thing to in iTIP to CREATE in CAP. &nbsp;That's what I was saying in my earlier message. The mapping is probably not going to work out in all cases. That's why I'm scared of this. I do not consider the commands to be interchangable between passports.<br> </blockquote> and, of course, by "passports" I mean "transports".<br> -Steve<br> <br> </body> </html> --------------070501020806010407010506-- From owner-ietf-calendar@mail.imc.org Sat Jul 28 20:49:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13721 for <calsch-archive@odin.ietf.org>; Sat, 28 Jul 2001 20:49:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6SJwrM24558 for ietf-calendar-bks; Sat, 28 Jul 2001 12:58:53 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6SJwps24554 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 12:58:51 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6SJwlv19598 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 12:58:47 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GH78TK00.PAQ; Sat, 28 Jul 2001 12:58:46 -0700 Message-ID: <3B63191F.80500@netscape.com> Date: Sat, 28 Jul 2001 12:57:19 -0700 From: sman@netscape.com (Steve Mansour) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010713 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: Martijn van Beers <martijn@eekeek.org> CC: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <20010728204435.B31282@khazad-dum.copa.nl> Content-Type: multipart/alternative; boundary="------------000004030708090205020900" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> --------------000004030708090205020900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Martijn van Beers wrote: >On Sat, Jul 28, 2001 at 10:32:22AM -0700, Steve Mansour wrote: > >>Martijn van Beers wrote: >> >>... >> BEGIN:VCOMMAND >> METHOD:CREATE >> >... but to continue nit-picking, doesn't the CREATE here mean it's >a calendaring command instead of a scheduling command? > yep >> TARGET:cap://a.b.com/sman >> TARGET:mailto:bill@example.com >> BEGIN:VEVENT >> ... >> ORGANIZER:cap://a.b.com/sman >> ATTENDEE;<bla bla bla>:cap://a.b.com/sman >> ATTENDEE;<bla bla bla>:mailto:bill@example.com >> ... >> >>The intent of the the fanout capability in CAP is that when the target >>mailto:bill@example.com is processed, the CREATE method is automagically transformed into an iTIP REQUEST method and that the VEVENT information is transformed as needed to become a valid iTIP message. >> > >That sounds strange to me. CREATE is a command to put a component in >a calendar, while REQUEST is like asking if you're available, right? >How come they are considered to be interchangable then when the >message uses several transports? > Is everyone concerned yet? REQUEST is the closest thing to in iTIP to CREATE in CAP. That's what I was saying in my earlier message. The mapping is probably not going to work out in all cases. That's why I'm scared of this. I do not consider the commands to be interchangable between passports. -Steve --------------000004030708090205020900 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <html> <head> </head> <body> <br> Martijn van Beers wrote:<br> <blockquote type="cite" cite="mid:20010728204435.B31282@khazad-dum.copa.nl"> <pre wrap="">On Sat, Jul 28, 2001 at 10:32:22AM -0700, Steve Mansour wrote:<br></pre> <blockquote type="cite"> <pre wrap="">Martijn van Beers wrote:<br></pre> </blockquote> <blockquote type="cite"> <pre wrap="">...<br> BEGIN:VCOMMAND<br> METHOD:CREATE<br></pre> </blockquote> <pre wrap=""><!---->... but to continue nit-picking, doesn't the CREATE here mean it's<br>a calendaring command instead of a scheduling command?</pre> </blockquote> yep<br> <blockquote type="cite" cite="mid:20010728204435.B31282@khazad-dum.copa.nl"> <blockquote type="cite"> <pre wrap=""> TARGET:cap://a.b.com/sman<br> TARGET:<a class="moz-txt-link-freetext" href="mailto:bill@example.com">mailto:bill@example.com</a><br> BEGIN:VEVENT<br> ...<br> ORGANIZER:cap://a.b.com/sman<br> ATTENDEE;&lt;bla bla bla&gt;:cap://a.b.com/sman<br> ATTENDEE;&lt;bla bla bla&gt;:<a class="moz-txt-link-freetext" href="mailto:bill@example.com">mailto:bill@example.com</a><br> ...<br><br>The intent of the the fanout capability in CAP is that when the target<br><a class="moz-txt-link-freetext" href="mailto:bill@example.com">mailto:bill@example.com</a> is processed, the CREATE method is automagically transformed into an iTIP REQUEST method and that the VEVENT information is transformed as needed to become a valid iTIP message.<br></pre> </blockquote> <pre wrap=""><!----><br>That sounds strange to me. CREATE is a command to put a component in<br>a calendar, while REQUEST is like asking if you're available, right?<br>How come they are considered to be interchangable then when the<br>message uses several transports?<br></pre> </blockquote> Is everyone concerned yet? &nbsp; REQUEST is the closest thing to in iTIP to CREATE in CAP. &nbsp;That's what I was saying in my earlier message. The mapping is probably not going to work out in all cases. That's why I'm scared of this. I do not consider the commands to be interchangable between passports.<br> <br> -Steve<br> <br> </body> </html> --------------000004030708090205020900-- From owner-ietf-calendar@mail.imc.org Sat Jul 28 20:49:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13734 for <calsch-archive@odin.ietf.org>; Sat, 28 Jul 2001 20:49:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6SIfb223772 for ietf-calendar-bks; Sat, 28 Jul 2001 11:41:37 -0700 (PDT) Received: from amsmta05-svc.chello.nl (mail-out.chello.nl [213.46.240.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6SIfas23768 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 11:41:36 -0700 (PDT) Received: from khazad-dum.copa.nl ([212.187.86.233]) by amsmta05-svc.chello.nl (InterMail vK.4.03.02.00 201-232-124 license dd4a379df8e387594186908c65258374) with ESMTP id <20010728184150.OARJ15664.amsmta05-svc@khazad-dum.copa.nl>; Sat, 28 Jul 2001 20:41:50 +0200 Received: from martijn by khazad-dum.copa.nl with local (Exim 3.31 #1 (Debian)) id 15QZ4l-00089d-00; Sat, 28 Jul 2001 20:44:35 +0200 Date: Sat, 28 Jul 2001 20:44:35 +0200 From: Martijn van Beers <martijn@eekeek.org> To: Steve Mansour <sman@netscape.com> Cc: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP Message-ID: <20010728204435.B31282@khazad-dum.copa.nl> Mail-Followup-To: Martijn van Beers <martijn@eekeek.org>, Steve Mansour <sman@netscape.com>, CalSched IETF <ietf-calendar@imc.org> References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B62F726.32DA3264@netscape.com> User-Agent: Mutt/1.3.18i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> On Sat, Jul 28, 2001 at 10:32:22AM -0700, Steve Mansour wrote: > Martijn van Beers wrote: > > Hmm, does that mean CAP scheduling messages aren't > > (encapsulated) iTIP messages? > I think the answer is "no, cap scheduling messages are not iTIP messages" > but I'm not sure what you mean by "encapsulated". The issue we're I meant the "SENDDATA\n" and "\n.\n" bits around the actual MIME message > talking about here involves a request that gets sent to a CAP server > that has a mixture of cap addresses and mailto addresses in the > attendee list. For example: Ok, I guess I should have found out what fan-out was before saying anything, since I wasn't really talking in that context. > ... > BEGIN:VCOMMAND > METHOD:CREATE ... but to continue nit-picking, doesn't the CREATE here mean it's a calendaring command instead of a scheduling command? > TARGET:cap://a.b.com/sman > TARGET:mailto:bill@example.com > BEGIN:VEVENT > ... > ORGANIZER:cap://a.b.com/sman > ATTENDEE;<bla bla bla>:cap://a.b.com/sman > ATTENDEE;<bla bla bla>:mailto:bill@example.com > ... > > The intent of the the fanout capability in CAP is that when the target > mailto:bill@example.com is processed, the CREATE method is automagically > transformed into an iTIP REQUEST method and that the VEVENT information is > transformed as needed to become a valid iTIP message. That sounds strange to me. CREATE is a command to put a component in a calendar, while REQUEST is like asking if you're available, right? How come they are considered to be interchangable then when the message uses several transports? Martijn From owner-ietf-calendar@mail.imc.org Sat Jul 28 20:54:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15240 for <calsch-archive@odin.ietf.org>; Sat, 28 Jul 2001 20:54:34 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6SHZQt23060 for ietf-calendar-bks; Sat, 28 Jul 2001 10:35:26 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6SHZOs23056 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 10:35:24 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6SHZKB26390 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 10:35:21 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GH726W00.N4R for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 10:35:20 -0700 Message-ID: <3B62F78F.5030605@netscape.com> Date: Sat, 28 Jul 2001 10:34:07 -0700 From: sman@netscape.com (Steve Mansour) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010713 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF <ietf-calendar@imc.org> Subject: Status of CAP issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Hey All, I want to close up on the issues I posted last week. Here's the quick summary. If anyone disagrees with the resolution, please speak up on the list before the meeting in London. Issue: Fallback/fanout to iTIP (see message Thu, 19 Jul 2001 09:59:21 -0700 ) - specifying how a mapping is made between a cap:// url is changed to a mailto: url when fanning out a meeting request . Resolution: CAP does not specify. Issue: Workflow path may not be true path (see message Thu, 19 Jul 2001 10:16:40 -0700) Resolution: CAP does not specify. Left up to implementations Issue: CS does not preserve data integrity on multipart/signed (see message Thu, 19 Jul 2001 10:31:29 -0700) Resolution: CAP does not address this problem Issue: JIT signing/encryption (see message Thu, 19 Jul 2001 10:38:06 -0700) Resolution: CAP does not address this problem Issue: Decreed VCARs (see message Thu, 19 Jul 2001 17:08:58 -0700) Resolution: Drop them. -Steve From owner-ietf-calendar@mail.imc.org Sat Jul 28 20:54:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15250 for <calsch-archive@odin.ietf.org>; Sat, 28 Jul 2001 20:54:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6SHXgW23047 for ietf-calendar-bks; Sat, 28 Jul 2001 10:33:42 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6SHXfs23041 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 10:33:41 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6SHXav19498 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 10:33:36 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GH723Z00.H1H; Sat, 28 Jul 2001 10:33:35 -0700 Message-ID: <3B62F726.32DA3264@netscape.com> Date: Sat, 28 Jul 2001 10:32:22 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Martijn van Beers <martijn@eekeek.org> CC: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> Content-Type: multipart/mixed; boundary="------------28F9DD4AE3AD00D0008460A4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. --------------28F9DD4AE3AD00D0008460A4 Content-Type: multipart/alternative; boundary="------------C61FC3CE1D408ED6C2E57D42" --------------C61FC3CE1D408ED6C2E57D42 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry for the delayed response on this. The day gig gets in the way sometimes. Martijn van Beers wrote: > On Thu, Jul 19, 2001 at 04:57:15PM -0700, Steve Mansour wrote: > > Martijn van Beers wrote: > > > > If a CAP request must get turned into iTIP then some extra coding must > occur > > > > Shouldn't that be iMIP, not iTIP, or am I misunderstanding all of this > completely? > > yes. Sometimes we use those two interchangeably. It should be something like > > a CAP request gets translated into an iTIP equivalent and sent via iMIP. But > > I think you get the idea. > > Hmm, does that mean CAP scheduling messages aren't > (encapsulated) iTIP messages? I think the answer is "no, cap scheduling messages are not iTIP messages" but I'm not sure what you mean by "encapsulated". The issue we're talking about here involves a request that gets sent to a CAP server that has a mixture of cap addresses and mailto addresses in the attendee list. For example: ... BEGIN:VCOMMAND METHOD:CREATE TARGET:cap://a.b.com/sman TARGET:mailto:bill@example.com BEGIN:VEVENT ... ORGANIZER:cap://a.b.com/sman ATTENDEE;<bla bla bla>:cap://a.b.com/sman ATTENDEE;<bla bla bla>:mailto:bill@example.com ... The intent of the the fanout capability in CAP is that when the target mailto:bill@example.com is processed, the CREATE method is automagically transformed into an iTIP REQUEST method and that the VEVENT information is transformed as needed to become a valid iTIP message. [ed note: if this sort of transformation doesn't make you nervous, it should. iTIP methods are not as rich as CAP's and I see big potential for the wrong thing to happen. I'd be happy if we got rid of the notion of fanout altogether, but I'll go with the masses on this] Anyway, back to the problem. In order to send this component in an iTIP/iMIP message, we have to transform all the calids into something iMIP-compatible. That would be "mailto:" addresses. Now, how do you guarantee a transformation between cap://a.b.com/sman and the appropriate "mailto:" address? Without this transformation, you can't produce a valid iMIP message. Maybe someone has an inspired idea to deal with this, but the recommendation is to leave this as an exercise for the implementation. -Steve --------------C61FC3CE1D408ED6C2E57D42 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Sorry for the delayed response on this.&nbsp; The day gig gets in the way sometimes. <p>Martijn van Beers wrote: <blockquote TYPE=CITE>On Thu, Jul 19, 2001 at 04:57:15PM -0700, Steve Mansour wrote: <br>> Martijn van Beers wrote: <br>> > >&nbsp;&nbsp; If a CAP request must get turned into iTIP then some extra coding must occur <br>> > > Shouldn't that be iMIP, not iTIP, or am I misunderstanding all of this completely? <br>> yes. Sometimes we use those two interchangeably.&nbsp; It should be something like <br>> a CAP request gets translated into an iTIP equivalent and sent via iMIP.&nbsp; But <br>> I think you get the idea. <p>Hmm, does that mean CAP scheduling messages aren't <br>(encapsulated) iTIP messages?</blockquote> I think the answer is "no, cap scheduling messages are not iTIP messages" but I'm not sure what you mean by "encapsulated".&nbsp; The issue we're talking about here involves a request that gets sent to a CAP server that has a mixture of cap addresses and mailto addresses in the attendee list.&nbsp; For example: <blockquote>... <br>BEGIN:VCOMMAND <br>METHOD:CREATE <br>TARGET:cap://a.b.com/sman <br>TARGET:<A HREF="mailto:bill@example.com">mailto:bill@example.com</A> <br>&nbsp;BEGIN:VEVENT <br>&nbsp;... <br>ORGANIZER:cap://a.b.com/sman <br>ATTENDEE;&lt;bla bla bla>:cap://a.b.com/sman <br>ATTENDEE;&lt;bla bla bla>:<A HREF="mailto:bill@example.com">mailto:bill@example.com</A> <br>...</blockquote> The intent of the the fanout capability in CAP is that when the target <A HREF="mailto:bill@example.com">mailto:bill@example.com</A> is processed, the CREATE method is automagically transformed into an iTIP REQUEST method and that the VEVENT information is transformed as needed to become a valid iTIP message. <blockquote>[ed note: if this sort of transformation doesn't make you nervous, it should. iTIP methods are not as rich as CAP's and I see big potential for the wrong thing to happen.&nbsp; I'd be happy if we got rid of the notion of fanout altogether, but I'll go with the masses on this]</blockquote> Anyway, back to the problem.&nbsp; In order to send this component in an iTIP/iMIP message, we have to transform all the calids into something iMIP-compatible. That would be "mailto:" addresses. Now, how do you guarantee a transformation between cap://a.b.com/sman and the appropriate "mailto:" address?&nbsp; Without this transformation, you can't produce a valid iMIP message.&nbsp; Maybe someone has an inspired idea to deal with this, but the recommendation is to leave this as an exercise for the implementation. <p>-Steve</html> --------------C61FC3CE1D408ED6C2E57D42-- --------------28F9DD4AE3AD00D0008460A4 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------28F9DD4AE3AD00D0008460A4-- From owner-ietf-calendar@mail.imc.org Sat Jul 28 20:59:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16095 for <calsch-archive@odin.ietf.org>; Sat, 28 Jul 2001 20:59:40 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6SAHKx09840 for ietf-calendar-bks; Sat, 28 Jul 2001 03:17:20 -0700 (PDT) Received: from public.szptt.net.cn (mail1-smtp.szptt.net.cn [202.96.136.221]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6SAHDs09836 for <ietf-calendar@imc.org>; Sat, 28 Jul 2001 03:17:13 -0700 (PDT) Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm283b62927a; Sat, 28 Jul 2001 10:14:42 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm103b60603f; Thu, 26 Jul 2001 10:14:39 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26039 for ietf-123-outbound.01@ietf.org; Wed, 25 Jul 2001 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25391 for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:31:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07271; Wed, 25 Jul 2001 06:31:33 -0400 (EDT) Message-Id: <200107251031.GAA07271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cap-05.txt Date: Wed, 25 Jul 2001 06:31:33 -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendar Access Protocol (CAP) Author(s) : S. Mansour, D. Royer, G. Babics, P. Hill Filename : draft-ietf-calsch-cap-05.txt Pages : 124 Date : 24-Jul-01 The Calendar Access Protocol (CAP) is an Internet protocol that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). This memo defines the CAP specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-cap-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cap-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132027.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Sat Jul 28 20:59:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16138 for <calsch-archive@odin.ietf.org>; Sat, 28 Jul 2001 20:59:46 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6S5Dg708659 for ietf-calendar-bks; Fri, 27 Jul 2001 22:13:42 -0700 (PDT) Received: from beast.uwillsee.com (h220020.ppp.asahi-net.or.jp [61.114.220.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6S5Dds08655 for <ietf-calendar@imc.org>; Fri, 27 Jul 2001 22:13:39 -0700 (PDT) Received: from tom by beast.uwillsee.com with local (Exim 3.22 #1) id 15QMPF-0005Wr-00; Sat, 28 Jul 2001 14:12:53 +0900 Date: Sat, 28 Jul 2001 14:12:53 +0900 From: "Thomas O'Dowd" <tom@nooper.com> To: ietf-calendar@imc.org Cc: Jonathan Lennox <lennox@cs.columbia.edu>, Bruce_Kahn@iris.com Subject: Re: BYSETPOS: Fresh start Message-ID: <20010728141253.T5321@beast.uwillsee.com> References: <OFB6DC0861.3AC24216-ON85256A96.001D4803@iris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <OFB6DC0861.3AC24216-ON85256A96.001D4803@iris.com>; from Bruce_Kahn@iris.com on Fri, Jul 27, 2001 at 01:44:03AM -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Hi all, I posted a little on this before. I've implemented the RRULE spec as per RFC2445 including BYSETPOS, so having worked on some of the details, I've some of my own opinions... > 1: BYSETPOS is only of real use when the data set from the recurrence rule > has a variable amount of data (ie: "All the Thursdays in the Month") For > ALL other cases the recurrence rule can easily be rewritten to just select > those desired data points. So I would agree that some prose in the > updated draft could reflect this and possibly even mandate that BYSETPOS > is only used for rules that generate variable sets of data. That is to > say, in a FREQ=WEEKLY;BYDAY=MO,WE,FR rule that a BYSETPOS=2 on that should > just cause the rule to be simplified down to FREQ=WEEKLY;BYDAY=WE. RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU -> Event on Wednesday, Friday, Sunday every week. RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU;BYSETPOS=1 -> Event on Wednesday every week. If we add WKST=SU to the rule though this changes. This is another case where WKST affects the outcome of an RRULE. RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU;WKST=SU;BYSETPOS=1 -> Event on Sunday every week. As Bruce said though, this is pretty silly usage of RRULE and it would be hard to see why an interface would generate such a rule anyway. Much simplier would be FREQ=WEEKLY;BYDAY=WE or FREQ=WEEKLY;BYDAY=SU Personally after evaluating most real life cases and what actual users are interested in representing, I believe that BYSETPOS should be simplified and limited to MONTHLY and YEARLY Frequencies (monthly is the most useful in real life). BYSETPOS should also not be used when the following BYxxx rules are used; BYSECOND, BYMINUTE, BYHOUR. I think this solves most problems for most people. I think the other situations are nice to consider but who will implement them and also what calendar system will be able generate them via a GUI without asking the user to enter raw RRULE text? Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com tom@nooper.com - Testing - http://nooper.co.jp/labs From owner-ietf-calendar@mail.imc.org Sun Jul 29 09:18:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19745 for <calsch-archive@odin.ietf.org>; Sun, 29 Jul 2001 09:18:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6TCrLo02640 for ietf-calendar-bks; Sun, 29 Jul 2001 05:53:21 -0700 (PDT) Received: from amsmta06-svc.chello.nl (mail-out.chello.nl [213.46.240.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6TCrJs02636 for <ietf-calendar@imc.org>; Sun, 29 Jul 2001 05:53:19 -0700 (PDT) Received: from khazad-dum.copa.nl ([212.187.86.233]) by amsmta06-svc.chello.nl (InterMail vK.4.03.02.00 201-232-124 license dd4a379df8e387594186908c65258374) with ESMTP id <20010729125325.GXAJ20849.amsmta06-svc@khazad-dum.copa.nl> for <ietf-calendar@imc.org>; Sun, 29 Jul 2001 14:53:25 +0200 Received: from martijn by khazad-dum.copa.nl with local (Exim 3.31 #1 (Debian)) id 15Qq78-0000hc-00 for <ietf-calendar@imc.org>; Sun, 29 Jul 2001 14:56:10 +0200 Date: Sun, 29 Jul 2001 14:56:10 +0200 From: Martijn van Beers <martijn@eekeek.org> To: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP Message-ID: <20010729145610.A2695@khazad-dum.copa.nl> Mail-Followup-To: Martijn van Beers <martijn@eekeek.org>, CalSched IETF <ietf-calendar@imc.org> References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <20010728204435.B31282@khazad-dum.copa.nl> <3B63191F.80500@netscape.com> <3B633730.4020100@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B633730.4020100@netscape.com> User-Agent: Mutt/1.3.18i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> On Sat, Jul 28, 2001 at 03:05:36PM -0700, Steve Mansour wrote: > Steve Mansour wrote: > > Is everyone concerned yet? REQUEST is the closest thing to in iTIP > > to CREATE in CAP. That's what I was saying in my earlier message. The > > mapping is probably not going to work out in all cases. That's why I'm > > scared of this. I do not consider the commands to be interchangable > > between passports. > and, of course, by "passports" I mean "transports". Hrm. All of this implies that CREATE and the other calendaring commands in CAP aren't going back into iTIP (or get their own document). Are they really so tied to CAP? And so far I've only heard Steve's opinion on fan-out. Could anyone who was in favour of it speak up on why it is a good idea? Martijn From owner-ietf-calendar@mail.imc.org Sun Jul 29 13:38:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27676 for <calsch-archive@odin.ietf.org>; Sun, 29 Jul 2001 13:38:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6THBud11620 for ietf-calendar-bks; Sun, 29 Jul 2001 10:11:56 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6THBss11616 for <ietf-calendar@imc.org>; Sun, 29 Jul 2001 10:11:54 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6THBov25980 for <ietf-calendar@imc.org>; Sun, 29 Jul 2001 10:11:50 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GH8VRQ00.TCC; Sun, 29 Jul 2001 10:11:50 -0700 Message-ID: <3B644391.50806@netscape.com> Date: Sun, 29 Jul 2001 10:10:41 -0700 From: sman@netscape.com (Steve Mansour) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010713 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: Martijn van Beers <martijn@eekeek.org> CC: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <20010728204435.B31282@khazad-dum.copa.nl> <3B63191F.80500@netscape.com> <3B633730.4020100@netscape.com> <20010729145610.A2695@khazad-dum.copa.nl> Content-Type: multipart/alternative; boundary="------------070801060406040601000909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> --------------070801060406040601000909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I'm interested in the opinion of others as well. Maybe someone can clear it up for me and make it seem like a workable idea. Still, I have a couple of comments on your question below. -Steve Martijn van Beers wrote: >On Sat, Jul 28, 2001 at 03:05:36PM -0700, Steve Mansour wrote: > >>Steve Mansour wrote: >> >>>Is everyone concerned yet? REQUEST is the closest thing to in iTIP >>>to CREATE in CAP. That's what I was saying in my earlier message. The >>>mapping is probably not going to work out in all cases. That's why I'm >>>scared of this. I do not consider the commands to be interchangable >>>between passports. >>> >>and, of course, by "passports" I mean "transports". >> > >Hrm. All of this implies that CREATE and the other calendaring >commands in CAP aren't going back into iTIP (or get their own >document). Are they really so tied to CAP? > note section 2.8 of the current cap draft. The model for thinking about this is shown in the diagram. Components that have been sent via iMIP are saved in the calstore with their METHOD value set to the iTIP METHOD value. That way, a client can simply query on things like SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' to find all the scheduling requests. So, I think we're OK on finding things. However, the is the concern is the following. We use TARGET to identify the calids. We use the VCOMMAND component to specify the action to apply to the targets. The possibility for problems comes up when the TARGET is a mailto calid (mailto:bill@example.com, which means iMIP to me) and the VCOMMAND has no iTIP equivalent, such as READ. >And so far I've only heard Steve's opinion on fan-out. Could anyone >who was in favour of it speak up on why it is a good idea? > From a pure *functionality* point of view, I think the desired functionality is great. A CUA does not have to concern itself with all the messy details of sending some create requests to a cap server, and some imip requests to individual mail recipients. It doesn't have to worry about the calendar address translations between cap and imip. It can send down one command and have the server take care of all this. So, small devices that want to be CAP clients don't need a lot of fancy code to deal with all this. But this functionality seems to be problematic. -Steve --------------070801060406040601000909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <html> <head> </head> <body> I'm interested in the opinion of others as well. Maybe someone can clear it up for me and make it seem like a workable idea. &nbsp;Still, I have a couple of comments on your question below.<br> -Steve<br> <br> Martijn van Beers wrote:<br> <blockquote type="cite" cite="mid:20010729145610.A2695@khazad-dum.copa.nl"> <pre wrap="">On Sat, Jul 28, 2001 at 03:05:36PM -0700, Steve Mansour wrote:<br></pre> <blockquote type="cite"> <pre wrap="">Steve Mansour wrote:<br></pre> <blockquote type="cite"> <pre wrap="">Is everyone concerned yet? REQUEST is the closest thing to in iTIP <br>to CREATE in CAP. That's what I was saying in my earlier message. The <br>mapping is probably not going to work out in all cases. That's why I'm <br>scared of this. I do not consider the commands to be interchangable <br>between passports.<br></pre> </blockquote> <pre wrap="">and, of course, by "passports" I mean "transports".<br></pre> </blockquote> <pre wrap=""><!----><br>Hrm. All of this implies that CREATE and the other calendaring<br>commands in CAP aren't going back into iTIP (or get their own<br>document). Are they really so tied to CAP?</pre> </blockquote> note section 2.8 of the current cap draft. The model for thinking about this is shown in the diagram. Components that have been sent via iMIP are saved in the calstore with their METHOD value set to the iTIP METHOD value. That way, a client &nbsp;can simply query on things like<br> <blockquote> <pre>SELECT * FROM VEVENT WHERE&nbsp;METHOD = 'REQUEST'<br></pre> </blockquote> to find all the scheduling requests. &nbsp;So, I think we're OK on finding things.<br> <br> However, the is the concern is the following. We use TARGET to identify the calids. We use the VCOMMAND component to specify the action to apply to the targets. The possibility for problems comes up when the TARGET is a mailto calid (<a class="moz-txt-link-freetext" href="mailto:bill@example.com">mailto:bill@example.com</a>, which means iMIP to me) and the VCOMMAND has no iTIP equivalent, such as READ. <br> <blockquote type="cite" cite="mid:20010729145610.A2695@khazad-dum.copa.nl"> <pre wrap="">And so far I've only heard Steve's opinion on fan-out. Could anyone<br>who was in favour of it speak up on why it is a good idea?</pre> </blockquote> From a pure *functionality* point of view, I think the desired functionality is great. A CUA does not have to concern itself with all the messy details of sending some create requests to a cap server, and some imip requests to individual mail recipients. It doesn't have to worry about the calendar address translations between cap and imip. It can send down one command and have the server take care of all this. &nbsp;So, small devices that want to be CAP clients don't need a lot of fancy code to deal with all this. But this functionality seems to be problematic. <br> <br> -Steve<br> <br> </body> </html> --------------070801060406040601000909-- From owner-ietf-calendar@mail.imc.org Mon Jul 30 10:09:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23122 for <calsch-archive@odin.ietf.org>; Mon, 30 Jul 2001 10:09:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6UDnOX28805 for ietf-calendar-bks; Mon, 30 Jul 2001 06:49:24 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UDnNs28801 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 06:49:23 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6UDp4R13255 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 09:51:04 -0400 Message-ID: <3B656648.5080808@ecal.com> Date: Mon, 30 Jul 2001 09:51:04 -0400 From: John Stracke <francis@ecal.com> Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Steve Mansour wrote: > Anyway, back to the problem. In order to send this component in an > iTIP/iMIP message, we have to transform all the calids into something > iMIP-compatible. That would be "mailto:" addresses. I think that's what CRISP was for: so you could use cap: addresses for everything, and iTIP messages could go over CAP instead of email. (This could happen without CRISP; CRISP was just a way to set up a CAP server that just did iTIP, for security reasons.) That doesn't answer the question of how to transform CREATE into REQUEST, though. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |Dave Barry for President! He'll Keep Dan Quayle.| |francis@ecal.com|(OK, it's old) | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Jul 30 10:11:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23221 for <calsch-archive@odin.ietf.org>; Mon, 30 Jul 2001 10:11:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6UDqQF28873 for ietf-calendar-bks; Mon, 30 Jul 2001 06:52:26 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UDqPs28869 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 06:52:25 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA26005; Mon, 30 Jul 2001 09:52:20 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6UDqKv27345; Mon, 30 Jul 2001 09:52:20 -0400 (EDT) Message-ID: <3B656693.5ABB5046@steltor.com> Date: Mon, 30 Jul 2001 09:52:19 -0400 From: George Babics <georgeb@steltor.com> X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <20010728204435.B31282@khazad-dum.copa.nl> <3B63191F.80500@netscape.com> <3B633730.4020100@netscape.com> <20010729145610.A2695@khazad-dum.copa.nl> <3B644391.50806@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit I agree that it can be very useful from a functionality point of view. It will save the CUA much trouble. However, we should go through the exercise of making sure it can work. For instance, as mentioned earlier, can we properly map all the CAP methods to all the iTIP methods? CREATE & MODIFY -> REQUEST MODIFY (as attendee) -> REPLY MOVE entry -> ? MOVE calendar -> ? nothing to do if email address of organizer stays the same? DELETE calendar -> send a CANCEL for each entry in the calendar DELETE entry -> send a CANCEL READ -> ? Some other issues. With CAP how can one send out a COUNTER, or a request for free busy time to a user who only supports iMIP? I'm sure there are many other similar questions. George Steve Mansour wrote: > > I'm interested in the opinion of others as well. Maybe someone can clear it up for me and make it > seem like a workable idea. Still, I have a couple of comments on your question below. > -Steve > > Martijn van Beers wrote: > > > On Sat, Jul 28, 2001 at 03:05:36PM -0700, Steve Mansour wrote: > > > >> Steve Mansour wrote: > >> > >> > Is everyone concerned yet? REQUEST is the closest thing to in iTIP > >> > to CREATE in CAP. That's what I was saying in my earlier message. The > >> > mapping is probably not going to work out in all cases. That's why I'm > >> > scared of this. I do not consider the commands to be interchangable > >> > between passports. > >> > > >> and, of course, by "passports" I mean "transports". > >> > > Hrm. All of this implies that CREATE and the other calendaring > > commands in CAP aren't going back into iTIP (or get their own > > document). Are they really so tied to CAP? > > > note section 2.8 of the current cap draft. The model for thinking about this is shown in the > diagram. Components that have been sent via iMIP are saved in the calstore with their METHOD value > set to the iTIP METHOD value. That way, a client can simply query on things like > > SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' > > to find all the scheduling requests. So, I think we're OK on finding things. > > However, the is the concern is the following. We use TARGET to identify the calids. We use the > VCOMMAND component to specify the action to apply to the targets. The possibility for problems > comes up when the TARGET is a mailto calid (mailto:bill@example.com, which means iMIP to me) and > the VCOMMAND has no iTIP equivalent, such as READ. > > > And so far I've only heard Steve's opinion on fan-out. Could anyone > > who was in favour of it speak up on why it is a good idea? > > > From a pure *functionality* point of view, I think the desired functionality is great. A CUA does > not have to concern itself with all the messy details of sending some create requests to a cap > server, and some imip requests to individual mail recipients. It doesn't have to worry about the > calendar address translations between cap and imip. It can send down one command and have the > server take care of all this. So, small devices that want to be CAP clients don't need a lot of > fancy code to deal with all this. But this functionality seems to be problematic. > > -Steve From owner-ietf-calendar@mail.imc.org Mon Jul 30 11:21:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27729 for <calsch-archive@odin.ietf.org>; Mon, 30 Jul 2001 11:21:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6UF1KU00484 for ietf-calendar-bks; Mon, 30 Jul 2001 08:01:20 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UF1Js00480 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 08:01:19 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6UF1Ev12782 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 08:01:14 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GHAKE200.JU8; Mon, 30 Jul 2001 08:01:14 -0700 Message-ID: <3B657672.7010202@netscape.com> Date: Mon, 30 Jul 2001 08:00:03 -0700 From: sman@netscape.com (Steve Mansour) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010713 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: John Stracke <francis@ecal.com> CC: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <3B656648.5080808@ecal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit John Stracke wrote: > Steve Mansour wrote: > >> Anyway, back to the problem. In order to send this component in an >> iTIP/iMIP message, we have to transform all the calids into something >> iMIP-compatible. That would be "mailto:" addresses. > > I think that's what CRISP was for: so you could use cap: addresses for > everything, and iTIP messages could go over CAP instead of email. > (This could happen without CRISP; CRISP was just a way to set up a CAP > server that just did iTIP, for security reasons.) > > That doesn't answer the question of how to transform CREATE into > REQUEST, though. So... any opinions on whether or not to try to keep fanout in CAP ? John? Anybody? -Steve From owner-ietf-calendar@mail.imc.org Mon Jul 30 11:28:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28258 for <calsch-archive@odin.ietf.org>; Mon, 30 Jul 2001 11:28:58 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6UF9iX00620 for ietf-calendar-bks; Mon, 30 Jul 2001 08:09:44 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UF9hs00616 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 08:09:43 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6UFBXR13519 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 11:11:33 -0400 Message-ID: <3B657924.9000504@ecal.com> Date: Mon, 30 Jul 2001 11:11:32 -0400 From: John Stracke <francis@ecal.com> Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <20010728204435.B31282@khazad-dum.copa.nl> <3B63191F.80500@netscape.com> <3B633730.4020100@netscape.com> <20010729145610.A2695@khazad-dum.copa.nl> <3B644391.50806@netscape.com> <3B656693.5ABB5046@steltor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit George Babics wrote: >For instance, as mentioned earlier, can we properly map all the >CAP methods to all the iTIP methods? > >CREATE & MODIFY -> REQUEST > Almost certainly not. What happens if I get a REQUEST by iMIP, my MUA passes it to my CUA, and the CUA tells the CS to CREATE it? >DELETE calendar -> send a CANCEL for each entry in the calendar >DELETE entry -> send a CANCEL > Possibly not--deleting an event from my CS does not necessarily imply anything about whether the event will take place. For example, maybe I've got more than one CS. I suspect it'll turn out that the only reliable way to do fanout is if the CUA actually talks iTIP to the CS, so there's no translation going on. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Until you stalk and overrun, you can't devour| |francis@ecal.com|anyone. --Hobbes | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Jul 30 12:21:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02942 for <calsch-archive@odin.ietf.org>; Mon, 30 Jul 2001 12:21:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6UG0k805832 for ietf-calendar-bks; Mon, 30 Jul 2001 09:00:46 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UG0js05828 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 09:00:45 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA28700; Mon, 30 Jul 2001 12:00:41 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6UG0ev09968; Mon, 30 Jul 2001 12:00:41 -0400 (EDT) Message-ID: <3B6584A8.636AF6F4@steltor.com> Date: Mon, 30 Jul 2001 12:00:40 -0400 From: George Babics <georgeb@steltor.com> X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour <sman@netscape.com> CC: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP Issue: Decreed VCARs References: <3B57769A.D06440A7@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit I believe decreed VCARs can be useful. It allows an administrator to prevent users changing certain access rights on their calendars. For instance, one can have a decreed VCAR that prevents users from making their calendars modifiable by anonymous users. As for the differences between VCARs and decreed VCARs: The UPN for GRANT and DENY seems to be special users of "OWNER" and "*". That is rights can be denied or granted to everyone and to all owners. One can do a query for these types of VCARs. (However, all the above is not clearly defined in CAP. We should add an example and clarify what decreed VCARs mean.) Another difference is that VCARs are owned by the CS administrator. CAP also says that they are immutable. However, a CS administrator may want to change it at some point. Decreed VCARs are a MAY. If we do remove them from CAP, an implementor may decide to implement these security features in their own way. However, decreed VCARs seem straightforward, useful, and do not add complexity to CAP. Thus, we could leave them in CAP. However, we may want to change their being immutable. George Steve Mansour wrote: > > Hey All, > > I'm trying to determine if there is any detectable difference between a > decreed vcar versus any other vcar. If there is no difference between > them, I'm wondering how we would know a vcar is decreed. > > Are they declared differently than any others? Is there anything about > their data content that distinguishes them from any other vcar? What > does a query for the decreed vcars look like? > > If you have an idea about how they work, please reply and help me out. > > If no one has good answers to these questions, and since decreed vcars > are a "MAY" implement, I think we should we drop them. Any comments on > that? > > -Steve From owner-ietf-calendar@mail.imc.org Mon Jul 30 16:49:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23570 for <calsch-archive@odin.ietf.org>; Mon, 30 Jul 2001 16:49:58 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6UKSxn11469 for ietf-calendar-bks; Mon, 30 Jul 2001 13:28:59 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UKSvs11465 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 13:28:58 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6UKUni15380 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 16:30:49 -0400 Message-ID: <3B65C3F9.6020603@ecal.com> Date: Mon, 30 Jul 2001 16:30:49 -0400 From: John Stracke <francis@ecal.com> Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <3B656648.5080808@ecal.com> <3B657672.7010202@netscape.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Steve Mansour wrote: > So... any opinions on whether or not to try to keep fanout in CAP ? > John? Anybody? Having just reread the fanout section in the I-D, I'd say cut it. It doesn't introduce any truly new capabilities, and it does introduce some potentially serious security problems. Either the servers trust each other, or the server doing fanout has to be able to exercise the user's credentials on the remote server. Either way, it permits an attacker who subverts one server to use it against other servers, instead of limiting the damage to a single server. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |There are footprints on the moon. No feet, just| |francis@ecal.com|footprints. | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Jul 31 01:03:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18352 for <calsch-archive@odin.ietf.org>; Tue, 31 Jul 2001 01:03:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6V4gFu20034 for ietf-calendar-bks; Mon, 30 Jul 2001 21:42:15 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6V4gDs20029 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 21:42:13 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6V4gAv06695 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 21:42:10 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GHBMEB00.137; Mon, 30 Jul 2001 21:42:11 -0700 Message-ID: <3B6636D7.16EDE1B9@netscape.com> Date: Mon, 30 Jul 2001 21:40:55 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: George Babics <georgeb@steltor.com> CC: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP Issue: Decreed VCARs References: <3B57769A.D06440A7@netscape.com> <3B6584A8.636AF6F4@steltor.com> Content-Type: multipart/mixed; boundary="------------EAD8A05D9B325B316EACFADE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. --------------EAD8A05D9B325B316EACFADE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George, How do you know, given a particular VCAR, whether or not it is decreed? Since decreed vcars cannot be overridden, we have to know. For example BEGIN:VCAR CARID:Users Default Access GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; VALUE="Users Default Access" ;OBJECT=METHOD,VALUE=DELETE,MODIFY END:VCAR What is it about this VCAR that is tells me that it is decreed? The complexity decreed vcars is that they add at least two exception cases that I can see. The complexity is small, but it is present. First, they override all others VCARs. So for every access control check you'll need to check decreed vcars first to see if they apply, and if they don't, then you apply the normal vcars. Second, they cannot be changed -- which, I assume, means that only an administrator can change them, because someone will inevitably make a mistake on a decreed vcar and need to change it. So, there will need to be some sort of special handling to create/modify/delete them. -Steve George Babics wrote: > I believe decreed VCARs can be useful. It allows an administrator > to prevent users changing certain access rights on their calendars. > For instance, one can have a decreed VCAR that prevents users from > making their calendars modifiable by anonymous users. > > As for the differences between VCARs and decreed VCARs: > > The UPN for GRANT and DENY seems to be special users of "OWNER" > and "*". That is rights can be denied or granted to everyone and > to all owners. One can do a query for these types of VCARs. > (However, all the above is not clearly defined in CAP. We should > add an example and clarify what decreed VCARs mean.) > > Another difference is that VCARs are owned by the CS > administrator. CAP also says that they are immutable. However, > a CS administrator may want to change it at some point. > > Decreed VCARs are a MAY. If we do remove them from CAP, an implementor > may decide to implement these security features in their own way. > However, decreed VCARs seem straightforward, useful, and do not add > complexity to CAP. Thus, we could leave them in CAP. However, we may > want to change their being immutable. > > George > > > Steve Mansour wrote: > > > > Hey All, > > > > I'm trying to determine if there is any detectable difference between a > > decreed vcar versus any other vcar. If there is no difference between > > them, I'm wondering how we would know a vcar is decreed. > > > > Are they declared differently than any others? Is there anything about > > their data content that distinguishes them from any other vcar? What > > does a query for the decreed vcars look like? > > > > If you have an idea about how they work, please reply and help me out. > > > > If no one has good answers to these questions, and since decreed vcars > > are a "MAY" implement, I think we should we drop them. Any comments on > > that? > > > > -Steve --------------EAD8A05D9B325B316EACFADE Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------EAD8A05D9B325B316EACFADE-- From owner-ietf-calendar@mail.imc.org Tue Jul 31 01:47:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23494 for <calsch-archive@odin.ietf.org>; Tue, 31 Jul 2001 01:47:01 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6V5WxS21067 for ietf-calendar-bks; Mon, 30 Jul 2001 22:32:59 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6V5Wvs21063 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 22:32:57 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6V5WtB00097 for <ietf-calendar@imc.org>; Mon, 30 Jul 2001 22:32:55 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GHBOQW00.5RF; Mon, 30 Jul 2001 22:32:56 -0700 Message-ID: <3B6642BB.EF563126@netscape.com> Date: Mon, 30 Jul 2001 22:31:39 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke <francis@ecal.com> CC: CalSched IETF <ietf-calendar@imc.org> Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <3B656648.5080808@ecal.com> <3B657672.7010202@netscape.com> <3B65C3F9.6020603@ecal.com> Content-Type: multipart/mixed; boundary="------------0578B8D62995D60A3AF05490" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. --------------0578B8D62995D60A3AF05490 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alright John! Any other opinions on this. It's a pretty major change (simplification) to CAP. I want to make sure that there's general buy-in before doing anything. -Steve John Stracke wrote: > Steve Mansour wrote: > > > So... any opinions on whether or not to try to keep fanout in CAP ? > > John? Anybody? > > Having just reread the fanout section in the I-D, I'd say cut it. It > doesn't introduce any truly new capabilities, and it does introduce some > potentially serious security problems. Either the servers trust each > other, or the server doing fanout has to be able to exercise the user's > credentials on the remote server. Either way, it permits an attacker > who subverts one server to use it against other servers, instead of > limiting the damage to a single server. --------------0578B8D62995D60A3AF05490 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------0578B8D62995D60A3AF05490-- From owner-ietf-calendar@mail.imc.org Tue Jul 31 13:59:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03827 for <calsch-archive@odin.ietf.org>; Tue, 31 Jul 2001 13:59:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6VHcGP08400 for ietf-calendar-bks; Tue, 31 Jul 2001 10:38:16 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VHcEs08396 for <ietf-calendar@imc.org>; Tue, 31 Jul 2001 10:38:14 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6VHe7k18297 for <ietf-calendar@imc.org>; Tue, 31 Jul 2001 13:40:07 -0400 Message-ID: <3B66ED77.3000701@ecal.com> Date: Tue, 31 Jul 2001 13:40:07 -0400 From: John Stracke <francis@ecal.com> Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG <ietf-calendar@imc.org> Subject: Monday night dinner? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Are people up for our usual Monday night dinner? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Ea est fabula nostra, et non mutabimus eam! | |francis@ecal.com|--House Falconguard and Affiliated Scum | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Jul 31 14:46:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08229 for <calsch-archive@odin.ietf.org>; Tue, 31 Jul 2001 14:46:06 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6VIYxF09527 for ietf-calendar-bks; Tue, 31 Jul 2001 11:34:59 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VIYws09523 for <ietf-calendar@imc.org>; Tue, 31 Jul 2001 11:34:58 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA16221; Tue, 31 Jul 2001 14:34:59 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA09262; Tue, 31 Jul 2001 14:34:58 -0400 (EDT) Received: from [18.18.1.170] (BOB.MIT.EDU [18.18.1.170]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA08952; Tue, 31 Jul 2001 14:34:57 -0400 (EDT) Mime-Version: 1.0 Message-Id: <p05010405b78caa6be94d@[18.18.1.170]> In-Reply-To: <3B66ED77.3000701@ecal.com> References: <3B66ED77.3000701@ecal.com> Date: Tue, 31 Jul 2001 14:34:54 -0400 To: John Stracke <francis@ecal.com> From: Bob Mahoney <bobmah@mit.edu> Subject: Re: Monday night dinner? Cc: calsch WG <ietf-calendar@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> At 1:40 PM -0400 7/31/01, John Stracke wrote: >Are people up for our usual Monday night dinner? I'm assuming we'll follow our usual tradition if meeting at the main registration desk at 7pm. (to be followed by an inefficient Restaurant Selection Process, and a Meandering Stroll... :-) -Bob From owner-ietf-calendar@mail.imc.org Tue Jul 31 14:50:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08810 for <calsch-archive@odin.ietf.org>; Tue, 31 Jul 2001 14:50:30 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6VIfLD09634 for ietf-calendar-bks; Tue, 31 Jul 2001 11:41:21 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VIfKs09630 for <ietf-calendar@imc.org>; Tue, 31 Jul 2001 11:41:20 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6VIhBk26878 for <ietf-calendar@imc.org>; Tue, 31 Jul 2001 14:43:12 -0400 Message-ID: <3B66FC3F.4080201@ecal.com> Date: Tue, 31 Jul 2001 14:43:11 -0400 From: John Stracke <francis@ecal.com> Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG <ietf-calendar@imc.org> Subject: Re: Monday night dinner? References: <3B66ED77.3000701@ecal.com> <p05010405b78caa6be94d@[18.18.1.170]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Bob Mahoney wrote: > I'm assuming we'll follow our usual tradition if meeting at the main > registration desk at 7pm. (to be followed by an inefficient > Restaurant Selection Process, Sounds like the subject of an April Fool's RFC... -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Q: What goes "Pieces of 7! Pieces of 7!"? A: A| |francis@ecal.com|parroty error. | \===============================================================/