X-Envelope-From: danw@novell.com X-Envelope-To: Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8TGh7Bm000565 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 29 Sep 2004 09:43:09 -0700 Received: (qmail 8093 invoked from network); 29 Sep 2004 16:43:00 -0000 Received: from localhost (HELO twelve-monkeys.boston.ximian.com) (127.0.0.1) by localhost with SMTP; 29 Sep 2004 16:43:00 -0000 From: Dan Winship To: ietf-caldav@osafoundation.org Content-Type: text/plain Date: Wed, 29 Sep 2004 12:41:06 -0400 Message-Id: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] comments on -02 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 16:43:13 -0000 Simple typos: "calenadr" in 4.1, "calendards" in 5.2, "apper" in 14.3 > 4.2 Recurrence and the Data Model How/where are "detached" instances of a recurrence represented? Eg, if I change the SUMMARY of one instance of a meeting, does that require creating a new resource (with the same UID as an existing resource)? > 4.3 CalDAV and timezones This feels like it presupposes a certain calsify outcome... > 4.4 Scheduling, Fanout and the Data model > The Inbox contains inbound iTIP messages long after they are > handled/seen by the user OK. How long? > CalDAV defines an iTIP Outbox collection... In email clients and real life, an outbox/"out box" is for things that are on their way out. The CalDAV Outbox stores things that have *already* gone out. Seems weird, but I don't know if this is going to annoy anyone but me. :) > Two users coordinating scheduling with one calendar (e.g. a calendar > user and her assistant) can see what scheduling messages the other > user has sent. But does that actually tell them what they want to know? Wouldn't it would be better to look in the calendar folder instead? * If some invitees have already responded to the invite, the copy of the event in the calendar will show updated PARTSTATs, but the copy in the Outbox won't. * If the other user made changes to the event after first scheduling it (eg, added an attendee who was forgotten in the original invite), that will be reflected all in one place in the calendar folder, but the information would be split across multiple separate Outbox messages. * If a meeting was scheduled entirely via iMIP (perhaps because it was received as a REQUEST from a non-CalDAV user), then it will appear in the calendar, but not in the Outbox. Another problem is that the Outbox doesn't record the responses to the SCHEDULE request. So you might see an invite that appears to have been sent to several people, when in fact the server returned a 502 for every Recipient. > However, the server MAY be configured (how is not defined here) to > auto-accept or auto-reject invitations, and if the server > auto-accepts invitations then the server is responsible for creating > VEVENT resources in the user's calendar. ("VEVENT" is wrong here, it might be automatically accepting VTODOs too.) If the spec is going to explicitly allow servers to do this, it should specify how the client is expected to behave in such a situation. How does a client determine if the server has already processed an invitation? And is the server allowed (or REQUIRED) to process it *before* putting it in the Inbox, to avoid a race condition? > 5.2 Calendars Collection > A WebDAV collection which corresponds to a single calendar or VAGENDA > is a Calendar. VAGENDA is a CAP-ism. RFC 2445 has only VCALENDARs. > It MUST contain one event collection Any reason for that? What if a system wants to support just todo data? (Eg, a bug-tracking system could export your bugs as tasks.) > and one alarm collection. That's wrong now, right? > 5.3 Event Collection > and each one contains exactly one VEVENT or VFREEBUSY object. Do we really want static VFREEBUSY objects? > 5.7 iTIP Outbox Collection > Every non-collection resource in the scheduling collection is > considered to be a REQUEST or REPLY. No COUNTER, DECLINE-COUNTER, etc? > 6. Creating Resources Why not just say that the client should use POST (to the collection URL) rather than PUT, and let the server generate an object URL? > 7. Users and Groups > > The WebDAV ACL specification requires that any principal to whom > permissions can be represented via a WebDAV resource (complete with > WebDAV properties and a HTTP URL). Something is missing in that sentence. (s/can be represented/can be granted can be represented/ ?) > 9. Scheduling and Fanout > In other words, the server MUST handle fanout if requested I think that sentence predates the calendar-schedule capability... the section probably needs a little rewriting > CalDAV servers that return the value "calendar-schedule" in the DAV > response header MUST support iTIP to send and receive scheduling > requests as well as reply to scheduling request. Outgoing iTIP > messages MUST be submitted to an iTIP Outbox collection. Who is being MUSTed in the second sentence? The paragraph starts out talking about servers, but servers don't submit things to Outboxes. And if it means "Clients MUST submit outgoing iTIP messages to an iTIP Outbox collection", that would imply they weren't allowed to do iMIP, which also sounds wrong. > Incoming iTIP messages MUST be delivered to an iTIP Inbox collection. Another dangling MUST. > 9.1 SCHEDULE Method for WebDAV > The list of attendees and the organizer information in this request > body might well be redundant with the values of the Recipient and > Originator headers. This is intentional, so that the client can have > more control over who receives invitations and who sends them: I think each of the three examples you give is redundant with existing iCalendar/iTIP functionality: > o The client may send invitations to calendar users not on the > attendee list (for example, to an assistant, caterer, observer, > etc). They could also be listed as ATTENDEEs with ROLE=NON-PARTICIPANT. > o The client may choose not to send invitations to calendar users > who are on the attendee list (for example, attendees who have been > scheduled through an out-of-band mechanism). Maybe they could just be listed with PARTSTAT=ACCEPTED? (Maybe not...) > o The originator may be different than the organizer, for example an > assistant who has calendar-bind privileges on the organizer's > calendar. You can specify that with the SENT-BY property on the ORGANIZER. > 9.1.1 Status Codes for use with 207 (Multi-Status) Tying back to the Outbox comments earlier, does every successful SCHEDULE result in a message being appended to Outbox, even when every Recipient fails? Need a little more discussion of the exact scheduling flow. Section 9 mentions "(c) a new method requests fanout of a resource that has already been uploaded", but the description of SCHEDULE itself doesn't mention ordering at all, which it probably should. (If you do SCHEDULE first, then PUT, there's a race condition in that someone else's REPLY could come in before you PUT the event they're REPLYing to, especially if there are auto-accepting/rejecting resources on the system.) OTOH, what's the advantage in doing a PUT to the calendar followed by a SCHEDULE to the Outbox, rather than just doing a SCHEDULE to the calendar? > 202 (Accepted) - The request was accepted, but the server has not > performed any action with it yet. What happens if the server returns a 202 and is then unable to complete the transaction? (Presumably if it *knew* it was going to be able to succeed, it would have just returned a 200 instead.) Eg, it might return a 202 if it forwards the request to a remote user via iMIP, but then what happens if the iMIP message bounces? There doesn't seem to be any way for the server to inform the client of that. > 507 (Insufficient Storage) - The server did not have sufficient space > to record the iTIP message. "in the Recipient's iTIP Inbox". Presumably if the Originator is over quota, the SCHEDULE would get back a top-level 507 rather than a 207. > 9.2.1 Example - Retrieve incoming iTIP Message The example has an "Originator" header in the response. Is that a bug? If not, something needs to say explicitly somewhere that that information is preserved. (And that the Recipient information isn't? What about in the copy in Outbox?) > 13. CalDAV Principal Properties Many of these properties would be useful (or maybe even necessary) for resource-type calendars as well, which (according to section 12) wouldn't have any principal associated with them. Is there any reason these couldn't be defined on the Calendar or Calendar Container instead of the Principal? > 13.3 itip-inbox-URL Property > 13.4 itip-outbox-URL Property Both of these are multi-valued... is there any particular behavior expected of clients in the presence of multiple Inboxes or Outboxes? (If not, then why can you have more than one?) > 14.3 calendar-bind Privilege > Recipient header. The SCHEDULE request If the server's calendar-bind > privilege check fails for a given inbox, the rest of the SCHEDULE I think the "The SCHEDULE request " there is a cut+pasto. > 15.1 calendar-time-range Report Need to clarify how free/busy works in CalDAV (probably with an explicit example). Do you have to request the Vfreebusy component-filter? What does the response data look like? The text sort of implies that view- free-busy gives you the ability to ask for and see the dtstart and dtend of VEVENTs, as opposed to just asking for a time range and getting back a VFREEBUSY object containing anonymous time ranges. If the response uses VFREEBUSY, are BUSY-TENTATIVE and BUSY-UNAVAILABLE periods ever used? (Perhaps the server MAY return BUSY-TENTATIVE periods corresponding to unprocessed invites, and MAY allow the user to mark a time period BUSY-UNAVAILABLE?) > 15.1.2 Response to 'calendar-time-range' > The response to this report is a WebDAV Multi-Status response, > containing one element for each event AND for each > recurrence. This differs from the PROPFIND response to an event > collection only in that the relevant recurrences each have their own > element, not just the master event. That's sort of ambiguous about whether or not the master event is returned. -- Dan X-Envelope-From: daboo@isamet.com Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8TEopBm025021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Sep 2004 07:50:54 -0700 Received: from [10.0.1.5] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i8TESKo3005540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Sep 2004 10:28:21 -0400 Date: Wed, 29 Sep 2004 10:50:45 -0400 From: Cyrus Daboo To: TimHare@comcast.net, Lisa Dusseault , CalDAV DevList Subject: Re: [Ietf-caldav] Questions on use cases Message-ID: In-Reply-To: <6.1.1.1.0.20040928200326.02804eb0@mail.comcast.net> References: <49CF7500-1194-11D9-A678-000A95B2BB72@osafoundation.org> <6.1.1.1.0.20040928200326.02804eb0@mail.comcast.net> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 14:51:01 -0000 Hi TimHare@comcast.net, --On Tuesday, September 28, 2004 8:16 PM -0400 TimHare@comcast.net wrote: > My favorite candidate for 'helper application', which I once wrote on > OfficeVision/MVS, a mainframe e-mail/calendaring system, is 'NEXT'. All > this helper does is look at your calendar and tell you either your next > event, or the meeting you are currently supposed to be in, if the current > time is within a certain amount of the start time. This would be helped > by having DTSTART, at the least, be something searchable. The question is whether you would want to get that info via webdav properties or via a webdav REPORT. There will be a 'time-range' report in caldav that you could use to get the same information. > Alarms without VEVENTs or VTODOs might as well be relegated to cron jobs > in my opinion - what would be the point of an alarm that goes off just > because it's "that time"? If you want a reminder without revealing what > it is ("time to check Ebay!") leave the text out of the VTODO/VEVENT. We are not talking about alarms that operate without any reference to a VEVENT, but rather the ability to store alarms separately from VEVENTs, but have them linked backed to the VEVENT in some way (e.g. via a webdav property containing the URL to the event(s)). Lisa's example of having a 'library' of standard alarms is one case where that would be useful. The other is being able to provide per-user private alarms on shared events (e.g. user A wants an alarm 5 minutes before, user B wants one 10 minutes before). That is hard to do when the alarm data is embedded in the event data or when users don't have write access to the event but still want to have an alarm for it. So what are the expected use cases for alarms, particularly in the shared calendar case? Do we want to allow per-user private alarms? -- Cyrus Daboo X-Envelope-From: TimHare@comcast.net Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8T0JCBl018436; Tue, 28 Sep 2004 17:19:12 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc12) with SMTP id <2004092900190301200qrr28e> (Authid: TimHare); Wed, 29 Sep 2004 00:19:04 +0000 Message-Id: <6.1.1.1.0.20040928200326.02804eb0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 28 Sep 2004 20:16:38 -0400 To: Lisa Dusseault , CalDAV DevList From: TimHare@comcast.net Subject: Re: [Ietf-caldav] Questions on use cases In-Reply-To: <49CF7500-1194-11D9-A678-000A95B2BB72@osafoundation.org> References: <49CF7500-1194-11D9-A678-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.39 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 00:19:13 -0000 My favorite candidate for 'helper application', which I once wrote on OfficeVision/MVS, a mainframe e-mail/calendaring system, is 'NEXT'. All this helper does is look at your calendar and tell you either your next event, or the meeting you are currently supposed to be in, if the current time is within a certain amount of the start time. This would be helped by having DTSTART, at the least, be something searchable. Alarms without VEVENTs or VTODOs might as well be relegated to cron jobs in my opinion - what would be the point of an alarm that goes off just because it's "that time"? If you want a reminder without revealing what it is ("time to check Ebay!") leave the text out of the VTODO/VEVENT. At 05:20 PM 9/28/04, Lisa Dusseault wrote: >Bernard, Cyrus & I have had a chance to discuss alarms, property promotion >and scheduling some more, and while we have some opinions based on our own >respective products, it would be nice to get a wider set of use cases. > >Alarms: The use cases around alarms should help us decide whether each >VALARM is "hidden" inside the body of a VEVENT resource, or if alarms are >available as properties on VEVENT resources, or as standalone resources. > - What are the ways clients want to use alarms? > - Is an alarm always treated as part of an event? > - Are there clients (actual, planned or envisioned) which would use > alarms and not use the rest of the event/todo? > - Do clients conceptually "reuse" alarms? E.g. practically all my > alarms could be factored down to one alarm "produce alert and basso sound > 15 min before event start". In other words, most of my VEVENTs could all > link to the same VALARM if it were not a subcomponent, but I'm not sure > that would be useful. > >Property Promotion: My original design for property promotion assumed >that there would be clients that relied on properties heavily or >exclusively. Clients could browse via properties before going to the step >of downloading the iCalendar body, or perhaps even do without the body >entirely. However, it's become clear that making the iCalendar body fully >redundant is hard. We'd have to deal with custom iCalendar properties, >with alarm sub-components, with multi-valued properties like attendees, >and with large properties like attachments. How worthwhile is it? Should >we head towards full property promotion, or towards zero property >promotion, or is there some middle ground that actually improves life for >clients? Some of the questions to feed into this: > - Are any clients planning to use WebDAV properties for anything > besides getting the ETag to do synchronization? How would you use properties? > - Does every client plan to have a full iCalendar parser? I know that > traditional full "calendar client" software will probably have a full > iCalendar parser anyway, but are there helper applications that could do > features with only a subset of the iCalendar information? >E.g. a helper application that only cares about start/end times? > - Use cases for WebDAV custom properties? > >Scheduling: The content in the draft -02 describing scheduling isn't >complete, yet it is probably fairly illustrative of one possible >approach. What are your initial thoughts? Does anybody have very >important use cases that this approach completely fails to address? > >Thanks for your input and help in advance, > >Lisa >_______________________________________________ >Ietf-caldav mailing list >Ietf-caldav@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8SLLABm001111 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 28 Sep 2004 14:21:10 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <49CF7500-1194-11D9-A678-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: CalDAV DevList From: Lisa Dusseault Date: Tue, 28 Sep 2004 14:20:57 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] Questions on use cases X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 21:21:11 -0000 Bernard, Cyrus & I have had a chance to discuss alarms, property promotion and scheduling some more, and while we have some opinions based on our own respective products, it would be nice to get a wider set of use cases. Alarms: The use cases around alarms should help us decide whether each VALARM is "hidden" inside the body of a VEVENT resource, or if alarms are available as properties on VEVENT resources, or as standalone resources. - What are the ways clients want to use alarms? - Is an alarm always treated as part of an event? - Are there clients (actual, planned or envisioned) which would use alarms and not use the rest of the event/todo? - Do clients conceptually "reuse" alarms? E.g. practically all my alarms could be factored down to one alarm "produce alert and basso sound 15 min before event start". In other words, most of my VEVENTs could all link to the same VALARM if it were not a subcomponent, but I'm not sure that would be useful. Property Promotion: My original design for property promotion assumed that there would be clients that relied on properties heavily or exclusively. Clients could browse via properties before going to the step of downloading the iCalendar body, or perhaps even do without the body entirely. However, it's become clear that making the iCalendar body fully redundant is hard. We'd have to deal with custom iCalendar properties, with alarm sub-components, with multi-valued properties like attendees, and with large properties like attachments. How worthwhile is it? Should we head towards full property promotion, or towards zero property promotion, or is there some middle ground that actually improves life for clients? Some of the questions to feed into this: - Are any clients planning to use WebDAV properties for anything besides getting the ETag to do synchronization? How would you use properties? - Does every client plan to have a full iCalendar parser? I know that traditional full "calendar client" software will probably have a full iCalendar parser anyway, but are there helper applications that could do features with only a subset of the iCalendar information? E.g. a helper application that only cares about start/end times? - Use cases for WebDAV custom properties? Scheduling: The content in the draft -02 describing scheduling isn't complete, yet it is probably fairly illustrative of one possible approach. What are your initial thoughts? Does anybody have very important use cases that this approach completely fails to address? Thanks for your input and help in advance, Lisa X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8RLOgBm027886 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Sep 2004 14:24:43 -0700 In-Reply-To: <6.1.1.1.0.20040921222859.027f1970@mail.comcast.net> References: <6.1.1.1.0.20040921222859.027f1970@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/alternative; boundary=Apple-Mail-1--98523782 Message-Id: From: Lisa Dusseault Subject: Re: [Ietf-caldav] Question on caldav-02.txt Date: Mon, 27 Sep 2004 14:24:36 -0700 To: TimHare@comcast.net X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 21:24:44 -0000 --Apple-Mail-1--98523782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Thanks, I propose clearing this up for now by removing the offending=20 sentence in 5.3. The model assumption, for now, is that putting all events in the same=20 collection should make it easier for clients to figure out what's on=20 somebody else's calendar. Lisa On Sep 21, 2004, at 7:32 PM, TimHare@comcast.net wrote: > In 5.2 it says a calendar should contain no more than one events=20 > collection: > > > > > > It MUST NOT contain more than one of any > >=A0=A0 of these specific collections, although > > > > > In 5.3 it says a client must be able to handle multiple events=20 > collections: > > > > > > Clients MUST be > >=A0=A0 prepared to identify and navigate multiple event > collections within a > >=A0=A0 Calendar > > > > > This seems contradictory to me, and possibly needs clearing up? > > > Tim Hare > Interested Bystander, Non-Inc. > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav --Apple-Mail-1--98523782 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=ISO-8859-1 Thanks, I propose clearing this up for now by removing the offending sentence in 5.3. The model assumption, for now, is that putting all events in the same collection should make it easier for clients to figure out what's on somebody else's calendar. Lisa On Sep 21, 2004, at 7:32 PM, TimHare@comcast.net wrote: In 5.2 it says a calendar should contain no more than one events collection: > > It MUST NOT contain more than one of any >=A0=A0 of these specific collections, although > In 5.3 it says a client must be able to handle multiple events collections: > > Clients MUST be >=A0=A0 prepared to identify and navigate multiple event collections within a >=A0=A0 Calendar > This seems contradictory to me, and possibly needs clearing up? Tim Hare Interested Bystander, Non-Inc.=20 _______________________________________________ Ietf-caldav mailing list Ietf-caldav@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-caldav = --Apple-Mail-1--98523782-- X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8M2YLBl002261 for ; Tue, 21 Sep 2004 19:34:21 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc12) with SMTP id <2004092202341501400bp480e> (Authid: TimHare); Wed, 22 Sep 2004 02:34:16 +0000 Message-Id: <6.1.1.1.0.20040921222859.027f1970@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 21 Sep 2004 22:32:21 -0400 To: ietf-caldav@osafoundation.org From: TimHare@comcast.net Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] Question on caldav-02.txt X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 02:34:22 -0000 In 5.2 it says a calendar should contain no more than one events collection:

>
> It MUST NOT contain more than one of any
>   of these specific collections, although
>

In 5.3 it says a client must be able to handle multiple events collections:

>
> Clients MUST be
>   prepared to identify and navigate multiple event
collections within a
>   Calendar
>

This seems contradictory to me, and possibly needs clearing up?

Tim Hare
Interested Bystander, Non-Inc. X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8LKRIBm022172 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 21 Sep 2004 13:27:18 -0700 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i8LKM2Qw021593 for ; Tue, 21 Sep 2004 13:22:02 -0700 (PDT) Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i8LKRBeB001767; Tue, 21 Sep 2004 14:27:11 -0600 Received: from oracle.com (bdesruis-ca.ca.oracle.com [144.23.213.225]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i8LKRAvt001724; Tue, 21 Sep 2004 14:27:10 -0600 Message-ID: <41508E98.9080301@oracle.com> Date: Tue, 21 Sep 2004 16:27:04 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Content-Type: multipart/mixed; boundary="------------010109000808010008060100" X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-02.txt] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2004 20:27:19 -0000 This is a multi-part message in MIME format. --------------010109000808010008060100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-dusseault-caldav-02.txt Date: Tue, 21 Sep 2004 15:38:09 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Calendar Server Extensions for WebDAV (CalDAV) Author(s) : L. Dusseault, et al. Filename : draft-dusseault-caldav-02.txt Pages : 55 Date : 2004-9-21 In the five years since WebDAV [3] was standardized, at least three groups have used WebDAV as a basis to provide Internet calendar access with a minimum of development effort. However, each group decided independently how the calendaring data model would map to the WebDAV data model and how to deal with features such as recurrance and queries for free-busy times. This draft proposes a standard data model mapping and a few extensions to WebDAV that make WebDAV-server-based calendaring work well for clients while requiring a minimum of new work (particularly on clients). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-02.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-dusseault-caldav-02.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. --------------010109000808010008060100 Content-Type: Message/External-body; name="draft-dusseault-caldav-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-dusseault-caldav-02.txt" Content-Type: text/plain Content-ID: <2004-9-21153111.I-D@ietf.org> --------------010109000808010008060100 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/BDESRU%7E1.STE/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/BDESRU%7E1.STE/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------010109000808010008060100-- X-Envelope-From: harrie@inet.it Received: from mid-1.inet.it (mid-1.inet.it [213.92.5.18]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8F78Xpo020451; Wed, 15 Sep 2004 00:08:34 -0700 Received: from hhazewinkel.inet.it [::ffff:213.92.1.191] by mid-1.inet.it via I-SMTP-5.1.13-51A id ::ffff:213.92.1.191+xXQvG7k3PpH1; Wed, 15 Sep 2004 09:08:27 +0200 Message-ID: <4147EA66.3070305@inet.it> Date: Wed, 15 Sep 2004 09:08:22 +0200 From: Harrie Hazewinkel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR References: <122A4AE0-069F-11D9-9C6B-000A95B2BB72@osafoundation.org> In-Reply-To: <122A4AE0-069F-11D9-9C6B-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 07:08:35 -0000 Lisa Dusseault wrote: > Some broader input would be nice on an issue I've been looking at out of > band... > > - If the CalDAV VEVENT resources (the resource that corresponds to a > simple event) is of type "text/calendar", then it has to have > BEGIN:VCALENDAR and END:VCALENDAR as a wrapper. > - If that wrapper exists on every single CalDAV resource it's a bit of > constant redundant overhead. I agree her that it would be redundant. I have build here in I.Net a prototype of a SyncML -based synchronization server for our calendar server (CAP-based) and all mobile devices wrap for synchronization the VEVENT in a VCALENDAR. On its won no real problem, it is required by mime-type. From a synchronization server implementation I handle internally only the VEVENTs. I do this for conversion/comparison. SyncML is 'item' oriented and most mobile devices do not combine multiple VEVENTs as a single item. From the CAP side I can get a number of VEVENTS in a single request. Therefore, I had the choice patch up all (multiple enclosed VEVENTS from the CAP side of strip the 'wrapping' of the 'item' in the SYncML side. As you say it seems redundant and so the chcoie was made. > > It's not that much overhead, so if we have to keep it to be > backward-compatible I think we ought. The question is, do iCalendar > parsers today handle something that is text/calendar and doesn't begin > with BEGIN:VCALENDAR? Instead it would just start with BEGIN:VEVENT and > contain only one VEVENT. In other words, how forgiving are existing > iCalendar parsers in this respect? It depends I guess, we use the freeassociation/libical from sourceforge. That library is able to make directly VEVENTS from strings. Honestly, I believe that many implementation can do that. It sounds to me reasonable, because the applications must be able to manipulate the VEVENT. However, you have to realize the amount of devices out there that handle calendar parts. That grows quickly, since almost every mobile telephone has a calendar nowadays. Harrie X-Envelope-From: daboo@isamet.com Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8F2ecpp001115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Sep 2004 19:40:40 -0700 Received: from [10.0.1.3] (pool-141-158-116-239.pitt.east.verizon.net [141.158.116.239]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i8F2KKo3021898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Sep 2004 22:20:23 -0400 Date: Tue, 14 Sep 2004 22:40:32 -0400 From: Cyrus Daboo To: TimHare@comcast.net, Lisa Dusseault Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR Message-ID: <94558FA1CA2B0A1A19787649@ninevah.local> In-Reply-To: <6.1.1.1.0.20040914211626.02864550@mail.comcast.net> References: <122A4AE0-069F-11D9-9C6B-000A95B2BB72@osafoundation.org> <6.1.1.1.0.20040914202703.028505d0@mail.comcast.net> <6970AD1F-06AF-11D9-9C6B-000A95B2BB72@osafoundation.org> <6.1.1.1.0.20040914211626.02864550@mail.comcast.net> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 02:40:42 -0000 Hi Tim, --On Tuesday, September 14, 2004 9:17 PM -0400 TimHare@comcast.net wrote: > Hmm perhaps there should be a collection for each type of METHOD - one > collection for PUBLISH items, another for scheduling REQUESTs, etc. I think that's dividing things too far. What we need is a single collection (Inbox) for all incoming iTIP requests - there would be a WebDAV property on the actual resources in the collection that exposes the method. -- Cyrus Daboo X-Envelope-From: TimHare@comcast.net Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8F1Hlpo017482; Tue, 14 Sep 2004 18:17:50 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc13) with SMTP id <20040915011741016005qfhee> (Authid: TimHare); Wed, 15 Sep 2004 01:17:41 +0000 Message-Id: <6.1.1.1.0.20040914211626.02864550@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 14 Sep 2004 21:17:14 -0400 To: Lisa Dusseault From: TimHare@comcast.net Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR In-Reply-To: <6970AD1F-06AF-11D9-9C6B-000A95B2BB72@osafoundation.org> References: <122A4AE0-069F-11D9-9C6B-000A95B2BB72@osafoundation.org> <6.1.1.1.0.20040914202703.028505d0@mail.comcast.net> <6970AD1F-06AF-11D9-9C6B-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.39 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 01:17:57 -0000 Hmm perhaps there should be a collection for each type of METHOD - one collection for PUBLISH items, another for scheduling REQUESTs, etc. At 08:37 PM 9/14/04, Lisa Dusseault wrote: >See, the thing is, there wouldn't be a method. These are being stored >somewhere, they're not requests. Will existing iCalendar parsers choke >if there's no method? > >I suppose if there had to be a method it would be PUBLISH, for events >stored in the user's calendar. Even if the event isn't being very widely >published, still that's the closest concept. > >Lisa > > >On Sep 14, 2004, at 5:29 PM, TimHare@comcast.net wrote: > >>I don't know how other parsers do it.. but the METHOD property in the >>BEGIN: VCALENDAR is an important piece of information: it tells you >>whether the object is PUBLISHed or is a REQUEST, REPLY, etc. METHOD only >>exists in the VCALENDAR component. If there is a way to "nest" objects >>within CalDAV then you can make do with only one VCALENDAR pair per >>grouping but otherwise I think you need it. >> >>At 06:40 PM 9/14/04, you wrote: >>>Some broader input would be nice on an issue I've been looking at out of >>>band... >>> >>> - If the CalDAV VEVENT resources (the resource that corresponds to a >>> simple event) is of type "text/calendar", then it has to have >>> BEGIN:VCALENDAR and END:VCALENDAR as a wrapper. >>> - If that wrapper exists on every single CalDAV resource it's a bit of >>> constant redundant overhead. >>> >>>It's not that much overhead, so if we have to keep it to be >>>backward-compatible I think we ought. The question is, do iCalendar >>>parsers today handle something that is text/calendar and doesn't begin >>>with BEGIN:VCALENDAR? Instead it would just start with BEGIN:VEVENT and >>>contain only one VEVENT. In other words, how forgiving are existing >>>iCalendar parsers in this respect? >>> >>>Lisa >>> >>>_______________________________________________ >>>Ietf-caldav mailing list >>>Ietf-caldav@osafoundation.org >>>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav >> >>Tim Hare >>Interested Bystander, Non-Inc. Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8F0hlpo013019 for ; Tue, 14 Sep 2004 17:43:47 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <20040915004341013001oj9le> (Authid: TimHare); Wed, 15 Sep 2004 00:43:41 +0000 Message-Id: <6.1.1.1.0.20040914204300.028647e0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 14 Sep 2004 20:43:09 -0400 To: ietf-caldav@osafoundation.org From: TimHare@comcast.net Subject: Fwd: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 00:43:47 -0000 >Date: Tue, 14 Sep 2004 20:29:25 -0400 >To: Lisa Dusseault >From: TimHare@comcast.net >Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain >BEGIN/END VCALENDAR > >I don't know how other parsers do it.. but the METHOD property in the >BEGIN: VCALENDAR is an important piece of information: it tells you >whether the object is PUBLISHed or is a REQUEST, REPLY, etc. METHOD only >exists in the VCALENDAR component. If there is a way to "nest" objects >within CalDAV then you can make do with only one VCALENDAR pair per >grouping but otherwise I think you need it. > >At 06:40 PM 9/14/04, you wrote: >>Some broader input would be nice on an issue I've been looking at out of >>band... >> >> - If the CalDAV VEVENT resources (the resource that corresponds to a >> simple event) is of type "text/calendar", then it has to have >> BEGIN:VCALENDAR and END:VCALENDAR as a wrapper. >> - If that wrapper exists on every single CalDAV resource it's a bit of >> constant redundant overhead. >> >>It's not that much overhead, so if we have to keep it to be >>backward-compatible I think we ought. The question is, do iCalendar >>parsers today handle something that is text/calendar and doesn't begin >>with BEGIN:VCALENDAR? Instead it would just start with BEGIN:VEVENT and >>contain only one VEVENT. In other words, how forgiving are existing >>iCalendar parsers in this respect? >> >>Lisa >> >>_______________________________________________ >>Ietf-caldav mailing list >>Ietf-caldav@osafoundation.org >>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > >Tim Hare >Interested Bystander, Non-Inc. Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8F0bSpp011207 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Sep 2004 17:37:29 -0700 In-Reply-To: <6.1.1.1.0.20040914202703.028505d0@mail.comcast.net> References: <122A4AE0-069F-11D9-9C6B-000A95B2BB72@osafoundation.org> <6.1.1.1.0.20040914202703.028505d0@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6970AD1F-06AF-11D9-9C6B-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR Date: Tue, 14 Sep 2004 17:37:24 -0700 To: TimHare@comcast.net X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 00:37:30 -0000 See, the thing is, there wouldn't be a method. These are being stored somewhere, they're not requests. Will existing iCalendar parsers choke if there's no method? I suppose if there had to be a method it would be PUBLISH, for events stored in the user's calendar. Even if the event isn't being very widely published, still that's the closest concept. Lisa On Sep 14, 2004, at 5:29 PM, TimHare@comcast.net wrote: > I don't know how other parsers do it.. but the METHOD property in the > BEGIN: VCALENDAR is an important piece of information: it tells you > whether the object is PUBLISHed or is a REQUEST, REPLY, etc. METHOD > only exists in the VCALENDAR component. If there is a way to "nest" > objects within CalDAV then you can make do with only one VCALENDAR > pair per grouping but otherwise I think you need it. > > At 06:40 PM 9/14/04, you wrote: >> Some broader input would be nice on an issue I've been looking at out >> of band... >> >> - If the CalDAV VEVENT resources (the resource that corresponds to a >> simple event) is of type "text/calendar", then it has to have >> BEGIN:VCALENDAR and END:VCALENDAR as a wrapper. >> - If that wrapper exists on every single CalDAV resource it's a bit >> of constant redundant overhead. >> >> It's not that much overhead, so if we have to keep it to be >> backward-compatible I think we ought. The question is, do iCalendar >> parsers today handle something that is text/calendar and doesn't >> begin with BEGIN:VCALENDAR? Instead it would just start with >> BEGIN:VEVENT and contain only one VEVENT. In other words, how >> forgiving are existing iCalendar parsers in this respect? >> >> Lisa >> >> _______________________________________________ >> Ietf-caldav mailing list >> Ietf-caldav@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > Tim Hare > Interested Bystander, Non-Inc. > X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8F0aspp011089 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 14 Sep 2004 17:36:58 -0700 Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i8F0aemq011914 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 14 Sep 2004 17:36:45 -0700 Message-ID: <41478E98.5050608@Royer.com> Date: Tue, 14 Sep 2004 18:36:40 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR References: <122A4AE0-069F-11D9-9C6B-000A95B2BB72@osafoundation.org> In-Reply-To: <122A4AE0-069F-11D9-9C6B-000A95B2BB72@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040307020808070503060904" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: CalDAV DevList List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 00:37:00 -0000 This is a cryptographically signed message in MIME format. --------------ms040307020808070503060904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Some broader input would be nice on an issue I've been looking at out > of band... > > - If the CalDAV VEVENT resources (the resource that corresponds to a > simple event) is of type "text/calendar", then it has to have > BEGIN:VCALENDAR and END:VCALENDAR as a wrapper. > - If that wrapper exists on every single CalDAV resource it's a bit > of constant redundant overhead. > > It's not that much overhead, so if we have to keep it to be > backward-compatible I think we ought. The question is, do iCalendar > parsers today handle something that is text/calendar and doesn't begin > with BEGIN:VCALENDAR? Instead it would just start with BEGIN:VEVENT > and contain only one VEVENT. In other words, how forgiving are > existing iCalendar parsers in this respect? This in a slightly different format came up on the CALSIFY mailing list. Some of the properties (METHOD for example ) exist only outside of a VEVENT. When needed it would force the BEGIN/END VCALENDAR tags. Sometimes or not sometimes would be a little flaky. Many implementions toss data before a BEGIN VCALENDAR and after a END VCALENDAR assuming it is MIME noise. Its kind of a poor mans ical/mime parser. At least one vendor wrapps each and every VEVENT with a BEGIN/END VCALENDAR. Another vendor only allows one BEGIN/END VCALENDAR per mime object. I would recomment that this list not re-invent iCAL or CALSIFY except when unique to CALDAV, else we are going to have multiple was to do the same thing again. I am not sure which way CALSIFY is going. I am hoping one BEGIN/END VCALENDAR per unique METHOD so that existing parsers work and are reusable for iMIP. And in keeping with iMIP only ONE BEGIN/END VCALENDAR per unique METHOD . Which is the same as one and only one BEGIN/END VCALENDAR per MIME object. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040307020808070503060904 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwOTE1MDAzNjQwWjAjBgkqhkiG9w0BCQQxFgQU5LYBx4RonqBi+IzeEO3y mHxw+a8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAmFO864DbHDQhQtjcqjmGxg907qCPurvX8lZ8WbN3bfKLqyvzwMA1vsedr19yxmum 4WNrOwqKu3x840UUJxQVFOvBNAseR3qM18iE62x+BGBN3hkIGwfLl4DpEXuwFR00nKKinHla v2c0lNEGGACEi4zSxWOEiJv1xjxIb4NFzv0fKzARG6X+phrOursdHtHpuNFEuOJiyrCIq4FR amApekYRhxB0KlkwRhnA3ngICAg1xm0fnxkvHuoZGbCII7k6/EbIe1xHRUNVUNJ8aze3vU8F uOUd6HufPx6JdBO94RMvelEGibHFQ+fUjzfbTZcSVQnla0t7wKFGenizxmXDdgAAAAAAAA== --------------ms040307020808070503060904-- X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8EMeVpp027459 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 14 Sep 2004 15:40:35 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <122A4AE0-069F-11D9-9C6B-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: CalDAV DevList From: Lisa Dusseault Date: Tue, 14 Sep 2004 15:40:25 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 22:40:36 -0000 Some broader input would be nice on an issue I've been looking at out of band... - If the CalDAV VEVENT resources (the resource that corresponds to a simple event) is of type "text/calendar", then it has to have BEGIN:VCALENDAR and END:VCALENDAR as a wrapper. - If that wrapper exists on every single CalDAV resource it's a bit of constant redundant overhead. It's not that much overhead, so if we have to keep it to be backward-compatible I think we ought. The question is, do iCalendar parsers today handle something that is text/calendar and doesn't begin with BEGIN:VCALENDAR? Instead it would just start with BEGIN:VEVENT and contain only one VEVENT. In other words, how forgiving are existing iCalendar parsers in this respect? Lisa X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87H2qpp009546 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 7 Sep 2004 10:02:52 -0700 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i87H2k8m030196 for ; Tue, 7 Sep 2004 10:02:46 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i87H2kGw010378 for ; Tue, 7 Sep 2004 11:02:46 -0600 Received: from oracle.com (bdesruis-ca.ca.oracle.com [144.23.213.225]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i87H2bjV009859; Tue, 7 Sep 2004 11:02:37 -0600 Message-ID: <413DE9AC.1040009@oracle.com> Date: Tue, 07 Sep 2004 13:02:36 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Creating a calendar References: <412E429A.4060504@oracle.com> <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> <412F6636.9070303@cse.ucsc.edu> <6.1.1.1.0.20040907103336.02842ac0@mail.comcast.net> In-Reply-To: <6.1.1.1.0.20040907103336.02842ac0@mail.comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 17:02:53 -0000 Tim, You must be talking of "Calendar Attributes for vCard and LDAP": http://www.ietf.org/rfc/rfc2739.txt Cheers, Bernard TimHare@comcast.net wrote: > I think, myself, that this should be a property in a user's directory > entry in some directory accessible via LDAP. I believe one of the > iCalendar RFCs referenced doing this, although a cursory search of RFC > 2445 only references using LDAP in a component property, rather than > using LDAP to locate user calendars. In any case, it is very desirable > to be able to use directory search to find the user's calendar. > > > > At 12:49 PM 8/27/04, Elias Sinderson wrote: > >> Lisa Dusseault wrote: >> >>> I also like the idea of looking at the principal resource to find out >>> more information like where the user's calendar is homed, where the >>> user's other file sharing space can be found, etc. CalDAV would only >>> have to define a property on the principal resource for this to work >>> [...] >> >> >> +1 - simple and elegant. >> >> Cyrus Daboo wrote: >> >>> Lisa Dusseault wrote: >>> >>>> When a user logs in, the ACL standard defines a REPORT to ask "who >>>> am I". >>>> With that report the client gets the mapping from the user's login >>>> ID to >>>> a principal URL. >>> >>> >>> But that does not help locating calendars for resources that are not >>> associated with a principal e.g. public calendars, calendars for >>> meeting rooms etc One could argue that you could use DASL to find >>> those things, but I think having a NAMESPACE report would be better. >> >> >> Presumably these resources could also be located via other means >> (links from a corporate intranet web site, group homepage, etc.). As >> long as a client provides a way for a user to enter in the location of >> a calendar the issue is somewhat moot. I do support the notion of >> automatic / programmatic location of calendar resources, however I >> don't believe that it necessarily entails the creation of a new report >> type. >> >> You are completely correct in that DASL is general enough to support >> this use case - can you explain why you believe that the report >> approach is somehow better? IMHO, using DASL for calendar resource >> discovery makes perfect sense and wouldn't put an inordinate amount of >> load on a server, considering that the discovery process would only >> happen infrequently at worst and only a few times per user / client at >> best (on a given server). >> >> >> Cheers, >> Elias >> _______________________________________________ >> Ietf-caldav mailing list >> Ietf-caldav@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > > Tim Hare > Interested Bystander, Non-Inc. > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87Gu6pp008948 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 7 Sep 2004 09:56:06 -0700 In-Reply-To: <6.1.1.1.0.20040907103336.02842ac0@mail.comcast.net> References: <412E429A.4060504@oracle.com> <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> <412F6636.9070303@cse.ucsc.edu> <6.1.1.1.0.20040907103336.02842ac0@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating a calendar Date: Tue, 7 Sep 2004 09:55:58 -0700 To: TimHare@comcast.net X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 16:56:09 -0000 Typically the WebDAV "principal resources" are actually reflections of LDAP data. For example, if you have Xythos WebFile Server, when a query to a principal resource like "http://example.org/users/ldusseault" is handled by the WebDAV server, it can actually make a live request to the LDAP server to get the user's display name or other information, before responding to the HTTP request. The reasoning behind the design of "principal resources" in the first place was to keep HTTP/WebDAV clients from having to implement LDAP in order to find users to set access control; also to keep from requiring sites that use WebDAV from necessarily having to include LDAP in the architecture. The existence of principal resources means that a site that doesn't use LDAP can get the user data from another source without having to change HTTP/WebDAV client implementations. All this is not mutually exclusive with using LDAP to locate user calendars, but it does make LDAP less of a requirement. Lisa On Sep 7, 2004, at 7:38 AM, TimHare@comcast.net wrote: > I think, myself, that this should be a property in a user's directory > entry in some directory accessible via LDAP. I believe one of the > iCalendar RFCs referenced doing this, although a cursory search of RFC > 2445 only references using LDAP in a component property, rather than > using LDAP to locate user calendars. In any case, it is very desirable > to be able to use directory search to find the user's calendar. > > > > At 12:49 PM 8/27/04, Elias Sinderson wrote: >> Lisa Dusseault wrote: >> >>> I also like the idea of looking at the principal resource to find >>> out more information like where the user's calendar is homed, where >>> the user's other file sharing space can be found, etc. CalDAV would >>> only have to define a property on the principal resource for this to >>> work [...] >> >> +1 - simple and elegant. >> >> Cyrus Daboo wrote: >> >>> Lisa Dusseault wrote: >>> >>>> When a user logs in, the ACL standard defines a REPORT to ask "who >>>> am I". >>>> With that report the client gets the mapping from the user's login >>>> ID to >>>> a principal URL. >>> >>> But that does not help locating calendars for resources that are not >>> associated with a principal e.g. public calendars, calendars for >>> meeting rooms etc One could argue that you could use DASL to find >>> those things, but I think having a NAMESPACE report would be better. >> >> Presumably these resources could also be located via other means >> (links from a corporate intranet web site, group homepage, etc.). As >> long as a client provides a way for a user to enter in the location >> of a calendar the issue is somewhat moot. I do support the notion of >> automatic / programmatic location of calendar resources, however I >> don't believe that it necessarily entails the creation of a new >> report type. >> >> You are completely correct in that DASL is general enough to support >> this use case - can you explain why you believe that the report >> approach is somehow better? IMHO, using DASL for calendar resource >> discovery makes perfect sense and wouldn't put an inordinate amount >> of load on a server, considering that the discovery process would >> only happen infrequently at worst and only a few times per user / >> client at best (on a given server). >> >> >> Cheers, >> Elias >> _______________________________________________ >> Ietf-caldav mailing list >> Ietf-caldav@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > Tim Hare > Interested Bystander, Non-Inc. > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i87Ek0po028256 for ; Tue, 7 Sep 2004 07:46:00 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <2004090714455501300aou85e> (Authid: TimHare); Tue, 7 Sep 2004 14:45:55 +0000 Message-Id: <6.1.1.1.0.20040907103336.02842ac0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 07 Sep 2004 10:38:10 -0400 To: CalDAV DevList From: TimHare@comcast.net Subject: Re: [Ietf-caldav] Creating a calendar In-Reply-To: <412F6636.9070303@cse.ucsc.edu> References: <412E429A.4060504@oracle.com> <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> <412F6636.9070303@cse.ucsc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 14:46:01 -0000 I think, myself, that this should be a property in a user's directory entry in some directory accessible via LDAP. I believe one of the iCalendar RFCs referenced doing this, although a cursory search of RFC 2445 only references using LDAP in a component property, rather than using LDAP to locate user calendars. In any case, it is very desirable to be able to use directory search to find the user's calendar. At 12:49 PM 8/27/04, Elias Sinderson wrote: >Lisa Dusseault wrote: > >>I also like the idea of looking at the principal resource to find out >>more information like where the user's calendar is homed, where the >>user's other file sharing space can be found, etc. CalDAV would only >>have to define a property on the principal resource for this to work [...] > >+1 - simple and elegant. > >Cyrus Daboo wrote: > >>Lisa Dusseault wrote: >> >>>When a user logs in, the ACL standard defines a REPORT to ask "who am I". >>>With that report the client gets the mapping from the user's login ID to >>>a principal URL. >> >>But that does not help locating calendars for resources that are not >>associated with a principal e.g. public calendars, calendars for meeting >>rooms etc One could argue that you could use DASL to find those things, >>but I think having a NAMESPACE report would be better. > >Presumably these resources could also be located via other means (links >from a corporate intranet web site, group homepage, etc.). As long as a >client provides a way for a user to enter in the location of a calendar >the issue is somewhat moot. I do support the notion of automatic / >programmatic location of calendar resources, however I don't believe that >it necessarily entails the creation of a new report type. > >You are completely correct in that DASL is general enough to support this >use case - can you explain why you believe that the report approach is >somehow better? IMHO, using DASL for calendar resource discovery makes >perfect sense and wouldn't put an inordinate amount of load on a server, >considering that the discovery process would only happen infrequently at >worst and only a few times per user / client at best (on a given server). > > >Cheers, >Elias >_______________________________________________ >Ietf-caldav mailing list >Ietf-caldav@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc.