From owner-ietf-calendar@mail.imc.org Fri Aug 2 14:12:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29397 for ; Fri, 2 Aug 2002 14:12:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72I4lq26510 for ietf-calendar-bks; Fri, 2 Aug 2002 11:04:47 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72I4kw26502 for ; Fri, 2 Aug 2002 11:04:46 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 55717155C7; Thu, 1 Aug 2002 18:41:44 +0200 (CEST) Date: Thu, 1 Aug 2002 18:41:43 +0200 From: Andrea Campi To: ietf-calendar@imc.org Subject: Question Message-ID: <20020801164143.GB24990@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I'm reading section 2.2 and I need confirmation I'm reading this correctly. This might also be a hint that this might be stated in a more explicit way... [...] If existing "UNPROCESSED" objects exist in the CS for the same UID then a CUA may wish to consolidate the objects in to one "BOOKED" object. The CUA would fetch the "UNPROCESSED" objects for that UID and process them in the CUA as described in [iTIP]. Then if the CUA wished to book the UID, then the CUA would issue a "CREATE" command to create the new "BOOKED" object in the CS, followed by a "DELETE" command to remove any related old [iTIP] objects from the CS. And it might also involve having the CUA send some [iMIP] objects or contacting other CS's and performing CAP operations on those CSs. [...] Several "UNPROCESSED" entries can be in the CS for the same UID. However once consolidated, then only one entry exists in the CS and that is the booked object. The others MUST BE removed, or have their state changed to "DELETED". There MUST NOT BE more than one "BOOKED" entry in a calendar for the same "UID". So I should first CREATE the BOOKED object and then delete the UNPROCESSED ones, ok. What puzzles me is the statement that "others MUST BE removed": how can a server possibly enforce this? This is in fact saying that BOOKED and UNPROCESSED entries MAY exist at the same time, however short that can be. By the way, this would be solved by doing it the other way around (first delete then create) IFF we had some way of doing atomic transactions... Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Aug 2 14:13:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29431 for ; Fri, 2 Aug 2002 14:13:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72I4lF26509 for ietf-calendar-bks; Fri, 2 Aug 2002 11:04:47 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72I4kw26501 for ; Fri, 2 Aug 2002 11:04:46 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 1B5CB155C6; Thu, 1 Aug 2002 18:30:22 +0200 (CEST) Date: Thu, 1 Aug 2002 18:30:22 +0200 From: Andrea Campi To: ietf-calendar@imc.org Subject: Another dubious example Message-ID: <20020801163021.GA24990@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, in 9.1.1 there's an example: In this example the initiator asks for the listeners capabilities. I: Content-Type: text/calendar I: I: BEGIN:VCALENDAR I: VERSION:2.0 I: PRODID:The CUA's PRODID I: CMD;ID=xyz12346:GET-CAPABILITY I: END:VCALENDAR # After 3 seconds L: Content-Type: text/calendar L: L: BEGIN:VCALENDAR L: VERSION:2.0 L: CMD;ID=xyz12346:TIMEOUT L: END:VCALENDAR This should probably be: I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Aug 2 14:51:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01060 for ; Fri, 2 Aug 2002 14:51:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72IkZE00831 for ietf-calendar-bks; Fri, 2 Aug 2002 11:46:35 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g72IkYw00825 for ; Fri, 2 Aug 2002 11:46:34 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002080214530628827 for ; Fri, 02 Aug 2002 14:53:06 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Aug 2002 14:44:55 -0400 Message-ID: <3D4AD327.90808@centivinc.com> Date: Fri, 02 Aug 2002 14:44:55 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question References: <20020801164143.GB24990@inet.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2002 18:44:55.0233 (UTC) FILETIME=[B1AC7B10:01C23A54] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: >So I should first CREATE the BOOKED object and then delete the >UNPROCESSED ones, ok. >What puzzles me is the statement that "others MUST BE removed": how >can a server possibly enforce this? > > By deleting the UNPROCESSED ones once the BOOKED one has been created, without waiting for the client to tell it to. -- /===========================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |===========================================================| |Stupid, adj.: Losing $25 on the game and $50 on the instant| |replay. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 2 15:29:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02851 for ; Fri, 2 Aug 2002 15:29:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72JMWI01840 for ietf-calendar-bks; Fri, 2 Aug 2002 12:22:32 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72JMVw01836 for ; Fri, 2 Aug 2002 12:22:31 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g72JMS6U002252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 2 Aug 2002 12:22:32 -0700 Message-ID: <3D4ADBF1.AA3CCC2F@Royer.com> Date: Fri, 02 Aug 2002 13:22:25 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Another dubious example References: <20020801163021.GA24990@inet.it> Content-Type: multipart/mixed; boundary="------------3312976E2E16959F7F603BA2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3312976E2E16959F7F603BA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > Hi all, > > in 9.1.1 there's an example: > > In this example the initiator asks for the listeners capabilities. > ... > > This should probably be: > > I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY [this may be a resend - Netscape crashed just as I hit the send button] If you are ever in Idaho - I'll take your fishing on the Snake or Salmon river. *Thanks* for this help with proof reading and checking the draft! -Doug --------------3312976E2E16959F7F603BA2 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------3312976E2E16959F7F603BA2-- From owner-ietf-calendar@mail.imc.org Fri Aug 2 15:35:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03111 for ; Fri, 2 Aug 2002 15:35:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72JUDH02007 for ietf-calendar-bks; Fri, 2 Aug 2002 12:30:13 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72JUCw02003 for ; Fri, 2 Aug 2002 12:30:12 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g72JUC6U002345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 2 Aug 2002 12:30:15 -0700 Message-ID: <3D4ADDC2.59CBC0DC@Royer.com> Date: Fri, 02 Aug 2002 13:30:10 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question References: <20020801164143.GB24990@inet.it> Content-Type: multipart/mixed; boundary="------------4762008EDF94EC263310E5DD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4762008EDF94EC263310E5DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > What puzzles me is the statement that "others MUST BE removed": how > can a server possibly enforce this? Your right. And John's post: > By deleting the UNPROCESSED ones once the BOOKED one has been created, > without waiting for the client to tell it to. I really had not thought of having the CS do it, we could. Do we want to make the CS delete all unprocessed entries for the same UID when a UID is booked? The the CS could do its best to transaction lock (as you point out below). > This is in fact saying that BOOKED > and UNPROCESSED entries MAY exist at the same time, however short > that can be. You can have booked and UNPROCESSED entries for the same UID in the CS. I meant to say that the CUA should do the removal once the unprocessed entries are processed. Are there any down sides to having the CS do the removal automatically? > By the way, this would be solved by doing it the other way around > (first delete then create) IFF we had some way of doing atomic > transactions... Yes. And if we did require the CS to do that (removal), then for implementations that have transaction enabled databases behind them - it would work safer. --------------4762008EDF94EC263310E5DD Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------4762008EDF94EC263310E5DD-- From owner-ietf-calendar@mail.imc.org Fri Aug 2 15:56:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03935 for ; Fri, 2 Aug 2002 15:56:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72JnGi02486 for ietf-calendar-bks; Fri, 2 Aug 2002 12:49:16 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g72JnEw02482 for ; Fri, 2 Aug 2002 12:49:14 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002080215555608534 for ; Fri, 02 Aug 2002 15:55:56 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Aug 2002 15:47:43 -0400 Message-ID: <3D4AE1DF.5090406@centivinc.com> Date: Fri, 02 Aug 2002 15:47:43 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question References: <20020801164143.GB24990@inet.it> <3D4ADDC2.59CBC0DC@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2002 19:47:43.0885 (UTC) FILETIME=[77F723D0:01C23A5D] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >Yes. And if we did require the CS to do that (removal), then for >implementations that have transaction enabled databases >behind them - it would work safer. > Right. And, for those that don't, it can't be made safer (unless they want to implement transactions themselves, which, ah, will give them some time-to-market problems ;-). It might be clearer to add a new command to consolidate the entries, rather than having a DELETE happen as a side effect of CREATE. In that case, we'd add the restriction that CREATing a BOOKED entry will fail if there's an UNPROCESSED entry with the same UID. Alternatively, what are the implications of requiring the CUA to cope with BOOKED and UNPROCESSED existing together? That might be better--by removing a restriction on the CS, it'd promote scalability. -- /===========================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |===========================================================| |Stupid, adj.: Losing $25 on the game and $50 on the instant| |replay. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 2 16:36:25 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05436 for ; Fri, 2 Aug 2002 16:36:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72KTob05059 for ietf-calendar-bks; Fri, 2 Aug 2002 13:29:50 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72KTnw05055 for ; Fri, 2 Aug 2002 13:29:49 -0700 (PDT) Received: from cube.webcom.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g72KTk5f015684; Fri, 2 Aug 2002 22:29:47 +0200 Date: Fri, 2 Aug 2002 22:29:36 +0200 Subject: Re: Question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "ietf-calendar@imc.org" To: John Stracke From: Andrea Campi In-Reply-To: <3D4AE1DF.5090406@centivinc.com> Message-Id: <9031539B-A656-11D6-B464-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g72KTow05056 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Venerd́, agosto 2, 2002, at 09:47 , John Stracke wrote: > > Doug Royer wrote: > >> Yes. And if we did require the CS to do that (removal), then for >> implementations that have transaction enabled databases >> behind them - it would work safer. >> > Right. And, for those that don't, it can't be made safer (unless they > want to implement transactions themselves, which, ah, will give them > some time-to-market problems ;-). Well, it wouldn't be hard to support an atomic command to do this. You just need to make sure you don't delete UNPROCESSED entries which might arrive while you are deleting them - I can think of at least 2 ways to do this [*]. > It might be clearer to add a new command to consolidate the entries, > rather than having a DELETE happen as a side effect of CREATE. In that > case, we'd add the restriction that CREATing a BOOKED entry will fail > if there's an UNPROCESSED entry with the same UID. I was about to agree with Doug (having the server delete the UNPROCESSED entries), but you do have a point here. I guess it would be better if we had a command to consolidates entries. A server might not implement it; in that case, the client should fallback to deleting the entries by itself, and take the hint that it might not be safe to do that. > Alternatively, what are the implications of requiring the CUA to cope > with BOOKED and UNPROCESSED existing together? That might be better--by > removing a restriction on the CS, it'd promote scalability. > That was the initial question, in the current draft I don't see any such requirement. Bye, Andrea [*] 1- some kind of serialization point; 2- holding a reference to the storage entries and delete them, without reloading the list. From owner-ietf-calendar@mail.imc.org Fri Aug 2 16:39:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05484 for ; Fri, 2 Aug 2002 16:39:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72KWtG05168 for ietf-calendar-bks; Fri, 2 Aug 2002 13:32:55 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g72KWsw05164 for ; Fri, 2 Aug 2002 13:32:54 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002080216393506476 for ; Fri, 02 Aug 2002 16:39:35 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Aug 2002 16:31:23 -0400 Message-ID: <3D4AEC1B.2090206@centivinc.com> Date: Fri, 02 Aug 2002 16:31:23 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question References: <9031539B-A656-11D6-B464-003065A8EEFC@inet.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2002 20:31:23.0859 (UTC) FILETIME=[91977230:01C23A63] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: > I guess it would be better if we had a command to consolidates > entries. A server might not implement it; Very bad idea--that would mean every client has to have code to do it both ways. However, a server might not implement it *atomically*. -- /=============================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |=============================================================| |Q: What goes "Pieces of 7! Pieces of 7!"? A: A parroty error.| \=============================================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 2 16:45:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05745 for ; Fri, 2 Aug 2002 16:45:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72Ke6f05386 for ietf-calendar-bks; Fri, 2 Aug 2002 13:40:06 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72Ke4w05382 for ; Fri, 2 Aug 2002 13:40:05 -0700 (PDT) Received: from cube.webcom.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g72Ke45f017143 for ; Fri, 2 Aug 2002 22:40:04 +0200 Date: Fri, 2 Aug 2002 22:39:56 +0200 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: No comments on my proposals? From: Andrea Campi To: "ietf-calendar@imc.org" Content-Transfer-Encoding: 7bit Message-Id: <01AB6752-A658-11D6-B464-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.482) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I received no answer to the proposals I made in my email of Jul 17 (http://www.imc.org/ietf-calendar/mail-archive/msg05880.html). Were they missed or do you feel they are not interesting? Bye, Andrea From owner-ietf-calendar@mail.imc.org Fri Aug 2 17:08:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06550 for ; Fri, 2 Aug 2002 17:08:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72L0tC06732 for ietf-calendar-bks; Fri, 2 Aug 2002 14:00:55 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72L0sw06728 for ; Fri, 2 Aug 2002 14:00:54 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g72L0i6U003169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 2 Aug 2002 14:00:56 -0700 Message-ID: <3D4AF2FA.6AF849D3@Royer.com> Date: Fri, 02 Aug 2002 15:00:42 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No comments on my proposals? References: <01AB6752-A658-11D6-B464-003065A8EEFC@inet.it> Content-Type: multipart/mixed; boundary="------------77B05893D1E6FF8A102AEB53" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------77B05893D1E6FF8A102AEB53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > Hi all, > > I received no answer to the proposals I made in my email of Jul 17 > (http://www.imc.org/ietf-calendar/mail-archive/msg05880.html). Were they > missed or do you feel they are not interesting? See: http://www.imc.org/ietf-calendar/mail-archive/msg05975.html --------------77B05893D1E6FF8A102AEB53 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------77B05893D1E6FF8A102AEB53-- From owner-ietf-calendar@mail.imc.org Fri Aug 2 17:32:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07625 for ; Fri, 2 Aug 2002 17:32:44 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g72LODl07570 for ietf-calendar-bks; Fri, 2 Aug 2002 14:24:13 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72LOCw07566 for ; Fri, 2 Aug 2002 14:24:12 -0700 (PDT) Received: from cube.webcom.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g72LOCpe017296; Fri, 2 Aug 2002 23:24:12 +0200 Date: Fri, 2 Aug 2002 23:24:02 +0200 Subject: Re: Question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "ietf-calendar@imc.org" To: John Stracke From: Andrea Campi In-Reply-To: <3D4AEC1B.2090206@centivinc.com> Message-Id: <2ABB3298-A65E-11D6-B2D9-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g72LODw07567 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Venerd́, agosto 2, 2002, at 10:31 , John Stracke wrote: > > Andrea Campi wrote: > >> I guess it would be better if we had a command to consolidates >> entries. A server might not implement it; > > Very bad idea--that would mean every client has to have code to do it > both ways. True.. > However, a server might not implement it *atomically*. I'm not sure what's worse, really. I'd really like to be able to trust the server to not lose data. I think we should at the very least warmly recommend a server SHOULD do its best to do it amotically. I also think we should have a capability to specify if the server has real transactions or not. Also, while we're speaking of this, today a thought struck me. Suppose I'm setting up a meeting with other people on the same server: BEGIN:VCALENDAR PRODID:A CUA METHOD:REQUEST TARGET:my-agenda TARGET:att1-agenda TARGET:att2-agenda BEGIN:VEVENT ... ORGANIZER:my-email@example.com ATTENDEE:my-email@example.com ATTENDEE:att1@example.com ATTENDEE:att2@example.com END:VEVENT END:VCALENDAR Question: should I include my agenda in the TARGETs and immediately change it to BOOKED? Or should I only include TARGETs for other people and immediately create a BOOKED entry on mine? Either way, I need to send two commands (unless I'm missing something), do we want this? Do we want to recommend one of the two approaches? Should we add an example? Or am I completely off base? Bye, Andrea From owner-ietf-calendar@mail.imc.org Fri Aug 2 17:36:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07762 for ; Fri, 2 Aug 2002 17:36:06 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g72LSej07663 for ietf-calendar-bks; Fri, 2 Aug 2002 14:28:40 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72LSdw07659 for ; Fri, 2 Aug 2002 14:28:39 -0700 (PDT) Received: from cube.webcom.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g72LSd5f023367 for ; Fri, 2 Aug 2002 23:28:39 +0200 Date: Fri, 2 Aug 2002 23:28:31 +0200 Subject: Re: No comments on my proposals? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Andrea Campi To: "ietf-calendar@imc.org" In-Reply-To: <3D4AF2FA.6AF849D3@Royer.com> Message-Id: X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g72LSew07660 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Venerd́, agosto 2, 2002, at 11:00 , Doug Royer wrote: > Andrea Campi wrote: >> >> Hi all, >> >> I received no answer to the proposals I made in my email of Jul 17 >> (http://www.imc.org/ietf-calendar/mail-archive/msg05880.html). Were >> they >> missed or do you feel they are not interesting? > > See: > > http://www.imc.org/ietf-calendar/mail-archive/msg05975.html > Uhm... yes I saw that, but under the ALLOW-CONFLICT comment there was a lot more... The proposal for NAMESPACE and NATIVE parameters, etc... Bye, Andrea From owner-ietf-calendar@mail.imc.org Fri Aug 2 17:38:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07903 for ; Fri, 2 Aug 2002 17:38:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72LVmD07719 for ietf-calendar-bks; Fri, 2 Aug 2002 14:31:48 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g72LVlw07715 for ; Fri, 2 Aug 2002 14:31:47 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002080217382822597 for ; Fri, 02 Aug 2002 17:38:28 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Aug 2002 17:30:17 -0400 Message-ID: <3D4AF9E8.7020102@centivinc.com> Date: Fri, 02 Aug 2002 17:30:16 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question References: <2ABB3298-A65E-11D6-B2D9-003065A8EEFC@inet.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2002 21:30:17.0097 (UTC) FILETIME=[CB90C790:01C23A6B] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: >> However, a server might not implement it *atomically*. > > > I'm not sure what's worse, really. Well, but, if the server doesn't implement it, then the client's workaround isn't going to be atomic, either. So a non-atomic implementation on the server is no worse than no implementation on the server, and is actually better because it preserves interop. > I'd really like to be able to trust the server to not lose data. Then don't use servers that aren't built on transactional databases. Without that, it gets much harder to trust them. -- /===============================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |===============================================================| |"I use emacs, which might be thought of as a thermonuclear word| |processor." -- Neal Stephenson | \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 2 18:51:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10303 for ; Fri, 2 Aug 2002 18:51:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72MkE412571 for ietf-calendar-bks; Fri, 2 Aug 2002 15:46:14 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72MkCw12564 for ; Fri, 2 Aug 2002 15:46:13 -0700 (PDT) Received: from cube.webcom.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g72MkB5f000906; Sat, 3 Aug 2002 00:46:11 +0200 Date: Sat, 3 Aug 2002 00:46:03 +0200 Subject: Re: Question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "ietf-calendar@imc.org" To: John Stracke From: Andrea Campi In-Reply-To: <3D4AF9E8.7020102@centivinc.com> Message-Id: <9F98EAE0-A669-11D6-B7A6-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g72MkDw12567 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Venerd́, agosto 2, 2002, at 11:30 , John Stracke wrote: > > Andrea Campi wrote: >> >> I'm not sure what's worse, really. > > Well, but, if the server doesn't implement it, then the client's > workaround isn't going to be atomic, either. So a non-atomic > implementation on the server is no worse than no implementation on the > server, and is actually better because it preserves interop. It was a rethorical question... > >> I'd really like to be able to trust the server to not lose data. > > Then don't use servers that aren't built on transactional > databases. Without that, it gets much harder to trust them. > Ok let's put it this way, then: if I were to write a client which needed to work with different servers, I'd like to be able to tell the user: this server doesn't support transactions, so you might risk some data. Or even refuse to talk to such a server! In fact, IMHO such a server would be really less useful than using iTIP over a protocol such as email, and keeping a reliable data store on the client. But to conclude, since we are really going off on a tangent here: I'm not saying that a server MUST do it atomically, only that it SHOULD. Personally I'd never write nor use a server which doesn't, nor can I imagine why somebody would want, but I guess someone will come up with a valid reason I haven't thought about... Bye, andrea From owner-ietf-calendar@mail.imc.org Fri Aug 2 19:57:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12104 for ; Fri, 2 Aug 2002 19:57:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72Npqr15112 for ietf-calendar-bks; Fri, 2 Aug 2002 16:51:52 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72Npow15106 for ; Fri, 2 Aug 2002 16:51:50 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g72Npp6U004534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 2 Aug 2002 16:51:53 -0700 Message-ID: <3D4B1B14.B73160C3@Royer.com> Date: Fri, 02 Aug 2002 17:51:48 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No comments on my proposals? References: Content-Type: multipart/mixed; boundary="------------A33FC63FD80B97E48AD7AA9F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A33FC63FD80B97E48AD7AA9F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > Uhm... yes I saw that, but under the ALLOW-CONFLICT comment there was a > lot more... The proposal for NAMESPACE and NATIVE parameters, etc... NAMESPACE: CARID's are not authoritative. By that I mean they could be just sequentially numbered. They have no other meaning other than being unique to the CS. If there is a conflict, just pick a new CARID. NATIVE - Where you say: > Description: A server may choose to implement some stored > queries in the most efficient way, which may not be easy to express > in CAL-QL-1. A server may also choose to do this in order to avoid > having to parse and compile CAL-QL-1 queries in its native query > language. As all iCalendar objects (we believe) can be represented and restricted with the VCAR model in CAP. The only thing left would be vendor extensions. And we allow the (x-) experimental extensions now that vendors can use. A CS could be written that tells you what its VCARs are while at the same time not be able to parse any. They could be compiled into a ROM and the CS just sends them. One of which could be to disallow any addition, deletion or modification of any VCARs (all decreed). So that CS would never need to parse a VCAR. The rules could be compiled into the CS and the VCARs it sends back could just be a string of text to the CS. One or more VCARs could be hard coded. --------------A33FC63FD80B97E48AD7AA9F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------A33FC63FD80B97E48AD7AA9F-- From owner-ietf-calendar@mail.imc.org Sat Aug 3 14:07:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08305 for ; Sat, 3 Aug 2002 14:07:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g73Hxkv21490 for ietf-calendar-bks; Sat, 3 Aug 2002 10:59:46 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g73Hxjw21483 for ; Sat, 3 Aug 2002 10:59:45 -0700 (PDT) Received: from cube.webcom.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g73Hxjpe013497 for ; Sat, 3 Aug 2002 19:59:45 +0200 Date: Sat, 3 Aug 2002 19:59:40 +0200 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Is TARGET mandatory? From: Andrea Campi To: "ietf-calendar@imc.org" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.482) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, nowhere in the current text is indicated whether the TARGET property is mandatory or optional. If we want it to be optional, we need to specify what is the implied behavior if it's not specified. I would expect all commands to operate on a default depending on the user identity (the user's default VAGENDA probably), right? Bye, Andrea From owner-ietf-calendar@mail.imc.org Sun Aug 4 01:19:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17960 for ; Sun, 4 Aug 2002 01:19:49 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g745Buu16336 for ietf-calendar-bks; Sat, 3 Aug 2002 22:11:56 -0700 (PDT) Received: from vineland.unknown (c17802.fitzg1.qld.optusnet.com.au [210.49.37.156]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g745Bhw16330 for ; Sat, 3 Aug 2002 22:11:53 -0700 (PDT) Received: from vineland.unknown ([192.168.0.2]) by vineland.unknown with ESMTP id <3D4CB790.00000006@vineland.unknown> for ; Sun, 04 Aug 2002 05:11:44 GMT Date: Sun, 04 Aug 2002 15:11:25 +1000 From: Andrew Davison Organization: Infradig Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: RE: Application for port-number (1026)] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4CB790.00000006@vineland.unknown> X-Authenticated-Sender: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I just installed WIN2K Service Pack 3 (SP3) today and guess what? It has started using port 1026 for it's own inscrutable reasons! It opens that port early on (among many others) on all interfaces, and it definitely is not a calendar server. I assume it started using port 1025, then 1026 etc. as ephemeral ports but for listening. The same probably exists in WINXP as i believe a lot of stuff was back ported to WIN2K in SP3. I have been through all stoppable services and nothing i could find would disable it. Nor have i been able to find any information on it at microsoft.com so perhaps someone is in a position of knowledge and could comment. From owner-ietf-calendar@mail.imc.org Sun Aug 4 11:41:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07162 for ; Sun, 4 Aug 2002 11:41:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g74FZEW09062 for ietf-calendar-bks; Sun, 4 Aug 2002 08:35:14 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g74FZCw09057 for ; Sun, 4 Aug 2002 08:35:12 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: [Fwd: RE: Application for port-number (1026)] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Sun, 4 Aug 2002 11:35:10 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 08/04/2002 11:35:14 AM, Serialize complete at 08/04/2002 11:35:14 AM Content-Type: multipart/alternative; boundary="=_alternative 00559E1585256C0B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00559E1585256C0B_= Content-Type: text/plain; charset="us-ascii" Forgot to cc: the list on this note. ----- Forwarded by Pat R Egen/Egen Consulting/01 on 08/04/2002 11:34 ----- Pat R Egen 08/04/2002 11:34 To: Andrew Davison cc: Subject: Re: [Fwd: RE: Application for port-number (1026)] Hm, this is not good. I wonder if Microsoft registered those ports with IANA. We can not register a port (completely) until a draft is an RFC - CAP is not there yet. So, we may indeed have lost this port number. Andrew Davison Sent by: owner-ietf-calendar@mail.imc.org 08/04/2002 01:11 To: ietf-calendar@imc.org cc: Subject: Re: [Fwd: RE: Application for port-number (1026)] I just installed WIN2K Service Pack 3 (SP3) today and guess what? It has started using port 1026 for it's own inscrutable reasons! It opens that port early on (among many others) on all interfaces, and it definitely is not a calendar server. I assume it started using port 1025, then 1026 etc. as ephemeral ports but for listening. The same probably exists in WINXP as i believe a lot of stuff was back ported to WIN2K in SP3. I have been through all stoppable services and nothing i could find would disable it. Nor have i been able to find any information on it at microsoft.com so perhaps someone is in a position of knowledge and could comment. --=_alternative 00559E1585256C0B_= Content-Type: text/html; charset="us-ascii"
Forgot to cc: the list on this note.
----- Forwarded by Pat R Egen/Egen Consulting/01 on 08/04/2002 11:34 -----
Pat R Egen

08/04/2002 11:34


        To:        Andrew Davison <andrew@infradig.com>
        cc:        
        Subject:        Re: [Fwd: RE: Application for port-number (1026)]Link




Hm, this is not good.  I wonder if Microsoft registered those ports with IANA.  We can not register a port (completely) until a draft is an RFC - CAP is not there yet.  So, we may indeed have lost this port number.
Andrew Davison <andrew@infradig.com>
Sent by: owner-ietf-calendar@mail.imc.org

08/04/2002 01:11

       
       To:        ietf-calendar@imc.org
       cc:        
       Subject:        Re: [Fwd: RE: Application for port-number (1026)]





I just installed WIN2K Service Pack 3 (SP3) today and guess what? It has
started using port 1026 for it's own inscrutable reasons! It opens that
port early on (among many others) on all interfaces,  and it definitely
is not a calendar server. I assume it started using port 1025, then 1026
etc. as ephemeral ports but for listening. The same probably exists in
WINXP as i believe a lot of stuff was back ported to WIN2K in SP3. I
have been through all stoppable services and nothing i could find would
disable it. Nor have i been able to find any information on it at
microsoft.com so perhaps someone is in a position of knowledge and could
comment.
--=_alternative 00559E1585256C0B_=-- From owner-ietf-calendar@mail.imc.org Sun Aug 4 14:50:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10483 for ; Sun, 4 Aug 2002 14:50:05 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g74If1E21835 for ietf-calendar-bks; Sun, 4 Aug 2002 11:41:01 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g74If0w21826 for ; Sun, 4 Aug 2002 11:41:00 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g74Iex6U011148 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 4 Aug 2002 11:41:01 -0700 Message-ID: <3D4D7539.6FF4585@Royer.com> Date: Sun, 04 Aug 2002 12:40:57 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: RE: Application for port-number (1026)] References: <3D4CB790.00000006@vineland.unknown> Content-Type: multipart/mixed; boundary="------------50476C79FA0AF612AA3ED03F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------50476C79FA0AF612AA3ED03F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew Davison wrote: > > I just installed WIN2K Service Pack 3 (SP3) today and guess what? It has > started using port 1026 for it's own inscrutable reasons! It opens that > port early on (among many others) on all interfaces, and it definitely > is not a calendar server. I assume it started using port 1025, then 1026 > etc. as ephemeral ports but for listening. The same probably exists in > WINXP as i believe a lot of stuff was back ported to WIN2K in SP3. I > have been through all stoppable services and nothing i could find would > disable it. Nor have i been able to find any information on it at > microsoft.com so perhaps someone is in a position of knowledge and could > comment. Port 1026 is currently registered with IANA for CAP. As to what MS is doing with that port, some checking shows me that NT runs mstask.exe on port 1026, what ever that is. There are several reported hack attempts to bring an NT box down via some bug using 1026. The reading also shows me that mstask.exe starts at 1025 and starts looking for unused ports. I do not know the NT flavor of the MS OS's, but if that is true, start your CAP server first then it will find the first unused port after that. -Doug --------------50476C79FA0AF612AA3ED03F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------50476C79FA0AF612AA3ED03F-- From owner-ietf-calendar@mail.imc.org Sun Aug 4 14:56:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10737 for ; Sun, 4 Aug 2002 14:56:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g74IoVb22033 for ietf-calendar-bks; Sun, 4 Aug 2002 11:50:31 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g74IoTw22028 for ; Sun, 4 Aug 2002 11:50:29 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g74IoD6U011210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 4 Aug 2002 11:50:24 -0700 Message-ID: <3D4D7762.9025575@Royer.com> Date: Sun, 04 Aug 2002 12:50:10 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Is TARGET mandatory? References: Content-Type: multipart/mixed; boundary="------------E65DAA515FB8AB59DC0AFECB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E65DAA515FB8AB59DC0AFECB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > Hi all, > > nowhere in the current text is indicated whether the TARGET property is > mandatory or optional. Section (2.) does, it calls it optional. It is listed in (2.) as optional because not all containers use the TARGET property. ; These are optional, but MUST NOT occur ; more than once. ; calscale / method / target / iana-prop / cmd / And in: 7.24 TARGET Property Property Name: TARGET Purpose: This property defines the container that the command that is issued will act upon. It its value is a capurl as defended in Section 5. I guess we could add something like 'And the TARGET property MUST BE supplied for all commands...' to the text. > If we want it to be optional, we need to specify > what is the implied behavior if it's not specified. I would expect all > commands to operate on a default depending on the user identity (the > user's default VAGENDA probably), right? I do not think we want it optional for any command. However I could go with it as you say, if not supplied then it is the currently authenticated users calendar. Then what do we do when the currently authenticated user does not have a calendar? I would lean towards making it a requirement for all commands. --------------E65DAA515FB8AB59DC0AFECB Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------E65DAA515FB8AB59DC0AFECB-- From owner-ietf-calendar@mail.imc.org Sun Aug 4 19:46:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15610 for ; Sun, 4 Aug 2002 19:46:49 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g74NfFi07145 for ietf-calendar-bks; Sun, 4 Aug 2002 16:41:15 -0700 (PDT) Received: from vineland.unknown (c17802.fitzg1.qld.optusnet.com.au [210.49.37.156]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g74NfDw07139 for ; Sun, 4 Aug 2002 16:41:13 -0700 (PDT) Received: from vineland.unknown ([192.168.0.2]) by vineland.unknown with ESMTP id <3D4DBB98.0000001A@vineland.unknown> for ; Sun, 04 Aug 2002 23:41:12 GMT Date: Mon, 05 Aug 2002 09:41:09 +1000 From: Andrew Davison Organization: Infradig Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: RE: Application for port-number (1026)] References: <3D4CB790.00000006@vineland.unknown> <3D4D7539.6FF4585@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4DBB98.0000001A@vineland.unknown> X-Authenticated-Sender: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >As to what MS is doing with that port, some checking shows >me that NT runs mstask.exe on port 1026, what ever that is. > >There are several reported hack attempts to bring an NT >box down via some bug using 1026. The reading also shows >me that mstask.exe starts at 1025 and starts looking >for unused ports. I do not know the NT flavor of the MS >OS's, but if that is true, start your CAP server first >then it will find the first unused port after that. > >-Doug > you're right, it's the 'Task Scheduler' service ( i remember i didn't stop that one). my guess is it's the new remote update facility: micrsoft must connect to the task scheduler to tell it it has work to do, push rather than pull (how does it know my server is there? on startup it must inform microsoft i suppose). having to alter startup dependancies of operating system components will sure make deploying a CAP server more difficult on WIN2K and XP. ad From owner-ietf-calendar@mail.imc.org Sun Aug 4 20:10:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16063 for ; Sun, 4 Aug 2002 20:10:24 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7504Pf07747 for ietf-calendar-bks; Sun, 4 Aug 2002 17:04:25 -0700 (PDT) Received: from vineland.unknown (c17802.fitzg1.qld.optusnet.com.au [210.49.37.156]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7504Nw07743 for ; Sun, 4 Aug 2002 17:04:23 -0700 (PDT) Received: from vineland.unknown ([192.168.0.2]) by vineland.unknown with ESMTP id <3D4DC107.0000001E@vineland.unknown> for ; Mon, 05 Aug 2002 00:04:23 GMT Date: Mon, 05 Aug 2002 10:04:03 +1000 From: andrew davison User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: RE: Application for port-number (1026)] References: <3D4CB790.00000006@vineland.unknown> <3D4D7539.6FF4585@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4DC107.0000001E@vineland.unknown> X-Authenticated-Sender: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >As to what MS is doing with that port, some checking shows >me that NT runs mstask.exe on port 1026, what ever that is. > >There are several reported hack attempts to bring an NT >box down via some bug using 1026. The reading also shows >me that mstask.exe starts at 1025 and starts looking >for unused ports. I do not know the NT flavor of the MS >OS's, but if that is true, start your CAP server first >then it will find the first unused port after that. > >-Doug > actually, ms use ports >1024 and <5000 as ephemeral ports so any assignment of CAP in that area will run into potential difficulties, especially so close to the lower end. i'm told Active Directory can also grab 1025 & 1026 for logon and replication services. From owner-ietf-calendar@mail.imc.org Sun Aug 4 20:11:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16093 for ; Sun, 4 Aug 2002 20:11:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7505lY07787 for ietf-calendar-bks; Sun, 4 Aug 2002 17:05:47 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7505kw07783 for ; Sun, 4 Aug 2002 17:05:46 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7505f6U013355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 4 Aug 2002 17:05:49 -0700 Message-ID: <3D4DC152.43CFC32B@Royer.com> Date: Sun, 04 Aug 2002 18:05:38 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: [Fwd: RE: Application for port-number (1026)] References: <3D4CB790.00000006@vineland.unknown> <3D4D7539.6FF4585@Royer.com> <3D4DBB98.0000001A@vineland.unknown> Content-Type: multipart/mixed; boundary="------------B7FB7EBD8B293FAE234A7191" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B7FB7EBD8B293FAE234A7191 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew Davison wrote: > > Doug Royer wrote: > > >As to what MS is doing with that port, some checking shows > >me that NT runs mstask.exe on port 1026, what ever that is. > > > >There are several reported hack attempts to bring an NT > >box down via some bug using 1026. The reading also shows > >me that mstask.exe starts at 1025 and starts looking > >for unused ports. I do not know the NT flavor of the MS > >OS's, but if that is true, start your CAP server first > >then it will find the first unused port after that. > > > >-Doug > > > you're right, it's the 'Task Scheduler' service ( i remember i didn't > stop that one). my guess is it's the new remote update facility: > micrsoft must connect to the task scheduler to tell it it has work to > do, push rather than pull (how does it know my server is there? on > startup it must inform microsoft i suppose). having to alter startup > dependancies of operating system components will sure make deploying a > CAP server more difficult on WIN2K and XP. I would think that the wonderful M$ tools do that for you :-) Plus, if they are looking for unused ports, I would think that they would make sure that mstask.exe is one of the last things started, otherwise they could break many things. --------------B7FB7EBD8B293FAE234A7191 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------B7FB7EBD8B293FAE234A7191-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 03:52:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04340 for ; Mon, 5 Aug 2002 03:52:34 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g757g7l18546 for ietf-calendar-bks; Mon, 5 Aug 2002 00:42:07 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g757g5w18542 for ; Mon, 5 Aug 2002 00:42:06 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 6DA1E1552F; Mon, 5 Aug 2002 09:42:04 +0200 (CEST) Date: Mon, 5 Aug 2002 09:42:04 +0200 From: Andrea Campi To: "ietf-calendar@imc.org" Subject: Re: Is TARGET mandatory? Message-ID: <20020805074204.GA10602@inet.it> References: <3D4D7762.9025575@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D4D7762.9025575@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, Aug 04, 2002 at 12:50:10PM -0600, Doug Royer wrote: > Andrea Campi wrote: > > > > Hi all, > > > > nowhere in the current text is indicated whether the TARGET property is > > mandatory or optional. > > Section (2.) does, it calls it optional. It is listed in (2.) as > optional because not all containers use the TARGET property. Right, I overlooked this. > 7.24 TARGET Property > > Property Name: TARGET > > Purpose: This property defines the container that the command > that is issued will act upon. It its value is a capurl as > defended in Section 5. > > I guess we could add something like 'And the TARGET property MUST BE > supplied for all commands...' to the text. Some commands don't need it (GET-CAPALITY comes to my mind), so I think it should still be optional; the commands which do need it should indicate it is MUST be supplied. > I do not think we want it optional for any command. > However I could go with it as you say, if not supplied then > it is the currently authenticated users calendar. Then what > do we do when the currently authenticated user does not have > a calendar? I would lean towards making it a requirement > for all commands. Me too, for the same reason. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Aug 5 04:01:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04527 for ; Mon, 5 Aug 2002 04:01:54 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g757slF20577 for ietf-calendar-bks; Mon, 5 Aug 2002 00:54:47 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g757skw20565 for ; Mon, 5 Aug 2002 00:54:46 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 6F97F1552F; Mon, 5 Aug 2002 09:54:45 +0200 (CEST) Date: Mon, 5 Aug 2002 09:54:45 +0200 From: Andrea Campi To: "ietf-calendar@imc.org" Subject: Re: No comments on my proposals? Message-ID: <20020805075445.GB10602@inet.it> References: <3D4B1B14.B73160C3@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D4B1B14.B73160C3@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Aug 02, 2002 at 05:51:48PM -0600, Doug Royer wrote: > Andrea Campi wrote: > > > Uhm... yes I saw that, but under the ALLOW-CONFLICT comment there was a > > lot more... The proposal for NAMESPACE and NATIVE parameters, etc... > > NAMESPACE: > > CARID's are not authoritative. By that I mean they could > be just sequentially numbered. They have no other meaning > other than being unique to the CS. If there is a conflict, > just pick a new CARID. I might have been unclear, sorry. I was referring in general to queries, but I was thinking of the SEARCH command in particular. Think of this scenario: a client could conceivably use stored queries for most if not all of its needs (that's why we have stored queries at all, right?). The client needs to know the queries are there, so they must be there and have the name it expects, not just any unique name. If vendors start to add stored queries, we can't expect everybody to uniquely name things so that they don't conflict, or if they do, they don't have slightly different semantics. Besides, the only way a client can be sure to find their stored queries is to install them; if a conflict arise during installation, it's not easy to just change name. Do you agree there's a problem there? If you do, do you have any other solution besides what I propose? Otherwise I can't see how QUERYID is going to be of any use in improving, instead of reducing, interoperability. > > NATIVE - Where you say: > > > Description: A server may choose to implement some stored > > queries in the most efficient way, which may not be easy to express > > in CAL-QL-1. A server may also choose to do this in order to avoid > > having to parse and compile CAL-QL-1 queries in its native query > > language. > > As all iCalendar objects (we believe) can be represented > and restricted with the VCAR model in CAP. The only thing > left would be vendor extensions. And we allow the (x-) > experimental extensions now that vendors can use. Again, I wasn't thinking of VCARs, I was thinking of a server which mapped queries to an SQL backend. Anyway, see below: > A CS could be written that tells you what its VCARs are while > at the same time not be able to parse any. They could be > compiled into a ROM and the CS just sends them. One of which > could be to disallow any addition, deletion or modification of > any VCARs (all decreed). So that CS would never need to > parse a VCAR. The rules could be compiled into the CS and > the VCARs it sends back could just be a string of text > to the CS. One or more VCARs could be hard coded. Yes, you are right, I withdraw my proposal as it would serve no pratical purpose. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Aug 5 04:03:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04571 for ; Mon, 5 Aug 2002 04:03:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g757x7D21719 for ietf-calendar-bks; Mon, 5 Aug 2002 00:59:07 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g757x6w21711 for ; Mon, 5 Aug 2002 00:59:06 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 044E51552F; Mon, 5 Aug 2002 09:59:05 +0200 (CEST) Date: Mon, 5 Aug 2002 09:59:05 +0200 From: Andrea Campi To: "ietf-calendar@imc.org" Subject: CREATEing a meeting Message-ID: <20020805075905.GA14023@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry, this is a partial repost. It was at end of a different thread and somebody might have missed it.] Also, while we're speaking of this, today a thought struck me. Suppose I'm setting up a meeting with other people on the same server: BEGIN:VCALENDAR PRODID:A CUA METHOD:REQUEST TARGET:my-agenda TARGET:att1-agenda TARGET:att2-agenda BEGIN:VEVENT ... ORGANIZER:my-email@example.com ATTENDEE:my-email@example.com ATTENDEE:att1@example.com ATTENDEE:att2@example.com END:VEVENT END:VCALENDAR Question: should I include my agenda in the TARGETs and immediately change it to BOOKED? Or should I only include TARGETs for other people and immediately create a BOOKED entry on mine? Either way, I need to send two commands (unless I'm missing something), do we want this? Do we want to recommend one of the two approaches? Should we add an example? Or am I completely off base? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Aug 5 04:06:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04614 for ; Mon, 5 Aug 2002 04:06:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7581x121907 for ietf-calendar-bks; Mon, 5 Aug 2002 01:01:59 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7581xw21899 for ; Mon, 5 Aug 2002 01:01:59 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id EDE1C1552F; Mon, 5 Aug 2002 10:01:55 +0200 (CEST) Date: Mon, 5 Aug 2002 10:01:55 +0200 From: Andrea Campi To: "ietf-calendar@imc.org" Subject: VQUERY extension proposal Message-ID: <20020805080155.GB14023@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Sorry, this is a partial repost; it was at the end of a long email and somebody might have lost it.] I also propose to change VQUERY to allow a VERSION property. This allows a future draft to define extensions to the query language while keeping backward and forward compatibility. If you agree to this, then I think we should discuss whether or not the QUERY-LEVEL should allow for a list. To give you an example of what I'm talking about, let's say a future draft defines substitution parameters in stored queries, so that for instance it's possible to store (this is just an example!): BEGIN:VQUERY QUERYID;NAMESPACE=example.com:foo(date) QUERY:SELECT * FROM VEVENT WHERE DTSTART = ?date? END:VQUERY which would be then invoked as: BEGIN:VCALENDAR VERSION:2.0 CMD:QUERY TARGET:relcal1 BEGIN:VQUERY QUERYID;NAMESPACE=example.com:foo('20020708T000000Z') END:VQUERY This could be name CAL-QL-EXT1. At a later time a new draft could specify CAL-QL-EXT2, which doesn't imply CAL-QL-EXT1. It would be most useful to be able to say: ... BEGIN:VREPLY ... QUERY-LEVEL:CAL-QL-1,CAL-QL-EXT2,my-extensions ... END:VREPLY Bye, andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Aug 5 08:02:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09061 for ; Mon, 5 Aug 2002 08:02:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75BuSx13978 for ietf-calendar-bks; Mon, 5 Aug 2002 04:56:28 -0700 (PDT) Received: from smtp09.wxs.nl (smtp09.wxs.nl [195.121.6.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75BuQw13974 for ; Mon, 5 Aug 2002 04:56:26 -0700 (PDT) Received: from compaqp1000 ([213.10.149.128]) by smtp09.wxs.nl (Netscape Messaging Server 4.15) with SMTP id H0DD5X00.XQ1 for ; Mon, 5 Aug 2002 13:56:21 +0200 Message-ID: <004401c23c77$27061500$0200a8c0@compaqp1000> Reply-To: "ArentJan Banck" From: "ArentJan Banck" To: Subject: dtend/dtstart date value in sample iCalendar DTD Document (xCal) Date: Mon, 5 Aug 2002 13:56:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1050 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1050 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, The sample on page 25 draft-ietf-calsch-many-xcal-02.txt says: 19990101T125957Z-123403@host.com 19990101T130000Z 19991102 19991102 ... As RFC 2445 says dtend MUST be later in time then the value of the "DTSTART" property, I would assume that setting dtstart and dtend to the same date value is incorrect. To specify a one-day event, shouldn't only DTSTART be set to a DATE value, without a DTEND property? ArentJan From owner-ietf-calendar@mail.imc.org Mon Aug 5 10:05:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14175 for ; Mon, 5 Aug 2002 10:05:27 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g75E0UV19733 for ietf-calendar-bks; Mon, 5 Aug 2002 07:00:30 -0700 (PDT) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75E0Uw19728 for ; Mon, 5 Aug 2002 07:00:30 -0700 (PDT) Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g75E0PT01621 for ; Mon, 5 Aug 2002 07:00:25 -0700 (PDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g75E0OR01579 for ; Mon, 5 Aug 2002 07:00:24 -0700 (PDT) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g75E0N715217 for ; Mon, 5 Aug 2002 08:00:23 -0600 (MDT) Message-ID: <3D4E861E.E603537C@oracle.com> Date: Mon, 05 Aug 2002 10:05:18 -0400 From: Bernard Desruisseaux X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Is TARGET mandatory? References: <3D4D7762.9025575@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Andrea Campi wrote: > > > > Hi all, > > > > nowhere in the current text is indicated whether the TARGET property is > > mandatory or optional. > > Section (2.) does, it calls it optional. It is listed in (2.) as > optional because not all containers use the TARGET property. > > ; These are optional, but MUST NOT occur > ; more than once. > ; > calscale / > method / > target / > iana-prop / > cmd / Actually this is wrong since TARGET "MAY occur more than once". > > And in: > > 7.24 TARGET Property > > Property Name: TARGET > > Purpose: This property defines the container that the command > that is issued will act upon. It its value is a capurl as > defended in Section 5. > > I guess we could add something like 'And the TARGET property MUST BE > supplied for all commands...' to the text. Don't do that. Many commands don't need a TARGET (e.g., GENERATE-UID, GET-CAPABILITY). > > > If we want it to be optional, we need to specify > > what is the implied behavior if it's not specified. I would expect all > > commands to operate on a default depending on the user identity (the > > user's default VAGENDA probably), right? > > I do not think we want it optional for any command. > However I could go with it as you say, if not supplied then > it is the currently authenticated users calendar. Then what > do we do when the currently authenticated user does not have > a calendar? I would lean towards making it a requirement > for all commands. See above. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard.desruisseaux@oracle.com Server Technologies Tel. : +1 514 733-8500 x4213 Oracle Corporation Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Mon Aug 5 10:54:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16083 for ; Mon, 5 Aug 2002 10:54:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75Enw723522 for ietf-calendar-bks; Mon, 5 Aug 2002 07:49:58 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75Envw23517 for ; Mon, 5 Aug 2002 07:49:57 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g75Ent6U019700 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 5 Aug 2002 07:49:57 -0700 Message-ID: <3D4E9090.ABBE817F@Royer.com> Date: Mon, 05 Aug 2002 08:49:52 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No comments on my proposals? References: <3D4B1B14.B73160C3@Royer.com> <20020805075445.GB10602@inet.it> Content-Type: multipart/mixed; boundary="------------00218064B98ED36595730693" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------00218064B98ED36595730693 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > On Fri, Aug 02, 2002 at 05:51:48PM -0600, Doug Royer wrote: > > Andrea Campi wrote: > > > > > Uhm... yes I saw that, but under the ALLOW-CONFLICT comment there was a > > > lot more... The proposal for NAMESPACE and NATIVE parameters, etc... > > > > NAMESPACE: > > > > CARID's are not authoritative. By that I mean they could > > be just sequentially numbered. They have no other meaning > > other than being unique to the CS. If there is a conflict, > > just pick a new CARID. > > I might have been unclear, sorry. I was referring in general to > queries, but I was thinking of the SEARCH command in particular. > Think of this scenario: a client could conceivably use stored > queries for most if not all of its needs (that's why we have stored > queries at all, right?). The client needs to know the queries are > there, so they must be there and have the name it expects, not just > any unique name. If vendors start to add stored queries, we can't > expect everybody to uniquely name things so that they don't conflict, > or if they do, they don't have slightly different semantics. > Besides, the only way a client can be sure to find their stored > queries is to install them; if a conflict arise during installation, > it's not easy to just change name. There are only two kinds of stored queries. (1) Those placed there by the CS implementation, and (2) those placed there by a CUA. It is conceivable that the stored queries placed there by the CS implementation are not delectable or modifiable (by VCAR control) to the CUA. So no matter what the CUA wants, it can not use those QUERYID's for its own stored queries. If the stored query is placed there by any CUA the same is true. The first one that grabs a QUERYID wins. The next attempt better use an different QUERYID. > Do you agree there's a problem there? If you do, do you have any > other solution besides what I propose? Otherwise I can't see how > QUERYID is going to be of any use in improving, instead of reducing, > interoperability. I do not see a problem. I can still store my queries and use them by ID. And the QUERYID is still just a random unique string. I do not see an interoperability problem. I think you are saying that if a CUA were to connect to multiple CS's and had permission to store queries on each of those CS's, it would have to keep a map of its queries vs. which CS. A bit painful, but I do not see that as an interoperability issue. I guess if others wanted namespaces, we could add it. In order for namespaces to not conflict with each other, would we need to setup a registration process? Otherwise what is to keep the namespaces from stepping on each other? > > NATIVE - Where you say: > > > > > Description: A server may choose to implement some stored > > > queries in the most efficient way, which may not be easy to express > > > in CAL-QL-1. A server may also choose to do this in order to avoid > > > having to parse and compile CAL-QL-1 queries in its native query > > > language. > > > > As all iCalendar objects (we believe) can be represented > > and restricted with the VCAR model in CAP. The only thing > > left would be vendor extensions. And we allow the (x-) > > experimental extensions now that vendors can use. > > Again, I wasn't thinking of VCARs, I was thinking of a server which mapped > queries to an SQL backend. Anyway, see below: FYI - I map VCARs using an SQL backend. > Yes, you are right, I withdraw my proposal as it would serve no pratical > purpose. --------------00218064B98ED36595730693 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------00218064B98ED36595730693-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 10:57:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16158 for ; Mon, 5 Aug 2002 10:57:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75EqSm23607 for ietf-calendar-bks; Mon, 5 Aug 2002 07:52:28 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75EqQw23601 for ; Mon, 5 Aug 2002 07:52:27 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g75EqO6U019731 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 5 Aug 2002 07:52:26 -0700 Message-ID: <3D4E9125.20347D95@Royer.com> Date: Mon, 05 Aug 2002 08:52:21 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Is TARGET mandatory? References: <3D4D7762.9025575@Royer.com> <3D4E861E.E603537C@oracle.com> Content-Type: multipart/mixed; boundary="------------0F8BB9EC59FD3D17186814C0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0F8BB9EC59FD3D17186814C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Andrea Campi wrote: > > > > > > Hi all, > > > > > > nowhere in the current text is indicated whether the TARGET property is > > > mandatory or optional. > > > > Section (2.) does, it calls it optional. It is listed in (2.) as > > optional because not all containers use the TARGET property. > > > > ; These are optional, but MUST NOT occur > > ; more than once. > > ; > > calscale / > > method / > > target / > > iana-prop / > > cmd / > > Actually this is wrong since TARGET "MAY occur more than once". Thanks. I just updated my copy, it will be in the next push. > > > > And in: > > > > 7.24 TARGET Property > > > > Property Name: TARGET > > > > Purpose: This property defines the container that the command > > that is issued will act upon. It its value is a capurl as > > defended in Section 5. > > > > I guess we could add something like 'And the TARGET property MUST BE > > supplied for all commands...' to the text. > > Don't do that. Many commands don't need a TARGET (e.g., > GENERATE-UID, GET-CAPABILITY). We are in agreement. --------------0F8BB9EC59FD3D17186814C0 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------0F8BB9EC59FD3D17186814C0-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 11:11:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16769 for ; Mon, 5 Aug 2002 11:11:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g75F6Ip24004 for ietf-calendar-bks; Mon, 5 Aug 2002 08:06:18 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75F6Gw24000 for ; Mon, 5 Aug 2002 08:06:16 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g75F616U019831 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 5 Aug 2002 08:06:03 -0700 Message-ID: <3D4E9457.33551A0B@Royer.com> Date: Mon, 05 Aug 2002 09:05:59 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: xCal Mailing List CC: ietf-calendar@imc.org Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <004401c23c77$27061500$0200a8c0@compaqp1000> Content-Type: multipart/mixed; boundary="------------4BF48B4FC79D543D61FD1A5A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4BF48B4FC79D543D61FD1A5A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ArentJan Banck wrote: > > Hi, > The sample on page 25 draft-ietf-calsch-many-xcal-02.txt says: > > > 19990101T125957Z-123403@host.com > 19990101T130000Z > 19991102 > 19991102 > ... > > As RFC 2445 says dtend MUST be later in time then the value > of the "DTSTART" property, I would assume that setting dtstart > and dtend to the same date value is incorrect. > > To specify a one-day event, shouldn't only DTSTART be set to a > DATE value, without a DTEND property? Yep, thanks, I just updated the draft and removed dtend. It will be in the next push. FYI - xcal discussions generally take place on xcal-dev@inet-consulting.com . --------------4BF48B4FC79D543D61FD1A5A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------4BF48B4FC79D543D61FD1A5A-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 11:17:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17019 for ; Mon, 5 Aug 2002 11:17:47 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g75FE3524340 for ietf-calendar-bks; Mon, 5 Aug 2002 08:14:03 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75FE1w24334 for ; Mon, 5 Aug 2002 08:14:01 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g75FE06U019893 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 5 Aug 2002 08:14:03 -0700 Message-ID: <3D4E9636.8432162B@Royer.com> Date: Mon, 05 Aug 2002 09:13:58 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VQUERY extension proposal References: <20020805080155.GB14023@inet.it> Content-Type: multipart/mixed; boundary="------------BBC15450A255EF9E758430AC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BBC15450A255EF9E758430AC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > [Sorry, this is a partial repost; it was at the end of a long email and > somebody might have lost it.] > > I also propose to change VQUERY to allow a VERSION property. This > allows a future draft to define extensions to the query language > while keeping backward and forward compatibility. I would think that when (if) ever we extend the QL, then that would be the time to decide how to extend it? At that time we can have a debate on if any extensions could/should/must be compatible with existing queries? If they are compatible, and as the query-level is in the get-capabability reply from the CS, the CUA could tell without adding any version information to the query. FYI - there is no reason that your CS could not send an X-MY-CAL-QL-EXT-1 in the get-capabiliteis reply so that your CUAs could use any x- extensions your implementation might want. --------------BBC15450A255EF9E758430AC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------BBC15450A255EF9E758430AC-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 11:50:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18415 for ; Mon, 5 Aug 2002 11:50:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75FjgK25231 for ietf-calendar-bks; Mon, 5 Aug 2002 08:45:42 -0700 (PDT) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75Fjfw25227 for ; Mon, 5 Aug 2002 08:45:41 -0700 (PDT) Received: from jsoft.com (IDENT:UKijRfLTTxdB1FdgKGpwnsLWXjqx3AFY@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g75FeoT25452; Mon, 5 Aug 2002 10:40:50 -0500 Message-ID: <3D4E9C82.3040508@jsoft.com> Date: Mon, 05 Aug 2002 10:40:50 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Royer CC: xCal Mailing List , ietf-calendar@imc.org Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <004401c23c77$27061500$0200a8c0@compaqp1000> <3D4E9457.33551A0B@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, Since joining xcal-dev@inet-consulting.com is now open to everyone, I'll get back on. Thanks, Gary Doug Royer wrote: > ArentJan Banck wrote: > >>Hi, >>The sample on page 25 draft-ietf-calsch-many-xcal-02.txt says: >> >> >> 19990101T125957Z-123403@host.com >> 19990101T130000Z >> 19991102 >> 19991102 >> ... >> >>As RFC 2445 says dtend MUST be later in time then the value >>of the "DTSTART" property, I would assume that setting dtstart >>and dtend to the same date value is incorrect. >> >>To specify a one-day event, shouldn't only DTSTART be set to a >>DATE value, without a DTEND property? > > > Yep, thanks, I just updated the draft and removed dtend. > It will be in the next push. > > FYI - xcal discussions generally take place on > xcal-dev@inet-consulting.com . From owner-ietf-calendar@mail.imc.org Mon Aug 5 12:04:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19350 for ; Mon, 5 Aug 2002 12:04:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75Fvoi25817 for ietf-calendar-bks; Mon, 5 Aug 2002 08:57:50 -0700 (PDT) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75Fvnw25813 for ; Mon, 5 Aug 2002 08:57:49 -0700 (PDT) Received: from jsoft.com (IDENT:XzltO9GTLTmc5EztMyRMNH///Uqb0sQ5@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g75Fr9T25513; Mon, 5 Aug 2002 10:53:09 -0500 Message-ID: <3D4E9F65.6000506@jsoft.com> Date: Mon, 05 Aug 2002 10:53:09 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Royer CC: xCal Mailing List , ietf-calendar@imc.org Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <004401c23c77$27061500$0200a8c0@compaqp1000> <3D4E9457.33551A0B@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, could we have a bit of conversation about this? rfc2445 states The following is an example of the "VEVENT" calendar component used to represent an anniversary that will occur annually. Since it takes up no time, it will not appear as opaque in a search for busy time; no matter what the value of the "TRANSP" property indicates: BEGIN:VEVENT UID:19970901T130000Z-123403@host.com DTSTAMP:19970901T1300Z DTSTART:19971102 SUMMARY:Our Blissful Anniversary CLASS:CONFIDENTIAL CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION RRULE:FREQ=YEARLY END:VEVENT If the xCal example was to show a one day event, removing the DTEND will make it take up no time and that is probably not what is wanted. I suggest the text in rfc2455 be changed to say that a DTEND should be 'equal to or' greater than the DTSTART. And I guess we would have to say that if it's equal to, the 'duration' is that day. Will that cause other problems? Gary Doug Royer wrote: > ArentJan Banck wrote: > >>Hi, >>The sample on page 25 draft-ietf-calsch-many-xcal-02.txt says: >> >> >> 19990101T125957Z-123403@host.com >> 19990101T130000Z >> 19991102 >> 19991102 >> ... >> >>As RFC 2445 says dtend MUST be later in time then the value >>of the "DTSTART" property, I would assume that setting dtstart >>and dtend to the same date value is incorrect. >> >>To specify a one-day event, shouldn't only DTSTART be set to a >>DATE value, without a DTEND property? > > > Yep, thanks, I just updated the draft and removed dtend. > It will be in the next push. > > FYI - xcal discussions generally take place on > xcal-dev@inet-consulting.com . From owner-ietf-calendar@mail.imc.org Mon Aug 5 12:54:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21959 for ; Mon, 5 Aug 2002 12:54:27 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g75Gmcd29030 for ietf-calendar-bks; Mon, 5 Aug 2002 09:48:38 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75Gmaw29023 for ; Mon, 5 Aug 2002 09:48:36 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g75GmZ6U020785 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 5 Aug 2002 09:48:38 -0700 Message-ID: <3D4EAC61.8F594F1@Royer.com> Date: Mon, 05 Aug 2002 10:48:33 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: xCal Mailing List Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <004401c23c77$27061500$0200a8c0@compaqp1000> <3D4E9457.33551A0B@Royer.com> <3D4E9F65.6000506@jsoft.com> Content-Type: multipart/mixed; boundary="------------158436BF0DEAE4CF42BFCA54" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------158436BF0DEAE4CF42BFCA54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > > Doug, could we have a bit of conversation about this? > > rfc2445 states > > The following is an example of the "VEVENT" calendar component used > to represent an anniversary that will occur annually. Since it takes > up no time, it will not appear as opaque in a search for busy time; > no matter what the value of the "TRANSP" property indicates: > > BEGIN:VEVENT > UID:19970901T130000Z-123403@host.com > DTSTAMP:19970901T1300Z > DTSTART:19971102 > SUMMARY:Our Blissful Anniversary > CLASS:CONFIDENTIAL > CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION > RRULE:FREQ=YEARLY > END:VEVENT > > If the xCal example was to show a one day event, > removing the DTEND will make it take up no time and that > is probably not what is wanted. Just like with iCal - if you want it to consume time, then make DTEND greater than DTSTART. The example in xcal should not have a DTEND, just like the iCal representation did not in 2445 as you point out. It is clear to me that the xcal example is showing exactly how a repeating anniversary is represented exactly like the same entry in iCal. > I suggest the text in rfc2455 be changed to say that a DTEND should > be 'equal to or' greater than the DTSTART. And I guess we would have > to say that if it's equal to, the 'duration' is that day. I would say - no. We had debates about this. If you want to represent time, make DTEND larger than DTSTART or use DTSTART and DURATION. > Will that cause other problems? A DTSTART and a DTEND with the same value will look like a busted iCalendar object according to 2445 compliant CUAs, so it would be an incompatible change. And there is compatible solution: use DTEND or DURATION. --------------158436BF0DEAE4CF42BFCA54 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------158436BF0DEAE4CF42BFCA54-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 13:05:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22422 for ; Mon, 5 Aug 2002 13:05:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75H1nS29369 for ietf-calendar-bks; Mon, 5 Aug 2002 10:01:49 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75H1mw29363 for ; Mon, 5 Aug 2002 10:01:48 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id DBD0F1552F; Mon, 5 Aug 2002 19:01:47 +0200 (CEST) Date: Mon, 5 Aug 2002 19:01:46 +0200 From: Andrea Campi To: "ietf-calendar@imc.org" Subject: Re: No comments on my proposals? Message-ID: <20020805170146.GC45572@inet.it> References: <3D4B1B14.B73160C3@Royer.com> <20020805075445.GB10602@inet.it> <3D4E9090.ABBE817F@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D4E9090.ABBE817F@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Aug 05, 2002 at 08:49:52AM -0600, Doug Royer wrote: > I do not see an interoperability problem. I think you > are saying that if a CUA were to connect to multiple CS's and > had permission to store queries on each of those CS's, it > would have to keep a map of its queries vs. which CS. A bit > painful, but I do not see that as an interoperability issue. Even if a CUA connects to just one CS it needs to track the queries. With my proposal, the CUA installation process just stores the queries, the the CUA can as well have them compiled in. > I guess if others wanted namespaces, we could add it. > In order for namespaces to not conflict with each other, > would we need to setup a registration process? Otherwise > what is to keep the namespaces from stepping on each other? Well, if somebody chose not to use sensible names, yes. Otherwise I see no need for a registry; I would use my domain name, for instance. Anyway: if anybody supports the idea, great, otherwise I will stop promoting it and just name my queries in an unlikely way... Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Aug 5 13:31:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23564 for ; Mon, 5 Aug 2002 13:31:43 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g75HRU500661 for ietf-calendar-bks; Mon, 5 Aug 2002 10:27:30 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75HRQw00650 for ; Mon, 5 Aug 2002 10:27:28 -0700 (PDT) In-Reply-To: <3D4AE1DF.5090406@centivinc.com> To: John Stracke Cc: "ietf-calendar@imc.org" Subject: Re: Question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_08042002NP August 04, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 5 Aug 2002 13:27:22 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_07302002NP|July 30, 2002) at 08/05/2002 01:21:41 PM, Serialize complete at 08/05/2002 01:21:41 PM Content-Type: multipart/alternative; boundary="=_alternative 005FE13185256C0C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005FE13185256C0C_= Content-Type: text/plain; charset="US-ASCII" John replied on 08/02/2002 03:47:43 PM: > It might be clearer to add a new command to consolidate the entries, > rather than having a DELETE happen as a side effect of CREATE. In that > case, we'd add the restriction that CREATing a BOOKED entry will fail if > there's an UNPROCESSED entry with the same UID. This smacks big time of feature creep that will drag out the process of creating CAP. If not careful we will wind up with just 1 command like "DOITALLTHEWAYIIMAGINEITSHOULDBE" and thats it. Cool for CUA coders maybe but not for CS coders... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005FE13185256C0C_= Content-Type: text/html; charset="US-ASCII"
John replied on 08/02/2002 03:47:43 PM:
> It might be clearer to add a new command to consolidate the entries,
> rather than having a DELETE happen as a side effect of CREATE.  In that
> case, we'd add the restriction that CREATing a BOOKED entry will fail if
> there's an UNPROCESSED entry with the same UID.
This smacks big time of feature creep that will drag out the process of creating CAP.  

If not careful we will wind up with just 1 command like "DOITALLTHEWAYIIMAGINEITSHOULDBE" and thats it.  Cool for CUA coders maybe but not for CS coders...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005FE13185256C0C_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 13:39:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23811 for ; Mon, 5 Aug 2002 13:39:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75HXwm01541 for ietf-calendar-bks; Mon, 5 Aug 2002 10:33:58 -0700 (PDT) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75HXvw01535 for ; Mon, 5 Aug 2002 10:33:57 -0700 (PDT) Received: from jsoft.com (IDENT:DtX1HAPBlLWP6WdnxL7vutnL6IcAWzB3@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g75HTTT26989 for ; Mon, 5 Aug 2002 12:29:30 -0500 Message-ID: <3D4EB5F9.9020504@jsoft.com> Date: Mon, 05 Aug 2002 12:29:29 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <004401c23c77$27061500$0200a8c0@compaqp1000> <3D4E9457.33551A0B@Royer.com> <3D4E9F65.6000506@jsoft.com> <3D4EAC61.8F594F1@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit DURATION! Part of the original question was how to represent a day long event. Let me make sure I have it right. Use case #1 DTSTART;DATE:19971102 with no DTEND/DURATION is an event that takes up no time. Use case #2 DTSTART;DATE:19971102 DTEND;DATE:19971102 incorrect. DTEND is the same time as DTSTART Use case #3 DTSTART;DATE:19971102 DTEND;DATE:19971103 Valid and represents time. Use case #4 DTSTART;DATE:19971102 DURATION:PT12H Valid and represents time - 12 hours. ==== So you can represent an anniversary with Use case #1 and an one day event (12 hours long) with Use case #4. How long is use case #3? 24 hours? DTEND is the non-inclusive end of the event. If so, would that be a way to represent an event that was on 19971102? Seems like it to me. Gary Doug Royer wrote: > Gary Frederick wrote: > >>Doug, could we have a bit of conversation about this? >> >>rfc2445 states >> >> The following is an example of the "VEVENT" calendar component used >> to represent an anniversary that will occur annually. Since it takes >> up no time, it will not appear as opaque in a search for busy time; >> no matter what the value of the "TRANSP" property indicates: >> >> BEGIN:VEVENT >> UID:19970901T130000Z-123403@host.com >> DTSTAMP:19970901T1300Z >> DTSTART:19971102 >> SUMMARY:Our Blissful Anniversary >> CLASS:CONFIDENTIAL >> CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION >> RRULE:FREQ=YEARLY >> END:VEVENT >> >>If the xCal example was to show a one day event, >>removing the DTEND will make it take up no time and that >>is probably not what is wanted. > > > Just like with iCal - if you want it to consume time, then > make DTEND greater than DTSTART. > > The example in xcal should not have a DTEND, just like > the iCal representation did not in 2445 as you point out. > > It is clear to me that the xcal example is showing exactly > how a repeating anniversary is represented exactly > like the same entry in iCal. > > >>I suggest the text in rfc2455 be changed to say that a DTEND should >>be 'equal to or' greater than the DTSTART. And I guess we would have >>to say that if it's equal to, the 'duration' is that day. > > > I would say - no. We had debates about this. If you want > to represent time, make DTEND larger than DTSTART or > use DTSTART and DURATION. > > >>Will that cause other problems? > > > A DTSTART and a DTEND with the same value will look like a > busted iCalendar object according to 2445 compliant CUAs, so it > would be an incompatible change. And there is compatible solution: > use DTEND or DURATION. From owner-ietf-calendar@mail.imc.org Mon Aug 5 14:03:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25053 for ; Mon, 5 Aug 2002 14:03:32 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g75HwKq04561 for ietf-calendar-bks; Mon, 5 Aug 2002 10:58:20 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75HwJw04557 for ; Mon, 5 Aug 2002 10:58:19 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g75HwI6U021533 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 5 Aug 2002 10:58:21 -0700 Message-ID: <3D4EBCB8.B86C3D97@Royer.com> Date: Mon, 05 Aug 2002 11:58:16 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <004401c23c77$27061500$0200a8c0@compaqp1000> <3D4E9457.33551A0B@Royer.com> <3D4E9F65.6000506@jsoft.com> <3D4EAC61.8F594F1@Royer.com> <3D4EB5F9.9020504@jsoft.com> Content-Type: multipart/mixed; boundary="------------EC1F379825EBB97BBAD3A775" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EC1F379825EBB97BBAD3A775 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > > DURATION! > > Part of the original question was how to represent a > day long event. Let me make sure I have it right. (part of your question - not the original - correct?) The original question ("ArentJan Banck" ) was: >...To specify a one-day event, shouldn't only DTSTART be set > to a DATE value, without a DTEND property? And the answer was yes. >... > > Use case #3 > > DTSTART;DATE:19971102 > DTEND;DATE:19971103 > > Valid and represents time. > ... > > ==== > > ... > > How long is use case #3? 24 hours? DTEND is the non-inclusive > end of the event. If so, would that be a way to represent an > event that was on 19971102? Seems like it to me. Yes - #3 represents a 24 hour one day event. I think this is a topic that was debated within the last year on calsch. As I recall, 2445 only talked about 'date-time', and I think the WG concluded that it also applied to 'date' when time was not supplied. Note: The original from page 25 of xcal as noted in the original email - has an RRULE. Just in case someone thinks I was responding to that one :-) --------------EC1F379825EBB97BBAD3A775 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------EC1F379825EBB97BBAD3A775-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 14:04:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25094 for ; Mon, 5 Aug 2002 14:04:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75I0CT04624 for ietf-calendar-bks; Mon, 5 Aug 2002 11:00:12 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75I0Bw04619 for ; Mon, 5 Aug 2002 11:00:11 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Question about iTIP + VCARs MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_08042002NP August 04, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 5 Aug 2002 14:00:02 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_07302002NP|July 30, 2002) at 08/05/2002 01:54:24 PM, Serialize complete at 08/05/2002 01:54:24 PM Content-Type: multipart/alternative; boundary="=_alternative 0062DEE685256C0C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062DEE685256C0C_= Content-Type: text/plain; charset="US-ASCII" Doug wrote: > The CS can store them any way the implementation wishes. > It is independent of the CAP protocol. Some implementations > may use the METHOD property, others may use some other metadata. Are you saying that a CS may be allowed to modify the METHOD property that a CUA specifies to suite its own need of storing metdata data about the entry?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0062DEE685256C0C_= Content-Type: text/html; charset="US-ASCII"
Doug wrote:
> The CS can store them any way the implementation wishes.
> It is independent of the CAP protocol. Some implementations
> may use the METHOD property, others may use some other metadata.

Are you saying that a CS may be allowed to modify the METHOD property that a CUA specifies to suite its own need of storing metdata data about the entry??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0062DEE685256C0C_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 5 14:39:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26573 for ; Mon, 5 Aug 2002 14:39:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75IWSK05481 for ietf-calendar-bks; Mon, 5 Aug 2002 11:32:28 -0700 (PDT) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75IWRw05477 for ; Mon, 5 Aug 2002 11:32:27 -0700 (PDT) Received: from jsoft.com (IDENT:EmfRfIHUHLBR+gOcg0gRoLMVnxhc/+am@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g75IRxT27420 for ; Mon, 5 Aug 2002 13:27:59 -0500 Message-ID: <3D4EC3AE.7050907@jsoft.com> Date: Mon, 05 Aug 2002 13:27:58 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <004401c23c77$27061500$0200a8c0@compaqp1000> <3D4E9457.33551A0B@Royer.com> <3D4E9F65.6000506@jsoft.com> <3D4EAC61.8F594F1@Royer.com> <3D4EB5F9.9020504@jsoft.com> <3D4EBCB8.B86C3D97@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Gary Frederick wrote: > >>DURATION! >> >>Part of the original question was how to represent a >>day long event. Let me make sure I have it right. > > > (part of your question - not the original - correct?) No. The original. > > The original question ("ArentJan Banck" ) > was: > > >...To specify a one-day event, shouldn't only DTSTART be set > > to a DATE value, without a DTEND property? > > And the answer was yes. Use case #1 is good for documenting an anniversary, something that does not need to take up time. I understood that the original question was about a one day event and I read it as an event that DID take time, one day - Use case #3 as you said below. > > >>... >> >>Use case #3 >> >> DTSTART;DATE:19971102 >> DTEND;DATE:19971103 >> >>Valid and represents time. >>... >> >>==== >> >>... >> >>How long is use case #3? 24 hours? DTEND is the non-inclusive >>end of the event. If so, would that be a way to represent an >>event that was on 19971102? Seems like it to me. > > > Yes - #3 represents a 24 hour one day event. I think this > is a topic that was debated within the last year on calsch. > As I recall, 2445 only talked about 'date-time', and I think the WG > concluded that it also applied to 'date' when time was not > supplied. I don't think it's worth modifying 2445, is there a faq that could clarify this and other points? > > Note: The original from page 25 of xcal as noted in the original > email - has an RRULE. Just in case someone thinks I was responding > to that one :-) Thanks, Gary From owner-ietf-calendar@mail.imc.org Mon Aug 5 14:41:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26671 for ; Mon, 5 Aug 2002 14:41:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75IZ1105533 for ietf-calendar-bks; Mon, 5 Aug 2002 11:35:01 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75IZ0w05529 for ; Mon, 5 Aug 2002 11:35:00 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g75IYx6U021856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 5 Aug 2002 11:35:02 -0700 Message-ID: <3D4EC551.F112D6E2@Royer.com> Date: Mon, 05 Aug 2002 12:34:57 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Re: Question about iTIP + VCARs] Content-Type: multipart/mixed; boundary="------------44BBE77329F341CA9E18C23F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------44BBE77329F341CA9E18C23F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [I accidentally sent my reply just to Bruce] -------- Original Message -------- Subject: Re: Question about iTIP + VCARs Date: Mon, 05 Aug 2002 12:33:34 -0600 From: Doug Royer Organization: http://INET-Consulting.com To: Bruce_Kahn@notesdev.ibm.com Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote: > > The CS can store them any way the implementation wishes. > > It is independent of the CAP protocol. Some implementations > > may use the METHOD property, others may use some other metadata. > > Are you saying that a CS may be allowed to modify the METHOD property > that a CUA specifies to suite its own need of storing metdata data > about the entry?? I am saying that whatever the CS does inside of the implementation does not effect the CAP wire protocol - as long as it stays inside the implementation. In my implementation, I store the METHOD property with each component - if it had one, else I use the METHOD property to store BOOKED or other internal flags. You and all CUAs will never see this - unless my CS is buggy. --------------44BBE77329F341CA9E18C23F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------44BBE77329F341CA9E18C23F-- From owner-ietf-calendar@mail.imc.org Tue Aug 6 07:40:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05954 for ; Tue, 6 Aug 2002 07:40:09 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g76BVwv19699 for ietf-calendar-bks; Tue, 6 Aug 2002 04:31:58 -0700 (PDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76BVuw19692 for ; Tue, 6 Aug 2002 04:31:56 -0700 (PDT) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g76BVkS23039 for ; Tue, 6 Aug 2002 04:31:46 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g76BVj223005 for ; Tue, 6 Aug 2002 04:31:45 -0700 (PDT) Received: from web155 (web155.oracle.com [148.87.16.128] (may be forged)) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g76BViK07952 for ; Tue, 6 Aug 2002 05:31:44 -0600 (MDT) Message-ID: <2428324.1028633346219.JavaMail.nobody@web155> Date: Tue, 6 Aug 2002 03:29:06 -0800 (GMT-08:00) From: "PATRICE.LAPIERRE" To: ietf-calendar@imc.org Subject: Re: No comments on my proposals? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 X-Mailer: Oracle Webmail Client Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Mon, 2002-08-05 at 13:01, Andrea Campi wrote: > ... > Anyway: if anybody supports the idea, great, otherwise I will stop > promoting it and just name my queries in an unlikely way... > Hi Andrea, If I understand correctly, the purpose of the proposition is to remove the ambiguity present when referring to a stored VQUERY having a non-unique QUERYID within the CS. I agree that removing the ambiguity is important. However I don't think that we need to introduce a new namespace to achieve this goal. A VQUERY may be stored in either the VCALSTORE or a VAGENDA. Your proposition could be modified to use the container as a namespace. i.e., The ambiguity could be removed by: 1. Enforcing the uniqueness QUERYID within its container (not the whole CS). 2. When referring to a stored VQUERY the container, where it's located, must be specified (otherwise the VCALSTORE is assumed). e.g., BEGIN:VCALENDAR VERSION:2.0 CMD:SEARCH TARGET:relcalid-where-to-search TARGET:another-relcalid-where-to-search BEGIN:VQUERY QUERYID:foo TARGET:relcalid-where-the-vquery-is-stored ; TARGET could be a parameter of QUERYID if people prefer. END:VQUERY END:VCALENDAR -- Patrice. From owner-ietf-calendar@mail.imc.org Tue Aug 6 12:02:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16248 for ; Tue, 6 Aug 2002 12:02:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76Fsfm14259 for ietf-calendar-bks; Tue, 6 Aug 2002 08:54:41 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76Fsdw14249 for ; Tue, 6 Aug 2002 08:54:39 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g76FsmM22250 for ; Tue, 6 Aug 2002 10:54:48 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 6 Aug 2002 10:54:41 -0500 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 6 Aug 2002 10:54:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: dtend/dtstart date value in sample iCalendar DTD Document (xCal) Date: Tue, 6 Aug 2002 10:54:39 -0500 Message-ID: <15A85922ED48294F80973D83F95074B6013684DC@daebe006.NOE.Nokia.com> Thread-Topic: dtend/dtstart date value in sample iCalendar DTD Document (xCal) Thread-Index: AcI8kb+USqmGI2KySOi7ManMzjV9KAAzqD0wAAAmQ/A= From: To: , , Cc: X-OriginalArrivalTime: 06 Aug 2002 15:54:40.0814 (UTC) FILETIME=[930ED4E0:01C23D61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g76Fsew14252 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I reread Doug's discussion of the subject thread and agree with him. Use of DTSTART _and_ DTEND would only work if the DTSTART and DTEND had DATETIME format and had DTEND>DTSTART values. -- Frank > -----Original Message----- > From: ext [mailto:Frank.Dawson@nokia.com] > Sent: Tuesday, August 06, 2002 08:46 > To: Doug@Royer.com; xcal-dev@inet-consulting.com > Cc: ietf-calendar@imc.org > Subject: RE: dtend/dtstart date value in sample iCalendar DTD Document > (xCal) > > > Either should be valid. The original is more explicit (ie, > has a precise start and end). From owner-ietf-calendar@mail.imc.org Tue Aug 6 12:17:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16758 for ; Tue, 6 Aug 2002 12:17:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76G9UQ14587 for ietf-calendar-bks; Tue, 6 Aug 2002 09:09:30 -0700 (PDT) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76G9Tw14583 for ; Tue, 6 Aug 2002 09:09:29 -0700 (PDT) Received: from jsoft.com (IDENT:g7SQ89OdIvHAzTvb/QlJm3gI4kozRypS@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g76G4WT03022; Tue, 6 Aug 2002 11:04:32 -0500 Message-ID: <3D4FF390.5030403@jsoft.com> Date: Tue, 06 Aug 2002 11:04:32 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank.Dawson@nokia.com CC: Doug@royer.com, xcal-dev@inet-consulting.com, ietf-calendar@imc.org Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <15A85922ED48294F80973D83F95074B6013684DC@daebe006.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Did you read my use cases on ietf-calendar? ... Use case #1 DTSTART;DATE:19971102 with no DTEND/DURATION is an event that takes up no time. ... Use case #3 DTSTART;DATE:19971102 DTEND;DATE:19971103 Valid and represents time. ... So you can represent an anniversary with Use case #1 and an one day event (12 hours long) with Use case #3. Gary Frank.Dawson@nokia.com wrote: > I reread Doug's discussion of the subject thread and agree with him. Use of DTSTART _and_ DTEND would only work if the DTSTART and DTEND had DATETIME format and had DTEND>DTSTART values. > > -- Frank > > >>-----Original Message----- >>From: ext [mailto:Frank.Dawson@nokia.com] >>Sent: Tuesday, August 06, 2002 08:46 >>To: Doug@Royer.com; xcal-dev@inet-consulting.com >>Cc: ietf-calendar@imc.org >>Subject: RE: dtend/dtstart date value in sample iCalendar DTD Document >>(xCal) >> >> >>Either should be valid. The original is more explicit (ie, >>has a precise start and end). > From owner-ietf-calendar@mail.imc.org Tue Aug 6 12:19:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16900 for ; Tue, 6 Aug 2002 12:19:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76GCWb14678 for ietf-calendar-bks; Tue, 6 Aug 2002 09:12:32 -0700 (PDT) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76GCVw14674 for ; Tue, 6 Aug 2002 09:12:31 -0700 (PDT) Received: from jsoft.com (IDENT:PznICN1bUrjOHfIicCQvpmlcyHVB3MA0@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g76G88T03055; Tue, 6 Aug 2002 11:08:08 -0500 Message-ID: <3D4FF467.5000808@jsoft.com> Date: Tue, 06 Aug 2002 11:08:07 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: xcal-dev@inet-consulting.com Subject: Re: dtend/dtstart date value in sample iCalendar DTD Document (xCal) References: <15A85922ED48294F80973D83F95074B6013684DC@daebe006.NOE.Nokia.com> <3D4FF390.5030403@jsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Make that So you can represent an anniversary with Use case #1 and an one day event with Use case #3. Gary Frederick wrote: > Did you read my use cases on ietf-calendar? > > ... > Use case #1 > > DTSTART;DATE:19971102 > > with no DTEND/DURATION is an event that takes up no time. > > ... > > > Use case #3 > > DTSTART;DATE:19971102 > DTEND;DATE:19971103 > > Valid and represents time. > > ... > So you can represent an anniversary with Use case #1 and an one day > event (12 hours long) with Use case #3. > > Gary > > Frank.Dawson@nokia.com wrote: > >> I reread Doug's discussion of the subject thread and agree with him. >> Use of DTSTART _and_ DTEND would only work if the DTSTART and DTEND >> had DATETIME format and had DTEND>DTSTART values. >> >> -- Frank >> >> >>> -----Original Message----- >>> From: ext [mailto:Frank.Dawson@nokia.com] >>> Sent: Tuesday, August 06, 2002 08:46 >>> To: Doug@Royer.com; xcal-dev@inet-consulting.com >>> Cc: ietf-calendar@imc.org >>> Subject: RE: dtend/dtstart date value in sample iCalendar DTD Document >>> (xCal) >>> >>> >>> Either should be valid. The original is more explicit (ie, has a >>> precise start and end). >> >> From owner-ietf-calendar@mail.imc.org Tue Aug 6 12:29:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17275 for ; Tue, 6 Aug 2002 12:29:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76GNRp15537 for ietf-calendar-bks; Tue, 6 Aug 2002 09:23:27 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76GNQw15530 for ; Tue, 6 Aug 2002 09:23:26 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g76GNO6U031316 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 6 Aug 2002 09:23:27 -0700 Message-ID: <3D4FF7FA.47CD26EC@Royer.com> Date: Tue, 06 Aug 2002 10:23:22 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No comments on my proposals? References: <2428324.1028633346219.JavaMail.nobody@web155> Content-Type: multipart/mixed; boundary="------------C6395A04123CC7536A971F1C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C6395A04123CC7536A971F1C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "PATRICE.LAPIERRE" wrote: > > On Mon, 2002-08-05 at 13:01, Andrea Campi wrote: > > ... > > Anyway: if anybody supports the idea, great, otherwise I will stop > > promoting it and just name my queries in an unlikely way... > > > > Hi Andrea, > > If I understand correctly, the purpose of the proposition > is to remove the ambiguity present when referring to a stored > VQUERY having a non-unique QUERYID within the CS. > > I agree that removing the ambiguity is important. However > I don't think that we need to introduce a new namespace to > achieve this goal. > > A VQUERY may be stored in either the VCALSTORE or a > VAGENDA. Your proposition could be modified to use the > container as a namespace. > > i.e., The ambiguity could be removed by: > > 1. Enforcing the uniqueness QUERYID within its > container (not the whole CS). It would help solve the uniqueness problem for owners of the container. But as I understand the issue, it would not solve all of the other issues (CUA's may have to still keep N number of QUERYID's mappings). It sounds like a good idea to me. And it gets the spirit of Andrea's idea and adds a way to ensure uniqueness. > 2. When referring to a stored VQUERY the container, > where it's located, must be specified (otherwise the > VCALSTORE is assumed). I could go with TARGET as a parameter, but some get upset when a property and parameter have the same name. So, I would lean towards adding TARGET as a property in VQUERY. --------------C6395A04123CC7536A971F1C Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------C6395A04123CC7536A971F1C-- From owner-ietf-calendar@mail.imc.org Tue Aug 6 13:26:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19572 for ; Tue, 6 Aug 2002 13:26:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76HGHE19656 for ietf-calendar-bks; Tue, 6 Aug 2002 10:16:17 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76HGGw19649 for ; Tue, 6 Aug 2002 10:16:16 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id E945215533; Tue, 6 Aug 2002 19:16:16 +0200 (CEST) Date: Tue, 6 Aug 2002 19:16:16 +0200 From: Andrea Campi To: "PATRICE.LAPIERRE" Cc: ietf-calendar@imc.org Subject: Re: No comments on my proposals? Message-ID: <20020806171616.GA20430@inet.it> References: <2428324.1028633346219.JavaMail.nobody@web155> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2428324.1028633346219.JavaMail.nobody@web155> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Aug 06, 2002 at 03:29:06AM -0800, PATRICE.LAPIERRE wrote: > > If I understand correctly, the purpose of the proposition > is to remove the ambiguity present when referring to a stored > VQUERY having a non-unique QUERYID within the CS. Not really, my purpose it to avoid conflicts between vendors calling similar (But not necessarily identical) queries in the same way. I wouldn't want to lose uniqueness! > I agree that removing the ambiguity is important. However > I don't think that we need to introduce a new namespace to > achieve this goal. I only propose introducing a new parameter, actually... > A VQUERY may be stored in either the VCALSTORE or a > VAGENDA. Your proposition could be modified to use the > container as a namespace. > > i.e., The ambiguity could be removed by: > > 1. Enforcing the uniqueness QUERYID within its > container (not the whole CS). > > 2. When referring to a stored VQUERY the container, > where it's located, must be specified (otherwise the > VCALSTORE is assumed). > In practice this is the same as I was proposing but I guess your version is cleaner. I also agree with Doug that we should avoid calling a parameter like a property, but at the same time I wouldn't use a TARGET property for this (right now TARGET has a very clear semantic) - the container this query is defined in is definitely a parameter. What if it was a parameter called SOURCE? BEGIN:VCALENDAR VERSION:2.0 CMD:SEARCH TARGET:relcalid-where-to-search TARGET:another-relcalid-where-to-search BEGIN:VQUERY QUERYID:SOURCE:relcalid-where-the-vquery-is-stored:foo END:VQUERY END:VCALENDAR Anywhere, I'm not going to argue on name or parameter vs property. What matters to me is that this solves my problem (which is not only mine I see). Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Tue Aug 6 13:44:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20537 for ; Tue, 6 Aug 2002 13:44:11 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g76Hbm922523 for ietf-calendar-bks; Tue, 6 Aug 2002 10:37:48 -0700 (PDT) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76Hblw22515 for ; Tue, 6 Aug 2002 10:37:47 -0700 (PDT) Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g76HbiT18473 for ; Tue, 6 Aug 2002 10:37:44 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g76HbhR18460 for ; Tue, 6 Aug 2002 10:37:43 -0700 (PDT) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g76HbgB11830 for ; Tue, 6 Aug 2002 11:37:42 -0600 (MDT) Received: from c-1241.in.steltor.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g76Hben11710; Tue, 6 Aug 2002 11:37:40 -0600 (MDT) Subject: Re: No comments on my proposals? From: Patrice Lapierre To: Andrea Campi Cc: ietf-calendar@imc.org In-Reply-To: <20020806171616.GA20430@inet.it> References: <2428324.1028633346219.JavaMail.nobody@web155> <20020806171616.GA20430@inet.it> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 06 Aug 2002 13:35:26 -0400 Message-Id: <1028655328.13913.51.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 2002-08-06 at 13:16, Andrea Campi wrote: > On Tue, Aug 06, 2002 at 03:29:06AM -0800, PATRICE.LAPIERRE wrote: > > > > If I understand correctly, the purpose of the proposition > > is to remove the ambiguity present when referring to a stored > > VQUERY having a non-unique QUERYID within the CS. > > Not really, my purpose it to avoid conflicts between vendors calling similar > (But not necessarily identical) queries in the same way. I wouldn't want to > lose uniqueness! Understood. > ... > What if it was a parameter called SOURCE? I agree. -- Patrice. From owner-ietf-calendar@mail.imc.org Tue Aug 6 14:41:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23170 for ; Tue, 6 Aug 2002 14:41:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76IZhM25044 for ietf-calendar-bks; Tue, 6 Aug 2002 11:35:43 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76IZgw25040 for ; Tue, 6 Aug 2002 11:35:42 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g76IZg6U032328 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 6 Aug 2002 11:35:44 -0700 Message-ID: <3D5016FC.8C357601@Royer.com> Date: Tue, 06 Aug 2002 12:35:40 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: No comments on my proposals? References: <2428324.1028633346219.JavaMail.nobody@web155> <20020806171616.GA20430@inet.it> Content-Type: multipart/mixed; boundary="------------D01509FCE221D3A1F7392C07" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D01509FCE221D3A1F7392C07 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > On Tue, Aug 06, 2002 at 03:29:06AM -0800, PATRICE.LAPIERRE wrote: > > > > If I understand correctly, the purpose of the proposition > > is to remove the ambiguity present when referring to a stored > > VQUERY having a non-unique QUERYID within the CS. > > Not really, my purpose it to avoid conflicts between vendors > calling similar (But not necessarily identical) queries in the same > way. I wouldn't want to lose uniqueness! I am not sure that adding TARGET to the VQUERY solves your issue. Two CUA vendors could still create a QUERYID 'my-favorite' and we solved nothing. > > > I agree that removing the ambiguity is important. However > > I don't think that we need to introduce a new namespace to > > achieve this goal. > > I only propose introducing a new parameter, actually... Called NAMESPACE :-) And it only adds another possible ambiguity. For example my company is INET-CONSULTING, and I frequently use 'INET' as a shorthand. I noticed that your company is 'inet.it', so I suspect you might also use 'INET'. We solved nothing. > > A VQUERY may be stored in either the VCALSTORE or a > > VAGENDA. Your proposition could be modified to use the > > container as a namespace. > > > > i.e., The ambiguity could be removed by: > > > > 1. Enforcing the uniqueness QUERYID within its > > container (not the whole CS). > > > > 2. When referring to a stored VQUERY the container, > > where it's located, must be specified (otherwise the > > VCALSTORE is assumed). > > > > In practice this is the same as I was proposing but I guess your > version is cleaner. > I also agree with Doug that we should avoid calling a parameter > like a property, but at the same time I wouldn't use a TARGET > property for this (right now TARGET has a very clear semantic) - > the container this query is defined in is definitely a parameter. In both cases TARGET means container. One for the QUERYID and one for the CMD. Looks like the same usage to me. > Anywhere, I'm not going to argue on name or parameter vs property. > What matters to me is that this solves my problem (which is not only > mine I see). Does it solve the problem? Two vendor CUA could still randomly select the same QUERYID in the same container (my CUA from work selected by my employer, and my CUA at home). In both cases (NAMESPACE or TARGET) the only thing we did was specify where the QUERYID is located. It does not solve the ambiguity problem. CUA's sill might not be able to use any QUERYID they choose to use. --------------D01509FCE221D3A1F7392C07 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------D01509FCE221D3A1F7392C07-- From owner-ietf-calendar@mail.imc.org Wed Aug 7 13:17:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29605 for ; Wed, 7 Aug 2002 13:17:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g77H8TN24528 for ietf-calendar-bks; Wed, 7 Aug 2002 10:08:29 -0700 (PDT) Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g77H8Sw24522 for ; Wed, 7 Aug 2002 10:08:28 -0700 (PDT) Received: from inet-mail2.oracle.com (localhost [127.0.0.1]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g77H8Pt16342 for ; Wed, 7 Aug 2002 10:08:25 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g77H8Ol16327 for ; Wed, 7 Aug 2002 10:08:24 -0700 (PDT) Received: from c-1241.in.steltor.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g77H8NK25636 for ; Wed, 7 Aug 2002 11:08:23 -0600 (MDT) Subject: TARGET in VQUERY (was: No comments on my proposals?) From: Patrice Lapierre To: ietf-calendar@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 07 Aug 2002 13:06:07 -0400 Message-Id: <1028739969.18782.107.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I think we all agree that a stored VQUERY must have unique QUERYID within its container (the VCALSTORE or a given VAGENDA). The next question is should uniqueness of QUERYID be enforced globally within a given CS? Personally I don't think so for the following reasons: 1. Consistency with other components present in CAP. e.g., CARIDs are only unique within their container. 2. Don't add dependencies between VAGENGAs e.g., When moving/copying a VAGENGA to another server I don't want the operation to fail because of a QUERYID conflict. 3. Efficiency: no need to verify all containers or maintain global repository. If we follow that direction, then within a CS there may be several stored VQUERYs with the same QUERYID and therefore we must provide a mean to uniquely identify them. The addition of a TARGET property in VQUERY addresses this issue, and may even allow a more efficient implementation since we don't need to search all the VAGENDAs to find the VQUERY. Regards, Patrice. From owner-ietf-calendar@mail.imc.org Thu Aug 8 06:15:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06781 for ; Thu, 8 Aug 2002 06:15:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g78AAGP04595 for ietf-calendar-bks; Thu, 8 Aug 2002 03:10:16 -0700 (PDT) Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g78AAEw04587 for ; Thu, 8 Aug 2002 03:10:14 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g78AADs15887 for ; Thu, 8 Aug 2002 11:10:13 +0100 Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Thu, 08 Aug 2002 11:10:14 +0100 (BST) Message-ID: <3D524384.6010300@samsungcontact.com> Date: Thu, 08 Aug 2002 11:10:12 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Search replies Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I am currently looking at the search command and want to check my understanding with a few questions: It might also be useful to add some more examples ,particuarly successful ones, in the search section of CAP (section 9.8). 1) Given the search command in section 9.8: C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: VERSION:2.0 C: CMD:SEARCH C: TARGET:relcal2 C: TARGET:relcal3 C: BEGIN:VQUERY C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID C: FROM VEVENT C: WHERE DTEND >= '19990310T080000Z' C: AND DTSTART <= '19990310T190000Z' C: AND STATE() = 'BOOKED' C: END:VQUERY C: END:VCALENDAR I would expect a successful responce to look like this: S: Content-Type: text/calendar S: BEGIN:VCALENDAR S: TARGET:relcal2 S: CMD:REPLY S: VERSION:2.0 S: BEGIN:VREPLY S: DTSTART:19990310T090000Z S: DTEND:19990310T100000Z S: SUMMARY:Meeting 1 S: UID:123456@xxx.yyy S: DTSTART:19990310T170000Z S: DTEND:19990310T180000Z S: SUMMARY:Meeting 2 S: UID:345678@xxx.yyy S: REQUEST-STATUS:2.0 S: END:VREPLY S: END:VCALENDAR S: Content-Type: text/calendar S: BEGIN:VCALENDAR S: TARGET:relcal3 S: CMD:REPLY S: VERSION:2.0 S: BEGIN:VREPLY S: DTSTART:19990310T090000Z S: DTEND:19990310T100000Z S: SUMMARY:Meeting 1 S: UID:123456@xxx.yyy S: REQUEST-STATUS:2.0 S: END:VREPLY S: END:VCALENDAR 2) If this is correct, then I think the example where VEVENT contents are not accessible should look like this: S: Content-Type: text/calendar S: BEGIN:VCALENDAR S: TARGET:relcal2 S: CMD:REPLY S: VERSION:2.0 S: BEGIN:VREPLY S: REQUEST-STATUS:4.1 S: END:VREPLY S: END:VCALENDAR S: Content-Type: text/calendar S: BEGIN:VCALENDAR S: TARGET:relcal3 S: CMD:REPLY S: VERSION:2.0 S: BEGIN:VREPLY S: REQUEST-STATUS:4.1 S: END:VREPLY S: END:VCALENDAR ie there should not be BEGIN:VEVENT / END:VEVENT lines TYPO: In cap08 page 117 2nd from last line, the last word is missing a d from the end - should be selected 3) If I want all the VEVENT objects from a VAGENDA do I use SELECT VEVENT FROM VAGENDA or SELECT * FROM VEVENT 4) From owner-ietf-calendar@mail.imc.org Thu Aug 8 11:12:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15461 for ; Thu, 8 Aug 2002 11:12:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g78F1WD22622 for ietf-calendar-bks; Thu, 8 Aug 2002 08:01:32 -0700 (PDT) Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g78F1Uw22618 for ; Thu, 8 Aug 2002 08:01:30 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g78F1UH13357 for ; Thu, 8 Aug 2002 16:01:31 +0100 Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Thu, 08 Aug 2002 16:01:31 +0100 (BST) Message-ID: <3D5287CA.1060409@samsungcontact.com> Date: Thu, 08 Aug 2002 16:01:30 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAL-QUERY definition Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Section 6.1.1 of cap draft 08 The formal definition has a number of things that are not used in it: cauprops capcprops uprop-list cprop-list There is not a cap-using, so cap-local cannot be defined so should be removed? The querycomp and queries seem to be defining a VQUERY which is done in 8.6 and should also be removed. If I am correct, it should look more like this: Formal Definition: The value type is defined by the following notation: cal-query = "SELECT" SP cap-cols SP "FROM" SP comp-name SP "WHERE" SP cap-expr / "SELECT" SP cap-cols SP "FROM" SP comp-name cap-cols = cap-col / ( cap-cols "," cap-col) / "*" cap-col = ; Any property name found in the component ; named in the comp-name used in the FROM clause. ; ; SELECT ORGANIZER FROM VEVENT ... ; ; OR ; ; A component name of an existing component contained ; inside of the comp-name used in the FROM clause. ; ; SELECT VALARM FROM VEVENT ... ; NOTE: there is NO space around the "," on ; the next line comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VAGENDA" / "VCAR" / "VCALSTORE" / "VQUERY" / iana-name / x-comp cap-expr = "(" cap-expr ")" / cap-term cap-term = cap-expr SP cap-logical SP cap-expr / cap-factor cap-logical = "AND" / "OR" cap-factor = cap-colval SP cap-oper SP col-value / cap-colval SP "NOT LIKE" SP col-value / cap-colval SP "LIKE" SP col-value / cap-colval SP "IS NULL" / cap-colval SP "IS NOT NULL" / col-value SP "NOT IN" cap-colval" / col-value SP "IN" cap-colval" cap-colval = cap-col / "PARAM(" cap-col "," cap-param ")" cap-param = ; Any parameter that may be contained in the cap-col ; in the supplied PARAM() function col-value = col-literal / "STATE()" / "SELF()" / "CAL-OWNERS()" / "CAL-OWNERS(" cal-address ")" / "CURRENT-TARGET()" cal-address = ; A CALID as define by CAP col-literal = "'" literal-data "'" literal-data = ; Any data that matches the value type of the ; column that is being compared. That is you can ; not compare PRIORITY to "some string" because ; PRIORITY has a value type of integer. If it is ; not preceded by the LIKE element, any '%' and '_' ; characters in the literal data are not treated as ; wildcard characters and do not have to be backslash ; escaped. ; ; OR ; ; If the literal-data is preceded by the LIKE ; element it may also contain the '%' and '_' ; wildcard characters. And if the literal data ; that is comparing contains any '%' or '_' ; characters, they MUST BE backslash escaped as ; described in the notes below in order for them not ; to be treated as wildcard characters. cap-oper = "=" / "!=" / "<" / ">" / "<=" / ">=" SP = ; A single white space ascii character ; (value in HEX %x20). x-comp = ; As defined in RFC 2445. iana-name = ; As defined in RFC 2445. Mark Davidson From owner-ietf-calendar@mail.imc.org Thu Aug 8 12:14:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18005 for ; Thu, 8 Aug 2002 12:14:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g78G8Tk24753 for ietf-calendar-bks; Thu, 8 Aug 2002 09:08:29 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g78G8Rw24748 for ; Thu, 8 Aug 2002 09:08:28 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 8F25415533; Thu, 8 Aug 2002 18:08:28 +0200 (CEST) Date: Thu, 8 Aug 2002 18:08:28 +0200 From: Andrea Campi To: ietf-calendar@imc.org Subject: answer to query for UNPROCESSED Message-ID: <20020808160828.GH72501@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, if I send a query like SELECT * FROM VEVENT WHERE STATE()='UNPROCESSED' what do I get back? I guess one mime object for each METHOD, right? Might be a good idea to add at least an example on the description for SEARCH, similar to the example for CREATE with >1 TARGET. Bye, Andrea Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Aug 8 13:16:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20099 for ; Thu, 8 Aug 2002 13:16:19 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g78HATl28469 for ietf-calendar-bks; Thu, 8 Aug 2002 10:10:29 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g78HARw28465 for ; Thu, 8 Aug 2002 10:10:27 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002080813165821989 for ; Thu, 08 Aug 2002 13:16:58 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 8 Aug 2002 13:08:45 -0400 Message-ID: <3D52A59D.8000702@centivinc.com> Date: Thu, 08 Aug 2002 13:08:45 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: RE: Application for port-number (1026)] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2002 17:08:45.0884 (UTC) FILETIME=[415A2FC0:01C23EFE] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > Hm, this is not good. I wonder if Microsoft registered those ports > with IANA. We can not register a port (completely) until a draft is > an RFC - CAP is not there yet. So, we may indeed have lost this port > number. Well, losing a port number isn't such a big deal; pre-RFC implementations, if any, will just have to make the change. (In the Unix world, they could just make sure to look up the port number via getprotobyname(3); then, even if they have to ship before RFC--bad idea--then they just have to change /etc/services.) -- /===========================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com| |Centiv |My opinions are my own. | |===========================================| |Newt Nuggets! | \===========================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 8 13:40:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20793 for ; Thu, 8 Aug 2002 13:40:52 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g78HY0129350 for ietf-calendar-bks; Thu, 8 Aug 2002 10:34:00 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g78HXxw29345 for ; Thu, 8 Aug 2002 10:33:59 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002080813403728401 for ; Thu, 08 Aug 2002 13:40:37 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 8 Aug 2002 13:32:25 -0400 Message-ID: <3D52AB29.6070007@centivinc.com> Date: Thu, 08 Aug 2002 13:32:25 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2002 17:32:25.0945 (UTC) FILETIME=[8FC64C90:01C23F01] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > John replied on 08/02/2002 03:47:43 PM: > > It might be clearer to add a new command to consolidate the entries, > > rather than having a DELETE happen as a side effect of CREATE. In that > > case, we'd add the restriction that CREATing a BOOKED entry will > fail if > > there's an UNPROCESSED entry with the same UID. > > This smacks big time of feature creep that will drag out the process > of creating CAP. I'm not so sure, actually; either we have feature creep or we have side effect creep. Both take the same amount of effort to agree on; side effect creep probably adds more effort to implement (since it's harder to QA). (Sorry about the delay in responding; I've been offline the past few days.) -- /===========================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com| |Centiv |My opinions are my own. | |===========================================| |Newt Nuggets! | \===========================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 24 12:54:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14038 for ; Sat, 24 Aug 2002 12:54:14 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7OGhAK05898 for ietf-calendar-bks; Sat, 24 Aug 2002 09:43:10 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7OGh9205890 for ; Sat, 24 Aug 2002 09:43:09 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7OGgmbB008455 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 24 Aug 2002 09:43:00 -0700 Message-ID: <3D67B706.B9AF1F57@Royer.com> Date: Sat, 24 Aug 2002 10:40:38 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY definition References: <3D5287CA.1060409@samsungcontact.com> Content-Type: multipart/mixed; boundary="------------3D31E375DAAB63291F8BB689" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3D31E375DAAB63291F8BB689 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks, it looks great to me and there have been no objections. I replaced the ABNF with the text you provided in the source. -Doug Mark Davidson wrote: > > Hi, > > Section 6.1.1 of cap draft 08 > > The formal definition has a number of things that are not used in it: > cauprops > capcprops > uprop-list > cprop-list > > There is not a cap-using, so cap-local cannot be defined so should be > removed? > > The querycomp and queries seem to be defining a VQUERY which is done in 8.6 > and should also be removed. > > If I am correct, it should look more like this: > > Formal Definition: The value type is defined by the following > notation: > > ... (see archives) --------------3D31E375DAAB63291F8BB689 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------3D31E375DAAB63291F8BB689-- From owner-ietf-calendar@mail.imc.org Sat Aug 24 13:01:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14158 for ; Sat, 24 Aug 2002 13:01:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7OGr1G06574 for ietf-calendar-bks; Sat, 24 Aug 2002 09:53:01 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7OGr0206566 for ; Sat, 24 Aug 2002 09:53:00 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7OGqxbB008511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 24 Aug 2002 09:53:02 -0700 Message-ID: <3D67B969.2430CA5E@Royer.com> Date: Sat, 24 Aug 2002 10:50:49 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: TARGET in VQUERY (was: No comments on my proposals?) References: <1028739969.18782.107.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------B6C3BF564DD332B81FB7DA75" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B6C3BF564DD332B81FB7DA75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > Hi, > > I think we all agree that a stored VQUERY must have unique > QUERYID within its container (the VCALSTORE or a given VAGENDA). > > The next question is should uniqueness of QUERYID be enforced > globally within a given CS? I agree. > Personally I don't think so for the following reasons: > > 1. Consistency with other components present in CAP. > e.g., CARIDs are only unique within their container. If you mean because the DEFAULT_VCARS are copied into each newly created VAGENDA - yes. > 2. Don't add dependencies between VAGENGAs > e.g., When moving/copying a VAGENGA to another server > I don't want the operation to fail because of a > QUERYID conflict. Yes that could be a big issue. I have seen no objections. > 3. Efficiency: no need to verify all containers or maintain > global repository. > > If we follow that direction, then within a CS there may be several > stored VQUERYs with the same QUERYID and therefore we must provide > a mean to uniquely identify them. > > The addition of a TARGET property in VQUERY addresses this issue, > and may even allow a more efficient implementation since we don't > need to search all the VAGENDAs to find the VQUERY. I agree. I have seen no objection, so I added to the CAP source. -Doug --------------B6C3BF564DD332B81FB7DA75 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------B6C3BF564DD332B81FB7DA75-- From owner-ietf-calendar@mail.imc.org Sat Aug 24 13:21:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14450 for ; Sat, 24 Aug 2002 13:21:27 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7OHFS307677 for ietf-calendar-bks; Sat, 24 Aug 2002 10:15:28 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7OHFR207673 for ; Sat, 24 Aug 2002 10:15:27 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7OHFQbB008660 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 24 Aug 2002 10:15:29 -0700 Message-ID: <3D67BEAC.1627CA38@Royer.com> Date: Sat, 24 Aug 2002 11:13:16 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Search replies References: <3D524384.6010300@samsungcontact.com> Content-Type: multipart/mixed; boundary="------------F539A1DFAE8843B5CEFFDC99" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F539A1DFAE8843B5CEFFDC99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Davidson wrote: > > Hi, > > I am currently looking at the search command and want to check my > understanding with a few questions: > > It might also be useful to add some more examples ,particuarly > successful ones, in the search section of CAP (section 9.8). > > 1) Given the search command in section 9.8: > > ... > > I would expect a successful responce to look like this: > ... > > 2) If this is correct, then I think the example where > VEVENT contents are not accessible should look like this: > > S: Content-Type: text/calendar > S: BEGIN:VCALENDAR > S: TARGET:relcal2 > S: CMD:REPLY > S: VERSION:2.0 > S: BEGIN:VREPLY > S: REQUEST-STATUS:4.1 > S: END:VREPLY > S: END:VCALENDAR > > S: Content-Type: text/calendar > S: BEGIN:VCALENDAR > S: TARGET:relcal3 > S: CMD:REPLY > S: VERSION:2.0 > S: BEGIN:VREPLY > S: REQUEST-STATUS:4.1 > S: END:VREPLY > S: END:VCALENDAR > > ie there should not be BEGIN:VEVENT / END:VEVENT lines The text describes that the VEVENT contents are not accessible. Not the VEVENT. So no. If the VEVENTs were not accessible - then yes. See the very next example that shows what to do when the the components are not accessible. It is the same as your suggested response. > TYPO: In cap08 page 117 2nd from last line, the last word is > missing a d from the end - should be selected Fixed - thanks. > 3) If I want all the VEVENT objects from a VAGENDA do I use > > SELECT VEVENT FROM VAGENDA It would give you: All of the VEVENTs from in VAGENDA and all if their properties wrapped in BEGIN/END VEVENT. > or > > SELECT * FROM VEVENT This would give your all of the properties from the VEVENTS in TARGET not wrapped in BEGIN/END VEVENT. --------------F539A1DFAE8843B5CEFFDC99 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------F539A1DFAE8843B5CEFFDC99-- From owner-ietf-calendar@mail.imc.org Sat Aug 24 13:41:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14889 for ; Sat, 24 Aug 2002 13:41:44 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7OHYnQ08377 for ietf-calendar-bks; Sat, 24 Aug 2002 10:34:49 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7OHYm208372 for ; Sat, 24 Aug 2002 10:34:48 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7OHYgbB008760 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 24 Aug 2002 10:34:45 -0700 Message-ID: <3D67C32F.8FC9E404@Royer.com> Date: Sat, 24 Aug 2002 11:32:31 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: answer to query for UNPROCESSED References: <20020808160828.GH72501@inet.it> Content-Type: multipart/mixed; boundary="------------A5A9145867AB95B0506F7490" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A5A9145867AB95B0506F7490 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > Hi all, > > if I send a query like > > SELECT * FROM VEVENT WHERE STATE()='UNPROCESSED' > > what do I get back? I guess one mime object for each METHOD, right? > Might be a good idea to add at least an example on the description > for SEARCH, similar to the example for CREATE with >1 TARGET. You would get back like all of the properties that are in all of the UNPROCESSED VEVENTs. You might really want: SELECT VEVENT FROM VAGENDA WHERE STATE() = 'UNPROCESSED' Which would give you all of the VEVENTs that were UNPROCESSED. --------------A5A9145867AB95B0506F7490 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------A5A9145867AB95B0506F7490-- From owner-ietf-calendar@mail.imc.org Sat Aug 24 14:11:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15370 for ; Sat, 24 Aug 2002 14:11:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7OI4ls09783 for ietf-calendar-bks; Sat, 24 Aug 2002 11:04:47 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7OI4k209779 for ; Sat, 24 Aug 2002 11:04:46 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7OI4jbB009130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 24 Aug 2002 11:04:48 -0700 Message-ID: <3D67CA3A.F89A9DBF@Royer.com> Date: Sat, 24 Aug 2002 12:02:34 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP - latest snapshot draft-ietf-calsch-cap-09b Content-Type: multipart/mixed; boundary="------------9C9A48E7AB94F4825D4CBC7D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9C9A48E7AB94F4825D4CBC7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have placed the latest snapshot (B version of -09) of CAP at: ftp://Royer.com/pub/CALSCH/cap.txt and ftp://Royer.com/pub/CALSCH/cap.html In addition to the e-mail I sent today, I: (1) Added a section that describes the 'PARAM()' cal-query function: X.Y PARAM() Used in a CAL-QUERY. Returns the value of the named parameter from the named property. If there are multiple properties in the object, then PARAM() returns a comma separated list of parameter values. If needed each value can be quoted or contain backslash escaped contents. (2) Defined 'container' to mean VCALSTORE or VAGENDA. As it was used in the TARGET section: Container - This is a generic name for VCALSTORE or VAGENDA.  (3) I replaced 'container' with 'component' when it mean any component, in several places. --------------9C9A48E7AB94F4825D4CBC7D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------9C9A48E7AB94F4825D4CBC7D-- From owner-ietf-calendar@mail.imc.org Mon Aug 26 12:36:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13785 for ; Mon, 26 Aug 2002 12:36:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7QGPsl02679 for ietf-calendar-bks; Mon, 26 Aug 2002 09:25:54 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7QGPq202675 for ; Mon, 26 Aug 2002 09:25:53 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 60016155B7; Mon, 26 Aug 2002 18:25:53 +0200 (CEST) Date: Mon, 26 Aug 2002 18:25:53 +0200 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: answer to query for UNPROCESSED Message-ID: <20020826162553.GD89476@inet.it> References: <20020808160828.GH72501@inet.it> <3D67C32F.8FC9E404@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D67C32F.8FC9E404@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, Aug 24, 2002 at 11:32:31AM -0600, Doug Royer wrote: > Andrea Campi wrote: > > > > what do I get back? I guess one mime object for each METHOD, right? > > Might be a good idea to add at least an example on the description > > for SEARCH, similar to the example for CREATE with >1 TARGET. > > You might really want: > > SELECT VEVENT FROM VAGENDA WHERE STATE() = 'UNPROCESSED' > > Which would give you all of the VEVENTs that were UNPROCESSED. Sorry, you're right. But I still would like to ask: what do I get back? Supposing I have two onprocessed entries, one REPLY and one COUNTER, I expect I would get: Content-Type: text/calendar BEGIN:VCALENDAR VERSION:2.0 PRODID:-//someone's prodid CMD:REPLY TARGET:cal.example.com METHOD:REPLY BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT END:VREPLY END:VCALENDAR Content-Type: text/calendar BEGIN:VCALENDAR VERSION:2.0 PRODID:-//someone's prodid CMD:REPLY TARGET:cal.example.com METHOD:COUNTER BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT END:VREPLY END:VCALENDAR Am I right? Can we add an example to clarify this? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Aug 26 15:41:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20472 for ; Mon, 26 Aug 2002 15:41:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7QJMte08027 for ietf-calendar-bks; Mon, 26 Aug 2002 12:22:55 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7QJMs208022 for ; Mon, 26 Aug 2002 12:22:54 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7QJMebB018128 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 26 Aug 2002 12:22:42 -0700 Message-ID: <3D6A7F65.E836A6E9@Royer.com> Date: Mon, 26 Aug 2002 13:20:05 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: answer to query for UNPROCESSED References: <20020808160828.GH72501@inet.it> <3D67C32F.8FC9E404@Royer.com> <20020826162553.GD89476@inet.it> Content-Type: multipart/mixed; boundary="------------502C2C17FFF84715CE281908" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------502C2C17FFF84715CE281908 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > Sorry, you're right. But I still would like to ask: what do I get back? > Supposing I have two onprocessed entries, one REPLY and one COUNTER, I > expect I would get: > > ... > > Am I right? Can we add an example to clarify this? If they are not the same METHOD, they MUST BE in separate BEGIN/END VCALENDAR objects (as you showed). If they are the same METHOD, then they can be in separate or the same objects. This is an iCalendar restriction, not a CAP protocol issue. I am not sure we need to restate this in CAP. --------------502C2C17FFF84715CE281908 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------502C2C17FFF84715CE281908-- From owner-ietf-calendar@mail.imc.org Tue Aug 27 11:53:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29110 for ; Tue, 27 Aug 2002 11:53:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7RFjRD06485 for ietf-calendar-bks; Tue, 27 Aug 2002 08:45:27 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RFjQ206481 for ; Tue, 27 Aug 2002 08:45:26 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id D31D2155B7; Tue, 27 Aug 2002 17:45:26 +0200 (CEST) Date: Tue, 27 Aug 2002 17:45:26 +0200 From: Andrea Campi To: ietf-calendar@imc.org Message-ID: <20020827154526.GC77082@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I just noticed one area of ambiguity wrt the LATENCY param. What is not clear if this applies to the whole transaction or if it's a proper latency, i.e. it applies only to the time before the first reply is sent. For example, imagine a search that returns multiple objects with different METHODs. The draft allows the server to send them using separate ANS BEEP frames. Should the server stop checking for the latency after the first ANS is sent, or should it keep checking and maybe abort halfway? The latter doesn't seem very useful IMHO. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Tue Aug 27 12:30:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00614 for ; Tue, 27 Aug 2002 12:30:22 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7RGJgA08430 for ietf-calendar-bks; Tue, 27 Aug 2002 09:19:42 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RGJf208420 for ; Tue, 27 Aug 2002 09:19:41 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 9EBA3155B7; Tue, 27 Aug 2002 18:19:42 +0200 (CEST) Date: Tue, 27 Aug 2002 18:19:42 +0200 From: Andrea Campi To: ietf-calendar@imc.org Subject: MIME encapsulation of multipart responses Message-ID: <20020827161942.GD77082@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7RGJg208424 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi all, I had a look at the archives and, while there was some discussion about the (optional) use of multipart/* mime types, I didn't see any agreement. I'm asking this because the draft is still ambigous on how to send multiple replies, in case multiple TARGETs or multiple METHODs are involved. For instance, in section 9.1.4: The CS would sends the REPLY in separate MIME objects, one per TARGET. S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR [...] And would send the second part of the reply later: S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR [...] multipart/* is obviously not used, but then I can't see any mean of determining where one body ends and the other one begins - I can only guess they can be in different ANS BEEP frames? Besides, the messages from Doug and other people left another opportunity open, that is, one body with more iCalendar containers: BEGIN:VCALENDAR .. END:VCALENDAR BEGIN:VCALENDAR .. END:VCALENDAR Thoughts? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Tue Aug 27 13:07:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02281 for ; Tue, 27 Aug 2002 13:07:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7RGn7D09810 for ietf-calendar-bks; Tue, 27 Aug 2002 09:49:07 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7RGn6209805 for ; Tue, 27 Aug 2002 09:49:06 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002082712562018428 for ; Tue, 27 Aug 2002 12:56:20 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Aug 2002 12:47:08 -0400 Message-ID: <3D6BAD0B.2080107@centivinc.com> Date: Tue, 27 Aug 2002 12:47:07 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2002 16:47:08.0788 (UTC) FILETIME=[62124B40:01C24DE9] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: >Besides, the messages from Doug and other people left another >opportunity open, that is, one body with more iCalendar containers: > >BEGIN:VCALENDAR >.. >END:VCALENDAR >BEGIN:VCALENDAR >.. >END:VCALENDAR > > That would not be legal text/calendar, any more than ... ... is legal XML--in both cases, you've got a forest when the spec says you have to have a tree. -- /================================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |================================================================| |"I said no camels! That's 5 camels! Can't you count?" -- Indiana| |Jones & TLC | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 27 15:41:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09237 for ; Tue, 27 Aug 2002 15:41:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7RJOcR22225 for ietf-calendar-bks; Tue, 27 Aug 2002 12:24:38 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RJOb222221 for ; Tue, 27 Aug 2002 12:24:37 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7RJOZbB027830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 27 Aug 2002 12:24:38 -0700 Message-ID: <3D6BD14B.39682F5@Royer.com> Date: Tue, 27 Aug 2002 13:21:47 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: References: <20020827154526.GC77082@inet.it> Content-Type: multipart/mixed; boundary="------------9F9C4FC15AD39BC5B69D01E4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9F9C4FC15AD39BC5B69D01E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > Hi all, > > I just noticed one area of ambiguity wrt the LATENCY param. What > is not clear if this applies to the whole transaction or if it's > a proper latency, i.e. it applies only to the time before the first > reply is sent. > For example, imagine a search that returns multiple objects with > different METHODs. The draft allows the server to send them using > separate ANS BEEP frames. Should the server stop checking for the > latency after the first ANS is sent, or should it keep checking and > maybe abort halfway? The latter doesn't seem very useful IMHO. 9.1.1 Bounded Latency ... If the command is unable to be completed in the specified amount of time ... Great question, it does look confusing. I would say that as the CS determines the timeout. It would know if it has completed the command and if it can complete the command. To muddy it more, if I were to write a multi-treaded CS and I handed each TARGET off to a separate thread, thread ONE could be done and sending, and thread TWO might not be able to complete - what do I do? (A) The CS must decide and the CUA must be able to handle ether: (1) no-answer and (2) partial-answers OR (B) Should a CS wait until it has all of the answers before sending any replies? And then if it does not have all of the answers by LATENCY - only then time out? I would lean towards (B), as it may make the CUA easier to implement?? --------------9F9C4FC15AD39BC5B69D01E4 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------9F9C4FC15AD39BC5B69D01E4-- From owner-ietf-calendar@mail.imc.org Tue Aug 27 16:09:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10644 for ; Tue, 27 Aug 2002 16:09:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7RK3gW24481 for ietf-calendar-bks; Tue, 27 Aug 2002 13:03:42 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7RK3f224475 for ; Tue, 27 Aug 2002 13:03:41 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002082716111407169 for ; Tue, 27 Aug 2002 16:11:14 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Aug 2002 16:02:03 -0400 Message-ID: <3D6BDABB.1000101@centivinc.com> Date: Tue, 27 Aug 2002 16:02:03 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: References: <20020827154526.GC77082@inet.it> <3D6BD14B.39682F5@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2002 20:02:03.0928 (UTC) FILETIME=[9CEB0980:01C24E04] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >(B) Should a CS wait until it has all of the answers before sending > any replies? And then if it does not have all of the answers > by LATENCY - only then time out? > >I would lean towards (B), as it may make the CUA easier to >implement?? > It depends on the answer to another question: when is the command completed? Is it when the CS has all the data, and can start sending, or when the CUA receives the last byte? Over a slow link, these could be very different--and, in the nature of TCP (and socket APIs), the CS will probably be completely unable to know how different. (I, of course, consider this yet another argument against including bounded latency in the protocol at all: it necessarily results in ill-defined behavior.) My first impulse was to say that (B) is the Right Thing, since the protocol can't expose whether the CS is multithreaded or not. However, waiting until you have all the data before sending any of it gratuitously increases latency, which is a Bad Thing. (It also increases the CS's memory requirements.) -- /============================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |============================================================| |In the country of the blind, the one-eyed man is in therapy.| \============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 27 20:08:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18071 for ; Tue, 27 Aug 2002 20:08:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7S055L06772 for ietf-calendar-bks; Tue, 27 Aug 2002 17:05:05 -0700 (PDT) Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RNcH205470; Tue, 27 Aug 2002 16:38:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 27 Aug 2002 16:38:17 -0700 To: (many IETF mailing lists) From: Paul Hoffman / IMC Subject: Nomcom call for volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Forwarded for Phil Roberts : The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. From owner-ietf-calendar@mail.imc.org Wed Aug 28 04:23:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20591 for ; Wed, 28 Aug 2002 04:23:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7S8Ii506961 for ietf-calendar-bks; Wed, 28 Aug 2002 01:18:44 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7S8Ig206957 for ; Wed, 28 Aug 2002 01:18:43 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 01776155B7; Wed, 28 Aug 2002 10:18:41 +0200 (CEST) Date: Wed, 28 Aug 2002 10:18:41 +0200 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: Message-ID: <20020828081841.GA80081@inet.it> References: <20020827154526.GC77082@inet.it> <3D6BD14B.39682F5@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6BD14B.39682F5@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7S8Ih206958 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Tue, Aug 27, 2002 at 01:21:47PM -0600, Doug Royer wrote: > To muddy it more, if I were to write a multi-treaded CS and > I handed each TARGET off to a separate thread, thread ONE > could be done and sending, and thread TWO might not be able > to complete - what do I do? Exactly. > (A) The CS must decide and the CUA must be able to handle ether: > (1) no-answer and (2) partial-answers > > OR > > (B) Should a CS wait until it has all of the answers before sending > any replies? And then if it does not have all of the answers > by LATENCY - only then time out? > What about: (C) The CS does preliminary processing bounded by the provided latency; if it's unable to complete by that, it aborts. The latency is only meaningful until the server sends the first part of the answer - either RPY or the first ANS - and then can take however long. Note that the "preliminary processing" might even include executing any needed SQL queries to the backend, so by the time it starts sending it can reasonably expect to be able to complete in at least a finite time. Note that the client can always decide to abort a transaction (by closing the channel) and can always detect whether an answer was complete and valid (by validating the iCalendar content; or we could even add a Content-Length header). These are desirable features, as in a GUI MUA the user may hit a stop button before the timeout has expired. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Aug 28 04:25:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20663 for ; Wed, 28 Aug 2002 04:25:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7S8LJh07085 for ietf-calendar-bks; Wed, 28 Aug 2002 01:21:19 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7S8LI207081 for ; Wed, 28 Aug 2002 01:21:18 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 80619155B7; Wed, 28 Aug 2002 10:21:17 +0200 (CEST) Date: Wed, 28 Aug 2002 10:21:17 +0200 From: Andrea Campi To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses Message-ID: <20020828082117.GB80081@inet.it> References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6BAD0B.2080107@centivinc.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7S8LI207082 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Tue, Aug 27, 2002 at 12:47:07PM -0400, John Stracke wrote: > That would not be legal text/calendar, any more than > > ... > ... > > is legal XML--in both cases, you've got a forest when the spec says you > have to have a tree. > I might be wrong, and please forgive me if I am, but: Content-Type: text/calendar ... Content-Type: text/calendar ... doesn't look any more valid to me. This would only leave multipart/related, then. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Aug 28 05:21:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21689 for ; Wed, 28 Aug 2002 05:21:49 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7S9Gdu11597 for ietf-calendar-bks; Wed, 28 Aug 2002 02:16:39 -0700 (PDT) Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7S9Gb211590 for ; Wed, 28 Aug 2002 02:16:37 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g7S9GGl17280; Wed, 28 Aug 2002 10:16:16 +0100 Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Wed, 28 Aug 2002 10:16:17 +0100 (BST) Message-ID: <3D6C94DC.2070306@samsungcontact.com> Date: Wed, 28 Aug 2002 10:16:12 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi CC: John Stracke , ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > I might be wrong, and please forgive me if I am, but: > > Content-Type: text/calendar > > ... > > Content-Type: text/calendar > > ... > > > doesn't look any more valid to me. > > This would only leave multipart/related, then. > Each responce is in a separate ANS (see BEEP) reply followed by a NUL reply. So if there is only a single text/calendar object as a reply it is sent as a RPY. If there are multiple text/calendar objects then each is send as an ANS. On the receiving end if you get a RPY you know this is the only response, if you get an ANS then you continue getting responces until you get a NUL. Mark From owner-ietf-calendar@mail.imc.org Wed Aug 28 05:36:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21887 for ; Wed, 28 Aug 2002 05:36:39 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7S9UnY13241 for ietf-calendar-bks; Wed, 28 Aug 2002 02:30:49 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7S9Um213237 for ; Wed, 28 Aug 2002 02:30:48 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id D4350155B7; Wed, 28 Aug 2002 11:30:47 +0200 (CEST) Date: Wed, 28 Aug 2002 11:30:47 +0200 From: Andrea Campi To: Mark Davidson Cc: John Stracke , ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses Message-ID: <20020828093047.GD80081@inet.it> References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6C94DC.2070306@samsungcontact.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7S9Um213238 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Wed, Aug 28, 2002 at 10:16:12AM +0100, Mark Davidson wrote: > Each responce is in a separate ANS (see BEEP) reply followed by a NUL reply. > > So if there is only a single text/calendar object as a reply it is sent as > a RPY. > > If there are multiple text/calendar objects then each is send as an ANS. > > On the receiving end if you get a RPY you know this is the only response, > if you get > an ANS then you continue getting responces until you get a NUL. This is really ok with me, but it's not stated that way in the draft. There's just a very brief mention of ANS wrt multiple targets, not multiple methods. Even then, the examples for CREATE only say: " The CS would sends the REPLY in separate MIME objects, one per TARGET. " But there is no mention that they are in separate ANS. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Aug 28 06:22:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22567 for ; Wed, 28 Aug 2002 06:22:46 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7SAEYU17040 for ietf-calendar-bks; Wed, 28 Aug 2002 03:14:34 -0700 (PDT) Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SAEW217033 for ; Wed, 28 Aug 2002 03:14:32 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g7SAEUx18724; Wed, 28 Aug 2002 11:14:30 +0100 Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Wed, 28 Aug 2002 11:14:30 +0100 (BST) Message-ID: <3D6CA27F.7000303@samsungcontact.com> Date: Wed, 28 Aug 2002 11:14:23 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi CC: John Stracke , ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <20020828093047.GD80081@inet.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: > On Wed, Aug 28, 2002 at 10:16:12AM +0100, Mark Davidson wrote: > >>Each responce is in a separate ANS (see BEEP) reply followed by a NUL reply. >> >>So if there is only a single text/calendar object as a reply it is sent as >>a RPY. >> >>If there are multiple text/calendar objects then each is send as an ANS. >> >>On the receiving end if you get a RPY you know this is the only response, >>if you get >>an ANS then you continue getting responces until you get a NUL. > > > This is really ok with me, but it's not stated that way in the draft. > There's just a very brief mention of ANS wrt multiple targets, not > multiple methods. Even then, the examples for CREATE only say: > " The CS would sends the REPLY in separate MIME objects, one per > TARGET. " > But there is no mention that they are in separate ANS. > > Bye, > Andrea > The draft kind of says something in section 11 (BEEP and CAP). But it would be better if it was more explicit. I might be wrong in how I am interpreting the draft, but it seemed to be the simplest answer when using BEEP. Mark From owner-ietf-calendar@mail.imc.org Wed Aug 28 16:38:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17924 for ; Wed, 28 Aug 2002 16:38:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SKJCE03108 for ietf-calendar-bks; Wed, 28 Aug 2002 13:19:12 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SKJB203103 for ; Wed, 28 Aug 2002 13:19:11 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7SKJAbB005739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 28 Aug 2002 13:19:12 -0700 Message-ID: <3D6D2F8B.8375F2F7@Royer.com> Date: Wed, 28 Aug 2002 14:16:11 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> Content-Type: multipart/mixed; boundary="------------629A843BA5296CFE81096324" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------629A843BA5296CFE81096324 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Andrea Campi wrote: > > >Besides, the messages from Doug and other people left another > >opportunity open, that is, one body with more iCalendar containers: > > > >BEGIN:VCALENDAR > >.. > >END:VCALENDAR > >BEGIN:VCALENDAR > >.. > >END:VCALENDAR > > > > > That would not be legal text/calendar, any more than > ... In 2445: > 4.4 iCalendar Object > > The Calendaring and Scheduling Core Object is a collection of > calendaring and scheduling information. Typically, this information > will consist of a single iCalendar object. However, multiple > iCalendar objects can be sequentially grouped together. The first > line and last line of the iCalendar object MUST contain a pair of > iCalendar object delimiter strings. The syntax for an iCalendar > object is as follows: > > icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF > icalbody > "END" ":" "VCALENDAR" CRLF) So, 'multiple iCalendar objects ... grouped together." Tells me that: BEGIN:VCALENDAR ... END:VCALENDAR BEGIN:VCALENDAR .. END:VCALENDAR Is valid. --------------629A843BA5296CFE81096324 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------629A843BA5296CFE81096324-- From owner-ietf-calendar@mail.imc.org Wed Aug 28 16:52:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18638 for ; Wed, 28 Aug 2002 16:52:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SKaHm04467 for ietf-calendar-bks; Wed, 28 Aug 2002 13:36:17 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SKaF204463 for ; Wed, 28 Aug 2002 13:36:15 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7SKa9bB005868 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 28 Aug 2002 13:36:14 -0700 Message-ID: <3D6D3385.9E1F9DCE@Royer.com> Date: Wed, 28 Aug 2002 14:33:09 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> Content-Type: multipart/mixed; boundary="------------609F020B8E776FABEA8A48EC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------609F020B8E776FABEA8A48EC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Davidson wrote: > > Each responce is in a separate ANS (see BEEP) reply followed by a NUL > reply. > > So if there is only a single text/calendar object as a reply it is sent > as a RPY. > > If there are multiple text/calendar objects then each is send as an ANS. > > On the receiving end if you get a RPY you know this is the only > response, if you get an ANS then you continue getting responces > until you get a NUL. I think we want to allow: (1) Multiple BEGIN/END VCALENDAR in one MIME body. All must be the same METHOD (per iCal or iMIP?) And I think 2445 "4.4 iCalendar Object" says we can. (2) Allow multipart/related, where each 'part' can have separate METHODs from the other 'parts'. Each MIME object (part) may have multiple BEGIN/END VCALENDAR This is so we can transport an entire VAGENDA or VCALSTORE in one multipart/related. In CAP, I think we need to allow for any ANS or RPY to have: (1) A single MIME object with a single icalobject. (2) A single MIME object with multiple icalobjects's. (All same METHOD). (3) A multipart/related MIME object, with each part being (1) or (2). And as each 'part' has a MIME header, each related object can have a unique METHOD. In some cases (T1 for example), everything in one blob will be faster with less CPU overhead (does it matter?) On small wireless devices, one large blob may give slower response if retransmission's and noise are an issue. As smaller packets tend to get through better. Is there a BEEP way that the Initiator can request ANS vs RPY? (I don't think so). I think that using ANS vs RPY is a transmission issue or a and I don't think that it is a technical gain one way or the other. If the Initiator has very little memory, it may want ANS with single mime objects with single icalobjects. --------------609F020B8E776FABEA8A48EC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------609F020B8E776FABEA8A48EC-- From owner-ietf-calendar@mail.imc.org Wed Aug 28 16:54:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18718 for ; Wed, 28 Aug 2002 16:54:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SKl9105072 for ietf-calendar-bks; Wed, 28 Aug 2002 13:47:09 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SKl3205063 for ; Wed, 28 Aug 2002 13:47:08 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7SKksbB005932 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 28 Aug 2002 13:46:58 -0700 Message-ID: <3D6D3609.54BC87F7@Royer.com> Date: Wed, 28 Aug 2002 14:43:53 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <20020828093047.GD80081@inet.it> <3D6CA27F.7000303@samsungcontact.com> Content-Type: multipart/mixed; boundary="------------F4DD1196FFA6557533711BA2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F4DD1196FFA6557533711BA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Davidson wrote: > > The draft kind of says something in section 11 (BEEP and CAP). But > it would be better if it was more explicit. I might be wrong in how > I am interpreting the draft, but it seemed to be the simplest > answer when using BEEP. I could flip a coin and be happy with the answer. I do not see that it matters to CAP. (I know we have to decide). If I do a 'get me the entire VAGENDA', which do I want: (a) One massive blob in a multipart/related MIME object. or (b) A massive amount of small blobs each in a single MIME object. or (c) A mixture of (a) and (b) with multiple icalobjects in each (b) of the same METHOD. Before we can decide on the ANS vs RPY. Are there any of the above we can eliminate as valid (outside of BEEP)? Are there more? --------------F4DD1196FFA6557533711BA2 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------F4DD1196FFA6557533711BA2-- From owner-ietf-calendar@mail.imc.org Wed Aug 28 16:58:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18847 for ; Wed, 28 Aug 2002 16:58:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SKqt805259 for ietf-calendar-bks; Wed, 28 Aug 2002 13:52:55 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7SKqs205254 for ; Wed, 28 Aug 2002 13:52:54 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002082817002717937 for ; Wed, 28 Aug 2002 17:00:27 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 Aug 2002 16:51:17 -0400 Message-ID: <3D6D37C5.3030301@centivinc.com> Date: Wed, 28 Aug 2002 16:51:17 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <3D6D2F8B.8375F2F7@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 20:51:17.0272 (UTC) FILETIME=[A7A95180:01C24ED4] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >>4.4 iCalendar Object >> >> The Calendaring and Scheduling Core Object is a collection of >> calendaring and scheduling information. Typically, this information >> will consist of a single iCalendar object. However, multiple >> iCalendar objects can be sequentially grouped together. >> Ah, bleep. I knew I should've checked the spec. (This'd be something to test for at CalConnect, BTW; I know I've written at least one parser that assumed there was only one iCalendar object per text/calendar, and I bet I'm not the only one.) -- /===========================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com| |Centiv |My opinions are my own. | |===========================================| |This space intentionally not left blank. | \===========================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 28 17:12:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19432 for ; Wed, 28 Aug 2002 17:12:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SL7rL05801 for ietf-calendar-bks; Wed, 28 Aug 2002 14:07:53 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7SL7q205793 for ; Wed, 28 Aug 2002 14:07:52 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002082817152205189 for ; Wed, 28 Aug 2002 17:15:22 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 Aug 2002 17:06:11 -0400 Message-ID: <3D6D3B43.5070602@centivinc.com> Date: Wed, 28 Aug 2002 17:06:11 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <20020828093047.GD80081@inet.it> <3D6CA27F.7000303@samsungcontact.com> <3D6D3609.54BC87F7@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 21:06:11.0628 (UTC) FILETIME=[BCBD36C0:01C24ED6] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > > (b) A massive amount of small blobs each in a single > MIME object. > I would recommend (b), on the grounds that it makes it easier to transport the iCalendar objects together outside of the BEEP and MIME wrappers--for example, if, N years from now, somebody wants to put CAP over a different transport. -- /===========================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com| |Centiv |My opinions are my own. | |===========================================| |This space intentionally not left blank. | \===========================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 28 17:16:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19573 for ; Wed, 28 Aug 2002 17:16:23 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7SLAKl05932 for ietf-calendar-bks; Wed, 28 Aug 2002 14:10:20 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7SLAI205927 for ; Wed, 28 Aug 2002 14:10:18 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002082817175103107 for ; Wed, 28 Aug 2002 17:17:51 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 Aug 2002 17:08:41 -0400 Message-ID: <3D6D3BD9.8090609@centivinc.com> Date: Wed, 28 Aug 2002 17:08:41 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 21:08:41.0789 (UTC) FILETIME=[163DF6D0:01C24ED7] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >I think we want to allow: > > (1) Multiple BEGIN/END VCALENDAR in one MIME body. > All must be the same METHOD (per iCal or iMIP?) > And I think 2445 "4.4 iCalendar Object" says > we can. > > (2) Allow multipart/related, where each 'part' can > have separate METHODs from the other 'parts'. Each > MIME object (part) may have multiple BEGIN/END > VCALENDAR > I don't think we want to allow multiple choices--There's More Than One Way To Do It is a curse, not a blessing. And why /related? What's the root object? >On small wireless devices, one large blob may give slower >response if retransmission's and noise are an issue. As smaller >packets tend to get through better. > I don't think this makes a difference--at and below the TCP level, the difference between packaging in MIME and packaging in iCalendar will be invisible. -- /===========================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com| |Centiv |My opinions are my own. | |===========================================| |This space intentionally not left blank. | \===========================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 28 18:07:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21637 for ; Wed, 28 Aug 2002 18:06:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SLvnF08720 for ietf-calendar-bks; Wed, 28 Aug 2002 14:57:49 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SLvm208714 for ; Wed, 28 Aug 2002 14:57:48 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7SLvmbB006478 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 28 Aug 2002 14:57:50 -0700 Message-ID: <3D6D46A7.C857E9B2@Royer.com> Date: Wed, 28 Aug 2002 15:54:47 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> Content-Type: multipart/mixed; boundary="------------7876EBA032EB3C6A88A932EF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7876EBA032EB3C6A88A932EF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > > >I think we want to allow: > > > > (1) Multiple BEGIN/END VCALENDAR in one MIME body. > > All must be the same METHOD (per iCal or iMIP?) > > And I think 2445 "4.4 iCalendar Object" says > > we can. > > > > (2) Allow multipart/related, where each 'part' can > > have separate METHODs from the other 'parts'. Each > > MIME object (part) may have multiple BEGIN/END > > VCALENDAR > > > I don't think we want to allow multiple choices--There's More Than One > Way To Do It is a curse, not a blessing. I think we do for the reasons below... > And why /related? What's the root object? What is an iCalendar 'root object'? No such item is needed. You can reconstruct a VAGENDA from booked items out of (original) order. > >On small wireless devices, one large blob may give slower > >response if retransmission's and noise are an issue. As smaller > >packets tend to get through better. > > > I don't think this makes a difference--at and below the TCP level, the > difference between packaging in MIME and packaging in iCalendar will be > invisible. As a HAM radio operator I can tell you if sending 1k of data; if you get air-wave noise 10 times, you can get this for the same 1k data blob: Sending 256 byte packets; you send 10 of the 256 byte packets 10 times. (2,560 retry bytes + 1,024 non-retry bytes sent) Sending 1k byte packets; you send 10 of the 1k byte packet 10 times. (10,240 retry bytes + 1,024 non-retry bytes sent) One large blob is almost always slower over the radio (and cell). I am saying that it can be an issue. On faster and more reliable transports, the overhead of small packets starts to be greater than the transmission time of larger packets. I think we need to allow for both one large blob and many small blobs. Let the CS decide. A CS implementation could know or be configured to know its 'average' user requirements and adjust the method. AND BECAUSE: All of the above are valid iCalendar objects. The one multipart/related huge blob can arrive now - per iCal. Correct? Multiple single icalobject MIME objects can arrive now - per iCal. Correct? --------------7876EBA032EB3C6A88A932EF Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------7876EBA032EB3C6A88A932EF-- From owner-ietf-calendar@mail.imc.org Wed Aug 28 18:43:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23071 for ; Wed, 28 Aug 2002 18:43:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SMZwI09875 for ietf-calendar-bks; Wed, 28 Aug 2002 15:35:58 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7SMZv209871 for ; Wed, 28 Aug 2002 15:35:57 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002082818433011589 for ; Wed, 28 Aug 2002 18:43:30 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 Aug 2002 18:34:20 -0400 Message-ID: <3D6D4FEC.2060502@centivinc.com> Date: Wed, 28 Aug 2002 18:34:20 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 22:34:20.0345 (UTC) FILETIME=[0D0F6290:01C24EE3] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >John Stracke wrote: > > >>Doug Royer wrote: >> >> >>And why /related? What's the root object? >> >> > >What is an iCalendar 'root object'? > There isn't one. But multipart/related has a single bodypart, the root, which coordinates the others--as in the case of an HTML email message which contains both the HTML page (the root) and the images it uses. Maybe you mean multipart/mixed? >>>On small wireless devices, one large blob may give slower >>>response if retransmission's and noise are an issue. As smaller >>>packets tend to get through better. >>> >>> >>> >>I don't think this makes a difference--at and below the TCP level, the >>difference between packaging in MIME and packaging in iCalendar will be >>invisible. >> >> > >As a HAM radio operator I can tell you if sending 1k of data; >if you get air-wave noise 10 times, you can get this >for the same 1k data blob: > Yeah, I *understand* that. But that's for the IP layer to worry about--it should set the MTU to match the link layer, so that TCP can do path MTU discovery. At the application layer, we just shovel bytes down the TCP pipe; formatting them into smaller or larger chunks won't make any difference in how they get broken into TCP segments, nor how the TCP segments get broken into IP packets. >I think we need to allow for both one large blob and >many small blobs. Let the CS decide. A CS implementation >could know or be configured to know its 'average' user requirements >and adjust the method. > That's both unnecessary (IP handles it) and undesirable (an application admin should not >The one multipart/related huge blob can arrive now - per iCal. >Correct? > Uh...no. The term "multipart/related" does not appear in RFC-2445. Nor is it a requirement for basic MIME processing. >Multiple single icalobject MIME objects can arrive now - per iCal. >Correct? > Yes. -- /===============================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |===============================================================| |Both candidates are better than a megalomaniac mutant lab mouse| |bent on world domination...but it's pretty close. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 28 19:49:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24912 for ; Wed, 28 Aug 2002 19:49:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SNj1U13967 for ietf-calendar-bks; Wed, 28 Aug 2002 16:45:01 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SNix213959 for ; Wed, 28 Aug 2002 16:44:59 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7SNivbB007636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 28 Aug 2002 16:45:01 -0700 Message-ID: <3D6D5FC4.B6709E0@Royer.com> Date: Wed, 28 Aug 2002 17:41:56 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> Content-Type: multipart/mixed; boundary="------------C925A57FE179FE8E36DBC4D2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C925A57FE179FE8E36DBC4D2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > >What is an iCalendar 'root object'? > > > There isn't one. But multipart/related has a single bodypart, the root, > which coordinates the others--as in the case of an HTML email message > which contains both the HTML page (the root) and the images it uses. > Maybe you mean multipart/mixed? It has been a while so maybe it is multipart/mixed that I mean. Is multipart/related when you have the first part that can contain CID's or MID's? If so, in 2445: 4.2.1 Alternate Text Representation ... DESCRIPTION;ALTREP="CID:":Project XYZ Review Meeting will include the following agenda items: (a) Market Overview, (b) Finances, (c) Project Management ... So multipart/ must be valid. > >The one multipart/related huge blob can arrive now - per iCal. > >Correct? > > > Uh...no. The term "multipart/related" does not appear in RFC-2445. Nor > is it a requirement for basic MIME processing. Nor is it (or multipart/) excluded - so it is valid. And I agree that it is not 'required', but iCalendar is a MIME object, and a MIME object can be multipart/ - correct? I remember this list talking about multipart/ pre CAP and just after the first cal-connect. Some implementations used it, others disallowed it. I think the consensus was that we can not mandate it, and can not disallow it. It was a MAY. It is not that hard to implement multilpart/. > >Multiple single icalobject MIME objects can arrive now - per iCal. > >Correct? > > > Yes. --------------C925A57FE179FE8E36DBC4D2 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------C925A57FE179FE8E36DBC4D2-- From owner-ietf-calendar@mail.imc.org Thu Aug 29 09:24:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21115 for ; Thu, 29 Aug 2002 09:24:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7TDH9A09922 for ietf-calendar-bks; Thu, 29 Aug 2002 06:17:09 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7TDH8209912 for ; Thu, 29 Aug 2002 06:17:08 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002082909243907849 for ; Thu, 29 Aug 2002 09:24:39 -0400 Received: from centivinc.com ([10.10.30.101]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 Aug 2002 09:15:29 -0400 Message-ID: <3D6E1ED7.5080202@centivinc.com> Date: Thu, 29 Aug 2002 09:17:11 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 13:15:29.0447 (UTC) FILETIME=[25802370:01C24F5E] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >It has been a while so maybe it is multipart/mixed that I mean. > >Is multipart/related when you have the first part that can >contain CID's or MID's? > Yes. >DESCRIPTION;ALTREP="CID:":Project > XYZ Review Meeting will include the following agenda items: (a) > Market Overview, (b) Finances, (c) Project Management > > ... > > >So multipart/ must be valid. > Not necessarily. A cid: URL can point to a body-part outside the current message (see RFC-2392, section 1, paragraph 3). Besides, examples aren't normative. >>>The one multipart/related huge blob can arrive now - per iCal. >>>Correct? >>> >>Uh...no. The term "multipart/related" does not appear in RFC-2445. Nor >>is it a requirement for basic MIME processing. >> > >Nor is it (or multipart/) excluded - so it is valid. > Oh, OK, so all CUAs have to understand multipart/I-just-made-it-up? >And I agree that it is not 'required', but iCalendar is a MIME >object, and a MIME object can be multipart/ - correct? > Yes, but a CUA is not required to understand the special semantics of multipart/related. >I remember this list talking about multipart/ pre CAP >and just after the first cal-connect. Some implementations >used it, others disallowed it. I think the consensus was that >we can not mandate it, and can not disallow it. It was a MAY. > I believe the context was that some iMIP implementations were refusing a multipart/ that contained a text/calendar body part. This was proven to be unacceptable because RFC-2049 says that any MIME-compliant MUA MUST recognize multipart/mixed ("show the user all the body parts and let them do what they will with it") and, if they don't understand multipart/foo, MUST treat it as multipart/mixed. The situation here is different, because RFC-2049 can't be taken to apply to CAP--or else we'd be requiring CUAs to accept text/plain from the CS. Besides, before we were trying to look at existing standards and figure out what they said; here we're writing a new standard. We need to agree on what the Right Thing is and write the spec to require it. So, the question remains: multipart/mixed or multiple VCALENDARs in a text/calendar? The only advantage I can see to multipart/mixed is that, if you're parsing the incoming text/calendar as it comes in, and see something that means you have to discard it (say, if you did a query that returned more than you really wanted, because you couldn't express what you wanted in the query language), then multipart/mixed offers an easy way to skip past the rest of the body part--just look for the multipart boundary. From owner-ietf-calendar@mail.imc.org Thu Aug 29 11:36:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27357 for ; Thu, 29 Aug 2002 11:36:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7TFUD818641 for ietf-calendar-bks; Thu, 29 Aug 2002 08:30:13 -0700 (PDT) Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7TFUC218633 for ; Thu, 29 Aug 2002 08:30:12 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g7TFUDg21849 for ; Thu, 29 Aug 2002 16:30:13 +0100 Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Thu, 29 Aug 2002 16:30:13 +0100 (BST) Message-ID: <3D6E3E05.9080106@samsungcontact.com> Date: Thu, 29 Aug 2002 16:30:13 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > So, the question remains: multipart/mixed or multiple VCALENDARs in a > text/calendar? The only advantage I can see to multipart/mixed is that, > if you're parsing the incoming text/calendar as it comes in, and see > something that means you have to discard it (say, if you did a query > that returned more than you really wanted, because you couldn't express > what you wanted in the query language), then multipart/mixed offers an > easy way to skip past the rest of the body part--just look for the > multipart boundary. > > Using multiparts seems to be an extra layer of complexity that is not needed. Currently CAP parsers only need to understand text/calendar and I'd rather keep it as simple as possible. Mark Davidson From owner-ietf-calendar@mail.imc.org Thu Aug 29 11:39:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27511 for ; Thu, 29 Aug 2002 11:39:48 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7TFNaP18203 for ietf-calendar-bks; Thu, 29 Aug 2002 08:23:36 -0700 (PDT) Received: from mail.samsungcontact.com (host195-89-159-51.uk.regusnet.com [195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7TFNY218195 for ; Thu, 29 Aug 2002 08:23:34 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g7TFNLh21697; Thu, 29 Aug 2002 16:23:21 +0100 Received: from samsungcontact.com (host195-89-159-62.uk.regusnet.com 195.89.159.62) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Thu, 29 Aug 2002 16:23:22 +0100 (BST) Message-ID: <3D6E3C69.40209@samsungcontact.com> Date: Thu, 29 Aug 2002 16:23:21 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Royer CC: ietf-calendar@imc.org Subject: Small correction in GENERATE-UID Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 9.2 the Response has a delete-vreply in it and the example is missing the request status. So it should be: Response: gen-reply = "BEGIN" ":" "VCALENDAR" CRLF calprops 1*(gen-vreply) "END" ":" "VCALENDAR" CRLF gen-vreply = "BEGIN" ":" "VREPLY" CRLF *(uid) request-status "END" ":" "VREPLY" CRLF Example: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//someone's prodid C: CMD;ID=unique-per-cua-124;OPTIONS=5:GENERATE-UID C: END:VCALENDAR S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR S: VERSION:2.0 S: PRODID:-//someone's prodid S: CMD;ID=unique-per-cua-124:REPLY S: BEGIN:VREPLY S: UID:20011121T120000Z-12340@cal.example.com S: UID:20011121T120000Z-12341@cal.example.com S: UID:20011121T120000Z-12342@cal.example.com S: UID:20011121T120000Z-12343@cal.example.com S: UID:20011121T120000Z-12344@cal.example.com S: REQUEST-STATUS:2.0 S: END:VREPLY S: END:VCALENDAR Mark Davidson From owner-ietf-calendar@mail.imc.org Thu Aug 29 12:36:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00179 for ; Thu, 29 Aug 2002 12:36:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7TGUob22536 for ietf-calendar-bks; Thu, 29 Aug 2002 09:30:50 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7TGUn222530 for ; Thu, 29 Aug 2002 09:30:49 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002082912382101696 for ; Thu, 29 Aug 2002 12:38:21 -0400 Received: from centivinc.com ([10.10.30.108]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 Aug 2002 12:29:10 -0400 Message-ID: <3D6E4C2A.6060303@centivinc.com> Date: Thu, 29 Aug 2002 12:30:34 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E3E05.9080106@samsungcontact.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 16:29:10.0741 (UTC) FILETIME=[3454E050:01C24F79] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Davidson wrote: > >> then multipart/mixed offers an easy way to skip past the rest of the >> body part--just look for the multipart boundary. > > Using multiparts seems to be an extra layer of complexity that is not > needed. I think I'd agree, but I wouldn't be too opposed if somebody came up with another benefit for multipart/mixed--after all, most implementors are going to use off-the-shelf MIME libraries, which will already have multipart. From owner-ietf-calendar@mail.imc.org Thu Aug 29 13:07:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02083 for ; Thu, 29 Aug 2002 13:07:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7TH1Xi24540 for ietf-calendar-bks; Thu, 29 Aug 2002 10:01:33 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7TH1W224536 for ; Thu, 29 Aug 2002 10:01:32 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7TH1VbB014525 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 29 Aug 2002 10:01:34 -0700 Message-ID: <3D6E52AE.E53B8D67@Royer.com> Date: Thu, 29 Aug 2002 10:58:22 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> Content-Type: multipart/mixed; boundary="------------2162A661E84A033BA2C06344" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2162A661E84A033BA2C06344 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > >So multipart/ must be valid. > > > Not necessarily. A cid: URL can point to a body-part outside the > current message (see RFC-2392, section 1, paragraph 3). No, re-read that RFC. A 'MID' can point out side of a message. A 'CID' points to a specific body part in the same message. > Besides, examples aren't normative. > > >>>The one multipart/related huge blob can arrive now - per iCal. > >>>Correct? > >>> > >>Uh...no. The term "multipart/related" does not appear in RFC-2445. Nor > >>is it a requirement for basic MIME processing. > >> > > > >Nor is it (or multipart/) excluded - so it is valid. > > > Oh, OK, so all CUAs have to understand multipart/I-just-made-it-up? No, but it seems clear to me that the examples in iCal (normative or not) should not be excluded from working in CAP. > So, the question remains: multipart/mixed or multiple VCALENDARs in a > text/calendar? I don't see that it has to be an OR. Multiple VCALENDARs in a single MIME body part are valid. And there are already iMIP implementations that can do multipart/mixed. (and thanks for the history). And don't forget xCal. The current plan is to allow sending multipart mixed with xCal and text/calendar (and plain text). --------------2162A661E84A033BA2C06344 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------2162A661E84A033BA2C06344-- From owner-ietf-calendar@mail.imc.org Thu Aug 29 13:12:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02345 for ; Thu, 29 Aug 2002 13:12:51 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7TH9Gb25366 for ietf-calendar-bks; Thu, 29 Aug 2002 10:09:16 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7TH9F225360 for ; Thu, 29 Aug 2002 10:09:15 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7TH93bB014560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 29 Aug 2002 10:09:05 -0700 Message-ID: <3D6E5471.FE19A27@Royer.com> Date: Thu, 29 Aug 2002 11:05:53 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Davidson CC: ietf-calendar@imc.org Subject: Re: Small correction in GENERATE-UID References: <3D6E3C69.40209@samsungcontact.com> Content-Type: multipart/mixed; boundary="------------3967289941CA359049592D3B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3967289941CA359049592D3B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Davidson wrote: > > In section 9.2 the Response has a delete-vreply in it and the example > is missing the request status. So it should be: Thanks, I have updated the draft. -Doug --------------3967289941CA359049592D3B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------3967289941CA359049592D3B-- From owner-ietf-calendar@mail.imc.org Fri Aug 30 06:10:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09719 for ; Fri, 30 Aug 2002 06:10:15 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7UA2wp20313 for ietf-calendar-bks; Fri, 30 Aug 2002 03:02:58 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7UA2r220295 for ; Fri, 30 Aug 2002 03:02:54 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 385A415528; Fri, 30 Aug 2002 12:02:51 +0200 (CEST) Date: Fri, 30 Aug 2002 12:02:51 +0200 From: Andrea Campi To: Mark Davidson Cc: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses Message-ID: <20020830100251.GB2968@inet.it> References: <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E3E05.9080106@samsungcontact.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6E3E05.9080106@samsungcontact.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 29, 2002 at 04:30:13PM +0100, Mark Davidson wrote: > > >So, the question remains: multipart/mixed or multiple VCALENDARs in a > >text/calendar? The only advantage I can see to multipart/mixed is that, > > Using multiparts seems to be an extra layer of complexity that is not > needed. > Currently CAP parsers only need to understand text/calendar and I'd rather > keep > it as simple as possible. Another thought just occurred to me. The same reasoning that allows multipart/* in answers would allow it in commands. THIS would be a mixed blessing: an initiator could send a multipart/* with multiple CREATE, but then it would have a bad time interpreting the answer (think what happens if some commands fail and some succeeds). IMHO this is too complicated, and I've yet to see any real advantage. I'd say if we have no really important reason to go this way, we should KISS. The only advantage to multipart/* that was mentioned in this thread is the opportunity to skip answers we're not interested in, but this could be accomplished even better using one-to-many ANS. I also disagree on the point that the choice between a single large blob or many small ones is irrelevant, or network performance related only - a multithread CUA would work better with many small ones, as it would be able to parse each of them independently and refresh its views. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Aug 30 08:57:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15124 for ; Fri, 30 Aug 2002 08:57:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UCjHb02793 for ietf-calendar-bks; Fri, 30 Aug 2002 05:45:17 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7UCjG202785 for ; Fri, 30 Aug 2002 05:45:16 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002083008524723174 for ; Fri, 30 Aug 2002 08:52:47 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Aug 2002 08:43:36 -0400 Message-ID: <3D6F6876.3030304@centivinc.com> Date: Fri, 30 Aug 2002 08:43:34 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E3E05.9080106@samsungcontact.com> <20020830100251.GB2968@inet.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 12:43:36.0839 (UTC) FILETIME=[DBE91170:01C25022] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: >disagree on the point that the choice between a single large blob or >many small ones is irrelevant, or network performance related only - >a multithread CUA would work better with many small ones, as it would >be able to parse each of them independently and refresh its views. > > I don't think that's true; with multipart/mixed, you still need a single-threaded MIME parser to split out the various iCalendar objects in any event, so your multiple threads are going to be blocking on that main parser. Plus, then you'll effectively be parsing the same data more than once (the first phase will be simpler, is all). With a single multiobject text/calendar, you can just run a single pass over the data; parse it as it comes in, and construct an internal representation of each object. When you hit an END:VCALENDAR, you can take that internal representation and pass it off to another thread, if you want. -- /===========================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com| |Centiv |My opinions are my own. | |===========================================| |A mime is a wonderful thing to waste. | \===========================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 30 09:03:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15301 for ; Fri, 30 Aug 2002 09:03:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UCxFL03462 for ietf-calendar-bks; Fri, 30 Aug 2002 05:59:15 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7UCxD203458 for ; Fri, 30 Aug 2002 05:59:13 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002083009064409590 for ; Fri, 30 Aug 2002 09:06:44 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Aug 2002 08:57:34 -0400 Message-ID: <3D6F6BBE.8040507@centivinc.com> Date: Fri, 30 Aug 2002 08:57:34 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E52AE.E53B8D67@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 12:57:34.0662 (UTC) FILETIME=[CF4AB660:01C25024] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >John Stracke wrote: > > > >>>So multipart/ must be valid. >>> >>> >>> >>Not necessarily. A cid: URL can point to a body-part outside the >>current message (see RFC-2392, section 1, paragraph 3). >> >> > >No, re-read that RFC. A 'MID' can point out side >of a message. A 'CID' points to a specific body part >in the same message. > Nope. You're thinking of RFC-1873, which defines the content-ID access type for message/external-body. That one refers only to body parts in the same message; but RFC-2392 explicitly states that cid: can cross messages. The paragraph I referenced says: The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide identifiers for messages and their body parts. The "mid" scheme uses (a part of) the message-id of an email message to refer to a specific message. The "cid" scheme refers to a specific body part of a message; its use is generally limited to references to other body parts in the same message as the referring body part. The "mid" scheme may also refer to a specific body part within a designated message, by including the content-ID's address. And, further down: The Content-ID of a MIME body part is required to be globally unique. And: Conforming implementations can choose to, but are not required to, take advantage of the content-id's uniqueness and interpret a "cid" URL to refer to any body part within the message store. >>Besides, examples aren't normative. >> >>Oh, OK, so all CUAs have to understand multipart/I-just-made-it-up? >> >> > >No, but it seems clear to me that the examples in iCal (normative >or not) should not be excluded from working in CAP. > The term "multipart" does not appear in RFC-2445. The use of "cid:" in an iCalendar object does not imply that the object is contained in a multipart message. >>So, the question remains: multipart/mixed or multiple VCALENDARs in a >>text/calendar? >> >I don't see that it has to be an OR. > Of course it does. When there's more than one equivalent way to do something, a standard should pick one. Otherwise, everybody has to implement both in order to interoperate. >And don't forget xCal. > See, case in point! > The current plan is to allow sending multipart >mixed with xCal and text/calendar (and plain text). > That's terrible. You'd spend bandwidth and cycles and gain absolutely no benefit in expressiveness or interoperability. -- /===========================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com| |Centiv |My opinions are my own. | |===========================================| |A mime is a wonderful thing to waste. | \===========================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 30 10:01:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17761 for ; Fri, 30 Aug 2002 10:01:01 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7UDsW106142 for ietf-calendar-bks; Fri, 30 Aug 2002 06:54:32 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7UDsV206137 for ; Fri, 30 Aug 2002 06:54:31 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 1A30715528; Fri, 30 Aug 2002 15:54:32 +0200 (CEST) Date: Fri, 30 Aug 2002 15:54:32 +0200 From: Andrea Campi To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses Message-ID: <20020830135431.GC2968@inet.it> References: <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E3E05.9080106@samsungcontact.com> <20020830100251.GB2968@inet.it> <3D6F6876.3030304@centivinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6F6876.3030304@centivinc.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Aug 30, 2002 at 08:43:34AM -0400, John Stracke wrote: > > Andrea Campi wrote: > > >disagree on the point that the choice between a single large blob or > >many small ones is irrelevant, or network performance related only - > >a multithread CUA would work better with many small ones, as it would > >be able to parse each of them independently and refresh its views. > > > > > I don't think that's true; with multipart/mixed, you still need a > single-threaded MIME parser to split out the various iCalendar objects > in any event, so your multiple threads are going to be blocking on that > main parser. Plus, then you'll effectively be parsing the same data Sorry, my fault for not being clear. When I said many small ones, I meant multiple ANS each containing a single text/calendar (with one or a few iCalendar objects). A multipart/mixed would still qualify as a single large one from the point of view of a multithreaded client, for the exact reason you mentioned. So, we're basically agreeing, you just explained it better ;-) Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Aug 30 13:31:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26835 for ; Fri, 30 Aug 2002 13:31:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UHLYt17067 for ietf-calendar-bks; Fri, 30 Aug 2002 10:21:34 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7UHLX217061 for ; Fri, 30 Aug 2002 10:21:33 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7UHLMbB025200 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 30 Aug 2002 10:21:34 -0700 Message-ID: <3D6FA8C8.DE03F80A@Royer.com> Date: Fri, 30 Aug 2002 11:18:00 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E3E05.9080106@samsungcontact.com> <20020830100251.GB2968@inet.it> Content-Type: multipart/mixed; boundary="------------6AC66A906B8F1C01175A7FF4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6AC66A906B8F1C01175A7FF4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > On Thu, Aug 29, 2002 at 04:30:13PM +0100, Mark Davidson wrote: > > > > >So, the question remains: multipart/mixed or multiple VCALENDARs in a > > >text/calendar? The only advantage I can see to multipart/mixed is that, > > > > Using multiparts seems to be an extra layer of complexity that is not > > needed. > > Currently CAP parsers only need to understand text/calendar and I'd rather > > keep > > it as simple as possible. > > Another thought just occurred to me. The same reasoning that allows > multipart/* in answers would allow it in commands. THIS would be a > mixed blessing: an initiator could send a multipart/* with multiple > CREATE, but then it would have a bad time interpreting the answer > (think what happens if some commands fail and some succeeds). Each would need to have a CMD and ID, so they would be uniquely identifiable just as if they had been sent separately. > IMHO this is too complicated, and I've yet to see any real advantage. > I'd say if we have no really important reason to go this way, we should > KISS. We would be electing not to allow all valid 2445 mime objects. How about a capability property to say that the endpoint can handle multipart/? And if not provided, then no. Such as: MULTIPART: related, mixed, ... > The only advantage to multipart/* that was mentioned in this thread > is the opportunity to skip answers we're not interested in, but this > could be accomplished even better using one-to-many ANS. Why would that be better? I see it as just different. > I also disagree on the point that the choice between a single large > blob or many small ones is irrelevant, or network performance related > only - a multithread CUA would work better with many small ones, as > it would be able to parse each of them independently and refresh > its views. How about a capability property: MULTIPLE-VCAL: TRUE / FALSE If FALSE, then the endpoint only allows for a single VCALENDAR per MIME object, if TRUE multiple per MIME object with the same METHOD are allowed. Then state that if MULTIPLE-VCAL is FALSE, then use one-to-many ANS. And state that a CS MUST be able to handle a CUA that has no MULTIPART and MULTIPLE-VCAL:FALSE. --------------6AC66A906B8F1C01175A7FF4 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------6AC66A906B8F1C01175A7FF4-- From owner-ietf-calendar@mail.imc.org Fri Aug 30 13:36:51 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27120 for ; Fri, 30 Aug 2002 13:36:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UHTWw18243 for ietf-calendar-bks; Fri, 30 Aug 2002 10:29:32 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7UHTV218237 for ; Fri, 30 Aug 2002 10:29:31 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g7UHTVbB025249 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 30 Aug 2002 10:29:33 -0700 Message-ID: <3D6FAAB1.F1ABDC4D@Royer.com> Date: Fri, 30 Aug 2002 11:26:09 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E52AE.E53B8D67@Royer.com> <3D6F6BBE.8040507@centivinc.com> Content-Type: multipart/mixed; boundary="------------FF72BFAB340A356043A35DB2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FF72BFAB340A356043A35DB2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > > >John Stracke wrote: > > > > > > > >>>So multipart/ must be valid. > >>> > >>> > >>> > >>Not necessarily. A cid: URL can point to a body-part outside the > >>current message (see RFC-2392, section 1, paragraph 3). > >> > >> > > > >No, re-read that RFC. A 'MID' can point out side > >of a message. A 'CID' points to a specific body part > >in the same message. > > > Nope. ... > ....Conforming > implementations can choose to, but are not required to, take > advantage of the content-id's uniqueness and interpret a "cid" URL to > refer to any body part within the message store. Your right. I was confused. A MID can refer to outside the store, I got that mixed up - thanks. > >>Oh, OK, so all CUAs have to understand multipart/I-just-made-it-up? > >> > >> > > > >No, but it seems clear to me that the examples in iCal (normative > >or not) should not be excluded from working in CAP. > > > The term "multipart" does not appear in RFC-2445. The use of "cid:" in > an iCalendar object does not imply that the object is contained in a > multipart message. I does in 2445: Example: DESCRIPTION;ALTREP="CID:":Project XYZ Review Meeting will include the following agenda items: (a) Market Overview, (b) Finances, (c) Project Management --> The "ALTREP" property parameter value might point to a "text/html" content portion. If it is not talking about another body part, what is it? > >>So, the question remains: multipart/mixed or multiple VCALENDARs in a > >>text/calendar? > >> > >I don't see that it has to be an OR. > > > Of course it does. When there's more than one equivalent way to do > something, a standard should pick one. Otherwise, everybody has to > implement both in order to interoperate. No, a standard must pick one as a must. And make sure that things interoperate. But disallowing some valid 2445 MIME objects in CAP is the wrong thing to do. --------------FF72BFAB340A356043A35DB2 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------FF72BFAB340A356043A35DB2-- From owner-ietf-calendar@mail.imc.org Fri Aug 30 13:56:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28035 for ; Fri, 30 Aug 2002 13:56:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UHqZb19496 for ietf-calendar-bks; Fri, 30 Aug 2002 10:52:35 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7UHqX219492 for ; Fri, 30 Aug 2002 10:52:33 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002083014000513583 for ; Fri, 30 Aug 2002 14:00:05 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Aug 2002 13:50:55 -0400 Message-ID: <3D6FB080.2010100@centivinc.com> Date: Fri, 30 Aug 2002 13:50:56 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME encapsulation of multipart responses References: <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E3E05.9080106@samsungcontact.com> <20020830100251.GB2968@inet.it> <3D6FA8C8.DE03F80A@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 17:50:55.0507 (UTC) FILETIME=[CA368630:01C2504D] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >We would be electing not to allow all valid 2445 mime objects. > 2445 says nothing about multipart. >How about a capability property to say that the endpoint can handle >multipart/? And if not provided, then no. > [...] >How about a capability property: > > MULTIPLE-VCAL: TRUE / FALSE > No, this is illegitimate, because iCalendar permits multiple objects per text/calendar. -- /=====================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |=====================================================| |"No, no, that's *not* a boat, that's Queen Victoria."| \=====================================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 30 14:04:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28446 for ; Fri, 30 Aug 2002 14:04:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UHxK819645 for ietf-calendar-bks; Fri, 30 Aug 2002 10:59:20 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7UHxJ219641 for ; Fri, 30 Aug 2002 10:59:19 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002083014065103247 for ; Fri, 30 Aug 2002 14:06:51 -0400 Received: from centivinc.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Aug 2002 13:57:41 -0400 Message-ID: <3D6FB216.5070604@centivinc.com> Date: Fri, 30 Aug 2002 13:57:42 -0400 From: John Stracke Organization: Centiv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME encapsulation of multipart responses References: <20020827161942.GD77082@inet.it> <3D6BAD0B.2080107@centivinc.com> <20020828082117.GB80081@inet.it> <3D6C94DC.2070306@samsungcontact.com> <3D6D3385.9E1F9DCE@Royer.com> <3D6D3BD9.8090609@centivinc.com> <3D6D46A7.C857E9B2@Royer.com> <3D6D4FEC.2060502@centivinc.com> <3D6D5FC4.B6709E0@Royer.com> <3D6E1ED7.5080202@centivinc.com> <3D6E52AE.E53B8D67@Royer.com> <3D6F6BBE.8040507@centivinc.com> <3D6FAAB1.F1ABDC4D@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 17:57:41.0145 (UTC) FILETIME=[BBFDF890:01C2504E] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >>The term "multipart" does not appear in RFC-2445. The use of "cid:" in >>an iCalendar object does not imply that the object is contained in a >>multipart message. >> >> > >I does in 2445: > > Example: > > DESCRIPTION;ALTREP="CID:":Project > XYZ Review Meeting will include the following agenda items: (a) > Market Overview, (b) Finances, (c) Project Management > >--> The "ALTREP" property parameter value might point to a "text/html" > content portion. > >If it is not talking about another body part, what is it? > It's another body part *in another message*. >>>>So, the question remains: multipart/mixed or multiple VCALENDARs in a >>>>text/calendar? >>>> >>>> >>>> >>>I don't see that it has to be an OR. >>> >>> >>> >>Of course it does. When there's more than one equivalent way to do >>something, a standard should pick one. Otherwise, everybody has to >>implement both in order to interoperate. >> >> > >No, a standard must pick one as a must. And make sure that > > >things interoperate. > A standard MUST provide at least MTI option. A standard MAY provide extra options; but, if those options are equivalent in semantics, it SHOULD NOT. We already have multiple VCALENDARs in a single text/calendar; packaging them instead as multiple text/calendars in a multipart/mixed will not add any new semantics. Therefore, we SHOULD NOT permit multipart/mixed in CAP. >But disallowing some valid 2445 MIME objects >in CAP is the wrong thing to do. > MIME multipart is *not* valid in 2445. -- /=====================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |=====================================================| |"No, no, that's *not* a boat, that's Queen Victoria."| \=====================================================/ From subs-reminder@imc.org Sat Aug 31 17:00:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12317 for ; Sat, 31 Aug 2002 17:00:19 -0400 (EDT) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g7VL1kM05245; Sat, 31 Aug 2002 14:01:46 -0700 (PDT) Date: Sat, 31 Aug 2002 14:01:46 -0700 (PDT) Message-Id: <200208312101.g7VL1kM05245@above.proper.com> To: calsch-archive@ietf.org Subject: [[054270131]] Subscription to ietf-calendar for calsch-archive@lists.ietf.org Greetings. This message is a periodic reminder that calsch-archive@lists.ietf.org is subscribed to the ietf-calendar mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-calendar mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "calsch-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator