From owner-ietf-calendar@mail.imc.org Sat Mar 1 07:20:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03648 for ; Sat, 1 Mar 2003 07:20:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h21C8eY13494 for ietf-calendar-bks; Sat, 1 Mar 2003 04:08:40 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h21C8dY13490 for ; Sat, 1 Mar 2003 04:08:39 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 51C46155C6; Sat, 1 Mar 2003 13:08:34 +0100 (CET) Date: Sat, 1 Mar 2003 13:08:34 +0100 From: Andrea Campi To: Mark Swanson Cc: "ietf-calendar@imc.org" Subject: Re: The charset issue Message-ID: <20030301120834.GA50051@inet.it> References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> <200302280850.26773.mark@WebServiceSolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302280850.26773.mark@WebServiceSolutions.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Feb 28, 2003 at 08:50:26AM -0500, Mark Swanson wrote: > Perhaps you missed the discussion about this. > There is a big problem with it: if test1.ics is in utf-8 and test2.ics is in > latin1 the web server will serve both as latin1. This can not work. Uhm... I see no reason why that should be the case. It's an implementation detail really, but just for an example, CERN-style meta files have been around for like 10 years; if using Apache you can also use mod_asis, even though it's not optimal. Or even if using static files you could pass all requests through a script which determines the appropriate charset via your preferred mechanism, and adds it to the MIME headers. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - 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 Sat Mar 1 07:25:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03726 for ; Sat, 1 Mar 2003 07:25:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h21CKVp13934 for ietf-calendar-bks; Sat, 1 Mar 2003 04:20:31 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h21CKUY13929 for ; Sat, 1 Mar 2003 04:20:30 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 25A47155C6; Sat, 1 Mar 2003 13:20:30 +0100 (CET) Date: Sat, 1 Mar 2003 13:20:30 +0100 From: Andrea Campi To: Mark Swanson Cc: "ietf-calendar@imc.org" Subject: Re: The charset issue Message-ID: <20030301122030.GB50051@inet.it> References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> <200302280917.04804.mark@WebServiceSolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302280917.04804.mark@WebServiceSolutions.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Feb 28, 2003 at 09:17:04AM -0500, Mark Swanson wrote: > On February 28, 2003 06:23 am, Andrea Campi wrote: > > > > Since the discussion has reached (IMO) a dead end, I'll voice my opinion. > > I am 1000% of Doug's opinion. Mark, you are presenting a non-compliant > > implementation as reason for changing RFC2445. Like it or not, an http > > No Andrea. This is not why I am doing this at all. > Perhaps a summary of reasons will help: > > 1. MIME is not the universe (to steal a phrase from John Stacke :-). 2445 > states iCalendar objects are to work fine outside the MIME environment. To > quote from 2445, "the format in this memo is equally applicable for use > outside of a MIME message content type.". This is exactly the reason why I think no change is necessary. If you are in a MIME environment, use MIME. If you are not, you MUST use UTF-8. I think this is quite reasonable in fact. > There are the obvious examples of using an iCalendar object outside the MIME > environment: http/ftp/custom protocols - even copying the iCalendar object as > presented by Outlook (in text format, which does not show the MIME headers as > part of the iCalendar object) to the clipboard. John Strake has stated that > no MIME implementations (MUA or HTTP) include the MIME headers when it saves > a MIME body-part. You see - implementation errors. ;-) Even for clipboards, you do have a choice - you can trancode to UTF-8 before sending the data to the clipboard, i.e. before throwing away the charset information. I agree with you that it would be nice to be universally compatible; however, I don't think that should be done by compromising on the present clean specification - expecially since I still haven't seen a single example where implementations could not do The Right Thing (TM) within the standard. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - 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 Sat Mar 1 07:32:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03797 for ; Sat, 1 Mar 2003 07:32:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h21CNoE14005 for ietf-calendar-bks; Sat, 1 Mar 2003 04:23:50 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h21CNnY14001 for ; Sat, 1 Mar 2003 04:23:49 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 82E2B155C6; Sat, 1 Mar 2003 13:23:49 +0100 (CET) Date: Sat, 1 Mar 2003 13:23:49 +0100 From: Andrea Campi To: Lawrence Greenfield Cc: Mark Swanson , "ietf-calendar@imc.org" Subject: Re: The charset issue Message-ID: <20030301122349.GC50051@inet.it> References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> <200302280917.04804.mark@WebServiceSolutions.com> <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Feb 28, 2003 at 01:43:07PM -0500, Lawrence Greenfield wrote: > There are the obvious examples of using an iCalendar object outside > the MIME environment: http/ftp/custom protocols - even copying the > iCalendar object as presented by Outlook (in text format, which > does not show the MIME headers as part of the iCalendar object) to > the clipboard. John Strake has stated that no MIME implementations > (MUA or HTTP) include the MIME headers when it saves a MIME > body-part. > > Of course not. They should save objects in the local charset, doing > conversions if necessary. Absolutely not, they should convert everything to UTF-8. I honestly can't see the reason for NOT doing that - since any conforming implementation MUST be able to handle at least UTF-8, why go to the effort of using anything else as a native charset? I mean I can see the need to import or even export data in different charsets, but UTF-8 should be the main one. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - 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 Sun Mar 2 18:25:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21092 for ; Sun, 2 Mar 2003 18:25:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h22NFZ624449 for ietf-calendar-bks; Sun, 2 Mar 2003 15:15:35 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22NFXY24445 for ; Sun, 2 Mar 2003 15:15:33 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: Push of CAP to ietf MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Sun, 2 Mar 2003 18:15:35 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/02/2003 06:15:37 PM, Serialize complete at 03/02/2003 06:15:37 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks. We're getting ready to update the calsch website as well. I have a person who has volunteered to keep it up to date - I'm getting too busy to be very current. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 02/28/2003 19:24 Please respond to "ietf-calendar@imc.org" To: "ietf-calendar@imc.org" cc: Subject: Push of CAP to ietf I am sending the 17-FEB-2003 version + some changes to the IETF list tonight. I know there are some issues still, but by sending it to the IETF it can be discussed in S.F. I'll post a URL to the diffs. - -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Sun Mar 2 22:34:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25172 for ; Sun, 2 Mar 2003 22:34:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h233RAX29596 for ietf-calendar-bks; Sun, 2 Mar 2003 19:27:10 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h233R9Y29592 for ; Sun, 2 Mar 2003 19:27:09 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 31CED4F31 for ; Sun, 2 Mar 2003 22:26:47 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Sun, 2 Mar 2003 22:14:28 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> <200302280850.26773.mark@WebServiceSolutions.com> <20030301120834.GA50051@inet.it> In-Reply-To: <20030301120834.GA50051@inet.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303022214.28101.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On March 1, 2003 07:08 am, Andrea Campi wrote: > On Fri, Feb 28, 2003 at 08:50:26AM -0500, Mark Swanson wrote: > > Perhaps you missed the discussion about this. > > There is a big problem with it: if test1.ics is in utf-8 and test2.ics is > > in latin1 the web server will serve both as latin1. This can not work. > > Uhm... I see no reason why that should be the case. It's an > implementation detail really, but just for an example, CERN-style > meta files have been around for like 10 years; if using Apache you My web server doesn't support CERN-style meta files. > can also use mod_asis, even though it's not optimal. Or even if mod_asis is not supported by my web browser, and even though I agree it would serve the purpose of providing the MIME headers I still do not like the fact that requiring MIME breaks the fundamental encapsulation of iCalendar. > using static files you could pass all requests through a script > which determines the appropriate charset via your preferred > mechanism, and adds it to the MIME headers. You could, but imposing that as a restriction to using iCalendar is not reasonable. Again, the fundamental objection is: 2445 should work equally well outside of a MIME environment. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Sun Mar 2 22:48:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25406 for ; Sun, 2 Mar 2003 22:48:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h233bw500598 for ietf-calendar-bks; Sun, 2 Mar 2003 19:37:58 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h233bvY00594 for ; Sun, 2 Mar 2003 19:37:57 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 1A2614F31 for ; Sun, 2 Mar 2003 22:37:35 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Re: The charset issue Date: Sun, 2 Mar 2003 22:25:14 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> <200302280917.04804.mark@WebServiceSolutions.com> <20030301122030.GB50051@inet.it> In-Reply-To: <20030301122030.GB50051@inet.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303022225.14645.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On March 1, 2003 07:20 am, Andrea Campi wrote: > On Fri, Feb 28, 2003 at 09:17:04AM -0500, Mark Swanson wrote: > > On February 28, 2003 06:23 am, Andrea Campi wrote: > > > Since the discussion has reached (IMO) a dead end, I'll voice my > > > opinion. I am 1000% of Doug's opinion. Mark, you are presenting a > > > non-compliant implementation as reason for changing RFC2445. Like it or > > > not, an http > > > > No Andrea. This is not why I am doing this at all. > > Perhaps a summary of reasons will help: > > > > 1. MIME is not the universe (to steal a phrase from John Stacke :-). 2445 > > states iCalendar objects are to work fine outside the MIME environment. > > To quote from 2445, "the format in this memo is equally applicable for > > use outside of a MIME message content type.". > > This is exactly the reason why I think no change is necessary. If > you are in a MIME environment, use MIME. If you are not, you MUST > use UTF-8. I think this is quite reasonable in fact. I mostly quite like that. Unfortunately 2445 does not agree with us. Instead of a CHARSET property would you agree to rewording 2445 so UTF-8 MUST be used if not in a MIME environment? > > There are the obvious examples of using an iCalendar object outside the > > MIME environment: http/ftp/custom protocols - even copying the iCalendar > > object as presented by Outlook (in text format, which does not show the > > MIME headers as part of the iCalendar object) to the clipboard. John > > Strake has stated that no MIME implementations (MUA or HTTP) include the > > MIME headers when it saves a MIME body-part. > > You see - implementation errors. ;-) Even for clipboards, you do > have a choice - you can trancode to UTF-8 before sending the data > to the clipboard, i.e. before throwing away the charset information. Oh? You are going to expect all past and future software to do this? Notepad.exe for example? > I agree with you that it would be nice to be universally compatible; > however, I don't think that should be done by compromising on the > present clean specification - expecially since I still haven't seen > a single example where implementations could not do The Right Thing (TM) > within the standard. The examples are endless: FTP for example, notepad editing a 2445 document and pasting to clipboard for another. Perhaps more importantly the possibilities are endless because not all environments are MIME environments. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Sun Mar 2 23:05:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25756 for ; Sun, 2 Mar 2003 23:05:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h233wiG01099 for ietf-calendar-bks; Sun, 2 Mar 2003 19:58:44 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h233wgY01094 for ; Sun, 2 Mar 2003 19:58:42 -0800 (PST) To: ietf-calendar@imc.org Subject: IETF San Francisco - who's going? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Sun, 2 Mar 2003 22:58:46 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/02/2003 10:58:47 PM, Serialize complete at 03/02/2003 10:58:47 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a quick note to get a count of who will be at the IETF meeting in San Francisco. If you are going and plan on being at the CalSch session, let us know. Also, we will do our traditional Monday night dinner and meet in the lobby of the hotel around 6:30 pm. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 From owner-ietf-calendar@mail.imc.org Mon Mar 3 13:10:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05798 for ; Mon, 3 Mar 2003 13:10:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23Hueu07616 for ietf-calendar-bks; Mon, 3 Mar 2003 09:56:40 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23HucX07612 for ; Mon, 3 Mar 2003 09:56:38 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h23HuZb2016660 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 3 Mar 2003 09:56:38 -0800 Message-ID: <3E63974E.5050904@Royer.com> Date: Mon, 03 Mar 2003 10:56:30 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302280917.04804.mark@WebServiceSolutions.com> <20030301122030.GB50051@inet.it> <200303022225.14645.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050909000607040607050808" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050909000607040607050808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > > I mostly quite like that. > Unfortunately 2445 does not agree with us. > Instead of a CHARSET property would you agree to rewording 2445 so UTF-8 MUST > be used if not in a MIME environment? That is not going to happen ether as several asian countries charsets are more efficient then UTF-8 for them. We did not pick UTF-8 and the wording in 2445 at random. It was discussed over a few years and agreed upon. Changing 2445 in an incompatible way is just not going to happen. If we changed it to a MUST it would make currently compliant applications non compliant. Do you think they are just going to ignore that issue? >> >> ... > Oh? You are going to expect all past and future software to do this? > Notepad.exe for example? It is *not* the job of an interoperability protocol to be view-ready. It is the job of an interoperability protocol to be interoperable with multiple venders across multiple countries. Your OS tool specific example is not relevant. The point made was that you can write code to do copy/paste, do it or not but do not expect every vendor to agree that they have to change. >>I agree with you that it would be nice to be universally compatible; >>however, I don't think that should be done by compromising on the >>present clean specification - expecially since I still haven't seen >>a single example where implementations could not do The Right Thing (TM) >>within the standard. > > > The examples are endless: FTP for example, notepad editing a 2445 document and > pasting to clipboard for another. Perhaps more importantly the possibilities > are endless because not all environments are MIME environments. Your point is not relevant to iCalendar as FTP and Notepad.exe were never designed to be iCalendar aware as was an endless list of other unrelated software. Just because you do not want to write code to translate charset does not mean the rest of the iCalendar compliant vendors should break their code to make you happy. If you have suggestions that can extend or make it more useful, great. But making a new version of 2445 break or make non compliant existing implementations is not going to happen. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050909000607040607050808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDMxNzU2MzBaMCMGCSqGSIb3DQEJBDEWBBQQ qf9+fi2zZ2iTgPXn8aghM2zszjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAIWRj6O7K+5kc X3/8UeEDDePe7JPSluta3wHjtd0VGAMlfvMEWZ2S62KluHD/DYjgAVMjkOzZj0U4oauW/N7q OFDvxoVIYsAThhwVld7H6OOFFLZopX3V9etlGBnuPU+Imdw9ZdwDChCcVXH4bkzMwYKBTJPx REqmhPzXWbdlOAuOjb8sILAI3CmlSH/7Qx6UbrCOnFMJydGLXEMPgIVLDMu45d8Kj0pdiaix Ar25fdh6bthzpvxql/6KcRONeWCf8NVAHvbmZDIzbyuCBHl7luQqo+ljiAF3P7eIXco/GoPz zkPGcIpGIVXRFQaDB87XcqS+g2Bktz1kVQlVqMZ+lQAAAAAAAA== --------------ms050909000607040607050808-- From owner-ietf-calendar@mail.imc.org Mon Mar 3 14:28:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08896 for ; Mon, 3 Mar 2003 14:28:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23JGjL11883 for ietf-calendar-bks; Mon, 3 Mar 2003 11:16:45 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23JGhX11875 for ; Mon, 3 Mar 2003 11:16:44 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id F13DB4F32 for ; Mon, 3 Mar 2003 14:16:19 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Mon, 3 Mar 2003 14:01:35 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> <200303022225.14645.mark@WebServiceSolutions.com> <3E63974E.5050904@Royer.com> In-Reply-To: <3E63974E.5050904@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303031401.35138.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On March 3, 2003 12:56 pm, Doug Royer wrote: > Mark Swanson wrote: > > I mostly quite like that. > > Unfortunately 2445 does not agree with us. > > Instead of a CHARSET property would you agree to rewording 2445 so UTF-8 > > MUST be used if not in a MIME environment? > > That is not going to happen ether as several asian countries charsets > are more efficient then UTF-8 for them. We did not pick UTF-8 and the > wording in 2445 at random. It was discussed over a few years and agreed > upon. Changing 2445 in an incompatible way is just not going to happen. > If we changed it to a MUST it would make currently compliant applications > non compliant. Do you think they are just going to ignore that issue? Others have pointed this out to me too. I agree we can't force UTF-8. > >> ... > > > > Oh? You are going to expect all past and future software to do this? > > Notepad.exe for example? > > It is *not* the job of an interoperability protocol to be view-ready. > It is the job of an interoperability protocol to be interoperable > with multiple venders across multiple countries. Your OS tool specific > example is not relevant. The point made was that you can write > code to do copy/paste, do it or not but do not expect every > vendor to agree that they have to change. My opinion is that 2445 should encapsulate charset so we can work outside the MIME environment, as mandated by the spec. > >>I agree with you that it would be nice to be universally compatible; > >>however, I don't think that should be done by compromising on the > >>present clean specification - expecially since I still haven't seen > >>a single example where implementations could not do The Right Thing (TM) > >>within the standard. > > > > The examples are endless: FTP for example, notepad editing a 2445 > > document and pasting to clipboard for another. Perhaps more importantly > > the possibilities are endless because not all environments are MIME > > environments. > > Your point is not relevant to iCalendar as FTP and Notepad.exe were never > designed to be iCalendar aware as was an endless list of other unrelated > software. It is relevant because iCalendar states that it should work outside of a MIME environment. > Just because you do not want to write code to translate charset does > not mean the rest of the iCalendar compliant vendors should break > their code to make you happy. It is wrong of you to make this personal. It is wrong of you to publicly state that I want or do not want to do something when you have absolutely no idea what my reasons or intentions are. Peace... > If you have suggestions that can extend or make it more useful, great. > But making a new version of 2445 break or make non compliant existing > implementations is not going to happen. Perhaps it is me. Perhaps I just do not understand one single sentence in 2445: "However, the format in this memo is equally applicable for use outside of a MIME message content type." Because of this, I maintain the spec is broken because the format will not work without a CHARSET property. All arguments seem to be based around, "use MIME". But this is in conflict with the sentence above. I see multiple organizations taking advantage of this to break interoperability in various ways (from calendar clients and servers to cell phones) and I feel it is only going to get worse. There has not been a single better proposal than the CHARSET property for fixing the above statement. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Mar 3 14:43:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09503 for ; Mon, 3 Mar 2003 14:43:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23JWXq13064 for ietf-calendar-bks; Mon, 3 Mar 2003 11:32:33 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23JWWX13057 for ; Mon, 3 Mar 2003 11:32:32 -0800 (PST) To: "ietf-calendar@imc.org" Subject: re: Charset MIME-Version: 1.0 X-Mailer: Lotus Notes Build V601_01232003 January 23, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 3 Mar 2003 14:32:20 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/03/2003 02:32:21 PM, Serialize complete at 03/03/2003 02:32:21 PM Content-Type: multipart/alternative; boundary="=_alternative 006B355985256CDE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B355985256CDE_= Content-Type: text/plain; charset="US-ASCII" I agree with Mark Swanson, we should add the CHARSET property. I had to modify Notes code to allow the recipient to try different charsets on attached iCalendar objects. The reason was that some phones in Japan can generate iCalendar. However they are being generated in SHIFT-JIS. They are sent as attachments to email. As a consequence to this problem Notes/Domino 6.0 always inserts an X-LOTUS-CHARSET as just below the BEGIN: VCALENDAR. Thus, if it was generated as an attachment by Notes (i.e sending some sort of combined event such as conference), I absolutely know the charset. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com --=_alternative 006B355985256CDE_= Content-Type: text/html; charset="US-ASCII"
I agree with Mark Swanson, we should add the CHARSET property.  I had to modify Notes code to allow  the recipient to try different charsets on attached iCalendar objects.  The reason was that some phones in Japan can generate iCalendar.  However they are being generated in SHIFT-JIS.  They are sent as attachments to email.  As a consequence to this problem Notes/Domino 6.0 always inserts an X-LOTUS-CHARSET <inana-charset> as just below the BEGIN: VCALENDAR.  Thus, if it was generated as an attachment by Notes (i.e sending some sort of combined event such as conference), I absolutely know the charset.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com --=_alternative 006B355985256CDE_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 3 15:13:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11214 for ; Mon, 3 Mar 2003 15:13:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23K15416502 for ietf-calendar-bks; Mon, 3 Mar 2003 12:01:05 -0800 (PST) Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23K14X16494 for ; Mon, 3 Mar 2003 12:01:04 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp5.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h23K15RI022934; Mon, 3 Mar 2003 15:01:05 -0500 Date: Mon, 3 Mar 2003 15:01:05 -0500 Message-Id: <200303032001.h23K15RI022934@smtp5.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: ietf-calendar@imc.org Subject: simple question about parsing User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not clear on where folding whitespace is allowed. My strict reading of it leads me to believe that B E G IN: VCAL ENDAR END:VCALENDAR should be parsed the same as BEGIN:VCALENDAR END:VCALENDAR I also don't see any minimum required sizes. Do I have to parse lines up to 8k long? Longer? Are there any length limits on names or at least minimums I might be required to preserve? thanks, Larry From owner-ietf-calendar@mail.imc.org Mon Mar 3 15:19:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11494 for ; Mon, 3 Mar 2003 15:19:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23KAT916778 for ietf-calendar-bks; Mon, 3 Mar 2003 12:10:29 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23KARX16767 for ; Mon, 3 Mar 2003 12:10:28 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h23KAPb2017588 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 3 Mar 2003 12:10:28 -0800 Message-ID: <3E63B6AB.8040504@Royer.com> Date: Mon, 03 Mar 2003 13:10:19 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060606030607020503080003" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060606030607020503080003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit What is the MIME header for the attachment? What is the Content-Type header in the E-mail? - Robert_Ransdell@notesdev.ibm.com wrote: > > I agree with Mark Swanson, we should add the CHARSET property. I had to > modify Notes code to allow the recipient to try different charsets on > attached iCalendar objects. The reason was that some phones in Japan > can generate iCalendar. However they are being generated in SHIFT-JIS. > They are sent as attachments to email. As a consequence to this > problem Notes/Domino 6.0 always inserts an X-LOTUS-CHARSET > as just below the BEGIN: VCALENDAR. Thus, if it was > generated as an attachment by Notes (i.e sending some sort of combined > event such as conference), I absolutely know the charset. > _____________________ > Note: new email address > > tom_ransdell@notesdev.ibm.com -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060606030607020503080003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDMyMDEwMTlaMCMGCSqGSIb3DQEJBDEWBBRh raDOyk4uTt/Cg/BfN50069DTDjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEASpMZLqIOKnH0 Pdj48E3Z1IxFg+JH0V5jS5JIgAAeGsPIn0Q0qQ6hT4M10lsCMn4p0xa6rEwh7NTe0m9GGO/D bggCVfWGQHuYHnJ7AxYD5ldYarT89oGgTdmGBDWvN9d8HTfSi04+z/fPkWZI6FniIyRS74pV JC3+TU+aHaxuG5VDDkNZOKraJ2uNvYIhgw4wc/Nx8AiC/10ZxNWGG3chdvf8sDy2MIPswVcg 9qyctlyD6BXdgnyLq0rKCr2/Qh/znbXpa6II1R51x0iCNXA8BvxfMDj+LbnWC8hpIL/D+reA KVQgSY/yQq29aBWUqNwojfPj9Ni2wczSNXHL33rTGAAAAAAAAA== --------------ms060606030607020503080003-- From owner-ietf-calendar@mail.imc.org Mon Mar 3 15:22:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11577 for ; Mon, 3 Mar 2003 15:22:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23KGWK17042 for ietf-calendar-bks; Mon, 3 Mar 2003 12:16:32 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23KGVX17038 for ; Mon, 3 Mar 2003 12:16:31 -0800 (PST) In-Reply-To: <3E63B6AB.8040504@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Charset MIME-Version: 1.0 X-Mailer: Lotus Notes Build V601_01232003 January 23, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 3 Mar 2003 15:16:32 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/03/2003 03:16:18 PM, Serialize complete at 03/03/2003 03:16:18 PM Content-Type: multipart/alternative; boundary="=_alternative 006F412B85256CDE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F412B85256CDE_= Content-Type: text/plain; charset="US-ASCII" Does not matter since I have to look at attachment after it was de-attached. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 03/03/2003 03:10 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: Charset What is the MIME header for the attachment? What is the Content-Type header in the E-mail? - Robert_Ransdell@notesdev.ibm.com wrote: > > I agree with Mark Swanson, we should add the CHARSET property. I had to > modify Notes code to allow the recipient to try different charsets on > attached iCalendar objects. The reason was that some phones in Japan > can generate iCalendar. However they are being generated in SHIFT-JIS. > They are sent as attachments to email. As a consequence to this > problem Notes/Domino 6.0 always inserts an X-LOTUS-CHARSET > as just below the BEGIN: VCALENDAR. Thus, if it was > generated as an attachment by Notes (i.e sending some sort of combined > event such as conference), I absolutely know the charset. > _____________________ > Note: new email address > > tom_ransdell@notesdev.ibm.com -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 006F412B85256CDE_= Content-Type: text/html; charset="US-ASCII"
Does not matter since I have to look at attachment after it was de-attached.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


Doug Royer <Doug@royer.com>
Sent by: owner-ietf-calendar@mail.imc.org

03/03/2003 03:10 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: Charset






What is the MIME header for the attachment? What is the Content-Type
header in the E-mail?

-

Robert_Ransdell@notesdev.ibm.com wrote:
>
> I agree with Mark Swanson, we should add the CHARSET property.  I had to
> modify Notes code to allow  the recipient to try different charsets on
> attached iCalendar objects.  The reason was that some phones in Japan
> can generate iCalendar.  However they are being generated in SHIFT-JIS.
>  They are sent as attachments to email.  As a consequence to this
> problem Notes/Domino 6.0 always inserts an X-LOTUS-CHARSET
> <inana-charset> as just below the BEGIN: VCALENDAR.  Thus, if it was
> generated as an attachment by Notes (i.e sending some sort of combined
> event such as conference), I absolutely know the charset.
> _____________________
> Note: new email address
>
> tom_ransdell@notesdev.ibm.com


--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.com                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards
--=_alternative 006F412B85256CDE_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 3 16:07:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12963 for ; Mon, 3 Mar 2003 16:07:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23KvHO18166 for ietf-calendar-bks; Mon, 3 Mar 2003 12:57:17 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23KvGX18162 for ; Mon, 3 Mar 2003 12:57:16 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h23KvCb2017874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 3 Mar 2003 12:57:17 -0800 Message-ID: <3E63C1A2.3010408@Royer.com> Date: Mon, 03 Mar 2003 13:57:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040408070605010206040603" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040408070605010206040603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Does not matter since I have to look at attachment after it was > de-attached. Then that is the real problem not the fact that the object does not have its original charset inside the object. You seem to be talking about how you store the object in your application. If you are electing to save it in its original charset then that is fine. If you charset it to UTF-8, then you would not need it. What do you do when you get a charset that you can not read without first knowing the charset - after ripping off the MIME header? It looks to me as if MIME and iCalendar is working as documented. Otherwise you would not know that it was SHIFT-JIS. And that is what iCalendar + iMIP is about - it is already 100% portable - correct? So despite the fact that you want to add CHARSET to the object, your telling me that as an interoperability protocol - you did not need it. How you store object internally (which is what I seem to think you are saying) is out of scope for this working group. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040408070605010206040603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDMyMDU3MDdaMCMGCSqGSIb3DQEJBDEWBBSq Q+MTJ73Yi9zbXvG4CHn9oGtcajBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAHaLx0wvvHJ5y FuKvPo3YJevBaQU/ryvLIsbYLr2jB3v2bYggfvIE7LEEpn1UBIER/qikL2eFEzFMTYsRCKf3 B59WGcQ5IyYpJ4qasRhSgBp42RhAIdx14IbovPNS/nKaJGD3Z8uu9hiF8PeQiZEHoJgRj00X TlnKBP+xQkeRlb9XTeqJypyDwupRuKyL5X7yC9Z8ps6RlJWXwBIxjSDA40DWJBw7Ec7SMw3y M4kjWoJRHBIJ5blk7JDrUv6ZsEx1/lZqIqTfdYhT6LoFeI+A5iJ9mWVV1C8DXQLVC14HlLhh eTV3B/cnhVcMvpA17+MzSTyhszhjPRau+D4fjACBcQAAAAAAAA== --------------ms040408070605010206040603-- From owner-ietf-calendar@mail.imc.org Mon Mar 3 16:25:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13429 for ; Mon, 3 Mar 2003 16:25:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23LGOK18784 for ietf-calendar-bks; Mon, 3 Mar 2003 13:16:24 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23LGNX18780 for ; Mon, 3 Mar 2003 13:16:23 -0800 (PST) In-Reply-To: <3E63C1A2.3010408@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Charset MIME-Version: 1.0 X-Mailer: Lotus Notes Build V601_01232003 January 23, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Mon, 3 Mar 2003 16:16:23 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/03/2003 04:16:25 PM, Serialize complete at 03/03/2003 04:16:25 PM Content-Type: multipart/alternative; boundary="=_alternative 0074BC1B85256CDE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0074BC1B85256CDE_= Content-Type: text/plain; charset="US-ASCII" When you try to OPEN an attachment, you must pass attachment to registered handler for the attachment. So attachment is extracted and handed off. It is no longer in MIME envelope. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 03/03/2003 03:57 PM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: Charset Robert_Ransdell@notesdev.ibm.com wrote: > > Does not matter since I have to look at attachment after it was > de-attached. Then that is the real problem not the fact that the object does not have its original charset inside the object. You seem to be talking about how you store the object in your application. If you are electing to save it in its original charset then that is fine. If you charset it to UTF-8, then you would not need it. What do you do when you get a charset that you can not read without first knowing the charset - after ripping off the MIME header? It looks to me as if MIME and iCalendar is working as documented. Otherwise you would not know that it was SHIFT-JIS. And that is what iCalendar + iMIP is about - it is already 100% portable - correct? So despite the fact that you want to add CHARSET to the object, your telling me that as an interoperability protocol - you did not need it. How you store object internally (which is what I seem to think you are saying) is out of scope for this working group. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 0074BC1B85256CDE_= Content-Type: text/html; charset="US-ASCII"
When you try to OPEN an attachment, you must pass attachment to registered handler for the attachment.  So attachment is extracted and handed off.  It is no longer in MIME envelope.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


Doug Royer <Doug@royer.com>
Sent by: owner-ietf-calendar@mail.imc.org

03/03/2003 03:57 PM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: Charset







Robert_Ransdell@notesdev.ibm.com wrote:
>
> Does not matter since I have to look at attachment after it was
> de-attached.

Then that is the real problem not the fact that the object
does not have its original charset inside the object. You seem
to be talking about how you store the object in your application.

If you are electing to save it in its original charset then that
is fine. If you charset it to UTF-8, then you would not need it.

What do you do when you get a charset that you can not read without first
knowing the charset - after ripping off the MIME header?

It looks to me as if MIME and iCalendar is working as documented.
Otherwise you would not know that it was SHIFT-JIS. And that
is what iCalendar + iMIP is about - it is already 100% portable - correct?

So despite the fact that you want to add CHARSET to the object,
your telling me that as an interoperability protocol - you did
not need it. How you store object internally (which is what I seem
to think you are saying) is out of scope for this working group.



--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.com                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards
--=_alternative 0074BC1B85256CDE_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 3 16:34:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13673 for ; Mon, 3 Mar 2003 16:34:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23LQ3P19031 for ietf-calendar-bks; Mon, 3 Mar 2003 13:26:03 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23LQ2X19027 for ; Mon, 3 Mar 2003 13:26:02 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 527528D7B9; Mon, 3 Mar 2003 13:26:04 -0800 (PST) From: "Chris Olds" To: Lawrence Greenfield , ietf-calendar@imc.org Subject: Re: simple question about parsing Date: Mon, 3 Mar 2003 13:26:04 -0800 Message-Id: <20030303212604.M34942@asitturnsout.org> In-Reply-To: <200303032001.h23K15RI022934@smtp5.andrew.cmu.edu> References: <200303032001.h23K15RI022934@smtp5.andrew.cmu.edu> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.50 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I was going to disagree, but I reread 2445, and I think your interpretation is correct. I know that there are applications (e.g., MS Outlook) that treat the sequence '\n ' as if it were a single space, but the example (sec 4.1, p 13) makes it clear that '\n ' or '\n\t' should be removed as part of the folding process. I'm not sure what you're asking about wrt length limits on names (what kind of names?), but as far as I can see, an iCanendar object can, in theory, be arbitrarily large. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Mar 3 16:36:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13759 for ; Mon, 3 Mar 2003 16:36:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23LTvI19111 for ietf-calendar-bks; Mon, 3 Mar 2003 13:29:57 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23LTuX19107 for ; Mon, 3 Mar 2003 13:29:56 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h23LTupZ003764; Mon, 3 Mar 2003 16:29:56 -0500 Date: Mon, 3 Mar 2003 16:29:56 -0500 Message-Id: <200303032129.h23LTupZ003764@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: ietf-calendar@imc.org, Chris Olds In-reply-to: <20030303212604.M34942@asitturnsout.org> Subject: Re: simple question about parsing References: <200303032001.h23K15RI022934@smtp5.andrew.cmu.edu> <20030303212604.M34942@asitturnsout.org> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: "Chris Olds" Date: Mon, 3 Mar 2003 13:26:04 -0800 I was going to disagree, but I reread 2445, and I think your interpretation is correct. I know that there are applications (e.g., MS Outlook) that treat the sequence '\n ' as if it were a single space, but the example (sec 4.1, p 13) makes it clear that '\n ' or '\n\t' should be removed as part of the folding process. I'm not sure what you're asking about wrt length limits on names (what kind of names?), but as far as I can see, an iCanendar object can, in theory, be arbitrarily large. In order to guarantee interoperability, many specs would say something like: 'A "name" can be any size. Implementations MUST handle names at least 1024 octets long.' This way implementations can protect against denial-of-service attacks but there's a guaranteed size that will interoperate. Larry From owner-ietf-calendar@mail.imc.org Mon Mar 3 17:43:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15886 for ; Mon, 3 Mar 2003 17:43:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23MVZ622087 for ietf-calendar-bks; Mon, 3 Mar 2003 14:31:35 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23MVXX22079 for ; Mon, 3 Mar 2003 14:31:33 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h23MVOb2018534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 3 Mar 2003 14:31:34 -0800 Message-ID: <3E63D7B5.6050709@Royer.com> Date: Mon, 03 Mar 2003 15:31:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020505000006040802000106" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020505000006040802000106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > When you try to OPEN an attachment, you must pass attachment to > registered handler for the attachment. So attachment is extracted and > handed off. It is no longer in MIME envelope. That is what your implementation does. It is not because of iCalendar. Besides even if you are using some kind of library or tool on your OS, I can't believe that the MIME data is unavilable, if it were you would also loose encoding and other information. Its your CUA, and if not then intercept the MIME data prior to being sent to the MUA and send it to your CUA. Adding CHARSET to iCalendar objects will only make it work some times for some implementations and only when they try and guess the charset. Not a portable solution. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020505000006040802000106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDMyMjMxMThaMCMGCSqGSIb3DQEJBDEWBBRU D/GS0aY/GS1cX1410Sh7Tbf5AjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAH7ao1Uxj7qE+ HHYzqMx7INa8zWqlDo13iFGThUYcgRt+yhyG2j6lnQ3n6cM3ItPVRfLdG/MaE4JZiSOEV2SA mmglceEubXHmG08b7EhDXbXB7MXHiSMogAfZWWKlC1tLIqIe5O+Uoks6C3/xQh4ny87B0S+A x4thzX6BCFWmVa/BUCvSOPMjbSFtece0jlYAYf7ZiSA3qxGz9HAYVkfUCscEZS+pGjSrHzHO IdWWdESlhdm4wRyRFr3sroqHxapnuzCnBqdoBO1xMVuNiVxMGrXAkIlN8EjRmoLpeSJvikxR Oty6XWDjw1UWYjju3cgR/CqtzKXnxmWXgnFJY/EzJgAAAAAAAA== --------------ms020505000006040802000106-- From owner-ietf-calendar@mail.imc.org Mon Mar 3 17:43:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15901 for ; Mon, 3 Mar 2003 17:43:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23MZaX22662 for ietf-calendar-bks; Mon, 3 Mar 2003 14:35:36 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23MZZX22654 for ; Mon, 3 Mar 2003 14:35:35 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h23MZVb2018560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 3 Mar 2003 14:35:36 -0800 Message-ID: <3E63D8AD.3040503@Royer.com> Date: Mon, 03 Mar 2003 15:35:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: simple question about parsing References: <200303032001.h23K15RI022934@smtp5.andrew.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030701020206030801090902" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030701020206030801090902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: > I'm not clear on where folding whitespace is allowed. > > My strict reading of it leads me to believe that > > B > E > G > IN: > VCAL > ENDAR > END:VCALENDAR Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. Long content lines SHOULD be split into a multiple line representations using a line "folding" technique. That is, a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white space character (i.e., SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence of CRLF followed immediately by a single linear white space character is ignored (i.e., removed) when processing the content type. Yes - however it is typical to break at the normal CRLF. > should be parsed the same as > > BEGIN:VCALENDAR > END:VCALENDAR > > I also don't see any minimum required sizes. Do I have to parse lines > up to 8k long? You don't have to :-) However your might get one. > Longer? Same as above > Are there any length limits on names or at > least minimums I might be required to preserve? As long as it is syntactically correct it makes no difference. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030701020206030801090902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDMyMjM1MjVaMCMGCSqGSIb3DQEJBDEWBBTL QrGlAENI61BeN3ZW0aB/Ss3NbTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAKNM+WZDUmYeg r24KaPru1T2vv1aotWg6WA8ZPKHXhK4BRkcN7rUckeWsORHiyiNZSgCJnLunadWSbMFzHDnv 4VX7FKY/yzCNdJa92FoLb75yVY1a0SIAm973Jw9DxHfCvgq/sbDlVUrbPVhkrHYW0oOVKBBL YNp41reDk4oopM4JY237dmavv1IbM34BH/sa5Lb6U6+W5GV/3PHquZoT5iWv2+poT9uzqB45 Zkmt6XhUWGoWC5YrwLLdUV7rVrBWleqtpoadobnUc6C7P9w9MuiZQeDnI8NGSsUyFe0FJ7mP FiNiWwL3ELeXLuOKLq1ZPba5XZ1Wy0ZN7CnfJbwv9gAAAAAAAA== --------------ms030701020206030801090902-- From owner-ietf-calendar@mail.imc.org Mon Mar 3 18:13:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17556 for ; Mon, 3 Mar 2003 18:13:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23N2kp23911 for ietf-calendar-bks; Mon, 3 Mar 2003 15:02:46 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23N2iX23907 for ; Mon, 3 Mar 2003 15:02:44 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h23N2j6s002819; Mon, 3 Mar 2003 18:02:45 -0500 Date: Mon, 3 Mar 2003 18:02:45 -0500 Message-Id: <200303032302.h23N2j6s002819@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" In-reply-to: <3E63D8AD.3040503@Royer.com> Subject: Re: simple question about parsing References: <200303032001.h23K15RI022934@smtp5.andrew.cmu.edu> <3E63D8AD.3040503@Royer.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Mon, 03 Mar 2003 15:35:25 -0700 From: Doug Royer [...] > I also don't see any minimum required sizes. Do I have to parse lines > up to 8k long? You don't have to :-) However your might get one. I don't _have_ to do anything. However, my goal is to create interoperable software. [...] > Are there any length limits on names or at > least minimums I might be required to preserve? As long as it is syntactically correct it makes no difference. This is easy for things I generate. If I am writing a calendar store, I might try to store arbitrary objects generated by other implementations. Larry From owner-ietf-calendar@mail.imc.org Tue Mar 4 05:06:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11059 for ; Tue, 4 Mar 2003 05:06:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h249rgO03775 for ietf-calendar-bks; Tue, 4 Mar 2003 01:53:42 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h249rfX03767 for ; Tue, 4 Mar 2003 01:53:41 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 52D9E155C6; Tue, 4 Mar 2003 10:53:35 +0100 (CET) Date: Tue, 4 Mar 2003 10:53:35 +0100 From: Andrea Campi To: Mark Swanson Cc: "ietf-calendar@imc.org" Subject: Re: The charset issue Message-ID: <20030304095335.GE58688@inet.it> References: <3E5E49A6.2030102@Royer.com> <200303022225.14645.mark@WebServiceSolutions.com> <3E63974E.5050904@Royer.com> <200303031401.35138.mark@WebServiceSolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303031401.35138.mark@WebServiceSolutions.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This will be my last post on this thread, sorry my time is short lately. I feel this issue has been beaten to death, and Doug is voicing my opinion as well so I don't have much to add. Just a summary: On Mon, Mar 03, 2003 at 02:01:35PM -0500, Mark Swanson wrote: > > If you have suggestions that can extend or make it more useful, great. > > But making a new version of 2445 break or make non compliant existing > > implementations is not going to happen. > > Perhaps it is me. Perhaps I just do not understand one single sentence in > 2445: > > "However, the format in this memo is equally applicable > for use outside of a MIME message content type." > > Because of this, I maintain the spec is broken because the format will not > work without a CHARSET property. > > All arguments seem to be based around, "use MIME". But this is in conflict > with the sentence above. The format in the memo is perfectly applicable without MIME. However, the fact that your application works without MIME doesn't allow you to disregard charset issues; rather, it puts the burden on you to make sure you know how to interpret iCalendar data properly. This I think is the spirit of the above sentence, and thus the spec is doing its duty. You've been repeatedly citing the example of passing iCalendar data around with tools which are unaware of MIME. That's fine, you can either convert the data to UTF-8 or pass around external metadata. For instance, if a MUA saves a part from a MIME message and then calls an helper application to read it, it can either convert from the original charset to UTF-8, or it can pass the charset as a command line argument (for instance). > I see multiple organizations taking advantage of this to break > interoperability in various ways (from calendar clients and servers to cell > phones) and I feel it is only going to get worse. What makes you feel those organizations will update their applications to this new iteration of the spec you are proposing? > There has not been a single better proposal than the CHARSET property for > fixing the above statement. Sorry, I don't want to sound blunt, but since you're raising the issue and advocating a change, the onus is on you to bring evidence for the change, not the other way around. So far the hasn't been a single example of something which is not working because of a flaw in the spec instead of a vendor mistake. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - 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 Mar 4 10:03:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25307 for ; Tue, 4 Mar 2003 10:03:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24En6M21878 for ietf-calendar-bks; Tue, 4 Mar 2003 06:49:06 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24En5X21874 for ; Tue, 4 Mar 2003 06:49:05 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030409523109453 for ; Tue, 04 Mar 2003 09:52:31 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 09:46:46 -0500 Message-ID: <3E64BC55.8090509@centive.com> Date: Tue, 04 Mar 2003 09:46:45 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 14:46:46.0043 (UTC) FILETIME=[E10D9EB0:01C2E25C] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Robert_Ransdell@notesdev.ibm.com wrote: > >> When you try to OPEN an attachment, you must pass attachment to >> registered handler for the attachment. So attachment is extracted >> and handed off. It is no longer in MIME envelope. > > That is what your implementation does. That is what EVERY implementation does! Doug, you're resisting changing iCalendar because of the deployed base of CUAs; but what about the much larger deployed base of MUAs? If we want to be able to use iMIP, we cannot require that MUAs be modified to transport iCalendar safely. -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |He wondered if Elli was going to buy that explanation. His taste| |for heavily-armed girlfriends did have its drawbacks. | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 4 10:05:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25573 for ; Tue, 4 Mar 2003 10:05:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24En3l21873 for ietf-calendar-bks; Tue, 4 Mar 2003 06:49:03 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24En1X21869 for ; Tue, 4 Mar 2003 06:49:02 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030409523505299 for ; Tue, 04 Mar 2003 09:52:35 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 09:46:50 -0500 Message-ID: <3E64BC5A.1030908@centive.com> Date: Tue, 04 Mar 2003 09:46:50 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> <200302280917.04804.mark@WebServiceSolutions.com> <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 14:46:50.0465 (UTC) FILETIME=[E3B05D10:01C2E25C] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: > John Strake has stated that no MIME implementations > (MUA or HTTP) include the MIME headers when it saves a MIME > body-part. > >Of course not. They should save objects in the local charset, doing >conversions if necessary. > What is the local charset? POSIX, for example, specifies that locale settings are stored in environment variables, which means that charsets are per-process, not per-user or per-machine. -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |He wondered if Elli was going to buy that explanation. His taste| |for heavily-armed girlfriends did have its drawbacks. | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 4 10:37:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27411 for ; Tue, 4 Mar 2003 10:37:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24FOqp23529 for ietf-calendar-bks; Tue, 4 Mar 2003 07:24:52 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24FOpX23522 for ; Tue, 4 Mar 2003 07:24:51 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h24FOl6s003409; Tue, 4 Mar 2003 10:24:47 -0500 Date: Tue, 4 Mar 2003 10:24:47 -0500 Message-Id: <200303041524.h24FOl6s003409@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" , John Stracke In-reply-to: <3E64BC55.8090509@centive.com> Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Tue, 04 Mar 2003 09:46:45 -0500 From: John Stracke [...] Doug, you're resisting changing iCalendar because of the deployed base of CUAs; but what about the much larger deployed base of MUAs? If we want to be able to use iMIP, we cannot require that MUAs be modified to transport iCalendar safely. Having redundant and potentially conflicting character set tagging is harmful, too. Once the character set also exists inside the MIME object, all tools that might try to do a character set transcoding must be aware of the iCalendar format. If you want to go ahead with iCalendar having its own character set tagging system, you should choose a MIME type other than text/calendar so that processing systems do not default it to text/plain. Larry From owner-ietf-calendar@mail.imc.org Tue Mar 4 10:55:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28174 for ; Tue, 4 Mar 2003 10:55:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24Fgqv25021 for ietf-calendar-bks; Tue, 4 Mar 2003 07:42:52 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24FglX25011 for ; Tue, 4 Mar 2003 07:42:47 -0800 (PST) In-Reply-To: <20030304095335.GE58688@inet.it> To: a.campi@inet.it Cc: "ietf-calendar@imc.org" , Mark Swanson , owner-ietf-calendar@mail.imc.org Subject: Re: The charset issue MIME-Version: 1.0 X-Mailer: Lotus Notes Build V601_01232003 January 23, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Tue, 4 Mar 2003 10:42:45 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/04/2003 10:42:51 AM, Serialize complete at 03/04/2003 10:42:51 AM Content-Type: multipart/alternative; boundary="=_alternative 0056309585256CDF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056309585256CDF_= Content-Type: text/plain; charset="US-ASCII" Andre Campi wrote >Sorry, I don't want to sound blunt, but since you're raising the issue >and advocating a change, the onus is on you to bring evidence for the >change, not the other way around. So far the hasn't been a single >example of something which is not working because of a flaw in the >spec instead of a vendor mistake. I have already stated the example where this is happening. Phones in Japan create iCalendars in Shift-JIS and attach them to email messages. Because by standard you are suppose to hand the attachment to the registered handler on an OPEN, the attachment processor no longer has any MIME charset information. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Andrea Campi Sent by: owner-ietf-calendar@mail.imc.org 03/04/2003 04:53 AM To Mark Swanson cc "ietf-calendar@imc.org" Subject Re: The charset issue This will be my last post on this thread, sorry my time is short lately. I feel this issue has been beaten to death, and Doug is voicing my opinion as well so I don't have much to add. Just a summary: On Mon, Mar 03, 2003 at 02:01:35PM -0500, Mark Swanson wrote: > > If you have suggestions that can extend or make it more useful, great. > > But making a new version of 2445 break or make non compliant existing > > implementations is not going to happen. > > Perhaps it is me. Perhaps I just do not understand one single sentence in > 2445: > > "However, the format in this memo is equally applicable > for use outside of a MIME message content type." > > Because of this, I maintain the spec is broken because the format will not > work without a CHARSET property. > > All arguments seem to be based around, "use MIME". But this is in conflict > with the sentence above. The format in the memo is perfectly applicable without MIME. However, the fact that your application works without MIME doesn't allow you to disregard charset issues; rather, it puts the burden on you to make sure you know how to interpret iCalendar data properly. This I think is the spirit of the above sentence, and thus the spec is doing its duty. You've been repeatedly citing the example of passing iCalendar data around with tools which are unaware of MIME. That's fine, you can either convert the data to UTF-8 or pass around external metadata. For instance, if a MUA saves a part from a MIME message and then calls an helper application to read it, it can either convert from the original charset to UTF-8, or it can pass the charset as a command line argument (for instance). > I see multiple organizations taking advantage of this to break > interoperability in various ways (from calendar clients and servers to cell > phones) and I feel it is only going to get worse. What makes you feel those organizations will update their applications to this new iteration of the spec you are proposing? > There has not been a single better proposal than the CHARSET property for > fixing the above statement. Sorry, I don't want to sound blunt, but since you're raising the issue and advocating a change, the onus is on you to bring evidence for the change, not the other way around. So far the hasn't been a single example of something which is not working because of a flaw in the spec instead of a vendor mistake. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy --=_alternative 0056309585256CDF_= Content-Type: text/html; charset="US-ASCII"
Andre Campi  wrote
>Sorry, I don't want to sound blunt, but since you're raising the issue
>and advocating a change, the onus is on you to bring evidence for the
>change, not the other way around. So far the hasn't been a single
>example of something which is not working because of a flaw in the
>spec instead of a vendor mistake.

I have already stated the example where this is happening.
Phones in Japan create iCalendars in Shift-JIS and attach them to email messages.  Because  by standard you are suppose to hand the attachment to the registered handler on an OPEN, the attachment processor no longer has any MIME charset information.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


Andrea Campi <a.campi@inet.it>
Sent by: owner-ietf-calendar@mail.imc.org

03/04/2003 04:53 AM

To
Mark Swanson <mark@WebServiceSolutions.com>
cc
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject
Re: The charset issue






This will be my last post on this thread, sorry my time is short lately.
I feel this issue has been beaten to death, and Doug is voicing my
opinion as well so I don't have much to add. Just a summary:

On Mon, Mar 03, 2003 at 02:01:35PM -0500, Mark Swanson wrote:
> > If you have suggestions that can extend or make it more useful, great.
> > But making a new version of 2445 break or make non compliant existing
> > implementations is not going to happen.
>
> Perhaps it is me. Perhaps I just do not understand one single sentence in
> 2445:
>
> "However, the format in this memo is equally applicable
>    for use outside of a MIME message content type."
>
> Because of this, I maintain the spec is broken because the format will not
> work without a CHARSET property.
>
> All arguments seem to be based around, "use MIME". But this is in conflict
> with the sentence above.

The format in the memo is perfectly applicable without MIME. However,
the fact that your application works without MIME doesn't allow you to
disregard charset issues; rather, it puts the burden on you to make sure
you know how to interpret iCalendar data properly. This I think is the
spirit of the above sentence, and thus the spec is doing its duty.

You've been repeatedly citing the example of passing iCalendar data around
with tools which are unaware of MIME. That's fine, you can either convert
the data to UTF-8 or pass around external metadata. For instance, if a MUA
saves a part from a MIME message and then calls an helper application to
read it, it can either convert from the original charset to UTF-8, or it
can pass the charset as a command line argument (for instance).

> I see multiple organizations taking advantage of this to break
> interoperability in various ways (from calendar clients and servers to cell
> phones) and I feel it is only going to get worse.

What makes you feel those organizations will update their applications to
this new iteration of the spec you are proposing?

> There has not been a single better proposal than the CHARSET property for
> fixing the above statement.

Sorry, I don't want to sound blunt, but since you're raising the issue
and advocating a change, the onus is on you to bring evidence for the
change, not the other way around. So far the hasn't been a single
example of something which is not working because of a flaw in the
spec instead of a vendor mistake.


Bye,
                Andrea

--
Andrea Campi                              mailto:a.campi@inet.it
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D                                                     phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019                                                     fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy
--=_alternative 0056309585256CDF_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 11:24:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29223 for ; Tue, 4 Mar 2003 11:24:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24G8u428571 for ietf-calendar-bks; Tue, 4 Mar 2003 08:08:56 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24G8sX28561 for ; Tue, 4 Mar 2003 08:08:54 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id C95FA155C6; Tue, 4 Mar 2003 17:08:54 +0100 (CET) Date: Tue, 4 Mar 2003 17:08:54 +0100 From: Andrea Campi To: Robert Ransdell/Westford/IBM Cc: "ietf-calendar@imc.org" , Mark Swanson , owner-ietf-calendar@mail.imc.org Subject: Re: The charset issue Message-ID: <20030304160854.GB59255@inet.it> References: <20030304095335.GE58688@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Mar 04, 2003 at 10:42:45AM -0500, Robert Ransdell/Westford/IBM wrote: > Andre Campi wrote > >Sorry, I don't want to sound blunt, but since you're raising the issue > >and advocating a change, the onus is on you to bring evidence for the > >change, not the other way around. So far the hasn't been a single > >example of something which is not working because of a flaw in the > >spec instead of a vendor mistake. > > I have already stated the example where this is happening. > Phones in Japan create iCalendars in Shift-JIS and attach them to email > messages. Because by standard you are suppose to hand the attachment to > the registered handler on an OPEN, the attachment processor no longer has > any MIME charset information. Do they set the correct charset on the MIME part? If no, then it's their fault, and they should fix it. If yes, then it's the MUAs fault for not handling things properly. 4.1.4 Character Set There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is UTF-8 as defined in [RFC 2279]. The "charset" Content-Type parameter can be used in MIME transports to specify any other IANA registered character set. Which to me means: unless MIME header says otherwise (or your app knows better) the native charset is UTF-8. So to get back to my message you quoted: this example doesn't show a fault in the spec (IMO). Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - 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 Mar 4 11:31:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29453 for ; Tue, 4 Mar 2003 11:31:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24GKIL29792 for ietf-calendar-bks; Tue, 4 Mar 2003 08:20:18 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24GKGX29784 for ; Tue, 4 Mar 2003 08:20:16 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24GKBb2026082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 08:20:16 -0800 Message-ID: <3E64D235.7090805@Royer.com> Date: Tue, 04 Mar 2003 09:20:05 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000304080106030001050205" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000304080106030001050205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> Robert_Ransdell@notesdev.ibm.com wrote: >> >>> When you try to OPEN an attachment, you must pass attachment to >>> registered handler for the attachment. So attachment is extracted >>> and handed off. It is no longer in MIME envelope. >> >> >> That is what your implementation does. > > > That is what EVERY implementation does! > > Doug, you're resisting changing iCalendar because of the deployed base > of CUAs; but what about the much larger deployed base of MUAs? If we > want to be able to use iMIP, we cannot require that MUAs be modified to > transport iCalendar safely. No modification is needed in a MUA, they work already as MUAs do support MIME. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000304080106030001050205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxNjIwMDZaMCMGCSqGSIb3DQEJBDEWBBSC UmiEtwsFtHbOhndqemeSs0VtFDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEACfeOiqkdB2uU lmFOJWlw4C3blBi4MN+TQRou0/x0owJ1YqhqC2at1iZRitdoYj+iVbZnhI/YCvCPhUmT0SVC 8oFqcGmOwt2vuQMwMB7FSt2CVv7MSZDBjWjlE64NNw4abBbGu/eyPN5PEXnJoTJPsmrkdaVM sHwt5+RXjw+o2qvIqC8g1SwYWvXEImt/WyV55igkdYf2xJZYaDYhQKXjFY1raVwj9Lp55RKo yohyoEa2raUZ1Lbn7GMOMOiL4AQuB7qWSiZn+R4yMtiet9U3csrKo6uwCg9VugYFoBjf5iP+ gszulCaHnwFKEDUa58I/pmgjaEyxjfZDXcRC1kGDgAAAAAAAAA== --------------ms000304080106030001050205-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 11:37:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29697 for ; Tue, 4 Mar 2003 11:37:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24GOR800997 for ietf-calendar-bks; Tue, 4 Mar 2003 08:24:27 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24GOQX00989 for ; Tue, 4 Mar 2003 08:24:26 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24GONb2026094 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 08:24:26 -0800 Message-ID: <3E64D332.3000208@Royer.com> Date: Tue, 04 Mar 2003 09:24:18 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> <200302280917.04804.mark@WebServiceSolutions.com> <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> <3E64BC5A.1030908@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020700040608050800030807" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020700040608050800030807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Lawrence Greenfield wrote: > >> John Strake has stated that no MIME implementations >> (MUA or HTTP) include the MIME headers when it saves a MIME >> body-part. >> >> Of course not. They should save objects in the local charset, doing >> conversions if necessary. >> > What is the local charset? POSIX, for example, specifies that locale > settings are stored in environment variables, which means that charsets > are per-process, not per-user or per-machine. That works if it works for the implementation. However there is no such restriction as to the stored charset. Just because my application is running in en_US.US-ASCII, does not mean that it can not read in a binary blob of SHIFT-JIS and charset translate it to UTF-8 for storage. The user view and data storage do not have to be in the same charset. Nether does the view and the transport charset have to be the same. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020700040608050800030807 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxNjI0MThaMCMGCSqGSIb3DQEJBDEWBBQ9 g0GU7QNmH72XpeEncSonSM1TlTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAQtnJqfDpxhbZ 9MkZBRKtOwOPHLC0mRgXoH/w4pZSt4kkeBlUD/Y9Zd/lTU22pWOWB9d33veO9zcF1DeYzJ0C Mqbi7qZEBw1ZazJVwSttuvYNsrFTof8FElJwR5IPUfmPvEg4IyeYj+eJgbvTi/5PltNFef00 J4IA3OiToEXWWI2QC7xqecicl3ZNYPgP06KcwaCEJrzXI225uHLqWYxqULrZoCGne6EyCMud U/IiY8X9oMTKNJrjewKd8OENXKQd08E2Y/3pQVwHO4KtDFNgj+4CfX5IbgIfnR6FZSpZBnks naJitkbqcTF94uzFFhgSShmpHdwDl4n4Xbgc2n7f3gAAAAAAAA== --------------ms020700040608050800030807-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 11:40:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29803 for ; Tue, 4 Mar 2003 11:40:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24GRq401553 for ietf-calendar-bks; Tue, 4 Mar 2003 08:27:52 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24GRpX01545 for ; Tue, 4 Mar 2003 08:27:51 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24GRmb2026119 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 08:27:51 -0800 Message-ID: <3E64D3FF.2040202@Royer.com> Date: Tue, 04 Mar 2003 09:27:43 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <200303041524.h24FOl6s003409@smtp6.andrew.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050803080606000003020503" To: undisclosed-recipients:; Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050803080606000003020503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: > Date: Tue, 04 Mar 2003 09:46:45 -0500 > From: John Stracke > [...] > Doug, you're resisting changing iCalendar because of the deployed base > of CUAs; but what about the much larger deployed base of MUAs? If we > want to be able to use iMIP, we cannot require that MUAs be modified to > transport iCalendar safely. > > Having redundant and potentially conflicting character set tagging is > harmful, too. Once the character set also exists inside the MIME > object, all tools that might try to do a character set transcoding must > be aware of the iCalendar format. No, it means that they can do charset translation an never be aware of the content. > If you want to go ahead with iCalendar having its own character set > tagging system, you should choose a MIME type other than > text/calendar so that processing systems do not default it to > text/plain. I do not follow your logic on that point. I can charset translate any text/plain to any other charset once I look at the MIME header charset attribute and never know or care about the formatting of the contents. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050803080606000003020503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxNjI3NDNaMCMGCSqGSIb3DQEJBDEWBBTj WW/uFMTDOlR3X2dC8P0+tWmjaTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAFQqvDqEDmmbd jHVm9FoNUSTzv6+W/jCOTv6wSzJdi9nX7E+JQ2M1w9rokdgnhUvY3SukUu0F3nYVDbJ5FSjn 8sO8d2CDq3zOk6QHXf7y5hMPZTiUd8iS+acpVLtcwX6wH8waN4UDIyi4j5n8SZ//R4w5L5GA iF8/svzKj+vRYWRnnMnbo4Y13iZAwmfN0jsl5fweew8FaZCGJI+Lx3ZsCgMAgPqqhQ8Cfgez PHR9OpfKFV4gfxTftwaXVwV49ROyx0+fr3CLmcO5gHS624M+WNWvwflqeCQmMsISfj2+fBl7 QO37Zzhuh9dwC2dANTDhsxYZ70AYaRVFX9vj67hbjwAAAAAAAA== --------------ms050803080606000003020503-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 11:47:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00321 for ; Tue, 4 Mar 2003 11:47:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24GXaY02525 for ietf-calendar-bks; Tue, 4 Mar 2003 08:33:36 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24GXYX02518 for ; Tue, 4 Mar 2003 08:33:35 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24GXUb2026154 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 08:33:35 -0800 Message-ID: <3E64D554.9060705@Royer.com> Date: Tue, 04 Mar 2003 09:33:24 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040703000700000904000706" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040703000700000904000706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > Andre Campi wrote > >Sorry, I don't want to sound blunt, but since you're raising the issue > >and advocating a change, the onus is on you to bring evidence for the > >change, not the other way around. So far the hasn't been a single > >example of something which is not working because of a flaw in the > >spec instead of a vendor mistake. > > I have already stated the example where this is happening. > Phones in Japan create iCalendars in Shift-JIS and attach them to email > messages. Because by standard you are suppose to hand the attachment > to the registered handler on an OPEN, the attachment processor no longer > has any MIME charset information. I am not aware of any such 'standard' that says '...suppose to hand the attachment to the registered handler on an OPEN, the attachment processor no longer has any MIME charset information' If it exists please post the standards body name and the name or ID of the standard. So far it looks to me as if you are using an OS library that does that for you. That however is your implementation decision and not a MUA, MIME, or iCalendar restriction. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040703000700000904000706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxNjMzMjRaMCMGCSqGSIb3DQEJBDEWBBTH WY3nSM8iSS7hEiGPwk9A/0WM/zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAW2B2CFrq/v32 LiXRHjhjEL1z6ULwSjXQBdydIiNxKlBNQR/zz2HakUJd3zMxv+A2qGFUNAuZq7BsRfUqFsE1 m1mqL6Z7m4vp0xGixxuwWJY/xbHtwIwvEmtqAuwmvbtLtRNJaBGESAem4qAeT5lgLzqsnBam tujZgKzhANYO2clFM74FiJc3KrIN4k3JHq9xpdFj5yH4Fks3SS6vj63jPQzwcqdAJQb9ZY0W a0wCOt3h00QAw51jHwYji/IJ7t5HPPg+GRxMnOkZKBGVlWDBnJSu51HF4VvIHl4SBJTe/jX7 ReH3TdANv0NPfBMSjKBtxYCHnczAxCEFKBOyJGPyGgAAAAAAAA== --------------ms040703000700000904000706-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 12:14:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02052 for ; Tue, 4 Mar 2003 12:14:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24H1tw05057 for ietf-calendar-bks; Tue, 4 Mar 2003 09:01:55 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24H1sX05053 for ; Tue, 4 Mar 2003 09:01:54 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030412053014582 for ; Tue, 04 Mar 2003 12:05:30 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 11:59:44 -0500 Message-ID: <3E64DB80.60705@centive.com> Date: Tue, 04 Mar 2003 11:59:44 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E64D554.9060705@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 16:59:44.0600 (UTC) FILETIME=[74A4CD80:01C2E26F] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > I am not aware of any such 'standard' that says '...suppose to hand > the attachment to the registered handler on an OPEN, the attachment > processor no longer has any MIME charset information' If it exists > please post the standards body name and the name or ID of the standard. It is, however, a de facto standard, because that's what everybody does. Nobody's told everybody to do it, but everybody has to accept the reality that everyone else does it. -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |"Hastur was paranoid, which was simply a sensible...well-adjusted| |reaction to living in Hell." --_Good Omens_ | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 4 12:19:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02331 for ; Tue, 4 Mar 2003 12:19:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24H6QS05286 for ietf-calendar-bks; Tue, 4 Mar 2003 09:06:26 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24H6PX05281 for ; Tue, 4 Mar 2003 09:06:25 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030412100627030 for ; Tue, 04 Mar 2003 12:10:06 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 12:04:20 -0500 Message-ID: <3E64DC94.5040705@centive.com> Date: Tue, 04 Mar 2003 12:04:20 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> <200302280917.04804.mark@WebServiceSolutions.com> <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> <3E64BC5A.1030908@centive.com> <3E64D332.3000208@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 17:04:20.0720 (UTC) FILETIME=[19395F00:01C2E270] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Just because my application > is running in en_US.US-ASCII, does not mean that it can not read > in a binary blob of SHIFT-JIS and charset translate it to UTF-8 > for storage. Once again: MUAs don't do that. -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |"Hastur was paranoid, which was simply a sensible...well-adjusted| |reaction to living in Hell." --_Good Omens_ | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 4 12:19:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02346 for ; Tue, 4 Mar 2003 12:19:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24H6P105282 for ietf-calendar-bks; Tue, 4 Mar 2003 09:06:25 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24H6OX05277 for ; Tue, 4 Mar 2003 09:06:24 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030412100029581 for ; Tue, 04 Mar 2003 12:10:00 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 12:04:14 -0500 Message-ID: <3E64DC8E.3070801@centive.com> Date: Tue, 04 Mar 2003 12:04:14 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <20030304095335.GE58688@inet.it> <20030304160854.GB59255@inet.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 17:04:14.0516 (UTC) FILETIME=[1586B740:01C2E270] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrea Campi wrote: >If yes, then it's the MUAs fault for not handling things properly. > > Since no existing MUA does what you want, it is not legitimate to say that what you want is "handling things properly". Any new standard that uses RFC-X needs to take into account the environment of existing implementations of RFC-X. iCalendar has failed to do so. -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |"Hastur was paranoid, which was simply a sensible...well-adjusted| |reaction to living in Hell." --_Good Omens_ | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 4 12:22:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02417 for ; Tue, 4 Mar 2003 12:22:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24H3pG05126 for ietf-calendar-bks; Tue, 4 Mar 2003 09:03:51 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24H3oX05122 for ; Tue, 4 Mar 2003 09:03:50 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030412072517399 for ; Tue, 04 Mar 2003 12:07:25 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 12:01:40 -0500 Message-ID: <3E64DBF3.6080401@centive.com> Date: Tue, 04 Mar 2003 12:01:39 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <3E64D235.7090805@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 17:01:40.0198 (UTC) FILETIME=[B98BA860:01C2E26F] 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, you're resisting changing iCalendar because of the deployed >> base of CUAs; but what about the much larger deployed base of MUAs? >> If we want to be able to use iMIP, we cannot require that MUAs be >> modified to transport iCalendar safely. > > No modification is needed in a MUA, they work already as MUAs do > support MIME. False. Once again: the step of transporting the attachment from the MIME body to the helper application is not MIME-based. The only cases where the CUA gets the MIME headers are those where the CUA is part of the MUA. -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |"Hastur was paranoid, which was simply a sensible...well-adjusted| |reaction to living in Hell." --_Good Omens_ | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 4 13:00:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03910 for ; Tue, 4 Mar 2003 13:00:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24Hr4i06514 for ietf-calendar-bks; Tue, 4 Mar 2003 09:53:04 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24Hr3X06510 for ; Tue, 4 Mar 2003 09:53:03 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24Hr1KL027408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 09:53:03 -0800 Message-ID: <3E64E7F7.8040208@Royer.com> Date: Tue, 04 Mar 2003 10:52:55 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <20030304095335.GE58688@inet.it> <20030304160854.GB59255@inet.it> <3E64DC8E.3070801@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010409060102000202070007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010409060102000202070007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Andrea Campi wrote: > >> If yes, then it's the MUAs fault for not handling things properly. >> >> > Since no existing MUA does what you want, John - are you sure? :-) > it is not legitimate to say > that what you want is "handling things properly". Any new standard that > uses RFC-X needs to take into account the environment of existing > implementations of RFC-X. iCalendar has failed to do so. No. Implementations may have failed, however many work and they do not do it by magic. It it because there are ways to get the information, MIME headers, and iCalendar attachments. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010409060102000202070007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxNzUyNTVaMCMGCSqGSIb3DQEJBDEWBBSH KOoNPdNpUMMOIokZpbwUmzgmBzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAZKbbLtxCN+S7 nNrGH4DGCQDS4NEM/ffASK6JgMVgNIsWXE5OFRkok4bzpbBtMxS5SHlZlrKsfsGkqDmBQoso PeM709C5xP/Ldr/nv/h2Gq6YGIBfTSAxfXNN9qx5ohV8yuk2mL648OBRBp6j9+LyThb48zjc 4JaWlYxuj5/wFNZzM2oayu+Z4yx//miqHCs/4ZSC5Zdl1TqpXWEyePJbfz/bdXA+WvWwKDqU GCNcjMjDQp7QImf+vkNeHGG3cC1Szci/JHH4YSC5pyjqoSDZbbfjkHsZz4To1uSyHuX+lcG3 NZ+bVagccNCtGQvVkbfQ8pao6j2CU+t/lcPyenW9mAAAAAAAAA== --------------ms010409060102000202070007-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 13:03:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04102 for ; Tue, 4 Mar 2003 13:03:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24HpEa06445 for ietf-calendar-bks; Tue, 4 Mar 2003 09:51:14 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24HpDX06441 for ; Tue, 4 Mar 2003 09:51:13 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h24HpB6s015268; Tue, 4 Mar 2003 12:51:11 -0500 Date: Tue, 4 Mar 2003 12:51:11 -0500 Message-Id: <200303041751.h24HpB6s015268@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" In-reply-to: <3E64D3FF.2040202@Royer.com> Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <200303041524.h24FOl6s003409@smtp6.andrew.cmu.edu> <3E64D3FF.2040202@Royer.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Tue, 04 Mar 2003 09:27:43 -0700 From: Doug Royer [...] > Having redundant and potentially conflicting character set tagging is > harmful, too. Once the character set also exists inside the MIME > object, all tools that might try to do a character set transcoding must > be aware of the iCalendar format. No, it means that they can do charset translation an never be aware of the content. Huh? > If you want to go ahead with iCalendar having its own character set > tagging system, you should choose a MIME type other than > text/calendar so that processing systems do not default it to > text/plain. I do not follow your logic on that point. I can charset translate any text/plain to any other charset once I look at the MIME header charset attribute and never know or care about the formatting of the contents. That's correct. However, if iCalendar objects ("text/calendar") contained their _own_ charset information (via a CHARSET:utf-8 property or whatever) a naive conversion routine would not know to update that property. Larry From owner-ietf-calendar@mail.imc.org Tue Mar 4 13:11:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04236 for ; Tue, 4 Mar 2003 13:11:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24I0Ft06748 for ietf-calendar-bks; Tue, 4 Mar 2003 10:00:15 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24I0DX06743 for ; Tue, 4 Mar 2003 10:00:13 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24I0BKL027458 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 10:00:13 -0800 Message-ID: <3E64E9A5.8060906@Royer.com> Date: Tue, 04 Mar 2003 11:00:05 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> <200302280917.04804.mark@WebServiceSolutions.com> <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> <3E64BC5A.1030908@centive.com> <3E64D332.3000208@Royer.com> <3E64DC94.5040705@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050606070806010005040001" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050606070806010005040001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> Just because my application >> is running in en_US.US-ASCII, does not mean that it can not read >> in a binary blob of SHIFT-JIS and charset translate it to UTF-8 >> for storage. > > > Once again: MUAs don't do that. They don't have to do that. That's not their job. We are talking about a calendar aware program which can also be an MUA. You CAN send iCalendar attachments using any MUA that I have seen. MUA's are not responsible for displaying video attachments any more or less than iCalendar attachments. No where in RFC 244[567] or CAP does it mandate or suggest that MUAs be calendar aware. iMIP simply shows how to transport iCalendar data using MIME. 'MUA' is only used once in 2447 and it is not talking about mandating that MUA be CUAs. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050606070806010005040001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxODAwMDVaMCMGCSqGSIb3DQEJBDEWBBQf kjCECW/Dq5k/OiWQyWqJTHhwjzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAEULbqsYRtp9o QduuVqTu+lohs0UYhk9NlhbWDkCrn81/ESaiH2skOBdGnzu0auHXBj+WQcJ0MhvKiweiOMW0 g3ZClvGlGhsIhKLQeWgonU6LteHOe13t5G+E2Q5TffyyWeIn+jEDlMNTPl3ka20aOUcTXn8k 6nN8HLn0PqTqTmy3hBdStz1/hwlHxQeGFbAymPglCQdQIKSNis5AOrosgi2LnF1uVN314Mzt XwbxLl0VFrFGRCjmKnqyoGZo1bRgYQzKrNNhinHy8cvy6kGsbGcyZ8kJDbKLmJ/2mv8xZBaH 9yRZBpBy0HYfO52g8mhMEdUXbIDvWaCWztX7vrqWCgAAAAAAAA== --------------ms050606070806010005040001-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 13:16:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04340 for ; Tue, 4 Mar 2003 13:16:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24I9f807030 for ietf-calendar-bks; Tue, 4 Mar 2003 10:09:41 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24I9eX07026 for ; Tue, 4 Mar 2003 10:09:40 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id BE7BF155C6; Tue, 4 Mar 2003 19:09:40 +0100 (CET) Date: Tue, 4 Mar 2003 19:09:40 +0100 From: Andrea Campi To: John Stracke Cc: "ietf-calendar@imc.org" Subject: Re: The charset issue Message-ID: <20030304180939.GC59255@inet.it> References: <20030304095335.GE58688@inet.it> <20030304160854.GB59255@inet.it> <3E64DC8E.3070801@centive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E64DC8E.3070801@centive.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Mar 04, 2003 at 12:04:14PM -0500, John Stracke wrote: > > Andrea Campi wrote: > > >If yes, then it's the MUAs fault for not handling things properly. > > > > > Since no existing MUA does what you want, it is not legitimate to say The one I use (mutt) does, as all Unix MUAs which use metamail. In fact metamail has been handling this correctly for the best part of a decade. Correctly, in this context, means it's able to (be configured to) pass the charset as a command-line argument to any helper application it calls. That said, I'll readily agree that this is a niche application. Still it show that SOME existing MUA chose to do it right. I don't use Windows so I can't easily check it, but given that Unicode has been the native format from Win NT 3.5 (or was that 4?), it would surprise me if no MUA chose to convert from the incoming charset to some sort of Unicode before passing the data to an helper application. Bye, andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - 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 Mar 4 13:21:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04459 for ; Tue, 4 Mar 2003 13:21:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24I2FC06820 for ietf-calendar-bks; Tue, 4 Mar 2003 10:02:15 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24I2EX06816 for ; Tue, 4 Mar 2003 10:02:14 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24I2CKL027486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 10:02:15 -0800 Message-ID: <3E64EA1E.4070309@Royer.com> Date: Tue, 04 Mar 2003 11:02:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E64D554.9060705@Royer.com> <3E64DB80.60705@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090908040703030506080202" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090908040703030506080202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> I am not aware of any such 'standard' that says '...suppose to hand >> the attachment to the registered handler on an OPEN, the attachment >> processor no longer has any MIME charset information' If it exists >> please post the standards body name and the name or ID of the standard. > > It is, however, a de facto standard, because that's what everybody does. > Nobody's told everybody to do it, but everybody has to accept the > reality that everyone else does it. Everybody does not do that. And my other point is still valid. If that method does not work - don't use it. There are methods that do work. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090908040703030506080202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxODAyMDdaMCMGCSqGSIb3DQEJBDEWBBR7 sdwoW7k+iEFsrv0qS4H4ZsVDmjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAblqNoqSiiIef i5Ustmm+L2rIHc2l2hjM/0DDaFzi9JJgAocgeiAK8nOKU6hW90VbNqn5O+ai2LP3iE4otrAd CFmXXVTLLZrgNAK2JcrUXz0ZMZaBNhvmS6Nknw7HlOQ0PrTjyLHRhO274rVrVWcybcx4rnCQ +Qa7tB1kJZ7S1jF7TswhaHAaendCYGFLExHQe9D4nLCcQEkgCta9D1J3uYuPnPjbg6C43Q7e CyG2TUoYMFvMi3pPT5o9NZGoeY9kQYYKlXCAAvnUHsrKJrzaAhLDf5uwEtJ1Qm49J7ttht4v Rh7YOsfkAG41CM9CdazvDF/4ualdoZOJ10Fnk01DjQAAAAAAAA== --------------ms090908040703030506080202-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 13:25:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04542 for ; Tue, 4 Mar 2003 13:25:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24IEYl07325 for ietf-calendar-bks; Tue, 4 Mar 2003 10:14:34 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24IEXX07321 for ; Tue, 4 Mar 2003 10:14:33 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24IEUKL027572 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 10:14:33 -0800 Message-ID: <3E64ED01.2020807@Royer.com> Date: Tue, 04 Mar 2003 11:14:25 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <3E64D235.7090805@Royer.com> <3E64DBF3.6080401@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040801040603070107070508" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040801040603070107070508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > False. Once again: the step of transporting the attachment from the > MIME body to the helper application is not MIME-based. No, the method that SOME use might work that way. If it does not work for you or your application - use another method. I can extract the MIME headers on Windows and Unix from e-mail. It is an implementation decission - not a problem in the specification. > The only cases where the CUA gets the MIME headers are those where the > CUA is part of the MUA. In the area of calendaring - yes you need a CUA. Just like to view video you need some kind of viewer. That is orthogonal to the MIME header issue as there are methods that do work to get he MIME headers with the attachements. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040801040603070107070508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxODE0MjVaMCMGCSqGSIb3DQEJBDEWBBQu tOUbevB0Lq5Fr/MBilWyPwO1jzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAOtr6ZC+fSC5W St32ci+xkKarUa5OjndQyUE58GEynO+Mjx6lAoNpR1BtoyPagj0gROZxjaXInoMgJ5kYOmHf E0Bjhd7poJ15/+gLJeI7ytO+U1yf44l2GJ1nYGFQc1CMeF1XXaJrjhS/1e6SfxBpTNOuPjuQ Mrjuh6yKRckxDV+Z0O0enVAvqHmNGfTEUrSBGO/j3VmfDCY0eoRnG/L5qU2nGRUU6pmirm+Q ZS0Xxs4JfuEi3EfTtQFCj59F4/EcCIMeXY8zTf+bfcbhNmCsC+PoAz5Lm4KekMLIQWmg4E6w EC/A3beofLxaaf+WbIgrWOWeMpVA8g7FuFpQhGLJpgAAAAAAAA== --------------ms040801040603070107070508-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 13:43:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04985 for ; Tue, 4 Mar 2003 13:43:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24IQvj07948 for ietf-calendar-bks; Tue, 4 Mar 2003 10:26:57 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24IQuX07940 for ; Tue, 4 Mar 2003 10:26:56 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24IQsKL027664 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 10:26:56 -0800 Message-ID: <3E64EFE8.3050202@Royer.com> Date: Tue, 04 Mar 2003 11:26:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <200303041524.h24FOl6s003409@smtp6.andrew.cmu.edu> <3E64D3FF.2040202@Royer.com> <200303041751.h24HpB6s015268@smtp6.andrew.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030308000903050701090900" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030308000903050701090900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > That's correct. However, if iCalendar objects ("text/calendar") > contained their _own_ charset information (via a CHARSET:utf-8 > property or whatever) a naive conversion routine would not know to > update that property. As that would only work some of the time - why should we consider that? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030308000903050701090900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQxODI2NDhaMCMGCSqGSIb3DQEJBDEWBBSo yRL1moXBws8VWDcYn3lSeoYEFDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAAfzZmrcDsYpP HiIQRa8CHtqiZsJhnp+WTI2Dabike+UfzjQkzUAhaup0JJtsFLf1nbZxcVhI4S4Ijhk7TW7n 7xROF/UbRl71r43lplAZvx42ThZWokjnFjnRTzZpPZ1zSZLQR1ZpL0RU9Lg/PHeIT7zoXug7 oDGhKcIJiZdaZebcjQJFeIN69y0TfOoaPGU2xgQJ3e9inJfmX4SY9zwfLDiVIK3PST8vPPT9 +ppqKP0GReOCUmn/fmvttJlpMYs3JwccFAtU/PseXsLLnL8vdKmW4q6lRohZce+DWWCRwes9 3pYIw9oAYOlqHoRndtIJV1BcNJGOCv+FOtKtUckcMAAAAAAAAA== --------------ms030308000903050701090900-- From owner-ietf-calendar@mail.imc.org Tue Mar 4 13:53:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05304 for ; Tue, 4 Mar 2003 13:53:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24IaYv08995 for ietf-calendar-bks; Tue, 4 Mar 2003 10:36:34 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24IaWX08988 for ; Tue, 4 Mar 2003 10:36:33 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030413400829869 for ; Tue, 04 Mar 2003 13:40:08 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 13:34:22 -0500 Message-ID: <3E64F1AE.3000507@centive.com> Date: Tue, 04 Mar 2003 13:34:22 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <20030304095335.GE58688@inet.it> <20030304160854.GB59255@inet.it> <3E64DC8E.3070801@centive.com> <3E64E7F7.8040208@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 18:34:22.0685 (UTC) FILETIME=[AD0BD0D0:01C2E27C] 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: > >> >> Andrea Campi wrote: >> >>> If yes, then it's the MUAs fault for not handling things properly. >>> >>> >> Since no existing MUA does what you want, > > > John - are you sure? :-) Um, no, not any more. -- /=======================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=======================================================| |"Music is not a noun, it's a verb." --John Perry Barlow| \=======================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 4 14:11:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05970 for ; Tue, 4 Mar 2003 14:11:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24IuT011690 for ietf-calendar-bks; Tue, 4 Mar 2003 10:56:29 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24IuRX11686 for ; Tue, 4 Mar 2003 10:56:28 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 6E2784F30 for ; Tue, 4 Mar 2003 13:55:53 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Tue, 4 Mar 2003 13:56:03 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> <200303031401.35138.mark@WebServiceSolutions.com> <20030304095335.GE58688@inet.it> In-Reply-To: <20030304095335.GE58688@inet.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303041356.03773.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > The format in the memo is perfectly applicable without MIME. However, > the fact that your application works without MIME doesn't allow you to > disregard charset issues; rather, it puts the burden on you to make sure > you know how to interpret iCalendar data properly. This I think is the > spirit of the above sentence, and thus the spec is doing its duty. Would it be fair to say this: you feel it is up to non-MIME environments to come up with their own charset solution, while I feel this should be solved by having the document state its charset. My reason is because there exists a number of applications that do not provide a charset solution, and I'm sure there will be future applications that do not provide on either. It would seem to me that 2445 would only benefit from encapsulating the charset. > You've been repeatedly citing the example of passing iCalendar data around > with tools which are unaware of MIME. That's fine, you can either convert > the data to UTF-8 or pass around external metadata. For instance, if a MUA > saves a part from a MIME message and then calls an helper application to > read it, it can either convert from the original charset to UTF-8, or it > can pass the charset as a command line argument (for instance). No. Someone in Japan can't use notepad to edit a SHIFT-JIS iCalendar document and ftp it to me because I will not know what charset the document is in. > > I see multiple organizations taking advantage of this to break > > interoperability in various ways (from calendar clients and servers to > > cell phones) and I feel it is only going to get worse. > > What makes you feel those organizations will update their applications to > this new iteration of the spec you are proposing? I believe people will follow the spec if they can. Also, if the IETF releases a new spec people will have no choice if they want to interoperate. It's the same reason people try to comply the best they can right now. > > There has not been a single better proposal than the CHARSET property for > > fixing the above statement. > > Sorry, I don't want to sound blunt, but since you're raising the issue > and advocating a change, the onus is on you to bring evidence for the > change, not the other way around. So far the hasn't been a single > example of something which is not working because of a flaw in the > spec instead of a vendor mistake. There must be a disconnect as there are several posted by more than one person. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Tue Mar 4 14:18:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06204 for ; Tue, 4 Mar 2003 14:18:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24J8KI12662 for ietf-calendar-bks; Tue, 4 Mar 2003 11:08:20 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24J8IX12657 for ; Tue, 4 Mar 2003 11:08:19 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030414115423714 for ; Tue, 04 Mar 2003 14:11:54 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 14:06:08 -0500 Message-ID: <3E64F920.40001@centive.com> Date: Tue, 04 Mar 2003 14:06:08 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <3E64D235.7090805@Royer.com> <3E64DBF3.6080401@centive.com> <3E64ED01.2020807@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 19:06:08.0805 (UTC) FILETIME=[1D2EA550:01C2E281] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > That is orthogonal to the MIME > header issue as there are methods that do work to get he MIME headers > with the attachements. But there is no good method to do so without the cooperation of the MUA. I suppose there are some *bad* methods. If you know where the message came from (e.g., a local spool or an IMAP server), and have access to that source (might be tricky, if the IMAP server demands a certificate and the CUA doesn't have it, or if the IMAP server doesn't permit simultaneous logins--some don't--or if it's a nonstandard message store), you might be able to search for text/calendar attachments and read the MIME headers directly. It'd be disgustingly slow, though. -- /===============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |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 Tue Mar 4 14:45:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07098 for ; Tue, 4 Mar 2003 14:45:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24JWQX14000 for ietf-calendar-bks; Tue, 4 Mar 2003 11:32:26 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h24JWPX13994 for ; Tue, 4 Mar 2003 11:32:25 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030414360018728 for ; Tue, 04 Mar 2003 14:36:00 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Mar 2003 14:30:15 -0500 Message-ID: <3E64FEC7.8070008@centive.com> Date: Tue, 04 Mar 2003 14:30:15 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200303031401.35138.mark@WebServiceSolutions.com> <20030304095335.GE58688@inet.it> <200303041356.03773.mark@WebServiceSolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 19:30:15.0454 (UTC) FILETIME=[7B73C3E0:01C2E284] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Swanson wrote: >No. Someone in Japan can't use notepad > (Or vi, or emacs.) > to edit a SHIFT-JIS iCalendar document >and ftp it to me because I will not know what charset the document is in. > > >>What makes you feel those organizations will update their applications to >>this new iteration of the spec you are proposing? >> >> > >I believe people will follow the spec if they can. Also, if the IETF releases >a new spec people will have no choice if they want to interoperate. It's the >same reason people try to comply the best they can right now. > Right. And anybody that implements a Proposed Standard needs to know that they might have to change their implementation when it goes to Draft Standard--which, by definition, incorporates experience with interoperability problems. -- /===============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |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 Tue Mar 4 15:49:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10025 for ; Tue, 4 Mar 2003 15:49:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24KgDS19107 for ietf-calendar-bks; Tue, 4 Mar 2003 12:42:13 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24KgCX19103 for ; Tue, 4 Mar 2003 12:42:12 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id AE9A38D7B9; Tue, 4 Mar 2003 12:42:14 -0800 (PST) From: "Chris Olds" To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: Re: Charset Date: Tue, 4 Mar 2003 12:42:14 -0800 Message-Id: <20030304204214.M65090@asitturnsout.org> In-Reply-To: <3E64EFE8.3050202@Royer.com> References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <200303041524.h24FOl6s003409@smtp6.andrew.cmu.edu> <3E64D3FF.2040202@Royer.com> <200303041751.h24HpB6s015268@smtp6.andrew.cmu.edu> <3E64EFE8.3050202@Royer.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.50 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 04 Mar 2003 11:26:48 -0700, Doug Royer wrote > > That's correct. However, if iCalendar objects ("text/calendar") > > contained their _own_ charset information (via a CHARSET:utf-8 > > property or whatever) a naive conversion routine would not know to > > update that property. > > As that would only work some of the time - why should we consider that? Because MIME-encapsulation only works some of the time, and a CHARSET property helps with that complimentary set. I cannot recall any MUA that transcodes attachments (I would be interested to hear of an example), so I don't think that suggesting such transcoding is the duty of the MUA is a useful resolution to this issue, nor do I think that the potential problems with naive transcoding rule out a CHARSET property. Some comments on other emails I recieved today: The majority of non-EBCDIC character sets implement the invariant portions of ISO 646, so the property would provide usable information in those cases. Windows NT (and it heirs and assigns) are natively Unicode, but Unicode is not commonly used as the storage format for text documents (in the US, at least); the only UNICODE-capable editors than come to mind are TextPad and Emacs. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Tue Mar 4 17:49:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13317 for ; Tue, 4 Mar 2003 17:49:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24MXZg22359 for ietf-calendar-bks; Tue, 4 Mar 2003 14:33:35 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24MXXX22355 for ; Tue, 4 Mar 2003 14:33:33 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h24MXVKL029674 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Mar 2003 14:33:34 -0800 Message-ID: <3E6529B6.5080700@Royer.com> Date: Tue, 04 Mar 2003 15:33:26 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <200303041524.h24FOl6s003409@smtp6.andrew.cmu.edu> <3E64D3FF.2040202@Royer.com> <200303041751.h24HpB6s015268@smtp6.andrew.cmu.edu> <3E64EFE8.3050202@Royer.com> <20030304204214.M65090@asitturnsout.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060000070907050601030903" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060000070907050601030903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chris Olds wrote: > Because MIME-encapsulation only works some of the time, Until someone proposes and this WG agrees to a new iCalendar transfer protocol. I do not know of any proposed inter vendor issues with charset and iCalendar, iTIP, iMIP, or CAP. So far all of the issues presented are implementation issues and they are not protocol and transfer of information issues. > and a CHARSET property helps with that complimentary set. And makes some implementations objects in some charsets break. > Windows NT (and it heirs and assigns) are natively Unicode, but Unicode is not > commonly used as the storage format for text documents (in the US, at least); > the only UNICODE-capable editors than come to mind are TextPad and Emacs. This WG is concerted with transporting iCalendar objects between vendors as an interoperability protocol. Why should we care if you can hand edit an object or not? Copy/Paste and object or not? Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060000070907050601030903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDQyMjMzMjZaMCMGCSqGSIb3DQEJBDEWBBSM 8I+MK4vQMpfZCqvzJDCl6QfnUzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAU6+Kble21+AH AoGaojwdMXBe5LJvekxGvh7RSj55QSLTRW4uS+amO3nqpz/rC4apdlgJTQ82feJZ/Cf1GWrS NfP/eWtRNNH6d6CSPiTGrfqZG7kY500YR7G8EkWlEPXSe0Tqi5gKOGtJorGYc+XWGobeIcTS dMe7STgXHOqtPkyQReqoPPkqokmmVxUlgnsI+mXfLk+Dopf53I89ASn5N9i6ZX0Ia2805bor lj86/jES3OvsbPQv6lh24SGTt7yRj7Fv1V8lfxRrMdRGxf6aE+xsoYcmnnAvEMOexu1fjr9F qU+tC4b708kq1u9IweAzsZa4N8LekgsGvN4lAFsVrAAAAAAAAA== --------------ms060000070907050601030903-- From owner-ietf-calendar@mail.imc.org Wed Mar 5 11:51:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12070 for ; Wed, 5 Mar 2003 11:51:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25GcZF27051 for ietf-calendar-bks; Wed, 5 Mar 2003 08:38:35 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25GcY327044 for ; Wed, 5 Mar 2003 08:38:34 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id D8FC14F30 for ; Wed, 5 Mar 2003 11:38:01 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: Charset Date: Wed, 5 Mar 2003 11:37:49 -0500 User-Agent: KMail/1.5 References: <20030304204214.M65090@asitturnsout.org> <3E6529B6.5080700@Royer.com> In-Reply-To: <3E6529B6.5080700@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303051137.49474.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On March 4, 2003 05:33 pm, Doug Royer wrote: > Until someone proposes and this WG agrees to a new iCalendar > transfer protocol. I do not know of any proposed inter vendor > issues with charset and iCalendar, iTIP, iMIP, or CAP. So > far all of the issues presented are implementation issues and > they are not protocol and transfer of information issues. I can not find anywhere in the charter or in 2445 that states only certain transfer protocols are allowed. To me, this means that the iCalendar object is encapsulated well enough that it does not matter what transfer protocol is used. Many statements in the rfc and charter back this up. > This WG is concerted with transporting iCalendar objects between vendors > as an interoperability protocol. Why should we care if you can hand > edit an object or not? Copy/Paste and object or not? I care about how people will use ICalendar and I would like to see it used in many flexible ways. I believe the spirit of ICalendar is to have an encapsulated format you can send with any transport mechanism you like - even if that transport mechanism is something as simple as the clipboard. It seems to me the original authors of the spec (perhaps we could ask them) went through enormous pain in order to provide this flexibility and succeeded in every way except for the charset issue. As Chris mentioned, there is even a quote from 2445: Formal Definition: The character sets supported by this revision of iCalendar are UTF-8 and US ASCII thereof. The applicability to other character sets is for future work. This leads me to believe that we are doing this future work right now, and can complete the spec as it was intended to work. Comments welcome as always. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Mar 5 21:17:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10321 for ; Wed, 5 Mar 2003 21:17:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26218a25392 for ietf-calendar-bks; Wed, 5 Mar 2003 18:01:08 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26212325388 for ; Wed, 5 Mar 2003 18:01:02 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KT5VF5839S002DEU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-calendar@imc.org; Wed, 05 Mar 2003 18:00:56 -0800 (PST) Date: Wed, 05 Mar 2003 17:47:38 -0800 (PST) From: ned+ietf-calendar@mrochek.com Subject: Re: The charset issue In-reply-to: "Your message dated Tue, 04 Mar 2003 19:09:40 +0100" <20030304180939.GC59255@inet.it> To: Andrea Campi Cc: John Stracke , "ietf-calendar@imc.org" Message-id: <01KT6AEHQFV8002DEU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20030304095335.GE58688@inet.it> <20030304160854.GB59255@inet.it> <3E64DC8E.3070801@centive.com> <20030304180939.GC59255@inet.it> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > On Tue, Mar 04, 2003 at 12:04:14PM -0500, John Stracke wrote: > > > > Andrea Campi wrote: > > > > >If yes, then it's the MUAs fault for not handling things properly. > > > > > > > > Since no existing MUA does what you want, it is not legitimate to say > The one I use (mutt) does, as all Unix MUAs which use metamail. In fact > metamail has been handling this correctly for the best part of a > decade. Correctly, in this context, means it's able to (be configured to) > pass the charset as a command-line argument to any helper application > it calls. The MUA I use does this as well, and it isn't based on metamail. (I've been considering giving it access to content-disposition parameters as well.) And the EMS callout interface in Eudora provides access to both content-type and content-disposition parameters. It is also worth pointing out that the mailcap format metamail and others use that includes this ability to access content-type parameters is specified in RFC 1343. > That said, I'll readily agree that this is a niche application. Still > it show that SOME existing MUA chose to do it right. More than one, actually. FWIW. Ned From owner-ietf-calendar@mail.imc.org Thu Mar 6 06:44:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05272 for ; Thu, 6 Mar 2003 06:44:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26BQbP10111 for ietf-calendar-bks; Thu, 6 Mar 2003 03:26:37 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26BQa310107 for ; Thu, 6 Mar 2003 03:26:36 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02239; Thu, 6 Mar 2003 06:24:32 -0500 (EST) Message-Id: <200303061124.GAA02239@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cap-10.txt Date: Thu, 06 Mar 2003 06:24:31 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendar Access Protocol (CAP) Author(s) : D. Royer et al. Filename : draft-ietf-calsch-cap-10.txt Pages : 148 Date : 2003-3-5 The Calendar Access Protocol (CAP) is an Internet protocol described in this memo that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). The CAP definition is based on requirements identified by the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) Working Group. More information about the IETF CALSCH Working Group activities can be found on the IMC web site at http:// www.imc.org/ietf-calendar and at the IETF web site at http:// www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the references within this memo for further information on how to access these various documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-cap-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cap-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5140158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140158.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Thu Mar 6 09:26:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16463 for ; Thu, 6 Mar 2003 09:26:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26EAXC21129 for ietf-calendar-bks; Thu, 6 Mar 2003 06:10:33 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h26EAV321123 for ; Thu, 6 Mar 2003 06:10:31 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030609133622209 ; Thu, 06 Mar 2003 09:13:36 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 09:07:52 -0500 Message-ID: <3E675637.6090907@centive.com> Date: Thu, 06 Mar 2003 09:07:51 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ned.freed@mrochek.com CC: Andrea Campi , "ietf-calendar@imc.org" Subject: Re: The charset issue References: <20030304095335.GE58688@inet.it> <20030304160854.GB59255@inet.it> <3E64DC8E.3070801@centive.com> <20030304180939.GC59255@inet.it> <01KT6AEHQFV8002DEU@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 14:07:52.0065 (UTC) FILETIME=[C6B85710:01C2E3E9] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ned.freed@mrochek.com wrote: >It is also worth pointing out that the mailcap format metamail and others use >that includes this ability to access content-type parameters is specified >in RFC 1343. > OK, I'm dropping this line of argument; I was grossly ignorant. -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |"What now, Brain?" "We should flee in terror. Yes, that would be| |the wisest course." | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 6 09:26:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16478 for ; Thu, 6 Mar 2003 09:26:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26EGLc21359 for ietf-calendar-bks; Thu, 6 Mar 2003 06:16:21 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h26EGK321355 for ; Thu, 6 Mar 2003 06:16:20 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030609195429862 for ; Thu, 06 Mar 2003 09:19:54 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 09:14:09 -0500 Message-ID: <3E6757B0.8050005@centive.com> Date: Thu, 06 Mar 2003 09:14:08 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <3E63D7B5.6050709@Royer.com> <3E64BC55.8090509@centive.com> <200303041524.h24FOl6s003409@smtp6.andrew.cmu.edu> <3E64D3FF.2040202@Royer.com> <200303041751.h24HpB6s015268@smtp6.andrew.cmu.edu> <3E64EFE8.3050202@Royer.com> <20030304204214.M65090@asitturnsout.org> <3E6529B6.5080700@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 14:14:09.0111 (UTC) FILETIME=[A774FE70:01C2E3EA] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Why should we care if you can [...] > Copy/Paste and object or not? Well, obviously, somebody cared when 2445 was written. From the Abstract: In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, Clipboards tend to be typed, but I'm not aware of any that uses MIME headers. Mac doesn't; X doesn't; I'm pretty sure Windows doesn't (not surprising, since all of these predate MIME--RFC-1341, 1992). Admittedly, it doesn't actually seem to be covered in the WG's charter. -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |"What now, Brain?" "We should flee in terror. Yes, that would be| |the wisest course." | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 6 09:32:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16790 for ; Thu, 6 Mar 2003 09:32:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26EIAP21418 for ietf-calendar-bks; Thu, 6 Mar 2003 06:18:10 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h26EI8321414 for ; Thu, 6 Mar 2003 06:18:09 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030609214226194 for ; Thu, 06 Mar 2003 09:21:42 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 09:15:57 -0500 Message-ID: <3E67581D.2030100@centive.com> Date: Thu, 06 Mar 2003 09:15:57 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <20030304204214.M65090@asitturnsout.org> <3E6529B6.5080700@Royer.com> <200303051137.49474.mark@WebServiceSolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 14:15:57.0943 (UTC) FILETIME=[E8537070:01C2E3EA] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Swanson wrote: >Formal Definition: The character sets supported by this revision of > iCalendar are UTF-8 and US ASCII thereof. The applicability to other > character sets is for future work. > >This leads me to believe that we are doing this future work right now, and can >complete the spec as it was intended to work. > > Hear, hear. In fact, given the tarpit that awaits us if people fall into the trap of placing non-UTF-8 iCalendar objects into non-MIME environments (as they are starting to do), I'd say it might be important enough to split our attention and work on it alongside CAP. -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |"What now, Brain?" "We should flee in terror. Yes, that would be| |the wisest course." | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 6 10:12:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19392 for ; Thu, 6 Mar 2003 10:12:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26F0PR22863 for ietf-calendar-bks; Thu, 6 Mar 2003 07:00:25 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26F0N322859 for ; Thu, 6 Mar 2003 07:00:23 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id D82BD4F30 for ; Thu, 6 Mar 2003 09:59:54 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: Charset Date: Thu, 6 Mar 2003 10:00:22 -0500 User-Agent: KMail/1.5 References: <3E6529B6.5080700@Royer.com> <3E6757B0.8050005@centive.com> In-Reply-To: <3E6757B0.8050005@centive.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303061000.22327.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On March 6, 2003 09:14 am, John Stracke wrote: > Doug Royer wrote: > > Why should we care if you can [...] > > Copy/Paste and object or not? > > Well, obviously, somebody cared when 2445 was written. From the Abstract: > > In > addition, the content type is useful as an object for interactions > between desktop applications using the operating system clipboard, Excellent quote! -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Fri Mar 7 01:23:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01396 for ; Fri, 7 Mar 2003 01:23:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h276Dew01722 for ietf-calendar-bks; Thu, 6 Mar 2003 22:13:40 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h276Dd301718 for ; Thu, 6 Mar 2003 22:13:39 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 8D4A68D7D4 for ; Thu, 6 Mar 2003 22:13:41 -0800 (PST) From: "Chris Olds" To: ietf-calendar@imc.org Subject: 2445 test files? Date: Thu, 6 Mar 2003 22:13:41 -0800 Message-Id: <20030307061341.M10362@asitturnsout.org> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.50 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm working on validating my 2445 parser (written in Python); can anyone point me at a test suite? I'm also interested in any data people can share about differences between implementations; I've found some pages on the web about Outlook compatibility, but that's about all. Thanks - /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Fri Mar 7 01:44:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01729 for ; Fri, 7 Mar 2003 01:44:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h276U8H02169 for ietf-calendar-bks; Thu, 6 Mar 2003 22:30:08 -0800 (PST) Received: from mail.lan-aces.com (mail.lan-aces.com [65.17.118.66]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h276U7302165 for ; Thu, 6 Mar 2003 22:30:07 -0800 (PST) Message-Id: <200303070630.h276U7302165@above.proper.com> Received: from [65.17.118.66] (Ralph.Patterson@LAN-ACES.COM) by Office-Logic InterChange; Fri, 07 Mar 2003 00:30:09 -0600 Date: Fri, 07 Mar 2003 00:31:26 -0600 From: Ralph.Patterson@lan-aces.com To: "ietf-calendar@imc.org" Subject: Re: Charset X-Mailer: Office-Logic/Win32 7.12 MIME-Version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h276U7302166 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The original spec (RFC2445) required that the fidelity of the iCalendar object be maintained even after all of the MIME information was stripped off. The interpretation was that if something (e.g., Clipboard) took the object and repackaged and retransmitted it, it would remain unchanged between (inclusive) BEGIN:VCALENDAR ... END:VCALENDAR So even though the spec was for MIME-encoded transmission of calendar objects, the MIME/message header was not to contain anything necessary to interpret the object. Unless and until changed, I would take that to mean that after the message is decoded, it would be back to UTF-8 or US ASCII. The spec was for "over-the-wire" transmission but the iCalendar object itself contained the specified parameter tags and values necessary to recreate the event by the receiving application. Regards, Ralph Patterson LAN-ACES, Inc. http://WWW.LAN-ACES.COM *** End of comment *** On Thursday, March 06, 2003 9:00 AM, Mark Swanson wrote: > >Date: Thu, 6 Mar 2003 10:00:22 -0500 >From: Mark Swanson >To: "ietf-calendar@imc.org" >Subject: Re: Charset > >On March 6, 2003 09:14 am, John Stracke wrote: >> Doug Royer wrote: >> > Why should we care if you can [...] >> > Copy/Paste and object or not? >> >> Well, obviously, somebody cared when 2445 was written. From the Abstract: >> >> In >> addition, the content type is useful as an object for interactions >> between desktop applications using the operating system clipboard, > >Excellent quote! > >-- >Schedule your world with ScheduleWorld.com >http://www.ScheduleWorld.com/ >Java Web Start: >http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp > > From owner-ietf-calendar@mail.imc.org Fri Mar 7 10:33:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10944 for ; Fri, 7 Mar 2003 10:32:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27FI4R26998 for ietf-calendar-bks; Fri, 7 Mar 2003 07:18:04 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h27FI2326994 for ; Fri, 7 Mar 2003 07:18:02 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003030710212829451 for ; Fri, 07 Mar 2003 10:21:28 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Mar 2003 10:15:43 -0500 Message-ID: <3E68B79E.7050701@centive.com> Date: Fri, 07 Mar 2003 10:15:42 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Charset References: <200303070630.h276U7302165@above.proper.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2003 15:15:43.0110 (UTC) FILETIME=[6BAA4260:01C2E4BC] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ralph.Patterson@lan-aces.com wrote: >The original spec (RFC2445) required that the fidelity of the iCalendar >object be maintained even after all of the MIME information was stripped >off. > Can you cite a section, please? -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |"We can't duplicate the bug." "Have you tried the Xerox machine?"| \=================================================================/ From owner-ietf-calendar@mail.imc.org Sat Mar 8 02:04:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24033 for ; Sat, 8 Mar 2003 02:04:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h286qLq06208 for ietf-calendar-bks; Fri, 7 Mar 2003 22:52:21 -0800 (PST) Received: from mail.lan-aces.com (mail.lan-aces.com [65.17.118.66]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h286qK306204 for ; Fri, 7 Mar 2003 22:52:20 -0800 (PST) Message-Id: <200303080652.h286qK306204@above.proper.com> Received: from [65.17.118.66] (Ralph.Patterson@LAN-ACES.COM) by Office-Logic InterChange; Sat, 08 Mar 2003 00:52:22 -0600 Date: Sat, 08 Mar 2003 00:53:36 -0600 From: Ralph.Patterson@lan-aces.com To: John Stracke cc: "ietf-calendar@imc.org" Subject: cc: Re: Charset X-Mailer: Office-Logic/Win32 7.12 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-disposition: inline Content-transfer-encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would suggest: 4 iCalendar Object Specification The following sections define the details of a Calendaring and Scheduling Core Object Specification. This information is intended to be an integral part of the MIME content type registration. In addition, this information can be used independent of such content registration. ******** In particular, this memo has direct applicability for use as a calendaring and scheduling exchange format in file-, memory- or network-based transport mechanisms. ******** We wouldn't maintain the MIME wrapper for file-, memory, or network-based transports AND "can be used independent of such content" --RP On the CHARSET issue... Doesn't this suggest the use of UTF-8 for the objects? 4.1 Content Lines ... NON-US-ASCII = %x80-F8 ; Use restricted by charset parameter ; on outer MIME object (UTF-8 preferred) ... ********** Non-US-ASCII was specifically restricted to OUTER MIME objects only (UTF-8 preferred) -- RP 4.1.4 Character Set There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is UTF-8 as defined in [RFC 2279]. The "charset" Content-Type parameter can be used in MIME transports to specify any other IANA registered character set. ********** the CHARSET can be used in MIME transports -- not iCalendar object -- RP I would have to look at the rest but these are a couple of quick references. Regards, Ralph Patterson On Friday, March 07, 2003 9:15 AM, John Stracke wrote: > >Date: Fri, 07 Mar 2003 10:15:42 -0500 >From: John Stracke >To: "ietf-calendar@imc.org" >Subject: Re: Charset > >Ralph.Patterson@lan-aces.com wrote: > >>The original spec (RFC2445) required that the fidelity of the iCalendar >>object be maintained even after all of the MIME information was stripped >>off. >> >Can you cite a section, please? > >-- >/=================================================================\ >|John Stracke |jstracke@centive.com | >|Principal Engineer|http://www.centive.com | >|Centive |My opinions are my own. | >|=================================================================| >|"We can't duplicate the bug." "Have you tried the Xerox machine?"| >\=================================================================/ > > From owner-ietf-calendar@mail.imc.org Sat Mar 8 20:34:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28711 for ; Sat, 8 Mar 2003 20:34:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h291Pq719098 for ietf-calendar-bks; Sat, 8 Mar 2003 17:25:52 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h291Pp319092 for ; Sat, 8 Mar 2003 17:25:51 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h291Pn1W012035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 8 Mar 2003 17:25:52 -0800 Message-ID: <3E6A9817.1090800@Royer.com> Date: Sat, 08 Mar 2003 18:25:43 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: cc: Re: Charset References: <200303080652.h286qK306204@above.proper.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030004090705020307010601" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030004090705020307010601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think the issues here is that none of the RFCs mandate how the data is to be stored by the application. They talk about interoperability, not implementation. So it is working as specified and as you sited in your reply. We have defined how to transport 2445 objects using e-mail and now CAP. And the 2445 objects can be used in small devices and it will never matter to any RFC how the small devices store the 2445 objects. When small devices export a 2445 object they will take what ever their internal format and charset, then send e-mail or use CAP. If the small device uses another transport then it is ether going to be some future proposed protocol or a proprietary protocol. No one has proposed any other transport or protocol so I SEE that as covering all of the issues. Ralph.Patterson@lan-aces.com wrote: > I would suggest: > ... > Ralph Patterson > > On Friday, March 07, 2003 9:15 AM, John Stracke wrote: > >>Date: Fri, 07 Mar 2003 10:15:42 -0500 >>From: John Stracke >>To: "ietf-calendar@imc.org" >>Subject: Re: Charset >> >>Ralph.Patterson@lan-aces.com wrote: >> >> >>>The original spec (RFC2445) required that the fidelity of the iCalendar >>>object be maintained even after all of the MIME information was stripped >>>off. >>> >> >>Can you cite a section, please? Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030004090705020307010601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDkwMTI1NDRaMCMGCSqGSIb3DQEJBDEWBBS9 enio2TNDpo4UZzhvr5yCwiXfFzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAQdQ1iW7P0TBe QDIckMGcXUlCXHm5DAIpbXoAL1xMy2iEZzb5rjid/z1rqfk8TbQ45KoPiSqKwcCJF0XDc7uW GSif0PQm7XEWsBxyRhZhiQzSsG9ra7zttfsXFYe5UXrbfhhKUoY9BME1aBYy0tTKsc5QIDTC Z+NBlQnSbFU7V3nu/MjY/K1j41njvbFPUk2io16QrWE0yEps7le7FoCdYEufp3CbtAXbPtsm 2uV40oUaUkt76dcROjHEXQPmdRJtHMmL9VqRofQ3BDSHSNgOSmtFYF9Vde9H28l3zKZN3AK7 mDDTUs3oxMEPlO1hhNCNXESQnmxFhEaHRhjJCAtr8wAAAAAAAA== --------------ms030004090705020307010601-- From owner-ietf-calendar@mail.imc.org Mon Mar 10 09:07:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22745 for ; Mon, 10 Mar 2003 09:07:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ADtOg06414 for ietf-calendar-bks; Mon, 10 Mar 2003 05:55:24 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ADtN306410 for ; Mon, 10 Mar 2003 05:55:23 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 38004155BE; Mon, 10 Mar 2003 14:55:16 +0100 (CET) Date: Mon, 10 Mar 2003 14:55:15 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: REPLY to SEARCH [Was: CAP 10: CREATE Command and ordering of responses.] Message-ID: <20030310135515.GC79630@inet.it> References: <20030131080258.GA44085@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry for not answering before, I'm really busy at the moment and I can't give the topics we are discussing the attention the deserve. However, I think I should at least answer this one. On Tue, Feb 18, 2003 at 05:43:05PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > > Uhm yes sorry I overlooked that (maybe because SEARCH doesn't behave > like > > that: all commands return one match per VREPLY, apart from SEARCH where > > it's not clear); but I think I got it right in the code ;-) > > Please point out the unclearness in the draft so we can fix that! Clarity > good, uncertainty bad!! In 10.8 we have this text: The data in each result contains an iCalendar object composed of all the selected components enclosed in a "VREPLY" component. First of all, I'm not sure this text is ok because SEARCH can select "things" which are not components - and this sentence should be changed to reflect that. Apart from this, and assuming a query like SELECT * FROM VEVENT WHERE ...., am I right in assuming I'll get back all selected VEVENT inside one VREPLY (inside one VCALENDAR per target/method, as usual)? That is BEGIN:VCALENDAR BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT BEGIN:VEVENT ... END:VEVENT END:VREPLY END:VCALENDAR and not: BEGIN:VCALENDAR BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT END:VREPLY BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT END:VREPLY END:VCALENDAR I was just wondering whether this is intentional, given that this is different from all commands (except GENERATE-UID). Above all, this doesn't sound very useful when used with queries like SELECT UID,ATTENDEE FROM VEVENT WHERE ... If I'm just misunderstanding, then I think that sentence must be clarified. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - 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 Mar 10 12:22:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04350 for ; Mon, 10 Mar 2003 12:22:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AHBsJ17219 for ietf-calendar-bks; Mon, 10 Mar 2003 09:11:54 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AHBr317215 for ; Mon, 10 Mar 2003 09:11:53 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2AHBn1W017547 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Mar 2003 09:11:53 -0800 Message-ID: <3E6CC74F.8020406@Royer.com> Date: Mon, 10 Mar 2003 10:11:43 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: REPLY to SEARCH [Was: CAP 10: CREATE Command and ordering of responses.] References: <20030131080258.GA44085@inet.it> <20030310135515.GC79630@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000001080107080809010609" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000001080107080809010609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > ... > In 10.8 we have this text: > > The data in each result contains an iCalendar object composed of all > the selected components enclosed in a "VREPLY" component. > > ... > > First of all, I'm not sure this text is ok because SEARCH can select > "things" which are not components - and this sentence should be changed > to reflect that. > ... Correct and thanks - I changed the text to be: The data in each result set contains one or more iCalendar components composed of all the selected results enclosed in a single "VREPLY" component per "QUERY". Only "REQUEST-STATUS" property and the properties mentioned in the "SELECT" clause of the QUERY are included in the components. Each "VCALENDAR" component is tagged with the "TARGET" property. > Apart from this, and assuming a query like SELECT * FROM VEVENT WHERE ...., > am I right in assuming I'll get back all selected VEVENT inside one VREPLY > (inside one VCALENDAR per target/method, as usual)? That is > ... I updated the reply text of the example that matched the text you quoted above from CAP to be: Here the request was successful, however one of the "VEVENT" components contents were not accessible (4.1). S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR S: TARGET:relcalid S: CMD:REPLY S: VERSION:2.0 S: PRODID:-//someone's prodid S: BEGIN:VREPLY S: BEGIN:VEVENT S: REQUEST-STATUS:4.1 S: END:VEVENT S: BEGIN:VEVENT S: REQUEST-STATUS:2.0 S: UID:123 S: DTEND:19990310T080000Z S: DSTART:19990310T190000Z S: SUMMARY: Big meeting S: END:VEVENT S: END:VREPLY S: END:VCALENDAR -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000001080107080809010609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTAxNzExNDRaMCMGCSqGSIb3DQEJBDEWBBTH S4iFpZdhKYYMxJ0/6Ld6+B8GcTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEARvx5YJUUSVF3 ZsyOtOaqkXow7bMm4+CnrCHFpwkYhbTLq07bk66vtQLRbTGUAcwCQwSB3RTpt7/lKDjQW4T4 ueAaPWzrbvqzy+A5nllkoeANzP8uo/62m2ySRx1qlVTTP0MA/YuyGeNNkfwUY3zoag/SPayr +/vEO9LlZub/Ekuv6oUYR33mDQVpTuCjkpWHKmJndQvgI+TK1IWWktJVvlg6dmWnPcfFXgVE 6lZE1vr2bat3x/PXTsWRfu20oTe53if1h75AqBnJh5gQMBuDFhuDu6+SYqgHqcH2g2DZ9XB3 MAKRvatYujXsBRBEkvoBJopnBxrkSmyO1t67kozfVQAAAAAAAA== --------------ms000001080107080809010609-- From owner-ietf-calendar@mail.imc.org Mon Mar 10 12:33:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04716 for ; Mon, 10 Mar 2003 12:33:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AHN3c18059 for ietf-calendar-bks; Mon, 10 Mar 2003 09:23:03 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AHN2318055 for ; Mon, 10 Mar 2003 09:23:02 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2AHMw1W017631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Mar 2003 09:23:02 -0800 Message-ID: <3E6CC9EC.4060404@Royer.com> Date: Mon, 10 Mar 2003 10:22:52 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: Partial equality match and sort order Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010408050500020607070203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010408050500020607070203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I was reading another WG document this weekend and noticed that we did not include a description of the sort order when two or more results were a partial match of each other. I would like to add to cap: When determining which object to return first on sorted results when two or more results partially match each other, the shorter match will be returned first. If the following: SELECT SUMMARY FROM VEVENT WHERE ... returned two matches: SUMMARY:ABC SUMMARY:ABCD The "VEVENT" component that had the "SUMMARY" property value of "ABC" must be returned before the longer "ABCD" result. I really do not care if the longer or shorter one is returned first - I just picked one. Any objections? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010408050500020607070203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTAxNzIyNTJaMCMGCSqGSIb3DQEJBDEWBBS/ DzWHTd2bNh4cOIoDepYwFyZTJzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYD7nIfNiX4Ot G1D14NKGcUtDMo0u8V4ngqpnaJV1Y6JUeE3lhQs1LxWA9jIL7rL36BBFX+rh48a3sCDeZt5k PT7iE3S/BplSdNRaNXdpSq34GYvEED09cETq2KGmmllhUYMe12/MCVlSx+m5njHTu//Rkq0W 5iCI5Y6mf7GTugwA8usEvzhlUezS44etGf77jM2Vk2JeF094B7ZcnkZlV32dyZT8aebBvpPC h+Xcnd1IYdfWsMX5T8q1ROo/3c033qCSnJsIRkcCINZ+IdAoNsJB9aFjuozp8mbjBjiwjZOm 9RaOtgBdgcw9vqnjLIoRKoLCE4bhO3apnbEYXDmNBwAAAAAAAA== --------------ms010408050500020607070203-- From owner-ietf-calendar@mail.imc.org Mon Mar 10 13:27:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06804 for ; Mon, 10 Mar 2003 13:27:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AIFLh19914 for ietf-calendar-bks; Mon, 10 Mar 2003 10:15:21 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2AIFJ319910 for ; Mon, 10 Mar 2003 10:15:19 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031013184218253 for ; Mon, 10 Mar 2003 13:18:42 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 13:12:58 -0500 Message-ID: <3E6CD5A9.4040309@centive.com> Date: Mon, 10 Mar 2003 13:12:57 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: <3E6CC9EC.4060404@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2003 18:12:58.0049 (UTC) FILETIME=[ADD26B10:01C2E730] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > I was reading another WG document this weekend and noticed that we > did not include a description of the sort order when two or > more results were a partial match of each other. I'm not sure what this means. The word "partial" doesn't appear in draft 10; are you talking about queries using LIKE? Why would the sort order depend on the nature of the query? The draft defines the sort order as depending on the order in which the columns are listed; I assume that means listed in the cap-cols production, which makes it independent of the query. > SUMMARY:ABC > SUMMARY:ABCD Why wouldn't you just use the ordinary string sort for the locale, as specified in 6.1.1.6? -- /==============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==============================================================| |Until you stalk and overrun, you can't devour anyone. --Hobbes| \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 10 14:13:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08819 for ; Mon, 10 Mar 2003 14:13:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AJ56g22511 for ietf-calendar-bks; Mon, 10 Mar 2003 11:05:06 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJ55322507 for ; Mon, 10 Mar 2003 11:05:05 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2AJ531W018388 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Mar 2003 11:05:06 -0800 Message-ID: <3E6CE1D9.4090108@Royer.com> Date: Mon, 10 Mar 2003 12:04:57 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: <3E6CC9EC.4060404@Royer.com> <3E6CD5A9.4040309@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070106000405020001060003" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070106000405020001060003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> I was reading another WG document this weekend and noticed that we >> did not include a description of the sort order when two or >> more results were a partial match of each other. > > > I'm not sure what this means. The word "partial" doesn't appear in > draft 10; Which is my proposal - to add it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070106000405020001060003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTAxOTA0NTdaMCMGCSqGSIb3DQEJBDEWBBTu MONowS2jn4MzWrTIzG2L8toUgzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAtecCs1GWaVDz OU8s4Uj830KgSMnJST25oN0d8GsEFHKBZVSBrovFvWGAxfqCZ1T3pBHX8d+CO1UzYtSTo4au BqUS7J+IvhyeJglzZX14T+eTJ1+Ngd+uIgRqh0WjSpCeVxBxfXhfNhqT70BY1r1hRhrED5uC n/2ULOiYDXvILBYGGJhwGXVvGElfJHLevN3qNjMBUrOuKZU0DCgRvgV2kd0hlujzCt7G5LqC tkMkQENF/cjn2ahwTnZn9T+BAopgbMfSSRGknnDnwvRDlUvok5NkRNNe74Mfa0MdocyioYtF EK/AOnPstoPDozIwfu9xo5d5OfAf9iUZRfCrveRtEAAAAAAAAA== --------------ms070106000405020001060003-- From owner-ietf-calendar@mail.imc.org Mon Mar 10 14:15:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08935 for ; Mon, 10 Mar 2003 14:15:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AJ6Ot22537 for ietf-calendar-bks; Mon, 10 Mar 2003 11:06:24 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJ6N322533 for ; Mon, 10 Mar 2003 11:06:23 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2AJ6L1W018407 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Mar 2003 11:06:24 -0800 Message-ID: <3E6CE227.1070705@Royer.com> Date: Mon, 10 Mar 2003 12:06:15 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: <3E6CC9EC.4060404@Royer.com> <3E6CD5A9.4040309@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030802000102030403020101" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030802000102030403020101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Why wouldn't you just use the ordinary string sort for the locale, as > specified in 6.1.1.6? Does locale sort ordering solve it? I thought that partial match sorts were unspecified? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030802000102030403020101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTAxOTA2MTZaMCMGCSqGSIb3DQEJBDEWBBQT hL+racV0JGoKXmE8zeUwSicdYTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAN5az19Ynbar+ Ixp0+4/1n+NYtxFHpHtlGDbTHwEtoo0fj2XSubXpYTs9Zi/O2kOdM7zjLkxlHJA1iGBXhN7s kJ+LvAtbY2gEMHu8al2ZayRUQEC9oLRULUMHQaamj4Ht+MCL1l3aHtTtphoQehCK6fjmN30e X57452tuUePnrmAK9fqpt5AKkgc31SeiykTV2VoQ51nwGBctzW+3N4L5cDg/nVHIt28/KCxh fiO5cz7k2RsMYe/vWyfuBjeG/YALu9dxFJvsa5kk0kY1/cm17uIbfOEPhbCLv55YDNPq4DZ0 6p6X2Ni3VC2zwWQqtiDQ5/BBejzj8M4ZcbxNOCrIuQAAAAAAAA== --------------ms030802000102030403020101-- From owner-ietf-calendar@mail.imc.org Mon Mar 10 14:52:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10370 for ; Mon, 10 Mar 2003 14:52:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AJboE24311 for ietf-calendar-bks; Mon, 10 Mar 2003 11:37:50 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2AJbn324307 for ; Mon, 10 Mar 2003 11:37:49 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031014412217835 for ; Mon, 10 Mar 2003 14:41:22 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Mar 2003 14:35:37 -0500 Message-ID: <3E6CE909.9000603@centive.com> Date: Mon, 10 Mar 2003 14:35:37 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: <3E6CC9EC.4060404@Royer.com> <3E6CD5A9.4040309@centive.com> <3E6CE227.1070705@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2003 19:35:37.0935 (UTC) FILETIME=[3A24F5F0:01C2E73C] 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: > >> Why wouldn't you just use the ordinary string sort for the locale, as >> specified in 6.1.1.6? > > Does locale sort ordering solve it? I thought that partial match > sorts were unspecified? What are partial matches? -- /==============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==============================================================| |All I ask is a chance to prove that money can't make me happy.| \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 10 20:30:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23272 for ; Mon, 10 Mar 2003 20:30:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B1Kba11092 for ietf-calendar-bks; Mon, 10 Mar 2003 17:20:37 -0800 (PST) Received: from bikini.cac.washington.edu (bikini.cac.washington.edu [128.95.135.104]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B1Ka311088 for ; Mon, 10 Mar 2003 17:20:36 -0800 (PST) Received: (from slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) id h2B1OI504273; Mon, 10 Mar 2003 17:24:18 -0800 (PST) Date: Mon, 10 Mar 2003 17:24:18 -0800 (PST) Message-Id: <200303110124.h2B1OI504273@bikini.cac.washington.edu> To: ietf-calendar@imc.org Subject: java beep packages From: slh@cac.washington.edu Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [attempting to send this again, as it seemed to have not gotten to the list last time.] recommendations for java beep packages (for use with cap)? looked some or a lot at each of following. simplebeep: does not look like any recent activity on this project quite a few installation prerequisites beep4j: does not look like any recent activity on this project permabeep: seems to have no sasl profiles but does include a mime library (assumably could be used independent of the beep support) beepcore: includes sasl anonymous and otp (whatever exactly those are) may be simpler to use than permabeep, but not as flexible? seems to require 1.4+ (java.util.logging). are there better choices? beepcore seems the most likely. thanks in advance. From owner-ietf-calendar@mail.imc.org Mon Mar 10 21:31:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24547 for ; Mon, 10 Mar 2003 21:31:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B2Nlk13243 for ietf-calendar-bks; Mon, 10 Mar 2003 18:23:47 -0800 (PST) Received: from bikini.cac.washington.edu (bikini.cac.washington.edu [128.95.135.104]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B2Nj313238 for ; Mon, 10 Mar 2003 18:23:46 -0800 (PST) Received: (from slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) id h2B2RSM04415 for ietf-calendar@imc.org; Mon, 10 Mar 2003 18:27:28 -0800 (PST) Date: Mon, 10 Mar 2003 18:27:28 -0800 (PST) Message-Id: <200303110227.h2B2RSM04415@bikini.cac.washington.edu> To: ietf-calendar@imc.org Subject: cap-10 section 1. comments From: slh@cac.washington.edu Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: below are some suggested changes for section 1. of the cap-10 draft. most of it is very minor (as minor as an extra space...). I believe there is nothing reguarding the actual function of the spec. reading it properly depends on mail not reformatting the text and text being displayed in a fixed-width font, so I am not sure how well it will come across. the numbers in [] at the beginning of each are the page and line numbers. I think the markup is obvious, but: X under text indicates it should be deleted ^ under text indicates an insertion point (insert before) followed by the new text - under text indicates it should be changed (w/a specific substitution) followed by the new text or a comment/question * under text indicates what is specifically being commented on followed by a comment in () 
----------------------------------------
[6;286]

   This document specifies how a Calendar CUA interacts with a CS to
                                 XXXXXXXXX
----------------------------------------
[6;305]

   The definition of new components, properties, parameter's, and value
                                                          X
   types are broken into two parts.  The first part summarizes and
   defined the new objects.  The second part provides the detail and any
         -s
   ABNF for those objects.
----------------------------------------
[7;362]

   Within a query, the different parts are referred to as a "clause" and
   its value as "clause value" and the clause name will be in uppercase
   enclosed in quotes.  Example, The "SELECT" clause or if the "SELECT"
                        ***********************************************
   clause value contains ...
   *************************
(
this sentence seems inconsistant with the other like sentences and
does not seem constructed properly...
)
----------------------------------------
[9;459]

   Calendar Access Rights (VCAR) -  The mechanism for specifying the CAP
      operations ("PERMISSION") that a particular calendar user ("UPN")
      is granted or denied permission to perform on a given calendar
      object ("SCOPE").  The calendar access rights are specified with a
      "VCAR" component.  (Section 9.3.
                                     ^)
----------------------------------------
[9;482]

   Properties -  An attribute of a particular component.  Some
      properties are applicable to  different types of components.  For
                                   X
      example, the "DTSTART" property is applicable to the "VEVENT",
      "VTODO", and "VJOURNAL" components.  Other components are
                                                 ----------properties
      applicable only to an individual type of calendar component.  For
      example, the "TZURL" property may only be applicable to the
                                    ---is
      "VTIMEZONE" components.
----------------------------------------
[10;538]

   CAP Session -  An open communication channel between a CUA and a CS.
      If the CAP session is authenticated, the CU is "authenticated" and
                                          ^ then
      it is an "authenticated CAP session".

   Contained Component / Contained Properties -  A component or property
                                          ---y
      that is contained inside of another component.  A "VALARM"
      component for example may be contained inside of a "VEVENT"
      component.  And a "TRIGGER" property could be a contained property
      of a "VALARM" component.
----------------------------------------
[11;593]

   Owner -  One or more CUs or UGs that are listed in the "OWNER"
      property in a calendar.  There can be more than one owner.  The "
                                                                *******
(
spurious or missing text
)
----------------------------------------
From owner-ietf-calendar@mail.imc.org Tue Mar 11 10:26:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23551 for ; Tue, 11 Mar 2003 10:26:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFGRu11619 for ietf-calendar-bks; Tue, 11 Mar 2003 07:16:27 -0800 (PST) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFGQ311615 for ; Tue, 11 Mar 2003 07:16:26 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 11 Mar 2003 15:14:12 +0000 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 18slPS-00010a-00; Tue, 11 Mar 2003 15:11:18 +0000 Date: Tue, 11 Mar 2003 15:11:18 +0000 (GMT) From: Libby Miller X-X-Sender: ecemm@mail.ilrt.bris.ac.uk To: Mark Swanson cc: John Stracke , ietf-calendar Subject: Re: Is Apple creating invalid iCalendar? In-Reply-To: <200301221504.41813.mark@WebServiceSolutions.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark, did you get any reply to this? Libby On Wed, 22 Jan 2003, Mark Swanson wrote: > > On January 22, 2003 02:21 pm, John Stracke wrote: > > On Wed, 2003-01-22 at 00:07, Mark Swanson wrote: > > > > x-name may not be "VALUE" found above according to rfc2445: > > > > Then that's a bug in RFC-2445; obviously we want x-props to be able to > > use VALUE. > > I have found and misplaced several small lists of 2445 bugs over time. Does > anyone have a link to the definitive guide to: > > 1. rfc 2445 bugs > 2. rfc 2445 bugs that you must conform to if you want to interoperate :-) > > Thank you. > > -- > Schedule your world with ScheduleWorld.com > http://www.ScheduleWorld.com/ > Java Web Start: > http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp > > > > From owner-ietf-calendar@mail.imc.org Tue Mar 11 11:00:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24756 for ; Tue, 11 Mar 2003 11:00:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFm0d13487 for ietf-calendar-bks; Tue, 11 Mar 2003 07:48:00 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFlw313480 for ; Tue, 11 Mar 2003 07:47:58 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id A17674FCE; Tue, 11 Mar 2003 10:47:33 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: Libby Miller Subject: Re: errata Date: Tue, 11 Mar 2003 10:48:08 -0500 User-Agent: KMail/1.5 Cc: ietf-calendar References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303111048.08254.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On March 11, 2003 10:11 am, Libby Miller wrote: > Mark, did you get any reply to this? Patricia (pregen@egenconsulting.com) has stated she would put together the errata but I have not heard from her yet. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Tue Mar 11 11:18:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25537 for ; Tue, 11 Mar 2003 11:18:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFtfU14783 for ietf-calendar-bks; Tue, 11 Mar 2003 07:55:41 -0800 (PST) Received: from aretha.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFtf314778 for ; Tue, 11 Mar 2003 07:55:41 -0800 (PST) In-Reply-To: <3E6CC9EC.4060404@Royer.com> To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 11 Mar 2003 10:46:37 -0500 X-MIMETrack: Serialize by Router on Aretha/Iris(Build V602_02272003|February 27, 2003) at 03/11/2003 11:05:20 AM, Serialize complete at 03/11/2003 11:05:20 AM Content-Type: multipart/alternative; boundary="=_alternative 005773C105256CE6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005773C105256CE6_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 03/10/2003 12:22:52 PM: > I would like to add to cap: > > When determining which object to return first on sorted results > when two or more results partially match each other, the shorter > match will be returned first. If the following: > > SELECT SUMMARY FROM VEVENT WHERE ... > > returned two matches: > > SUMMARY:ABC > SUMMARY:ABCD > > The "VEVENT" component that had the "SUMMARY" property value of "ABC" > must be returned before the longer "ABCD" result. > > I really do not care if the longer or shorter one is returned > first - I just picked one. Any objections? I big time object. This just makes the CS have to cache up ALL matching objects/values to return before it can return ANY so that it can sort them based on some implyed sort order (the order of the SELECT). This makes bounded latency even worse! The CS should NOT have to cache ALL results before it can send back any results at all. The CS should be able to send back data as soon as it can thus allowing the data to flow back to the requestor as its available. My users are looking for better performance, not worse. 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 005773C105256CE6_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 03/10/2003 12:22:52 PM:
> I would like to add to cap:
>
>    When determining which object to return first on sorted results
>          when two or more results partially match each other, the shorter
>          match will be returned first. If the following:
>
>       SELECT SUMMARY FROM VEVENT WHERE ...
>
>    returned two matches:
>
>       SUMMARY:ABC
>       SUMMARY:ABCD
>
>          The "VEVENT" component that had the "SUMMARY" property value of "ABC"
>          must be returned before the longer "ABCD" result.
>
> I really do not care if the longer or shorter one is returned
> first - I just picked one. Any objections?
I big time object.  This just makes the CS have to cache up ALL matching objects/values to return before it can return ANY so that it can sort them based on some implyed sort order (the order of the SELECT).  This makes bounded latency even worse!

The CS should NOT have to cache ALL results before it can send back any results at all.  The CS should be able to send back data as soon as it can thus allowing the data to flow back to the requestor as its available.  My users are looking for better performance, not worse.

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 005773C105256CE6_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 11 11:46:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26925 for ; Tue, 11 Mar 2003 11:46:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BGbrq17727 for ietf-calendar-bks; Tue, 11 Mar 2003 08:37:53 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2BGbp317722 for ; Tue, 11 Mar 2003 08:37:52 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031111412427285 for ; Tue, 11 Mar 2003 11:41:24 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 11:35:39 -0500 Message-ID: <3E6E105B.8070400@centive.com> Date: Tue, 11 Mar 2003 11:35:39 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2003 16:35:39.0783 (UTC) FILETIME=[405B7970:01C2E7EC] 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: > I big time object. This just makes the CS have to cache up ALL > matching objects/values to return before it can return ANY so that it > can sort them based on some implyed sort order (the order of the > SELECT). This makes bounded latency even worse! True. We've been over this before, though I don't remember the discussion well enough to know why we settled on sorting. My take is that sorting is like any other CPU-intensive operation: if you want the system to scale, you need to push it to the edges. -- /========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |========================================================| |Diplomacy: The art of letting someone else have your way| \========================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 11 12:22:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28646 for ; Tue, 11 Mar 2003 12:22:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BHCqZ22752 for ietf-calendar-bks; Tue, 11 Mar 2003 09:12:52 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BHCo322738 for ; Tue, 11 Mar 2003 09:12:50 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2BHCl1W027938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 11 Mar 2003 09:12:50 -0800 Message-ID: <3E6E190A.8050301@Royer.com> Date: Tue, 11 Mar 2003 10:12:42 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-pessi-ical-isip-01.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020303020702090402080805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020303020702090402080805 Content-Type: multipart/mixed; boundary="------------020203080706000303070304" This is a multi-part message in MIME format. --------------020203080706000303070304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I just noticed this e-mail on the IETF-general list. -------- Original Message -------- Subject: I-D ACTION:draft-pessi-ical-isip-01.txt Date: Tue, 11 Mar 2003 06:46:22 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : iCalendar SIP-Based Interoperability Protocol Author(s) : P. Pessi, M. Mela Filename : draft-pessi-ical-isip-01.txt Pages : 13 Date : 2003-3-10 This document, proposes a binding from the abstract iCalendar Transport-independent Interoperability Protocol (iTIP) using Session Initiation Protocol (SIP) as transport and SIP/SIPS URIs as addresses. This document proposes using the iTIP objects as a MIME payload format with SIP. iTIP is an abstract transport protocol for exchanging calendaring information between calendar systems using the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC 2445. SIP is a application-layer signaling protocol for creating, modifying, and terminating multimedia sessions, retrieving user presence and sending instant messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pessi-ical-isip-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pessi-ical-isip-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pessi-ical-isip-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------020203080706000303070304 Content-Type: Message/External-body; name="draft-pessi-ical-isip-01.txt" Content-Disposition: inline; filename="draft-pessi-ical-isip-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-3-11070415.I-D@ietf.org> --------------020203080706000303070304-- --------------ms020303020702090402080805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTExNzEyNDJaMCMGCSqGSIb3DQEJBDEWBBS1 QhKninqWRBFZTlG1l6MX9Y8KdzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYe6ypQArLTdX TpVtMdDehQ7gycwpWV6W3nxvOoIN/417pfWobmiiYylogABtLs5cqBQ44kA4qo+F57nSwNZG TqgxmvDS2s1y5Zu8Q21ekyrGUNU86zo9jvPYP+O+cS+LBGHQr0c0d0NKQSasX0Lsu8GpSQos qVwTSQf/Eg/jDXj70ur8ak8jMPwrgObuBON1kDoQ+ecoYYbVFPsNUxanTZF3jF8nXFoaC2b/ EGxzjxYGRM3wwHnrtBRZs++/akwLX5TMnb46Xt6QOeQV6dImOMFYP4Ov0Pca02ftmgIsZJXn Ve4qmlbjVmhu/pX3c9jHeqK+82dEbvbsUqE8hjYAAAAAAAAAAA== --------------ms020303020702090402080805-- From owner-ietf-calendar@mail.imc.org Tue Mar 11 12:23:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28664 for ; Tue, 11 Mar 2003 12:23:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BHAQp22299 for ietf-calendar-bks; Tue, 11 Mar 2003 09:10:26 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BHAO322292 for ; Tue, 11 Mar 2003 09:10:24 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2BHAL1W027929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 11 Mar 2003 09:10:24 -0800 Message-ID: <3E6E1877.5090804@Royer.com> Date: Tue, 11 Mar 2003 10:10:15 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080909000105040707090506" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080909000105040707090506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 03/10/2003 12:22:52 PM: > > I would like to add to cap: > > > > When determining which object to return first on sorted results > > when two or more results partially match each other, the shorter > > match will be returned first. If the following: > > > > SELECT SUMMARY FROM VEVENT WHERE ... > > > > returned two matches: > > > > SUMMARY:ABC > > SUMMARY:ABCD > > > > The "VEVENT" component that had the "SUMMARY" property value > of "ABC" > > must be returned before the longer "ABCD" result. > > > > I really do not care if the longer or shorter one is returned > > first - I just picked one. Any objections? > > I big time object. This just makes the CS have to cache up ALL matching > objects/values to return before it can return ANY so that it can sort > them based on some implyed sort order (the order of the SELECT). This > makes bounded latency even worse! What do you do with the other items that must be sorted that is any different? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080909000105040707090506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTExNzEwMTVaMCMGCSqGSIb3DQEJBDEWBBQy w3eavM27YnhBnGQqBONO07wMcjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEACNl/ovXle+Qe ScLCjz4qTzDxeQRN9wp6cNjcORmYLiz+f2JBhb85M3p5C/h1CLL/p3oa2WsiKErHIfDw45wU LsL/GnGBWScrJpbIz3tUbQYDAQu+MeZwoEn7P4XYAOn+N2hA9NHdn2ItdueVDKUz6z+cl5vJ d1co6EFCoL8rixz1jgRfRaJMYSp9CrU+iY/T5+k0gQ6l4VjApfx+oPLsapnhj7ctmSJHaCT2 ccu2wNLofz0J95/csfdFPWm+tOx0UdISNkrJBDg8lXNl+ZZsyLhjGG8gHaRnscqKZpWWf/ek 40rPTuY5B5D5nqe6RCAMQVvG9J7toOy6i8spOJ58VAAAAAAAAA== --------------ms080909000105040707090506-- From owner-ietf-calendar@mail.imc.org Tue Mar 11 12:26:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28736 for ; Tue, 11 Mar 2003 12:26:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BHJkT23220 for ietf-calendar-bks; Tue, 11 Mar 2003 09:19:46 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BHJj323215 for ; Tue, 11 Mar 2003 09:19:46 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id B4F9D155BD; Tue, 11 Mar 2003 18:19:39 +0100 (CET) Date: Tue, 11 Mar 2003 18:19:39 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order Message-ID: <20030311171939.GG79630@inet.it> References: <3E6CC9EC.4060404@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Bruce, On Tue, Mar 11, 2003 at 10:46:37AM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > I big time object. This just makes the CS have to cache up ALL matching > objects/values to return before it can return ANY so that it can sort them > based on some implyed sort order (the order of the SELECT). This makes > bounded latency even worse! > The CS should NOT have to cache ALL results before it can send back any > results at all. The CS should be able to send back data as soon as it can > thus allowing the data to flow back to the requestor as its available. My > users are looking for better performance, not worse. just so that I'm sure I understand your POV: are you objecting to Doug's proposal or are you objecting to sorting in general? Sorting is still in the draft and I don't recall anybody objecting to it in recent times at least (read, last year). My opinion is that sorting is irrelevant and badly specified anyway [1]; I agree with John that sorting should be done at the client. Bye, Andrea [1] the draft says the results are sorted depending on the order in which columns appear in the query. This means the rather common SELECT * ... has no specified order. -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - 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 Mar 11 15:21:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10609 for ; Tue, 11 Mar 2003 15:21:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BK8be03958 for ietf-calendar-bks; Tue, 11 Mar 2003 12:08:37 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BK8a303953 for ; Tue, 11 Mar 2003 12:08:36 -0800 (PST) In-Reply-To: <20030311171939.GG79630@inet.it> To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 11 Mar 2003 15:08:34 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/11/2003 03:08:37 PM, Serialize complete at 03/11/2003 03:08:37 PM Content-Type: multipart/alternative; boundary="=_alternative 006E99CE85256CE6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E99CE85256CE6_= Content-Type: text/plain; charset="US-ASCII" Andrea Campi wrote on 03/11/2003 12:19:39 PM: > just so that I'm sure I understand your POV: are you objecting to > Doug's proposal or are you objecting to sorting in general? Sorting > is still in the draft and I don't recall anybody objecting to it in > recent times at least (read, last year). Sorting is in the latest draft as you noted. However it was was added to Draft 08 (so sometime between March 2002 and June 2002). It was (is!?) an issue before and I honestly do not recall reaching a concensus on it nor do I have cycles to research it. It was originally added to Draft 08 as just: 6.1.1.6 Ordering of Results Sorting will take place in the order the columns are supplied in the QUERY command. and is now covered in 2 sections in Draft 10: 6.1.1.6. Ordering of Results Sorting will take place in the order the columns are supplied in the QUERY command. The CS MUST sort at least the first column. The CS MAY sort additional columns. and 6.1.1.7. Date sorting order If EXPAND=FALSE sorting will be by the "DTSTART" property value ascending as if it were in UTC. If EXPAND=TRUE sorting will be by the "RECURRENCE-ID" property value ascending as if it were in UTC. I have an aversion to having the sorting requirement as stated as it precludes ANY ablity to send results back to the requestor as they are found. I think that having the CS "sort all results alphabetically (or reverse) based on SUMMARY and then DESCRIPTION [and then by LOCATION...]" is not necessarily all that useful. Sorting based on the order of the SELECT clause is something that the UI really wants, NOT that CAP itself needs IMHO. Sorting is more of a rendering concern than a protocol concern really. > My opinion is that sorting is irrelevant and badly specified anyway [1]; > I agree with John that sorting should be done at the client. Make that 3 votes for sorting in the client rather than in the CS. (If my MUA can insertion sort mail that arrives out of order in my Inbox, why cant my CUA?) 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 006E99CE85256CE6_= Content-Type: text/html; charset="US-ASCII"
Andrea Campi <a.campi@inet.it> wrote on 03/11/2003 12:19:39 PM:
> just so that I'm sure I understand your POV: are you objecting to
> Doug's proposal or are you objecting to sorting in general? Sorting
> is still in the draft and I don't recall anybody objecting to it in
> recent times at least (read, last year).
Sorting is in the latest draft as you noted.  However it was was added to Draft 08 (so sometime between March 2002 and June 2002).  It was (is!?) an issue before and I honestly do not recall reaching a concensus on it nor do I have cycles to research it.  

It was originally added to Draft 08 as just:

6.1.1.6 Ordering of Results

  Sorting will take place in the order the columns are supplied in the
  QUERY command.

and is now covered in 2 sections in Draft 10:

6.1.1.6.  Ordering of Results
    Sorting will take place in the order the columns are supplied in the QUERY command. The CS MUST sort at least the first column. The CS MAY sort additional columns.

and

6.1.1.7.  Date sorting order

    If EXPAND=FALSE sorting will be by the "DTSTART" property value ascending as if it were in UTC.
     If EXPAND=TRUE sorting will be by the "RECURRENCE-ID" property value ascending as if it were in UTC.

I have an aversion to having the sorting requirement as stated as it precludes ANY ablity to send results back to the requestor as they are found.

I think that having the CS "sort all results alphabetically (or reverse) based on SUMMARY and then DESCRIPTION [and then by LOCATION...]" is not necessarily all that useful.  Sorting based on the order of the SELECT clause is something that the UI really wants, NOT that CAP itself needs IMHO.  Sorting is more of a rendering concern than a protocol concern really.

> My opinion is that sorting is irrelevant and badly specified anyway [1];
> I agree with John that sorting should be done at the client.
Make that 3 votes for sorting in the client rather than in the CS.  (If my MUA can insertion sort mail that arrives out of order in my Inbox, why cant my CUA?)

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 006E99CE85256CE6_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 11 16:26:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12871 for ; Tue, 11 Mar 2003 16:26:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BLDI508754 for ietf-calendar-bks; Tue, 11 Mar 2003 13:13:18 -0800 (PST) Received: from bikini.cac.washington.edu (bikini.cac.washington.edu [128.95.135.104]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BLDH308750 for ; Tue, 11 Mar 2003 13:13:17 -0800 (PST) Received: from localhost (slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) with ESMTP id h2BLGxN05340 for ; Tue, 11 Mar 2003 13:16:59 -0800 (PST) Date: Tue, 11 Mar 2003 13:16:59 -0800 From: slh@bikini.cac.washington.edu To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: could the sort be specified in the query (as in ORDER BY ... ASCENDING/DESCENDING)? sorting would then only be done if and as desired. or was that already discussed and rejected? From owner-ietf-calendar@mail.imc.org Wed Mar 12 00:51:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27316 for ; Wed, 12 Mar 2003 00:51:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2C5b4d26988 for ietf-calendar-bks; Tue, 11 Mar 2003 21:37:04 -0800 (PST) Received: from bikini.cac.washington.edu (bikini.cac.washington.edu [128.95.135.104]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C5b3326984 for ; Tue, 11 Mar 2003 21:37:03 -0800 (PST) Received: (from slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) id h2C5emd05832 for ietf-calendar@imc.org; Tue, 11 Mar 2003 21:40:48 -0800 (PST) Date: Tue, 11 Mar 2003 21:40:48 -0800 (PST) Message-Id: <200303120540.h2C5emd05832@bikini.cac.washington.edu> To: ietf-calendar@imc.org Subject: cap-10 section 2. comments From: slh@cac.washington.edu Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: below are some suggested changes to and questions about section 2. of the cap-10 draft. a lot of it is minor text fixes or possible abnf problems. but I also have some questions about some of the abnf. I believe there is nothing reguarding the actual function of the spec. (same format as my previous msg about section 1.). 
----------------------------------------
[13;707]

    other-props  = *(x-prop) *(iana-prop) *(x-prop)
    ***********************************************
[
does this give anything more than:
	other-props  = *(x-prop / iana-prop)
would (which seems simpler and more straight-forward)?
or maybe better yet:
	other-props  = *(other-prop)
	other-prop   = x-prop / iana-prop
and then usually using other-prop and
only using other-props when necessary and non-redundant?
]
----------------------------------------
[14;757]

   alarmseqparams = other-params [";" local-param] other-params
                    *******************************************
[
is this construct different than usual
just because, due to the single (non other-param) parameter,
the syntax can be expressed w/o qualifications in comments?
the usual construct is a repeating list of alternatives w/comments
indicating the allowable number of occurrences of each.
]

                  ; Where DIGIT is defined in [iCAL]
                  ;
    posint0     = 1*DIGIT
    posint1     = posintfirst 1*DIGIT
    *********************************
[
this would make posint1 a 2+ digit number?
should it be:
	posint1     = posintfirst *DIGIT
?
]

                  ; A number starting with 1 through 9.
                  ;
    posintfirst = %x31-39

    other-params = *(";" xparam) *(";" iana-params) *(";" xparam)
    *************************************************************
[
similar comment to other-props...
]
----------------------------------------
[15;795]

   trigger    = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs)
                          ********************
[
should this be able to occur multiple times or just be optional?
]
----------------------------------------
[15;822]

   ENABLE -  The "ENABLE" parameter in CAP is used to tag a "TRIGGER"
      property in a component as disabled or enabled.  (Section 7.2).
                                                       **************
[
it seems constructs like ``(Section 7.2)''
should either all or none be followed by a period
(I do not know which is more correct,
 but it seems it should all be done the same)
]

   ID -  The "ID" parameter specifies a unique identifier to be used for
      any outstanding commands.
                               ^  (Section 7.3).
----------------------------------------
[16;844]

      in error and warning messages.
                                    ^  (Section 7.6).

   OPTIONS -  The "OPTIONS" parameter passes optional information for
      the command being sent.
                             ^  (Section 7.7).

   SEQUENCE -  When the "SEQUENCE" parameter is used in a "VALARM"
                                   ---------property
      component it uniquely identifies the instances of the "VALARM"
      within a component.
                         ^  (Section 8.?).
   *****************************************************************
[
this paragraph should be in the subsection 2.1.2 since it is a property.
there does not seem to be a subsection in section 8. for SEQUENCE.
]
----------------------------------------
[16;856]

   ALLOW-CONFLICT -  Some entries in a calendar might not be valid if
      other entries were allowed to overlap the same time span.
      (Section 8.1)
   ******************************************************************
[
is this the way this should be summarized?
]
----------------------------------------
[17;939]
   OWNER -  Each calendar has at least one "OWNER" property.  (xref
                                                              *****
      target="OWNER"/>) Related to the "CAL-OWNERS()" (Section 6.1.1.1)
      *****************************************************************
      query clause.
      *************
[
looks like something happened in the rendering of this sentence?
]

   PERMISSION -  This property specifies the permission being granted or
      denied.  Examples are the "SEARCH" and "MODIFY" values.  (Section
      8.25)

   QUERY -  Used to hold the CAL-QUERY (Section 8.26) for the component.
                                       XXXXXXXXXXXXXXX                  ^  (Section 8.25)
----------------------------------------
[18;985]

   TARGET -  The new "VCALENDAR" component property "TARGET" (Section
                                                             XXXXXXXX
      8.36) is used to specify which calendar(s) will be the subject of
      XXXXXX
      the CAP command.
                      ^(Section 8.36)
[
to be consistent with the other paragraphs
]
----------------------------------------
[20;1104]

   There MUST NOT BE more than one "BOOKED" state object in a calendar
   for the same "UID".  The "ADD" method value may create multiple
                                         XXXXXX
   objects all in the "BOOKED" state for the same UID, however for the
   purpose of this memo, they are the same object that simply have
   multiple "VCALENDAR" components.
----------------------------------------
From owner-ietf-calendar@mail.imc.org Wed Mar 12 11:34:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10329 for ; Wed, 12 Mar 2003 11:34:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CGKjF20150 for ietf-calendar-bks; Wed, 12 Mar 2003 08:20:45 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CGKi320146 for ; Wed, 12 Mar 2003 08:20:44 -0800 (PST) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 12 Mar 2003 11:20:41 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/12/2003 11:20:38 AM, Serialize complete at 03/12/2003 11:20:38 AM Content-Type: multipart/alternative; boundary="=_alternative 0059B81285256CE7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059B81285256CE7_= Content-Type: text/plain; charset="US-ASCII" I wrote on 03/11/2003 03:08:34 PM: > However it was was > added to Draft 08 (so sometime between March 2002 and June 2002). Last night that kinda felt odd so I did another check this AM and found that it was actually added into Draft 03 which was Dec 2000. I have to blame user error in trusting MSIE to search the archives on Dougs site for this (after all searching for "sort" should find any hits). Time to use Opera again... In briefly going back to the archives I see that we had no real meaty discussion on adding sorting so some of the more heated discussions must have been at an IETF meeting. The effort appears to have been triggered by Mark Pattersons discussion of ordering of results but in the context of the CAP requirements doc, not acutally in CAP discussions. In any case since there are previously expressed concerns by both John Strack (ie: locale) and Andrea (ie: The '*') case as well as my own dealing with the impact to bounded latency I think some cycles need to be put into a better solution or we should remove the implicit sorting entirely. I for one though have far fewer cycles to spare these days on CAP so I cannot offer any text now. I can suggest we take the KISS approach and simplify the design for CAP 1.0 and remove the sorting entirely. After all it was Doug who originally (1999) wanted to take this approach if I recall correctly... 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 0059B81285256CE7_= Content-Type: text/html; charset="US-ASCII"
I wrote on 03/11/2003 03:08:34 PM:
>                                                However it was was
> added to Draft 08 (so sometime between March 2002 and June 2002).  
Last night that kinda felt odd so I did another check this AM and found that it was actually added into Draft 03 which was Dec 2000.  I have to blame user error in trusting MSIE to search the archives on Dougs site for this (after all searching for "sort" should find any hits).  Time to use Opera again...  

In briefly going back to the archives I see that we had no real meaty discussion on adding sorting so some of the more heated discussions must have been at an IETF meeting.  The effort appears to have been triggered by Mark Pattersons discussion of ordering of results but in the context of the CAP requirements doc, not acutally in CAP discussions.

In any case since there are previously expressed concerns by both John Strack (ie: locale) and Andrea (ie: The '*') case as well as my own dealing with the impact to bounded latency I think some cycles need to be put into a better solution or we should remove the implicit sorting entirely.  I for one though have far fewer cycles to spare these days on CAP so I cannot offer any text now.  I can suggest we take the KISS approach and simplify the design for CAP 1.0 and remove the sorting entirely.  After all it was Doug who originally (1999) wanted to take this approach if I recall correctly...

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 0059B81285256CE7_=-- From owner-ietf-calendar@mail.imc.org Wed Mar 12 12:27:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12321 for ; Wed, 12 Mar 2003 12:27:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CH6QH22182 for ietf-calendar-bks; Wed, 12 Mar 2003 09:06:26 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CH6P322175 for ; Wed, 12 Mar 2003 09:06:25 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2CH6G1W006265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 12 Mar 2003 09:06:25 -0800 Message-ID: <3E6F6902.30105@Royer.com> Date: Wed, 12 Mar 2003 10:06:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070801000402000200050503" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070801000402000200050503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > I wrote on 03/11/2003 03:08:34 PM: > > However it was was > > added to Draft 08 (so sometime between March 2002 and June 2002). > > Last night that kinda felt odd so I did another check this AM and found > that it was actually added into Draft 03 which was Dec 2000. ... > > In briefly going back to the archives I see that we had no real meaty > discussion on adding sorting so some of the more heated discussions must > have been at an IETF meeting. So you are saying that just because you were busy (or for what ever reason) and did not wish to participate in that discussion that it does not count (as meaty)? Sorry - it was discussed and you elected not to particapte for what ever reason. It is time to close CAP and ship it. > The effort appears to have been triggered > by Mark Pattersons discussion of ordering of results but in the context > of the CAP requirements doc, not acutally in CAP discussions. I am confused - you site Mark Pattersons discussion of ordering (which IS on the list) and yet declare there was not a CAP discussion? Explain what a discussion is if that is not it? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070801000402000200050503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTIxNzA2MTBaMCMGCSqGSIb3DQEJBDEWBBQU LxZ+d6Dt93pshGaz+u2uqCcWJjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAl3FGHo8ZPxuc +HrXpaLEQnuWDk+6uKGRcGBeb0cYj7bS6bFn1qbnX68xMzjrva7d8oV1FDt+y9ApmI4Yk6v7 1kdDImprzpZCQ+t8CmHSrrgnWB93stfD77EOBHcShRoBe4sAG05XJmb2QJu2wGW4mfL6R1tH SwzAWKBlVgxwsYGqzLZpb6KoCl5v8cM0D+s8mEBZSojweFqzGuBESRTAVAZeeoy5Xcpy+Hfw sNjnMs9jWXaxrXErnRdjsWbvbjZPvGiUrOmrrudFRQlnNq2xMqG19ltQ54XurAENEzNwWS65 RIj5P09uOxYb/jQleVlxOej8ZQkUxn/m5r/r5BNdUQAAAAAAAA== --------------ms070801000402000200050503-- From owner-ietf-calendar@mail.imc.org Wed Mar 12 12:54:14 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13628 for ; Wed, 12 Mar 2003 12:54:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CHa4F24120 for ietf-calendar-bks; Wed, 12 Mar 2003 09:36:04 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHa2324116 for ; Wed, 12 Mar 2003 09:36:02 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2CHZx1W006452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 12 Mar 2003 09:36:03 -0800 Message-ID: <3E6F6FFA.2000707@Royer.com> Date: Wed, 12 Mar 2003 10:35:54 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040501010006020003000104" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040501010006020003000104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > I wrote on 03/11/2003 03:08:34 PM: > > However it was was > > added to Draft 08 (so sometime between March 2002 and June 2002). > > Last night that kinda felt odd so I did another check this AM and found > that it was actually added into Draft 03 which was Dec 2000. I have to > blame user error in trusting MSIE to search the archives on Dougs site > for this (after all searching for "sort" should find any hits). Time to > use Opera again... It was in CAP-00, draft-ietf-calsch-cap-00.txt dated August 5, 1999 : orderby = As some did not want SQL, this was changed into explicit sorting as the debate went forward. It has been in CAP for years. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040501010006020003000104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTIxNzM1NTRaMCMGCSqGSIb3DQEJBDEWBBQ5 AcnIdvlWynGTQis7IPPw3o0dDzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAboAUlbD2VCCi 5g1xZItV/IQrAR2afBTyOrQItxtT8/JYMqglfNGkIbOgQl4uo/KIcjhR1eEdnrVAq+vrs2KR Zykx4RkRygpxXV45D32E1BSYekxQKCXG+uwiZDxdL2bA+cNslM/jsmTU+i7HLHRHUSa9/e23 CrRu1pnU/FBgncoqFLcdE8iqlyCoaMdrvdPvg1ALnAL5EZcAGkHDZNZv4uvyBTQPV2tcuSjO PwLASMc1XdtDWQYYYG/gsFztagAIPxoU9L/pLRS5vsB7bUENQiV/C+c30ztUfv3GNa9+kEiz qOqTO+6fCHLIbRnU3igqt1Zm8+DfNcP0OVFSnP8iMgAAAAAAAA== --------------ms040501010006020003000104-- From owner-ietf-calendar@mail.imc.org Wed Mar 12 12:57:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13784 for ; Wed, 12 Mar 2003 12:57:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CHZVp24108 for ietf-calendar-bks; Wed, 12 Mar 2003 09:35:31 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHZT324104 for ; Wed, 12 Mar 2003 09:35:30 -0800 (PST) Subject: CAP Last call??? To: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Mar 2003 12:35:26 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/12/2003 12:35:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been watching the exchange of emails and many of them are bringing up old topics. At this point, I'd like to propose a last call on CAP. Guys, we need to get something out there for vendors to try to implement. It's only at that point that we really find out what does or does not work. We are NEVER going to have a perfect solution. At this point, I'll take a "mediocre" solution - because at least it's something. So, that being said, I am formally proposing a last call on CAP. All those violently opposed please respond to the list with specific reasons why you are opposed. Also, respond to the list if you are in favor of a last call. We can't do HMMMMs on the list - but we can do electronic "thumbs up". Those will work as well. We'll talk more about this at the IETF meeting in SFO. If you can not be there, try using the Jabber method to participate. From owner-ietf-calendar@mail.imc.org Wed Mar 12 14:59:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18553 for ; Wed, 12 Mar 2003 14:59:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CJmCo02356 for ietf-calendar-bks; Wed, 12 Mar 2003 11:48:12 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2CJmA302343 for ; Wed, 12 Mar 2003 11:48:11 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031214513631628 for ; Wed, 12 Mar 2003 14:51:36 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Mar 2003 14:45:51 -0500 Message-ID: <3E6F8E6F.3060704@centive.com> Date: Wed, 12 Mar 2003 14:45:51 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Last call??? References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2003 19:45:51.0516 (UTC) FILETIME=[FCB17DC0:01C2E8CF] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: >So, that being >said, I am formally proposing a last call on CAP. All those violently >opposed please respond to the list with specific reasons why you are >opposed. > I am opposed to including sorting. Server-side sorting: * Will increase CPU and buffering requirements on the server, which will hurt scalability. * Will increase latency. * Will not be of substantial benefit to clients. Server-side sorting has been advocated as being helpful for resource-constrained clients such as PDAs; but, realistically, a client that cannot afford to sort a set of events is going to have difficulty displaying that set. o There is one narrow set of clients which are an exception here: Web-based CUAs. Some simple UIs can be rendered more efficiently if the application can stream data down from the CS, transform each event it sees into HTML, and then discard the event without buffering; if the stream from the CS is not ordered, then it must be buffered and sorted. o However, this is less of a constraint than it seems. Normally, in a large-scale Web-based application, there are many Web servers and few database servers (or, in this case, few CAP servers); if the sorting has to be done, it should be done in the Web servers, to spread out the cost of sorting. (Scalability again: it's normally cheaper to buy 10 boxes with, say, 2 GIPS and 2G RAM apiece than to buy 1 box with 10 GIPS and 10G RAM.) * Will actually increase costs for some constrained clients, such as wireless devices where connect time is charged by the minute. Increased latency means increased connect time, after all. I realize that we've gone over this before; but, if Doug's dates are correct, then this is stuff I learned after we discussed it last, while building eCal's second-generation product. -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |"There is also plenty of marine life in the Virgin Islands, | |although due to poor planning it is located underwater." -- Dave| |Barry | \================================================================/ From owner-ietf-calendar@mail.imc.org Wed Mar 12 16:52:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24870 for ; Wed, 12 Mar 2003 16:52:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CLhMG07556 for ietf-calendar-bks; Wed, 12 Mar 2003 13:43:22 -0800 (PST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CLhL307552 for ; Wed, 12 Mar 2003 13:43:21 -0800 (PST) Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.3) with ESMTP id h2CLhJ613580 for ; Wed, 12 Mar 2003 13:43:19 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2CLhI213563 for ; Wed, 12 Mar 2003 13:43:18 -0800 (PST) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2CLhGq27188 for ; Wed, 12 Mar 2003 14:43:16 -0700 (MST) Received: from c-patrice.ca.oracle.com (c-patrice.ca.oracle.com [144.23.213.233]) by rgmgw1.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2CLhDV27115 for ; Wed, 12 Mar 2003 14:43:13 -0700 (MST) Subject: Re: Partial equality match and sort order From: Patrice Lapierre To: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1047505910.4849.175.camel@c-patrice.ca.oracle.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Mar 2003 16:51:50 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 2003-03-11 at 15:08, Bruce_Kahn@notesdev.ibm.com wrote: > > Make that 3 votes for sorting in the client rather than in the CS. > (If my MUA can insertion sort mail that arrives out of order in my > Inbox, why cant my CUA?) > Make that 4 votes. Interested parties can look at the archive: http://www.imc.org/ietf-calendar/mail-archive/msg03435.html -- Patrice. From owner-ietf-calendar@mail.imc.org Wed Mar 12 17:50:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27098 for ; Wed, 12 Mar 2003 17:50:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CMahP12798 for ietf-calendar-bks; Wed, 12 Mar 2003 14:36:43 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CMaf312784 for ; Wed, 12 Mar 2003 14:36:41 -0800 (PST) Subject: Re: Partial equality match and sort order To: Patrice Lapierre Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Mar 2003 17:36:28 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/12/2003 05:36:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ONe of the best ways I know to shake out bugs and fruit from a tree is to ask for a Last call. And, for the first time in a long time, we seem to have concensus on something. Be still my heart. I am now hearing 4 people say removing sorting to the client and out of the CS is a good thing. Sorry, Doug, but that does indeed stand as concensus and not even rough. Now, that being said, is this hard to do and does it break something else. If so, maybe we can get some help from those who are arguing to have it removed. 5 pair of eyes looking at the draft to remove this would really help a lot. 8-) ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Patrice Lapierre cc: Sent by: Subject: Re: Partial equality match and sort order owner-ietf-calendar@m ail.imc.org 03/12/03 04:51 PM On Tue, 2003-03-11 at 15:08, Bruce_Kahn@notesdev.ibm.com wrote: > > Make that 3 votes for sorting in the client rather than in the CS. > (If my MUA can insertion sort mail that arrives out of order in my > Inbox, why cant my CUA?) > Make that 4 votes. Interested parties can look at the archive: http://www.imc.org/ietf-calendar/mail-archive/msg03435.html -- Patrice. From owner-ietf-calendar@mail.imc.org Wed Mar 12 18:30:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29757 for ; Wed, 12 Mar 2003 18:30:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CNKio14140 for ietf-calendar-bks; Wed, 12 Mar 2003 15:20:44 -0800 (PST) Received: from eurekait.com (ns.eurekait.com [202.7.88.33]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CNKf314135 for ; Wed, 12 Mar 2003 15:20:42 -0800 (PST) Received: from laptop.eurekit.com (laptop [192.168.1.201]) by eurekait.com (Postfix) with ESMTP id C5ECB2B88E for ; Thu, 13 Mar 2003 10:32:12 +1100 (EST) Subject: Re: Partial equality match and sort order From: sfg To: ietf-calendar@imc.org In-Reply-To: <1047505910.4849.175.camel@c-patrice.ca.oracle.com> References: <1047505910.4849.175.camel@c-patrice.ca.oracle.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8-3mdk Date: 13 Mar 2003 10:20:41 +1100 Message-Id: <1047511241.1866.107.camel@laptop.eurekit.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 Thu, 2003-03-13 at 08:51, Patrice Lapierre wrote: > > On Tue, 2003-03-11 at 15:08, Bruce_Kahn@notesdev.ibm.com wrote: > > > > Make that 3 votes for sorting in the client rather than in the CS. > > (If my MUA can insertion sort mail that arrives out of order in my > > Inbox, why cant my CUA?) > > I vote against this. I've read the archives, I'm mainly a lurker with desires to build an Open Source CAP Server (http://www.sf.net/projects/jical) I would have thought ordering was a natural requirement of a server vs a client. Surely your data store can make these things easier via indexes etc. The comparison to an Inbox doesn't stack up. From reading the spec - CAP Servers are more like a specialised RDBMS. Imagine if your RDBMS did not support ORDER BY? An alternative would be to add the ORDERBY to capabilities so that the client can query and see if the server can/will handle ORDERBY. Stuart Guthrie vcard: http://www.eurekait.com/sfg.vcf OSS: http://www.sf.net/projects/jical From owner-ietf-calendar@mail.imc.org Wed Mar 12 19:40:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01542 for ; Wed, 12 Mar 2003 19:40:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D0RPL16203 for ietf-calendar-bks; Wed, 12 Mar 2003 16:27:25 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D0RO316199 for ; Wed, 12 Mar 2003 16:27:24 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2D0RN1W009829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 12 Mar 2003 16:27:26 -0800 Message-ID: <3E6FD065.3050301@Royer.com> Date: Wed, 12 Mar 2003 17:27:17 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: <1047505910.4849.175.camel@c-patrice.ca.oracle.com> <1047511241.1866.107.camel@laptop.eurekit.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040506020807060407080203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040506020807060407080203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit sfg wrote: > On Thu, 2003-03-13 at 08:51, Patrice Lapierre wrote: > >>On Tue, 2003-03-11 at 15:08, Bruce_Kahn@notesdev.ibm.com wrote: >> >>>Make that 3 votes for sorting in the client rather than in the CS. >>>(If my MUA can insertion sort mail that arrives out of order in my >>>Inbox, why cant my CUA?) >>> >> > > I vote against this. As do I. Would the others agree to a SORT capability? Where the default is "NONE"? Something like: SORT:none -> Any random order. SORT:SORT-1 -> As currently in CAP. This would cause less changes and debate than removing SORT completely and if we agreed then it is less change to CAP and allow us to ship CAP sooner? Comments? Thanks -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040506020807060407080203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTMwMDI3MTdaMCMGCSqGSIb3DQEJBDEWBBQ1 eGPvZwZmDYLTXnREbuNCNLXsaDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAFePDPaurf1rG 11RIk40/OP0jiX5DNJL0U0m2Dysk9U3XEFh5gOjjWZrGGYOHiueha/ssjojKUCSwiAGjDDo1 zISECxct47zvPxwTlKNAtZdZx3F3YH9ERYLfcQfswZuikBWLW6uXfQ9rvFS2fXZCf6jqxvhE KuPKkp/RWKGSR4W14agse9rGWy/9O6vXtke3RoqtzB2eCqtjd0DiFsfZa7pwcZ9tR8wKLsNL ZeV+bp21xfAzm8H4g7YOAt3LEkRmjxAauaG2ARdBb/IhbuyIk8XpBHYxZ4ENIh36eOFUwkEt EHvpXApaR5Mcp9bnF9aAL/aq6gF9jDRSRVPfeDDW1wAAAAAAAA== --------------ms040506020807060407080203-- From owner-ietf-calendar@mail.imc.org Wed Mar 12 20:20:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02616 for ; Wed, 12 Mar 2003 20:20:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D1D7R18387 for ietf-calendar-bks; Wed, 12 Mar 2003 17:13:07 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D1D5318377 for ; Wed, 12 Mar 2003 17:13:05 -0800 (PST) Subject: Re: Partial equality match and sort order To: sfg Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Mar 2003 20:13:07 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/12/2003 08:13:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: hm, the plot thickens. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 sfg To: ietf-calendar@imc.org Sent by: cc: owner-ietf-calendar@m Subject: Re: Partial equality match and sort order ail.imc.org 03/12/03 06:20 PM On Thu, 2003-03-13 at 08:51, Patrice Lapierre wrote: > > On Tue, 2003-03-11 at 15:08, Bruce_Kahn@notesdev.ibm.com wrote: > > > > Make that 3 votes for sorting in the client rather than in the CS. > > (If my MUA can insertion sort mail that arrives out of order in my > > Inbox, why cant my CUA?) > > I vote against this. I've read the archives, I'm mainly a lurker with desires to build an Open Source CAP Server (http://www.sf.net/projects/jical) I would have thought ordering was a natural requirement of a server vs a client. Surely your data store can make these things easier via indexes etc. The comparison to an Inbox doesn't stack up. From reading the spec - CAP Servers are more like a specialised RDBMS. Imagine if your RDBMS did not support ORDER BY? An alternative would be to add the ORDERBY to capabilities so that the client can query and see if the server can/will handle ORDERBY. Stuart Guthrie vcard: http://www.eurekait.com/sfg.vcf OSS: http://www.sf.net/projects/jical From owner-ietf-calendar@mail.imc.org Thu Mar 13 08:35:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00007 for ; Thu, 13 Mar 2003 08:35:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DDJmY09874 for ietf-calendar-bks; Thu, 13 Mar 2003 05:19:48 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2DDJl309868 for ; Thu, 13 Mar 2003 05:19:47 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031308201720271 for ; Thu, 13 Mar 2003 08:20:17 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 08:14:32 -0500 Message-ID: <3E708438.9050703@centive.com> Date: Thu, 13 Mar 2003 08:14:32 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order References: <1047505910.4849.175.camel@c-patrice.ca.oracle.com> <1047511241.1866.107.camel@laptop.eurekit.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2003 13:14:32.0893 (UTC) FILETIME=[7CC1AED0:01C2E962] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit sfg wrote: >On Thu, 2003-03-13 at 08:51, Patrice Lapierre wrote: > > >>On Tue, 2003-03-11 at 15:08, Bruce_Kahn@notesdev.ibm.com wrote: >> >> >>>Make that 3 votes for sorting in the client rather than in the CS. >>>(If my MUA can insertion sort mail that arrives out of order in my >>>Inbox, why cant my CUA?) >>> >>> >>> > >I vote against this. > (Remember, we don't vote.) >I would have thought ordering was a natural requirement of a server vs a >client. > Not really, no. Anything that can be done with equal ease on the server or on the client should be done on the client, because everything is more expensive on the server, where it has to be done many more times. >Surely your data store can make these things easier via indexes >etc. > Indices can make sorting more efficient; but it gets really expensive to maintain indices on every column, which is basically what would have to be done to meet this requirement. > The comparison to an Inbox doesn't stack up. From reading the spec >- CAP Servers are more like a specialised RDBMS. Imagine if your RDBMS >did not support ORDER BY? > That wouldn't be much of a problem, actually; I'd just sort in the client-side code. I use SQL pretty regularly these days, and I know of only two advantages for having ORDER BY in the language: (a) it's convenient for people writing queries by hand; (b) indices. (A) is not something we should be worrying about; (b) is expensive. (The big difference between indices for CAP and indices for a SQL database is that the schema of SQL databases tends to get customized to match the application; you can apply the indices that you think you're going to need. A CS can't do that, because it has to work with any CUA.) >An alternative would be to add the ORDERBY to >capabilities so that the client can query and see if the server can/will >handle ORDERBY. > > Not a good idea. The more optional features we have in the protocol, the harder it is for a client author to make sure their client can interoperate with every server. I mean, come on, guys. We're talking about *sorting* here. It's potentially CPU-intensive if you've got a huge dataset, but it's hardly a big deal to implement. Any sensible language will have a generic sorting feature in its standard library; even C has qsort(). If you're on a constrained device, you can put a limit on how many items you're going to sort, which will probably be pretty close to the number of items you can reasonably display; if you can't sort, you put up an error message or something. The tradeoffs to be made here depend on the UI, which means the decision should be made in the CUA. If the protocol specifies that the server has to sort, then it has no idea what the tradeoffs are. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"Chris is the most self-effacing guy I know." "Well, I'm not| |*that* good at it." | \============================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 13 14:31:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14206 for ; Thu, 13 Mar 2003 14:31:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DJEh002962 for ietf-calendar-bks; Thu, 13 Mar 2003 11:14:43 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DJEg302958 for ; Thu, 13 Mar 2003 11:14:42 -0800 (PST) In-Reply-To: <3E6F6902.30105@Royer.com> To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 13 Mar 2003 14:14:41 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/13/2003 02:14:28 PM, Serialize complete at 03/13/2003 02:14:28 PM Content-Type: multipart/alternative; boundary="=_alternative 0069AC3B85256CE8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069AC3B85256CE8_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 03/12/2003 12:06:10 PM: > So you are saying that just because you were busy (or for what ever > reason) and did not wish to participate in that discussion that it > does not count (as meaty)? Not quite. Ive been one of the most consistanly active folks in the WG since it was a BOF. There have been times when I was less than immediately responsive to postings (work pays the bills so it takes priority to the WG) but Ive always tried to keep up on the threads. I cannot think of anyone else whose had my record of consistant engagedment in this WG so dont try to make it sound like I was not engaged. Unless it was around the end game time of Notes R6 (~May - Sep 02) I've been involved in the discussion. > Sorry - it was discussed and you elected > not to particapte for what ever reason. It is time to close CAP > and ship it. I did a FT search of the archives for the word "sort" and there was NOT a big discussion of sorting as you would suggest. We did have some discussions on it and there was NOT the concensus you claim there is. In fact so far I hear only a concensus that it should NOT be in CAP. CAP has been drawn out over several years but I do not think we should just push it out the door because its taken so long. I have listed several issues in the past that have NOT been addressed and we still have some (ie: Stored VQUERYs, sorting, a LOGOUT command, signatures, multipart MIME, etc) that need to be addressed before we can attempt a Last Call. There are also the blank areas related to BEEP that have not yet been filled in for anyone to review. So I do not think CAP is ready for a Last Call yet. Once we "ship" CAP 1.0 we have to live with the warts it has if we (or some future effort) tries to fix up and extend CAP to include features too tough to get into CAP 1.0. I think we need to make sure the bigger warts are gone before we try to foist it off on folks and then sell products based on it. Otherwise CAP becomes a wasted protocol since its too buggy or kludgy to implement. > I am confused - you site Mark Pattersons discussion of ordering (which > IS on the list) and yet declare there was not a CAP discussion? Explain > what a discussion is if that is not it? Cant help your confusion any more than say go reread the archives. A FT search of the archives all the way back to the BOF days reveals 374 documents that contain the word 'sort'. This includes: 11 messages under this subject (excluding any traffic after my last msg) 8 messages under the CHARSET discussion recently 270+ messages sent during iCalendar/iTIP/iMIP (and cruft) development discussions. I kinda got lost after 280ish messages so Ill call it 270+ 80+ messages unrelated to actual sorting. Stuff like "intend to answer the sort of questions" or "I sort of was thinking...". or "going to work sort of " or "taxes out it's just sort " from Johns .sig. This rough check of 'sort' is ~369 messages. Deduct that from the 374 found and that leaves ~5 messages. That must have been a very meaty and engaging discussion and concensus building. Maybe it was done under the term "ORDERBY" and noone ever used the phrase "sort" (I guess its possible...). FYI: The Mark P. thread was ~29-Nov-2000 under the Subject "CAP requirements draft resubmitted". It only had ~8 msgs in that thread. I would not call that "meaty" either. Perhaps you do, I don't know. In any case so far I hear 4 votes against the sorting and 1 for it. The 300+ rest are abstentions. To me that sounds like rough concensus to remove it. 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 0069AC3B85256CE8_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 03/12/2003 12:06:10 PM:
> So you are saying that just because you were busy (or for what ever
> reason) and did not wish to participate in that discussion that it
> does not count (as meaty)?

Not quite.  

Ive been one of the most consistanly active folks in the WG since it was a BOF.  There have been times when I was less than immediately responsive to postings (work pays the bills so it takes priority to the WG) but Ive always tried to keep up on the threads.  I cannot think of anyone else whose had my record of consistant engagedment in this WG so dont try to make it sound like I was not engaged.  Unless it was around the end game time of Notes R6 (~May - Sep 02) I've been involved in the discussion.

>                                   Sorry - it was discussed and you elected
> not to particapte for what ever reason. It is time to close CAP
> and ship it.
I did a FT search of the archives for the word "sort" and there was NOT a big discussion of sorting as you would suggest.  We did have some discussions on it and there was NOT the concensus you claim there is.  In fact so far I hear only a concensus that it should NOT be in CAP.

CAP has been drawn out over several years but I do not think we should just push it out the door because its taken so long.  I have listed several issues in the past that have NOT been addressed and we still have some (ie: Stored VQUERYs, sorting, a LOGOUT command, signatures, multipart MIME, etc) that need to be addressed before we can attempt a Last Call.  There are also the blank areas related to BEEP that have not yet been filled in for anyone to review.  So I do not think CAP is ready for a Last Call yet.

Once we "ship" CAP 1.0 we have to live with the warts it has if we (or some future effort) tries to fix up and extend CAP to include features too tough to get into CAP 1.0.  I think we need to make sure the bigger warts are gone before we try to foist it off on folks and then sell products based on it.  Otherwise CAP becomes a wasted protocol since its too buggy or kludgy to implement.

> I am confused - you site Mark Pattersons discussion of ordering (which
> IS on the list) and yet declare there was not a CAP discussion? Explain
> what a discussion is if that is not it?
Cant help your confusion any more than say go reread the archives.  A FT search of the archives all the way back to the BOF days reveals 374 documents that contain the word 'sort'.  This includes:

11 messages under this subject (excluding any traffic after my last msg)
8 messages under the CHARSET discussion recently
270+ messages sent during iCalendar/iTIP/iMIP (and cruft) development discussions.  I kinda got lost after 280ish messages so Ill call it 270+
80+ messages unrelated to actual sorting.  Stuff like "intend to answer the sort of questions" or "I sort of was thinking...". or "going to work sort of " or  "taxes out it's just sort " from Johns .sig.

This rough check of 'sort' is ~369 messages.  Deduct that from the 374 found and that leaves ~5 messages.  That must have been a very meaty and engaging discussion and concensus building.  Maybe it was done under the term "ORDERBY" and noone ever used the phrase "sort" (I guess its possible...).

FYI: The Mark P. thread was ~29-Nov-2000 under the Subject "CAP requirements draft resubmitted".  It only had ~8 msgs in that thread.  I would not call that "meaty" either.  Perhaps you do, I don't know.

In any case so far I hear 4 votes against the sorting and 1 for it.  The 300+ rest are abstentions.  To me that sounds like rough concensus to remove it.

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 0069AC3B85256CE8_=-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 15:00:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15424 for ; Thu, 13 Mar 2003 15:00:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DJh2G03961 for ietf-calendar-bks; Thu, 13 Mar 2003 11:43:02 -0800 (PST) Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DJh1303956 for ; Thu, 13 Mar 2003 11:43:01 -0800 (PST) Received: (qmail 9232 invoked from network); 13 Mar 2003 19:42:57 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 13 Mar 2003 19:42:57 -0000 Subject: Re: Partial equality match and sort order From: Dan Winship To: ietf-calendar@imc.org In-Reply-To: <3E6FD065.3050301@Royer.com> References: <1047505910.4849.175.camel@c-patrice.ca.oracle.com> <1047511241.1866.107.camel@laptop.eurekit.com> <3E6FD065.3050301@Royer.com> Content-Type: text/plain Message-Id: <1047584700.26354.13.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.0.99 (Preview Release) Date: 13 Mar 2003 14:45:27 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wed, 2003-03-12 at 19:27, Doug Royer wrote: > Would the others agree to a SORT capability? Where the default is "NONE"? > Something like: > > SORT:none -> Any random order. > SORT:SORT-1 -> As currently in CAP. But then every client that cared about sorting would need to be able to do sorting itself in case it was talking to a SORT:none server. And if it has to have the code to do it sometimes, then why not do it all the time? -- Dan From owner-ietf-calendar@mail.imc.org Thu Mar 13 15:03:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15559 for ; Thu, 13 Mar 2003 15:03:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DJm2604196 for ietf-calendar-bks; Thu, 13 Mar 2003 11:48:02 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DJlu304191 for ; Thu, 13 Mar 2003 11:47:56 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DJpRF13318 for ; Thu, 13 Mar 2003 21:51:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 13 Mar 2003 21:47:57 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 21:47:56 +0200 Received: from localhost.localdomain (hedhc04nrc041-142.research.nokia.com [172.21.41.142]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id VAA11050 for ; Thu, 13 Mar 2003 21:47:56 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h2DJlden008725 for ; Thu, 13 Mar 2003 21:47:39 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h2DJld59008724; Thu, 13 Mar 2003 21:47:39 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: "ietf-calendar@imc.org" Subject: Re: [Fwd: I-D ACTION:draft-pessi-ical-isip-01.txt] X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3E6E190A.8050301@Royer.com> (Doug Royer's message of "Tue, 11 Mar 2003 10:12:42 -0700") References: <3E6E190A.8050301@Royer.com> Date: Thu, 13 Mar 2003 21:47:39 +0200 Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 13 Mar 2003 19:47:56.0945 (UTC) FILETIME=[71DE3010:01C2E999] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug Royer writes: >I just noticed this e-mail on the IETF-general list. I first received an automatic rejection reply, so I thought I'll have to send it again after cutoff period. Christmas seems to come twice this year. The document now recommends using the "text/calendar" format, and the examples have been converted to the iCal. There are a few open issues, most important I think is *what to do when a recipient cannot be reached immediately?* If delivery falls back to some other system than SIP, e.g., e-mail, what kind of addressing could be used? How a recipient can process and an iSIP message if it is received via non-SIP means? There is no applicability statement in the draft. Our main purpose here is to have off-line invitations to SIP conferences with standard format describing attendees and resources of SIP conferences. Unfortunately I've had no opportunity to dig in iRIP, so I really can't say for sure what makes iSIP radically different from iRIP. In my opinion, iSIP is just an alternative transport for iTIP with its own addresses. SIP is an existing transport, which propably will live and prosper on its own. iSIP is useful even if there is no real calendaring system available by SIP user-agents. It also helps to integrate the calendar and telephone applications in future mobile phones and PDAs. Pekka Pessi >-------- Original Message -------- >Subject: I-D ACTION:draft-pessi-ical-isip-01.txt >Date: Tue, 11 Mar 2003 06:46:22 -0500 >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >To: IETF-Announce: ; >A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : iCalendar SIP-Based Interoperability Protocol > Author(s) : P. Pessi, M. Mela > Filename : draft-pessi-ical-isip-01.txt > Pages : 13 > Date : 2003-3-10 >This document, proposes a binding from the abstract iCalendar >Transport-independent Interoperability Protocol (iTIP) using Session >Initiation Protocol (SIP) as transport and SIP/SIPS URIs as >addresses. This document proposes using the iTIP objects as a MIME >payload format with SIP. iTIP is an abstract transport protocol for >exchanging calendaring information between calendar systems using the >iCalendar, Internet Calendaring and Scheduling Core Object >Specification defined by RFC 2445. SIP is a application-layer >signaling protocol for creating, modifying, and terminating >multimedia sessions, retrieving user presence and sending instant >messages. >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-pessi-ical-isip-01.txt >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-pessi-ical-isip-01.txt". >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >Internet-Drafts can also be obtained by e-mail. >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-pessi-ical-isip-01.txt". >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. From owner-ietf-calendar@mail.imc.org Thu Mar 13 15:03:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15594 for ; Thu, 13 Mar 2003 15:03:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DJlqK04189 for ietf-calendar-bks; Thu, 13 Mar 2003 11:47:52 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DJlp304185 for ; Thu, 13 Mar 2003 11:47:51 -0800 (PST) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: CAP Last call??? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 13 Mar 2003 14:47:50 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/13/2003 02:47:35 PM, Serialize complete at 03/13/2003 02:47:35 PM Content-Type: multipart/alternative; boundary="=_alternative 006CB50B85256CE8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CB50B85256CE8_= Content-Type: text/plain; charset="US-ASCII" Pat wrote on 03/12/2003 12:35:26 PM: > I've been watching the exchange of emails and many of them are bringing up > old topics. Thats probably because we never reached concensus on some of them before moving on. I havent seen an updated CAP issues list in probably a year so its hard to tell if we've discussed them all and resolved them. The last reference to it I can find (not an actual WG posting) was by George B. back on 30-Jan-2002 under the heading "Updated CAP To Do and Issues List". Until we can say we've at least covered THOSE issues I think we cannot go to Last Call. > It's > only at that point that we really find out what does or does not work. We > are NEVER going to have a perfect solution. At this point, I'll take a > "mediocre" solution - because at least it's something. Id prefer a solution that while not perfect does not make fixing things in the future so Bisentine or impractical as to be nearly impossible. No protocol has been "perfect" out of the shoot (POP3 is 3rd revision, IMAP4rev1 is 4th revision, etc) but before we can push the baby out the door we need to make sure we dont have just danging holes in it or cruft that is not relevant / useful anymore. > All those violently > opposed please respond to the list with specific reasons why you are > opposed. We have unresolved issues that have not been declared as resolved: 1: Stored queries (no demonstrated usefulness for PDAs or 'fat' clients alike given our query language). 2: Sorting (see John's postings as far back as 2000 even). 3: The BEEP examples and registration profiles (ie: Section 12.1. BEEP Profile Registration of the Draft 10-17Feb2003) is not even filled in _let alone_ discussed at all in the WG. It is still "TBD" in the latest draft. 4: We have not made sure that any CAP issues that we overlooked have been addressed. Examples of this include those: A: Deletion vs 'marking for deletion". Its totally unclear what the disction is, what benefit 'marked for deletion" is and if it possible to undelete, etc. B: Multipart MIME support. There is no text or examples dealing with how multipart MIME should be properly dealt with in CAP. I had hoped we would have learned from iTIP interop testing but so far no... C: CAP preservation of IANA or X- properties/parameters, etc. Unlike iTIP where some properties are not guaranteed to be preserved by different implementations, CAP is how a CUA accesses a store so it SHOULD preserve everything. This is NOT clearly defined and proscribed for any CS. 5: We have made The last posted CAP issues list was dated 03/15/2001 12:45:39 PM by George B. There is an online one at the calsch web site that may or may not be insyc with that list and it has 25 unresolved issues on it with various assignments. Im sure some have to have been done by now but I say we update that list to make sure we cover them all. There are 'known issues' that we have decided to ignore for CAP 1.0 but they are NOT listed in any "Known Issues" section of CAP and they should be. It is MUCH better for us to say "Here are the areas we know are touchy and have decided to punt on. Implementations cover them at their own risk....". Better to acknowledge all the big cow patties than to pretend they are not there! > We'll talk more about this at the IETF meeting in SFO. > If you can not be there, try using the Jabber method to participate. I wont be in SFO and cannot make any promises about eAttendance. Last time I tired it did not even limp along. 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 006CB50B85256CE8_= Content-Type: text/html; charset="US-ASCII"
Pat wrote on 03/12/2003 12:35:26 PM:
> I've been watching the exchange of emails and many of them are bringing up
> old topics.  

Thats probably because we never reached concensus on some of them before moving on.

I havent seen an updated CAP issues list in probably a year so its hard to tell if we've discussed them all and resolved them.  The last reference to it I can find (not an actual WG posting) was by George B. back on 30-Jan-2002 under the heading "Updated CAP To Do and Issues List".  Until we can say we've at least covered THOSE issues I think we cannot go to Last Call.

>                                                                      It's
> only at that point that we really find out what does or does not work.  We
> are NEVER going to have a perfect solution.  At this point, I'll take a
> "mediocre" solution - because at least it's something.  

Id prefer a solution that while not perfect does not make fixing things in the future so Bisentine or impractical as to be nearly impossible.  No protocol has been "perfect" out of the shoot (POP3 is 3rd revision, IMAP4rev1 is 4th revision, etc) but before we can push the baby out the door we need to make sure we dont have just danging holes in it or cruft that is not relevant / useful anymore.

>                                                           All those violently
> opposed please respond to the list with specific reasons why you are
> opposed.  

We have unresolved issues that have not been declared as resolved:

1: Stored queries (no demonstrated usefulness for PDAs or 'fat' clients alike given our query language).
2: Sorting (see John's postings as far back as 2000 even).
3: The BEEP examples and registration profiles (ie: Section 12.1. BEEP Profile Registration  of the Draft 10-17Feb2003) is not even filled in _let alone_ discussed at all in the WG.  It is still "TBD" in the latest draft.
4: We have not made sure that any CAP issues that we overlooked have been addressed.  Examples of this include those:
        A: Deletion vs 'marking for deletion".  Its totally unclear what the disction is, what benefit 'marked for deletion" is and if it possible to undelete, etc.
        B: Multipart MIME support.  There is no text or examples dealing with how multipart MIME should be properly dealt with in CAP.  I had hoped we would have learned from iTIP interop testing but so far no...
        C: CAP preservation of IANA or X- properties/parameters, etc.  Unlike iTIP where some properties are not guaranteed to be preserved by different implementations, CAP is how a CUA accesses a store so it SHOULD preserve everything.  This is NOT clearly defined and proscribed for any CS.
5: We have made

The last posted CAP issues list was dated 03/15/2001 12:45:39 PM by George B.  There is an online one at the calsch web site that may or may not be insyc with that list and it has 25 unresolved issues on it with various assignments.  Im sure some have to have been done by now but I say we update that list to make sure we cover them all.

There are 'known issues' that we have decided to ignore for CAP 1.0 but they are NOT listed in any "Known Issues" section of CAP and they should be.  It is MUCH better for us to say "Here are the areas we know are touchy and have decided to punt on.  Implementations cover them at their own risk....".  Better to acknowledge all the big cow patties than to pretend they are not there!

>                We'll talk more about this at the IETF meeting in SFO.
> If you can not be there, try using the Jabber method to participate.
I wont be in SFO and cannot make any promises about eAttendance.  Last time I tired it did not even limp along.

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 006CB50B85256CE8_=-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 15:21:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17517 for ; Thu, 13 Mar 2003 15:21:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DK91S04754 for ietf-calendar-bks; Thu, 13 Mar 2003 12:09:01 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DK8x304750 for ; Thu, 13 Mar 2003 12:08:59 -0800 (PST) In-Reply-To: To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: Re: CAP Last call??? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 13 Mar 2003 15:08:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/13/2003 03:09:02 PM, Serialize complete at 03/13/2003 03:09:02 PM Content-Type: multipart/alternative; boundary="=_alternative 006EA45285256CE8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006EA45285256CE8_= Content-Type: text/plain; charset="US-ASCII" Pat wrote on 03/12/2003 12:35:26 PM: > All those violently > opposed please respond to the list with specific reasons why you are > opposed. Another issue from WAAAY back was the proliferation of top level Response Codes in CAP. From Section 10.11. Response Codes: Code Description -------------------------------------------------------------- 2.0 Success. The parameters vary with the operation and are specified. 2.0.3 In response to the client issuing an "abort" reply, this reply code indicates that any command currently underway was successfully aborted. 3.1.4 Capability not supported. 4.1 Calendar store access denied. 6.1 Container not found. 6.2 Attempt to create or modify an object such that it would overlap another object in either of the following two circumstances: (a) One of the objects has a TRANSP property set to OPAQUE-NOCONFLICT or TRANSPARENT-NOCONFLICT. (b) The calendar's ALLOW-CONFLICT property is set to FALSE. 6.3 Bad args. 6.4 Permission denied - VCAR restriction. A VCAR exists and the CS will not perform the operation. 7.0 A timeout has occurred. The server was unable to complete the operation in the requested time. 8.0 A failure has occurred in the CS that prevents the operation from succeeding. 8.1 A query was performed and the query is too complex for the CS. The operation was not performed. 8.2 Used to signal that an iCalendar object has exceeded the server's size limit 8.3 A DATETIME value was too far in the future represented on this Calendar. 8.4 A DATETIME value was too far in the past to be represented on this Calendar. 8.5 An attempt was made to create a new object but the unique UID specified is already in use. 9.0 An unrecognized command was received. Or an unsupported command was received. 10.4 The operation has not been performed because it would cause the resources (memory, disk, CPU, etc) to exceed the allocated quota. This adds 6, count 'em 6, new top level classes above and beyond the 4 defined in RFC 2445: |==============+===============================================| | Short Return | Longer Return Status Description | | Status Code | | |==============+===============================================| | 1.xx | Preliminary success. This class of status | | | of status code indicates that the request has | | | request has been initially processed but that | | | completion is pending. | |==============+===============================================| | 2.xx | Successful. This class of status code | | | indicates that the request was completed | | | successfuly. However, the exact status code | | | can indicate that a fallback has been taken. | |==============+===============================================| | 3.xx | Client Error. This class of status code | | | indicates that the request was not successful.| | | The error is the result of either a syntax or | | | a semantic error in the client formatted | | | request. Request should not be retried until | | | the condition in the request is corrected. | |==============+===============================================| | 4.xx | Scheduling Error. This class of status code | | | indicates that the request was not successful.| | | Some sort of error occurred within the | | | calendaring and scheduling service, not | | | directly related to the request itself. | |==============+===============================================| Nowhere can I find a description of these new top level classes and what they mean. (What the hell is a class 9x. response code good food for and how does it compare with a class 10.x or 8.x???). I have previously noted that there is NO 5.x description or class but that has somehow been overlooked. I have also noted that we have a 10.4 but no 10.0, 10.1, 10.2 or 10.3. Basically we need to take a cleanup pass over the new status codes to make sure we organzie them properly and cleanly. We should clearly define these new top level classes (ala RFC 2445) and possibly consolidate them down so we have a deeper response tree than a flatter one. After all that is why we defined the value to be hierarchical in the first place in iCalendar. 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 006EA45285256CE8_= Content-Type: text/html; charset="US-ASCII"
Pat wrote on 03/12/2003 12:35:26 PM:
>                                                All those violently
> opposed please respond to the list with specific reasons why you are
> opposed.  

Another issue from WAAAY back was the proliferation of top level Response Codes in CAP.  From Section 10.11. Response Codes:

    Code              Description
   --------------------------------------------------------------
   2.0               Success. The parameters vary with the
                     operation and are specified.

   2.0.3             In response to the client issuing an
                     "abort" reply, this reply code indicates
                     that any command currently underway was
                     successfully aborted.

   3.1.4             Capability not supported.

   4.1               Calendar store access denied.

   6.1               Container not found.

   6.2               Attempt to create or modify an object
                     such that it would overlap another object
                     in either of the following two circumstances:

                     (a) One of the objects has a TRANSP
                     property set to OPAQUE-NOCONFLICT or
                     TRANSPARENT-NOCONFLICT.

                     (b) The calendar's ALLOW-CONFLICT
                     property is set to FALSE.

   6.3               Bad args.

   6.4               Permission denied - VCAR restriction.
                     A VCAR exists and the CS will not perform
                     the operation.

   7.0               A timeout has occurred. The server was
                     unable to complete the operation in the
                     requested time.

   8.0               A failure has occurred in the CS
                     that prevents the operation from
                     succeeding.

   8.1               A query was performed and the query is
                     too complex for the CS. The operation
                     was not performed.

   8.2               Used to signal that an iCalendar object has
                     exceeded the server's size limit

   8.3               A DATETIME value was too far in the future
                     represented on this Calendar.

   8.4               A DATETIME value was too far in the past
                     to be represented on this Calendar.

   8.5               An attempt was made to create a new
                     object but the unique UID specified is
                     already in use.

   9.0               An unrecognized command was received.
                     Or an unsupported command was received.


   10.4              The operation has not been performed
                     because it would cause the resources
                     (memory, disk, CPU, etc) to exceed the
                     allocated quota.
This adds 6, count 'em 6, new top level classes above and beyond the 4 defined in RFC 2445:

     |==============+===============================================|
    | Short Return | Longer Return Status Description              |
    | Status Code  |                                               |
    |==============+===============================================|
    |    1.xx      | Preliminary success. This class of status     |
    |              | of status code indicates that the request has |
    |              | request has been initially processed but that |
    |              | completion is pending.                        |
    |==============+===============================================|
    |    2.xx      | Successful. This class of status code         |
    |              | indicates that the request was completed      |
    |              | successfuly. However, the exact status code   |
    |              | can indicate that a fallback has been taken.  |
    |==============+===============================================|
    |    3.xx      | Client Error. This class of status code       |
    |              | indicates that the request was not successful.|
    |              | The error is the result of either a syntax or |
    |              | a semantic error in the client formatted      |
    |              | request. Request should not be retried until  |
    |              | the condition in the request is corrected.    |
    |==============+===============================================|
    |    4.xx      | Scheduling Error. This class of status code   |
    |              | indicates that the request was not successful.|
    |              | Some sort of error occurred within the        |
    |              | calendaring and scheduling service, not       |
    |              | directly related to the request itself.       |
    |==============+===============================================|

Nowhere can I find a description of these new top level classes and what they mean. (What the hell is a class 9x. response code good food for and how does it compare with a class 10.x or 8.x???).  

I have previously noted that there is NO 5.x description or class but that has somehow been overlooked.  I have also noted that we have a 10.4 but no 10.0, 10.1, 10.2 or 10.3.  Basically we need to take a cleanup pass over the new status codes to make sure we organzie them properly and cleanly.

We should clearly define these new top level classes (ala RFC 2445) and possibly consolidate them down so we have a deeper response tree than a flatter one.  After all that is why we defined the value to be hierarchical in the first place in iCalendar.

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 006EA45285256CE8_=-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 15:41:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18306 for ; Thu, 13 Mar 2003 15:41:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DKSTF05574 for ietf-calendar-bks; Thu, 13 Mar 2003 12:28:29 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DKSS305570 for ; Thu, 13 Mar 2003 12:28:28 -0800 (PST) To: ietf-calendar@imc.org Cc: paf@cisco.com, ned+ietf-calendar@mrochek.com Subject: iSIP draft - ?? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 13 Mar 2003 15:28:28 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/13/2003 03:28:31 PM, Serialize complete at 03/13/2003 03:28:31 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have seen the following link posted as a new draft. http://www.ietf.org/internet-drafts/draft-pessi-calsch-isip-00.txt. Does anyone know about this? The draft says it's part of our working group - but I sure don't know about it. It really should not say it is associated with our group if it's never been discussed here. It can have a different title and be ok. But it should not say CALSCH WG if it's never been discussed in the group. So I'm checking here to see if anyone is aware of what this is. From owner-ietf-calendar@mail.imc.org Thu Mar 13 15:53:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18678 for ; Thu, 13 Mar 2003 15:53:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DKf5S06532 for ietf-calendar-bks; Thu, 13 Mar 2003 12:41:05 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DKf3306522 for ; Thu, 13 Mar 2003 12:41:03 -0800 (PST) To: Pekka Pessi Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: [Fwd: I-D ACTION:draft-pessi-ical-isip-01.txt] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 13 Mar 2003 15:41:05 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/13/2003 03:41:06 PM, Serialize complete at 03/13/2003 03:41:06 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Pekka. The document references that it is a CALSCH working group document. We've never seen it discussed here nor is it a part of our charter. Can you fill us in a little on what this is? I see why you think it is part of our WG - however, we sort of have to get permission from our Area Directors to add items to our charter. Pekka Pessi Sent by: owner-ietf-calendar@mail.imc.org 03/13/2003 14:47 To: "ietf-calendar@imc.org" cc: Subject: Re: [Fwd: I-D ACTION:draft-pessi-ical-isip-01.txt] Doug Royer writes: >I just noticed this e-mail on the IETF-general list. I first received an automatic rejection reply, so I thought I'll have to send it again after cutoff period. Christmas seems to come twice this year. The document now recommends using the "text/calendar" format, and the examples have been converted to the iCal. There are a few open issues, most important I think is *what to do when a recipient cannot be reached immediately?* If delivery falls back to some other system than SIP, e.g., e-mail, what kind of addressing could be used? How a recipient can process and an iSIP message if it is received via non-SIP means? There is no applicability statement in the draft. Our main purpose here is to have off-line invitations to SIP conferences with standard format describing attendees and resources of SIP conferences. Unfortunately I've had no opportunity to dig in iRIP, so I really can't say for sure what makes iSIP radically different from iRIP. In my opinion, iSIP is just an alternative transport for iTIP with its own addresses. SIP is an existing transport, which propably will live and prosper on its own. iSIP is useful even if there is no real calendaring system available by SIP user-agents. It also helps to integrate the calendar and telephone applications in future mobile phones and PDAs. Pekka Pessi >-------- Original Message -------- >Subject: I-D ACTION:draft-pessi-ical-isip-01.txt >Date: Tue, 11 Mar 2003 06:46:22 -0500 >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >To: IETF-Announce: ; >A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : iCalendar SIP-Based Interoperability Protocol > Author(s) : P. Pessi, M. Mela > Filename : draft-pessi-ical-isip-01.txt > Pages : 13 > Date : 2003-3-10 >This document, proposes a binding from the abstract iCalendar >Transport-independent Interoperability Protocol (iTIP) using Session >Initiation Protocol (SIP) as transport and SIP/SIPS URIs as >addresses. This document proposes using the iTIP objects as a MIME >payload format with SIP. iTIP is an abstract transport protocol for >exchanging calendaring information between calendar systems using the >iCalendar, Internet Calendaring and Scheduling Core Object >Specification defined by RFC 2445. SIP is a application-layer >signaling protocol for creating, modifying, and terminating >multimedia sessions, retrieving user presence and sending instant >messages. >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-pessi-ical-isip-01.txt >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-pessi-ical-isip-01.txt". >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >Internet-Drafts can also be obtained by e-mail. >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-pessi-ical-isip-01.txt". >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. From owner-ietf-calendar@mail.imc.org Thu Mar 13 16:57:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21035 for ; Thu, 13 Mar 2003 16:57:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DLjpn01405 for ietf-calendar-bks; Thu, 13 Mar 2003 13:45:51 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2DLjog01400 for ; Thu, 13 Mar 2003 13:45:50 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031316490203524 ; Thu, 13 Mar 2003 16:49:02 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 16:43:18 -0500 Message-ID: <3E70FB76.3040301@centive.com> Date: Thu, 13 Mar 2003 16:43:18 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pregen@egenconsulting.com CC: ietf-calendar@imc.org, paf@cisco.com, ned+ietf-calendar@mrochek.com Subject: Re: iSIP draft - ?? References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2003 21:43:18.0916 (UTC) FILETIME=[8FAF2440:01C2E9A9] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: >I have seen the following link posted as a new draft. http://www.ietf.org/internet-drafts/draft-pessi-calsch-isip-00.txt. > [...] >But it should not say CALSCH WG if it's >never been discussed in the group. > > The rule is only for things named "draft-ietf-calsch-", isn't it? It's unusual to see an individual submission named for a WG when it hasn't been discussed there, but it isn't forbidden. And this is related to calsch stuff. (Mind you, I don't like it much; it leaves too much stuff undefined, and its abstract seems overambitious. But that's another story.) -- /==============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==============================================================| |"Where's your sense of adventure?" "In front of a roaring fire| |with a cup of cocoa." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 13 17:57:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22733 for ; Thu, 13 Mar 2003 17:57:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DMnRS06672 for ietf-calendar-bks; Thu, 13 Mar 2003 14:49:27 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DMnQg06668 for ; Thu, 13 Mar 2003 14:49:26 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2DMnP1W019376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 13 Mar 2003 14:49:28 -0800 Message-ID: <3E710AF0.5080406@Royer.com> Date: Thu, 13 Mar 2003 15:49:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070209010607080203030008" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070209010607080203030008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Pat wrote on 03/12/2003 12:35:26 PM: > > All those violently > > opposed please respond to the list with specific reasons why you are > > opposed. > > Another issue from WAAAY back was the proliferation of top level > Response Codes in CAP. From Section 10.11. Response Codes: > ... So if you take the REQUEST-STATUS e-mail that I sent one or two weeks ago and add that into cap - does that solve *this* issue? It was a proposal on how to merge/fix/update the REQUEST-STATUS codes. I do not recall that you responded. I got NO negative feedback and some positive feedback. So I assume the rest of the WG felt it addressed those issues? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070209010607080203030008 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTMyMjQ5MjBaMCMGCSqGSIb3DQEJBDEWBBQ+ 8h4MTjcI5w5uixriiBPi25hgxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAjvEhQhAT9fSn LlMNTC/GhjskuURSjtORDHJIjo4Z9Tcb99qJLUAEPB0Deas1MMfhbK8xRvFriDA+j9h26DtP nHUQvstPPoJl444uXLXPNMgaKsx2uV/AfJYkOVVMcl2uTNl9SPoBCtbVruzLjx/bLD1L+wJ0 xLxVzBzgSHN6yAwq2Qo5BbV6b/437E3fyN9X5xzWEs6PRfalY3DTi7/Igmh7jvxP1nXxyoAp 6lg3YtmS3wqn9R3j9sxQeSHebZac0VFn0xSZ107XEIuYyzxSX1AQEFLi0j/boUfS8vvSFduV uKgsxPjWy8MFI+8OMyjC+nUcoo1okl+1qcp5rCaSJAAAAAAAAA== --------------ms070209010607080203030008-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 17:57:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22759 for ; Thu, 13 Mar 2003 17:57:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DMkFa06318 for ietf-calendar-bks; Thu, 13 Mar 2003 14:46:15 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DMkEg06314 for ; Thu, 13 Mar 2003 14:46:14 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2DMkD1W019363 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 13 Mar 2003 14:46:16 -0800 Message-ID: <3E710A2F.9010402@Royer.com> Date: Thu, 13 Mar 2003 15:46:07 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Partial equality match and sort order References: <1047505910.4849.175.camel@c-patrice.ca.oracle.com> <1047511241.1866.107.camel@laptop.eurekit.com> <3E6FD065.3050301@Royer.com> <1047584700.26354.13.camel@twelve-monkeys.boston.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010103020909020406020900" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010103020909020406020900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dan Winship wrote: > On Wed, 2003-03-12 at 19:27, Doug Royer wrote: > >>Would the others agree to a SORT capability? Where the default is "NONE"? >>Something like: >> >> SORT:none -> Any random order. >> SORT:SORT-1 -> As currently in CAP. > > > But then every client that cared about sorting would need to be able to > do sorting itself in case it was talking to a SORT:none server. And if > it has to have the code to do it sometimes, then why not do it all the > time? Your correct in that the client will have to do that in order to support CS that do not, however if SORT:SORT-1 is set, then the client will know that the CS has sorted the results in locale sort order. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010103020909020406020900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTMyMjQ2MDdaMCMGCSqGSIb3DQEJBDEWBBTs vGbdnzNiUWARYWV9g241lwLeVTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAmwEDwmmWHHsb iMrMAUDqD/SnYxD2uEEHpA4F2lpgFM0z9LXNL40AnVtaxCmhSF0P9YVxrJx1NEilXbCPnXCE Qs3jkuXZ1UGkqzjniGWRTXu3dtrqi6snN7hE5iJT7Cu471V8V5jLdEVeY+UICPEJZ7lZnQ0u i3BdEm5F6Y2Je4vifK1IaPBxO9PG0cf1LR7SB/f1tS/hasVJHGbFP9gRJO3TTOg2buCqGPa4 3aGARFL4Kts3VPz9fKNuIinsIq6fTpb0f+/Dz5r7hD408V6o3bYGk595O4rxNppSba1v2qnH yrrODtrb3+Z1i47CqUdMt5zsStokoVdYoYrK4mPiDgAAAAAAAA== --------------ms010103020909020406020900-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 18:00:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22876 for ; Thu, 13 Mar 2003 18:00:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DMqgp06815 for ietf-calendar-bks; Thu, 13 Mar 2003 14:52:42 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DMqfg06810 for ; Thu, 13 Mar 2003 14:52:41 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2DMqe1W019404 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 13 Mar 2003 14:52:43 -0800 Message-ID: <3E710BB3.1070100@Royer.com> Date: Thu, 13 Mar 2003 15:52:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? - beep References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050303060207010101000107" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050303060207010101000107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > 3: The BEEP examples and registration profiles (ie: Section 12.1. BEEP > Profile Registration of the Draft 10-17Feb2003) is not even filled in > _let alone_ discussed at all in the WG. It is still "TBD" in the latest > draft. It has been discussed. Did you object to the conclusions? One to Many or One to One replies? The issues were somewhat hot and you did participate. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050303060207010101000107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTMyMjUyMzVaMCMGCSqGSIb3DQEJBDEWBBQ6 DdtWHMsdHycamVzEi62XY+PrpDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAs3Hvv8B6Jz3m 6hClFRwuJLXoQ/VRSqUKTDqHiVo3xvg8A5bqMypEE0UBBQtw/tcVM0oGjVLYFsndqluJwvpv JcE7byI6X+iezb6HQcreUJ5zqyvB00xjL9Oemu9KM2JY/TwEfqBSeA+zs933PySR0sDlyfw5 ViVgZrUi4qffdSqtCDyejO0jsV5pDUltLzE1iTPS1/D5kAhyJBuAnoRTd+0bJakO+xiYQPlT icH+S3WE0NmJCJNLNi5VouqMOv+VdSNeF9LtGgXrLmcejb26r3PcNWraRIcrEfUx+Olt8J4W FZoqZPcs28MUkC6stSUdz/cJtwLpf0rA78ow/ig4ngAAAAAAAA== --------------ms050303060207010101000107-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 18:11:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24064 for ; Thu, 13 Mar 2003 18:11:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DN3eI07144 for ietf-calendar-bks; Thu, 13 Mar 2003 15:03:40 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DN3cg07134 for ; Thu, 13 Mar 2003 15:03:38 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2DN3c1W019484 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 13 Mar 2003 15:03:40 -0800 Message-ID: <3E710E44.3020106@Royer.com> Date: Thu, 13 Mar 2003 16:03:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? - delete / marked for delete References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030304010103050608060400" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030304010103050608060400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > A: Deletion vs 'marking for deletion". Its totally unclear what > the disction is, what benefit 'marked for deletion" is and if it > possible to undelete, etc. CAP REQUIREMENTS: CAP MUST allow synchronization, meaning at a minimum that the CUA is able to find and retrieve new, modified or deleted entries for a given time period. The CUA MUST be able to find out which entries ... The discussion that followed ... You have to be able to tag the entries as deleted, so that a later synchronization did not think they were new to the CS. CAP: When synchronizing with multiple CUAs, the marked for delete state could be used to inform the synchronization process that an object is to be deleted. How synchronization is done is not specified in this memo. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030304010103050608060400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTMyMzAzMzJaMCMGCSqGSIb3DQEJBDEWBBTc 2uGu/jnu97YtMJIiRFdNfJFL5TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAE4WD+5JzTg3u rZIt56bFqolx66ts5T9j9us+aPCrS8s/Cs25FyFyONOQTSatnGLJVMVJSEzy7QEwQQiw9M2I qnN0A1cTALWRUa3IRs8BmH6GreTokwZQa3lSj7/00CGSE9fYF4GnF5E8Yq6WbblJT9b2repG AH5SKj0DB/+TMldfgONpmKHYIjtjd7VrezEns9cd4cGBJ58k+Tk4LJ4KMQvAPDUOkXYzoNmP Oj9BrvzySaKRO5fJF8HskFo4O3usMDEaw5ttJv0QHpJkYoC8n0UQVJ6+ZFSZ3KNnZFefkufa 7p9OUhO20WoW8l1Ouv6XctQy+KuJ1gVGyBhYhFzbWwAAAAAAAA== --------------ms030304010103050608060400-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 18:12:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24181 for ; Thu, 13 Mar 2003 18:12:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DN7ZI07204 for ietf-calendar-bks; Thu, 13 Mar 2003 15:07:35 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DN7Xg07200 for ; Thu, 13 Mar 2003 15:07:33 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2DN7X1W019517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 13 Mar 2003 15:07:36 -0800 Message-ID: <3E710F30.6030409@Royer.com> Date: Thu, 13 Mar 2003 16:07:28 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? - multipart. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070803090504000706010602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070803090504000706010602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > B: Multipart MIME support. There is no text or examples dealing > with how multipart MIME should be properly dealt with in CAP. I had > hoped we would have learned from iTIP interop testing but so far no... Could you please post what your know from the interop testing about MIME support in iTIP? I thought we agreed to not limit CAP to specific implementations. So - all MIME multiplart (as specified in the CAPABILITY reply) may be sent. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070803090504000706010602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTMyMzA3MjhaMCMGCSqGSIb3DQEJBDEWBBRV Kzsm3Yhu9KZlh2HaZ9qs1iD7TzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbg8KLujbnN66 yPor2Jiusuvti1tFFWbS6yn3ux24DSRJIRpaLV3PMUefJDhkGhRXcw8XNvpKybHJixNK8Quy e4Kvoti9EnGrssh8Pq0dexD2Nm738is+sPDgFVCeaKd676js3TGg+a1HK+g6PgLA4T9hJ6YJ IxWce0O6w1YB/4iUoZhYRt8f3y9HHTNiwGvhOnUQbgRaS51o0EF0sjEC4SkF6BY3V9H9RyVU 4uaLff0t8/RSsuwDZiwAColObcyQPmo0PDfwaZXe7oyQq2Z9q2Fg5IXt3HmZas2hTp2YyAT/ ny3YWUn/9v/1PB4bGoEk9NqnLEWTLg+U2aF7CaAHYAAAAAAAAA== --------------ms070803090504000706010602-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 18:15:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24532 for ; Thu, 13 Mar 2003 18:15:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DN9TP07256 for ietf-calendar-bks; Thu, 13 Mar 2003 15:09:29 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DN9Sg07252 for ; Thu, 13 Mar 2003 15:09:28 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2DN9R1W019530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 13 Mar 2003 15:09:30 -0800 Message-ID: <3E710FA2.8050902@Royer.com> Date: Thu, 13 Mar 2003 16:09:22 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020101030407000505060506" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020101030407000505060506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > C: CAP preservation of IANA or X- properties/parameters, etc. > Unlike iTIP where some properties are not guaranteed to be preserved by > different implementations, CAP is how a CUA accesses a store so it > SHOULD preserve everything. This is NOT clearly defined and proscribed > for any CS. Good point. Are there any objects to saying that CAP MUST store ALL components, properties, and parameters sent to it by the CUA subject to VCAR rules? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020101030407000505060506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTMyMzA5MjJaMCMGCSqGSIb3DQEJBDEWBBTg RgFEXPjuOMqIHapzdIQU9ADgnDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAf94U6c6mH9zg QjsxBdZjqEiKl8hFuO08u197LtG/bjjkhWxb/zeZ9DMMVhx07BXhBCbUrLEnmI+pm6MVG4eE +NVx33prkCwglh0O0uA2PPMPi24G/qpkvvDJmYN4ltVMwaIfeT0SYyRoDm53kV3huzg/PrsO KMsjUXBp5SYFWhsxniHvRr+wsxQvEl164n+ywh82FnrAh0ufi5VXF9gfpGuQ9+T01IzCVLOa lki0jgihFQaRocor6qeBTtAXpYE/jAFU87Xe2Ogb74ukjh4sThz3X24qxSG8uF8gI5WcQ6Eu e97AWy4n5WtEoYk4pBsFUsXsgU9Kk666/7TiqstY/gAAAAAAAA== --------------ms020101030407000505060506-- From owner-ietf-calendar@mail.imc.org Thu Mar 13 23:09:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02131 for ; Thu, 13 Mar 2003 23:09:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2E42IX16277 for ietf-calendar-bks; Thu, 13 Mar 2003 20:02:18 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E42Fg16268 for ; Thu, 13 Mar 2003 20:02:15 -0800 (PST) Subject: Re: iSIP draft - ?? To: John Stracke Cc: ietf-calendar@imc.org, ned+ietf-calendar@mrochek.com, owner-ietf-calendar@mail.imc.org, paf@cisco.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Thu, 13 Mar 2003 23:02:19 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/13/2003 11:02:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for clarifying that John. The rules are "vague" and elusive until one does something incorrect - then you find out in a hurry what the rules really are. I just wanted to make sure that I covered the bases as the chair. Afterall, we all want to have iCalendr used as much as possible - especially for small footprint devices. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 John Stracke cc: ietf-calendar@imc.org, paf@cisco.com, ned+ietf-calendar@mrochek.com Sent by: Subject: Re: iSIP draft - ?? owner-ietf-calendar@m ail.imc.org 03/13/03 04:43 PM pregen@egenconsulting.com wrote: >I have seen the following link posted as a new draft. http://www.ietf.org/internet-drafts/draft-pessi-calsch-isip-00.txt. > [...] >But it should not say CALSCH WG if it's >never been discussed in the group. > > The rule is only for things named "draft-ietf-calsch-", isn't it? It's unusual to see an individual submission named for a WG when it hasn't been discussed there, but it isn't forbidden. And this is related to calsch stuff. (Mind you, I don't like it much; it leaves too much stuff undefined, and its abstract seems overambitious. But that's another story.) -- /==============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==============================================================| |"Where's your sense of adventure?" "In front of a roaring fire| |with a cup of cocoa." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 14 08:37:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24958 for ; Fri, 14 Mar 2003 08:37:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EDRY206355 for ietf-calendar-bks; Fri, 14 Mar 2003 05:27:34 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2EDRXg06348 for ; Fri, 14 Mar 2003 05:27:33 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031408310518149 for ; Fri, 14 Mar 2003 08:31:05 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 08:25:20 -0500 Message-ID: <3E71D840.8070708@centive.com> Date: Fri, 14 Mar 2003 08:25:20 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Last call??? References: <3E710FA2.8050902@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2003 13:25:20.0949 (UTC) FILETIME=[2970EE50:01C2EA2D] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Are there any objects to saying that CAP MUST store > ALL components, properties, and parameters sent to it by the CUA > subject to VCAR rules? I just posted in favor; but then I thought of a clarification: we need to permit the CS to ban components for administrative reasons. For example, it seems likely that someone will write a CUA that's equipped to spread viruses; once that happens, people will need to be able to build CSes that do virus filtering--and that's not something that can be expressed in a reasonable VCAR syntax. ;-) -- /=============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=============================================================| |The cheapest, fastest, most reliable components of a computer| |system are those that aren't there.--Gordon Bell | \=============================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 14 08:42:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25101 for ; Fri, 14 Mar 2003 08:42:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EDNc305753 for ietf-calendar-bks; Fri, 14 Mar 2003 05:23:38 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2EDNbg05746 for ; Fri, 14 Mar 2003 05:23:37 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031408270917370 for ; Fri, 14 Mar 2003 08:27:09 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 08:21:24 -0500 Message-ID: <3E71D754.3080408@centive.com> Date: Fri, 14 Mar 2003 08:21:24 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Last call??? References: <3E710FA2.8050902@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2003 13:21:24.0488 (UTC) FILETIME=[9C7FD880:01C2EA2C] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Bruce_Kahn@notesdev.ibm.com wrote: > >> CAP is how a CUA accesses a store so it SHOULD preserve everything. > > Good point. Are there any objects to saying that CAP MUST store > ALL components, properties, and parameters sent to it by the CUA > subject to VCAR rules? Sounds good to me. -- /=============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=============================================================| |The cheapest, fastest, most reliable components of a computer| |system are those that aren't there.--Gordon Bell | \=============================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 14 10:56:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00312 for ; Fri, 14 Mar 2003 10:56:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EFgrR16493 for ietf-calendar-bks; Fri, 14 Mar 2003 07:42:53 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EFgrg16489 for ; Fri, 14 Mar 2003 07:42:53 -0800 (PST) In-Reply-To: <3E710BB3.1070100@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? - beep MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 10:42:52 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 10:42:49 AM, Serialize complete at 03/14/2003 10:42:49 AM Content-Type: multipart/alternative; boundary="=_alternative 005642A985256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005642A985256CE9_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 03/13/2003 05:52:35 PM: > > 3: The BEEP examples and registration profiles (ie: Section 12.1. BEEP > > Profile Registration of the Draft 10-17Feb2003) is not even filled in > > _let alone_ discussed at all in the WG. It is still "TBD" in the latest > > draft. > > It has been discussed. Did you object to the conclusions? One to Many > or One to One replies? The issues were somewhat hot and you did > participate. No it has not! When I mentioned this months ago the response I got was "Later, we want to get the rest of CAP done first.". If it was discussed then under what heading and where is the prose? 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 005642A985256CE9_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 03/13/2003 05:52:35 PM:
> > 3: The BEEP examples and registration profiles (ie: Section 12.1. BEEP
> > Profile Registration  of the Draft 10-17Feb2003) is not even filled in
> > _let alone_ discussed at all in the WG.  It is still "TBD" in the latest
> > draft.
>
> It has been discussed. Did you object to the conclusions? One to Many
> or One to One replies? The issues were somewhat hot and you did
> participate.
No it has not!  When I mentioned this months ago the response I got was "Later, we want to get the rest of CAP done first.".

If it was discussed then under what heading and where is the prose?

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 005642A985256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 11:22:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01195 for ; Fri, 14 Mar 2003 11:22:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EG0bo17280 for ietf-calendar-bks; Fri, 14 Mar 2003 08:00:37 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EG0Zg17276 for ; Fri, 14 Mar 2003 08:00:35 -0800 (PST) In-Reply-To: <3E710AF0.5080406@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 11:00:35 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 11:00:32 AM, Serialize complete at 03/14/2003 11:00:32 AM Content-Type: multipart/alternative; boundary="=_alternative 0057E1F985256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057E1F985256CE9_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 03/13/2003 05:49:20 PM: > > Another issue from WAAAY back was the proliferation of top level > > Response Codes in CAP. From Section 10.11. Response Codes: > > ... > > So if you take the REQUEST-STATUS e-mail that I sent one or two > weeks ago and add that into cap - does that solve *this* issue? We were more focused on the issue of ordering responses in CREATE. Falling thru the cracks is a very good reason why we need to recheck and reupdate the issues list BEFORE we can go to Last Call dont you think? I found your posting dated 02/22/2003 06:33:16 PM MST under "REQUEST-STATUS errors and issues for CAP" and I would have to say no, it does not solve the issue. Here's why: RFC 2445 does not define a top level 5 class of error but we somehow put/left them in RFC 2446. This is a known issue with 2446 from, oh, about 2 or 3 years ago. This should be fixed when we post errata or an update to 2445. Neither 2446 NOR your posting has any prose on what a top level 5.x error code is. Nothing close to the cited table from 2445 that clearly defines them. Nor does CAP have anything like it. Nor does your message address the addition of 6 new top level classes in CAP without defining them either! Nor does your note address CAPs proliferation of so many near top level response codes. So I guess that would be a definite, No your note does NOT solve _*this*_ issue. If it does, could you point out what I missed so I can reconsider? > It was a proposal on how to merge/fix/update the REQUEST-STATUS > codes. I do not recall that you responded. I got NO negative feedback > and some positive feedback. So I assume the rest of the WG felt > it addressed those issues? We were more involved with the ongoing discussion of ordering of results and CREATE and the UTF-8 issues in case you hadn't noticed. I did not respond as it fell out of the active view of things. In looking now I see no negative OR postitive responses. When issues get squeezed out by more active and drawn out threads then silence is not always acceptance; it can be just a forgotten posting. 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 0057E1F985256CE9_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 03/13/2003 05:49:20 PM:
> > Another issue from WAAAY back was the proliferation of top level
> > Response Codes in CAP.  From Section 10.11. Response Codes:
> > ...
>
> So if you take the REQUEST-STATUS e-mail that I sent one or two
> weeks ago and add that into cap - does that solve *this* issue?
We were more focused on the issue of ordering responses in CREATE.  Falling thru the cracks is a very good reason why we need to recheck and reupdate the issues list BEFORE we can go to Last Call dont you think?

I found your posting dated 02/22/2003 06:33:16 PM MST under "REQUEST-STATUS errors and issues for CAP" and I would have to say no, it does not solve the issue.  Here's why:

RFC 2445 does not define a top level 5 class of error but we somehow put/left them in RFC 2446.  This is a known issue with 2446 from, oh, about 2 or 3 years ago.  This should be fixed when we post errata or an update to 2445.  Neither 2446 NOR your posting has any prose on what a top level 5.x error code is.  Nothing close to the cited table from 2445 that clearly defines them.  

Nor does CAP have anything like it.  Nor does your message address the addition of 6 new top level classes in CAP without defining them either!  Nor does your note address CAPs proliferation of so many near top level response codes.

So I guess that would be a definite, No your note does NOT solve _*this*_ issue.  If it does, could you point out what I missed so I can reconsider?

> It was a proposal on how to merge/fix/update the REQUEST-STATUS
> codes. I do not recall that you responded. I got NO negative feedback
> and some positive feedback. So I assume the rest of the WG felt
> it addressed those issues?
We were more involved with the ongoing discussion of ordering of results and CREATE and the UTF-8 issues in case you hadn't noticed.  I did not respond as it fell out of the active view of things.  In looking now I see no negative OR postitive responses.  When issues get squeezed out by more active and drawn out threads then silence is not always acceptance; it can be just a forgotten posting.

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 0057E1F985256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 12:01:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02691 for ; Fri, 14 Mar 2003 12:01:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EGj0Z18924 for ietf-calendar-bks; Fri, 14 Mar 2003 08:45:00 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EGiwg18918 for ; Fri, 14 Mar 2003 08:44:59 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: REQUEST-STATUS errors and issues for CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 11:44:55 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 11:44:53 AM, Serialize complete at 03/14/2003 11:44:53 AM Content-Type: multipart/alternative; boundary="=_alternative 005BF13285256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005BF13285256CE9_= Content-Type: text/plain; charset="US-ASCII" On 02/22/2003 06:33:16 PM MST Doug wrote (but noone responsed to): > (2) A note that says that REQUEST-STATUS is optional on success. > I propose that REQUEST-STATUS not be optional in CAP for > replies. I like this idea. No need for waffling. If it failed we let them know. If it worked we should also let them know. After all its only about 18-20 octets more in the overall data stream. However you MUST be careful in how you mandate it so that you do not preclude CAP->iTIP fallback in the future (ie: CAP 3.x) since iTIP does not mandate REQUEST-STATUS always. > [NOTE] Sections 3.2.3 and 3.4.4 seem to conflict with each other > [NOTE] and section 3.6 "Status Replies" with respect to error > [NOTE] code "5.3". > [NOTE] > [NOTE] I think that the "5.3" error code in section 3.4.4 of iTIP > [NOTE] should say "3.14". Agree? First off, as was noted many many moon ago there is NO 5.x class definition in RFC 2445 so: 1: There should be no 5.x error codes in 2446 OR 2: We need to clearly define what the 5.x error codes are used for in 2445 in the same way that the other codes are defined: | Short Return | Longer Return Status Description | | Status Code | | |==============+===============================================| | 1.xx | Preliminary success. This class of status | | | of status code indicates that the request has | | | request has been initially processed but that | | | completion is pending. | |==============+===============================================| | 2.xx | Successful. This class of status code | | | indicates that the request was completed | | | successfully. However, the exact status code | | | can indicate that a fallback has been taken. | |==============+===============================================| | 3.xx | Client Error. This class of status code | | | indicates that the request was not successful.| | | The error is the result of either a syntax or | | | a semantic error in the client formatted | | | request. Request should not be retried until | | | the condition in the request is corrected. | |==============+===============================================| | 4.xx | Scheduling Error. This class of status code | | | indicates that the request was not successful.| | | Some sort of error occurred within the | | | calendaring and scheduling service, not | | | directly related to the request itself. | I expect there to be a class 5 error defintion for something like "Server Error" or "Service Error" to convey things like "Server internal error" or "Server shutting down. No further commands allowed", etc. This is something we need for CAP but did not need for iTIP when we only focused on iMIP usages. However I have yet to see any kind of prose to this effect in CAP (see other threads of late). Secondly 3.14 is defined in 2446 as: | 3.14 | Unsupported capability | Method or action MAY | | | | be specified | and 5.3 is defined as: | 5.3 | No scheduling support for | ATTENDEE property value | | | user. | MAY be specified. | The former means that the METHOD used is unsupported entirely. The latter means that a particular ATTENDEE cannot perform workflow (aka Scheduling). It does not mean they cannot perform Calendaring. The rest of the ATTENDEEs have no problem performing workflow. The former is scoped to the iTIP message entirely. The latter is scoped to a particular ATTENDEE. Given this I would say that merging 5.3 and 3.14 is NOT the propery action. Im not sure we should collapse them down given the strict definition of a class 3 error code. It is clearly defined as "The error is the result of either a syntax or a semantic error in the client formatted request.". The inability of an ATTENDEE to perform workflow is NOT this kind of error. In looking at the 2445 definitions I think that merging it into 4.x is more accurate. Heres why: 1: The 4.x error code is defined as "Some sort of error occurred within the calendaring and scheduling service, not directly related to the request itself." This would easily match the analysis of the intent of 5.14; a particular user cannot perform "scheduling". 2:The problem described by 5.3 is "No scheduling support for user" and error class 4 is defined generally as "Scheduling Error". Perhaps 5.3 should become 4.1 since we only seem to have defined 4.0 in iTIP. > [NOTE] So I propose that in CAP we specify that code '3.14' means > [NOTE] that the "Attendee" calendar does not support the ADD method > [NOTE] for any component type, Why redefine 3.14 for just the ADD method?? It is equally valueable for those that do not support COUNTERs or other METHODs (even those TBD by CAP or some new effort). I see no benefit in narrowing 3.14 down to just "ADD". Also, I think this change would redefine the semantics of a clas 3 error code from being "a semantic error" to being "ADD not supported" and thats clearly NOT how 3.x is defined. Do not touch 3.14 for CAP, its use and meaning is already relatively clear and usable. Its 5.3 we need to focus on instead. > and that code "5.3" means that the > [NOTE] calendar does not support ANY scheduling - that is NO METHOD > [NOTE] values may be deposited in to the calendar. If it is attempted > [NOTE] then CS replies with 5.3, and they are not deposited. See above first about reclassifying 5.3 as 4.x. Next, 5.3 says that "scheduling" is not supported by the user". It does NOT say that Calendaring is not supported. That is, the user can still do PIM stuff, just no workflow. I dont think we should include Calendaring as part of the error code semantics. After all, if the user cannot do Calendar OR Scheduling then why the hell would they even use CAP (or would they even have a CAP server login)???? > [NOTE] Existing implementations should not be effected as they > [NOTE] do not interact with CAP. Error codes of 3.x and 4.0 are NOT CAP specific and should be supported and used by any existing implementation. As such we cannot just arbitrarily redefine the definition of 3.14 (without need!). > I further think we need to > [NOTE] specify that CUA's only use 5.3 when the CS does not > [NOTE] support ANY scheduling and 3.14 when the CS does not > [NOTE] support the ADD method. Again, if the CUA cannot perform any Calendaring or Scheduling then they surely do not use CAP since they essentially could do NOTHING! > ITIP: 3.2.4 ADD > > > The "UID" must be that of the existing event. If the "UID" property > value in the "ADD" is not found on the recipient's calendar, then the > recipient SHOULD send a "REFRESH" to the "Organizer" in order to be > updated with the latest version of the "VEVENT". If an "Attendee" > implementation does not support the "ADD" method it should respond > with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". This is correct. The same applys for COUNTERs and DECLINE-COUNTERs (although not supporting a DECLINE-COUNTER but supporting COUNTER is kinda odd!). It equally applys to any as yet undefined METHODs that a CUA could generate and send. > ITIP: 3.4.4 ADD > > If the "UID" property value in the "ADD" is not found on the > recipient's calendar, then the recipient SHOULD send a "REFRESH" to > the "Organizer" in order to be updated with the latest version of the > "VTODO". If an "Attendee" implementation does not support the "ADD" > method it should respond with a "REQUEST-STATUS" value of 5.3 and ask > for a "REFRESH". This is incorrect. (Imagine that, a mistake in the RFC?!?!) The VTODO prose should mirror that of the VEVENT. It could be that the change from 5.3 to 3.14 did not get fully applyed to iTIP prose and that left 5.3 around (along w/the rest of the 5.x error codes). After 255+ pages I guess noone was coherent enough to notice during Last Call. > [NOTE] An interesting note in iTIP about REQUEST-STATUS being optional > [NOTE] on success. I propose that in CAP that REQUEST-STATUS be > [NOTE] mandatory! In looking at Section 3.6 of iTIP I cannot see ANY prose that indicates this. The restriction tables for each METHOD determine this and I think all but PUBLISH have "REQUEST-STATUS 0+". I cannot recall any justification for not having 1+ on at least the REPLY message but perhaps that was another oversight. One thing to consider, if you are going to PUBLISH your calendar then REQUEST-STATUS has NO meaning as there is NOT workflow involved. As such mandating it in CAP for PUBLISHes is non-sensical. > iTIP: 4.2.2 Reply To A Group Event Request > > "B" could have declined the meeting or indicated tentative acceptance > by setting the "ATTENDEE" "partstat" parameter to "declined" or > "tentative", respectively. Also, "REQUEST-STATUS" is not required in > successful transactions. Again, either noone saw it or we just thought leaving it out was ok. Do you recall why we took this approach?? > IMIP / 2447 > > [NOTE] NO 'REQUEST-STATUS' is defined in 2447. Thats because iMIP is just a binding of iTIP and iTIP does the acutal content definition. iMIP just says how to bundle and send an iTIP message over email. BTW: In case we didnt cover this before, in 2446 we have: | 5.0 | Request MAY supported. | Method property value | | | | MAY be specified. | but its gramatically incorrect AND its use is totally vague/indeterminate. Unless we can figure out what 5.0 is intended for and better describe it we should probably remove it from iTIP (or reuse it and redefine it in CAP) 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 005BF13285256CE9_= Content-Type: text/html; charset="US-ASCII"
On 02/22/2003 06:33:16 PM MST Doug wrote (but noone responsed to):
>   (2) A note that says that REQUEST-STATUS is optional on success.
>       I propose that REQUEST-STATUS not be optional in CAP for
>       replies.
I like this idea.  No need for waffling.  If it failed we let them know.  If it worked we should also let them know.  After all its only about 18-20 octets more in the overall data stream.  

However you MUST be careful in how you mandate it so that you do not preclude CAP->iTIP fallback in the future (ie: CAP 3.x) since iTIP does not mandate REQUEST-STATUS always.

> [NOTE] Sections 3.2.3 and 3.4.4 seem to conflict with each other
> [NOTE] and section 3.6 "Status Replies" with respect to error
> [NOTE] code "5.3".
> [NOTE]
> [NOTE] I think that the "5.3" error code in section 3.4.4 of iTIP
> [NOTE] should say "3.14". Agree?
First off, as was noted many many moon ago there is NO 5.x class definition in RFC 2445 so:

1: There should be no 5.x error codes in 2446 OR
2: We need to clearly define what the 5.x error codes are used for in 2445 in the same way that the other codes are defined:

      | Short Return | Longer Return Status Description              |
     | Status Code  |                                               |
     |==============+===============================================|
     |    1.xx      | Preliminary success. This class of status     |
     |              | of status code indicates that the request has |
     |              | request has been initially processed but that |
     |              | completion is pending.                        |
     |==============+===============================================|
     |    2.xx      | Successful. This class of status code         |
     |              | indicates that the request was completed      |
     |              | successfully. However, the exact status code   |
     |              | can indicate that a fallback has been taken.  |
     |==============+===============================================|
     |    3.xx      | Client Error. This class of status code       |
     |              | indicates that the request was not successful.|
     |              | The error is the result of either a syntax or |
     |              | a semantic error in the client formatted      |
     |              | request. Request should not be retried until  |
     |              | the condition in the request is corrected.    |
     |==============+===============================================|
     |    4.xx      | Scheduling Error. This class of status code   |
     |              | indicates that the request was not successful.|
     |              | Some sort of error occurred within the        |
     |              | calendaring and scheduling service, not       |
     |              | directly related to the request itself.       |
I expect there to be a class 5 error defintion for something like "Server Error" or "Service Error" to convey things like "Server internal error" or "Server shutting down.  No further commands allowed", etc.  This is something we need for CAP but did not need for iTIP when we only focused on iMIP usages.  However I have yet to see any kind of prose to this effect in CAP (see other threads of late).

Secondly 3.14 is defined in 2446 as:

| 3.14         | Unsupported capability     | Method or action MAY    |
|              |                            | be specified            |
and 5.3 is defined as:

| 5.3          | No scheduling support for  | ATTENDEE property value |
|              | user.                      | MAY be specified.       |
The former means that the METHOD used is unsupported entirely.  The latter means that a particular ATTENDEE cannot perform workflow (aka Scheduling).  It does not mean they cannot perform Calendaring.  The rest of the ATTENDEEs have no problem performing workflow.  The former is scoped to the iTIP message entirely.  The latter is scoped to a particular ATTENDEE.  Given this I would say that merging 5.3 and 3.14 is NOT the propery action.

Im not sure we should collapse them down given the strict definition of a class 3 error code.  It is clearly defined as "The error is the result of either a syntax or a semantic error in the client formatted request.".  The inability of an ATTENDEE to perform workflow is NOT this kind of error.  In looking at the 2445 definitions I think that merging it into 4.x is more accurate.  Heres why:

1: The 4.x error code is defined as "Some sort of error occurred within the calendaring and scheduling service, not directly related to the request itself."  This would easily match the analysis of the intent of 5.14; a particular user cannot perform "scheduling".
2:The problem described by 5.3 is "No scheduling support for user" and error class 4 is defined generally as "Scheduling Error".

Perhaps 5.3 should become 4.1 since we only seem to have defined 4.0 in iTIP.

> [NOTE] So I propose that in CAP we specify that code '3.14' means
> [NOTE] that the "Attendee" calendar does not support the ADD method
> [NOTE] for any component type,

Why redefine 3.14 for just the ADD method??  It is equally valueable for those that do not support COUNTERs or other METHODs (even those TBD by CAP or some new effort).  I see no benefit in narrowing 3.14 down to just "ADD".  Also, I think this change would redefine the semantics of a clas 3 error code from being "a semantic error" to being "ADD not supported" and thats clearly NOT how 3.x is defined.

Do not touch 3.14 for CAP, its use and meaning is already relatively clear and usable.  Its 5.3 we need to focus on instead.

>                                 and that code "5.3" means that the
> [NOTE] calendar does not support ANY scheduling - that is NO METHOD
> [NOTE] values may be deposited in to the calendar. If it is attempted
> [NOTE] then CS replies with 5.3, and they are not deposited.
See above first about reclassifying 5.3 as 4.x.

Next, 5.3 says that "scheduling" is not supported by the user".  It does NOT say that Calendaring is not supported.  That is, the user can still do PIM stuff, just no workflow.  I dont think we should include Calendaring as part of the error code semantics.  After all, if the user cannot do Calendar OR Scheduling then why the hell would they even use CAP (or would they even have a CAP server login)????

> [NOTE] Existing implementations should not be effected as they
> [NOTE] do not interact with CAP.

Error codes of 3.x and 4.0 are NOT CAP specific and should be supported and used by any existing implementation.  As such we cannot just arbitrarily redefine the definition of 3.14 (without need!).  

>                                    I further think we need to
> [NOTE] specify that CUA's only use 5.3 when the CS does not
> [NOTE] support ANY scheduling and 3.14 when the CS does not
> [NOTE] support the ADD method.
Again, if the CUA cannot perform any Calendaring or Scheduling then they surely do not use CAP since they essentially could do NOTHING!

> ITIP: 3.2.4 ADD
>
>
>     The "UID" must be that of the existing event. If the "UID" property
>     value in the "ADD" is not found on the recipient's calendar, then the
>     recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
>     updated with the latest version of the "VEVENT".  If an "Attendee"
>     implementation does not support the "ADD" method it should respond
>     with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
This is correct.  The same applys for COUNTERs and DECLINE-COUNTERs (although not supporting a DECLINE-COUNTER but supporting COUNTER is kinda odd!).  It equally applys to any as yet undefined METHODs that a CUA could generate and send.

> ITIP: 3.4.4 ADD
>
>     If the "UID" property value in the "ADD" is not found on the
>     recipient's calendar, then the recipient SHOULD send a "REFRESH" to
>     the "Organizer" in order to be updated with the latest version of the
>     "VTODO". If an "Attendee" implementation does not support the "ADD"
>     method it should respond with a "REQUEST-STATUS" value of 5.3 and ask
>     for a "REFRESH".
This is incorrect.  (Imagine that, a mistake in the RFC?!?!)  The VTODO prose should mirror that of the VEVENT.  It could be that the change from 5.3 to 3.14 did not get fully applyed to iTIP prose and that left 5.3 around (along w/the rest of the 5.x error codes).  After 255+ pages I guess noone was coherent enough to notice during Last Call.

> [NOTE] An interesting note in iTIP about REQUEST-STATUS being optional
> [NOTE] on success. I propose that in CAP that REQUEST-STATUS be
> [NOTE] mandatory!
In looking at Section 3.6 of iTIP I cannot see ANY prose that indicates this.  The restriction tables for each METHOD determine this and I think all but PUBLISH have "REQUEST-STATUS 0+".  I cannot recall any justification for not having 1+ on at least the REPLY message but perhaps that was another oversight.

One thing to consider, if you are going to PUBLISH your calendar then REQUEST-STATUS has NO meaning as there is NOT workflow involved.  As such mandating it in CAP for PUBLISHes is non-sensical.

> iTIP: 4.2.2 Reply To A Group Event Request
>
>     "B" could have declined the meeting or indicated tentative acceptance
>     by setting the "ATTENDEE" "partstat" parameter to "declined" or
>     "tentative", respectively. Also, "REQUEST-STATUS" is not required in
>     successful transactions.
Again, either noone saw it or we just thought leaving it out was ok.  Do you recall why we took this approach??

>          IMIP / 2447
>
> [NOTE] NO 'REQUEST-STATUS' is defined in 2447.
Thats because iMIP is just a binding of iTIP and iTIP does the acutal content definition.  iMIP just says how to bundle and send an iTIP message over email.

BTW: In case we didnt cover this before, in 2446 we have:

| 5.0          | Request MAY supported.     | Method property value   |
|              |                            | MAY be specified.       |
but its gramatically incorrect AND its use is totally vague/indeterminate.  Unless we can figure out what 5.0 is intended for and better describe it we should probably remove it from iTIP (or reuse it and redefine it in CAP)

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 005BF13285256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 12:03:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02758 for ; Fri, 14 Mar 2003 12:03:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EGn0a19069 for ietf-calendar-bks; Fri, 14 Mar 2003 08:49:00 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EGmxg19064 for ; Fri, 14 Mar 2003 08:48:59 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 11:48:57 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 11:48:53 AM, Serialize complete at 03/14/2003 11:48:53 AM Content-Type: multipart/alternative; boundary="=_alternative 005C4FA185256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C4FA185256CE9_= Content-Type: text/plain; charset="US-ASCII" John asked on 03/10/2003: > > Does locale sort ordering solve it? I thought that partial match > > sorts were unspecified? > > What are partial matches? Doug does not mean partial in the sense of "some matched, some did not". He seems to just be taking about substring ordering (at least if you follow his examples). If there is something else then I too missed it. 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 005C4FA185256CE9_= Content-Type: text/html; charset="US-ASCII"
John asked on 03/10/2003:
> > Does locale sort ordering solve it? I thought that partial match
> > sorts were unspecified?
>
> What are partial matches?

Doug does not mean partial in the sense of "some matched, some did not".  He seems to just be taking about substring ordering (at least if you follow his examples).  If there is something else then I too missed it.

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 005C4FA185256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 12:27:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03299 for ; Fri, 14 Mar 2003 12:27:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EH6TG19850 for ietf-calendar-bks; Fri, 14 Mar 2003 09:06:29 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EH6Sg19846 for ; Fri, 14 Mar 2003 09:06:28 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 12:06:26 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 12:06:21 PM, Serialize complete at 03/14/2003 12:06:21 PM Content-Type: multipart/alternative; boundary="=_alternative 005DE96C85256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DE96C85256CE9_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 03/11/2003 10:10:15 AM MST: > > I big time object. This just makes the CS have to cache up ALL matching > > objects/values to return before it can return ANY so that it can sort > > them based on some implyed sort order (the order of the SELECT). This > > makes bounded latency even worse! > > What do you do with the other items that must be sorted that is > any different? Sorting is a client side preference/consideration to me. Each CUA can sort and resort the results any way the like, kinda like the way a good MUA will sort messages by Sender, Subject, Date, etc. Does my mail server have to worry about how I want to sort or resort my data? No. Does my mail server know my locale settings so that it can sort the results accurately? No. Does my mail server resort 'new arrivals' recieved out of order so that it can render properly in my Inbox. No, my MUA does that too. The same logic applys to CUAs. Making the CS sort the results means that the entire set must first be gathered THEN sorted THEN returned. If the CS is going to have to send back all the results anyway (assuming I dont ABORT it because its taking too long) why not let the CUA do the sorting so that the CS is available for other things/users? Any decent CUA is going to be able to sort / resort data for the CU so why not allow it to do the sorting entirely? That would allow the CS to start returning results as soon as it starts to get them rather than having to cache them ALL. In addition, making a CS store and then sort the results instead of returning them immediately will not likely scale well to large user counts. If the set of returned results will be the same no matter if the CS sorts them or the CUA sorts them but we get better scalability by letting the CUA sort them then what benefit do we get by making a CS do the work? 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 005DE96C85256CE9_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 03/11/2003 10:10:15 AM MST:
> > I big time object.  This just makes the CS have to cache up ALL matching
> > objects/values to return before it can return ANY so that it can sort
> > them based on some implyed sort order (the order of the SELECT).  This
> > makes bounded latency even worse!
>
> What do you do with the other items that must be sorted that is
> any different?

Sorting is a client side preference/consideration to me.  

Each CUA can sort and resort the results any way the like, kinda like the way a good MUA will sort messages by Sender, Subject, Date, etc.  Does my mail server have to worry about how I want to sort or resort my data?  No.  Does my mail server know my locale settings so that it can sort the results accurately?  No.  Does my mail server resort 'new arrivals' recieved out of order so that it can render properly in my Inbox.  No, my MUA does that too.  The same logic applys to CUAs.

Making the CS sort the results means that the entire set must first be gathered THEN sorted THEN returned.  If the CS is going to have to send back all the results anyway (assuming I dont ABORT it because its taking too long) why not let the CUA do the sorting so that the CS is available for other things/users?

Any decent CUA is going to be able to sort / resort data for the CU so why not allow it to do the sorting entirely?  That would allow the CS to start returning results as soon as it starts to get them rather than having to cache them ALL.  

In addition, making a CS store and then sort the results instead of returning them immediately will not likely scale well to large user counts.  If the set of returned results will be the same no matter if the CS sorts them or the CUA sorts them but we get better scalability by letting the CUA sort them then what benefit do we get by making a CS do the work?

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 005DE96C85256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 12:27:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03303 for ; Fri, 14 Mar 2003 12:27:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EH9tI19955 for ietf-calendar-bks; Fri, 14 Mar 2003 09:09:55 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EH9rg19951 for ; Fri, 14 Mar 2003 09:09:53 -0800 (PST) In-Reply-To: <3E710BB3.1070100@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? - beep MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 12:09:52 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 12:09:46 PM, Serialize complete at 03/14/2003 12:09:46 PM Content-Type: multipart/alternative; boundary="=_alternative 005E39C285256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E39C285256CE9_= Content-Type: text/plain; charset="US-ASCII" Doug suggested on 03/13/2003 05:52:35 PM: > > 3: The BEEP examples and registration profiles (ie: Section 12.1. BEEP > > Profile Registration of the Draft 10-17Feb2003) is not even filled in > > _let alone_ discussed at all in the WG. It is still "TBD" in the latest > > draft. > > It has been discussed. Did you object to the conclusions? One to Many > or One to One replies? The issues were somewhat hot and you did > participate. Sorry, the discussion of 1-to-many or 1-to-1 is NOT the sole consideration for 12.1 BEEP Profile Registration. There is simply NO prose in that section and there has been none given since we adopted BEEP last year! How can we have Last Call on NO PROSE? We could NOT have had ANY "hot" WG discussion on NO PROSE, at least not in this universe. 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 005E39C285256CE9_= Content-Type: text/html; charset="US-ASCII"
Doug suggested on 03/13/2003 05:52:35 PM:
> > 3: The BEEP examples and registration profiles (ie: Section 12.1. BEEP
> > Profile Registration  of the Draft 10-17Feb2003) is not even filled in
> > _let alone_ discussed at all in the WG.  It is still "TBD" in the latest
> > draft.
>
> It has been discussed. Did you object to the conclusions? One to Many
> or One to One replies? The issues were somewhat hot and you did
> participate.
Sorry, the discussion of 1-to-many or 1-to-1 is NOT the sole consideration for 12.1 BEEP Profile Registration.  

There is simply NO prose in that section and there has been none given since we adopted BEEP last year!  How can we have Last Call on NO PROSE?  We could NOT have had ANY "hot" WG discussion on NO PROSE, at least not in this universe.

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 005E39C285256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 12:48:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03830 for ; Fri, 14 Mar 2003 12:48:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EHZHR22213 for ietf-calendar-bks; Fri, 14 Mar 2003 09:35:17 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EHZGg22207 for ; Fri, 14 Mar 2003 09:35:16 -0800 (PST) In-Reply-To: <3E710E44.3020106@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? - delete / marked for delete MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 12:35:14 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 12:35:08 PM, Serialize complete at 03/14/2003 12:35:08 PM Content-Type: multipart/alternative; boundary="=_alternative 00608C3485256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00608C3485256CE9_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 03/13/2003 06:03:32 PM: > > A: Deletion vs 'marking for deletion". Its totally unclear what > > the disction is, what benefit 'marked for deletion" is and if it > > possible to undelete, etc. > > CAP REQUIREMENTS: > > CAP MUST allow synchronization, meaning at a minimum that the CUA is > able to find and retrieve new, modified or deleted entries for a > given time period. The CUA MUST be able to find out which entries > ... > > The discussion that followed ... > You have to be able to tag the entries as deleted, so that a later > synchronization did not think they were new to the CS. I am NOT talking about sync related issues. Im talking about the overall CAP design and how deletions are dealt with in a consistant manner by ALL implementations.. Ive mentioned this distintion at least 2 times before and I guess its still not clear to some so thats probably a bad sign. There is NO prose anywhere describing all kinds of questions around deletions such as: 1: The ability to 'unDELETE' entries "marked for deletion". Is this possible / allowed? (This ability is essentially 'soft deletes' for those that recall that topic.) 1.1: Do I actually delete a 'marked for deletion' (MFD) entry from the CS by reissuing a DELETE with no MARK parameter or is there some other way to actually remove it? 1.2: Does changing the state of the MDF entry effectively undelete it (assuming thats possible in CAP)? 1.3: Can an MFD entry be modified in any way (using the right SELECT, etc)? 2: Must a CS support marking for deletion (and thus soft deletions) or can it just do actual deletions? 2.1: If a CS does not support marking for deletion then should it treat the MARK parameter as optional OR should it fail the DELETE? 3: Is MFD a required feature of a CS or can it just support DELETE but no MARK paramter? 3: If soft deletions are NOT mandatory we need some clear prose to describe how implementations that do not support it should respond to soft delete requests. 4: What are the effects of actually deleting an entry and not just MARKing it for deletion? 4.1: Can a CUA just do this arbitrarily or SHOULD a CUA use MARK all the time? 4.2: What is the proper CUA & CS behaviour for dealing with responses to either an MFD or actually deleted (irregardless if the CS knows it was deleted or if it never existed yet!) entry? 4.3: Should we use DELETE to mean "mark for later deletion" and a _new_ (and yet undefined) command like PURGE or EXPUNGE to actually remove marked entries? 5: If we cannot unDELETE an entry then why should the CUA distinguish between actually deleting it (no MARK parameter) and marking it? As far as the CUA is concerned the entry is gone. As far as sync goes a sync engine just cares if the state is DELETED or not. 6: When does an MFD entry actually get removed from the system? 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 00608C3485256CE9_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 03/13/2003 06:03:32 PM:
> >         A: Deletion vs 'marking for deletion".  Its totally unclear what
> > the disction is, what benefit 'marked for deletion" is and if it
> > possible to undelete, etc.
>
>   CAP REQUIREMENTS:
>
>     CAP MUST allow synchronization, meaning at a minimum that the CUA is
>     able to find and retrieve new, modified or deleted entries for a
>     given time period. The CUA MUST be able to find out which entries
>     ...
>
> The discussion that followed ...
> You have to be able to tag the entries as deleted, so that a later
> synchronization did not think they were new to the CS.
I am NOT talking about sync related issues.  Im talking about the overall CAP design and how deletions are dealt with in a consistant manner by ALL implementations..

Ive mentioned this distintion at least 2 times before and I guess its still not clear to some so thats probably a bad sign.  

There is NO prose anywhere describing all kinds of questions around deletions such as:

1: The ability to 'unDELETE' entries "marked for deletion".  Is this possible / allowed?  (This ability is essentially 'soft deletes' for those that recall that topic.)
1.1: Do I actually delete a 'marked for deletion' (MFD) entry from the CS by reissuing a DELETE with no MARK parameter or is there some other way to actually remove it?
1.2: Does changing the state of the MDF entry effectively undelete it (assuming thats possible in CAP)?
1.3: Can an MFD entry be modified in any way (using the right SELECT, etc)?

2: Must a CS support marking for deletion (and thus soft deletions) or can it just do actual deletions?
2.1: If a CS does not support marking for deletion then should it treat the MARK parameter as optional OR should it fail the DELETE?

3: Is MFD a required feature of a CS or can it just support DELETE but no MARK paramter?
3: If soft deletions are NOT mandatory we need some clear prose to describe how implementations that do not support it should respond to soft delete requests.

4: What are the effects of actually deleting an entry and not just MARKing it for deletion?  
4.1: Can a CUA just do this arbitrarily or SHOULD a CUA use MARK all the time?
4.2: What is the proper CUA & CS behaviour for dealing with responses to either an MFD or actually deleted (irregardless if the CS knows it was deleted or if it never existed yet!) entry?
4.3: Should we use DELETE to mean "mark for later deletion" and a _new_ (and yet undefined) command like PURGE or EXPUNGE to actually remove marked entries?

5: If we cannot unDELETE an entry then why should the CUA distinguish between actually deleting it (no MARK parameter) and marking it?  As far as the CUA is concerned the entry is gone.  As far as sync goes a sync engine just cares if the state is DELETED or not.

6: When does an MFD entry actually get removed from the system?

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 00608C3485256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 13:03:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04319 for ; Fri, 14 Mar 2003 13:03:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EHmN422870 for ietf-calendar-bks; Fri, 14 Mar 2003 09:48:23 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EHmMg22865 for ; Fri, 14 Mar 2003 09:48:22 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2EHmI1W027318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Mar 2003 09:48:22 -0800 Message-ID: <3E7215DD.4070701@Royer.com> Date: Fri, 14 Mar 2003 10:48:13 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000109070001020500090300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000109070001020500090300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 03/13/2003 05:49:20 PM: > > > Another issue from WAAAY back was the proliferation of top level > > > Response Codes in CAP. From Section 10.11. Response Codes: > > > ... > > > > So if you take the REQUEST-STATUS e-mail that I sent one or two > > weeks ago and add that into cap - does that solve *this* issue? > > RFC 2445 does not define a top level 5 class of error but we somehow > put/left them in RFC 2446. This is a known issue with 2446 from, oh, > about 2 or 3 years ago. This should be fixed when we post errata or an > update to 2445. Neither 2446 NOR your posting has any prose on what a > top level 5.x error code is. Nothing close to the cited table from 2445 > that clearly defines them. I am confused - part of my proposal was to renumber the error codes: I also propose that we call all 6.x codes CMD or CS codes and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to be 6.x codes. We may also want to renumber some of these that are not used prior to CAP anyway. So I agree. And please note that I proposed deleting the 5.x codes. I also think we should/could re-map them into a 'command set' of errors that are CAP specific. > Nor does CAP have anything like it. Nor does your message address the > addition of 6 new top level classes in CAP without defining them either! > Nor does your note address CAPs proliferation of so many near top level > response codes. They were defined, example: 9.0 An unrecognized command was received. Or an unsupported command was received. And I do not care if it is y.z or 9.x. > So I guess that would be a definite, No your note does NOT solve > _*this*_ issue. If it does, could you point out what I missed so I can > reconsider? > > > It was a proposal on how to merge/fix/update the REQUEST-STATUS > > codes. I do not recall that you responded. I got NO negative feedback > > and some positive feedback. So I assume the rest of the WG felt > > it addressed those issues? > > We were more involved with the ongoing discussion of ordering of results > and CREATE and the UTF-8 issues in case you hadn't noticed. I did not > respond as it fell out of the active view of things. In looking now I > see no negative OR postitive responses. When issues get squeezed out by > more active and drawn out threads then silence is not always acceptance; > it can be just a forgotten posting. Thanks Pat for calling for Last Call so Bruce would read and respond to the e-mail :-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000109070001020500090300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTQxNzQ4MTNaMCMGCSqGSIb3DQEJBDEWBBQO vkuxH5o5BmfxcNaKESmUOBZkUjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAu7dEg1umXkqK MkfpGJU99YVEKXAq8LFL5HCzSJEsjCFE9oUGOmGeAWr2eNwdHNIN+xwkhS/Y9aXdvtvljFHM gYrN8r9hjs1Ori+Ock5F2dqgFUNQNz+4RLqJn8dqrqcRG8b3zlRMfccL18lVdSjDx4g4i7Eo 54H0YxqrNkRdObmT6veiFkcjiQJJQvr/xPZbhfLpti+8w36zLKrfXycc8hDvCSuCjV7Ui27X 0b0zU7d1UVpUcFO045xeSbs1HMmyHarjLm41Oy7w7+OwH2OGnBICMqY7ct8U5gMy6Nf8uh/z 8p+uJDy3/SWjiuj81x5iY0A/CA7Pbm/1309hUjrTzgAAAAAAAA== --------------ms000109070001020500090300-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 13:56:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07936 for ; Fri, 14 Mar 2003 13:56:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EIlca27915 for ietf-calendar-bks; Fri, 14 Mar 2003 10:47:38 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2EIlbg27909 for ; Fri, 14 Mar 2003 10:47:37 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031413504032520 ; Fri, 14 Mar 2003 13:50:40 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 13:44:56 -0500 Message-ID: <3E722327.6030007@centive.com> Date: Fri, 14 Mar 2003 13:44:55 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce_Kahn@notesdev.ibm.com CC: ietf-calendar@imc.org Subject: Re: Partial equality match and sort order References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2003 18:44:56.0053 (UTC) FILETIME=[CEB19A50:01C2EA59] 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 asked on 03/10/2003: > > > Does locale sort ordering solve it? I thought that partial match > > > sorts were unspecified? > > > > What are partial matches? > > Doug does not mean partial in the sense of "some matched, some did > not". He seems to just be taking about substring ordering (at least > if you follow his examples). Ah. Substring ordering is definitely specified by any reasonable sorting rules; the CS should just stick to the ordering specified by the locale (assuming sorting makes it into the RFC, that is :-). -- /==========================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==========================================| |This is not a self-referential .signature.| \==========================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 14 14:01:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08273 for ; Fri, 14 Mar 2003 14:01:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EIpgW28499 for ietf-calendar-bks; Fri, 14 Mar 2003 10:51:42 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EIpeg28487 for ; Fri, 14 Mar 2003 10:51:40 -0800 (PST) To: ietf-calendar@imc.org Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: CAP Last call??? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 14 Mar 2003 13:51:46 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/14/2003 01:51:43 PM, Serialize complete at 03/14/2003 01:51:43 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug, I did not do a last call so "bruce would respond to an email." 8-) I did a last call because we need to get this draft out - sometime in my lifetime. Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 03/14/2003 12:48 Please respond to ietf-calendar To: "ietf-calendar@imc.org" cc: Subject: Re: CAP Last call??? Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 03/13/2003 05:49:20 PM: > > > Another issue from WAAAY back was the proliferation of top level > > > Response Codes in CAP. From Section 10.11. Response Codes: > > > ... > > > > So if you take the REQUEST-STATUS e-mail that I sent one or two > > weeks ago and add that into cap - does that solve *this* issue? > > RFC 2445 does not define a top level 5 class of error but we somehow > put/left them in RFC 2446. This is a known issue with 2446 from, oh, > about 2 or 3 years ago. This should be fixed when we post errata or an > update to 2445. Neither 2446 NOR your posting has any prose on what a > top level 5.x error code is. Nothing close to the cited table from 2445 > that clearly defines them. I am confused - part of my proposal was to renumber the error codes: I also propose that we call all 6.x codes CMD or CS codes and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to be 6.x codes. We may also want to renumber some of these that are not used prior to CAP anyway. So I agree. And please note that I proposed deleting the 5.x codes. I also think we should/could re-map them into a 'command set' of errors that are CAP specific. > Nor does CAP have anything like it. Nor does your message address the > addition of 6 new top level classes in CAP without defining them either! > Nor does your note address CAPs proliferation of so many near top level > response codes. They were defined, example: 9.0 An unrecognized command was received. Or an unsupported command was received. And I do not care if it is y.z or 9.x. > So I guess that would be a definite, No your note does NOT solve > _*this*_ issue. If it does, could you point out what I missed so I can > reconsider? > > > It was a proposal on how to merge/fix/update the REQUEST-STATUS > > codes. I do not recall that you responded. I got NO negative feedback > > and some positive feedback. So I assume the rest of the WG felt > > it addressed those issues? > > We were more involved with the ongoing discussion of ordering of results > and CREATE and the UTF-8 issues in case you hadn't noticed. I did not > respond as it fell out of the active view of things. In looking now I > see no negative OR postitive responses. When issues get squeezed out by > more active and drawn out threads then silence is not always acceptance; > it can be just a forgotten posting. Thanks Pat for calling for Last Call so Bruce would read and respond to the e-mail :-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Fri Mar 14 14:21:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09602 for ; Fri, 14 Mar 2003 14:21:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EJDAC29146 for ietf-calendar-bks; Fri, 14 Mar 2003 11:13:10 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EJDAg29142 for ; Fri, 14 Mar 2003 11:13:10 -0800 (PST) In-Reply-To: <3E710F30.6030409@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? - multipart. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 14:03:54 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 02:12:57 PM, Serialize complete at 03/14/2003 02:12:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0069827D85256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069827D85256CE9_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 03/13/2003 06:07:28 PM: > Could you please post what your know from the interop testing about > MIME support in iTIP? I know that Outlook does NOT support any kind of multipart MIME types in its CUA but its MUA is multipart savy. As such I had to perform some funky MIME bundling to send a richer rendering of iCalendar OR to use ATTACHments (which they totally ignore). More details can be found in the published interop results (I assume they are somewhere to be found on the WG site or in the WG list archives). Essentially because iMIP did NOT include any prose on multipart MIME support or any multipart MIME exmaples, some vendors chose to _only_ support text/calendar and thus make interop testing hard/kludgy! > I thought we agreed to not limit CAP to specific implementations. > So - all MIME multiplart (as specified in the CAPABILITY reply) > may be sent. Thats NOT the same as having actual text around how multipart would be structured or even an actual multipart example (I know we all hate to put them into prose as they become gospel but thats only because we fail to provide prose describing exactly how they should be handled/returned). For example, having some prose around how the CS would construct and return a VEVENT with an ALTREP for the DESCRIPTION or an ATTACHment or even both. As a combined example, a CUA would send the following to create a VEVENT on the CUs calendar (prefix all lines below with "C: " to be consistant w/CAP): Content-Type: multipart/related; boundary=example-1 --example-1 Content-Type: text/calendar; charset=UTF-8 BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Hand Hack Corp//NONSGML NotePad 6.0//EN CMD;ID=creation01:CREATE TARGET:Bruces_RedCross_Calendar BEGIN:VTIMEZONE TZID:Eastern BEGIN:STANDARD DTSTART:19501029T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:19500402T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID="Eastern":20030407T190000 DTEND;TZID="Eastern":20030407T210000 TRANSP:OPAQUE RDATE;VALUE=PERIOD:20030407T230000Z/20030408T010000Z, 20030505T230000Z/20030506T010000Z, 20030602T230000Z/20030603T010000Z, 20030707T230000Z/20030708T010000Z, 20030804T230000Z/20030805T010000Z, 20030901T230000Z/20030902T010000Z, 20031006T230000Z/20031007T010000Z DTSTAMP:20030306T165203Z CLASS:PUBLIC DESCRIPTION;ALTREP="CID:":Regular FAS Committee Meeting on the 1st Monday of every month without fail.\n\nYou can drag/drop this onto your Outlook (NOT Outlook Express though sorry!) Calendar and it will appear there as a normal meeting. If you have other products like Lotus Notes it should appear there magically already. SUMMARY:Monthly FAS Committee Meeting LOCATION:Waltham Area Office ORGANIZER;CN="Bruce Kahn":mailto:Bruce_Kahn@notesdev.ibm.com UID:7B13A53223F7104C85256CE1005B90CD-Lotus_Notes_Generated ATTACH;FMTTYPE=application/zip:CID: END:VEVENT END:VCALENDAR --example-1 Content-Type: Application/zip Content-Description: The zipped Agenda Content-Transfer-Encoding: base64 Content-Id: T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW NrIHF1YWNrCkUgSSBFIEkgTwo= --example-1 Content-Type: text/html Content-Id:

Regular FAS Committee Meeting on the 1st Monday of every month without fail.\n\nYou can drag/drop this onto your Outlook (NOT Outlook Express though sorry!) Calendar and it will appear there as a normal meeting. If you have other products like Lotus Notes it should appear there magically already.

--example-1-- A more complex example could be to replace the last MIME parth with one that was of Content-Type: multipart/related and that contained the both the text/html AND the image/gif that the HTML refers to! An alternate way to construct the workflow so that non-CUAs at least RENDER it properly is to construct the entry so that the text/calendar is part of a multipart/alternative like: Content-Type: multipart/alternative; boundary=------_alternative_1 ------_=_alternative_1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Summary: Monthly FAS Committee Meeting Start: Mon, 04 Mar 2003 07:00 PM End: Mon, 03 Mar 2003 09:00 PM Repeats: Every 1st Monday of the month thru October Location: Waltham Area Office Description: Regular FAS... ------_=_alternative_1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" 
            Summary: Monthly FAS Committee Meeting
              Start: Mon, 04 Mar 2003 07:00 PM
                End: Mon, 03 Mar 2003 09:00 PM
            Repeats: Every 1st Monday of the month thru October
           Location: Waltham Area Office
        Description: Regular FAS...
------_=_alternative_1 Content-Type: text/calendar; charset=UTF-8 BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Hand Hack Corp//NONSGML NotePad 6.0//EN CMD;ID=creation01:CREATE TARGET:Bruces_RedCross_Calendar ... ------_=_alternative_1-- This latter snippet is really geared towards Scheduling messages rather than Calendaring ones but it is still legal and valid to do in both cases. One unanswered question is how the CUA can tell the CS it only wants the text/calendar version / body part when is uses "SELECT * FROM VEVENT WHERE UID = "7B13A53223F7104C85256CE1005B90CD-Lotus_Notes_Generated"". Or will the CUA just get back the text/calendar bits and never see the text/html again? I never found a way to tell the CS "yes send me the ALTREPs on DESCRIPTION" or "No, I want just the DESCRIPTION in 7-bit form and NO ALTREP this time." Also, is there some way for the CUA to say SELECT all properties EXCEPT, say, the ATTACHments so that the CUA does not have to itterate over ALL possible properties in the SELECT clause and possibly miss or overlook some (ie: some extension or other iana-prop)?? 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 0069827D85256CE9_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 03/13/2003 06:07:28 PM:
> Could you please post what your know from the interop testing about
> MIME support in iTIP?
I know that Outlook does NOT support any kind of multipart MIME types in its CUA but its MUA is multipart savy.  As such I had to perform some funky MIME bundling to send a richer rendering of iCalendar OR to use ATTACHments (which they totally ignore).  

More details can be found in the published interop results (I assume they are somewhere to be found on the WG site or in the WG list archives).

Essentially because iMIP did NOT include any prose on multipart MIME support or any multipart MIME exmaples, some vendors chose to _only_ support text/calendar and thus make interop testing hard/kludgy!

> I thought we agreed to not limit CAP to specific implementations.
> So - all MIME multiplart (as specified in the CAPABILITY reply)
> may be sent.
Thats NOT the same as having actual text around how multipart would be structured or even an actual multipart example (I know we all hate to put them into prose as they become gospel but thats only because we fail to provide prose describing exactly how they should be handled/returned).

For example, having some prose around how the CS would construct and return a VEVENT with an ALTREP for the DESCRIPTION or an ATTACHment or even both.   As a combined example, a CUA would send the following to create a VEVENT on the CUs calendar (prefix all lines below with "C: " to be consistant w/CAP):

Content-Type: multipart/related; boundary=example-1

--example-1
Content-Type: text/calendar; charset=UTF-8

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Hand Hack Corp//NONSGML NotePad 6.0//EN
CMD;ID=creation01:CREATE
TARGET:Bruces_RedCross_Calendar
BEGIN:VTIMEZONE
TZID:Eastern
BEGIN:STANDARD
DTSTART:19501029T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19500402T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID="Eastern":20030407T190000
DTEND;TZID="Eastern":20030407T210000
TRANSP:OPAQUE
RDATE;VALUE=PERIOD:20030407T230000Z/20030408T010000Z,
 20030505T230000Z/20030506T010000Z,
 20030602T230000Z/20030603T010000Z,
 20030707T230000Z/20030708T010000Z,
 20030804T230000Z/20030805T010000Z,
 20030901T230000Z/20030902T010000Z,
 20031006T230000Z/20031007T010000Z
DTSTAMP:20030306T165203Z
CLASS:PUBLIC
DESCRIPTION;ALTREP="CID:<part3.msg.20030315T083000@host.com>":Regular FAS
 Committee Meeting on the 1st Monday of every month without fail.\n\nYou
 can drag/drop this onto your Outlook (NOT Outlook Express though sorry!)
 Calendar and it will appear there as a normal meeting.  If you have
 other products like Lotus Notes it should appear there magically already.
SUMMARY:Monthly FAS Committee Meeting
LOCATION:Waltham Area Office
ORGANIZER;CN="Bruce Kahn":mailto:Bruce_Kahn@notesdev.ibm.com
UID:7B13A53223F7104C85256CE1005B90CD-Lotus_Notes_Generated
ATTACH;FMTTYPE=application/zip:CID:<part2.msg.20030315T083000@host.com>
END:VEVENT
END:VCALENDAR
--example-1
Content-Type: Application/zip
Content-Description: The zipped Agenda
Content-Transfer-Encoding: base64
Content-Id: <part2.msg.20030315T083000@host.com>
T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
NrIHF1YWNrCkUgSSBFIEkgTwo=
--example-1
Content-Type: text/html
Content-Id: <part3.msg.20030315T083000@host.com>

<html><body>
<p><b>Regular FAS Committee Meeting</b> on the <b>1st</b> Monday of every month without
fail.\n\nYou can drag/drop this onto your Outlook (<B><I>NOT</I></B> Outlook Express though sorry!)
Calendar and it will appear there as a normal meeting.  If you have other products like <B>Lotus Notes</B>
it should appear there magically already.<img src=http://www.host.com/images/smiley.gif>
</p>
</body></html>
--example-1--

A more complex example could be to replace the last MIME parth with one that was of Content-Type: multipart/related and that contained the both the text/html AND the image/gif that the HTML refers to!

An alternate way to construct the workflow so that non-CUAs at least RENDER it properly is to construct the entry so that the text/calendar is part of a multipart/alternative like:

Content-Type: multipart/alternative; boundary=------_alternative_1

        ------_=_alternative_1
        Content-Transfer-Encoding: 7bit
        Content-Type: text/plain; charset="us-ascii"

            Summary: Monthly FAS Committee Meeting
              Start: Mon, 04 Mar 2003 07:00 PM
                End: Mon, 03 Mar 2003 09:00 PM
            Repeats: Every 1st Monday of the month thru October
           Location: Waltham Area Office
        Description: Regular FAS...

        ------_=_alternative_1
        Content-Transfer-Encoding: 7bit
        Content-Type: text/html; charset="us-ascii"

        <pre>
            Summary: Monthly FAS Committee Meeting
              Start: Mon, 04 Mar 2003 07:00 PM
                End: Mon, 03 Mar 2003 09:00 PM
            Repeats: Every 1st Monday of the month thru October
           Location: Waltham Area Office
        Description: Regular FAS...
        </pre>
        ------_=_alternative_1
        Content-Type: text/calendar; charset=UTF-8
       
        BEGIN:VCALENDAR
        VERSION:2.0
        PRODID:-//Hand Hack Corp//NONSGML NotePad 6.0//EN
        CMD;ID=creation01:CREATE
       TARGET:Bruces_RedCross_Calendar
        ...
        ------_=_alternative_1--

This latter snippet is really geared towards Scheduling messages rather than Calendaring ones but it is still legal and valid to do in both cases.

One unanswered question is how the CUA can tell the CS it only wants the text/calendar version / body part  when is uses "SELECT *  FROM VEVENT WHERE UID = "7B13A53223F7104C85256CE1005B90CD-Lotus_Notes_Generated"".   Or will the CUA just get back the text/calendar bits and never see the text/html again?  I never found a way to tell the CS "yes send me the ALTREPs on DESCRIPTION" or "No, I want just the DESCRIPTION in 7-bit form and NO ALTREP this time."

<DIGRESSION>
Also, is there some way for the CUA to say SELECT all properties EXCEPT, say, the ATTACHments so that the CUA does not have to itterate over ALL possible properties in the SELECT clause and possibly miss or overlook some (ie: some extension or other iana-prop)??
</DIGRESSION>

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 0069827D85256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 14:29:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09833 for ; Fri, 14 Mar 2003 14:29:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EJLxc29435 for ietf-calendar-bks; Fri, 14 Mar 2003 11:21:59 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EJLwg29431 for ; Fri, 14 Mar 2003 11:21:58 -0800 (PST) In-Reply-To: <3E71D840.8070708@centive.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 14:12:41 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 02:21:44 PM, Serialize complete at 03/14/2003 02:21:44 PM Content-Type: multipart/alternative; boundary="=_alternative 006A509285256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A509285256CE9_= Content-Type: text/plain; charset="US-ASCII" John wrote on 03/14/2003 08:25:20 AM: > > Are there any objects to saying that CAP MUST store > > ALL components, properties, and parameters sent to it by the CUA > > subject to VCAR rules? > > I just posted in favor; but then I thought of a clarification: we need > to permit the CS to ban components for administrative reasons. That would probably fall under the "subject to VCAR rules" clause Doug suggested. I for one am in favor of Dougs proposal. > people will need to be able to > build CSes that do virus filtering--and that's not something that can be > expressed in a reasonable VCAR syntax. ;-) Since when does someone call our VCAR syntax reasonable? Actually, its quite powerful and could easily be used to prevent someone saving ATTACHments or other properties and there is nothing preventing a CS from rejecting a CREATE or MODIFY command because the contents of the payload were infected. Thats a good reason use for the new 5.x error class ("Server Error", ie 5.13.2.9: "Command failed due to administrative restriction.") Or perhaps you are proposing we amend the clause to be "subject to VCARs or administrative policies"? 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 006A509285256CE9_= Content-Type: text/html; charset="US-ASCII"
John wrote on 03/14/2003 08:25:20 AM:
> > Are there any objects to saying that CAP MUST store
> > ALL components, properties, and parameters sent to it by the CUA
> > subject to VCAR rules?
>
> I just posted in favor; but then I thought of a clarification: we need
> to permit the CS to ban components for administrative reasons.  

That would probably fall under the "subject to VCAR rules" clause Doug suggested.

I for one am in favor of Dougs proposal.

>                                       people will need to be able to
> build CSes that do virus filtering--and that's not something that can be
> expressed in a reasonable VCAR syntax.  ;-)
Since when does someone call our VCAR syntax reasonable?  Actually, its quite powerful and could easily be used to prevent someone saving ATTACHments or other properties and there is nothing preventing a CS from rejecting a CREATE or MODIFY command because the contents of the payload were infected.  Thats a good reason use for the new 5.x error class ("Server Error", ie 5.13.2.9: "Command failed due to administrative restriction.")

Or perhaps you are proposing we amend the clause to be "subject to VCARs or administrative policies"?

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 006A509285256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 14:52:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10798 for ; Fri, 14 Mar 2003 14:52:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EJiUO00768 for ietf-calendar-bks; Fri, 14 Mar 2003 11:44:30 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2EJiTg00764 for ; Fri, 14 Mar 2003 11:44:29 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031414480100523 for ; Fri, 14 Mar 2003 14:48:01 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 14:42:17 -0500 Message-ID: <3E723099.6040400@centive.com> Date: Fri, 14 Mar 2003 14:42:17 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Last call??? References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2003 19:42:17.0429 (UTC) FILETIME=[D1E9E850:01C2EA61] 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: > > people will need to be able to > > build CSes that do virus filtering--and that's not something that > can be > > expressed in a reasonable VCAR syntax. ;-) > > Since when does someone call our VCAR syntax reasonable? Actually, > its quite powerful and could easily be used to prevent someone saving > ATTACHments or other properties Can it check for a virus signature? > Or perhaps you are proposing we amend the clause to be "subject to > VCARs or administrative policies"? Yes, that's all. -- /==========================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==========================================| |This is not a self-referential .signature.| \==========================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 14 15:08:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11718 for ; Fri, 14 Mar 2003 15:08:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EJuXH01446 for ietf-calendar-bks; Fri, 14 Mar 2003 11:56:33 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EJuWg01441 for ; Fri, 14 Mar 2003 11:56:32 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2EJuU1W028306 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Mar 2003 11:56:33 -0800 Message-ID: <3E7233E9.600@Royer.com> Date: Fri, 14 Mar 2003 12:56:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? - delete / marked for delete References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040107060201060703080705" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040107060201060703080705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > 1: The ability to 'unDELETE' entries "marked for deletion". Is this > possible / allowed? (This ability is essentially 'soft deletes' for > those that recall that topic.) In CAP Requirements: 4.3.1 Deferred Requirements for Operations on a Calendar ... - How to undelete a calendar. 4.4.3 Deferred Requirements for Component Management ... - Undelete and purge deleted calendar entries. 4.5.5 Deferred Requirements for Search ... - How to fetch all components marked for deletion in a certain range. This could include components somehow marked for deletion but not yet purged from the CS. So - out of scope? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040107060201060703080705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTQxOTU2MjVaMCMGCSqGSIb3DQEJBDEWBBQi 8t6OayY6BCPqtMCX7uNG1xfeljBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAwJ9oPb7t/5zQ 5Z6BNHeLfMIRiSznb/9FhgWn4lW/N4YlX3inXvysjM3DalB2YgnLWS5wE5cQ8fiJutYcNOsX bEFytqI1WSwZE13akdSOM+E/Kvg17sFp3XtDigV+IrR08Kx1tKGEOTwROCkVFt/calPxIJMN wcOMxWOtt2RFbbw8m5nvUYkrTpAFKyKAgm7OPimbX6w3U3fByOvA5FM8cDDP4fYjSjgq6yjz P25qgNAvkrMfMpQ/Qjt6m/S0ZEGw6g+cRXSMSIG1FrkSQ6noiBM8xcmV9e7t6X4vH0egch8R 4Z3FM851NNCAbVIPsEkGBRC1uvpsh+ewckTWivDEcgAAAAAAAA== --------------ms040107060201060703080705-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 15:17:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12827 for ; Fri, 14 Mar 2003 15:17:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EK6Je01714 for ietf-calendar-bks; Fri, 14 Mar 2003 12:06:19 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EK6Hg01710 for ; Fri, 14 Mar 2003 12:06:17 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2EK6F1W028382 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Mar 2003 12:06:18 -0800 Message-ID: <3E723632.8010407@Royer.com> Date: Fri, 14 Mar 2003 13:06:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? - multipart. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070005070409020400060601" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070005070409020400060601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 03/13/2003 06:07:28 PM: > > Could you please post what your know from the interop testing about > > MIME support in iTIP? > > ...lots of feedback... Would you be willing to write a draft on how to use Multipart with iCalendar - perhaps a FYI? It is more than a CAP issue. I *think* the WG would endorse it!? Then we do not have to decide for CAP, just decide that we will support multipart. Right now as you point out that knowledge is not written down. This would help the those implementing and help CAP ship sooner. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070005070409020400060601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTQyMDA2MTBaMCMGCSqGSIb3DQEJBDEWBBT+ 0LhdGSSBDZAZicjinhVw/cQq2DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAhtmEKo0uZx+s i4TRGbml40skvywAify9srCu2gh7pAoSEZP2vYrnPd1J/H5Dgw1/zCr5yMGvYxu816u23TPK omAhDJ9fJNvB8kLCTzWVl6VA8VBHYUAXWV5mYxeHQhNrmlzIaMHyNoCzbUPLlUUW3NsGZjYs onlCb5RlYnj7cnaogS21L86gddESoopDL5prpj44lcOJtSEujbA/4E8i5+DCeVrTV4MQB/LH 1RY4tH/uhWCOo9qF+bd9gR2kGUePvIZfofiehH+MFVYh2UuBbSHdwpyHmD/B5S7NQ0h2O/+w EisZKa6XEVFdqmi2yPTkwNuUcVQVkfx15sxNG45afwAAAAAAAA== --------------ms070005070409020400060601-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 15:34:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13446 for ; Fri, 14 Mar 2003 15:34:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EKOoD02684 for ietf-calendar-bks; Fri, 14 Mar 2003 12:24:50 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EKOng02680 for ; Fri, 14 Mar 2003 12:24:49 -0800 (PST) In-Reply-To: <3E7215DD.4070701@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Mar 2003 15:24:46 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/14/2003 03:24:51 PM, Serialize complete at 03/14/2003 03:24:51 PM Content-Type: multipart/alternative; boundary="=_alternative 007011B085256CE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007011B085256CE9_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 03/14/2003 12:48:13 PM: > > RFC 2445 does not define a top level 5 class of error but we somehow > > put/left them in RFC 2446. This is a known issue with 2446 from, oh, > > about 2 or 3 years ago. This should be fixed when we post errata or an > > update to 2445. Neither 2446 NOR your posting has any prose on what a > > top level 5.x error code is. Nothing close to the cited table from 2445 > > that clearly defines them. > > I am confused - part of my proposal was to renumber the error codes: Sorry, I dont see any such proposal in your "REQUEST-STATUS errors and issues for CAP" posting (http://www.imc.org/ietf-calendar/mail-archive/msg05916.html). Did I just miss it? > I also propose that we call all 6.x codes CMD or CS codes > and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to > be 6.x codes. > > We may also want to renumber some of these that are not > used prior to CAP anyway. > > So I agree. And please note that I proposed deleting the 5.x codes. > I also think we should/could re-map them into a 'command set' of > errors that are CAP specific. I dont think we need to delete 5.x codes, we merely need to clearly define their class ala RFC 2445 did for 1.x thru 4.x. Then we could start using it. We may want to make 5.x for "Server Errors" akin to the 3.xx class. You may want to collapse the 6.x thru 10.x codes down into 4.x since that is already defined in 2445 as for "Scheduling Error". (After all why have 1.x thru 4.x and then 6.x but NO 5.x??) > > Nor does CAP have anything like it. Nor does your message address the > > addition of 6 new top level classes in CAP without defining them either! > > Nor does your note address CAPs proliferation of so many near top level > > response codes. > > They were defined, example: > > > 9.0 An unrecognized command was received. > Or an unsupported command was received. This defines the code for 9.0, not the overall 9.x class. An unrecognized command can be classified as a server error OR a client error (esp. if the client can tell what the server supports). An unsupported command sounds like a 3.14 case ("Unsupported capability") and thats already defined in iTIP. The same goes for the rest of the 6.x thru 10.x cases; they are defined as explcit values (ala iTIP) but not as an overall class (ala iCalendar). I think if we consolidate them down and clearly define the 5.x (and 6.x?) cases then we can properly reassign them and consolidate accordingly. In any case it needs to be done before Last Call. > Thanks Pat for calling for Last Call so Bruce would read and > respond to the e-mail :-) This was not a Last Call call, it was a query to see if we should go to Last Call. Dont put the RFC before the draft... For the longest time your server was sending out CAP issues list postings. Have you gone over that to make sure all are resolved in the latest draft?? 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 007011B085256CE9_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 03/14/2003 12:48:13 PM:
> > RFC 2445 does not define a top level 5 class of error but we somehow
> > put/left them in RFC 2446.  This is a known issue with 2446 from, oh,
> > about 2 or 3 years ago.  This should be fixed when we post errata or an
> > update to 2445.  Neither 2446 NOR your posting has any prose on what a
> > top level 5.x error code is.  Nothing close to the cited table from 2445
> > that clearly defines them.  
>
> I am confused - part of my proposal was to renumber the error codes:
Sorry, I dont see any such proposal in your "REQUEST-STATUS errors and issues for CAP" posting (http://www.imc.org/ietf-calendar/mail-archive/msg05916.html).  Did I just miss it?

>    I also propose that we call all 6.x codes CMD or CS codes
>    and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to
>    be 6.x codes.
>
>      We may also want to renumber some of these that are not
>    used prior to CAP anyway.
>
> So I agree. And please note that I proposed deleting the 5.x codes.
> I also think we should/could re-map them into a 'command set' of
> errors that are CAP specific.
I dont think we need to delete 5.x codes, we merely need to clearly define their class ala RFC 2445 did for 1.x thru 4.x.  Then we could start using it.  We may want to make 5.x for "Server Errors" akin to the 3.xx class.  You may want to collapse the 6.x thru 10.x codes down into 4.x since that is already defined in 2445 as for "Scheduling Error".

(After all why have 1.x thru 4.x and then 6.x but NO 5.x??)

> > Nor does CAP have anything like it.  Nor does your message address the
> > addition of 6 new top level classes in CAP without defining them either!
> >  Nor does your note address CAPs proliferation of so many near top level
> > response codes.
>
> They were defined, example:
>
>
>    9.0              An unrecognized command was received.
>                            Or an unsupported command was received.
This defines the code for 9.0, not the overall 9.x class.  An unrecognized command can be classified as a server error OR a client error (esp. if the client can tell what the server supports).  An unsupported command sounds like a 3.14 case ("Unsupported capability") and thats already defined in iTIP.

The same goes for the rest of the 6.x thru 10.x cases; they are defined as explcit values (ala iTIP) but not as an overall class (ala iCalendar).  I think if we consolidate them down and clearly define the 5.x (and 6.x?) cases then we can properly reassign them and consolidate accordingly.  In any case it needs to be done before Last Call.

> Thanks Pat for calling for Last Call so Bruce would read and
> respond to the e-mail :-)
This was not a Last Call call, it was a query to see if we should go to Last Call.  Dont put the RFC before the draft...

For the longest time your server was sending out CAP issues list postings.  Have you gone over that to make sure all are resolved in the latest draft??

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 007011B085256CE9_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 17:35:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17070 for ; Fri, 14 Mar 2003 17:35:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EMH4N08525 for ietf-calendar-bks; Fri, 14 Mar 2003 14:17:04 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EMH2g08515 for ; Fri, 14 Mar 2003 14:17:02 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2EMH01W029232 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Mar 2003 14:17:03 -0800 Message-ID: <3E7254D7.1000905@Royer.com> Date: Fri, 14 Mar 2003 15:16:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080407080203010704040805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080407080203010704040805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 03/14/2003 12:48:13 PM: > > > RFC 2445 does not define a top level 5 class of error but we somehow > > > put/left them in RFC 2446. This is a known issue with 2446 from, oh, > > > about 2 or 3 years ago. This should be fixed when we post errata > or an > > > update to 2445. Neither 2446 NOR your posting has any prose on what a > > > top level 5.x error code is. Nothing close to the cited table from > 2445 > > > that clearly defines them. > > > > I am confused - part of my proposal was to renumber the error codes: >-+ > | > Sorry, I dont see any such proposal in your "REQUEST-STATUS errors and | > issues for CAP" posting | > (http://www.imc.org/ietf-calendar/mail-archive/msg05916.html). Did I | > just miss it? | > | > > I also propose that we call all 6.x codes CMD or CS codes | > > and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to | > > be 6.x codes. | > > | > > We may also want to renumber some of these that are not <-----------+ > > used prior to CAP anyway. The above text is from my post. > > So I agree. And please note that I proposed deleting the 5.x codes. > > I also think we should/could re-map them into a 'command set' of > > errors that are CAP specific. > > I dont think we need to delete 5.x codes, we merely need to clearly > define their class ala RFC 2445 did for 1.x thru 4.x. Then we could > start using it. We may want to make 5.x for "Server Errors" akin to the > 3.xx class. You may want to collapse the 6.x thru 10.x codes down into > 4.x since that is already defined in 2445 as for "Scheduling Error". > > (After all why have 1.x thru 4.x and then 6.x but NO 5.x??) Yea - I do not care what the numbers are. > > This was not a Last Call call, it was a query to see if we should go to > Last Call. Dont put the RFC before the draft... > > For the longest time your server was sending out CAP issues list > postings. Have you gone over that to make sure all are resolved in the > latest draft?? I was asked to stop sending it. Perhaps because it was getting old. I will happily start sending it again. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080407080203010704040805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTQyMjE2NTVaMCMGCSqGSIb3DQEJBDEWBBSM sJQHFX6MEAmQsPsjH/wy6K/iwTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEABNg/Grstu4ks Lda7OGeTSsI0Kj9GAnyzBN+LUFELujDoQ5Q7FJML50M246TfQ/oDXSGEsgMh4pVliUNxxHKG eeH1Hmzf6ga6D2zgJJ8uzaQL5ZpU/SrLmnmUXO17Q1NMPzz6vydCY0fHbYrjhe+THcfxZKy/ 0jFp1X5Pij/4TQwXimV0/cJ0s6rTtjODLyqwYDjvEeQaEiDy/H2/MHGSh/NCHLkJpBBp6ViS 5n2jLFCoyhuv3EpY9JxbuImicUoQzUjd5OS30uqLsYnhTPIV8QbP+4775QUlj/IM8zUCBNvf 3tXfQEtnsqZxhVgc0H4wKJKsAllGeZzZJwimyn7ZmAAAAAAAAA== --------------ms080407080203010704040805-- From owner-ietf-calendar@mail.imc.org Fri Mar 14 17:35:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17086 for ; Fri, 14 Mar 2003 17:35:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EMIrG08716 for ietf-calendar-bks; Fri, 14 Mar 2003 14:18:53 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EMIpg08709 for ; Fri, 14 Mar 2003 14:18:51 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h2EMIo1W029241 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Mar 2003 14:18:53 -0800 Message-ID: <3E725544.9090506@Royer.com> Date: Fri, 14 Mar 2003 15:18:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Last call??? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090306040107080802000307" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090306040107080802000307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > Doug, I did not do a last call so "bruce would respond to an email." 8-) I stand corrected :-) It is however nice to get feedback! > I did a last call because we need to get this draft out - sometime in my > lifetime. Yes I would also not look forward to a 10 year CAP anniversary. This November will be the 5 year anniversary of capreq-00 publication. We have two basic choices: (1) Fix the missing items - only (Plus only BUSTED items in CAP fixes). This would require that we all remind each other of NO CHANGES. or (2) We keep this up for at least a year more to debate how each removal/fix is going to be written with MUST/MAY/SHOULD. Missing: BEEP PROFILE: Any volunteer proposals. (AS in if YES send the *proposals* to the list). REQUEST-STATUS codes: I think the text is correct, we just need to fix the numbers associated with those errors. --------------ms090306040107080802000307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTQyMjE4NDRaMCMGCSqGSIb3DQEJBDEWBBTo PeOcTKbmiV3SHAPGQW4VlkhWajBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAGJl7PLnultYz +yJfHv5hxNN2T3Tisif5Hc8tjaTWUVOExpmDlXca+yS2+sHJQvNdq5an7yvuygkhaZeNRklY 9fLA1h5ZJBrvk7PTyBXHZkRGqWll+AMmE9RTsAkOngMo0eosEVBw/7kuU1phexW2T/dcr9oz ycSqkuRhufO0EpK7c6FEyazM5GtlA7Bhf9SpQxyrIMUZH28BaFEaVE6as4YLEFr2uh7quznu r6Tq9QSDylKOvY5m4HM3zap7Po43uKIWXtGhADTEKUfXuZH+/+6wVb4HWZKw4i3xFMDgYhp+ XN3uGyxHO2xGeArfYUnAOEbPXxEHD6v2MHjyWToJQwAAAAAAAA== --------------ms090306040107080802000307-- From owner-ietf-calendar@mail.imc.org Sat Mar 15 18:38:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29922 for ; Sat, 15 Mar 2003 18:38:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2FNRBG03892 for ietf-calendar-bks; Sat, 15 Mar 2003 15:27:11 -0800 (PST) Received: from bikini.cac.washington.edu (bikini.cac.washington.edu [128.95.135.104]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2FNRAg03887 for ; Sat, 15 Mar 2003 15:27:10 -0800 (PST) Received: (from slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) id h2FNV0E10136 for ietf-calendar@imc.org; Sat, 15 Mar 2003 15:31:00 -0800 (PST) Date: Sat, 15 Mar 2003 15:31:00 -0800 (PST) From: slh@bikini.cac.washington.edu Message-Id: <200303152331.h2FNV0E10136@bikini.cac.washington.edu> To: ietf-calendar@imc.org Subject: cap-10 sections 3.-6. comments Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: below are some suggested changes to and questions about sections 3. through 6. of the cap-10 draft. (same format as my previous msgs). 
----------------------------------------
[23;1273]

   CAP uses beep as the transport and authentication protocol.
            ****
[
intended to be rendered as ``BEEP'' or ``[BEEP]''?
]
----------------------------------------
[25;1363]

   GET-CAPABILITY - Query the capabilities the other end point of the
                                          ^ of
      session.  (Section 10.3)
----------------------------------------
[28;1529]

   Access rights are used to grant or deny access to calendars,
   components, properties, and parameters in a CS to a CU.  CAP defines
   a new component type called a Calendar Access Right (VCAR).
   Specifically, a "VCAR" component grants, or denies, UPNs the right to
                                          X          X
   search and write components, properties, and parameters on calendars
                                          X
   within a CS.
[
not certain of the punctionation rules for or- and and-lists,
but I think at least two of those three commas should not be there.
commas in or- and and-lists seems to be inconsistent in general in the draft.
]
----------------------------------------
[29;1587]

   CARID:REQUESTONLY -  Specifies the "GRANT" and "DENY" rules to UPNs
      other than the owner of the calendar the ability to write new
      objects with the property "METHOD" property set to the "REQUEST"
                       --------calendar
      value.  This CARID allows the owner to specify which UPNs are
      allowed to make scheduling requests.  An example definition for
      this VCAR is:
----------------------------------------
[32;1753]

   capurl   = "cap://" csid [ "/" relcalid ]
   csid     = hostport   ; As defined in Section 3.2.2 of RFC 2396
   relcalid = *uric      ; As defined in Section 2 of RFC 2396
   ***************************************************************
[
this seems to only allow CSID URIs and qualified CalIDs.
should it also allow relative CalIDs?
(looks like 8.36/TARGET and possibly other places say it should)

also, are qualified and relative CalIDs suppose to be special cases of CalID?
because (going back to section 1.3 [9;490]):
   Calendar Identifier (CalID) -  A globally unique identifier
      associated with a calendar.  Calendars reside within a CS.  See
      Qualified Calendar Identifier and Relative Calendar Identifier.
      All CalIDs start with "cap:".
]
----------------------------------------
[skipping 6.1]
----------------------------------------
[51;2832]

   Description: This data type is an identifier that denotes a CU or a
   group of CU.  A UPN is a RFC 822 compliant email address, with
   exceptions listed below, and in most cases it is deliverable to the
   CU.  In some cases it is identical to the CU's well known email
   address.  A CU's UPN MUST never be an e-mail address that is
   deliverable to a different person as there is no requirement that a
   person's UPN MUST BE their e-mail address.  A UPN is formatted as a
   user name followed by "@" followed by a Realm in the form of a valid,
   and unique, DNS domain name.  The user name MUST BE unique within the
   Realm.  In  it's simplest form it looks like "user@example.com".
              -----its
----------------------------------------
From owner-ietf-calendar@mail.imc.org Mon Mar 17 11:40:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19622 for ; Mon, 17 Mar 2003 11:40:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HGPnP15434 for ietf-calendar-bks; Mon, 17 Mar 2003 08:25:49 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HGPmg15430 for ; Mon, 17 Mar 2003 08:25:48 -0800 (PST) In-Reply-To: <3E7233E9.600@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? - delete / marked for delete MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 17 Mar 2003 11:25:39 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/17/2003 11:25:45 AM, Serialize complete at 03/17/2003 11:25:45 AM Content-Type: multipart/alternative; boundary="=_alternative 005A1D6985256CEC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A1D6985256CEC_= Content-Type: text/plain; charset="US-ASCII" Doug responed on 03/14/2003 02:56:25 PM: > > 1: The ability to 'unDELETE' entries "marked for deletion". Is this > > possible / allowed? (This ability is essentially 'soft deletes' for > > those that recall that topic.) > > In CAP Requirements: I cant find my expired copy of this nor is it on the WG web site. Ill assume the cited blocks are accurate unless someone w/a copy can say otherwise. > 4.4.3 Deferred Requirements for Component Management > ... > - Undelete and purge deleted calendar entries. > > 4.5.5 Deferred Requirements for Search > ... > - How to fetch all components marked for deletion in a certain > range. This could include components somehow marked for deletion > but not yet purged from the CS. > > So - out of scope? Not entirely. 4.4.3 does not cover the questions like "If my AA DELETEs a VEVENT and then I come in and try to modify it, what happens?" Nor does it address all of my posted questions. Those still uncovered are: 1.1: Do I actually delete a 'marked for deletion' (MFD) entry from the CS by reissuing a DELETE with no MARK parameter or is there some other way to actually remove it? 1.3: Can an MFD entry be modified in any way (using the right SELECT, etc)? 2: Must a CS support marking for deletion (and thus soft deletions) or can it just do actual deletions? 2.1: If a CS does not support marking for deletion then should it treat the MARK parameter as optional OR should it fail the DELETE? 3: Is MFD a required feature of a CS or can it just support DELETE but no MARK paramter? 3: If soft deletions are NOT mandatory we need some clear prose to describe how implementations that do not support it should respond to soft delete requests. 4: What are the effects of actually deleting an entry and not just MARKing it for deletion? 4.1: Can a CUA just do this arbitrarily or SHOULD a CUA use MARK all the time? 4.2: What is the proper CUA & CS behaviour for dealing with responses to either an MFD or actually deleted (irregardless if the CS knows it was deleted or if it never existed yet!) entry? (4.3 is semi answered but not entirely.) 5: If we cannot unDELETE an entry then why should the CUA distinguish between actually deleting it (no MARK parameter) and marking it? As far as the CUA is concerned the entry is gone. As far as sync goes a sync engine just cares if the state is DELETED or not. CAP currently has some prose that says how to do exactly what 4.5.5 says is NOT covered: 1.3. Definitions BOOKED - An object in the calendar store has one of three conceptual states. It is in the "UNPROCESSED" state, "BOOKED" state, or marked for deletion which is the "DELETED" state. How the implementation stores the state of any object is not a protocol issues and is not discussed. An object can be said to be booked, unprocessed, or marked for delete. [Snip, snip] 3. A "DELETED" state entry is created by sending a "DELETE" command with the "OPTION" parameter value set to "MARK". To retrieve any deleted object, simply do a query asking for any objects that were stored in the "DELETED" state. and 6.1.1.5. STATE() Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" depending on the state of the object. Used in a CAL-QUERY "WHERE" clause. Where "DELETED" is a component in the marked for delete state. Components that have been removed from the store are never returned. so #3 and 6.1.1.5 do what 4.5.5 says is not covered. Guess we need to remove it from CAP then (or revise the requirements??) CAP Requirements are NOT going to RFC so any "Items we are not covering in CAP 1.0" should become some part of the CAP RFC so that readers will understand why there are apparent holes in the design or unanswered questions. To some extent we have this with lines like: How synchronization is done is not specified in this memo. Perhaps we should fold in the CAP requirements bits on what is "out of scope" in to some section so that we set reader expectations accordingly. 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 005A1D6985256CEC_= Content-Type: text/html; charset="US-ASCII"
Doug responed on 03/14/2003 02:56:25 PM:
> > 1: The ability to 'unDELETE' entries "marked for deletion".  Is this
> > possible / allowed?  (This ability is essentially 'soft deletes' for
> > those that recall that topic.)
>
> In CAP Requirements:
I cant find my expired copy of this nor is it on the WG web site.  Ill assume the cited blocks are accurate unless someone w/a copy can say otherwise.

>        4.4.3   Deferred Requirements for Component Management
>    ...
>      - Undelete and purge deleted calendar entries.
>
>        4.5.5   Deferred Requirements for Search
>    ...
>          - How to fetch all components marked for deletion in a certain
>            range. This could include components somehow marked for deletion
>            but not yet purged from the CS.
>
> So - out of scope?
Not entirely.

4.4.3 does not cover the questions like "If my AA DELETEs a VEVENT and then I come in and try to modify it, what happens?"  Nor does it address all of my posted questions.  Those still uncovered are:

1.1: Do I actually delete a 'marked for deletion' (MFD) entry from the CS by reissuing a DELETE with no MARK parameter or is there some other way to actually remove it?
1.3: Can an MFD entry be modified in any way (using the right SELECT, etc)?

2: Must a CS support marking for deletion (and thus soft deletions) or can it just do actual deletions?
2.1: If a CS does not support marking for deletion then should it treat the MARK parameter as optional OR should it fail the DELETE?

3: Is MFD a required feature of a CS or can it just support DELETE but no MARK paramter?
3: If soft deletions are NOT mandatory we need some clear prose to describe how implementations that do not support it should respond to soft delete requests.

4: What are the effects of actually deleting an entry and not just MARKing it for deletion?  
4.1: Can a CUA just do this arbitrarily or SHOULD a CUA use MARK all the time?
4.2: What is the proper CUA & CS behaviour for dealing with responses to either an MFD or actually deleted (irregardless if the CS knows it was deleted or if it never existed yet!) entry?
(4.3 is semi answered but not entirely.)

5: If we cannot unDELETE an entry then why should the CUA distinguish between actually deleting it (no MARK parameter) and marking it?  As far as the CUA is concerned the entry is gone.  As far as sync goes a sync engine just cares if the state is DELETED or not.

CAP currently has some prose that says how to do exactly what 4.5.5 says is NOT covered:

1.3.  Definitions

BOOKED -
        An object in the calendar store has one of three conceptual states. It is in the "UNPROCESSED" state, "BOOKED" state, or marked for deletion which is the "DELETED" state. How the implementation stores the state of any object is not a protocol issues and is not discussed. An object can be said to be booked, unprocessed, or marked for delete.
[Snip, snip]
        3.        A "DELETED" state entry is created by sending a "DELETE" command with the "OPTION" parameter value set to "MARK". To retrieve any deleted object, simply do a query asking for any objects that were stored in the "DELETED" state.

and

6.1.1.5.  STATE()

        Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" depending on the state of the object. Used in a CAL-QUERY "WHERE" clause. Where "DELETED" is a component in the marked for delete state. Components that have been removed from the store are never returned.

so #3 and 6.1.1.5 do what 4.5.5 says is not covered.  Guess we need to remove it from CAP then (or revise the requirements??)

CAP Requirements are NOT going to RFC so any "Items we are not covering in CAP 1.0" should become some part of the CAP RFC so that readers will understand why there are apparent holes in the design or unanswered questions.  To some extent we have this with lines like:

How synchronization is done is not specified in this memo.

Perhaps we should fold in the CAP requirements bits on what is "out of scope" in to some section so that we set reader expectations accordingly.

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 005A1D6985256CEC_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 17 11:44:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19896 for ; Mon, 17 Mar 2003 11:44:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HGUfW15768 for ietf-calendar-bks; Mon, 17 Mar 2003 08:30:41 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HGUeg15764 for ; Mon, 17 Mar 2003 08:30:40 -0800 (PST) In-Reply-To: <3E723632.8010407@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? - multipart. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 17 Mar 2003 11:30:38 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/17/2003 11:30:37 AM, Serialize complete at 03/17/2003 11:30:37 AM Content-Type: multipart/alternative; boundary="=_alternative 005A923085256CEC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A923085256CEC_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 03/14/2003 03:06:10 PM: > Would you be willing to write a draft on how to use Multipart > with iCalendar - perhaps a FYI? It is more than a CAP issue. If I had more time I would but as it stands now my available WG time is dwindling as others start to take the load from me. Its definitely NOT just a CAP issue but Id like to make sure that CAP is very clear on the issue/usage given the interop issues from iTIP alone. I would dearly love to make sure CAP fixes that oversight before it goes to Last Call. > Then we do not have to decide for CAP, just decide that we will > support multipart. PLEASE include at least 1 (preferably a few more) examples using multipart so that CAP readers will have something to get their heads around as they implement it (correctly). Even if it is NOT mine, something rich... Please!! > Right now as you point out that knowledge > is not written down. This would help the those implementing > and help CAP ship sooner. Much of it should be in the CalConnect I - III notes somewhere. I know it was in the notes we sent to Pat/Bob at least once... 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 005A923085256CEC_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 03/14/2003 03:06:10 PM:
> Would you be willing to write a draft on how to use Multipart
> with iCalendar - perhaps a FYI? It is more than a CAP issue.
If I had more time I would but as it stands now my available WG time is dwindling as others start to take the load from me.  

Its definitely NOT just a CAP issue but Id like to make sure that CAP is very clear on the issue/usage given the interop issues from iTIP alone.  I would dearly love to make sure CAP fixes that oversight before it goes to Last Call.

> Then we do not have to decide for CAP, just decide that we will
> support multipart.

PLEASE include at least 1 (preferably a few more) examples using multipart so that CAP readers will have something to get their heads around as they implement it (correctly).  Even if it is NOT mine, something rich... Please!!

>                      Right now as you point out that knowledge
> is not written down. This would help the those implementing
> and help CAP ship sooner.
Much of it should be in the CalConnect I - III notes somewhere.  I know it was in the notes we sent to Pat/Bob at least once...

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 005A923085256CEC_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 17 11:48:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20082 for ; Mon, 17 Mar 2003 11:48:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HGYkV15948 for ietf-calendar-bks; Mon, 17 Mar 2003 08:34:46 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HGYjg15944 for ; Mon, 17 Mar 2003 08:34:45 -0800 (PST) In-Reply-To: <3E7254D7.1000905@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP Last call??? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 17 Mar 2003 11:34:43 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/17/2003 11:34:42 AM, Serialize complete at 03/17/2003 11:34:42 AM Content-Type: multipart/alternative; boundary="=_alternative 005AF1BB85256CEC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005AF1BB85256CEC_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 03/14/2003 05:16:55 PM: > The above text is from my post. Not in the posting I saw. Instead of including it inline Ill just send the archive URL: http://www.imc.org/ietf-calendar/mail-archive/msg05916.html I see no such copy of that prose in that message. Am I going blind? > I was asked to stop sending it. Perhaps because it was getting old. I > will happily start sending it again. It may be a bit old but it still has issues that need to be resolved (or marked as resolved) before we can go to Last Call. After all the intent was to make sure we dont overlook any issues, yes? Maybe we just dont need it automated every week... Im sure that some issues are not on it as the list has not been updated publically since 2001 but we should fix that too... 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 005AF1BB85256CEC_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 03/14/2003 05:16:55 PM:
> The above text is from my post.
Not in the posting I saw.  Instead of including it inline Ill just send the archive URL: http://www.imc.org/ietf-calendar/mail-archive/msg05916.html

I see no such copy of that prose in that message.  Am I going blind?

> I was asked to stop sending it. Perhaps because it was getting old. I
> will happily start sending it again.
It may be a bit old but it still has issues that need to be resolved (or marked as resolved) before we can go to Last Call.  After all the intent was to make sure we dont overlook any issues, yes?  Maybe we just dont need it automated every week...

Im sure that some issues are not on it as the list has not been updated publically since 2001 but we should fix that too...

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 005AF1BB85256CEC_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 17 13:07:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23097 for ; Mon, 17 Mar 2003 13:07:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HHpNF21020 for ietf-calendar-bks; Mon, 17 Mar 2003 09:51:23 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HHpLg21016 for ; Mon, 17 Mar 2003 09:51:21 -0800 (PST) Subject: IETF dinner - Monday night To: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Mon, 17 Mar 2003 12:51:21 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/17/2003 12:51:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a reminder to all of those in SFO. WE'll meet in the lobby of the Hilton at 6:30 pm to head to dinner somewhere. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 From owner-ietf-calendar@mail.imc.org Mon Mar 17 19:40:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10277 for ; Mon, 17 Mar 2003 19:40:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2I0Ulc12839 for ietf-calendar-bks; Mon, 17 Mar 2003 16:30:47 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2I0Ujg12835 for ; Mon, 17 Mar 2003 16:30:45 -0800 (PST) Subject: iSIP clarification To: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Mon, 17 Mar 2003 19:30:46 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/17/2003 07:30:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have been adding all CALSCH minutes to an indexed database on my server. In the process, I found minutes from Atlanta, 2002. There is a section on the Agenda where the editors of the iSIP draft did talk about their work. Since I did not attend the Atlanta meeting - I did not realize this had happened. So, my apologies to the editors of this draft regarding my "this is news to me" note. On that note, this is a good start - and I want to make sure I say to the list that the draft editors have tried to talk about their work. However, there still is no discussion on the list. I think if everyone reads this draft (http://www.ietf.org/internet-drafts/draft-pessi-ical-isip-01.txt) and then comment if they "don't like it" then that is goodness. I still have a problem with the draft saying it is one of our works. In fact, with no discussion on the list, and with nothing in our charter, it can not be called one of our drafts. So, that wording either needs to be removed from the draft. This will not be added to our charter. We are trying to close down - not add new drafts. Hope that helps clear up a bit of things. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 From owner-ietf-calendar@mail.imc.org Mon Mar 17 23:04:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16109 for ; Mon, 17 Mar 2003 23:04:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2I3sGi19793 for ietf-calendar-bks; Mon, 17 Mar 2003 19:54:16 -0800 (PST) Received: from mail-3.nethere.net (mail-3.nethere.net [66.63.128.72]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2I3sEg19788 for ; Mon, 17 Mar 2003 19:54:14 -0800 (PST) Received: (qmail 57230 invoked from network); 18 Mar 2003 03:54:18 -0000 Received: from psharpe2-egw.access.nethere.net (russellsharpe.com [66.63.144.101]) by mail-3.nethere.net with SMTP; 18 Mar 2003 03:54:18 -0000 (envelope-sender ) Message-ID: <3E769845.3080100@russellsharpe.com> Date: Mon, 17 Mar 2003 19:53:41 -0800 From: Paul Sharpe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Events spanning a day boundary 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 Can anyone get me up to speed on the issues relating to models and implementations of events which span a day boundary? Every user-agent (most recently Mozilla Calendar) I recall using doesn't seem to be able to handle what seems to me to be such common use case. I guess there's a good reason for that? paul -- Paul Sharpe Tel: 619 523 0100 Fax: 619 523 0101 Russell Sharpe, Inc mailto:paul@russellsharpe.com 4993 Niagara Avenue, Suite 209 http://www.russellsharpe.com/ San Diego, CA 92107-3185 "I can write a Perl script to do that." From owner-ietf-calendar@mail.imc.org Tue Mar 18 14:30:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25527 for ; Tue, 18 Mar 2003 14:30:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IJFEf01277 for ietf-calendar-bks; Tue, 18 Mar 2003 11:15:14 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IJFDg01272 for ; Tue, 18 Mar 2003 11:15:13 -0800 (PST) Received: from Royer.com (ca-75-219.wired.ietf56.ietf.org [130.129.75.219]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h2IJEwj6002728 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 18 Mar 2003 11:15:15 -0800 Message-ID: <3E777D88.2090604@Royer.com> Date: Tue, 18 Mar 2003 13:11:52 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Events spanning a day boundary References: <3E769845.3080100@russellsharpe.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 iCalendar has no such restriction. It is a vender issue. Paul Sharpe wrote: > > Can anyone get me up to speed on the issues relating to models and > implementations of events which span a day boundary? Every user-agent > (most recently Mozilla Calendar) I recall using doesn't seem to be able > to handle what seems to me to be such common use case. I guess there's > a good reason for that? > > paul > From owner-ietf-calendar@mail.imc.org Tue Mar 18 16:16:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00417 for ; Tue, 18 Mar 2003 16:16:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IL59c06399 for ietf-calendar-bks; Tue, 18 Mar 2003 13:05:09 -0800 (PST) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IL57g06380 for ; Tue, 18 Mar 2003 13:05:07 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 18 Mar 2003 21:04:39 +0000 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 18vODc-0001Yl-00 for ietf-calendar@imc.org; Tue, 18 Mar 2003 21:01:56 +0000 Date: Tue, 18 Mar 2003 21:01:56 +0000 (GMT) From: Libby Miller X-X-Sender: ecemm@mail.ilrt.bris.ac.uk To: ietf-calendar@imc.org Subject: do timezone descriptions have to be in the same document? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm wondering whether you have to include a vtimezone component for each vcalendar according to RFC 2445. You can certainly point to a TZURL: "The optional "TZURL" property is url value that points to a published VTIMEZONE definition. TZURL SHOULD refer to a resource that is accessible by anyone who might need to interpret the object. This SHOULD NOT normally be a file: URL or other URL that is not widely accessible." (RFC 2445 4.6.5 Time Zone Component) - so can we just point to the descriptions of VTIMEZONES we already have in separate files? (we have them in RDF: http://www.w3.org/2002/12/cal/tzd/) thanks for any pointers, and sorry if I've missed something. cheers Libby From owner-ietf-calendar@mail.imc.org Tue Mar 18 17:03:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02542 for ; Tue, 18 Mar 2003 17:03:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ILvqC09822 for ietf-calendar-bks; Tue, 18 Mar 2003 13:57:52 -0800 (PST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILvog09818 for ; Tue, 18 Mar 2003 13:57:50 -0800 (PST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2ILvrsJ026944 for ; Tue, 18 Mar 2003 13:57:53 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 18 Mar 2003 13:57:52 -0800 Received: from apple.com (vpn-scv-x0-217.apple.com [17.219.192.217]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h2ILvpd28874; Tue, 18 Mar 2003 13:57:51 -0800 (PST) Date: Tue, 18 Mar 2003 22:57:48 +0100 Subject: Re: do timezone descriptions have to be in the same document? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ietf-calendar@imc.org To: Libby Miller From: Olivier Gutknecht In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, March 18, 2003, at 10:01 PM, Libby Miller wrote: > I'm wondering whether you have to include a vtimezone component for > each vcalendar according to RFC 2445. Yes, this is a 'must'. See section 4.2.19 in RFC 2445, Time zone identifier definition. "An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object." And STANDARD and/or DAYLIGHT must also appear in the timezone definition, so a simple TZURL won't be enough. Ol. From owner-ietf-calendar@mail.imc.org Tue Mar 18 17:11:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02797 for ; Tue, 18 Mar 2003 17:11:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IM4JH10066 for ietf-calendar-bks; Tue, 18 Mar 2003 14:04:19 -0800 (PST) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IM4Ig10061 for ; Tue, 18 Mar 2003 14:04:18 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 18 Mar 2003 22:01:41 +0000 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 18vP7r-0002fJ-00; Tue, 18 Mar 2003 22:00:03 +0000 Date: Tue, 18 Mar 2003 22:00:03 +0000 (GMT) From: Libby Miller X-X-Sender: ecemm@mail.ilrt.bris.ac.uk To: Olivier Gutknecht cc: Libby Miller , ietf-calendar Subject: Re: do timezone descriptions have to be in the same document? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I guess I was just being picky, but could not 'specified' just be 'pointed to' using tzurl? Just a thought.. cheers Ol Libby On Tue, 18 Mar 2003, Olivier Gutknecht wrote: > On Tuesday, March 18, 2003, at 10:01 PM, Libby Miller wrote: > > I'm wondering whether you have to include a vtimezone component for > > each vcalendar according to RFC 2445. > > Yes, this is a 'must'. See section 4.2.19 in RFC 2445, Time zone > identifier definition. > "An individual "VTIMEZONE" calendar component MUST be specified for > each unique "TZID" parameter value specified in the iCalendar object." > And STANDARD and/or DAYLIGHT must also appear in the timezone > definition, so a simple TZURL won't be enough. > > Ol. > > > From owner-ietf-calendar@mail.imc.org Tue Mar 18 17:22:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03010 for ; Tue, 18 Mar 2003 17:22:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IMB1410453 for ietf-calendar-bks; Tue, 18 Mar 2003 14:11:01 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2IMB0g10445 for ; Tue, 18 Mar 2003 14:11:00 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031817142420881 for ; Tue, 18 Mar 2003 17:14:24 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 17:08:40 -0500 Message-ID: <3E7798E7.9020407@centive.com> Date: Tue, 18 Mar 2003 17:08:39 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: do timezone descriptions have to be in the same document? References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2003 22:08:40.0147 (UTC) FILETIME=[EE795230:01C2ED9A] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Libby Miller wrote: >I'm wondering whether you have to include a vtimezone component for >each vcalendar according to RFC 2445. > Yes. >You can certainly point to a >TZURL: > But the ABNF is clear that you MUST have at least one of standardc or daylightc. I'm not sure why TZURL exists, actually. Putting your timezone definition outside the iCalendar is a good way to get people to show up for the event at different times. -- /================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================| |I will not buy this .signature, it is scratched.| \================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 18 18:08:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04605 for ; Tue, 18 Mar 2003 18:08:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IMxCs13741 for ietf-calendar-bks; Tue, 18 Mar 2003 14:59:12 -0800 (PST) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IMxBg13737 for ; Tue, 18 Mar 2003 14:59:11 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 18 Mar 2003 22:58:48 +0000 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 18vQ2W-0003lM-00; Tue, 18 Mar 2003 22:58:36 +0000 Date: Tue, 18 Mar 2003 22:58:36 +0000 (GMT) From: Libby Miller X-X-Sender: ecemm@mail.ilrt.bris.ac.uk To: John Stracke cc: ietf-calendar@imc.org Subject: Re: do timezone descriptions have to be in the same document? In-Reply-To: <3E7798E7.9020407@centive.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ok, thanks for the info everyone. In an RDF context it would make sense to point to it, but I can see why you might want to put it in the file as well. cheers, Libby On Tue, 18 Mar 2003, John Stracke wrote: > > Libby Miller wrote: > > >I'm wondering whether you have to include a vtimezone component for > >each vcalendar according to RFC 2445. > > > Yes. > > >You can certainly point to a > >TZURL: > > > But the ABNF is clear that you MUST have at least one of standardc or > daylightc. > > I'm not sure why TZURL exists, actually. Putting your timezone > definition outside the iCalendar is a good way to get people to show up > for the event at different times. > > -- > /================================================\ > |John Stracke |jstracke@centive.com | > |Principal Engineer|http://www.centive.com | > |Centive |My opinions are my own. | > |================================================| > |I will not buy this .signature, it is scratched.| > \================================================/ > > > > From owner-ietf-calendar@mail.imc.org Wed Mar 19 01:31:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18201 for ; Wed, 19 Mar 2003 01:31:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J6O2D01620 for ietf-calendar-bks; Tue, 18 Mar 2003 22:24:02 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J6O0g01616 for ; Tue, 18 Mar 2003 22:24:00 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2J6Rfu29296 for ; Wed, 19 Mar 2003 08:27:41 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 08:24:03 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 08:24:02 +0200 Received: from localhost.localdomain (nokesa194126.europe.nokia.com [172.21.194.126]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id IAA10523; Wed, 19 Mar 2003 08:23:58 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h2J6NVBA016855; Wed, 19 Mar 2003 08:23:31 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h2J6NSPB016854; Wed, 19 Mar 2003 08:23:28 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: "pregen@egenconsulting.com" Cc: Pekka Pessi , "ietf-calendar@imc.org" Subject: Re: [Fwd: I-D ACTION:draft-pessi-ical-isip-01.txt] X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: ("pregen@egenconsulting.com"'s message of "Thu, 13 Mar 2003 15:41:05 -0500") References: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) Date: Wed, 19 Mar 2003 08:23:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 19 Mar 2003 06:24:02.0542 (UTC) FILETIME=[2266E0E0:01C2EDE0] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry for the delay, but I have had problems getting the sendmail smarthost pointing to the right server... "pregen@egenconsulting.com" writes: >Hi Pekka. The document references that it is a CALSCH working group >document. We've never seen it discussed here nor is it a part of our >charter. Can you fill us in a little on what this is? I hope that I have made it clear in the document that it is an individual submission, not a CALSCH WG item. I presented the document in the CALSCH and SIPPING WGs during November IETF, and got a few comments there. >I see why you think it is part of our WG - however, we sort of have to >get permission from our Area Directors to add items to our charter. I'd like to know what is the WG opinion here. Do you feel that it is OK to discuss the draft here on CALSCH list, or is some other forum, like the mailing list of SIPPING WG more appropriate? Do you feel that iSIP should be a CALSCH WG item? (In that case, update to the WG charter and AD approval is required.) In any case I'd like to keep the iCalendar people aware of the progress of iSIP, so they have a chance to object loudly if it would cause problems to iMIP or CAP. The discussion can always be redirected to a more appropriate mailing list, if required. Best regards, Pekka Pessi > To: "ietf-calendar@imc.org" > cc: > Subject: Re: [Fwd: I-D ACTION:draft-pessi-ical-isip-01.txt] >Doug Royer writes: >>I just noticed this e-mail on the IETF-general list. > I first received an automatic rejection reply, so I >thought I'll > have to send it again after cutoff period. Christmas >seems to > come twice this year. > The document now recommends using the "text/calendar" >format, > and the examples have been converted to the iCal. > There are a few open issues, most important I think is > *what to do when a recipient cannot be reached >immediately?* > If delivery falls back to some other system than SIP, >e.g., > e-mail, what kind of addressing could be used? How a >recipient > can process and an iSIP message if it is received via >non-SIP > means? > There is no applicability statement in the draft. Our >main > purpose here is to have off-line invitations to SIP >conferences > with standard format describing attendees and resources >of SIP > conferences. > Unfortunately I've had no opportunity to dig in iRIP, so >I > really can't say for sure what makes iSIP radically >different > from iRIP. In my opinion, iSIP is just an alternative >transport > for iTIP with its own addresses. SIP is an existing >transport, > which propably will live and prosper on its own. iSIP is >useful > even if there is no real calendaring system available by >SIP > user-agents. It also helps to integrate the calendar and > telephone applications in future mobile phones and PDAs. > Pekka Pessi >>-------- Original Message -------- >>Subject: I-D ACTION:draft-pessi-ical-isip-01.txt >>Date: Tue, 11 Mar 2003 06:46:22 -0500 >>From: Internet-Drafts@ietf.org >>Reply-To: Internet-Drafts@ietf.org >>To: IETF-Announce: ; >>A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> Title : iCalendar SIP-Based >Interoperability Protocol >> Author(s) : P. Pessi, M. Mela >> Filename : draft-pessi-ical-isip-01.txt >> Pages : 13 >> Date : 2003-3-10 >>This document, proposes a binding from the abstract iCalendar >>Transport-independent Interoperability Protocol (iTIP) using Session >>Initiation Protocol (SIP) as transport and SIP/SIPS URIs as >>addresses. This document proposes using the iTIP objects as a MIME >>payload format with SIP. iTIP is an abstract transport protocol for >>exchanging calendaring information between calendar systems using the >>iCalendar, Internet Calendaring and Scheduling Core Object >>Specification defined by RFC 2445. SIP is a application-layer >>signaling protocol for creating, modifying, and terminating >>multimedia sessions, retrieving user presence and sending instant >>messages. >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-pessi-ical-isip-01.txt >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body of the >message. >>Internet-Drafts are also available by anonymous FTP. Login with the >username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-pessi-ical-isip-01.txt". >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>Internet-Drafts can also be obtained by e-mail. >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-pessi-ical-isip-01.txt". >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use >this >> feature, insert the command "ENCODING mime" before the >"FILE" >> command. To decode the response(s), you will need >"munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been >split >> up into multiple messages), so check your local >documentation on >> how to manipulate these messages. >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. From owner-ietf-calendar@mail.imc.org Wed Mar 19 11:45:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25410 for ; Wed, 19 Mar 2003 11:45:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JGaEh27366 for ietf-calendar-bks; Wed, 19 Mar 2003 08:36:14 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JGaCg27362 for ; Wed, 19 Mar 2003 08:36:12 -0800 (PST) Subject: jabber at IETF To: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Wed, 19 Mar 2003 11:36:12 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/19/2003 11:36:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a reminder that you can join our meeting at 9:00 PST on Wednesday at the IETF meeting by joinging the CALSCH conference room. It's at conference.ietf.jabber.com. "See" you there. From owner-ietf-calendar@mail.imc.org Wed Mar 19 12:00:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25956 for ; Wed, 19 Mar 2003 12:00:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JGqT627828 for ietf-calendar-bks; Wed, 19 Mar 2003 08:52:29 -0800 (PST) Received: from office2.jigzaw.com (adsl-68-20-84-161.dsl.chcgil.ameritech.net [68.20.84.161]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JGqSg27824 for ; Wed, 19 Mar 2003 08:52:28 -0800 (PST) Received: from colatz ([10.0.0.10]) by office2.jigzaw.com (8.9.3/8.9.3) with SMTP id KAA22869 for ; Wed, 19 Mar 2003 10:37:25 -0600 Reply-To: From: "Shannon J. Clark" To: Subject: RE: jabber at IETF Date: Wed, 19 Mar 2003 10:52:53 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just a quick confirmation check - that's 9:00 AM pst? And, what date (or is it 9:00pm tonight?) Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com Sent: Wednesday, March 19, 2003 10:36 AM To: ietf-calendar@imc.org Subject: jabber at IETF This is a reminder that you can join our meeting at 9:00 PST on Wednesday at the IETF meeting by joinging the CALSCH conference room. It's at conference.ietf.jabber.com. "See" you there. From owner-ietf-calendar@mail.imc.org Wed Mar 19 12:35:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26964 for ; Wed, 19 Mar 2003 12:35:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JHRDI29091 for ietf-calendar-bks; Wed, 19 Mar 2003 09:27:13 -0800 (PST) Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2JHRCg29086 for ; Wed, 19 Mar 2003 09:27:12 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003031912304309554 for ; Wed, 19 Mar 2003 12:30:43 -0500 Received: from centive.com ([10.10.48.148]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Mar 2003 12:24:58 -0500 Message-ID: <3E78A7EA.3010008@centive.com> Date: Wed, 19 Mar 2003 12:24:58 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: jabber at IETF References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 17:24:58.0778 (UTC) FILETIME=[775C47A0:01C2EE3C] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Shannon J. Clark wrote: >Just a quick confirmation check - that's 9:00 AM pst? > It would have to be--Wednesday night is the plenary. But you can check the agenda online. -- /===========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===========================================================| |Sleep is for wimps--healthy, well-adjusted wimps, but wimps| |nonetheless. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Wed Mar 19 13:14:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28774 for ; Wed, 19 Mar 2003 13:14:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JHvR001977 for ietf-calendar-bks; Wed, 19 Mar 2003 09:57:27 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JHvQg01973 for ; Wed, 19 Mar 2003 09:57:26 -0800 (PST) In-Reply-To: <3E769845.3080100@russellsharpe.com> To: ietf-calendar@imc.org Subject: Re: Events spanning a day boundary MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 19 Mar 2003 12:57:19 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/19/2003 12:57:23 PM, Serialize complete at 03/19/2003 12:57:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0062763985256CEE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062763985256CEE_= Content-Type: text/plain; charset="US-ASCII" Paul asked on 03/17/2003 10:53:41 PM: > Can anyone get me up to speed on the issues relating to models and > implementations of events which span a day boundary? There are no issues in iCalendar like this. Entries can span any length of time desired. > Every user-agent > (most recently Mozilla Calendar) I recall using doesn't seem to be able > to handle what seems to me to be such common use case. I guess there's > a good reason for that? Probably its not easy/clean/simple way to render an entry that starts at, say, 7:15PM today and ends at 11:30AM tomorrow in a way that wont confuse users (in addition to rendering other normal sized entries as well). ("Is that start time 7:15 yesterday or the day before??" "There is so much to try and squeeze into the UI that realestate is at a premium...") Eventually we may have a good example of how to do it but so far noone has seemed to find a solution for it. 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 0062763985256CEE_= Content-Type: text/html; charset="US-ASCII"
Paul asked on 03/17/2003 10:53:41 PM:
> Can anyone get me up to speed on the issues relating to models and
> implementations of events which span a day boundary?  

There are no issues in iCalendar like this.  Entries can span any length of time desired.

>                                                       Every user-agent
> (most recently Mozilla Calendar) I recall using doesn't seem to be able
> to handle what seems to me to be such common use case.  I guess there's
> a good reason for that?
Probably its not easy/clean/simple way to render an entry that starts at, say, 7:15PM today and ends at 11:30AM tomorrow in a way that wont confuse users (in addition to rendering other normal sized entries as well).  ("Is that start time 7:15 yesterday or the day before??"  "There is so much to try and squeeze into the UI that realestate is at a premium...")  Eventually we may have a good example of how to do it but so far noone has seemed to find a solution for it.

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 0062763985256CEE_=-- From owner-ietf-calendar@mail.imc.org Wed Mar 19 13:19:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28995 for ; Wed, 19 Mar 2003 13:19:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JIEbx02899 for ietf-calendar-bks; Wed, 19 Mar 2003 10:14:37 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JIEZg02894 for ; Wed, 19 Mar 2003 10:14:35 -0800 (PST) Received: from garvey (12-233-1-188.client.attbi.com[12.233.1.188]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <20030319181432051008tlj4e>; Wed, 19 Mar 2003 18:14:32 +0000 Reply-To: From: "Seamus Garvey" To: Subject: RE: jabber at IETF Date: Wed, 19 Mar 2003 10:14:16 -0800 Message-ID: <000401c2ee43$5a854c60$bc01e90c@attbi.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C2EE00.4C620C60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3E78A7EA.3010008@centive.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C2EE00.4C620C60 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit You'd think a bunch of calendar people would eschew such a discussion... Seamus J. Garvey (925) 368-4700 (mobile) (703) 991-2654 (fax) ------=_NextPart_000_0005_01C2EE00.4C620C60 Content-Type: message/rfc822 Content-Disposition: attachment From: "John Stracke" Sender: To: References: Subject: Re: jabber at IETF Date: Wed, 19 Mar 2003 09:24:58 -0800 Organization: Centive Message-ID: <3E78A7EA.3010008@centive.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C2EE00.4C58E4A0" X-Mailer: Microsoft Outlook, Build 10.0.2627 List-Unsubscribe: X-Accept-Language: en-us, en X-OriginalArrivalTime: 19 Mar 2003 17:24:58.0778 (UTC) FILETIME=[775C47A0:01C2EE3C] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C2EE00.4C58E4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Shannon J. Clark wrote: >Just a quick confirmation check - that's 9:00 AM pst? > It would have to be--Wednesday night is the plenary. But you can check the agenda online. -- /===========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===========================================================| |Sleep is for wimps--healthy, well-adjusted wimps, but wimps| |nonetheless. | \===========================================================/ ------=_NextPart_000_0000_01C2EE00.4C58E4A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: jabber at IETF

Shannon J. Clark wrote:

>Just a quick confirmation check - that's 9:00 AM = pst?
>
It would have to be--Wednesday night is the = plenary.  But you can check
the agenda online.

--
/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\
|John Stracke      = |jstracke@centive.com        &nbs= p;           |
|Principal Engineer|http://www.centive.com  &nb= sp;           &nbs= p;   |
|Centive         &n= bsp; |My opinions are my = own.           &nb= sp;     |
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
|Sleep is for wimps--healthy, well-adjusted wimps, = but wimps|
|nonetheless.        &nb= sp;           &nbs= p;            = ;            =   |
\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/

------=_NextPart_000_0000_01C2EE00.4C58E4A0-- ------=_NextPart_000_0005_01C2EE00.4C620C60-- From owner-ietf-calendar@mail.imc.org Wed Mar 19 16:08:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08275 for ; Wed, 19 Mar 2003 16:08:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JKwTV12289 for ietf-calendar-bks; Wed, 19 Mar 2003 12:58:29 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JKwQg12275 for ; Wed, 19 Mar 2003 12:58:27 -0800 (PST) Subject: RE: jabber at IETF To: Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Wed, 19 Mar 2003 15:58:26 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/19/2003 03:58:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: touche 8-) "Seamus Garvey" To: Sent by: cc: owner-ietf-calendar@m Subject: RE: jabber at IETF ail.imc.org 03/19/03 01:14 PM Please respond to seamusjg You'd think a bunch of calendar people would eschew such a discussion... Seamus J. Garvey (925) 368-4700 (mobile) (703) 991-2654 (fax) ----- Message from "John Stracke" on Wed, 19 Mar 2003 09:24:58 -0800 ----- To: Subject: Re: jabber at IETF Shannon J. Clark wrote: >Just a quick confirmation check - that's 9:00 AM pst? > It would have to be--Wednesday night is the plenary. But you can check the agenda online. -- /===========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===========================================================| |Sleep is for wimps--healthy, well-adjusted wimps, but wimps| |nonetheless. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Wed Mar 19 17:16:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12137 for ; Wed, 19 Mar 2003 17:16:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JLrpI16125 for ietf-calendar-bks; Wed, 19 Mar 2003 13:53:51 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JLrmg16120 for ; Wed, 19 Mar 2003 13:53:48 -0800 (PST) Subject: Jabber log for calsch meeting To: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Wed, 19 Mar 2003 16:53:49 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/19/2003 04:53:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For those of you interested, and/or could not attend the CALSCH meeting, there is a log of the jabber discussions located at http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/calsch/ . In addition, the power point pages have been saved as text to a page on my website - temporarily - until they show up on the IETF pages. http://www.egenconsulting.com/EGCForms.nsf/sfo?openpage From owner-ietf-calendar@mail.imc.org Wed Mar 19 17:30:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12588 for ; Wed, 19 Mar 2003 17:30:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JMKFh16960 for ietf-calendar-bks; Wed, 19 Mar 2003 14:20:15 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JMKDg16950 for ; Wed, 19 Mar 2003 14:20:13 -0800 (PST) Subject: RE: jabber at IETF To: Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Wed, 19 Mar 2003 17:20:12 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/19/2003 05:20:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My apologies to the list - it's 9:00 PST AM. You'd think a calendaring person would get it right - or send you an icalendar object to add to all the different calendars. Right... ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Shannon J. Clark" To: Sent by: cc: owner-ietf-calendar@m Subject: RE: jabber at IETF ail.imc.org 03/19/03 11:52 AM Please respond to shannon Just a quick confirmation check - that's 9:00 AM pst? And, what date (or is it 9:00pm tonight?) Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com Sent: Wednesday, March 19, 2003 10:36 AM To: ietf-calendar@imc.org Subject: jabber at IETF This is a reminder that you can join our meeting at 9:00 PST on Wednesday at the IETF meeting by joinging the CALSCH conference room. It's at conference.ietf.jabber.com. "See" you there. From owner-ietf-calendar@mail.imc.org Wed Mar 19 21:51:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21598 for ; Wed, 19 Mar 2003 21:51:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K2kRi01891 for ietf-calendar-bks; Wed, 19 Mar 2003 18:46:27 -0800 (PST) Received: from asclepius.uwa.edu.au (asclepius.uwa.edu.au [130.95.128.56]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K2kPg01887 for ; Wed, 19 Mar 2003 18:46:25 -0800 (PST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id E2C4C2F8A36; Thu, 20 Mar 2003 10:46:25 +0800 (WST) Received: from tartarus.uwa.edu.au (tartarus.uwa.edu.au [130.95.128.3]) by asclepius.uwa.edu.au (Postfix) with ESMTP id C56A72F81D2; Thu, 20 Mar 2003 10:46:25 +0800 (WST) Received: from tartarus.uwa.edu.au (tartarus.uwa.edu.au [130.95.128.3]) by tartarus.uwa.edu.au (Postfix) with ESMTP id E3AC5F5A4; Thu, 20 Mar 2003 10:46:25 +0800 (WST) Date: Thu, 20 Mar 2003 10:46:25 +0800 (WST) From: Mark Tearle X-X-Sender: mtearle@tartarus.uwa.edu.au To: pregen@egenconsulting.com Cc: shannon@jigzaw.com, Subject: RE: jabber at IETF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 Mar 2003 pregen@egenconsulting.com wrote: > Subject: RE: jabber at IETF > > My apologies to the list - it's 9:00 PST AM. You'd think a calendaring > person would get it right - or send you an icalendar object to add to all > the different calendars. Right... > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 > Or just posting it in UTC..... not all the world groks US timezones. Yours Mark PS. Most Australian current affairs and news is produced on the east coast (UTC+10) - occasionally they refer to an event happening at say 8pm Australian time - which completely wrong for the part of of Australia (the west) which I live in which is UTC+8 .... -- Mark Tearle - mark@tearle.com "... and the sea will grant each man new hope, as sleep brings dreams of home" - Christopher Columbus From owner-ietf-calendar@mail.imc.org Fri Mar 21 19:17:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03184 for ; Fri, 21 Mar 2003 19:17:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2M0CK624439 for ietf-calendar-bks; Fri, 21 Mar 2003 16:12:20 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2M0CHg24431 for ; Fri, 21 Mar 2003 16:12:18 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h2M0C5j6003993 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Mar 2003 16:12:20 -0800 Message-ID: <3E7BAA50.3080707@Royer.com> Date: Fri, 21 Mar 2003 17:12:00 -0700 From: Doug Royer Reply-To: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Getting close to final draft 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 Folks - it is very important that any feedback to the -10.txt version of the draft come in soon. Our plan is to be done VERY soon. We are looking for things that are BUSTED. What will be in the -11.txt version that we hope will be the LAST CALL version. We will be doing the last "last call" *SOON*! Sorting will be removed and will be submitted as a separate draft. Saving of VQUERY's will be removed. we will keep the QUERYID property in reserve so that it can be added later in a separate draft. Clarify that marked for delete is the old tombstone flag and is only (currently) used for the unspecified synchronization. Clarify that it is unspecified how/when you clean those out. Clarify that un-delete is unspecified. Adding a MULTIPART example (thanks Bruce). Typo fixes, ABNF fixes, and miscellaneous grammar fixes. The CALSCH meeting in San Francisco was interesting as were the hallway, and dinner talks. By directive from the IETF area directors - CAP will be shipping *SOON*. Any changes from this point forward will require a HUGE majority before being considered for the -11.txt version. There are over 300 subscribers to this list and a handful of requests is not a huge number. Please do not shoot the messenger :-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Fri Mar 21 21:55:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06018 for ; Fri, 21 Mar 2003 21:55:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2M2kXh02635 for ietf-calendar-bks; Fri, 21 Mar 2003 18:46:33 -0800 (PST) Received: from mail-3.nethere.net (mail-3.nethere.net [66.63.128.72]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2M2kWg02631 for ; Fri, 21 Mar 2003 18:46:32 -0800 (PST) Received: (qmail 11064 invoked from network); 22 Mar 2003 02:46:35 -0000 Received: from psharpe2-egw.access.nethere.net (russellsharpe.com [66.63.144.101]) by mail-3.nethere.net with SMTP; 22 Mar 2003 02:46:35 -0000 (envelope-sender ) Message-ID: <3E7BCE63.4000607@russellsharpe.com> Date: Fri, 21 Mar 2003 18:45:55 -0800 From: Paul Sharpe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Events spanning a day boundary References: In-Reply-To: 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 Bruce_Kahn@notesdev.ibm.com wrote: > > Paul asked on 03/17/2003 10:53:41 PM: > > Can anyone get me up to speed on the issues relating to models and > > implementations of events which span a day boundary? > > There are no issues in iCalendar like this. Entries can span any length > of time desired. > > > Every user-agent > > (most recently Mozilla Calendar) I recall using doesn't seem to be able > > to handle what seems to me to be such common use case. I guess there's > > a good reason for that? > > Probably its not easy/clean/simple way to render an entry that starts > at, say, 7:15PM today and ends at 11:30AM tomorrow in a way that wont > confuse users (in addition to rendering other normal sized entries as > well). ("Is that start time 7:15 yesterday or the day before??" "There > is so much to try and squeeze into the UI that realestate is at a > premium...") Eventually we may have a good example of how to do it but > so far noone has seemed to find a solution for it. Thanks for all of the responses, in summary: * Not an iCalendar constraint. * Ximian Evolution implements it and renders it pretty well. paul -- Paul Sharpe Tel: 619 523 0100 Fax: 619 523 0101 Russell Sharpe, Inc mailto:paul@russellsharpe.com 4993 Niagara Avenue, Suite 209 http://www.russellsharpe.com/ San Diego, CA 92107-3185 "I can write a Perl script to do that." From owner-ietf-calendar@mail.imc.org Sat Mar 22 01:31:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08758 for ; Sat, 22 Mar 2003 01:31:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2M6KYn06070 for ietf-calendar-bks; Fri, 21 Mar 2003 22:20:34 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2M6KVg06066 for ; Fri, 21 Mar 2003 22:20:31 -0800 (PST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2M6KU64069914 for ; Sat, 22 Mar 2003 01:20:30 -0500 Received: from d03nm694.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2M6KTu2129794 for ; Fri, 21 Mar 2003 23:20:30 -0700 Importance: Normal MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: ietf-calendar Non-sub: xCal attach property X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Yael Shaham-Gafni Date: Fri, 21 Mar 2003 22:20:27 -0800 X-MIMETrack: Serialize by Router on D03NM694/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 03/21/2003 23:20:29, Serialize complete at 03/21/2003 23:20:29 Content-Type: multipart/alternative; boundary="=_alternative 0022CF7C88256CF1_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0022CF7C88256CF1_= Content-Type: text/plain; charset="us-ascii" Hi, I'm looking at the xCal specification (http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt), and had a question regarding the attach property. The definition of the attach XML is: My question is: is the fmttype an attribute of only binary attachments, or can it also be the attribute of a uri attachment? by reading the iCalendar spec I understood it was the latter, but this is not reflected in the XML definition. Regards, Yael Shaham-Gafni eTechnologies, IBM Almaden Research Center shaham@us.ibm.com Phone: (408) 927-2455, Tie: 457-2455 Fax: (408) 927-3030 In the age of human dissolution of Nature, we can only save ourselves and the planet as we know it by eschewing greed, consumption and wealth in favour of Wisdom. --=_alternative 0022CF7C88256CF1_= Content-Type: text/html; charset="us-ascii"


Hi,
I'm looking at the xCal specification
(http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt),
and had a question regarding the attach property.
The definition of the attach XML is:
         <!ELEMENT attach (extref | b64bin)>
         <!-- extref holds a reference to an external entity that -->
         <!-- has the attachment. b64bin holds the inline BASE64 encoded -->
         <!-- binary data for the attachment as defined in RFC 2045. -->
         <!ELEMENT extref EMPTY>
             <!ATTLIST extref uri ENTITY #REQUIRED>
         <!ELEMENT b64bin (#PCDATA)>
             <!ATTLIST b64bin fmttype CDATA             #REQUIRED>
             <!ATTLIST b64bin value   NOTATION (BINARY) #IMPLIED>

My question is: is the fmttype an attribute of only binary attachments, or
can it also be the attribute of a uri attachment?
by reading the iCalendar spec I understood it was the latter, but this is
not reflected in the XML definition.
Regards,

Yael Shaham-Gafni
eTechnologies, IBM Almaden Research Center
shaham@us.ibm.com
Phone: (408) 927-2455, Tie: 457-2455
Fax: (408) 927-3030

In the age of human dissolution of Nature, we can only save ourselves and
the planet as we know it by eschewing greed, consumption and wealth in
favour of Wisdom.
 --=_alternative 0022CF7C88256CF1_=-- From owner-ietf-calendar@mail.imc.org Sun Mar 23 12:21:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05730 for ; Sun, 23 Mar 2003 12:21:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2NHB3021044 for ietf-calendar-bks; Sun, 23 Mar 2003 09:11:03 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NHB1g21038 for ; Sun, 23 Mar 2003 09:11:01 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h2NHAoj6008694 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 23 Mar 2003 09:10:54 -0800 Message-ID: <3E7DEA94.6070203@Royer.com> Date: Sun, 23 Mar 2003 10:10:44 -0700 From: Doug Royer Reply-To: xcal-dev@inet-consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcal-dev@inet-consulting.com CC: "ietf-calendar@imc.org" Subject: Re: ietf-calendar Non-sub: xCal attach property References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030003090100050608060906" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030003090100050608060906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The xCal mailing list is 'xcal-dev@inet-consulting.com'. To subscribe: xcal-dev-request@inet-consulting.com I have Cc'd that list and set the reply-to to be that list for this message. In the newest (being edited an not yet sent) xcal: all components are tags. all properties are tags. all parameters are tag attributes. The mapping is 1:1 to iCalendar, so if it is valid in iCalendar it is valid in xCal. If it is invalid in iCalendar, it is invalid in xCal. -Doug Yael Shaham-Gafni wrote: > > > > Hi, > I'm looking at the xCal specification > (http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt), > and had a question regarding the attach property. > The definition of the attach XML is: > > > > > > > > > > > My question is: is the fmttype an attribute of only binary attachments, or > can it also be the attribute of a uri attachment? > by reading the iCalendar spec I understood it was the latter, but this is > not reflected in the XML definition. > Regards, > > Yael Shaham-Gafni > eTechnologies, IBM Almaden Research Center > shaham@us.ibm.com > Phone: (408) 927-2455, Tie: 457-2455 > Fax: (408) 927-3030 > > In the age of human dissolution of Nature, we can only save ourselves and > the planet as we know it by eschewing greed, consumption and wealth in > favour of Wisdom. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030003090100050608060906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMjMxNzEwNDVaMCMGCSqGSIb3DQEJBDEWBBSD qEo/548T8mRUaKbgBFiHi6KO0DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAh0UD4J/yDcVz tjHR4HXLbJ8ka4FoZDIF8HzikCWS1xzcEw0qfNuBllVM452hfUTmgZLcjLmn71QUc9WaIjsY J3F8bGX65OiaCa7skd85PNdj30DbzMrgFTVYGTlz6sTJi0rLkELHYn6BJYf5Fia5WwAVZLFb 2DR2mw/eeEUrWJVkFt4jNQudIE0wjapYuvTPYRoNYWP6FBJy/jtvwwBlsTGe73ivvkoIHaLR wxaUy0SVv9giSSTq6oGihw/BuE4teTnmp9BzlitEh0CfqriELAXVCJKHLitCZze6h9DDznQR +lKgyab7Bxx4LzIxM/FXy6r+rn8UgxvsSCL/pjA5TQAAAAAAAA== --------------ms030003090100050608060906-- From owner-ietf-calendar@mail.imc.org Sun Mar 23 15:11:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09302 for ; Sun, 23 Mar 2003 15:11:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2NK3AX00538 for ietf-calendar-bks; Sun, 23 Mar 2003 12:03:10 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NK38g00534 for ; Sun, 23 Mar 2003 12:03:08 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h2NK35j6009889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 23 Mar 2003 12:03:08 -0800 Message-ID: <3E7E12F4.7040206@Royer.com> Date: Sun, 23 Mar 2003 13:03:00 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Updated calsch.org web site. Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020105000705080108010702" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020105000705080108010702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have updated the http://calsch.org/deafts web page. Now the 'drafts' page now includes: rfc 2445 rfc 2446 rfc 2447 rfc 2793 rfc 3283 draft-ietf-calsch-cap-00.txt draft-ietf-calsch-cap-01.txt draft-ietf-calsch-cap-02.txt draft-ietf-calsch-cap-03.txt draft-ietf-calsch-cap-04.txt draft-ietf-calsch-cap-05.txt draft-ietf-calsch-cap-06.txt draft-ietf-calsch-cap-07.txt draft-ietf-calsch-cap-08.txt draft-ietf-calsch-cap-09.txt draft-ietf-calsch-cap-10.txt draft-ietf-calsch-capreq-00.txt draft-ietf-calsch-capreq-01.txt draft-ietf-calsch-capreq-02.txt draft-ietf-calsch-capreq-03.txt draft-ietf-calsch-capreq-04.txt draft-ietf-calsch-cih-00.txt draft-ietf-calsch-cip-00.txt draft-ietf-calsch-crisp-00.txt draft-ietf-calsch-crisp-01.txt draft-ietf-calsch-csct-00.txt draft-ietf-calsch-ical-00.txt draft-ietf-calsch-ical-01.txt draft-ietf-calsch-ical-02.txt draft-ietf-calsch-ical-03.txt draft-ietf-calsch-ical-04.txt draft-ietf-calsch-ical-05.txt draft-ietf-calsch-ical-06.txt draft-ietf-calsch-ical-07.txt draft-ietf-calsch-ical-08.txt draft-ietf-calsch-ical-09.txt draft-ietf-calsch-ical-10.txt draft-ietf-calsch-ical-11.txt draft-ietf-calsch-ical-issues-00.txt draft-ietf-calsch-ical-issues-01.txt draft-ietf-calsch-ical21-00.txt draft-ietf-calsch-icalfpi-00.txt draft-ietf-calsch-icalfpi-01.txt draft-ietf-calsch-imip-00.txt draft-ietf-calsch-imip-01.txt draft-ietf-calsch-imip-02.txt draft-ietf-calsch-imip-03.txt draft-ietf-calsch-imip-04.txt draft-ietf-calsch-imip-05.txt draft-ietf-calsch-imip-06.txt draft-ietf-calsch-imip-07.txt draft-ietf-calsch-imp-guide-00.txt draft-ietf-calsch-imp-guide-01.txt draft-ietf-calsch-imp-guide-02.txt draft-ietf-calsch-inetcal-guide-00.txt draft-ietf-calsch-inetcal-guide-01.txt draft-ietf-calsch-irip-00.txt draft-ietf-calsch-irip-01.txt draft-ietf-calsch-irip-02.txt draft-ietf-calsch-irip-03.txt draft-ietf-calsch-itip-01.txt draft-ietf-calsch-itip-02.txt draft-ietf-calsch-itip-03.txt draft-ietf-calsch-itip-04.txt draft-ietf-calsch-itip-05.txt draft-ietf-calsch-itip-06.txt draft-ietf-calsch-itip-part1-00.txt draft-ietf-calsch-itip-part2-00.txt draft-ietf-calsch-itip-part3-00.txt draft-ietf-calsch-locating-00.txt draft-ietf-calsch-locating-01.txt draft-ietf-calsch-locating-02.txt draft-ietf-calsch-many-xcal-00.txt draft-ietf-calsch-many-xcal-01.txt draft-ietf-calsch-many-xcal-02.txt draft-ietf-calsch-mod-00.txt draft-ietf-calsch-mod-01.txt draft-ietf-calsch-mod-02.txt draft-ietf-calsch-mod-03.txt draft-ietf-calsch-rtreq-00.txt draft-ietf-calsch-scap-00.txt draft-ietf-calsch-sch-00.txt draft-many-ical-ski-06.txt draft-pessi-ical-isip-01.txt -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020105000705080108010702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMjMyMDAzMDBaMCMGCSqGSIb3DQEJBDEWBBRQ EVZHZb+P1qE7tTG1ZknKjFbSTzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAdOmVYvN88+I5 QuY9R8HlLtRZCTN58yp/7PYtfWcckgNFiNt4uzNHBrxKf4bhkbO6PeYRrX59nCWk8YAR4fD1 Umuayvyr7LcbtkNjavVZr7pjh3385kjuWwW0Kq7t+zhCqmj97h1KJD1zjmE4cVcm7n/dQ3XG bXRgr5RYrBgZiiwsQ+VdN/Xcn6ANe0q3Tezgg1yYLJsGakm+WfM9CUcirWJprtbrxNBx7zf3 Zfhosdnjqg+mDkvWN2lYB6KQUiJtmGt5aYsR+Aq3sF3M/4epEI8kj41I5F3biDHfwykpttYc 3knnJbqVh6pnOtWn7j6Ee9GuQmF2t7e8M4UnIUCLYwAAAAAAAA== --------------ms020105000705080108010702-- From owner-ietf-calendar@mail.imc.org Sun Mar 23 23:30:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21617 for ; Sun, 23 Mar 2003 23:30:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2O4LDs17231 for ietf-calendar-bks; Sun, 23 Mar 2003 20:21:13 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2O4LBg17226 for ; Sun, 23 Mar 2003 20:21:12 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h2O4LAj6013053 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 23 Mar 2003 20:21:15 -0800 Message-ID: <3E7E87AE.6060503@Royer.com> Date: Sun, 23 Mar 2003 21:21:02 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (OOPS) Updated calsch.org web site. References: <3E7E12F4.7040206@Royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000006050205090907040704" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000006050205090907040704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (OOPS) Doug Royer wrote: > > > I have updated the http://calsch.org/deafts web page. That is: http://www.calsch.org/ietf/drafts.html -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000006050205090907040704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMjQwNDIxMDNaMCMGCSqGSIb3DQEJBDEWBBTP 5ENQXFDbtbR8E0kOoVTPHlgF5zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAErDu+4PONlcj bMptne6XyutDMB9Nu45ZorkovyAfwYlJ2Iam0pUZCwahSWItW3aijzUHBZ4fr0MT9yRhLBW5 nUDgcRgODvIKU+cqHR84WoZr8qaml28EgRacMnBXFZb96CBE+hSTFQgLRxhEHJ5A7bFaEOpA 0Fyc4N0Vxww3vAU2BzE2Fh+qObvtAArK9GZ2hrbmSSm6oG7g866bxJtkaOilRNcgG0r90+gv GMMdA77ERpAyKcitKAMBu/62hPKpbZOJOsgUiF1DwxpJAkmdBaHpw8bX84DtrofK6g8gDBQQ y8ovojzmKWbH6MnFWTfmO3eZ/wh5pvlqQPfpjH6qSwAAAAAAAA== --------------ms000006050205090907040704-- From owner-ietf-calendar@mail.imc.org Wed Mar 26 10:50:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01480 for ; Wed, 26 Mar 2003 10:50:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QFZAq20701 for ietf-calendar-bks; Wed, 26 Mar 2003 07:35:10 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QFZ8g20697 for ; Wed, 26 Mar 2003 07:35:09 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: mailing list size MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 26 Mar 2003 10:35:17 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2003 10:35:15 AM, Serialize complete at 03/26/2003 10:35:15 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Recently, we had to tell the Area Directors the of people subscribed to this list. The number is 297. I found that quite interesting and thought maybe the list would as well. ----- Forwarded by Pat R Egen/Egen Consulting/01 on 03/26/2003 10:30 ----- Paul Hoffman / VPNC 03/20/2003 16:48 To: pregen@egenconsulting.com cc: Subject: Re: mailing list size >Thanks for taking care of this - and could you let me know what the >is the final number. I would appreciate it - that question actually >comes up periodically. 297. --Paul Hoffman, Director --VPN Consortium From owner-ietf-calendar@mail.imc.org Mon Mar 31 15:45:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23722 for ; Mon, 31 Mar 2003 15:45:42 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKNeJM008691 for ; Mon, 31 Mar 2003 12:23:40 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VKNedS008690 for ietf-calendar-bks; Mon, 31 Mar 2003 12:23:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VKNdJM008683 for ; Mon, 31 Mar 2003 12:23:39 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP & busytime? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 31 Mar 2003 15:22:17 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 03/31/2003 03:23:26 PM, Serialize complete at 03/31/2003 03:23:26 PM Content-Type: multipart/alternative; boundary="=_alternative 006FA68A85256CFA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006FA68A85256CFA_= Content-Type: text/plain; charset="US-ASCII" Its unclear in the latest drafts so I wanted to ask the WG at large something. Does CAP allow for a CUA to get busytime from the CS? The first paragraph in Section 1 says in part: It further specifies how to search for available busy time information. but I dont see any prose that actually says how this is to be done in CAP. All of the commands and examples appear to be oriented at entry creation/discovery/deletion but nowhere does there appear to be consideration of something like "How do I get Pats, Bobs and Dougs busytime?" Im merely guessing that I could SEARCH for it but all the examples/prose talk about entries like VEVENTs and VTODOs. Since busytime is NOT an actual entry but rather a conceptual thing ("Take all of Bruces entries for today and that is his 'busytime' for today") Im unclear how (or even _if_) busytime is addressed in CAP. Yes we have VFREEBUSY components but they are most typically synthesized by the system by amalgamating the other entrys rather than being an actually separately maintained _actual_ component. I may infer from the text under CREATE that I (or my CUA) must CREATE the VFREEBUSY for it to exist (see create-vreply and create-comp). I may also infer from the text under DELETE that I can delete VFREEBUSY data but not the actual entry that it represents (see delete-vreply) which can also cause some serious quandries ("The VEVENT is in my Calendar but it does not appear to be reflected in the VFREEBUSY data that I retrieved. Why not?") Im more than a bit confused as to the usefulness of 'moving' VFREEBUSY data around since breaks any linkage means of relating the entries in the VFREEBUSY to any possible entries in a users calendar. Why would I need (or even _want_ ) to move _my_ VFREEBUSY data onto, say, Pats calendar?? Doing so would make it relevant to Pat and not me, right??... Beyond the cited 3 commands above there is no text or hints on "how to search for available busy time information." as promised in Section 1. Does anyone else share this confusion or am I just missing the obvious? 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 006FA68A85256CFA_= Content-Type: text/html; charset="US-ASCII"
Its unclear in the latest drafts so I wanted to ask the WG at large something.  Does CAP allow for a CUA to get busytime from the CS?

The first paragraph in Section 1 says in part:

             It further specifies how to search for available busy time information.

but I dont see any prose that actually says how this is to be done in CAP.  All of the commands and examples appear to be oriented at entry creation/discovery/deletion but nowhere does there appear to be consideration of something like "How do I get Pats, Bobs and Dougs busytime?"

Im merely guessing that I could SEARCH for it but all the examples/prose talk about entries like VEVENTs and VTODOs.  Since busytime is NOT an actual entry but rather a conceptual thing ("Take all of Bruces entries for today and that is his 'busytime' for today") Im unclear how (or even _if_) busytime is addressed in CAP.  Yes we have VFREEBUSY components but they are most typically synthesized by the system by amalgamating the other entrys rather than being an actually separately maintained _actual_ component.

I may infer from the text under CREATE that I (or my CUA) must CREATE the VFREEBUSY for it to exist (see create-vreply and create-comp).  

I may also infer from the text under DELETE that I can delete VFREEBUSY data but not the actual entry that it represents (see delete-vreply) which can also cause some serious quandries ("The VEVENT is in my Calendar but it does not appear to be reflected in the VFREEBUSY data that I retrieved.  Why not?")

Im more than a bit confused as to the usefulness of 'moving' VFREEBUSY data around since breaks any linkage means of relating the entries in the VFREEBUSY to any possible entries in a users calendar.  Why would I need (or even _want_ ) to move _my_ VFREEBUSY data onto, say, Pats calendar??  Doing so would make it relevant to Pat and not me, right??...

Beyond the cited 3 commands above there is no text or hints on "how to search for available busy time information." as promised in Section 1.

Does anyone else share this confusion or am I just missing the obvious?

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 006FA68A85256CFA_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 31 16:23:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25195 for ; Mon, 31 Mar 2003 16:23:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VL95JM011864 for ; Mon, 31 Mar 2003 13:09:05 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VL95gZ011863 for ietf-calendar-bks; Mon, 31 Mar 2003 13:09:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.9/8.11.6) with SMTP id h2VL93JM011859 for ; Mon, 31 Mar 2003 13:09:04 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003033116132514394 for ; Mon, 31 Mar 2003 16:13:25 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 31 Mar 2003 16:06:41 -0500 Message-ID: <3E88ADE1.20607@centive.com> Date: Mon, 31 Mar 2003 16:06:41 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP & busytime? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2003 21:06:41.0115 (UTC) FILETIME=[6D20D2B0:01C2F7C9] 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: > Since busytime is NOT an actual entry but rather a conceptual thing > ("Take all of Bruces entries for today and that is his 'busytime' for > today") Im unclear how (or even _if_) busytime is addressed in CAP. > Yes we have VFREEBUSY components but they are most typically > synthesized by the system by amalgamating the other entrys rather than > being an actually separately maintained _actual_ component. Yeah...it would probably make sense for the CS to synthesize the VFREEBUSY on the fly, in response to a query. That'll complicate access control; do we have a way to say "Joe can't read my calendar, but he can read my freebusy"? -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 31 16:27:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25400 for ; Mon, 31 Mar 2003 16:27:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VLG0JM012161 for ; Mon, 31 Mar 2003 13:16:00 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VLG0XR012160 for ietf-calendar-bks; Mon, 31 Mar 2003 13:16:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VLFwJM012154 for ; Mon, 31 Mar 2003 13:15:58 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h2VLFvM4009188 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 31 Mar 2003 13:16:00 -0800 Message-ID: <3E88B003.40606@Royer.com> Date: Mon, 31 Mar 2003 14:15:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030904000608070205010709" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030904000608070205010709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Its unclear in the latest drafts so I wanted to ask the WG at large > something. Does CAP allow for a CUA to get busytime from the CS? The same as with iTIP. You publish yours and make it available. > The first paragraph in Section 1 says in part: > > It further specifies how to search for available busy time > information. > > but I dont see any prose that actually says how this is to be done in > CAP. All of the commands and examples appear to be oriented at entry > creation/discovery/deletion but nowhere does there appear to be > consideration of something like "How do I get Pats, Bobs and Dougs > busytime?" And you will notice that VFREEBUSY is in the ABNF for SEARCH. > Im merely guessing that I could SEARCH for it but all the examples/prose > talk about entries like VEVENTs and VTODOs. Since busytime is NOT an > actual entry but rather a conceptual thing ("Take all of Bruces entries > for today and that is his 'busytime' for today") Im unclear how (or even > _if_) busytime is addressed in CAP. Yes we have VFREEBUSY components > but they are most typically synthesized by the system by amalgamating > the other entrys rather than being an actually separately maintained > _actual_ component. We deferred 'roll-up' into VFREEBUSY. Yes it is unspecified. It would be an unspecified CUA-BOT. > I may infer from the text under CREATE that I (or my CUA) must CREATE > the VFREEBUSY for it to exist (see create-vreply and create-comp). Yes. > I may also infer from the text under DELETE that I can delete VFREEBUSY > data but not the actual entry that it represents (see delete-vreply) > which can also cause some serious quandries ("The VEVENT is in my > Calendar but it does not appear to be reflected in the VFREEBUSY data > that I retrieved. Why not?") TRANSPARENT entries will also not show up in your VFREEBUSY. Plus if you don't what that, do not allow a CUA or CUA-BOT to do that. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030904000608070205010709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMzEyMTE1NDdaMCMGCSqGSIb3DQEJBDEWBBQN gJhXYqvZEuys0jsLML6h7GYUCTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAQuUE1ryIaRYf EhKtpIvb1nzfBNUkLWJq3VR2RGJKA2nNUUGFcHn59O7d3Hy0Trhj3g8f5nfDvkaQoWQI5xaq pW1dAOaxAu/aTuczdsUVQVmyBDYtIm6C6FAqyKponNSfe0BCHWUtzNdSqkQO1C7ZrPzS3Ja2 YlY1qlHYe8C9aE/T8WeXlK1INu8UFp/q6xDq+Uh4UG5lIzyLvp9K7B27nIuG6znY8/nBwxpa s7rH9qdNB210S+KtC51bvKc5Uk2SijZ7ShdySxSCuOn5PX7uOAyLixFTKp/n9vE23f45upZD XaLak4oa6OgxSuIFE0APn7ArYjhNr4P99mR+kQ9e0QAAAAAAAA== --------------ms030904000608070205010709-- From owner-ietf-calendar@mail.imc.org Mon Mar 31 17:53:52 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29578 for ; Mon, 31 Mar 2003 17:53:52 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VMcgJM015323 for ; Mon, 31 Mar 2003 14:38:42 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VMcgfs015322 for ietf-calendar-bks; Mon, 31 Mar 2003 14:38:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VMceJM015313 for ; Mon, 31 Mar 2003 14:38:40 -0800 (PST) In-Reply-To: <3E88B003.40606@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 31 Mar 2003 17:34:53 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 03/31/2003 05:38:38 PM, Serialize complete at 03/31/2003 05:38:38 PM Content-Type: multipart/alternative; boundary="=_alternative 007BCA2E85256CFA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007BCA2E85256CFA_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 03/31/2003 04:15:47 PM: > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Its unclear in the latest drafts so I wanted to ask the WG at large > > something. Does CAP allow for a CUA to get busytime from the CS? > > The same as with iTIP. You publish yours and make it available. CAP commands do not map 1-to-1 onto iTIP messages. In CAP I CREATE a component in one or more TARGETs which may have some METHOD property value. In iTIP I send a message with a METHOD property value determined by iTIP. CAP always uses CREATE to create new entities (hmm, how do updates happen!) For busytime, iTIP uses the VFREEBUSY component with METHOD:REQUEST or METHOD:REPLY for requesting and responding, respectively. In CAP, I guess that would crudely map to a CREATE command with particular TARGETs but there is NOTHING to lead me to belive that the CS must do any actual processing beyond the actual request creation. Nothing in CAP says that the CS works in realtime to process the VFREEBUSY with METHOD:REQUEST as a realtime busytime lookup and as such SHOULD result in busytime results being sent back rather than "REQUEST-STATUS:2.0;VFREEBUSY Created" response. As such if my CUA CREATEs a VFREEBUSY with METHOD:REQUEST, all I get back is essentially a "Yes, your VFREEBUSY was created in the TARGET", NOT the actual results Im querying for! So how does my CUA get the RESULTS of the workflow query?? CAP is realtime so I would assume that the query / response for busytime would/should be realtime too! > > The first paragraph in Section 1 says in part: > > > > It further specifies how to search for available busy time > > information. > > > > but I dont see any prose that actually says how this is to be done in > > CAP. All of the commands and examples appear to be oriented at entry > > creation/discovery/deletion but nowhere does there appear to be > > consideration of something like "How do I get Pats, Bobs and Dougs > > busytime?" > > And you will notice that VFREEBUSY is in the ABNF for SEARCH. Actually it is not. The only ANBF in SEARCH is: search-cmd = searchparam ":" "SEARCH" searchparam = *( ; the following are optional, ; but MUST NOT occur more than once id-param / localize-param / latency-param ; the following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. / action-param ; the following is optional, ; and MAY occur more than once / other-params ) Not a single mention of VFREEBUSY. In fact the ABNF under search is incomplete compared with the ABNF under DELETE and CREATE which have create-vreply, create-vresponse, etc. but thats a different matter. > > Im merely guessing that I could SEARCH for it but all the examples/prose > > talk about entries like VEVENTs and VTODOs. Since busytime is NOT an > > actual entry but rather a conceptual thing ("Take all of Bruces entries > > for today and that is his 'busytime' for today") Im unclear how (or even > > _if_) busytime is addressed in CAP. Yes we have VFREEBUSY components > > but they are most typically synthesized by the system by amalgamating > > the other entrys rather than being an actually separately maintained > > _actual_ component. > > We deferred 'roll-up' into VFREEBUSY. Yes it is unspecified. It would > be an unspecified CUA-BOT. So the text from Section 1 is wrong; we do NOT provide a clear way to do realtime busytime lookups... Given that a CUA can create VFREEBUSY and query for them, etc I strongly suspect that VFREEBUSY and its use has been overlooked or ignored. What good is a calendaring and _SCHEDULING_ protocol if I cant get your schedule information?? If we treated VFREEBUSYs as 'meta' information instead of an actual component that can be crated/updated/modified by a CUA and thus NOT reflect the actual busytime of the TARGETs then I think its a step closer to being better. Otherwise we totally misconstruct the busytime ablities in CAP to be totally useless compared to those in iTIP (where we assumed the data to be generated dynamically rather than statically and CERTAINLY NOT modifiable by the requestor/CU). If we are going to defer it then we should put in some prose to that effect so that its clear that CAP 1.0 does not accuratly provide a busytime lookup mechanism. > > I may infer from the text under CREATE that I (or my CUA) must CREATE > > the VFREEBUSY for it to exist (see create-vreply and create-comp). > > Yes. Ugh, see above about iTIP vs CAP in this respect... > > I may also infer from the text under DELETE that I can delete VFREEBUSY > > data but not the actual entry that it represents (see delete-vreply) > > which can also cause some serious quandries ("The VEVENT is in my > > Calendar but it does not appear to be reflected in the VFREEBUSY data > > that I retrieved. Why not?") > > TRANSPARENT entries will also not show up in your VFREEBUSY. > Plus if you don't what that, do not allow a CUA or CUA-BOT to do that. They show up with the proper fbparam property parameter on each FREEBUSY within the VFREEBUSY. Go check 4.8.2.6 Free/Busy Time of 2445. 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 007BCA2E85256CFA_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 03/31/2003 04:15:47 PM:
> Bruce_Kahn@notesdev.ibm.com wrote:
> >
> > Its unclear in the latest drafts so I wanted to ask the WG at large
> > something.  Does CAP allow for a CUA to get busytime from the CS?
>
> The same as with iTIP. You publish yours and make it available.
CAP commands do not map 1-to-1 onto iTIP messages.  

In CAP I CREATE a component in one or more TARGETs which may have some METHOD property value.  In iTIP I send a message with a METHOD property value determined by iTIP.  CAP always uses CREATE to create new entities (hmm, how do updates happen!)

For busytime, iTIP uses the VFREEBUSY component with METHOD:REQUEST or METHOD:REPLY for requesting and responding, respectively.  In CAP, I guess that would crudely map to a CREATE command with particular TARGETs but there is NOTHING to lead me to belive that the CS must do any actual processing beyond the actual request creation.  

Nothing in CAP says that the CS works in realtime to process the VFREEBUSY with METHOD:REQUEST as a realtime busytime lookup and as such SHOULD result in busytime results being sent back rather than "REQUEST-STATUS:2.0;VFREEBUSY Created" response.  As such if my CUA CREATEs a VFREEBUSY with METHOD:REQUEST, all I get back is essentially a "Yes, your VFREEBUSY was created in the TARGET", NOT the actual results Im querying for!  So how does my CUA get the RESULTS of the workflow query??  CAP is realtime so I would assume that the query / response for busytime would/should be realtime too!

> > The first paragraph in Section 1 says in part:
> >
> >              It further specifies how to search for available busy time
> > information.
> >
> > but I dont see any prose that actually says how this is to be done in
> > CAP.  All of the commands and examples appear to be oriented at entry
> > creation/discovery/deletion but nowhere does there appear to be
> > consideration of something like "How do I get Pats, Bobs and Dougs
> > busytime?"
>
> And you will notice that VFREEBUSY is in the ABNF for SEARCH.
Actually it is not.  The only ANBF in SEARCH is:

        search-cmd   = searchparam ":" "SEARCH"

      searchparam   = *(

                    ; the following are optional,
                    ; but MUST NOT occur more than once

                      id-param
                    / localize-param
                    / latency-param

                    ; the following MUST occur exactly once and only
                    ; when the latency-param has been supplied and
                    ; MUST NOT be supplied if the latency-param is
                    ; not supplied.

                    / action-param

                    ; the following is optional,
                    ; and MAY occur more than once

                    / other-params

                    )
Not a single mention of VFREEBUSY.  In fact the ABNF under search is incomplete compared with the ABNF under DELETE and CREATE which have create-vreply, create-vresponse, etc. but thats a different matter.

> > Im merely guessing that I could SEARCH for it but all the examples/prose
> > talk about entries like VEVENTs and VTODOs.   Since busytime is NOT an
> > actual entry but rather a conceptual thing ("Take all of Bruces entries
> > for today and that is his 'busytime' for today") Im unclear how (or even
> > _if_) busytime is addressed in CAP.  Yes we have VFREEBUSY components
> > but they are most typically synthesized by the system by amalgamating
> > the other entrys rather than being an actually separately maintained
> > _actual_ component.
>
> We deferred 'roll-up' into VFREEBUSY. Yes it is unspecified. It would
> be an unspecified CUA-BOT.
So the text from Section 1 is wrong; we do NOT provide a clear way to do realtime busytime lookups...

Given that a CUA can create VFREEBUSY and query for them, etc I strongly suspect that VFREEBUSY and its use has been overlooked or ignored.  What good is a calendaring and _SCHEDULING_ protocol if I cant get your schedule information??

If we treated VFREEBUSYs as 'meta' information instead of an actual component that can be crated/updated/modified by a CUA and thus NOT reflect the actual busytime of the TARGETs then I think its a step closer to being better.  Otherwise we totally misconstruct the busytime ablities in CAP to be totally useless compared to those in iTIP (where we assumed the data to be generated dynamically rather than statically and CERTAINLY NOT modifiable by the requestor/CU).

If we are going to defer it then we should put in some prose to that effect so that its clear that CAP 1.0 does not accuratly provide a busytime lookup mechanism.

> > I may infer from the text under CREATE that I (or my CUA) must CREATE
> > the VFREEBUSY for it to exist (see create-vreply and create-comp).  
>
> Yes.
Ugh, see above about iTIP vs CAP in this respect...

> > I may also infer from the text under DELETE that I can delete VFREEBUSY
> > data but not the actual entry that it represents (see delete-vreply)
> > which can also cause some serious quandries ("The VEVENT is in my
> > Calendar but it does not appear to be reflected in the VFREEBUSY data
> > that I retrieved.  Why not?")
>
> TRANSPARENT entries will also not show up in your VFREEBUSY.
> Plus if you don't what that, do not allow a CUA or CUA-BOT to do that.
They show up with the proper fbparam property parameter on each FREEBUSY within the VFREEBUSY.  Go check 4.8.2.6 Free/Busy Time of 2445.

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 007BCA2E85256CFA_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 31 18:24:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02083 for ; Mon, 31 Mar 2003 18:24:27 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VND5JM017418 for ; Mon, 31 Mar 2003 15:13:05 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VND5Sr017417 for ietf-calendar-bks; Mon, 31 Mar 2003 15:13:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VND3JM017413 for ; Mon, 31 Mar 2003 15:13:03 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id h2VND0M4010293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 31 Mar 2003 15:13:04 -0800 Message-ID: <3E88CB76.7020703@Royer.com> Date: Mon, 31 Mar 2003 16:12:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080605070705060806030503" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080605070705060806030503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > For busytime, iTIP uses the VFREEBUSY component with METHOD:REQUEST or > METHOD:REPLY for requesting and responding, respectively. In CAP, I > guess that would crudely map to a CREATE command with particular TARGETs > but there is NOTHING to lead me to belive that the CS must do any actual > processing beyond the actual request creation. In fact we squashed the CS from doing any work for the CUA. You need to have your CUA or a CUA-BOT do it for you. > Actually it is not. The only ANBF in SEARCH is: Read more text...: comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" / x-comp / iana-comp And comp-name is used in: cal-query = "SELECT" SP cap-val SP "FROM" SP comp-name SP "WHERE" SP cap-expr -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080605070705060806030503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMzEyMzEyNTRaMCMGCSqGSIb3DQEJBDEWBBS9 YSQ9W1Lo9R/VAlawUq0RFxF2vzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAjQG8EqjVMpgl 9CaXajjoeQ2IFs+zaq1N3hgXosavrzs+FhnNgNqQFC+ZlpLVSaKj/xA6rQn21WuQcLDK1nyK UyP0dQdoGHaoXk700uZLEsj94r3Gx9BKIAfkD6QarCpY2xieaxTWuNWxj/3QNI501Bq+wIOy 7d+HKecQDXw3JYxSupL85gurZakxTZh98VNCaeIEXBkGgftnxUimpjtRKUJZ4I8iWNCH71K2 gjFItRrmPWhYPjqpqvaqXkcq/SipUaWLOWSdQopEkmHdpEsjJQfabC1pwMrQFVtzfpd0Owau tP8p+53Av4IOS31KgG8U1UbmkO0HMwaauxUXmlGwlgAAAAAAAA== --------------ms080605070705060806030503--