Subject: Re: [Ietf-caldav] Confused about calendar query filters
From: Bernard Desruisseaux <[email-masked]>
To: Wilfredo Sánchez Vega <[email-masked]>
Cc: [email-masked]
Date: Mon, 31 Oct 2005 20:37:49 -0500
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Wilfredo Sánchez Vega wrote:

>   I'm trying to get my head around example 6.4.1...
> 
>   Let's say I have a resource on my CalDAV server with four events:
> 
>     Jan 12, 2006 1PM WST
>     Feb 12, 2006 1PM WST
>     Mar 12, 2006 1PM WST
>     Apr 12, 2006 1PM WST
> 
> ...and all four events are in a custom timezone "WST" which is also  
> defined in that resource.
> 
>   And I request a calendar-query report with this filter:
> 
>     <filter>
>       <comp-filter name="VCALENDAR">
>         <comp-filter name="VEVENT">
>           <time-range start="20060201" end="20060228"/> <!-- All of  Feb 
> 2006 -->
>         </comp-filter>
>       </comp-filter>
>     </filter>
> 
>   When I get back the report, do I just get back the matching  component 
> (the Feb 12 event), or does the whole resource match, so I  get back all 
> four events plus the timezone definition?

You would get the whole calendar object resource with the four
recurrence instances.

If you only want to get the recurrence instances that match a given
time range you need to specify the CALDAV:limit-recurrence-set XML
element inside the CALDAV:calendar-data.

> 
>   If the former, then the example request in 6.4.1's request for  
> VTIMEZONE data in the response is not ever going to happen, so I'm  
> guessing it's the latter.  Specifically, I'm reading this as: "give  me 
> all data from any resource which contains an event that (at least  
> partially) occurs in Feb 2006."

Right.

> 
>   So if I had this instead:
> 
>     <filter>
>       <comp-filter name="VCALENDAR">
>         <comp-filter name="VEVENT"/>
>       </comp-filter>
>     </filter>
> 
>   I'd interpret it as "give me all data for any resource which  contains 
> an event." and going t the extreme:

Right, but you forgot the "is-defined" XML element.

      <filter>
        <comp-filter name="VCALENDAR">
          <comp-filter name="VEVENT">
            <is-defined/>
          </comp-filter>
        </comp-filter>
      </filter>

> 
>     <filter>
>       <comp-filter name="VCALENDAR"/>
>     </filter>
> 
> ...would be "give me all data for all resources."

Right, but you also need the "is-defined" XML element.

> 
>   Is this all correct?
> 
>   I think my confusion stems from the fact that the first example  
> contains both a filter (required) and a DAV:prop qualifier and it's  
> hard to keep track of which elements are doing what filtering for  you, 
> that the <filter> filters out resources and <DAV:prop> selects  
> components and properties within the matching resources.
> 
>   It might help if the example response included a (non-recurring)  
> event outside of the filter's time range, with the explanation that  the 
> event is part of a matching resource (notice the UID matches an  event 
> in the time range), and if it included a VTIMEZONE component  even 
> though there is no mention of VTIMEZONE in filter.  I think that  might 
> clarify things a little bit, assuming I'm reading it right.

Thanks for the feedback.  I'll update the example.

Cheers,
Bernard

> 
>     -wsv
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

To: [email-masked]
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Date: Mon, 31 Oct 2005 14:15:04 -0800
Subject: [Ietf-caldav] Confused about calendar query filters

--Apple-Mail-33-18366012
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

   I'm trying to get my head around example 6.4.1...

   Let's say I have a resource on my CalDAV server with four events:

     Jan 12, 2006 1PM WST
     Feb 12, 2006 1PM WST
     Mar 12, 2006 1PM WST
     Apr 12, 2006 1PM WST

...and all four events are in a custom timezone "WST" which is also  
defined in that resource.

   And I request a calendar-query report with this filter:

     <filter>
       <comp-filter name="VCALENDAR">
         <comp-filter name="VEVENT">
           <time-range start="20060201" end="20060228"/> <!-- All of  
Feb 2006 -->
         </comp-filter>
       </comp-filter>
     </filter>

   When I get back the report, do I just get back the matching  
component (the Feb 12 event), or does the whole resource match, so I  
get back all four events plus the timezone definition?

   If the former, then the example request in 6.4.1's request for  
VTIMEZONE data in the response is not ever going to happen, so I'm  
guessing it's the latter.  Specifically, I'm reading this as: "give  
me all data from any resource which contains an event that (at least  
partially) occurs in Feb 2006."

   So if I had this instead:

     <filter>
       <comp-filter name="VCALENDAR">
         <comp-filter name="VEVENT"/>
       </comp-filter>
     </filter>

   I'd interpret it as "give me all data for any resource which  
contains an event." and going t the extreme:

     <filter>
       <comp-filter name="VCALENDAR"/>
     </filter>

...would be "give me all data for all resources."

   Is this all correct?

   I think my confusion stems from the fact that the first example  
contains both a filter (required) and a DAV:prop qualifier and it's  
hard to keep track of which elements are doing what filtering for  
you, that the <filter> filters out resources and <DAV:prop> selects  
components and properties within the matching resources.

   It might help if the example response included a (non-recurring)  
event outside of the filter's time range, with the explanation that  
the event is part of a matching resource (notice the UID matches an  
event in the time range), and if it included a VTIMEZONE component  
even though there is no mention of VTIMEZONE in filter.  I think that  
might clarify things a little bit, assuming I'm reading it right.

     -wsv

--Apple-Mail-33-18366012
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-33-18366012--

From: Lisa Dusseault <[email-masked]>
Date: Sat, 29 Oct 2005 09:02:04 -0700
To: [email-masked]
Cc: [email-masked], Carol Tsai <[email-masked]>, [email-masked]
Subject: [Ietf-caldav] Transparency, status, attendance and free-busy interactions

Part of the iCalendar model confusion here is whether the VEVENT  
component is part of a personal calendar, or part of a shared  
repository of events.

In the case where VEVENTs are in a personal calendar, stored only on my  
machine (or on a server where other agents don't view the event as part  
of their calendar), then in that context it would be reasonable to  
model free-busy as being independent from attendance.    In this  
model/context:
  - Any event in a personal calendar that is confirmed and opaque would  
affect free-busy.
  - Even if there is no attendance list, it's on the personal calendar  
and opacity means it affects free-busy.
  - If there is an attendance list, and the user is not on that list,  
it's still on their personal calendar and thus opacity means it affects  
free-busy.
I believe this is the way most personal calendars work today, importing  
ICS files or storing data in ICS files locally or via WebCAL.

In the case where VEVENTs are in a shared repository, where multiple  
individuals view the same component, now attendance would affect  
free-busy.
  - If the user shows up as an attendee, and the event is confirmed, and  
the event is opaque, this would affect free-busy
  - Possibly opacity and status should be per-user properties.  Several  
attendees of a meeting might be in different stages of invitations --  
some confirmed, some only tentative.
I believe some shared calendar servers do work this way today and they  
should describe what they've actually implemented and what that means  
for iCalendar.

But what context dependencies mean for the overall discussion is that  
we can't discuss what free-busy means independent of context.  It may  
be very difficult to standardize this in just one way in RFC2445 bis  
and we should keep in mind other possibilities.  For example, we could  
split RFC2445 bis into several sections/documents
   1. the base format, used in many contexts
   2.  what different elements of the base format mean in import/export  
of ICS files for personal calendars
   3.  what different elements of the base format mean in iTIP usage

Lisa

On Oct 29, 2005, at 8:43 AM, Anil SRIVASTAVA wrote:

> On 2005-10-28/23:43 [-0400], [email-masked]  
> [Bernard...:
>
>> Carol,
>>
>> The table I posted in a separate thread was built with the
>> assumption that the "TENTATIVE" part in "BUSY-TENTATIVE" was
>> derived from STATUS:TENTATIVE based on the following information:
>>
>> RFC 2445, section 4.2.9 Free/Busy Time Type:
>>
>>  The value BUSY-TENTATIVE indicates that the time interval is busy
>>  because one or more events have been *tentatively scheduled* for
>>  that interval.
>>
>> RFC 2445, section 4.8.1.11 Status:
>>
>>  Description: In a group scheduled calendar component, the property is
>>  used by the "Organizer" to provide a confirmation of the event to the
>>  "Attendees". For example in a "VEVENT" calendar component, the
>>  "Organizer" can indicate that a meeting is tentative, confirmed or
>>  cancelled.
>>
>> You may ask "But what if I tentatively accepted the event?" (i.e.,
>> you set PARTSTAT=TENTATIVE on *your* ATTENDEE property). Shouldn't
>> the derived FBTYPE be BUSY-TENTATIVE even though the event might
>> have been confirmed by the Organizer (i.e., STATUS:CONFIRMED)?
>> It seems not.
>
> That being the case, I think it is clearly broken.  The attendees
> individual acceptance status has to play a role in the dynamically
> generated FB time.  If an attendee has not accepted the event or
> declined it, then clearly they are not attending the meeting the
> organizer put together and are therefor available.
>
> PARTSTAT of an attendee should take precedence over the STATUS  
> property.
>
>
> Anil
>
>>
>> Section 4.8.1.11 makes me believe that an attendee would not change
>> the value of the STATUS property set by the Organizer (i.e., "the
>> property is used by the Organizer..."). But I don't believe it is
>> the case for the TRANSP property given that its purpose is to "define
>> whether an event is transparent or not to busy time searches" on a
>> calendar. The same way you would ignore/modify the VALARM that you
>> would receive from the Organizer, you would also ignore/modify the
>> value of the TRANSP property as you wish.
>>
>> Cheers,
>> Bernard
>>
>> Carol Tsai wrote:
>>
>>> Hi Cameron,
>>>
>>> I was researching on how to create an iCal that has the show as time
>>> be Tentative when I came accross your posting
>>> (http://lists.osafoundation.org/pipermail/ietf-calsify/2004-August/ 
>>> 000050.html).
>>> I was wondering if you received a reply to that? I agree that the
>>> TRANSP property doesn't seem to have a Tentative option.
>>>
>>> Carol Tsai
>>>
>>> REARDEN commerce 1400 Fashion Island Blvd Suite 150 San Mateo Ca
>>> 94404
>>>
>>> T 650 212 8474 F 650 212 8499
>>>
>>> www.reardencommerce.com <http://www.reardencommerce.com>
>>>
>>> _______________________________________________ Ietf-calsify mailing
>>> list [email-masked]
>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>
> -- 
> _______________
> Anil SRIVASTAVA
> [email-masked]
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Sat, 29 Oct 2005 08:43:55 -0700 (Pacific Daylight Time)
From: Anil SRIVASTAVA <[email-masked]>
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Organization: Sun Microsystems [http://www.sun.com]
Accept-Language: English; en
Cc: [email-masked], [email-masked], Carol Tsai <[email-masked]>
Subject: [Ietf-caldav] Re: [Ietf-calsify] Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'
Reply-To: [email-masked]

On 2005-10-28/23:43 [-0400], [email-masked] [Bernard...:

> Carol,
> 
> The table I posted in a separate thread was built with the
> assumption that the "TENTATIVE" part in "BUSY-TENTATIVE" was
> derived from STATUS:TENTATIVE based on the following information:
> 
> RFC 2445, section 4.2.9 Free/Busy Time Type:
> 
>  The value BUSY-TENTATIVE indicates that the time interval is busy
>  because one or more events have been *tentatively scheduled* for
>  that interval.
> 
> RFC 2445, section 4.8.1.11 Status:
> 
>  Description: In a group scheduled calendar component, the property is
>  used by the "Organizer" to provide a confirmation of the event to the
>  "Attendees". For example in a "VEVENT" calendar component, the
>  "Organizer" can indicate that a meeting is tentative, confirmed or
>  cancelled.
> 
> You may ask "But what if I tentatively accepted the event?" (i.e.,
> you set PARTSTAT=TENTATIVE on *your* ATTENDEE property). Shouldn't
> the derived FBTYPE be BUSY-TENTATIVE even though the event might
> have been confirmed by the Organizer (i.e., STATUS:CONFIRMED)?
> It seems not.

That being the case, I think it is clearly broken.  The attendees 
individual acceptance status has to play a role in the dynamically 
generated FB time.  If an attendee has not accepted the event or 
declined it, then clearly they are not attending the meeting the 
organizer put together and are therefor available. 

PARTSTAT of an attendee should take precedence over the STATUS property.  

Anil

> 
> Section 4.8.1.11 makes me believe that an attendee would not change
> the value of the STATUS property set by the Organizer (i.e., "the
> property is used by the Organizer..."). But I don't believe it is
> the case for the TRANSP property given that its purpose is to "define
> whether an event is transparent or not to busy time searches" on a
> calendar. The same way you would ignore/modify the VALARM that you
> would receive from the Organizer, you would also ignore/modify the
> value of the TRANSP property as you wish.
> 
> Cheers,
> Bernard
> 
> Carol Tsai wrote:
> 
> > Hi Cameron,
> > 
> > I was researching on how to create an iCal that has the show as time
> > be Tentative when I came accross your posting
> > (http://lists.osafoundation.org/pipermail/ietf-calsify/2004-August/000050.html).
> > I was wondering if you received a reply to that? I agree that the
> > TRANSP property doesn't seem to have a Tentative option.
> > 
> > Carol Tsai
> > 
> > REARDEN commerce 1400 Fashion Island Blvd Suite 150 San Mateo Ca
> > 94404
> > 
> > T 650 212 8474 F 650 212 8499
> > 
> > www.reardencommerce.com <http://www.reardencommerce.com>
> > 
> > _______________________________________________ Ietf-calsify mailing
> > list [email-masked]
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

-- 
_______________
Anil SRIVASTAVA
[email-masked]

Date: Fri, 28 Oct 2005 23:43:04 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Carol Tsai <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [Ietf-caldav] Re: [Ietf-calsify] Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'

Carol,

The table I posted in a separate thread was built with the
assumption that the "TENTATIVE" part in "BUSY-TENTATIVE" was
derived from STATUS:TENTATIVE based on the following information:

RFC 2445, section 4.2.9 Free/Busy Time Type:

  The value BUSY-TENTATIVE indicates that the time interval is busy
  because one or more events have been *tentatively scheduled* for
  that interval.

RFC 2445, section 4.8.1.11 Status:

  Description: In a group scheduled calendar component, the property is
  used by the "Organizer" to provide a confirmation of the event to the
  "Attendees". For example in a "VEVENT" calendar component, the
  "Organizer" can indicate that a meeting is tentative, confirmed or
  cancelled.

You may ask "But what if I tentatively accepted the event?" (i.e.,
you set PARTSTAT=TENTATIVE on *your* ATTENDEE property). Shouldn't
the derived FBTYPE be BUSY-TENTATIVE even though the event might
have been confirmed by the Organizer (i.e., STATUS:CONFIRMED)?
It seems not.

Section 4.8.1.11 makes me believe that an attendee would not change
the value of the STATUS property set by the Organizer (i.e., "the
property is used by the Organizer..."). But I don't believe it is
the case for the TRANSP property given that its purpose is to "define
whether an event is transparent or not to busy time searches" on a
calendar. The same way you would ignore/modify the VALARM that you
would receive from the Organizer, you would also ignore/modify the
value of the TRANSP property as you wish.

Cheers,
Bernard

Carol Tsai wrote:

> Hi Cameron,
> 
> I was researching on how to create an iCal that has the show as time
> be Tentative when I came accross your posting
> (http://lists.osafoundation.org/pipermail/ietf-calsify/2004-August/000050.html).
> I was wondering if you received a reply to that? I agree that the
> TRANSP property doesn't seem to have a Tentative option.
> 
> Carol Tsai
> 
> REARDEN commerce 1400 Fashion Island Blvd Suite 150 San Mateo Ca
> 94404
> 
> T 650 212 8474 F 650 212 8499
> 
> www.reardencommerce.com <http://www.reardencommerce.com>
> 
> _______________________________________________ Ietf-calsify mailing
> list [email-masked] 
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 28 Oct 2005 10:52:01 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-caldav] How to derive FREEBUSY;FBTYPE from a VEVENT?
Cc: [email-masked]

Hi Bernard,

--On October 28, 2005 10:30:34 AM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> When would a calendar application derive FBTYPE=BUSY-UNAVAILABLE ?
>
> When would a calendar application derive FBTYPE=x-name ?

I don't think either of these should ever be 'derived' from a VEVENT. 
Rather, if a user wants to specify those, they directly create a VFREEBUSY 
object in their calendar and use that.

That said, I certainly would like to see a table like the one you created 
appearing in either 2445bis or 2446bis.

One other thing that came up as I reviewed this: its not totally clear to 
me how free-busy is supposed to work with all day events. If I have an all 
day event marked with TRANSP=OPAQUE, should the FREEBUSY property specify a 
date-time or a date only? 2445 only seems to show timed cases and kind of 
implies that times are always required. Can this be clarified?

-- 
Cyrus Daboo

Date: Fri, 28 Oct 2005 10:30:34 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-caldav] How to derive FREEBUSY;FBTYPE from a VEVENT?

The FBTYPE parameter of FREEBUSY properties of VFREEBUSY components
can take one of the following values:

  - FREE
  - BUSY
  - BUSY-UNAVAILABLE
  - BUSY-TENTATIVE
  - x-name

How can a calendar application (e.g., CalDAV Server) derive the
proper FBTYPE value from a given VEVENT?

Assuming that the FBTYPE parameter of the FREEBUSY property of
a VFREEBUSY component should be derived from the TRANSP and
STATUS properties of the VEVENT component, does the following
table make sense?

     +---------------------------++------------------+
     |          VEVENT           || VFREEBUSY        |
     +-------------+-------------++------------------+
     | TRANSP      | STATUS      || FBTYPE           |
     +=============+=============++==================+
     | TRANSPARENT | <Any value> || FREE             |
     +-------------+-------------++------------------+
     |             | CANCELLED   || FREE             |
     |             +-------------++------------------+
     |             | <Undefined> || BUSY             |
     | OPAQUE      | CONFIRMED   ||                  |
     | <Undefined> +-------------++------------------+
     |             |    ???      || BUSY-UNAVAILABLE |
     |             +-------------++------------------+
     |             | TENTATIVE   || BUSY-TENTATIVE   |
     +-------------+-------------++------------------+

When would a calendar application derive FBTYPE=BUSY-UNAVAILABLE ?

When would a calendar application derive FBTYPE=x-name ?

Cheers,
Bernard

From: "Trever L. Adams" <[email-masked]>
To: CalDav <[email-masked]>
Date: Tue, 25 Oct 2005 15:08:40 -0600
Subject: [Ietf-caldav] Secition 6.3 of Caldav-sched

Forgive me if my stupidity shows through. However, I believe this
section could be simply written if the server is required to send the
acceptance or "rejectance" of a task or calander. I quote:
"  TODO: Need to explain here how to handle incoming iTIP messages.  If
   the client wants to accept a message, it needs to create an event and
   mark the inbox resource as "accepted".  If the client wants to reject
   it, it simply changes a property.  Need to define that property.
   Also recommend locking the Inbox resource to avoid race conditions
   with other clients -- or use ETags to verify."

ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
    ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:mailto:cyr
    [email-masked]

To accept, the PARTSTAT should be Accepted (at least, I believe that is
the iCal text). To reject, the PARTSTAT should be declined. When they
are put back in the inbox, the server should send out the appropriate
iTip message. I believe this answers the above section clearly, it
avoids a huge amount of additional protocol cruft by just using built in
parts that already exist.

I think that any modification to an assigned task or meeting, no matter
where it exists (outgoing, incoming, or other) should be sent as an iTip
to the rest of the users. The exception may be description or notes.

I have seen it argued that tasks should have never been part of ical, I
do not see why not. Especially assigned tasks, they are just a meeting
more or less. They may be different things, but the schemes are all but
identical. A task is more or less the same as a private appointment as
well.

Are tasks supported in CalDAV? I think they should be.

Thanks for listening,
Trever Adams
--
"A citizen of America will cross the ocean to fight for democracy, but
won't cross the street to vote in a national election." -- Bill Vaughan

Date: Wed, 19 Oct 2005 13:44:29 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Off topic: CardDAV
Reply-To: CardDAV DevList <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms010906030601000409020206
Content-Type: multipart/mixed; boundary="------------070600090609010901060009"

This is a multi-part message in MIME format.
--------------070600090609010901060009
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Guenther wrote:
> I agree, and it begs the question if those two (CalDAV and CardDAV)  
> should be rolled into one standard.

This is really separate from CalDAV or CALSIFY:

I think that vCard and iCal should be able to be transported in
the same multipart/related mime object so that the iCal object
can transfer information needed about the entities.

This could also work with iMIP and any other transport.

If ATTENDEE were extended to include a ATTACH (or ATTACH like)
parameter then the vCard could just be another attachment. Or
maybe an ALTREP. Or maybe a new VCARD parameter that takes a URL
value?

If it used a CID, then it could be embedded into the same
MIME object, with that CID object specifying its own MIME
type of vCARD.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070600090609010901060009
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-594-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------070600090609010901060009--

--------------ms010906030601000409020206
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010906030601000409020206--

Content-Class: urn:content-classes:message
Subject: RE: [Ietf-caldav] Off topic: CardDAV
Date: Wed, 19 Oct 2005 10:05:58 -0700
From: Cameron Stillion <[email-masked]>
To: "Carsten Guenther" <[email-masked]>
Cc: CalDAV DevList <[email-masked]>, CardDAV DevList <[email-masked]>

I actually think there is value in having them separate - just as iCal
should never have contained tasks... They are fundamentally different
data types.  BUT, they need to have a connection.  The protocol and
schema should connect - clearly and purposefully.

cam

-----Original Message-----
From: Carsten Guenther [mailto:[email-masked]]=20
Sent: Wednesday.19.October.2005 09.41
To: Cameron Stillion
Cc: Mark Paterson; Cyrus Daboo; CalDAV DevList; CardDAV DevList
Subject: Re: [Ietf-caldav] Off topic: CardDAV

I agree, and it begs the question if those two (CalDAV and CardDAV)
should be rolled into one standard.

On Oct 19, 2005, at 9:38 AM, Cameron Stillion wrote:

>
> I would like to just add that strategically, vCard and iCal are=20
> intimately related.  Endeavors in this area are necessarily going to=20
> reference each other.  As soon as you begin implementing any PIM=20
> features of relative value, it becomes very clear.  Distributing=20
> Calendars needs a way to associate an owner with a calendar,=20
> especially the kind that represent your actual schedule, as opposed to

> the calendar for the little league team you coach on the weekends. =20
> Likewise, as soon as you begin distributing your contact information,=20
> the next piece you want to share is your schedule.  Both standards=20
> need to have a way to associate back and forth.  A standard or=20
> protocol that mentions one but not the other, is IMHO - incomplete,=20
> and unfinished.
>
> Cameron
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mark=20
> Paterson
> Sent: Wednesday.19.October.2005 08.59
> To: Cyrus Daboo
> Cc: CalDAV DevList; CardDAV DevList
> Subject: Re: [Ietf-caldav] Off topic: CardDAV
>
> Nice idea but you may want to consider a cardsify initiative to go=20
> along with it. vCard leaves a lot to be desired.:-)
>
> Cyrus Daboo wrote:
>
>
>> Hi folks,
>> This is a little of topic, but I think it is relevant for most folks.
>> I have just sent in a draft for a new protocol called CardDAV:
>>
>> <http://www.ietf.org/internet-drafts/draft-daboo-carddav-00.txt>
>>
>> CardDAV does for vCards what CalDAV does for iCalendar. i.e. it=20
>> provides a set of WebDAV extensions and a data model for access to=20
>> vCard objects stored on a server. CardDAV is very similar to CalDAV=20
>> because of the similarities between iCalendar and vCard formats.
>>
>> There is a separate discussion list setup for CardDAV, so please=20
>> respond to any comments on that list rather than the CalDAV list.
>> List
>>
>
>
>> details are below:
>>
>> <http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>
>>
>>
>
> --
> MARK PATERSON
> Director, Software Development
> Collaborative Application Services
> Oracle Corporation - Server Technologies
>
> Phone:  514.905.8649
> Mobile: 514.862.8505
> mailto: [email-masked]
> http:   www.oracle.com
>
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked] See=20
> http://ietf.webdav.org/caldav/ for more CalDAV resources=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked] See=20
> http://ietf.webdav.org/caldav/ for more CalDAV resources=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>

Date: Wed, 19 Oct 2005 09:41:27 -0700
From: "Carsten Guenther" <[email-masked]>
To: Cameron Stillion <[email-masked]>
Subject: Re: [Ietf-caldav] Off topic: CardDAV
Cc: CalDAV DevList <[email-masked]>, CardDAV DevList <[email-masked]>

I agree, and it begs the question if those two (CalDAV and CardDAV)  
should be rolled into one standard.

On Oct 19, 2005, at 9:38 AM, Cameron Stillion wrote:

>
> I would like to just add that strategically, vCard and iCal are
> intimately related.  Endeavors in this area are necessarily going to
> reference each other.  As soon as you begin implementing any PIM
> features of relative value, it becomes very clear.  Distributing
> Calendars needs a way to associate an owner with a calendar,  
> especially
> the kind that represent your actual schedule, as opposed to the  
> calendar
> for the little league team you coach on the weekends.  Likewise, as  
> soon
> as you begin distributing your contact information, the next piece you
> want to share is your schedule.  Both standards need to have a way to
> associate back and forth.  A standard or protocol that mentions one  
> but
> not the other, is IMHO - incomplete, and unfinished.
>
> Cameron
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mark
> Paterson
> Sent: Wednesday.19.October.2005 08.59
> To: Cyrus Daboo
> Cc: CalDAV DevList; CardDAV DevList
> Subject: Re: [Ietf-caldav] Off topic: CardDAV
>
> Nice idea but you may want to consider a cardsify initiative to go  
> along
> with it. vCard leaves a lot to be desired.:-)
>
> Cyrus Daboo wrote:
>
>
>> Hi folks,
>> This is a little of topic, but I think it is relevant for most folks.
>> I have just sent in a draft for a new protocol called CardDAV:
>>
>> <http://www.ietf.org/internet-drafts/draft-daboo-carddav-00.txt>
>>
>> CardDAV does for vCards what CalDAV does for iCalendar. i.e. it
>> provides a set of WebDAV extensions and a data model for access to
>> vCard objects stored on a server. CardDAV is very similar to CalDAV
>> because of the similarities between iCalendar and vCard formats.
>>
>> There is a separate discussion list setup for CardDAV, so please
>> respond to any comments on that list rather than the CalDAV list.  
>> List
>>
>
>
>> details are below:
>>
>> <http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>
>>
>>
>
> --
> MARK PATERSON
> Director, Software Development
> Collaborative Application Services
> Oracle Corporation - Server Technologies
>
> Phone:  514.905.8649
> Mobile: 514.862.8505
> mailto: [email-masked]
> http:   www.oracle.com
>
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked] See
> http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>

Content-Class: urn:content-classes:message
Subject: RE: [Ietf-caldav] Off topic: CardDAV
Date: Wed, 19 Oct 2005 09:38:17 -0700
From: Cameron Stillion <[email-masked]>
To: "Mark Paterson" <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: CalDAV DevList <[email-masked]>, CardDAV DevList <[email-masked]>

I would like to just add that strategically, vCard and iCal are
intimately related.  Endeavors in this area are necessarily going to
reference each other.  As soon as you begin implementing any PIM
features of relative value, it becomes very clear.  Distributing
Calendars needs a way to associate an owner with a calendar, especially
the kind that represent your actual schedule, as opposed to the calendar
for the little league team you coach on the weekends.  Likewise, as soon
as you begin distributing your contact information, the next piece you
want to share is your schedule.  Both standards need to have a way to
associate back and forth.  A standard or protocol that mentions one but
not the other, is IMHO - incomplete, and unfinished.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark
Paterson
Sent: Wednesday.19.October.2005 08.59
To: Cyrus Daboo
Cc: CalDAV DevList; CardDAV DevList
Subject: Re: [Ietf-caldav] Off topic: CardDAV

Nice idea but you may want to consider a cardsify initiative to go along
with it. vCard leaves a lot to be desired.:-)

Cyrus Daboo wrote:

> Hi folks,
> This is a little of topic, but I think it is relevant for most folks.=20
> I have just sent in a draft for a new protocol called CardDAV:
>
> <http://www.ietf.org/internet-drafts/draft-daboo-carddav-00.txt>
>
> CardDAV does for vCards what CalDAV does for iCalendar. i.e. it=20
> provides a set of WebDAV extensions and a data model for access to=20
> vCard objects stored on a server. CardDAV is very similar to CalDAV=20
> because of the similarities between iCalendar and vCard formats.
>
> There is a separate discussion list setup for CardDAV, so please=20
> respond to any comments on that list rather than the CalDAV list. List

> details are below:
>
> <http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>
>

--
MARK PATERSON
Director, Software Development
Collaborative Application Services
Oracle Corporation - Server Technologies

Phone:  514.905.8649
Mobile: 514.862.8505
mailto: [email-masked]
http:   www.oracle.com

_______________________________________________
Ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Wed, 19 Oct 2005 11:59:00 -0400
From: Mark Paterson <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] Off topic: CardDAV
Cc: CalDAV DevList <[email-masked]>, CardDAV DevList <[email-masked]>

Nice idea but you may want to consider a cardsify initiative to go along 
with it. vCard leaves a lot to be desired.:-)

Cyrus Daboo wrote:

> Hi folks,
> This is a little of topic, but I think it is relevant for most folks. 
> I have just sent in a draft for a new protocol called CardDAV:
>
> <http://www.ietf.org/internet-drafts/draft-daboo-carddav-00.txt>
>
> CardDAV does for vCards what CalDAV does for iCalendar. i.e. it 
> provides a set of WebDAV extensions and a data model for access to 
> vCard objects stored on a server. CardDAV is very similar to CalDAV 
> because of the similarities between iCalendar and vCard formats.
>
> There is a separate discussion list setup for CardDAV, so please 
> respond to any comments on that list rather than the CalDAV list. List 
> details are below:
>
> <http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>
>

-- 
MARK PATERSON
Director, Software Development
Collaborative Application Services
Oracle Corporation - Server Technologies

Phone:  514.905.8649
Mobile: 514.862.8505
mailto: [email-masked]
http:   www.oracle.com

Date: Tue, 18 Oct 2005 16:44:32 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Cc: CardDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Off topic: CardDAV

Hi folks,
This is a little of topic, but I think it is relevant for most folks. I 
have just sent in a draft for a new protocol called CardDAV:

<http://www.ietf.org/internet-drafts/draft-daboo-carddav-00.txt>

CardDAV does for vCards what CalDAV does for iCalendar. i.e. it provides a 
set of WebDAV extensions and a data model for access to vCard objects 
stored on a server. CardDAV is very similar to CalDAV because of the 
similarities between iCalendar and vCard formats.

There is a separate discussion list setup for CardDAV, so please respond to 
any comments on that list rather than the CalDAV list. List details are 
below:

<http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>

-- 
Cyrus Daboo

Date: Wed, 12 Oct 2005 20:28:54 -0400
To: CalDAV DevList <[email-masked]>
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-caldav] Subscriptions, free/busy etc

>
>OK, as soon as you add shared calendars into this, all bets are off 
>because iCalendar really does not support shared calendars in any 
>practical way. i.e. it is not possible for one 'subscriber' of a calendar 
>to indicate that they are attending one event independently of another 
>'subscriber'. i.e. there are no per-user options for the TRANSP property. 
>Really per-user options are going to be required to support this, not just 
>at the calendar level but at the event level - i.e. the subscription 
>mechanism needs to allow subscription to individual events within a calendar.
>

I think that the PARTSTAT parameter of the ATTENDEE property (4.2.12 in RFC 
2445) would be the place to start for this use case; I'm not positive of 
what method to use to implement it, but one possiblity is to have a VEVENT 
with a reference to the shared calendar VEVENT, and have it contain  an 
ATTENDEE property equal to "self" (however identified) with a PARTSTAT that 
indicates whether you're attending or not.   This is just an idea - but I 
did want to point out PARTSTAT in contrast to TRANSP because participation 
status for a meeting is much more analgous to attendance to some shared event.

Tim Hare
Interested Bystander, Non-Inc. 

Content-Class: urn:content-classes:message
Subject: RE: [Ietf-caldav] Subscriptions, free/busy etc
Date: Wed, 12 Oct 2005 08:45:00 -0700
From: Cameron Stillion <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Mike Douglass" <[email-masked]>, "CalDAV DevList" <[email-masked]>

I would like to add my 2 or 3 cents here - subscriptions are perhaps one
of the most interesting user features in this space.  Sans CalDav,
several ad-hoc standards (like webcal:// ) have emerged to try and fill
this gap.  A client is still required to click the link to configure and
"subscribe" to the rendering of the calendar (whether it is a
combination of other subscriptions or not...) The similarity to POP/SMTP
is fascinating, although no standards have emerged to fill the gap for
those types of server configurations - think of a POP3 client having the
one and only "subscription" to its inbox.  This is not completely unlike
rss subscriptions. =20

Hmmm.=20

And with that, I'll let the idea go where it will.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Wednesday.12.October.2005 07.32
To: Mike Douglass; CalDAV DevList
Subject: Re: [Ietf-caldav] Subscriptions, free/busy etc

Hi Mike,
Some comments. Note that I am going to express my own bias here which is
towards a central client preferences server solution since that is how I
did all this in Mulberry using IMSP & ACAP. Admittedly email is accessed
and managed differently than calendar data so analogies between mailbox
subscriptions and calendar subscriptions may not be completely valid,
but still I think there are enough similarities that it is worth doing.

--On October 12, 2005 10:02:22 AM -0400 Mike Douglass <[email-masked]>
wrote:

> 1. More of a convenience - I can set up my view of the world at some=20
> central location and all my clients will have the same view.

In theory. However, you really need to be very explicit as to what this
subscription behaviour is meant to me. For example, in the IMAP world
there are SUBSCRIBE'd mailboxes. However, clients have taken many
different views as to what that is actually supposed to me. Some
automatically subscribe users to all mailboxes they think are 'personal'
mailboxes. Others assume that subscribed mailboxes should always be
checked for new mail. Others use it as simply a way to emphasis certain
mailboxes in their display.

> 2. Perhaps a variant of 1 - how do I synch external devices to my full

> calendar view? via for example synchml

A smart CalDAV<->SyncML solution will need to allow users to specify a
list of calendars to actually sync to, and it will aggregate all those
calendars into one effective 'view' for SyncML purposes. In this case
some type of 'sync_calendars' property on the user principal in CalDAV
might do. Note however, that the ser of calendars I might want to sync
may be different from the set of calendars I want to display on my
mobile device. Some I think there would be a need to identify different
'types' of subscription:

1) 'View' subscription - these are all the calendars I want to see
overlayed on my desktop client
2) 'Mobile' subscription - these are all the calendars I want to see and
sync to on my mobile device.
3) 'Free Busy' subscription - these are all the calendars that indicate
my free-busy time.

> 3. How do I make my free/busy time available to someone if it depends=20
> upon a calendar I'm subscribed to?

The calendar-schedule portion of CalDAV will have to define that. i.e.
an iTIP request for free-busy time on the CalDAV server is going to have
to know which calendars of the calendar user are appropriate. This will
likely need the 'free busy' type subscription list.

> I understand Bernards point that we the calendars may not all be on=20
> the same server - at the extreme none of them need be. From a=20
> practical point of view however, subscriptions are very important and=20
> perhaps deserve central support.

They can be centrally supported if clients support a central preferences
store and we define a schema for calendar client preferences on that
store.=20
XCAP could easily provide that solution and go beyond just the
'subscription' preferences - e.g. the choice of which colour to use to
display each subscribed calendars is also a preference one would like to
carry over from one client to another.

> Students have their own personal calendars. They are subscribed to a=20
> calendar which provides their class schedule. Their free/busy time is=20
> certainly an amalgam of that and any other events they choose to add.

OK, as soon as you add shared calendars into this, all bets are off
because iCalendar really does not support shared calendars in any
practical way.=20
i.e. it is not possible for one 'subscriber' of a calendar to indicate
that they are attending one event independently of another 'subscriber'.
i.e.=20
there are no per-user options for the TRANSP property. Really per-user
options are going to be required to support this, not just at the
calendar level but at the event level - i.e. the subscription mechanism
needs to allow subscription to individual events within a calendar.

The question is whether something like this can be accomplished using
iCalendar extension or whether it should be done as part of CalDAV (i.e.

WebDAV properties). In either case it is going to require some sort of
extension to the base to provide per-user properties of some sort.

> Faculty have multiple calendars - consultation times, teaching times,=20
> personal information. Free/busy is an aggregation of that. For=20
> meetings others need to see the results after including all calendar
information.
>
> If we make subscriptions a client side only feature how do we get a=20
> true free/busy report for somebody else?

calendar-schedule will take care of that.

The other point to bear in mind here is that you are making assumption
on how clients are going to organize their display to the user.
Certainly in the email world there are many different ways that that has
been done, and client authors will likely want to be flexible in terms
of what they do based on their own requirements for the service they are
providing.

So in the end I'm not sure that the 'view' type of subscriptions are
going to be useful - certainly the free-busy issue has to be taken care
of and hopefully calendar-schedule will do that.

--
Cyrus Daboo
_______________________________________________
Ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Wed, 12 Oct 2005 10:32:12 -0400
From: Cyrus Daboo <[email-masked]>
To: Mike Douglass <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Subscriptions, free/busy etc

Hi Mike,
Some comments. Note that I am going to express my own bias here which is 
towards a central client preferences server solution since that is how I 
did all this in Mulberry using IMSP & ACAP. Admittedly email is accessed 
and managed differently than calendar data so analogies between mailbox 
subscriptions and calendar subscriptions may not be completely valid, but 
still I think there are enough similarities that it is worth doing.

--On October 12, 2005 10:02:22 AM -0400 Mike Douglass <[email-masked]> 
wrote:

> 1. More of a convenience - I can set up my view of the world at some
> central location and all my clients will have the same view.

In theory. However, you really need to be very explicit as to what this 
subscription behaviour is meant to me. For example, in the IMAP world there 
are SUBSCRIBE'd mailboxes. However, clients have taken many different views 
as to what that is actually supposed to me. Some automatically subscribe 
users to all mailboxes they think are 'personal' mailboxes. Others assume 
that subscribed mailboxes should always be checked for new mail. Others use 
it as simply a way to emphasis certain mailboxes in their display.

> 2. Perhaps a variant of 1 - how do I synch external devices to my full
> calendar view? via for example synchml

A smart CalDAV<->SyncML solution will need to allow users to specify a list 
of calendars to actually sync to, and it will aggregate all those calendars 
into one effective 'view' for SyncML purposes. In this case some type of 
'sync_calendars' property on the user principal in CalDAV might do. Note 
however, that the ser of calendars I might want to sync may be different 
from the set of calendars I want to display on my mobile device. Some I 
think there would be a need to identify different 'types' of subscription:

1) 'View' subscription - these are all the calendars I want to see 
overlayed on my desktop client
2) 'Mobile' subscription - these are all the calendars I want to see and 
sync to on my mobile device.
3) 'Free Busy' subscription - these are all the calendars that indicate my 
free-busy time.

> 3. How do I make my free/busy time available to someone if it depends
> upon a calendar I'm subscribed to?

The calendar-schedule portion of CalDAV will have to define that. i.e. an 
iTIP request for free-busy time on the CalDAV server is going to have to 
know which calendars of the calendar user are appropriate. This will likely 
need the 'free busy' type subscription list.

> I understand Bernards point that we the calendars may not all be on the
> same server - at the extreme none of them need be. From a practical point
> of view however, subscriptions are very important and perhaps deserve
> central support.

They can be centrally supported if clients support a central preferences 
store and we define a schema for calendar client preferences on that store. 
XCAP could easily provide that solution and go beyond just the 
'subscription' preferences - e.g. the choice of which colour to use to 
display each subscribed calendars is also a preference one would like to 
carry over from one client to another.

> Students have their own personal calendars. They are subscribed to a
> calendar which provides their class schedule. Their free/busy time is
> certainly an amalgam of that and any other events they choose to add.

OK, as soon as you add shared calendars into this, all bets are off because 
iCalendar really does not support shared calendars in any practical way. 
i.e. it is not possible for one 'subscriber' of a calendar to indicate that 
they are attending one event independently of another 'subscriber'. i.e. 
there are no per-user options for the TRANSP property. Really per-user 
options are going to be required to support this, not just at the calendar 
level but at the event level - i.e. the subscription mechanism needs to 
allow subscription to individual events within a calendar.

The question is whether something like this can be accomplished using 
iCalendar extension or whether it should be done as part of CalDAV (i.e. 
WebDAV properties). In either case it is going to require some sort of 
extension to the base to provide per-user properties of some sort.

> Faculty have multiple calendars - consultation times, teaching times,
> personal information. Free/busy is an aggregation of that. For meetings
> others need to see the results after including all calendar information.
>
> If we make subscriptions a client side only feature how do we get a true
> free/busy report for somebody else?

calendar-schedule will take care of that.

The other point to bear in mind here is that you are making assumption on 
how clients are going to organize their display to the user. Certainly in 
the email world there are many different ways that that has been done, and 
client authors will likely want to be flexible in terms of what they do 
based on their own requirements for the service they are providing.

So in the end I'm not sure that the 'view' type of subscriptions are going 
to be useful - certainly the free-busy issue has to be taken care of and 
hopefully calendar-schedule will do that.

-- 
Cyrus Daboo

Date: Wed, 12 Oct 2005 10:02:22 -0400
From: Mike Douglass <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Subscriptions, free/busy etc

I'll attempt to articulate some of my thoughts on subscriptions and I 
think at this stage I have more questions than otherwise.

The following reasons for some server side support of subscriptions come 
to mind

1. More of a convenience - I can set up my view of the world at some 
central location and all my clients will have the same view.

2. Perhaps a variant of 1 - how do I synch external devices to my full 
calendar view? via for example synchml

3. How do I make my free/busy time available to someone if it depends 
upon a calendar I'm subscribed to?

I understand Bernards point that we the calendars may not all be on the 
same server - at the extreme none of them need be. From a practical 
point of view however, subscriptions are very important and perhaps 
deserve central support.

Some examples from the educational world.

Students have their own personal calendars. They are subscribed to a 
calendar which provides their class schedule. Their free/busy time is 
certainly an amalgam of that and any other events they choose to add.

Faculty have multiple calendars - consultation times, teaching times, 
personal information. Free/busy is an aggregation of that. For meetings 
others need to see the results after including all calendar information.

If we make subscriptions a client side only feature how do we get a true 
free/busy report for somebody else?

On the other hand I agree it's asking a bit much for a server to support 
subscriptions to other calendar systems (unless they were caldav).

So is it fair to say that the only agent capable of getting a full 
dynamically created free/busy report is a client configured by the user?

And if that is so should we not support some feature which allows a user 
to publish their free/busy time?

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Mon, 03 Oct 2005 23:11:16 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-08.txt]
Cc: CalDAV DevList <[email-masked]>

Brian Moseley wrote:

 > Bernard Desruisseaux wrote:
 >
 >>    c.  Removed XML elements CALDAV:calendar-data-only.
 >
 >
 > why?

We have specified in section 4.2 that "Calendar collections
MUST only contain calendar object resources", as such this
element is now useless.

 >
 >>    d.  Removed resource type CALDAV:calendar-home.
 >
 >
 > why?

We could not justify a new resource type for calendar home.

Initially we thought that it would be useful to identify WebDAV
collections containing one or more calendar collections with a
new resource type, but given that we didn't want to force calendar
collections to always be contained in calendar home collections we
figured that CalDAV clients willing to browse a CalDAV server to
find calendar data would simply look for collections with the
CALDAV:calendar resource type...

Note that principal resources still have a CALDAV:calendar-home-set
property.

 >
 >>    j.  Changed the CALDAV:calendar-component-restriction-set and CALDAV:
 >>        calendar-restriction properties to always be protected.
 >
 >
 > yay!
 > _______________________________________________
 > Ietf-caldav mailing list -- [email-masked]
 > See http://ietf.webdav.org/caldav/ for more CalDAV resources
 > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Mon, 03 Oct 2005 18:43:23 -0700
From: Brian Moseley <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-08.txt]

Bernard Desruisseaux wrote:

>    c.  Removed XML elements CALDAV:calendar-data-only.

why?

>    d.  Removed resource type CALDAV:calendar-home.

why?

>    j.  Changed the CALDAV:calendar-component-restriction-set and CALDAV:
>        calendar-restriction properties to always be protected.

yay!

Date: Mon, 03 Oct 2005 21:35:13 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Calsify WG <[email-masked]>, WebDAV WG <[email-masked]>
Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-08.txt]

This is a multi-part message in MIME format.
--------------030201060504080201040300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

We submitted CalDAV draft -08 to the IETF last Friday.
It is now available at the following URL:

http://www.ietf.org/internet-drafts/draft-dusseault-caldav-08.txt

We are planning to submit a new revision in a few weeks for
an informal Last-Call on the ietf-caldav, ietf-calsify and
w3c-dist-auth (WebDAV) mailing lists before we actually submit
it to the IESG.

Please review the draft and send us feedback/questions/comments.

Thanks,
Bernard

B.1.  Changes in -08

    a.  Removed statement that said that client SHOULD always request
        DAV:getetag in calendar REPORTs.

    b.  Removed redefiniton of DAV:response.

    c.  Removed XML elements CALDAV:calendar-data-only.

    d.  Removed resource type CALDAV:calendar-home.

    e.  Moved the CALDAV:calendar-data element in the DAV:prop element in
        requests, and in the DAV:propstat element in responses.

    f.  Further defined the request body of MKCALENDAR to allow clients
        to set properties at calendar collection creation time.

    g.  Renamed CALDAV:calendar-home-URL to CALDAV:calendar-home-set

    h.  Clarified the fact that calendar collections may only contain
        calendar object resources and ordinary collections.

    i.  Clarified that calendar REPORTs should only be applied to
        calendar object resources contained in calendar collections.

    j.  Changed the CALDAV:calendar-component-restriction-set and CALDAV:
        calendar-restriction properties to always be protected.

    k.  Changed to use existing postcondition DAV:needs-privileges
        instead of a new CALDAV:insufficient-privilege postcondition.

    l.  Added example for limit-recurrence-set.

    m.  Added example for expand-recurrence-set.

    n.  Moved CALDAV:calendar-address-set in the calendar-schedule draft
        and renamed it to CALDAV:calendar-user-address-set.

    o.  Added guidelines on attachments and alarms.

-------- Original Message --------
Subject: I-D ACTION:draft-dusseault-caldav-08.txt
Date: Mon, 03 Oct 2005 15:50:02 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Calendaring Extensions to WebDAV (CalDAV)
	Author(s)	: L. Dusseault, et al.
	Filename	: draft-dusseault-caldav-08.txt
	Pages		: 75
	Date		: 2005-10-3
	
This document specifies a set of methods, headers, message bodies,
    properties, and reports that define calendar access extensions to the
    WebDAV protocol.  The new protocol elements are intended to make
    WebDAV-based calendaring and scheduling an interoperable standard
    that supports calendar access, calendar management, calendar sharing,
    and calendar publishing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-08.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-dusseault-caldav-08.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-dusseault-caldav-08.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.

--------------030201060504080201040300
Content-Type: Message/External-body;
 name="draft-dusseault-caldav-08.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-dusseault-caldav-08.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

nt-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------030201060504080201040300--

Date: Mon, 03 Oct 2005 16:12:36 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>, Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] New xCal draft sent to the IETF

This is a cryptographically signed message in MIME format.

--------------ms070405090106090606080503
Content-Type: multipart/mixed; boundary="------------080503040904020800040207"

This is a multi-part message in MIME format.
--------------080503040904020800040207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I have sent -02 of xCal to the IETF, copies at:

	http://inet-consulting.com/draft-royer-calsch-xcal-02.txt
	http://inet-consulting.com/draft-royer-calsch-xcal-02.html
	http://inet-consulting.com/draft-royer-calsch-xcal-02.xml

Namespace to urn:ietf:params:xml:ns:xcal

I removed unneeded namespace prefixes in examples.

The iCalendar LANGUAGE parameter is now xml:lang

I specified, standard XML encoding, rather than
specifically sayiing 'entity' encoding.

I updated the XSLT (xml -> iCal translator) on SourceForge
(http://sourceforge.net/projects/icalendar/) to translate
xml:lang -> LANGUAGE.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------080503040904020800040207
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------080503040904020800040207--

--------------ms070405090106090606080503
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070405090106090606080503--

Date: Mon, 03 Oct 2005 13:26:16 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Error in link to Timezone Questionnaire Results Document
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------000503080709050700050703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I made an error in transcribing the URL to the Timezone Questionnaire 
Results document in my previous posting.  The correct link is:

http://www.calconnect.org/publications/resultsfromtimezonequestionnairev1.0.pdf.

You may also retrief the document by going to http://www.calconnect.org 
and selecting "Work Products" from the sidebar.

Apologies,

Dave Thewlis
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------000503080709050700050703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I made an error in transcribing the URL to the Timezone Questionnaire
Results document in my previous posting.&nbsp; The correct link is: <br>
<br>
<a
 href="http://www.calconnect.org/publications/resultsfromtimezonequestionnairev1.0.pdf">http://www.calconnect.org/publications/resultsfromtimezonequestionnairev1.0.pdf</a>.<br>
<br>
You may also retrief the document by going to <a
 href="http://www.calconnect.org">http://www.calconnect.org</a> and
selecting "Work Products" from the sidebar.<br>
<br>
Apologies,<br>
<br>
Dave Thewlis<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

--------------000503080709050700050703--

Date: Mon, 03 Oct 2005 12:41:40 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Results from CalConnect Timezone Questionnaire
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------090301050308080900000205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

TC-TIMEZONE, the TIMEZONE Technical Committee of the Calendaring and 
Scheduling Consortium, has published the results of the Timezone 
Questionnaire it conducted earlier
this year. The document is available on the CalConnect web site at 
http://www.calconnect.org/publications/resultsfrom 
timezonequestionnairev1.0.pdf 
<http://www.calconnect.org/publications/caldavusecasesv1.0.pdf> or by 
going to http://www.calconnect.org and selecting "Work Products" from 
the sidebar index.

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------090301050308080900000205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
TC-TIMEZONE, the TIMEZONE Technical Committee of the Calendaring and
Scheduling Consortium, has published the results of the Timezone
Questionnaire it conducted earlier<br>
this year. The document is available
on the CalConnect web site at <a
 href="http://www.calconnect.org/publications/caldavusecasesv1.0.pdf">http://www.calconnect.org/publications/resultsfrom
timezonequestionnairev1.0.pdf</a>
or by going to <a href="http://www.calconnect.org">http://www.calconnect.org</a>
and selecting "Work Products" from the sidebar index.<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

--------------090301050308080900000205--