Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DE3F67F532 for ; Thu, 25 Aug 2005 16:34:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id BA3971422DD for ; Thu, 25 Aug 2005 16:34:20 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24694-06 for ; Thu, 25 Aug 2005 16:34:20 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 3FF661422DA for ; Thu, 25 Aug 2005 16:34:20 -0700 (PDT) Received: from mead11.u.washington.edu (mead11.u.washington.edu [140.142.12.175]) by mxout3.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j7PNYJtc029856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Aug 2005 16:34:19 -0700 Received: from localhost (gsbarnes@localhost) by mead11.u.washington.edu (8.13.4+UW05.03/8.13.4+UW05.07) with ESMTP id j7PNYJ9S3387536 for ; Thu, 25 Aug 2005 16:34:19 -0700 Date: Thu, 25 Aug 2005 16:34:19 -0700 (PDT) From: "G. Barnes" To: CalDAV DevList Subject: Re: [Ietf-caldav] Calendar collections In-Reply-To: <9f530ba27acc8c52a040798dc63bd58e@osafoundation.org> Message-ID: References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> <4307C958.90408@rpi.edu> <9e118d34088fb83a003d7ca5a33c7c33@osafoundation.org> <9f530ba27acc8c52a040798dc63bd58e@osafoundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 25 Aug 2005 23:34:21 -0000 On Thu, 25 Aug 2005, Lisa Dusseault wrote: > You're both entirely correct, but collections are rather a necessity for many > existing architectures. Some of what you need or want collections for: > - must have for PROPFIND -- partition entire space of events into > reasonable-to-PROPFIND chunks > - nice to have for managing quota (proposed quota properties on collections) > - nice to have (or must on some servers) for managing access control -- can > grant "read" access to Mike on my calendar via the calendar collection > - collections inside user accounts provide guidance for ownership -- who > should be able to control content as last resort > - the standard, required way URLs are constructed in WebDAV As I said, I'm not suggesting the existing data model be changed. You list some of the good reasons why it is the way it is. [...] > Mike, I'm quite sensitive to the comparison to email (we're struggling with > that with IMAP support in Chandler). But unless we had or designed a new > collection-free repository access protocol (or morphed WebDAV into one) we're > kind of stuck with collections. I welcome any suggestions that help ensure > that the protocol data model isn't forced into user's faces any more than it > has to be. I made one concrete suggestion. I think the 2nd paragraph in 4.6.1 should be changed: Support for MKCALENDAR on the server is OPTIONAL because some calendar stores only support one calendar per user (or principal) and those are typically pre-created for each account. However, servers and clients are strongly encouraged to support MKCALENDAR whenever possible to allow users to create multiple calendar collections to better help organize their data. First of all, there's the obvious problem that this paragraph says OPTIONAL (equivalent to MAY), when Section 2 says SHOULD. More importantly for this discussion: if you agree that CalDAV is not necessarily in the business of defining a user model, then the justification that MKCALENDAR 'allows users to create multiple calendar collections to better organize their data' should not be used, as it closely links the DAV collections model and the user model. I originally suggested that the SHOULD (from section 2) be changed into a MAY. Upon further reflection, I suspect there are probably good reasons why we want to encourage support of MKCALENDAR, such as that it allows *clients* to create calendar collections when appropriate --- if we're going to force clients to create a coherent user model out of the WebDAV collections model, we should give them all the tools we can. So I withdraw any preference for SHOULD vs. MAY/OPTIONAL, as long as the justification in the last sentence is changed to make it clear that this method is for the benefit of CalDAV clients, not the end users. [...] > Finally, Greg, part of the problem you describe with different calendar > owners wanting a piece of the same public event is inherent not just in > WebDAV but in the federated nature of successful content systems on the > Internet. Today if I want to publicize a band's concert I do so on my own > Web blog even if that band has it's own web site and the concert hall has its > own web site too. If you send me an email you probably retain a copy on your > server as well as the copy (or copies) I retain on my server. I don't think > that single-instancing public content is a problem that we can or want to fix > -- and I apologize if this turns out to be a straw man. I could easily change the example so that it works within the university setting, where it's easy to imagine most or all of the calendars reside on the same server. But even if you only consider private events, partitioning is not easy or, I think, particularly desirable. If there's a retirement party for my co-worker Joe next Friday during regular work hours, do I stick that in my 'social' calendar, or my 'work' calendar? This goes back to my filing example. I can divide most of my stuff into neat little categories, but some of it belongs in more than one. Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 > On Aug 25, 2005, at 8:05 AM, Mike Shaver wrote: > >> On 8/25/05, G. Barnes wrote: >>> This discussion reinforces my belief that the data model of CalDAV >>> calendar collections probably should not be used as the data model one >>> presents to users. >>> >>> Although this is never stated explicitly in the draft, it appears to >>> me that the underlying CalDAV model is one where calendar collections >>> partition the universe of events. I'm sure there are valid reasons >>> for this model, so I'm certainly not going to say it should be changed. >>> >>> However, there is a danger when you try to make your users' model match >>> this model. That is, I think most people who use calendaring systems >>> will agree that a 'calendar' is a useful thing to think about. But >>> if you try to make 'calendars' equivalent to CalDAV calendar collections, >>> you're going to run into problems. >> >> Yes, yes, yes. This is basically what happened with every thick mail >> client built in the 90s: it was a faithful reflection of the server's >> folder hierarchy -- or, for many users, the hierarchies of multiple >> servers. In the calendar case we already have a large body of >> evidence indicating that users will aggregate many different calendars >> into their views of the world, and partitioning them along >> server-storage lines is not something that I think we should be >> "baking into" recommendations like the CalDAV spec. >> >> Mike > > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 48C397F533 for ; Thu, 25 Aug 2005 15:14:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 3A0AE1422CF for ; Thu, 25 Aug 2005 15:14:12 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23034-06; Thu, 25 Aug 2005 15:14:11 -0700 (PDT) Received: from [192.168.101.65] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id F07871422B1; Thu, 25 Aug 2005 15:14:10 -0700 (PDT) In-Reply-To: References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> <4307C958.90408@rpi.edu> <9e118d34088fb83a003d7ca5a33c7c33@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9f530ba27acc8c52a040798dc63bd58e@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Calendar collections Date: Thu, 25 Aug 2005 15:14:06 -0700 To: Mike Shaver X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: "G. Barnes" , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 25 Aug 2005 22:14:12 -0000 You're both entirely correct, but collections are rather a necessity for many existing architectures. Some of what you need or want collections for: - must have for PROPFIND -- partition entire space of events into reasonable-to-PROPFIND chunks - nice to have for managing quota (proposed quota properties on collections) - nice to have (or must on some servers) for managing access control -- can grant "read" access to Mike on my calendar via the calendar collection - collections inside user accounts provide guidance for ownership -- who should be able to control content as last resort - the standard, required way URLs are constructed in WebDAV Recall that addresses and the structure of addresses are both somewhat fixed and somewhat arbitrary. The REPORTs we have so far go a certain way towards treating calendar data like it resides in one big component soup without arbitrary collections -- e.g. if you put a bunch of sports-related calendars, each in an individual collection, all inside one parent collection, and support calendar REPORT on the parent collection, then a REPORT lets me see events across all those calendars with certain filters. What else can a server do beyond CalDAV and collections? - In addition to the structured, collection namespace, the server could offer a "soup" namespace -- for example a way to retrieve each event by some unique identifier: "http://caldav.example.org/uuid/6ba7b814-9dad-11d1-80b4-00c04fd430c8" - The server could support additional REPORT or SEARCH tools to allow arbitrary access across the repository. What else can a client do? - A client like Apple's iCal is entirely possible - I can subscribe to Mike's calendar on Mike's server and Greg's calendar on Greg's server, and overlay those calendars with my own (hosted at a third server) - A personal calendar client could (and arguably should) put all "my" events into a single calendar. It could also create a second calendar only if I, the user, explicitly wanted a separate set of people to share a separate set of events with -- a rare, power-user function. - A calendar client managing public event calendars could (and arguably should) group events for several organizations or venues into one CalDAV "calendar" collection and tag those events according to venue and group. E.g. the "543 Howard St office" calendar could include events for the Gotham, Lilliput and Whoville meeting rooms and for OSAF, KEI and Creative Commons organizations -- all in one collection. - A calendar client subscribing to public event calendars could browse the "543 Howard St office" calendar and then decide only to display (if this were the user's choice) those meetings that were tagged with the OSAF organization[1] These are basically examples of what Greg suggests -- that the basic CalDAV data model isn't at all the final answer for the client's calendar model or the mental model it creates for users. Mike, I'm quite sensitive to the comparison to email (we're struggling with that with IMAP support in Chandler). But unless we had or designed a new collection-free repository access protocol (or morphed WebDAV into one) we're kind of stuck with collections. I welcome any suggestions that help ensure that the protocol data model isn't forced into user's faces any more than it has to be. Finally, Greg, part of the problem you describe with different calendar owners wanting a piece of the same public event is inherent not just in WebDAV but in the federated nature of successful content systems on the Internet. Today if I want to publicize a band's concert I do so on my own Web blog even if that band has it's own web site and the concert hall has its own web site too. If you send me an email you probably retain a copy on your server as well as the copy (or copies) I retain on my server. I don't think that single-instancing public content is a problem that we can or want to fix -- and I apologize if this turns out to be a straw man. Lisa Footnote 1: I'm hand-waving over the standardization of events tagged with organization affiliations or machine-readable locations, because we haven't addressed standardizing public calendars -- we're focused on individual calendar use cases in CalDAV 1.0. On Aug 25, 2005, at 8:05 AM, Mike Shaver wrote: > On 8/25/05, G. Barnes wrote: >> This discussion reinforces my belief that the data model of CalDAV >> calendar collections probably should not be used as the data model one >> presents to users. >> >> Although this is never stated explicitly in the draft, it appears to >> me that the underlying CalDAV model is one where calendar collections >> partition the universe of events. I'm sure there are valid reasons >> for this model, so I'm certainly not going to say it should be >> changed. >> >> However, there is a danger when you try to make your users' model >> match >> this model. That is, I think most people who use calendaring systems >> will agree that a 'calendar' is a useful thing to think about. But >> if you try to make 'calendars' equivalent to CalDAV calendar >> collections, >> you're going to run into problems. > > Yes, yes, yes. This is basically what happened with every thick mail > client built in the 90s: it was a faithful reflection of the server's > folder hierarchy -- or, for many users, the hierarchies of multiple > servers. In the calendar case we already have a large body of > evidence indicating that users will aggregate many different calendars > into their views of the world, and partitioning them along > server-storage lines is not something that I think we should be > "baking into" recommendations like the CalDAV spec. > > Mike Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 83E7D7F53B for ; Thu, 25 Aug 2005 08:35:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 6D4241422DA for ; Thu, 25 Aug 2005 08:35:04 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22245-01 for ; Thu, 25 Aug 2005 08:35:04 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id E6C5D1422D8 for ; Thu, 25 Aug 2005 08:35:03 -0700 (PDT) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j7PFVHuG028281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2005 11:31:17 -0400 Date: Thu, 25 Aug 2005 11:34:57 -0400 From: Cyrus Daboo To: Mike Shaver , "G. Barnes" Subject: Re: [Ietf-caldav] Calendar collections Message-ID: In-Reply-To: References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> <4307C958.90408@rpi.edu> <9e118d34088fb83a003d7ca5a33c7c33@osafoundation.org> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 25 Aug 2005 15:35:04 -0000 Hi Mike, --On August 25, 2005 11:05:27 AM -0400 Mike Shaver wrote: > Yes, yes, yes. This is basically what happened with every thick mail > client built in the 90s: it was a faithful reflection of the server's > folder hierarchy -- or, for many users, the hierarchies of multiple > servers. In the calendar case we already have a large body of > evidence indicating that users will aggregate many different calendars > into their views of the world, and partitioning them along > server-storage lines is not something that I think we should be > "baking into" recommendations like the CalDAV spec. Currently there is nothing stopping a client from merging data from multiple calendar collections into one 'virtual' calendar view. The question is whether the 'virtual' calendar view is something that should be managed on the server or client end. In the email world (IMAP) clients do all the work of virtual mailboxes - which misses one of the major benefits of IMAP, namely having the server centrally manage the data in a way consistent for all clients. Frankly its about time that IMAP had a virtual folder extension. Something similar could be done as an extension to CalDAV if the demand arises. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 588527F53C for ; Thu, 25 Aug 2005 08:05:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 3B0C91422DD for ; Thu, 25 Aug 2005 08:05:28 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18552-03 for ; Thu, 25 Aug 2005 08:05:28 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by smtp.osafoundation.org (Postfix) with ESMTP id D48C31422DA for ; Thu, 25 Aug 2005 08:05:27 -0700 (PDT) Received: by zproxy.gmail.com with SMTP id 16so250869nzp for ; Thu, 25 Aug 2005 08:05:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kz0GRpBTh/fBZ3b7LFHYwk9vokb6qiZQgG6PUv6LC3dcoxlNG25Pfebb5GW6x9Ds/LnDVJzoS6OQMafthiu2g62nEuAFJuDu5OUWqfsRSXi/cpgy/mQHxVLpcXqUaP4gHdhP24+QI9I3eUzl/ZZuxs+6T4FWQBWITrKt49rn4TU= Received: by 10.36.101.14 with SMTP id y14mr95445nzb; Thu, 25 Aug 2005 08:05:27 -0700 (PDT) Received: by 10.36.106.19 with HTTP; Thu, 25 Aug 2005 08:05:27 -0700 (PDT) Message-ID: Date: Thu, 25 Aug 2005 11:05:27 -0400 From: Mike Shaver To: "G. Barnes" Subject: Re: [Ietf-caldav] Calendar collections In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> <4307C958.90408@rpi.edu> <9e118d34088fb83a003d7ca5a33c7c33@osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=BAYES_00, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 25 Aug 2005 15:05:28 -0000 On 8/25/05, G. Barnes wrote: > This discussion reinforces my belief that the data model of CalDAV > calendar collections probably should not be used as the data model one > presents to users. >=20 > Although this is never stated explicitly in the draft, it appears to > me that the underlying CalDAV model is one where calendar collections > partition the universe of events. I'm sure there are valid reasons > for this model, so I'm certainly not going to say it should be changed. >=20 > However, there is a danger when you try to make your users' model match > this model. That is, I think most people who use calendaring systems > will agree that a 'calendar' is a useful thing to think about. But > if you try to make 'calendars' equivalent to CalDAV calendar collections, > you're going to run into problems. Yes, yes, yes. This is basically what happened with every thick mail client built in the 90s: it was a faithful reflection of the server's folder hierarchy -- or, for many users, the hierarchies of multiple servers. In the calendar case we already have a large body of evidence indicating that users will aggregate many different calendars into their views of the world, and partitioning them along server-storage lines is not something that I think we should be "baking into" recommendations like the CalDAV spec. Mike Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 76D557F511; Wed, 24 Aug 2005 23:03:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 2F1D31422B3; Wed, 24 Aug 2005 23:03:02 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12273-05; Wed, 24 Aug 2005 23:03:01 -0700 (PDT) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 98EDB1422B1; Wed, 24 Aug 2005 23:03:01 -0700 (PDT) Received: from mead11.u.washington.edu (mead11.u.washington.edu [140.142.12.175]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j7P630aw007116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2005 23:03:00 -0700 Received: from localhost (gsbarnes@localhost) by mead11.u.washington.edu (8.13.4+UW05.03/8.13.4+UW05.07) with ESMTP id j7P62xVb3481786; Wed, 24 Aug 2005 23:03:00 -0700 Date: Wed, 24 Aug 2005 23:02:59 -0700 (PDT) From: "G. Barnes" To: Lisa Dusseault Subject: Re: [Ietf-caldav] Calendar collections In-Reply-To: <9e118d34088fb83a003d7ca5a33c7c33@osafoundation.org> Message-ID: References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> <4307C958.90408@rpi.edu> <9e118d34088fb83a003d7ca5a33c7c33@osafoundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 25 Aug 2005 06:03:02 -0000 On Sat, 20 Aug 2005, Lisa Dusseault wrote: > Yep -- or your administrative interface could offer a way to convert "arts" > into a calendar home and move all the events down a level. > > I agree that the model limitation imposes drawbacks in the case of certain > calendar reorganization use cases. I just don't think we should optimize for > those rare use cases. Most client implementations will never have to deal > with those use cases. My apologies for jumping in late. This discussion reinforces my belief that the data model of CalDAV calendar collections probably should not be used as the data model one presents to users. Although this is never stated explicitly in the draft, it appears to me that the underlying CalDAV model is one where calendar collections partition the universe of events. I'm sure there are valid reasons for this model, so I'm certainly not going to say it should be changed. However, there is a danger when you try to make your users' model match this model. That is, I think most people who use calendaring systems will agree that a 'calendar' is a useful thing to think about. But if you try to make 'calendars' equivalent to CalDAV calendar collections, you're going to run into problems. To take a simple example, the coffee shop up the hill from my house is hosting a concert by Joe Smith next Saturday at 6pm. The coffee shop would probably like to add this event to its 'calendar'. Joe Smith would probably like to have this event in his 'calendar' of upcoming shows. The local weekly also wants the event in their 'calendar' of concerts, and maybe in another 'calendar' of spotlighted events. While the local magazine for parents might like to have it in its 'calendar' of kid-friendly events. Clearly, these 'calendars' do not partition the universe of events. As another example, one can imagine Chemistry 101 has an associated 'calendar' consisting of all class meetings, plus the final exam and perhaps some associated study sessions. But wait, Chem 101 has labs, too, and maybe discussion sections. But if you're the professor, you don't show up at the labs or discussion sections, and probably not the study session. So the professor's Chemistry 101 calendar consists of lectures plus the final, plus maybe some deadlines like when grades have to be turned in and homeworks created. While a TA's Chemistry 101 consists mostly of discussion sessions and labs they lead, and a student's Chem 101 calendar is all the lectures plus the final and study sessions, plus one lab and one discussion section. Meanwhile, the Chemistry department probably wants to create *its* own calendar of all the lectures of all the classes in the department, including most of these subcalendars. What I'm getting at is that, as the number of events on your server increases, your users will want to combine, merge, subdivide, select and do all sorts of whatnot with them in the ways they like. And they'll probably call these things they create 'calendars'. So I don't think you can just sit back and think the CalDAV model imposes some small inconveniences in some corner cases. I suspect it will impose a lot of inconveniences a lot of the time, assuming you want your program to cater to your users and not vice versa. On the other hand, I also agree that time is a-wasting, and there's no point in trying to get the perfect model. Might as well go with the limitations that are there now (assuming, of course, the actual implementers don't find something wrong with them). But to reiterate my original point, I think this means the CalDAV model cannot be used as a model for users. You're going to have to build quite a lot on top of it to get what users want. As a tangent, and to get away from the whole 'public events' thing, my wife was just complaining to me this weekend that she didn't like my filing system for our papers. Unfortunately, with paper items like bills, you have to partition them. But for events stored on a computer, I think we can do much better. Hence all the interest in 'desktop search'. People can't even organize their own personal files on their own personal computer in a satisfactory way. I don't expect having people partition their personal events is going to work much better. To bring this back to something resembling a point, I do have one complaint about the draft in light of what I just said, which is with 4.6.1, MKCALENDAR. In this section, there is a clear bias toward making the CalDAV data model match the real world user model. For reasons I have just argued, I think this is a mistake. Yes, that's one way of doing things, but to imply that it is the best way, as the 2nd paragraph in this section does, is, I think, wrong. To put it in IETF terms, I think this paragraph should be changed to suggest MKCALENDAR as one way to allow people to organize their events, and the 'SHOULD' in Section 2 should become a 'MAY'. And now that I look at it, Section 2 says MKCALENDAR support is a SHOULD, but 4.6.1 says it's OPTIONAL. Regardless of whether you agree with what I've been saying, these should match. Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 > On Aug 20, 2005, at 5:22 PM, Mike Douglass wrote: > >> >> >> Lisa Dusseault wrote: >> >>> ... >>> I do understand how reorganization can be a problem but I don't see how >>> allowing calendar collections to nest would help that case. Can you >>> explain that? >>> >> I may have something wrong in my thinking but I see it as mainly a user >> convenience issue. Say, for want of a better example, we have 1000 arts >> events and we belatedly realised we should have subdivided them so now we >> have >> >> arts/event1,... arts/event1000 >> >> arts is a calendar collection. We're not allowed to create arts/performance >> alongside the events as we would naturally do in a file system. So we have >> to do something like rename arts, create a new non-calendar collection and >> then create the sub-collections. >> >> The same is presumably true of auser with a personal calendar who may >> decide they'd like to subcategorize their personal calendar. >> >> Currently our users can subscribe to "arts" and get all the subcategories >> so I will support report on those collections. >> >>> thanks, >>> Lisa >>> >> >> -- >> >> Mike Douglass douglm@rpi.edu >> Senior Systems Programmer >> Communication & Collaboration Technologies 518 276 6780(voice) 2809 >> (fax) >> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 >> > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A9C417F588 for ; Mon, 22 Aug 2005 12:57:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 9BCBF1422B7 for ; Mon, 22 Aug 2005 12:57:56 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12324-06; Mon, 22 Aug 2005 12:57:56 -0700 (PDT) Received: from [192.168.101.65] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 39B0814229A; Mon, 22 Aug 2005 12:57:56 -0700 (PDT) In-Reply-To: <11F943CA-85D0-47B5-A754-6DFE3CAEE9DE@opengroupware.org> References: <430A1F14.1030204@osafoundation.org> <18590297-7F57-486C-B3A4-F8123946DF0E@opengroupware.org> <430A2645.8040004@osafoundation.org> <11F943CA-85D0-47B5-A754-6DFE3CAEE9DE@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: multipart/alternative; boundary=Apple-Mail-3-404585664 Message-Id: From: Lisa Dusseault Subject: Re: [Ietf-caldav] GET for calendar collections Date: Mon, 22 Aug 2005 12:57:53 -0700 To: Helge Hess X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 22 Aug 2005 19:57:56 -0000 --Apple-Mail-3-404585664 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Aug 22, 2005, at 12:42 PM, Helge Hess wrote: > On 22. Aug 2005, at 21:23 Uhr, Brian Moseley wrote: >> i did not advocate that it be a requirement, but rather a suggestion, >> and a pretty simple one at that. > > Yes, but shouldn't CalDAV be kept as tight as possible and focus on > the new protocol? > >> can you some details about why you don't think caldav should make >> this suggestion? > > Well, mostly for the same reason why CalDAV doesn't include IMAP4 or > LDAP ;-) Separate protocols should be kept separate. > I sort of agree with that but we might want to deal with Accept header just a little bit -- since we're modeling calendar components as HTTP resources, a few words about what to do when the client sends the Accept header might be in order. That doesn't necessarily pull in all the other pieces like what to do about PUT which I agree should be a separate document -- supporting iCal and CalDAV at the same time, both read/write, could be a bite-sized Internet-Draft in itself. At some point Dan Winship was interested in writing such a document but I think he's not working on calendar stuff so much now. Any other volunteers? lisa --Apple-Mail-3-404585664 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII On Aug 22, 2005, at 12:42 PM, Helge Hess wrote: On 22. Aug 2005, at 21:23 Uhr, Brian Moseley wrote: i did not advocate that it be a requirement, but rather a suggestion, and a pretty simple one at that. Yes, but shouldn't CalDAV be kept as tight as possible and focus on the new protocol? can you some details about why you don't think caldav should make this suggestion? Well, mostly for the same reason why CalDAV doesn't include IMAP4 or LDAP ;-) Separate protocols should be kept separate. I sort of agree with that but we might want to deal with Accept header just a little bit -- since we're modeling calendar components as HTTP resources, a few words about what to do when the client sends the Accept header might be in order. That doesn't necessarily pull in all the other pieces like what to do about PUT which I agree should be a separate document -- supporting iCal and CalDAV at the same time, both read/write, could be a bite-sized Internet-Draft in itself. At some point Dan Winship was interested in writing such a document but I think he's not working on calendar stuff so much now. Any other volunteers? lisa --Apple-Mail-3-404585664-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B43EC7F586 for ; Mon, 22 Aug 2005 12:57:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id A60C71422B7 for ; Mon, 22 Aug 2005 12:57:44 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10333-08; Mon, 22 Aug 2005 12:57:44 -0700 (PDT) Received: from [192.168.101.176] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 44DA014229A; Mon, 22 Aug 2005 12:57:44 -0700 (PDT) Message-ID: <430A2E38.6090603@osafoundation.org> Date: Mon, 22 Aug 2005 12:57:44 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] GET for calendar collections References: <430A1F14.1030204@osafoundation.org> <18590297-7F57-486C-B3A4-F8123946DF0E@opengroupware.org> <430A2645.8040004@osafoundation.org> <11F943CA-85D0-47B5-A754-6DFE3CAEE9DE@opengroupware.org> In-Reply-To: <11F943CA-85D0-47B5-A754-6DFE3CAEE9DE@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 22 Aug 2005 19:57:44 -0000 Helge Hess wrote: > Anyway if you include that, you'll need to answer at least those > questions as well: > a) PUT? > b) locking? > c) ACLs? > ... with concurrent "real" CalDAV access on the same collection. with the exception of acls, i don't think any of the rest of these concerns are relevant to providing a read-only calendar view of a calendar collection. there has definitely been some noise made about an informational document discussing read/write synchronization with existing icalendar-over-webdav clients. i'm not prepared to go there yet :) as far as acls go, yes, i think clients would need assurance that acls are respected. but let's step back and think about what currently happens. i bet 100% of webdav servers return text/html directory listings in response to GET requests for collections. i also bet that 100% of them respect whatever security model they implement when doing so. so i don't see acls being problematic here. perhaps the draft authors could add whatever language they feel appropriate to what i've suggested. > You don't have access to Google? ;-) > > http://www.google.de/search?as_qdr=all&q=+GET+text%2Fcalendar+site% > 3Ahttp%3A%2F%2Flists.osafoundation.org%2Fpipermail%2Fietf-caldav%2F good one, thanks :) Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3459A7F584 for ; Mon, 22 Aug 2005 12:43:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 17D861422B0 for ; Mon, 22 Aug 2005 12:43:03 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11913-10 for ; Mon, 22 Aug 2005 12:43:02 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by smtp.osafoundation.org (Postfix) with ESMTP id A8A0A14229A for ; Mon, 22 Aug 2005 12:43:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id BCA58321CFF for ; Mon, 22 Aug 2005 21:40:07 +0200 (CEST) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 6A266321737 for ; Mon, 22 Aug 2005 21:40:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <430A2645.8040004@osafoundation.org> References: <430A1F14.1030204@osafoundation.org> <18590297-7F57-486C-B3A4-F8123946DF0E@opengroupware.org> <430A2645.8040004@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11F943CA-85D0-47B5-A754-6DFE3CAEE9DE@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] GET for calendar collections Date: Mon, 22 Aug 2005 21:42:58 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.734) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 22 Aug 2005 19:43:03 -0000 On 22. Aug 2005, at 21:23 Uhr, Brian Moseley wrote: > i did not advocate that it be a requirement, but rather a > suggestion, and a pretty simple one at that. Yes, but shouldn't CalDAV be kept as tight as possible and focus on the new protocol? > can you some details about why you don't think caldav should make > this suggestion? Well, mostly for the same reason why CalDAV doesn't include IMAP4 or LDAP ;-) Separate protocols should be kept separate. Anyway if you include that, you'll need to answer at least those questions as well: a) PUT? b) locking? c) ACLs? ... with concurrent "real" CalDAV access on the same collection. >> PS: this was also discussed in the past, you might find the >> archives interesting. > i bet i would, if i had a viable mechanism for searching the > archive other than downloading and grepping the mbox files ;) You don't have access to Google? ;-) http://www.google.de/search?as_qdr=all&q=+GET+text%2Fcalendar+site% 3Ahttp%3A%2F%2Flists.osafoundation.org%2Fpipermail%2Fietf-caldav%2F Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1263E7F581 for ; Mon, 22 Aug 2005 12:23:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id F050F1422B8 for ; Mon, 22 Aug 2005 12:23:48 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12226-04 for ; Mon, 22 Aug 2005 12:23:48 -0700 (PDT) Received: from [192.168.101.176] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id BAD3C1422B0 for ; Mon, 22 Aug 2005 12:23:48 -0700 (PDT) Message-ID: <430A2645.8040004@osafoundation.org> Date: Mon, 22 Aug 2005 12:23:49 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] GET for calendar collections References: <430A1F14.1030204@osafoundation.org> <18590297-7F57-486C-B3A4-F8123946DF0E@opengroupware.org> In-Reply-To: <18590297-7F57-486C-B3A4-F8123946DF0E@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 22 Aug 2005 19:23:49 -0000 Helge Hess wrote: > IMO its a separate (/simpler) protocol which can be used alongside > CalDAV, just like GroupDAV. So care should be taken that this protocol > can be implemented by the server together with CalDAV (eg CalDAV should > not specify the GET), but it probably doesn't belong into CalDAV itself > and shouldn't be a requirement. i did not advocate that it be a requirement, but rather a suggestion, and a pretty simple one at that. can you some details about why you don't think caldav should make this suggestion? > PS: this was also discussed in the past, you might find the archives > interesting. i bet i would, if i had a viable mechanism for searching the archive other than downloading and grepping the mbox files ;) Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6ADEE7F57F for ; Mon, 22 Aug 2005 12:09:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 544791422A7 for ; Mon, 22 Aug 2005 12:09:21 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10432-10 for ; Mon, 22 Aug 2005 12:09:21 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by smtp.osafoundation.org (Postfix) with ESMTP id EDE15142292 for ; Mon, 22 Aug 2005 12:09:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 58670323200 for ; Mon, 22 Aug 2005 21:06:25 +0200 (CEST) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 889B3322C36 for ; Mon, 22 Aug 2005 21:06:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <430A1F14.1030204@osafoundation.org> References: <430A1F14.1030204@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18590297-7F57-486C-B3A4-F8123946DF0E@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] GET for calendar collections Date: Mon, 22 Aug 2005 21:09:14 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.734) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 22 Aug 2005 19:09:21 -0000 On 22. Aug 2005, at 20:53 Uhr, Brian Moseley wrote: > i wonder if it makes sense for caldav to make the following > recommendations: > > 1) clients MAY ask for a text/calendar representation of a calendar > collection (via the Accept header) > > 2) servers SHOULD be able to respond to such a request > > in fact, it might be beneficial to recommend text/calendar as the > default representation for a calendar collection, for the sake of > interoperability with existing clients which expect to be able to > GET a single icalendar resource representing an entire calendar. > > thoughts? IMO its a separate (/simpler) protocol which can be used alongside CalDAV, just like GroupDAV. So care should be taken that this protocol can be implemented by the server together with CalDAV (eg CalDAV should not specify the GET), but it probably doesn't belong into CalDAV itself and shouldn't be a requirement. Greets, Helge PS: this was also discussed in the past, you might find the archives interesting. -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 382C87F561 for ; Mon, 22 Aug 2005 11:53:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 221F41422B8 for ; Mon, 22 Aug 2005 11:53:09 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10432-06 for ; Mon, 22 Aug 2005 11:53:08 -0700 (PDT) Received: from [192.168.101.176] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id B54A41422B0 for ; Mon, 22 Aug 2005 11:53:08 -0700 (PDT) Message-ID: <430A1F14.1030204@osafoundation.org> Date: Mon, 22 Aug 2005 11:53:08 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] GET for calendar collections X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 22 Aug 2005 18:53:09 -0000 as per rfc 2518, the response to a GET request for a collection is undefined. perhaps a more natural behavior for calendar collections is to return a text/calendar response. i wonder if it makes sense for caldav to make the following recommendations: 1) clients MAY ask for a text/calendar representation of a calendar collection (via the Accept header) 2) servers SHOULD be able to respond to such a request in fact, it might be beneficial to recommend text/calendar as the default representation for a calendar collection, for the sake of interoperability with existing clients which expect to be able to GET a single icalendar resource representing an entire calendar. thoughts? Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3520D7F566 for ; Sat, 20 Aug 2005 20:47:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 1EA9914227C for ; Sat, 20 Aug 2005 20:47:07 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20478-07; Sat, 20 Aug 2005 20:47:06 -0700 (PDT) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 64A27142276; Sat, 20 Aug 2005 20:47:06 -0700 (PDT) In-Reply-To: <4307C958.90408@rpi.edu> References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> <4307C958.90408@rpi.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9e118d34088fb83a003d7ca5a33c7c33@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Calendar collections Date: Sat, 20 Aug 2005 20:46:57 -0700 To: Mike Douglass X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sun, 21 Aug 2005 03:47:07 -0000 Yep -- or your administrative interface could offer a way to convert "arts" into a calendar home and move all the events down a level. I agree that the model limitation imposes drawbacks in the case of certain calendar reorganization use cases. I just don't think we should optimize for those rare use cases. Most client implementations will never have to deal with those use cases. Lisa On Aug 20, 2005, at 5:22 PM, Mike Douglass wrote: > > > Lisa Dusseault wrote: > >> ... >> I do understand how reorganization can be a problem but I don't see >> how allowing calendar collections to nest would help that case. Can >> you explain that? >> > I may have something wrong in my thinking but I see it as mainly a > user convenience issue. Say, for want of a better example, we have > 1000 arts events and we belatedly realised we should have subdivided > them so now we have > > arts/event1,... arts/event1000 > > arts is a calendar collection. We're not allowed to create > arts/performance alongside the events as we would naturally do in a > file system. So we have to do something like rename arts, create a new > non-calendar collection and then create the sub-collections. > > The same is presumably true of auser with a personal calendar who may > decide they'd like to subcategorize their personal calendar. > > Currently our users can subscribe to "arts" and get all the > subcategories so I will support report on those collections. > >> thanks, >> Lisa >> > > -- > > Mike Douglass douglm@rpi.edu > Senior Systems Programmer > Communication & Collaboration Technologies 518 276 6780(voice) > 2809 > (fax) > Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8E29B7F566; Sat, 20 Aug 2005 17:22:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 75E04142278; Sat, 20 Aug 2005 17:22:56 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20061-08; Sat, 20 Aug 2005 17:22:56 -0700 (PDT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 1AF3D142277; Sat, 20 Aug 2005 17:22:56 -0700 (PDT) Received: from [192.168.0.103] (vpn-832.nss.rpi.edu [128.113.211.82]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j7L0Mr9C027000; Sat, 20 Aug 2005 20:22:54 -0400 Message-ID: <4307C958.90408@rpi.edu> Date: Sat, 20 Aug 2005 20:22:48 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Calendar collections References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> In-Reply-To: <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sun, 21 Aug 2005 00:22:56 -0000 Lisa Dusseault wrote: > ... > I do understand how reorganization can be a problem but I don't see > how allowing calendar collections to nest would help that case. Can > you explain that? > I may have something wrong in my thinking but I see it as mainly a user convenience issue. Say, for want of a better example, we have 1000 arts events and we belatedly realised we should have subdivided them so now we have arts/event1,... arts/event1000 arts is a calendar collection. We're not allowed to create arts/performance alongside the events as we would naturally do in a file system. So we have to do something like rename arts, create a new non-calendar collection and then create the sub-collections. The same is presumably true of auser with a personal calendar who may decide they'd like to subcategorize their personal calendar. Currently our users can subscribe to "arts" and get all the subcategories so I will support report on those collections. > thanks, > Lisa > -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 492707F565 for ; Sat, 20 Aug 2005 16:22:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 2BFB0142279 for ; Sat, 20 Aug 2005 16:22:20 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21763-05; Sat, 20 Aug 2005 16:22:19 -0700 (PDT) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id CDB2E142278; Sat, 20 Aug 2005 16:22:18 -0700 (PDT) In-Reply-To: <43079839.7010100@rpi.edu> References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7e868bbd70fe4a16d2caf107c2bdb4da@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Calendar collections Date: Sat, 20 Aug 2005 16:22:15 -0700 To: Mike Douglass X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sat, 20 Aug 2005 23:22:20 -0000 Hi Mike, I can't see much of a server implementation difficulty difference between allowing calendar collections to contain calendar collections, and on the other hand having a parent collection that can contain multiple calendar collections. I guess it does mean that if your server allows multiple calendar collections you've got to start the user off with a calendar home as well as a starting calendar collection -- then they've got a place to make more calendar collections. If it makes it easier the parent collection *can* contain events -- or if it makes it easier the parent collection might be disabled for any purpose but MKCALENDAR. Your example of somebody interested in all of "arts" is a great example of how somebody can subscribe to a number of calendars. In that case, it would make it easier if the server supported the calendar REPORT queries on the "arts" collection as well as on the calendar collections inside it. Then the user would only have to do one REPORT to see all the events in the next week. This is the same way CalDAV does calendar roll-up for individual users who have multiple calendars. I do understand how reorganization can be a problem but I don't see how allowing calendar collections to nest would help that case. Can you explain that? thanks, Lisa On Aug 20, 2005, at 1:53 PM, Mike Douglass wrote: > The first problem I see for personal users is that we rarely know how > we > want to organize our stuff till we've been at it a while. > > The current restriction by the way seems to require that we make a > users > top level calendar be inside a (virtual) non-calendar collection > otherwise they'd never be able to reorganize their events - because > they > can't create a target collection to move their events into. That is - > as > user douglm I can't have a root calendar collection of douglm/ but > require douglm/calendar > > Performance wasn't my concern. > > For public events organization is more of a problem. We don't reorg > much > but calendars do provide a way for users to select subsets of events > and > occasionally the need arises. For example we might have: > > arts/dance > arts/film > arts/theatre > > or just > > arts/ > > Somebody may be interested enough in the films to want to subscribe to > that calendar in their personal calendar but others may be interested > in > all arts events. > > > Lisa Dusseault wrote: > >> The way we'd been thinking about multiple nested calendar collections >> was that there would have to be some rhyme or reason to why an event >> would be in one or the other. >> >> If a user has two separate calendar collections, home and work, we >> defined what that means -- they really intend the events to be >> displayed separately and probably share those two calendars to >> separate sets of people (this solves required use cases) >> >> But if we have /users/lisa/work, /users/lisa/work/part1 and >> /users/lisa/work/part2 then we have a lot of open issues... >> * How does the client know whether to put an event in >> /users/lisa/work, or in part1 or part2? >> * Does it mean something to have part1 and part2? Are clients >> supposed to display any differently depending on where the event is? >> * Does the server handle the three collections differently? Or do >> they all get included in REPORT? And if they're all in the same >> REPORTs then what's the utility of having them split up? >> * If the 'work' event collection gets split up, how does that >> affect other clients who do synchronization? Can they identify that >> an event was the same as the previous and whether it was changed or >> not? (changes might get lost during a reorg, in other words) >> * Finally, what use cases does it solve? How difficult is it if >> an event collection grows big? How big? Can we characterize the >> cost? >> >> I wouldn't recommend getting users to split their calendar >> collections (although note that I may not understand what use case or >> problem you have in mind when you describe the user moving >> "everything out first") . Unless the user decides they really have >> two semantically different calendars, all the events for a calendar >> really do belong together. At OSAF we're working with moderately >> large 3000-event calendars which is not at all unreasonable to handle >> -- and note that Apple iCal performance seems not to suck even >> putting all those events in one file. >> >> Yes, it's work to enforce the limitation we described, but it's also >> work to handle the flexibility. Work for clients is even worse than >> work for servers. And there's the cost in specification work, >> specification complexity and interoperability testing of the various >> cases and behaviors. The tradeoff Bernard and Cyrus and I have >> settled on so far did involve considering performance and the other >> factors you and I have mentioned. >> >> Lisa >> >> On Aug 20, 2005, at 1:15 PM, Mike Douglass wrote: >> >>> I asked about this but can't find any response: >>> >>> Why this restriction? (4.3): >>> >>> Calendar collections MUST NOT contain other calendar collections. >>> >>> It certainly makes things difficult if my event collection grows big >>> and I want to split it up. As a user I have to move everything out >>> first before I can create sub-collections. >>> >>> It also doesn't correspond to what we expect from most file systems. >>> >>> Just interested in knowing before I implement the not insignificant >>> amount of code to enforce this. >>> >>> >>> -- >>> >>> Mike Douglass douglm@rpi.edu >>> Senior Systems Programmer >>> Communication & Collaboration Technologies 518 276 6780(voice) >>> 2809 >>> (fax) >>> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 >>> >>> _______________________________________________ >>> Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >>> See http://ietf.webdav.org/caldav/ for more CalDAV resources >>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav >> >> > > -- > > Mike Douglass douglm@rpi.edu > Senior Systems Programmer > Communication & Collaboration Technologies 518 276 6780(voice) > 2809 > (fax) > Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 > > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 119EB7F565 for ; Sat, 20 Aug 2005 14:52:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id ED9F2142279 for ; Sat, 20 Aug 2005 14:52:07 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22059-05 for ; Sat, 20 Aug 2005 14:52:07 -0700 (PDT) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by smtp.osafoundation.org (Postfix) with ESMTP id 6F3DE142278 for ; Sat, 20 Aug 2005 14:52:07 -0700 (PDT) Received: from [192.168.168.10] (unverified [69.92.70.67]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 27920611 for ; Sat, 20 Aug 2005 15:51:21 -0700 Message-ID: <4307A604.30402@Royer.com> Date: Sat, 20 Aug 2005 15:52:04 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Calendar collections References: <43078F44.50008@rpi.edu> <43079839.7010100@rpi.edu> In-Reply-To: <43079839.7010100@rpi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010201080805020906000608" X-IP-stats: Incoming Outgoing Last 1, First 8, in=12, out=10, spam=0 Known=true X-External-IP: 69.92.70.67 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sat, 20 Aug 2005 21:52:08 -0000 This is a cryptographically signed message in MIME format. --------------ms010201080805020906000608 Content-Type: multipart/mixed; boundary="------------080503050602040801030002" This is a multi-part message in MIME format. --------------080503050602040801030002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In addition to Lisa's comments: iCalendar does not support nested calendars. So this would open up for a redesign of iCal at a time when simplifications and clarifications of iCal are in progress. The reason iCal does not have nested or layered calendars has already been discussed on this and the old CALSCH mailing list. In summary: It causes all kinds of roll-up problems with busy time, permissions, the reasons Lisa gave, and more. There is no reason that your user interface can not make calendars appear nested or layered. iCal does not need to support this feature in order for your user interface to provide nested views. Mike Douglass wrote: > The first problem I see for personal users is that we rarely know how we > want to organize our stuff till we've been at it a while. > > The current restriction by the way seems to require that we make a users > top level calendar be inside a (virtual) non-calendar collection > otherwise they'd never be able to reorganize their events - because they > can't create a target collection to move their events into. That is - as > user douglm I can't have a root calendar collection of douglm/ but > require douglm/calendar > > Performance wasn't my concern. > > For public events organization is more of a problem. We don't reorg much > but calendars do provide a way for users to select subsets of events and > occasionally the need arises. For example we might have: > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080503050602040801030002 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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------080503050602040801030002-- --------------ms010201080805020906000608 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 9w0BCQUxDxcNMDUwODIwMjE1MjA0WjAjBgkqhkiG9w0BCQQxFgQU9qUDFiqSniaaT8toCjlO 98NfcxMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAKunsKqpykdILqqlbGPo4I+myU5AvKOYhxwNGuvdtXybCeEjjVqOL06a1TMbLIN3K obDhFGpcxdgGg3DOaBkOx7J347sfPNY2eKQ7T5BzR6qDffldq3mbHHBk3cb/4b6x99vnnzDw bqCGKLsCJ70dXZ+cdKjAUkKXq7z8Fwf7MmcfqF3dN4pMlA5FIF55kpMAOWWAne6qyA4hGd/3 B1VInu39DmEF4iQsuYHkW6SGSavDAMHl3yGkV5+SSqVN/xfz1YDMd220Ipjm/Fzm8Id2+0Zv BscGmj/l9Ln3LCShuFbNYtoTYIweimsBl7B+KcBni3uS0tyAYc6ReYWdY/be/wAAAAAAAA== --------------ms010201080805020906000608-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6E6627F565 for ; Sat, 20 Aug 2005 13:53:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 4FFB2142272 for ; Sat, 20 Aug 2005 13:53:21 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21629-01 for ; Sat, 20 Aug 2005 13:53:20 -0700 (PDT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id B5B0014226E for ; Sat, 20 Aug 2005 13:53:20 -0700 (PDT) Received: from [192.168.0.103] (vpn-832.nss.rpi.edu [128.113.211.82]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j7KKrIKB005861 for ; Sat, 20 Aug 2005 16:53:19 -0400 Message-ID: <43079839.7010100@rpi.edu> Date: Sat, 20 Aug 2005 16:53:13 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Calendar collections References: <43078F44.50008@rpi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sat, 20 Aug 2005 20:53:21 -0000 The first problem I see for personal users is that we rarely know how we want to organize our stuff till we've been at it a while. The current restriction by the way seems to require that we make a users top level calendar be inside a (virtual) non-calendar collection otherwise they'd never be able to reorganize their events - because they can't create a target collection to move their events into. That is - as user douglm I can't have a root calendar collection of douglm/ but require douglm/calendar Performance wasn't my concern. For public events organization is more of a problem. We don't reorg much but calendars do provide a way for users to select subsets of events and occasionally the need arises. For example we might have: arts/dance arts/film arts/theatre or just arts/ Somebody may be interested enough in the films to want to subscribe to that calendar in their personal calendar but others may be interested in all arts events. Lisa Dusseault wrote: > The way we'd been thinking about multiple nested calendar collections > was that there would have to be some rhyme or reason to why an event > would be in one or the other. > > If a user has two separate calendar collections, home and work, we > defined what that means -- they really intend the events to be > displayed separately and probably share those two calendars to > separate sets of people (this solves required use cases) > > But if we have /users/lisa/work, /users/lisa/work/part1 and > /users/lisa/work/part2 then we have a lot of open issues... > * How does the client know whether to put an event in > /users/lisa/work, or in part1 or part2? > * Does it mean something to have part1 and part2? Are clients > supposed to display any differently depending on where the event is? > * Does the server handle the three collections differently? Or do > they all get included in REPORT? And if they're all in the same > REPORTs then what's the utility of having them split up? > * If the 'work' event collection gets split up, how does that > affect other clients who do synchronization? Can they identify that an > event was the same as the previous and whether it was changed or not? > (changes might get lost during a reorg, in other words) > * Finally, what use cases does it solve? How difficult is it if an > event collection grows big? How big? Can we characterize the cost? > > I wouldn't recommend getting users to split their calendar collections > (although note that I may not understand what use case or problem you > have in mind when you describe the user moving "everything out > first") . Unless the user decides they really have two semantically > different calendars, all the events for a calendar really do belong > together. At OSAF we're working with moderately large 3000-event > calendars which is not at all unreasonable to handle -- and note that > Apple iCal performance seems not to suck even putting all those events > in one file. > > Yes, it's work to enforce the limitation we described, but it's also > work to handle the flexibility. Work for clients is even worse than > work for servers. And there's the cost in specification work, > specification complexity and interoperability testing of the various > cases and behaviors. The tradeoff Bernard and Cyrus and I have > settled on so far did involve considering performance and the other > factors you and I have mentioned. > > Lisa > > On Aug 20, 2005, at 1:15 PM, Mike Douglass wrote: > >> I asked about this but can't find any response: >> >> Why this restriction? (4.3): >> >> Calendar collections MUST NOT contain other calendar collections. >> >> It certainly makes things difficult if my event collection grows big >> and I want to split it up. As a user I have to move everything out >> first before I can create sub-collections. >> >> It also doesn't correspond to what we expect from most file systems. >> >> Just interested in knowing before I implement the not insignificant >> amount of code to enforce this. >> >> >> -- >> >> Mike Douglass douglm@rpi.edu >> Senior Systems Programmer >> Communication & Collaboration Technologies 518 276 6780(voice) 2809 >> (fax) >> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 >> >> _______________________________________________ >> Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DD0707F565 for ; Sat, 20 Aug 2005 13:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id BC91E142272 for ; Sat, 20 Aug 2005 13:30:22 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19122-10; Sat, 20 Aug 2005 13:30:22 -0700 (PDT) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 6FF9914226E; Sat, 20 Aug 2005 13:30:21 -0700 (PDT) In-Reply-To: <43078F44.50008@rpi.edu> References: <43078F44.50008@rpi.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Calendar collections Date: Sat, 20 Aug 2005 13:30:17 -0700 To: Mike Douglass X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sat, 20 Aug 2005 20:30:23 -0000 The way we'd been thinking about multiple nested calendar collections was that there would have to be some rhyme or reason to why an event would be in one or the other. If a user has two separate calendar collections, home and work, we defined what that means -- they really intend the events to be displayed separately and probably share those two calendars to separate sets of people (this solves required use cases) But if we have /users/lisa/work, /users/lisa/work/part1 and /users/lisa/work/part2 then we have a lot of open issues... * How does the client know whether to put an event in /users/lisa/work, or in part1 or part2? * Does it mean something to have part1 and part2? Are clients supposed to display any differently depending on where the event is? * Does the server handle the three collections differently? Or do they all get included in REPORT? And if they're all in the same REPORTs then what's the utility of having them split up? * If the 'work' event collection gets split up, how does that affect other clients who do synchronization? Can they identify that an event was the same as the previous and whether it was changed or not? (changes might get lost during a reorg, in other words) * Finally, what use cases does it solve? How difficult is it if an event collection grows big? How big? Can we characterize the cost? I wouldn't recommend getting users to split their calendar collections (although note that I may not understand what use case or problem you have in mind when you describe the user moving "everything out first") . Unless the user decides they really have two semantically different calendars, all the events for a calendar really do belong together. At OSAF we're working with moderately large 3000-event calendars which is not at all unreasonable to handle -- and note that Apple iCal performance seems not to suck even putting all those events in one file. Yes, it's work to enforce the limitation we described, but it's also work to handle the flexibility. Work for clients is even worse than work for servers. And there's the cost in specification work, specification complexity and interoperability testing of the various cases and behaviors. The tradeoff Bernard and Cyrus and I have settled on so far did involve considering performance and the other factors you and I have mentioned. Lisa On Aug 20, 2005, at 1:15 PM, Mike Douglass wrote: > I asked about this but can't find any response: > > Why this restriction? (4.3): > > Calendar collections MUST NOT contain other calendar collections. > > It certainly makes things difficult if my event collection grows big > and I want to split it up. As a user I have to move everything out > first before I can create sub-collections. > > It also doesn't correspond to what we expect from most file systems. > > Just interested in knowing before I implement the not insignificant > amount of code to enforce this. > > > -- > > Mike Douglass douglm@rpi.edu > Senior Systems Programmer > Communication & Collaboration Technologies 518 276 6780(voice) > 2809 > (fax) > Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8FCE37F561 for ; Sat, 20 Aug 2005 13:25:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 7B885142272 for ; Sat, 20 Aug 2005 13:25:46 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21543-02 for ; Sat, 20 Aug 2005 13:25:46 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by smtp.osafoundation.org (Postfix) with ESMTP id 24C1314226E for ; Sat, 20 Aug 2005 13:25:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 24D503220E0 for ; Sat, 20 Aug 2005 22:23:15 +0200 (CEST) Received: from [192.168.1.126] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id C2D4D3220BF for ; Sat, 20 Aug 2005 22:23:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <43078F44.50008@rpi.edu> References: <43078F44.50008@rpi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <599ff30d14824efdf832e44e99285971@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Calendar collections Date: Sat, 20 Aug 2005 22:27:09 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sat, 20 Aug 2005 20:25:46 -0000 On Aug 20, 2005, at 22:15, Mike Douglass wrote: > Why this restriction? (4.3): > Calendar collections MUST NOT contain other calendar collections. You might want to check the archives for that, it was discussed in the past: http://lists.osafoundation.org/pipermail/ietf-caldav/ Should there be a CalDAV FAQ? Personally I still have the opinion that nested calendars should be possible. regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3810B7F556 for ; Sat, 20 Aug 2005 13:15:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 21611142274 for ; Sat, 20 Aug 2005 13:15:08 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20601-07 for ; Sat, 20 Aug 2005 13:15:07 -0700 (PDT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id BEA86142275 for ; Sat, 20 Aug 2005 13:15:07 -0700 (PDT) Received: from [192.168.0.103] (vpn-832.nss.rpi.edu [128.113.211.82]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j7KKF5Jx025946 for ; Sat, 20 Aug 2005 16:15:06 -0400 Message-ID: <43078F44.50008@rpi.edu> Date: Sat, 20 Aug 2005 16:15:00 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] Calendar collections X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sat, 20 Aug 2005 20:15:08 -0000 I asked about this but can't find any response: Why this restriction? (4.3): Calendar collections MUST NOT contain other calendar collections. It certainly makes things difficult if my event collection grows big and I want to split it up. As a user I have to move everything out first before I can create sub-collections. It also doesn't correspond to what we expect from most file systems. Just interested in knowing before I implement the not insignificant amount of code to enforce this. -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9651A7F4F9 for ; Tue, 16 Aug 2005 09:59:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 8250C142292 for ; Tue, 16 Aug 2005 09:59:49 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27522-06 for ; Tue, 16 Aug 2005 09:59:49 -0700 (PDT) Received: from [10.0.1.5] (c-67-188-209-63.hsd1.ca.comcast.net [67.188.209.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 521DF142291 for ; Tue, 16 Aug 2005 09:59:49 -0700 (PDT) Message-ID: <43021B85.7080909@osafoundation.org> Date: Tue, 16 Aug 2005 09:59:49 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] calendar-schedule support on servers? References: <4301F553.7090308@adevsoft.com> In-Reply-To: <4301F553.7090308@adevsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 16 Aug 2005 16:59:49 -0000 Kervin L. Pierre wrote: > Is there planned support for calendar-schedule, > http://ietfreport.isoc.org/idref/draft-desruisseaux-caldav-sched/ > in any of the servers being developed? definitely in cosmo, at some point down the road. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 547577F51A for ; Tue, 16 Aug 2005 07:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 39954142294 for ; Tue, 16 Aug 2005 07:38:45 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24925-05 for ; Tue, 16 Aug 2005 07:38:45 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id CAA12142291 for ; Tue, 16 Aug 2005 07:38:44 -0700 (PDT) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j7GEaPuG031303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2005 10:36:25 -0400 Date: Tue, 16 Aug 2005 10:38:41 -0400 From: Cyrus Daboo To: "Kervin L. Pierre" , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] calendar-schedule support on servers? Message-ID: In-Reply-To: <4301F553.7090308@adevsoft.com> References: <4301F553.7090308@adevsoft.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 16 Aug 2005 14:38:45 -0000 Hi Kervin, --On August 16, 2005 10:16:51 AM -0400 "Kervin L. Pierre" wrote: > Is there planned support for calendar-schedule, > http://ietfreport.isoc.org/idref/draft-desruisseaux-caldav-sched/ > in any of the servers being developed? > > Oracle? Cosmo? others? > > calendar-schedule's functionality seems > useful, but will it be widely implemented? That draft is still in the early stages and there will likely be some significant revisions over the coming months as the protocol is firmed up. I certainly have plans to add scheduling functionality to our Apache Slide-based CalDAV server and our client product suite, once we get close to a stable spec. I suspect many other will do the same as the scheduling portion of CalDAV is as important as the basic access capability IMHO. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4B2BD7F518 for ; Tue, 16 Aug 2005 07:15:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 3184E142294 for ; Tue, 16 Aug 2005 07:15:23 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24010-05 for ; Tue, 16 Aug 2005 07:15:23 -0700 (PDT) Received: from svr59.edns1.com (svr59.edns1.com [67.15.20.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id ED4D0142291 for ; Tue, 16 Aug 2005 07:15:22 -0700 (PDT) Received: from [12.8.36.193] (port=2367 helo=[192.168.0.70]) by svr59.edns1.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1E52Do-0002tJ-2Q for ietf-caldav@osafoundation.org; Tue, 16 Aug 2005 07:15:20 -0700 Message-ID: <4301F553.7090308@adevsoft.com> Date: Tue, 16 Aug 2005 10:16:51 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr59.edns1.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - adevsoft.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] calendar-schedule support on servers? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 16 Aug 2005 14:15:23 -0000 Hello, Is there planned support for calendar-schedule, http://ietfreport.isoc.org/idref/draft-desruisseaux-caldav-sched/ in any of the servers being developed? Oracle? Cosmo? others? calendar-schedule's functionality seems useful, but will it be widely implemented? Regards, Kervin Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 501E67F552 for ; Fri, 12 Aug 2005 16:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 3AE211422BD for ; Fri, 12 Aug 2005 16:58:55 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09821-03 for ; Fri, 12 Aug 2005 16:58:55 -0700 (PDT) Received: from [10.0.1.5] (c-67-188-209-63.hsd1.ca.comcast.net [67.188.209.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 067EA1422BC for ; Fri, 12 Aug 2005 16:58:54 -0700 (PDT) Message-ID: <42FD37BC.60203@osafoundation.org> Date: Fri, 12 Aug 2005 16:58:52 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] calendar-description property and language References: <42FAB363.3000908@osafoundation.org> <28D85188AF39D10FAC3843FD@ninevah.local> <42FBAA7F.8080803@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Fri, 12 Aug 2005 23:58:55 -0000 Lisa Dusseault wrote: > How about this conformance language: > > This property MAY be protected and SHOULD NOT be returned > by a PROPFIND allprop request (as defined in Section 12.14.1 > of ). Servers MUST preserve the human > language of the description using the xml:lang attribute if > language information is provided by the client, and MUST > provide that information in subsequent PROPFIND responses. i have no problem with that. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F2F6A7F552 for ; Fri, 12 Aug 2005 16:53:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id DF4A21422BD for ; Fri, 12 Aug 2005 16:53:34 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07655-06; Fri, 12 Aug 2005 16:53:34 -0700 (PDT) Received: from lisa.local (unknown [198.144.201.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 96F691422B9; Fri, 12 Aug 2005 16:53:33 -0700 (PDT) Date: Fri, 12 Aug 2005 16:53:30 -0700 To: "Bernard Desruisseaux" , "Cyrus Daboo" Subject: Re: [Ietf-caldav] calendar-description property and language References: <42FAB363.3000908@osafoundation.org> <28D85188AF39D10FAC3843FD@ninevah.local> <42FBAA7F.8080803@oracle.com> From: "Lisa Dusseault" Organization: OSAF Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <42FBAA7F.8080803@oracle.com> User-Agent: Opera M2/8.01 (MacPPC, build 2092) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Fri, 12 Aug 2005 23:53:35 -0000 How about this conformance language: This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of ). Servers MUST preserve the human language of the description using the xml:lang attribute if language information is provided by the client, and MUST provide that information in subsequent PROPFIND responses. Lisa On Thu, 11 Aug 2005 12:43:59 -0700, Bernard Desruisseaux wrote: > Actually this text was copied and pasted from section 5.3. > DAV:supported-privilege-set of RFC 3744 [WebDAV ACL]. > > We wanted the definition of CALDAV:calendar-description > to be in line with the definition of DAV:description. > > xml:lang is discussed in RFC2518, RFC3253, and RFC3744... > but not enough I guess. > > I don't believe you can PROPATCH multiple values of a given > property with different xml:lang values. Nor retrieve multiple > values of a given property with different xml:lang values with > PROPFIND. > > My understanding is that if your server knows of multiple > values for different languages for a given property (by > some proprietary way) it should consider the value of the > Accept-Language request header to decide which value to > return. > > Cheers, > Bernard > > Cyrus Daboo wrote: >> Hi Brian, >> --On August 10, 2005 7:09:39 PM -0700 Brian Moseley >> wrote: >> >>> in defining the calendar-description property, section 4.4.1 mentions >>> that "servers MUST indicate the human language of the description using >>> the xml:lang attribute and SHOULD consider the HTTP Accept-Language >>> request header when selecting one of multiple available languages". >>> >>> what exactly does it mean for a server to "select one of multiple >>> available languages"? does this imply that the server could store >>> multiple values for the property, each corresponding to a different >>> language? i'm not seeing anything in rfc 2518 that supports either >>> setting or returning multiple values for a property, nor do i see >>> anything in the caldav draft that defines sub-elements for the >>> calendar-description element. >> In an ideal world it would be nice to have multilingual webdav >> properties: i.e. the ability to set different values for different >> languages for the same property, and have the server automatically >> return the appropriate language variant of the property value based on >> the Accept-Language header provided by the client. >> In the real world I don't know any servers that can do that, so >> perhaps we are being to optimistic with that sentence in the CalDAV >> spec. >> > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4E1A17F536 for ; Fri, 12 Aug 2005 10:17:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 399591422B6 for ; Fri, 12 Aug 2005 10:17:12 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04989-08 for ; Fri, 12 Aug 2005 10:17:12 -0700 (PDT) Received: from [10.0.1.5] (c-67-188-209-63.hsd1.ca.comcast.net [67.188.209.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 067A9142276 for ; Fri, 12 Aug 2005 10:17:12 -0700 (PDT) Message-ID: <42FCD995.4060903@osafoundation.org> Date: Fri, 12 Aug 2005 10:17:09 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] calendar-description property and language References: <42FAB363.3000908@osafoundation.org> <28D85188AF39D10FAC3843FD@ninevah.local> <42FBAA7F.8080803@oracle.com> In-Reply-To: <42FBAA7F.8080803@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Fri, 12 Aug 2005 17:17:12 -0000 Bernard Desruisseaux wrote: > My understanding is that if your server knows of multiple > values for different languages for a given property (by > some proprietary way) it should consider the value of the > Accept-Language request header to decide which value to > return. thanks for the explanation. i wonder if there are any real-world examples of this behavior. it seems to me like an attempt to be overly accomodating. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 77A947F543 for ; Fri, 12 Aug 2005 00:38:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 519351422A2 for ; Fri, 12 Aug 2005 00:38:42 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25946-10 for ; Fri, 12 Aug 2005 00:38:42 -0700 (PDT) Received: from mail1.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.76.156]) by smtp.osafoundation.org (Postfix) with ESMTP id E4ABC14229E for ; Fri, 12 Aug 2005 00:38:41 -0700 (PDT) Received: from DF-GWY-01.Exchange.Corp.Microsoft.com ([157.54.54.62]) by mail1.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Aug 2005 00:36:13 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.8.109) by DF-GWY-01.Exchange.Corp.microsoft.com (157.54.54.62) with Microsoft SMTP Server id 8.0.324.11; Fri, 12 Aug 2005 07:36:13 +0000 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Aug 2005 00:36:12 -0700 Received: from DF-Scruffy-BHD.Exchange.Microsoft.com ([157.54.54.216]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Aug 2005 00:36:12 -0700 In-Reply-To: <42FBAA7F.8080803@oracle.com> X-OriginalArrivalTime: 12 Aug 2005 07:36:12.0500 (UTC) FILETIME=[8388C940:01C59F10] Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-caldav] calendar-description property and language Date: Fri, 12 Aug 2005 00:26:15 -0700 Message-ID: <6B5F25B9F515B744B97F1B6E99AC9F59145C40@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: [Ietf-caldav] calendar-description property and language Thread-Index: AcWerLymHhN0Le4ZSt+qAfPnLzFOrAAYV3bg From: Cameron Stillion To: "Bernard Desruisseaux" , "Cyrus Daboo" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Fri, 12 Aug 2005 07:38:42 -0000 Localization of compile-time strings is perfectly reasonable, and localizing a server or client is common for vendors who target international markets. But localization of content? Unless it's a bad babelfish-like automated translation, I cannot imagine users wanting to submit multiple values (one for each language), and if they did, which one would a client application display? OS-selected UI language? Application-specific UI language? Keyboard input language? Server-installed language? All could be different, in fact. =20 It's too frightening to pursue... I imagine that separate calendars should be stored and/or generated. And isn't XML/XSL the grand unified theory of serving up special content based on endpoint capabilities? Cameron -----Original Message----- From: ietf-caldav-bounces@osafoundation.org [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of Bernard Desruisseaux Sent: Thursday.11.August.2005 12.44 To: Cyrus Daboo Cc: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] calendar-description property and language Actually this text was copied and pasted from section 5.3. DAV:supported-privilege-set of RFC 3744 [WebDAV ACL]. We wanted the definition of CALDAV:calendar-description to be in line with the definition of DAV:description. xml:lang is discussed in RFC2518, RFC3253, and RFC3744... but not enough I guess. I don't believe you can PROPATCH multiple values of a given property with different xml:lang values. Nor retrieve multiple values of a given property with different xml:lang values with PROPFIND. My understanding is that if your server knows of multiple values for different languages for a given property (by some proprietary way) it should consider the value of the Accept-Language request header to decide which value to return. Cheers, Bernard Cyrus Daboo wrote: > Hi Brian, >=20 > --On August 10, 2005 7:09:39 PM -0700 Brian Moseley=20 > wrote: >=20 >> in defining the calendar-description property, section 4.4.1 mentions >> that "servers MUST indicate the human language of the description=20 >> using the xml:lang attribute and SHOULD consider the HTTP=20 >> Accept-Language request header when selecting one of multiple available languages". >> >> what exactly does it mean for a server to "select one of multiple=20 >> available languages"? does this imply that the server could store=20 >> multiple values for the property, each corresponding to a different=20 >> language? i'm not seeing anything in rfc 2518 that supports either=20 >> setting or returning multiple values for a property, nor do i see=20 >> anything in the caldav draft that defines sub-elements for the=20 >> calendar-description element. >=20 >=20 > In an ideal world it would be nice to have multilingual webdav > properties: i.e. the ability to set different values for different=20 > languages for the same property, and have the server automatically=20 > return the appropriate language variant of the property value based on > the Accept-Language header provided by the client. >=20 > In the real world I don't know any servers that can do that, so=20 > perhaps we are being to optimistic with that sentence in the CalDAV spec. >=20 _______________________________________________ Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org See http://ietf.webdav.org/caldav/ for more CalDAV resources http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 90EB77F51C; Thu, 11 Aug 2005 12:44:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 797AF14229C; Thu, 11 Aug 2005 12:44:21 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24374-06; Thu, 11 Aug 2005 12:44:21 -0700 (PDT) Received: from agminet03.oracle.com (agminet03.oracle.com [141.146.126.230]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 22D0514229A; Thu, 11 Aug 2005 12:44:21 -0700 (PDT) Received: from agminet03.oracle.com (localhost [127.0.0.1]) by agminet03.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7BJiImS000709; Thu, 11 Aug 2005 14:44:18 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet03.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7BJiHKS000696; Thu, 11 Aug 2005 14:44:18 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id j7BJiGwv023200; Thu, 11 Aug 2005 13:44:17 -0600 Received: from [144.23.219.129] (dhcp-ca-montreal-144-23-219-129.ca.oracle.com [144.23.219.129]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7BJi1Ep022925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 11 Aug 2005 13:44:06 -0600 Message-ID: <42FBAA7F.8080803@oracle.com> Date: Thu, 11 Aug 2005 15:43:59 -0400 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] calendar-description property and language References: <42FAB363.3000908@osafoundation.org> <28D85188AF39D10FAC3843FD@ninevah.local> In-Reply-To: <28D85188AF39D10FAC3843FD@ninevah.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 11 Aug 2005 19:44:21 -0000 Actually this text was copied and pasted from section 5.3. DAV:supported-privilege-set of RFC 3744 [WebDAV ACL]. We wanted the definition of CALDAV:calendar-description to be in line with the definition of DAV:description. xml:lang is discussed in RFC2518, RFC3253, and RFC3744... but not enough I guess. I don't believe you can PROPATCH multiple values of a given property with different xml:lang values. Nor retrieve multiple values of a given property with different xml:lang values with PROPFIND. My understanding is that if your server knows of multiple values for different languages for a given property (by some proprietary way) it should consider the value of the Accept-Language request header to decide which value to return. Cheers, Bernard Cyrus Daboo wrote: > Hi Brian, > > --On August 10, 2005 7:09:39 PM -0700 Brian Moseley > wrote: > >> in defining the calendar-description property, section 4.4.1 mentions >> that "servers MUST indicate the human language of the description using >> the xml:lang attribute and SHOULD consider the HTTP Accept-Language >> request header when selecting one of multiple available languages". >> >> what exactly does it mean for a server to "select one of multiple >> available languages"? does this imply that the server could store >> multiple values for the property, each corresponding to a different >> language? i'm not seeing anything in rfc 2518 that supports either >> setting or returning multiple values for a property, nor do i see >> anything in the caldav draft that defines sub-elements for the >> calendar-description element. > > > In an ideal world it would be nice to have multilingual webdav > properties: i.e. the ability to set different values for different > languages for the same property, and have the server automatically > return the appropriate language variant of the property value based on > the Accept-Language header provided by the client. > > In the real world I don't know any servers that can do that, so perhaps > we are being to optimistic with that sentence in the CalDAV spec. > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 49EF37F533 for ; Thu, 11 Aug 2005 10:41:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 364DC14229F for ; Thu, 11 Aug 2005 10:41:11 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22997-09 for ; Thu, 11 Aug 2005 10:41:11 -0700 (PDT) Received: from [192.168.101.23] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id ACF6614229E for ; Thu, 11 Aug 2005 10:41:10 -0700 (PDT) Message-ID: <42FB8D66.6010907@osafoundation.org> Date: Thu, 11 Aug 2005 10:39:50 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] calendar-description property and language References: <42FAB363.3000908@osafoundation.org> <28D85188AF39D10FAC3843FD@ninevah.local> In-Reply-To: <28D85188AF39D10FAC3843FD@ninevah.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 11 Aug 2005 17:41:11 -0000 Cyrus Daboo wrote: > In an ideal world it would be nice to have multilingual webdav > properties: i.e. the ability to set different values for different > languages for the same property, and have the server automatically > return the appropriate language variant of the property value based on > the Accept-Language header provided by the client. agree. > In the real world I don't know any servers that can do that, so perhaps > we are being to optimistic with that sentence in the CalDAV spec. ok. i'll ignore the xml:lang attribute for now and wait to see what changes in the next draft. thanks. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9E69A7F532; Thu, 11 Aug 2005 07:04:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 8920E1422A1; Thu, 11 Aug 2005 07:04:12 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21453-02; Thu, 11 Aug 2005 07:04:12 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 27C7C14229F; Thu, 11 Aug 2005 07:04:12 -0700 (PDT) Received: from [10.0.1.2] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j7BE2duG026110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Aug 2005 10:02:39 -0400 Date: Thu, 11 Aug 2005 10:04:08 -0400 From: Cyrus Daboo To: Brian Moseley , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] calendar-description property and language Message-ID: <28D85188AF39D10FAC3843FD@ninevah.local> In-Reply-To: <42FAB363.3000908@osafoundation.org> References: <42FAB363.3000908@osafoundation.org> X-Mailer: Mulberry/4.0.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 11 Aug 2005 14:04:13 -0000 Hi Brian, --On August 10, 2005 7:09:39 PM -0700 Brian Moseley wrote: > in defining the calendar-description property, section 4.4.1 mentions > that "servers MUST indicate the human language of the description using > the xml:lang attribute and SHOULD consider the HTTP Accept-Language > request header when selecting one of multiple available languages". > > what exactly does it mean for a server to "select one of multiple > available languages"? does this imply that the server could store > multiple values for the property, each corresponding to a different > language? i'm not seeing anything in rfc 2518 that supports either > setting or returning multiple values for a property, nor do i see > anything in the caldav draft that defines sub-elements for the > calendar-description element. In an ideal world it would be nice to have multilingual webdav properties: i.e. the ability to set different values for different languages for the same property, and have the server automatically return the appropriate language variant of the property value based on the Accept-Language header provided by the client. In the real world I don't know any servers that can do that, so perhaps we are being to optimistic with that sentence in the CalDAV spec. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DE8DA7F526 for ; Wed, 10 Aug 2005 19:09:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id CA5D81422A3 for ; Wed, 10 Aug 2005 19:09:44 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14422-07 for ; Wed, 10 Aug 2005 19:09:44 -0700 (PDT) Received: from [10.0.1.5] (c-67-188-209-63.hsd1.ca.comcast.net [67.188.209.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 68B4C14229F for ; Wed, 10 Aug 2005 19:09:44 -0700 (PDT) Message-ID: <42FAB363.3000908@osafoundation.org> Date: Wed, 10 Aug 2005 19:09:39 -0700 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] calendar-description property and language X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Thu, 11 Aug 2005 02:09:45 -0000 in defining the calendar-description property, section 4.4.1 mentions that "servers MUST indicate the human language of the description using the xml:lang attribute and SHOULD consider the HTTP Accept-Language request header when selecting one of multiple available languages". what exactly does it mean for a server to "select one of multiple available languages"? does this imply that the server could store multiple values for the property, each corresponding to a different language? i'm not seeing anything in rfc 2518 that supports either setting or returning multiple values for a property, nor do i see anything in the caldav draft that defines sub-elements for the calendar-description element. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B8A1F7F583; Tue, 9 Aug 2005 20:08:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id A3EAD142298; Tue, 9 Aug 2005 20:08:44 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02348-09; Tue, 9 Aug 2005 20:08:44 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.76.22]) by smtp.osafoundation.org (Postfix) with ESMTP id 452AA142294; Tue, 9 Aug 2005 20:08:44 -0700 (PDT) Received: from thare.comcast.net (pcp03614075pcs.micske01.fl.comcast.net[68.84.31.33]) by comcast.net (sccrmhc12) with SMTP id <2005081002292001200pdq60e>; Wed, 10 Aug 2005 02:29:20 +0000 Message-Id: <6.2.1.2.0.20050809222707.01ea2408@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 09 Aug 2005 22:29:26 -0400 To: xcal-dev@inet-consulting.com, xcal-dev@inet-consulting.com From: Tim Hare In-Reply-To: <42F9179B.30008@Royer.com> References: <42F7C417.3050503@Royer.com> <42F8728F.9070808@gmx.de> <42F9179B.30008@Royer.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_40_50, HTML_MESSAGE, MIME_HTML_ONLY X-Spam-Level: Cc: Calsify , CalDAV DevList , "ietf-calendar@imc.org" Subject: [Ietf-caldav] Re: xCal - namespace URL X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 10 Aug 2005 03:08:44 -0000 Actually, if I recall my XML rules, you can code:


<xCal:iCalendar
xmlns:xCal="http://ietf.org/rfc/rfcXXXX.txt">
Namespaces apply to the containing element as well. And I agree that the iCalendar element should be in a namespace. Just for human-readability reasons it associates the iCalendar with the xCal namespace, and that's a good thing to be reminded ot.

At 04:52 PM 8/9/2005, Doug Royer wrote:


Julian Reschke wrote:

Just two quick formal comments...:
1) Is it intentional that in the examples, the iCalendar container element is in no namespace?

I think we need to have it in a namespace.
I can go ether way.

I think we need to define one so that mixed content can
exist in an XML file.

2) I don't think the IETF will let you use something like " http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you probably should use " http://ietf.org/rfc/rfcXXXX" (no extension) instead.

:-)

--

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

              We Do Standards - You Need Standards




Tim Hare
Interested Bystander, Non-Inc. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6DD847F562; Tue, 9 Aug 2005 17:59:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 53AF4142299; Tue, 9 Aug 2005 17:59:41 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31547-08; Tue, 9 Aug 2005 17:59:41 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by smtp.osafoundation.org (Postfix) with ESMTP id B7854142290; Tue, 9 Aug 2005 17:59:40 -0700 (PDT) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 17:59:39 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 17:59:39 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 17:59:39 -0700 Received: from DF-Scruffy-BHD.Exchange.Microsoft.com ([157.54.54.216]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 17:57:12 -0700 In-Reply-To: <42F9164E.6010401@Royer.com> X-OriginalArrivalTime: 10 Aug 2005 00:57:12.0881 (UTC) FILETIME=[71955210:01C59D46] MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-caldav] Re: xCal - resubmitted - file name suffix Date: Tue, 9 Aug 2005 17:59:37 -0700 Message-ID: <6B5F25B9F515B744B97F1B6E99AC9F5914598F@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-caldav] Re: xCal - resubmitted - file name suffix Thread-Index: AcWdI0fChHEkTb7GT2C1BiAAfr3bWgAEcWsQ From: "Cameron Stillion" To: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Calsify , CalDAV DevList , ietf-calendar@imc.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 10 Aug 2005 00:59:41 -0000 The multiple dots have no ill effects to users of Windows versions that support long filenames (XP, 2000, and perhaps 98, though to a limited degree) - only the final dot extension is meaningful when associating application behaviors or displaying icons, etc. The rest of the string is considered the filename sans extension. Like the .tar example, this leaves further "unwrapping" of the file up to the application. -----Original Message----- From: ietf-caldav-bounces@osafoundation.org [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of Doug Royer Sent: Tuesday, August 09, 2005 1:47 PM To: xcal@inet-consulting.com Cc: Calsify; CalDAV DevList; ietf-calendar@imc.org Subject: [Ietf-caldav] Re: xCal - resubmitted - file name suffix [ I have set the REPLY-TO to the xcal@INET-Consulting.com mailing list - This is of interest to CALSIFY and CALDAV users, but not really 'on topic' - Join at http://inet-consulting.com/mailman/listinfo/xcal ] As to the file name suffix point . Many insisted (Mostly Microsoft and Microsoft application developers) that iCal define a file extension. And as I have noticed that MANY implementations store ICS files without their text/calendar MIME header. I suspect many will for xCAL. So without a MIME type in the file, many data typing engines would fail if it were not for a file name suffix. So xCal has a file extension. I do not care what it is. And I do not care how many 'dots' are in the file name as long as the OS's and their applications allow for it. Cameron Stillion wrote: > REBTW2: Extension "stacking" is not "unsupported" by most systems=20 > either. It works fine in Unix, Mac, and Windows. It is supported by some POSIX (UNIX, Linux, BSD, and newer Mac) applications, but not those OS's. In fact on those POSIX OS's the 'dot' means nothing at all and it is simply another character in the file name that can have zero to many 'dot's in the file name. Cameron - Question: Can the windows registry handle multiple DOTs in suffixes to files on what ever are the top most Windows versions in use? My VERY LIMITED knowledge and testing says no, but I might not know what I am doing as I use POSIX systems for almost everything. --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A4CC17F563; Tue, 9 Aug 2005 16:19:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 8D9FE142285; Tue, 9 Aug 2005 16:19:44 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31101-06; Tue, 9 Aug 2005 16:19:44 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 0ED82142284; Tue, 9 Aug 2005 16:19:44 -0700 (PDT) Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j79NJa0A027533 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 9 Aug 2005 16:19:39 -0700 Message-ID: <42F93A08.9030904@Royer.com> Date: Tue, 09 Aug 2005 17:19:36 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: timezone@inet-consulting.com Content-Type: multipart/mixed; boundary="------------090908080802080608050808" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify , CalDAV DevList Subject: [Ietf-caldav] draft-royer-timezone-registry-03.txt X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timezone@inet-consulting.com 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, 09 Aug 2005 23:19:44 -0000 This is a multi-part message in MIME format. --------------090908080802080608050808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [ REPLY-TO set to the time zone mailing list - see end of this message ] I have started the change of removing the SERVER part from the IANA registry. In this draft, the TZID will list the official IANA registry name for the time zone. And the TZURL will point to the server that supplies the details. Discussion takes place on TimeZone@INET-Consulting.com Copies of the draft at: http://INET-Consulting.com/draft-royer-timezone-registry-03.html http://INET-Consulting.com/draft-royer-timezone-registry-03.txt http://INET-Consulting.com/draft-royer-timezone-registry-03.xml JOIN the TimeZone mailing list at: http://inet-consulting.com/mailman/listinfo/timezone -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090908080802080608050808 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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------090908080802080608050808-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 366957F506; Tue, 9 Aug 2005 13:52:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 1ED18142279; Tue, 9 Aug 2005 13:52:51 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30350-06; Tue, 9 Aug 2005 13:52:50 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 22A42142274; Tue, 9 Aug 2005 13:52:50 -0700 (PDT) Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j79Kqiw0025489 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 9 Aug 2005 13:52:46 -0700 Message-ID: <42F9179B.30008@Royer.com> Date: Tue, 09 Aug 2005 14:52:43 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcal-dev@inet-consulting.com References: <42F7C417.3050503@Royer.com> <42F8728F.9070808@gmx.de> In-Reply-To: <42F8728F.9070808@gmx.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040408070303080807090907" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify , CalDAV DevList , "ietf-calendar@imc.org" Subject: [Ietf-caldav] xCal - namespace URL X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: xcal-dev@inet-consulting.com 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, 09 Aug 2005 20:52:51 -0000 This is a cryptographically signed message in MIME format. --------------ms040408070303080807090907 Content-Type: multipart/mixed; boundary="------------030304040503050005060403" This is a multi-part message in MIME format. --------------030304040503050005060403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > > Just two quick formal comments...: > > 1) Is it intentional that in the examples, the iCalendar container > element is in no namespace? I think we need to have it in a namespace. I can go ether way. I think we need to define one so that mixed content can exist in an XML file. > 2) I don't think the IETF will let you use something like > "http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you > probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead. :-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030304040503050005060403 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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------030304040503050005060403-- --------------ms040408070303080807090907 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 9w0BCQUxDxcNMDUwODA5MjA1MjQzWjAjBgkqhkiG9w0BCQQxFgQUNc+a3tU6jKSud9Uq+ulr mNkubNowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEADREAT8UeN0ztxVOF6SO+nwKpVnYa5H1uk410SS/su6f6ggbdlPY0Y4IHdxttGCPr 3st29gOwbGONx7HxOErmTwBcfcPKomLlvHQdYUssDPoeZDyJbvUuh/wFnW+1L3KVCTUVLlR9 wyqvw8d6FMD9m4/RiCCOVfQHHlWkVZuw9245zp8Jppehs2osJGyKRovtsGTNPacyeqcn3a5G e6fq4VYIS5RBWkA1OeQCPcIsfRBa4yf3tzUxMuba+e1WxihLpsOzePR4o/FX4rgmOEI2Avxm +pv7n+wwSeXy5vX6TL+s8AEve1ScWgXqsYK+RkSy4i5XcprCHezSjh2ybw5lfAAAAAAAAA== --------------ms040408070303080807090907-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 88B087F4F9; Tue, 9 Aug 2005 13:47:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 6D1C2142249; Tue, 9 Aug 2005 13:47:19 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30398-09; Tue, 9 Aug 2005 13:47:19 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 519ED142246; Tue, 9 Aug 2005 13:47:18 -0700 (PDT) Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j79KlArd025368 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 9 Aug 2005 13:47:12 -0700 Message-ID: <42F9164E.6010401@Royer.com> Date: Tue, 09 Aug 2005 14:47:10 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcal@inet-consulting.com References: <6B5F25B9F515B744B97F1B6E99AC9F591458F8@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> In-Reply-To: <6B5F25B9F515B744B97F1B6E99AC9F591458F8@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010705010402090100040405" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify , CalDAV DevList , "ietf-calendar@imc.org" Subject: [Ietf-caldav] Re: xCal - resubmitted - file name suffix X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: xcal@inet-consulting.com 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, 09 Aug 2005 20:47:19 -0000 This is a cryptographically signed message in MIME format. --------------ms010705010402090100040405 Content-Type: multipart/mixed; boundary="------------080208010200080206020103" This is a multi-part message in MIME format. --------------080208010200080206020103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [ I have set the REPLY-TO to the xcal@INET-Consulting.com mailing list - This is of interest to CALSIFY and CALDAV users, but not really 'on topic' - Join at http://inet-consulting.com/mailman/listinfo/xcal ] As to the file name suffix point . Many insisted (Mostly Microsoft and Microsoft application developers) that iCal define a file extension. And as I have noticed that MANY implementations store ICS files without their text/calendar MIME header. I suspect many will for xCAL. So without a MIME type in the file, many data typing engines would fail if it were not for a file name suffix. So xCal has a file extension. I do not care what it is. And I do not care how many 'dots' are in the file name as long as the OS's and their applications allow for it. Cameron Stillion wrote: > REBTW2: Extension "stacking" is not "unsupported" by most systems > either. It works fine in Unix, Mac, and Windows. It is supported by some POSIX (UNIX, Linux, BSD, and newer Mac) applications, but not those OS's. In fact on those POSIX OS's the 'dot' means nothing at all and it is simply another character in the file name that can have zero to many 'dot's in the file name. Cameron - Question: Can the windows registry handle multiple DOTs in suffixes to files on what ever are the top most Windows versions in use? My VERY LIMITED knowledge and testing says no, but I might not know what I am doing as I use POSIX systems for almost everything. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080208010200080206020103 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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------080208010200080206020103-- --------------ms010705010402090100040405 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 9w0BCQUxDxcNMDUwODA5MjA0NzEwWjAjBgkqhkiG9w0BCQQxFgQUBnYHXT/d8JZrqnZ0E2jK DVZJIdQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAdvmKddSroEY5t3lXuNkfmV86rli4PUm2x7EwJIK4oV3+u//RS9r55q8PKYz+5Q3i 5UZafrvgxcKZEQKgOIRT1YjKfaw2SnAoAqp3OC/enL/vdFqRveVd5P+z8mMKXepp3UuofpJk +Lu4yjBbGp+GfxRlTLyR6bpOCIi+zSwJitevaXX0nuTUKjVcK6Pu9+Cx8hLBjwMqDwy6Pq14 BaerryGGtaxCdbShG0HPY5DsqeI/cBTj9R6lqIRy3tnw9IA7RXbF4uhqIJY+2q/Rz6U7wIDP FvQ5RZZ6GSuCQx1hGAZN8NWFkLFx3KLV1CKQaE/JDR1zt2e2vVOU5aZTFMrUoAAAAAAAAA== --------------ms010705010402090100040405-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 180E27F55A; Tue, 9 Aug 2005 13:18:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id F0640142274; Tue, 9 Aug 2005 13:18:43 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31281-02; Tue, 9 Aug 2005 13:18:43 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id D5C6114225D; Tue, 9 Aug 2005 13:18:42 -0700 (PDT) Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j79KIVg8025037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 9 Aug 2005 13:18:35 -0700 Message-ID: <42F90F96.7040504@Royer.com> Date: Tue, 09 Aug 2005 14:18:30 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcal@inet-consulting.com Subject: Re: [Ietf-calsify] RE: [Ietf-caldav] xCal - resubmitted. References: <6B5F25B9F515B744B97F1B6E99AC9F591458F8@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> In-Reply-To: <6B5F25B9F515B744B97F1B6E99AC9F591458F8@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000505060505050205020801" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify , CalDAV DevList , "ietf-calendar@imc.org" X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: xcal@inet-consulting.com 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, 09 Aug 2005 20:18:44 -0000 This is a cryptographically signed message in MIME format. --------------ms000505060505050205020801 Content-Type: multipart/mixed; boundary="------------030001070904020705060900" This is a multi-part message in MIME format. --------------030001070904020705060900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [ I have set the REPLY-TO the xcal@INET-Consulting.com mailing list - This is of interest to CALSIFY and CALDAV users, but not really 'on topic' - Join at http://inet-consulting.com/mailman/listinfo/xcal ] > Anyway, is there anyone else who feels as I do that enforcing both xcal > and ical as multipart alternative is overkill? Or is this also beyond > the scope of this proposal? This is left over from the CALSCH days. When Frank, Surendra, and I did the first XCAL, we were told by the AD's at the time that they would not endorse ANOTHER calendar data format, unless it was an alternate view of iCalendar data. So the agreed solution was that xCal objects would be attached as an alternate view to iCal objects. Currently iMIP requires that people use S/MIME. I do not recall seeing many S/MIME iCalendar emails. The danger here is that we re-invent the wheel breaking things. The purpose of CALSIFY is to simplify and make a set of objects and procedures that will enable iCal and vendors to have standard calendaring objects. If we open up the debate to XML 'IS calendaring' then all that is compatibility that we already have is lost. There are many XML parsers out there and XML can be transformed back into iCal (see my posting of the XSLT translation on the xCal mailing list). How do we enable XML and not disrupt iCal ? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030001070904020705060900 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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------030001070904020705060900-- --------------ms000505060505050205020801 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 9w0BCQUxDxcNMDUwODA5MjAxODMwWjAjBgkqhkiG9w0BCQQxFgQUD7Jfxz94TJ2YQa36nTDo thJ+RGEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAkMLCkDSh733CCwwDNZckgy8ghLRn5VVT+T1P8spjPmQ/40Js5TOrkV+6gNAHn3WN WeCI5/f7A34fiG6wpU/qs4QH7B7YUfemZNhwN4SoDXhb+jHhe948bVyn6/T/k+xVBdnTOEla zqUEnJ1FkUgvPW53flhFVht4tHBN6B1iOMUY3uN6UI5C9vzYXXS1xRVeKh8oKk+6GnZm7Pac IuSgCWdaRGHK5ngOYzaZEgZSxxhL9E6Dj9j8i4NH77oyiOd5KTuLi0L4zbLrL/UD67I6y/Lo 8ecDSo647V5NRBjr5R5Rtfselq1956ArPtWrEnPN0T94xfn21AZic9ZU/V/+DwAAAAAAAA== --------------ms000505060505050205020801-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A8E0E7F55A; Tue, 9 Aug 2005 11:37:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 874F4142280; Tue, 9 Aug 2005 11:37:48 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24976-08; Tue, 9 Aug 2005 11:37:48 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by smtp.osafoundation.org (Postfix) with ESMTP id 282A714227E; Tue, 9 Aug 2005 11:37:48 -0700 (PDT) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 11:37:47 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 11:37:47 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 11:37:46 -0700 Received: from DF-Underdog-BHD.Exchange.Microsoft.com ([157.54.6.161]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 11:35:20 -0700 In-Reply-To: <3187F016-B28D-4E3E-83D2-D840A8320DD0@opengroupware.org> X-OriginalArrivalTime: 09 Aug 2005 18:35:20.0665 (UTC) FILETIME=[18D69C90:01C59D11] MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-caldav] xCal - resubmitted. Date: Tue, 9 Aug 2005 11:16:10 -0700 Message-ID: <6B5F25B9F515B744B97F1B6E99AC9F591458F8@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-caldav] xCal - resubmitted. Thread-Index: AcWdArJ+ULqpRic8SbSZxXkScLLiQQAA1Ljw From: "Cameron Stillion" To: "Helge Hess" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Calsify , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 18:37:48 -0000 I appreciate your point Helge - still, the standard can scarcely avoid using a filename (see attachments section) and actually, this seems like a very simple and meaningful place to provide interoperability guidelines. Most other "file format" standards cannot avoid it, or choose instead to specify it. That's probably why it's here in the first place. Are you suggesting we remove all references to filenames/extensions from this draft? And in general, would you say we should not suggest anything outside the internals of the MIME type itself? =20 In practice, I find this incomplete - but if you think it belongs elsewhere, that's fine. REBTW1: the distinction between an encapsulated format and a specialization of a format is a fine one. I rather think extensions are useful hints, not strictly delineations of encapsulation or (indeed) of specialization. But the similarities here are useful. I understand your concern, but the purpose is merely informational, not a strict non-repudiation of format, encoding, or schema. REBTW2: Extension "stacking" is not "unsupported" by most systems either. It works fine in Unix, Mac, and Windows.=20 Anyway, is there anyone else who feels as I do that enforcing both xcal and ical as multipart alternative is overkill? Or is this also beyond the scope of this proposal? -----Original Message----- From: Helge Hess [mailto:helge.hess@opengroupware.org]=20 Sent: Tuesday, August 09, 2005 9:54 AM To: Cameron Stillion Cc: Calsify; CalDAV DevList Subject: Re: [Ietf-caldav] xCal - resubmitted. now thats getting entirely off-topic, but anwyay ... On 9. Aug 2005, at 18:12 Uhr, Cameron Stillion wrote: > (interestingly enough, it seems MacOS is now, in many cases, favoring=20 > file extensions and "all the data in the 'data fork'" rather than=20 > using separate resource forks. Fascinating...) Its that way for a long time (~4 years?), since NeXTstep 5 aka MacOSX. If you are interested on the topic: http://arstechnica.com/reviews/os/macosx-10.4.ars/11 > But philosophically, why not put "publisher's clearinghouse=20 > sweepstakes" on the OUTSIDE of the envelope as well? You can, but you started to discuss clever ways of file extension mapping which is not used that way anywhere (except for informational purposes). This is IMHO out of scope of the RFC, better avoid the whole issue. BTW: the example of "file.xml.xcal" is _not_ the same thing like "file.tar.gz". The latter forms no typing hierarchy but a stacking of formats (converting a .gz will result in a .tar, its not a special type or "subclass" of .tar). BTW2: Few systems support such stacking which is why .tgz is not so unusual either. > If we speak of attachments, we're going to have to pick something to=20 > use in our examples. I don't see how this would matter for the xCal spec. It describes the data format, not the transport and therefore doesn't include any filenames (with or without extensions). Do I miss something? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 06F9F7F552; Tue, 9 Aug 2005 09:54:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id DF9E2142282; Tue, 9 Aug 2005 09:54:40 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27257-03; Tue, 9 Aug 2005 09:54:40 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by smtp.osafoundation.org (Postfix) with ESMTP id 7C60614227E; Tue, 9 Aug 2005 09:54:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id CDBBD31FF30; Tue, 9 Aug 2005 18:48:33 +0200 (CEST) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 5728231B916; Tue, 9 Aug 2005 18:48:32 +0200 (CEST) In-Reply-To: <6B5F25B9F515B744B97F1B6E99AC9F591458B1@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> References: <6B5F25B9F515B744B97F1B6E99AC9F591458B1@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3187F016-B28D-4E3E-83D2-D840A8320DD0@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] xCal - resubmitted. Date: Tue, 9 Aug 2005 18:54:27 +0200 To: "Cameron Stillion" X-Mailer: Apple Mail (2.733) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 16:54:41 -0000 now thats getting entirely off-topic, but anwyay ... On 9. Aug 2005, at 18:12 Uhr, Cameron Stillion wrote: > (interestingly enough, it seems MacOS is now, in many cases, favoring > file extensions and "all the data in the 'data fork'" rather than > using > separate resource forks. Fascinating...) Its that way for a long time (~4 years?), since NeXTstep 5 aka MacOSX. If you are interested on the topic: http://arstechnica.com/reviews/os/macosx-10.4.ars/11 > But philosophically, why not put "publisher's > clearinghouse sweepstakes" on the OUTSIDE of the envelope as well? You can, but you started to discuss clever ways of file extension mapping which is not used that way anywhere (except for informational purposes). This is IMHO out of scope of the RFC, better avoid the whole issue. BTW: the example of "file.xml.xcal" is _not_ the same thing like "file.tar.gz". The latter forms no typing hierarchy but a stacking of formats (converting a .gz will result in a .tar, its not a special type or "subclass" of .tar). BTW2: Few systems support such stacking which is why .tgz is not so unusual either. > If we speak of attachments, we're going to have to pick something > to use in our > examples. I don't see how this would matter for the xCal spec. It describes the data format, not the transport and therefore doesn't include any filenames (with or without extensions). Do I miss something? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B2DB87F56E; Tue, 9 Aug 2005 09:12:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 8E829142282; Tue, 9 Aug 2005 09:12:18 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26556-01; Tue, 9 Aug 2005 09:12:18 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by smtp.osafoundation.org (Postfix) with ESMTP id 27647142279; Tue, 9 Aug 2005 09:12:18 -0700 (PDT) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 09:12:17 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 09:12:15 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 09:12:14 -0700 Received: from DF-Underdog-BHD.Exchange.Microsoft.com ([157.54.6.161]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 09:09:48 -0700 In-Reply-To: <71b769a6632deb7998f6d9309951d2e9@opengroupware.org> X-OriginalArrivalTime: 09 Aug 2005 16:09:48.0785 (UTC) FILETIME=[C43B7610:01C59CFC] MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-caldav] xCal - resubmitted. Date: Tue, 9 Aug 2005 09:12:14 -0700 Message-ID: <6B5F25B9F515B744B97F1B6E99AC9F591458B1@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-caldav] xCal - resubmitted. Thread-Index: AcWc0+H49cBnaneZQDCQO854VYhr+QAJa4DQ From: "Cameron Stillion" To: "Helge Hess" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Calsify , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 16:12:18 -0000 Not instead of - just in addition to. It's just a hint. Windows also has "forested" files, and "structured" files, just like Mac's "resource forks". I agree you'd never want to use a filename INSTEAD of the actual annotations internally. But philosophically, why not put "publisher's clearinghouse sweepstakes" on the OUTSIDE of the envelope as well?=20 Perhaps it doesn't belong in this particular document, though it seems many format documents have trouble avoiding it. If we speak of attachments, we're going to have to pick something to use in our examples. Design sneaks into implementation... (interestingly enough, it seems MacOS is now, in many cases, favoring file extensions and "all the data in the 'data fork'" rather than using separate resource forks. Fascinating...) cameron -----Original Message----- From: ietf-caldav-bounces@osafoundation.org [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of Helge Hess Sent: Tuesday.09.August.2005 04.20 To: Cameron Stillion Cc: Calsify; CalDAV DevList Subject: Re: [Ietf-caldav] xCal - resubmitted. On Aug 9, 2005, at 12:59, Cameron Stillion wrote: > The idea here is to give processing software an idea what is inside=20 > the envelope. If you are familiar with the envelope/letter approach=20 > to data abstraction, it is a very powerful metaphor. This proposal=20 > mentions that it will NOT use .xml as an extensions - presumably for=20 > this same reason. If all applications, MTAs, and processing software=20 > of all operating systems begin to name data files based on the use of=20 > xml, pretty soon all documents will have the .xml extension. Great. =20 > We might as well call everything data.xml, and go ahead with a full=20 > parse of the content to determine what to do next. The performance=20 > implications of this are rather dismal, and the design I find not very > useful. Why NOT give a hint as to the content using an extension? While I agree with all of that, I honestly think that it doesn't belong into a specification on the xCal data format. Standardizing content typing is a completely different story and actually one which is already covered and widely implemented in RFCs:=20 MIME. This is used for both, transmitting iCal/xCal by mail and for storing iCal/xCal content in HTTP servers. How MIME is mapped to local storages (extensions, resource forks, FS annotations, spotlight attributes etc) is entirely operating system dependend. So in my opinion you might want to document a file-extension "best practice" for xCal, but it doesn't really belong into the RFC. The RFC should just outline the MIME type. > I do not know how a more simple and direct way of giving a hint to the > processing software might be, than to annotate the name of the content > - > but I am always willing to learn. What are these "better ways" you=20 > speak of? Well, annotating the content instead of the name? Googling for MacOS resource forks might be a starting point to find out why file extensions are problematic ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org _______________________________________________ Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org See http://ietf.webdav.org/caldav/ for more CalDAV resources http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3BFDF7F56D for ; Tue, 9 Aug 2005 07:29:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 2A90914227E for ; Tue, 9 Aug 2005 07:29:29 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24280-08 for ; Tue, 9 Aug 2005 07:29:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by smtp.osafoundation.org (Postfix) with SMTP id 66225142280 for ; Tue, 9 Aug 2005 07:29:28 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2005 14:29:26 -0000 Received: from p508FAAA5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.165] by mail.gmx.net (mp030) with SMTP; 09 Aug 2005 16:29:26 +0200 X-Authenticated: #1915285 Message-ID: <42F8BDB3.5000100@gmx.de> Date: Tue, 09 Aug 2005 16:29:07 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Connolly Subject: Re: [Ietf-caldav] xCal - resubmitted. References: <42F7C417.3050503@Royer.com> <42F8728F.9070808@gmx.de> <1123597518.18971.922.camel@dirk> In-Reply-To: <1123597518.18971.922.camel@dirk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: xcal-dev@inet-consulting.com, Calsify , "ietf-calendar@imc.org" , Doug Royer , CalDAV DevList , www-rdf-calendar@w3.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 14:29:29 -0000 Dan Connolly wrote: > On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote: > [...] > >>>Copies of the draft at: >>> >>> http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt >>> http://INET-Consulting.com/draft-royer-calsch-xcal-01.html >>> http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml >> >>Just two quick formal comments...: >> >>1) Is it intentional that in the examples, the iCalendar container >>element is in no namespace? >> >>2) I don't think the IETF will let you use something like >>"http://ietf.org/rfc/rfcXXXX.txt" as namespace name; > > > Right; I gather Best Current Practice is... > > [[[ > If the registrant wishes to > have a URI assigned, then a URN of the form > > urn:ietf:params:xml:: > > will be assigned where is the type of the document being > registered (see below). > ]]] > -- http://www.faqs.org/rfcs/rfc3688.html One could probably also use: (see ). > ... Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 797987F56D; Tue, 9 Aug 2005 07:25:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 5CD77142280; Tue, 9 Aug 2005 07:25:20 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25744-03; Tue, 9 Aug 2005 07:25:20 -0700 (PDT) Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by smtp.osafoundation.org (Postfix) with ESMTP id 0B71F14227E; Tue, 9 Aug 2005 07:25:20 -0700 (PDT) Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D29454F3C6; Tue, 9 Aug 2005 10:25:18 -0400 (EDT) Subject: Re: [Ietf-caldav] xCal - resubmitted. From: Dan Connolly To: Julian Reschke In-Reply-To: <42F8728F.9070808@gmx.de> References: <42F7C417.3050503@Royer.com> <42F8728F.9070808@gmx.de> Content-Type: text/plain Organization: World Wide Web Consortium (http://www.w3.org/) Date: Tue, 09 Aug 2005 09:25:18 -0500 Message-Id: <1123597518.18971.922.camel@dirk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: xcal-dev@inet-consulting.com, Calsify , "ietf-calendar@imc.org" , Doug Royer , CalDAV DevList , www-rdf-calendar@w3.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 14:25:20 -0000 On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote: [...] > > Copies of the draft at: > > > > http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt > > http://INET-Consulting.com/draft-royer-calsch-xcal-01.html > > http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml > Just two quick formal comments...: > > 1) Is it intentional that in the examples, the iCalendar container > element is in no namespace? > > 2) I don't think the IETF will let you use something like > "http://ietf.org/rfc/rfcXXXX.txt" as namespace name; Right; I gather Best Current Practice is... [[[ If the registrant wishes to have a URI assigned, then a URN of the form urn:ietf:params:xml:: will be assigned where is the type of the document being registered (see below). ]]] -- http://www.faqs.org/rfcs/rfc3688.html Meanwhile, you can get an http namespace name from W3C if you like: "W3C provides the service of allocating and maintaining persistent URIs so that those URIs remain stable during discussions. Allocation does not imply any endorsement by W3C of the related specifications." -- http://www.w3.org/1999/10/nsuri see for example http://www.w3.org/2005/Atom > but if they do, you > probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead. Actually I think the .txt form is more official: [[ The full text of the specification is then available using the following URL: http://www.ietf.org/rfc/rfcNNNN.txt where "NNNN" is the number of the RFC being submitted. ]] -- section 3.4.2 Submitting IETF Documents to JTC1 http://www.ietf.org/rfc/rfc3563.txt The /rfc/rfcXXXX form is supported by accident, as far as I can tell. > Best regards, Julian -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 04A327F563; Tue, 9 Aug 2005 04:19:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id DFBB4142280; Tue, 9 Aug 2005 04:19:09 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24009-01; Tue, 9 Aug 2005 04:19:09 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by smtp.osafoundation.org (Postfix) with ESMTP id 49F4D14227E; Tue, 9 Aug 2005 04:19:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id BAF5A320990; Tue, 9 Aug 2005 13:13:00 +0200 (CEST) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 6AD8332098E; Tue, 9 Aug 2005 13:13:00 +0200 (CEST) In-Reply-To: <6B5F25B9F515B744B97F1B6E99AC9F591458A5@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> References: <6B5F25B9F515B744B97F1B6E99AC9F591458A5@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71b769a6632deb7998f6d9309951d2e9@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] xCal - resubmitted. Date: Tue, 9 Aug 2005 13:20:22 +0200 To: "Cameron Stillion" X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 11:19:10 -0000 On Aug 9, 2005, at 12:59, Cameron Stillion wrote: > The idea here is to give processing software an idea what is inside the > envelope. If you are familiar with the envelope/letter approach to > data > abstraction, it is a very powerful metaphor. This proposal mentions > that it will NOT use .xml as an extensions - presumably for this same > reason. If all applications, MTAs, and processing software of all > operating systems begin to name data files based on the use of xml, > pretty soon all documents will have the .xml extension. Great. We > might > as well call everything data.xml, and go ahead with a full parse of the > content to determine what to do next. The performance implications of > this are rather dismal, and the design I find not very useful. Why NOT > give a hint as to the content using an extension? While I agree with all of that, I honestly think that it doesn't belong into a specification on the xCal data format. Standardizing content typing is a completely different story and actually one which is already covered and widely implemented in RFCs: MIME. This is used for both, transmitting iCal/xCal by mail and for storing iCal/xCal content in HTTP servers. How MIME is mapped to local storages (extensions, resource forks, FS annotations, spotlight attributes etc) is entirely operating system dependend. So in my opinion you might want to document a file-extension "best practice" for xCal, but it doesn't really belong into the RFC. The RFC should just outline the MIME type. > I do not know how a more simple and direct way of giving a hint to the > processing software might be, than to annotate the name of the content > - > but I am always willing to learn. What are these "better ways" you > speak of? Well, annotating the content instead of the name? Googling for MacOS resource forks might be a starting point to find out why file extensions are problematic ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CE50A7F563; Tue, 9 Aug 2005 03:59:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id AE64D142281; Tue, 9 Aug 2005 03:59:12 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23061-06; Tue, 9 Aug 2005 03:59:12 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by smtp.osafoundation.org (Postfix) with ESMTP id 450EF142280; Tue, 9 Aug 2005 03:59:12 -0700 (PDT) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 03:59:11 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 03:59:11 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 03:59:11 -0700 Received: from DF-Underdog-BHD.Exchange.Microsoft.com ([157.54.6.161]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 03:56:45 -0700 In-Reply-To: <200508091222.37067.reinhold@kainhofer.com> X-OriginalArrivalTime: 09 Aug 2005 10:56:45.0221 (UTC) FILETIME=[085B0D50:01C59CD1] MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-caldav] xCal - resubmitted. Date: Tue, 9 Aug 2005 03:59:08 -0700 Message-ID: <6B5F25B9F515B744B97F1B6E99AC9F591458A5@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-caldav] xCal - resubmitted. Thread-Index: AcWcy/QT42MBAHuaSauAyOAzhGZXGgABCfZQ From: "Cameron Stillion" To: "Reinhold Kainhofer" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Calsify , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 10:59:13 -0000 I'm glad there are others who remember such tools. Surely there are more stringent mechanisms than looking at the file extension - this is simply the first hint. This is the reason that file extensions were invented, to give the first hint as to what to do with the file. It treats the file as an object, and lends the file system an object-oriented nature. Applications, verbs, or actions can be associated with extensions or schemes, or both. =20 Granted, it is not the last word. I can rename a text file with .exe or .tar, but in unix or windows or osx, this does not mean it will execute... And this approach is not specific to any particular OS, to be sure. The idea here is to give processing software an idea what is inside the envelope. If you are familiar with the envelope/letter approach to data abstraction, it is a very powerful metaphor. This proposal mentions that it will NOT use .xml as an extensions - presumably for this same reason. If all applications, MTAs, and processing software of all operating systems begin to name data files based on the use of xml, pretty soon all documents will have the .xml extension. Great. We might as well call everything data.xml, and go ahead with a full parse of the content to determine what to do next. The performance implications of this are rather dismal, and the design I find not very useful. Why NOT give a hint as to the content using an extension?=20 I do not know how a more simple and direct way of giving a hint to the processing software might be, than to annotate the name of the content - but I am always willing to learn. What are these "better ways" you speak of?=20 Cameron -----Original Message----- From: Reinhold Kainhofer [mailto:reinhold@kainhofer.com]=20 Sent: Tuesday.09.August.2005 03.23 To: Cameron Stillion Cc: Calsify; CalDAV DevList Subject: Re: [Ietf-caldav] xCal - resubmitted. On Tuesday 09 August 2005 11:35, Cameron Stillion wrote: > 2.12 > how about using a double extension - .xml.xcs > This is reminiscent of tar files for those who are ancient enough to=20 > remember those Sorry, but just because tar archives are not common under Windows, doesn't mean they are ancient. In fact, they are the most common compressed archive format in Linux and also on Unix systems, far more popular than zip files!=20 E.g. almost all source code for Linux applications (if not accessed through svn, cvs or some other versioning system) is distributed as gzipped tar files or bziped tar files.=20 > - anytime to add another layer of > schematization over a file, you add an extension. Why don't we follow > the same pattern? I can't think of a good reason not to. File names (and thus also the part after a period in the file name) in Linux don't really have such a strong binding to the file type than the file name extensions in Windows.=20 > While you're at it - why not go another step further and specify file=20 > extensions for the different types of iCals (which the ical standard=20 > unfortunately failed to do) - for instance, a meeting request=20 > "method=3D'request'" might have an extension of .xrc while a published = > calendar "method=3D'publish'" might have an extension of .xcs - this=20 > gives everyone a much more tangible understanding of the data without=20 > having to crack it and parse it first. There's a thought. As I said, in Linux and unix systems, the file name extension is typically not associated with the file content as strong as Windows uses them. Sure, they can be used to indicate the type of a file, but that's noting more than an indication and doesn't mean it really has to be that type of file. There are better means of determining the contents of a file in Linux. Cheers, Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4D1837F563; Tue, 9 Aug 2005 03:22:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 258B7142280; Tue, 9 Aug 2005 03:22:45 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23524-01; Tue, 9 Aug 2005 03:22:44 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 75D22142279; Tue, 9 Aug 2005 03:22:44 -0700 (PDT) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3) with ESMTP id j79AMb3k009993; Tue, 9 Aug 2005 12:22:39 +0200 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: "Cameron Stillion" Subject: Re: [Ietf-caldav] xCal - resubmitted. Date: Tue, 9 Aug 2005 12:22:31 +0200 User-Agent: KMail/1.8.90 References: <6B5F25B9F515B744B97F1B6E99AC9F591458A4@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> In-Reply-To: <6B5F25B9F515B744B97F1B6E99AC9F591458A4@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3176406.cJ48L3No6I"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508091222.37067.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Calsify , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 10:22:45 -0000 --nextPart3176406.cJ48L3No6I Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 09 August 2005 11:35, Cameron Stillion wrote: > 2.12 > how about using a double extension - .xml.xcs > This is reminiscent of tar files for those who are ancient > enough to remember those=20 Sorry, but just because tar archives are not common under Windows, doesn't= =20 mean they are ancient. In fact, they are the most common compressed archive= =20 format in Linux and also on Unix systems, far more popular than zip files!= =20 E.g. almost all source code for Linux applications (if not accessed through= =20 svn, cvs or some other versioning system) is distributed as gzipped tar fil= es=20 or bziped tar files.=20 > - anytime to add another layer of=20 > schematization over a file, you add an extension. Why don't we follow > the same pattern? I can't think of a good reason not to. =46ile names (and thus also the part after a period in the file name) in Li= nux=20 don't really have such a strong binding to the file type than the file name= =20 extensions in Windows.=20 > While you're at it - why not go another step further and specify > file extensions for the different types of iCals (which the ical > standard unfortunately failed to do) - for instance, a meeting request > "method=3D'request'" might have an extension of .xrc while a published > calendar "method=3D'publish'" might have an extension of .xcs - this gives > everyone a much more tangible understanding of the data without having > to crack it and parse it first. There's a thought. As I said, in Linux and unix systems, the file name extension is typically = not=20 associated with the file content as strong as Windows uses them. Sure, they= =20 can be used to indicate the type of a file, but that's noting more than an= =20 indication and doesn't mean it really has to be that type of file. There ar= e=20 better means of determining the contents of a file in Linux. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer --nextPart3176406.cJ48L3No6I Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBC+IPtTqjEwhXvPN0RAnUpAJ9iXk6TXHLA6cG6B1OXw7oBWKfHtACeNKNs m4y0JDwTfoti80+GNI3UmlQ= =Hp7N -----END PGP SIGNATURE----- --nextPart3176406.cJ48L3No6I-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 677997F563; Tue, 9 Aug 2005 02:50:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 4973A142280; Tue, 9 Aug 2005 02:50:35 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22980-04; Tue, 9 Aug 2005 02:50:35 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by smtp.osafoundation.org (Postfix) with ESMTP id 02E3D142273; Tue, 9 Aug 2005 02:50:34 -0700 (PDT) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 02:50:34 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 02:50:34 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 02:50:33 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 02:48:06 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 02:32:45 -0700 Received: from DF-Underdog-BHD.Exchange.Microsoft.com ([157.54.6.161]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 02:32:44 -0700 In-Reply-To: <42F8728F.9070808@gmx.de> X-OriginalArrivalTime: 09 Aug 2005 09:32:44.0639 (UTC) FILETIME=[4BEF46F0:01C59CC5] Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-caldav] xCal - resubmitted. Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 02:35:09 -0700 Message-ID: <6B5F25B9F515B744B97F1B6E99AC9F591458A4@DF-SCRUFFY-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Ietf-caldav] xCal - resubmitted. Thread-Index: AcWcwcBb05r0QopzRrqUhjyKd2XbRQAAaOyg X-Priority: 5 Priority: Non-Urgent Importance: low From: "Cameron Stillion" To: "Doug Royer" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: Cc: xcal-dev@inet-consulting.com, Calsify , CalDAV DevList , www-rdf-calendar@w3.org, ietf-calendar@imc.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 09:50:35 -0000 2.2.1 Are you minimizing the difference between the inherent unicode capabilities of XML and the rather esoteric encoding requirements of iCal? Simply wrapping the data in tags is not really enough... 2.2.2 isomeric - I think you mean "isometric". Ah, the difference one character can make... also - why is it required to send an alternate MIME body part in normal iCal format? Is this format designed to replace the old format? Ultimately? If so, why should both be required? iCal readers of old can read xcal via transform, and new applications can easily parse using a standard xml parser... Why limit all uses of this to also implement the old way of doing things? This seems counter productive to me. 2.11 why not simply use "text/xcal" ?=20 again, why the restriction for backwards compatability? This sounds like you are enforcing client functionality. How about you allow the MTA or client application to determine whether or not to send a downlevel representation? 2.12 how about using a double extension - .xml.xcs This is reminiscent of tar files for those who are ancient enough to remember those - anytime to add another layer of schematization over a file, you add an extension. Why don't we follow the same pattern? I can't think of a good reason not to. While you're at it - why not go another step further and specify file extensions for the different types of iCals (which the ical standard unfortunately failed to do) - for instance, a meeting request "method=3D'request'" might have an extension of .xrc while a published calendar "method=3D'publish'" might have an extension of .xcs - this = gives everyone a much more tangible understanding of the data without having to crack it and parse it first. There's a thought. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D0E997F563 for ; Tue, 9 Aug 2005 02:08:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id B437C142282 for ; Tue, 9 Aug 2005 02:08:42 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16547-07 for ; Tue, 9 Aug 2005 02:08:42 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by smtp.osafoundation.org (Postfix) with SMTP id EA5A8142280 for ; Tue, 9 Aug 2005 02:08:41 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2005 09:08:40 -0000 Received: from p508FAAA5.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.165] by mail.gmx.net (mp027) with SMTP; 09 Aug 2005 11:08:40 +0200 X-Authenticated: #1915285 Message-ID: <42F8728F.9070808@gmx.de> Date: Tue, 09 Aug 2005 11:08:31 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Royer Subject: Re: [Ietf-caldav] xCal - resubmitted. References: <42F7C417.3050503@Royer.com> In-Reply-To: <42F7C417.3050503@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: xcal-dev@inet-consulting.com, Calsify , CalDAV DevList , www-rdf-calendar@w3.org, "ietf-calendar@imc.org" X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 09 Aug 2005 09:08:42 -0000 Doug Royer wrote: > > > The xCal draft has been rewritten and submitted to the IETF. > > I have an XSLT translation file that I will be releasing > soon on SourceForge that can translate an xCal object > back to an iCal object. I am waiting for SourceForge > to approve the project name. > > Discussion takes place on xCal@INET-Consulting.com > > Copies of the draft at: > > http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt > http://INET-Consulting.com/draft-royer-calsch-xcal-01.html > http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml > > > JOIN the xCal mailing list at: > > http://inet-consulting.com/mailman/listinfo/xcal > Just two quick formal comments...: 1) Is it intentional that in the examples, the iCalendar container element is in no namespace? 2) I don't think the IETF will let you use something like "http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead. Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6CFF27F55C; Mon, 8 Aug 2005 13:44:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 5708914227E; Mon, 8 Aug 2005 13:44:18 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13482-07; Mon, 8 Aug 2005 13:44:18 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id D089114227D; Mon, 8 Aug 2005 13:44:17 -0700 (PDT) Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j78Ki7ko031942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 8 Aug 2005 13:44:09 -0700 Message-ID: <42F7C417.3050503@Royer.com> Date: Mon, 08 Aug 2005 14:44:07 -0600 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcal-dev@inet-consulting.com Content-Type: multipart/mixed; boundary="------------040500060400060002010604" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify , CalDAV DevList , www-rdf-calendar@w3.org, "ietf-calendar@imc.org" Subject: [Ietf-caldav] xCal - resubmitted. X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 08 Aug 2005 20:44:18 -0000 This is a multi-part message in MIME format. --------------040500060400060002010604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The xCal draft has been rewritten and submitted to the IETF. I have an XSLT translation file that I will be releasing soon on SourceForge that can translate an xCal object back to an iCal object. I am waiting for SourceForge to approve the project name. Discussion takes place on xCal@INET-Consulting.com Copies of the draft at: http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt http://INET-Consulting.com/draft-royer-calsch-xcal-01.html http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml JOIN the xCal mailing list at: http://inet-consulting.com/mailman/listinfo/xcal -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040500060400060002010604 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:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040500060400060002010604-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B13AB7F4FD for ; Mon, 8 Aug 2005 11:57:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 9A8C1142274 for ; Mon, 8 Aug 2005 11:57:35 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12114-07 for ; Mon, 8 Aug 2005 11:57:35 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 3698714226B for ; Mon, 8 Aug 2005 11:57:35 -0700 (PDT) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j78IuRuG019688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2005 14:56:28 -0400 Date: Mon, 08 Aug 2005 14:57:30 -0400 From: Cyrus Daboo To: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] caldav global addressbook Message-ID: <18DDB6E39446D90D77A4E8B7@ninevah.cyrusoft.com> In-Reply-To: <42F7A36A.2000505@adevsoft.com> References: <42F784F1.5030705@adevsoft.com> <42F7A36A.2000505@adevsoft.com> X-Mailer: Mulberry/4.0.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 08 Aug 2005 18:57:35 -0000 Hi Kervin, --On August 8, 2005 2:24:42 PM -0400 "Kervin L. Pierre" wrote: >> What type of 'discovery' do you want? Right now there is a way for an >> individual to find their own 'calendar-home' directory (which would be >> the 'root' of their personal calendars) and for an individual to find >> 'calendar-homes' of other users. > > My client is a Microsoft Outlook extension, > [ http://openconnector.org/ ]. I am mapping > the Outlook/MAPI addressbook interface to > CalDAV. Ie. remote, read-only address book. > > To do this, the server would have to be able > to return all principles ( with correct > permissions of course ), and hopefully run a > principle search based on a regular expression > provided by the client. > > What I am looking for, I believe, is > 'calendar-address-set' property > [ http://ietfreport.isoc.org/idref/draft-dusseault-caldav/#page-22 ] > with regex functionality. Does this exist? > > Eg.... > > > > > mailto:.* > Assuming that WebDAV principals had an 'email-address' property, then you could use the usual WebDAV ACL reports to list and query such principals. However, CalDAV does not require any type of email address attribute. That is something that you would have to do outside of CalDAV. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 66C657F55C for ; Mon, 8 Aug 2005 11:23:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 50C8E142274 for ; Mon, 8 Aug 2005 11:23:26 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13323-03 for ; Mon, 8 Aug 2005 11:23:26 -0700 (PDT) Received: from svr59.edns1.com (svr59.edns1.com [67.15.20.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 0C167142260 for ; Mon, 8 Aug 2005 11:23:26 -0700 (PDT) Received: from rrcs-24-227-116-130.se.biz.rr.com ([24.227.116.130]:64986 helo=[10.55.10.20]) by svr59.edns1.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1E2CHQ-0002xl-PW; Mon, 08 Aug 2005 11:23:21 -0700 Message-ID: <42F7A36A.2000505@adevsoft.com> Date: Mon, 08 Aug 2005 14:24:42 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] caldav global addressbook References: <42F784F1.5030705@adevsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr59.edns1.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - adevsoft.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 08 Aug 2005 18:23:26 -0000 Hello Cyrus, Cyrus Daboo wrote: > > What type of 'discovery' do you want? Right now there is a way for an > individual to find their own 'calendar-home' directory (which would be > the 'root' of their personal calendars) and for an individual to find > 'calendar-homes' of other users. My client is a Microsoft Outlook extension, [ http://openconnector.org/ ]. I am mapping the Outlook/MAPI addressbook interface to CalDAV. Ie. remote, read-only address book. To do this, the server would have to be able to return all principles ( with correct permissions of course ), and hopefully run a principle search based on a regular expression provided by the client. What I am looking for, I believe, is 'calendar-address-set' property [ http://ietfreport.isoc.org/idref/draft-dusseault-caldav/#page-22 ] with regex functionality. Does this exist? Eg.... mailto:.* Or.... mailto:bernard@.* Regards, Kervin Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1ADEB7F543 for ; Mon, 8 Aug 2005 09:19:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 04D53142274 for ; Mon, 8 Aug 2005 09:19:42 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11096-10 for ; Mon, 8 Aug 2005 09:19:41 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 93C53142273 for ; Mon, 8 Aug 2005 09:19:41 -0700 (PDT) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j78GIPuG016801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2005 12:18:25 -0400 Date: Mon, 08 Aug 2005 12:19:27 -0400 From: Cyrus Daboo To: "Kervin L. Pierre" , CalDAV DevList Subject: Re: [Ietf-caldav] caldav global addressbook Message-ID: In-Reply-To: <42F784F1.5030705@adevsoft.com> References: <42F784F1.5030705@adevsoft.com> X-Mailer: Mulberry/4.0.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 08 Aug 2005 16:19:42 -0000 Hi Kervin, --On August 8, 2005 12:14:41 PM -0400 "Kervin L. Pierre" wrote: > Apologies if I've missed something obvious or > a previous discussion, but what are the current > recommendations, if any, for a global addressbook > on a CalDAV server? CalDAV has nothing to say about address books. However, I am working on a CalDAV-like proposal for the smart storage/retrieval of vCards in WebDAV. That would probably be what you want for handling personal address books (as opposed to directories which should be LDAP-based). > Does/will the CalDAV protocol support any features > that allows the discovery of other calendars on > the same CalDAV server? What type of 'discovery' do you want? Right now there is a way for an individual to find their own 'calendar-home' directory (which would be the 'root' of their personal calendars) and for an individual to find 'calendar-homes' of other users. There is no way to automatically discover other types of hierarchy (e.g. for public calendars, calendars of non-principals (rooms, printers etc)). At one point there was a 'namespace' option in CalDAV that was similar to the NAMESPACE extension in IMAP, that would provide for a broad discovery option, but that was dropped for various reasons. It could still be resurrected as an extension at some later point if the need arose. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 35BE87F53D for ; Mon, 8 Aug 2005 09:13:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 20B9E142274 for ; Mon, 8 Aug 2005 09:13:24 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09371-02 for ; Mon, 8 Aug 2005 09:13:23 -0700 (PDT) Received: from svr59.edns1.com (svr59.edns1.com [67.15.20.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id DFB5D142273 for ; Mon, 8 Aug 2005 09:13:23 -0700 (PDT) Received: from [12.8.36.193] (port=1114 helo=[192.168.0.70]) by svr59.edns1.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1E2AFb-00024J-QS for ietf-caldav@osafoundation.org; Mon, 08 Aug 2005 09:13:19 -0700 Message-ID: <42F784F1.5030705@adevsoft.com> Date: Mon, 08 Aug 2005 12:14:41 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr59.edns1.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - adevsoft.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] caldav global addressbook X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 08 Aug 2005 16:13:24 -0000 Hello, Apologies if I've missed something obvious or a previous discussion, but what are the current recommendations, if any, for a global addressbook on a CalDAV server? Does/will the CalDAV protocol support any features that allows the discovery of other calendars on the same CalDAV server? Regards, Kervin Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4EBBF7F549 for ; Thu, 4 Aug 2005 09:31:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 3B32E142271 for ; Thu, 4 Aug 2005 09:31:14 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28879-10 for ; Thu, 4 Aug 2005 09:31:14 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by smtp.osafoundation.org (Postfix) with SMTP id DE38A142270 for ; Thu, 4 Aug 2005 09:31:13 -0700 (PDT) Received: (qmail 4304 invoked from network); 4 Aug 2005 16:30:07 -0000 Received: from unknown (HELO ?192.168.0.102?) (dave.thewlis@sbcglobal.net@69.107.98.68 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2005 16:30:07 -0000 Message-ID: <42F2428B.9020503@calconnect.org> Date: Thu, 04 Aug 2005 09:30:03 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_30_40, HTML_MESSAGE, MIME_HTML_ONLY X-Spam-Level: Subject: [Ietf-caldav] Errata on Calconnect Roundtable and Interop Announcement for September 2005 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 16:31:14 -0000 1.  The registration fee for the Roundtable was mistakenly quoted as $275 through 15 May 2005.  The correct information is $275 through 31 August 2005; the registration fee goes up to $325 on 1 September 2005.

2.  Apparently there was some garbage HTML hidden before the beginning of my announcement e-mail which was not visible when I composed it and does not show in all e-mail clients.  However, if it does show in your client and you wish a revised version of the announcement please let me know.  I hesitate to send the whole thing out again to everybody.

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 · Dave.Thewlis@calconnect.org
Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1723A7F518 for ; Thu, 4 Aug 2005 09:03:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id EF53114226D for ; Thu, 4 Aug 2005 09:03:54 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28218-02 for ; Thu, 4 Aug 2005 09:03:54 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by smtp.osafoundation.org (Postfix) with SMTP id 679C7142267 for ; Thu, 4 Aug 2005 09:03:54 -0700 (PDT) Received: (qmail 29526 invoked from network); 4 Aug 2005 16:03:51 -0000 Received: from unknown (HELO ?192.168.0.102?) (dave.thewlis@sbcglobal.net@69.107.98.68 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2005 16:03:50 -0000 Message-ID: <42F23C63.5000300@calconnect.org> Date: Thu, 04 Aug 2005 09:03:47 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_40_50, HTML_FONT_FACE_CAPS, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, MIME_HTML_ONLY X-Spam-Level: Subject: [Ietf-caldav] Registration open for Calconnect Roundtable and Interop Testing Event, September 2005 - The Calendaring and Scheduling Consortium X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 16:03:55 -0000
Please note that this announcement is being posted on multiple calendaring-related reflectors and to the Calconnect mailing lists to ensure as wide a distribution as possible.  Our apologies if you receive multiple copies.


CALCONNECT ROUNDTABLE IV - 13-15 September 2005
 
CALCONNECT INTEROP TESTING EVENT -  13-14 September 2005

 
CalConnect - The Calendaring and Scheduling Consortium - invites you to our fourth Roundtable and to the associated Calendaring and Scheduling Interop Testing Event on 13-15 September, 2005 in San Francisco, hosted by OSAF, the Open Source Applications Foundation. 

Registration is now open for these events as of 4 August 2005.


The Roundtable, 13-15 September, will feature Technical Committee meetings, ad hoc meetings, and a full Plenary of the Consortium.  You must represent a member of CalConnect to attend the Roundtable unless your organization chooses to participate as an Observer (a non-member who wishes to attend a Roundtable to evaluate participation in the Consortium).

The Interop, 13-14 September (at the same location), will offer multiple Interop Testing Scenarios including
  • extensive CalDAV testing,
  • RFC (iCalendar, iMIP, iTIP) interoperability and RFC conformance testing
  • CALSIFY minimum interoperability testing. 
Participating organizations may choose one or more than one scenario for testing -- however these scenarios will be going on simultaneously so you will probably need a person for each scenario you participate in. 

Interop participation is open to all interested organizations that wish to test calendaring and scheduling implementations, and is not limited to members of the Consortium (although members receive a significant discount on the Interop participation fee).
 

REGISTRATION FEES
 
Roundtable:  $275 per individual until 15 May and $325 thereafter.  The Roundtable is limited to representatives of Consortium members or declared Observers (an non-member that wishes to attend a Roundtable to evaluate participation in the Consortium).   Registration for the Roundtable does not include Interop participation.
 
Interop: $1500 for Consortium members and $2500 for non-members.  The registration fee covers two individuals; additional individuals are $275 each for members or non-members.  (If you are planning to participate in more than one Interop scenario, or participate in all the TC meetings, you will need more than one person and possibly more than two.)  The Interop Registration Fee also covers participation in the Consortium Roundtable for members or declared observers.
 

ADDITIONAL DETAILS AND REGISTRATION INFORMATION

More information on the Roundtable, including logistics, current schedule and agenda planning, and registration information is available on the Consortium website at http://www.calconnect.org/roundtable4.html. 

More information on the Interop including logistics, planning, and registration information is available on the Consortium website at http://www.calconnect.org/iopsep2005.html.

You may also go to Consortium site at http://www.calconnect.org and select "Coming Events" from the sidebar to find logistics, planning and registration information for both the Roundtable and the Interop.

For questions and additional information please contact the Consortium's Executive Director, Dave Thewlis, via the contact information listed below.

Space will be limited, so register as soon as possible.

Best Regards,

Dave Thewlis

--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile) · +1 415 946 3454 (fax)
http://www.calconnect.org · Dave.Thewlis@calconnect.org