From owner-ietf-calendar@mail.imc.org Tue Jul 1 12:58:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07072 for ; Tue, 1 Jul 2003 12:58:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61GkQFK068174 for ; Tue, 1 Jul 2003 09:46:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61GkQG9068173 for ietf-calendar-bks; Tue, 1 Jul 2003 09:46:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61GkOFK068167 for ; Tue, 1 Jul 2003 09:46:24 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h61GkLfU010921 for ; Tue, 1 Jul 2003 09:46:21 -0700 (PDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h61GkLaJ001414 for ; Tue, 1 Jul 2003 09:46:21 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HHC00CYVUL80Z@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Tue, 01 Jul 2003 09:46:20 -0700 (PDT) Date: Tue, 01 Jul 2003 09:46:20 -0700 From: Satya Vempati Subject: RE: CAP draft - last call, etc. To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_n28sl2MaCS+gj6/yHeOLjA)"; DIFFERENCES=Content-Language Content-language: en-USA Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_n28sl2MaCS+gj6/yHeOLjA) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT Some of the iCAL/iTIP questions will impact the decisions on CAP. Especially, the outcome of the discussion on RECURRENCE-ID fundamentally affects the CAP spec based on how it is eventually resolved. IMHO, one final draft (hopefully 11) to iron out the differences is required before going to RFC. -----Original Message----- From: Doug Royer [mailto:Doug@royer.com] Sent: Monday, June 30, 2003 8:19 PM To: ietf-calendar@imc.org Subject: Re: CAP draft - last call, etc. Items that will be changed in the -11 version of the draft. (1) Sorting is out per this WG. (I submitted my own add on draft). (2) The ABNF will be fixed per the email on this WG. (3) Various typos sent to me and this list. (4) CS to generate FREEBUSY data (NOT CUA). As of the San Francisco IETF meeting (-10 release) there have been no other new CAP issues that seem to have reach consensus. The only new issue seems to be if TARGET will default and I did not think that made it past a couple of questions and opinions sent to the list. Unless I missed something, all of the other issues are all iCal/iTIP/iMIP issues. PLEASE SPEAK UP if you think that something else should make the -11 version of the draft - I AM EDITING IT NOW. Still To do: (I) Beep profile. (II) Document the 1:1 or 1:MANY replies. Item (II) was discussed in S.F. and the thoughts were that you would bundle all single TARGET replies in one blob, and for each unique TARGET in the CS reply, the CS would send another blob of data. pregen@egenconsulting.com wrote: > > Well, there's been a lot of traffic going on about all sort of issues > and topics. However, it came to a halt when one note came up with what > may be a "show-stopper." So, I think we need to make a decision here. > Do we take items that are too hard to fix, remove them, and put in an > addendum that says "the following items need to be resolved in the next > version"? Or do we try to take a stab at fixing them. We need to get a > version of CAP into RFC status. We need to get people interoperating so > we can see what's really working and what's really hosed badly. I asked > for a last call and that didn't work. We really do need to get this out > the door. Therefore, I'm once again asking for a last hard look at what > can stay and what needs to go in the current CAP draft. If it's broken > and needs a lot of work - it goes out. I am going to go back over the > last year's thr! eads and see what I can determine are the big issues. > I'll post a note to the list with the items and will ask for a "hm" > from the list as to whether the item stays or goes. If it goes, we'll > need help changing the draft to remove all text regarding that topic. > > If you disagree with the items I post - say so. If you agree with the > items - say so. That way I know people are reading the list and will > agree with what we produce as the final draft. > > Cool? > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 -- 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 --Boundary_(ID_n28sl2MaCS+gj6/yHeOLjA) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT Some of the iCAL/iTIP questions will impact the decisions on CAP. Especially, the outcome of the discussion on RECURRENCE-ID fundamentally affects the CAP spec based on how it is eventually resolved.
IMHO, one final draft (hopefully 11) to iron out the differences is required before going to RFC.
-----Original Message-----
From: Doug Royer [mailto:Doug@royer.com]
Sent: Monday, June 30, 2003 8:19 PM
To: ietf-calendar@imc.org
Subject: Re: CAP draft - last call, etc.
Items that will be changed in the -11 version of the draft.
(1) Sorting is out per this WG. (I submitted my own add on draft).
(2) The ABNF will be fixed per the email on this WG.
(3) Various typos sent to me and this list.
(4) CS to generate FREEBUSY data (NOT CUA).
As of the San Francisco IETF meeting (-10 release) there have been no
other new CAP issues that seem to have reach consensus. The only
new issue seems to be if TARGET will default and I did not think
that made it past a couple of questions and opinions sent to the list.
Unless I missed something, all of the other issues are
all iCal/iTIP/iMIP issues.
PLEASE SPEAK UP if you think that something else should make the -11
version of the draft - I AM EDITING IT NOW.
Still To do:
(I) Beep profile.
(II) Document the 1:1 or 1:MANY replies.
Item (II) was discussed in S.F. and the thoughts were that
you would bundle all single TARGET replies in one blob,
and for each unique TARGET in the CS reply, the CS would
send another blob of data.
pregen@egenconsulting.com wrote:
>
> Well, there's been a lot of traffic going on about all sort of issues
> and topics. However, it came to a halt when one note came up with what
> may be a "show-stopper." So, I think we need to make a decision here.
> Do we take items that are too hard to fix, remove them, and put in an
> addendum that says "the following items need to be resolved in the next
> version"? Or do we try to take a stab at fixing them. We need to get a
> version of CAP into RFC status. We need to get people interoperating so
> we can see what's really working and what's really hosed badly. I asked
> for a last call and that didn't work. We really do need to get this out
> the door. Therefore, I'm once again asking for a last hard look at what
> can stay and what needs to go in the current CAP draft. If it's broken
> and needs a lot of work - it goes out. I am going to go back over the
> last year's thr! eads and see what I can determine are the big issues.
> I'll post a note to the list with the items and will ask for a "hm"
> from the list as to whether the item stays or goes. If it goes, we'll
> need help changing the draft to remove all text regarding that topic.
>
> If you disagree with the items I post - say so. If you agree with the
> items - say so. That way I know people are reading the list and will
> agree with what we produce as the final draft.
>
> Cool?
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652
--
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
--Boundary_(ID_n28sl2MaCS+gj6/yHeOLjA)-- From owner-ietf-calendar@mail.imc.org Tue Jul 1 13:29:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07555 for ; Tue, 1 Jul 2003 13:29:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61HL8FK069500 for ; Tue, 1 Jul 2003 10:21:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61HL76R069499 for ietf-calendar-bks; Tue, 1 Jul 2003 10:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61HL5FK069488 for ; Tue, 1 Jul 2003 10:21:05 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CAP draft - last call, etc. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 1 Jul 2003 13:21:06 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 07/01/2003 01:21:07 PM, Serialize complete at 07/01/2003 01:21:07 PM Content-Type: multipart/alternative; boundary="=_alternative 005F50E485256D56_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005F50E485256D56_= Content-Type: text/plain; charset="us-ascii" What about the scoping issue? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/30/2003 23:18 Please respond to ietf-calendar To: ietf-calendar@imc.org cc: Subject: Re: CAP draft - last call, etc. Items that will be changed in the -11 version of the draft. (1) Sorting is out per this WG. (I submitted my own add on draft). (2) The ABNF will be fixed per the email on this WG. (3) Various typos sent to me and this list. (4) CS to generate FREEBUSY data (NOT CUA). As of the San Francisco IETF meeting (-10 release) there have been no other new CAP issues that seem to have reach consensus. The only new issue seems to be if TARGET will default and I did not think that made it past a couple of questions and opinions sent to the list. Unless I missed something, all of the other issues are all iCal/iTIP/iMIP issues. PLEASE SPEAK UP if you think that something else should make the -11 version of the draft - I AM EDITING IT NOW. Still To do: (I) Beep profile. (II) Document the 1:1 or 1:MANY replies. Item (II) was discussed in S.F. and the thoughts were that you would bundle all single TARGET replies in one blob, and for each unique TARGET in the CS reply, the CS would send another blob of data. pregen@egenconsulting.com wrote: > > Well, there's been a lot of traffic going on about all sort of issues > and topics. However, it came to a halt when one note came up with what > may be a "show-stopper." So, I think we need to make a decision here. > Do we take items that are too hard to fix, remove them, and put in an > addendum that says "the following items need to be resolved in the next > version"? Or do we try to take a stab at fixing them. We need to get a > version of CAP into RFC status. We need to get people interoperating so > we can see what's really working and what's really hosed badly. I asked > for a last call and that didn't work. We really do need to get this out > the door. Therefore, I'm once again asking for a last hard look at what > can stay and what needs to go in the current CAP draft. If it's broken > and needs a lot of work - it goes out. I am going to go back over the > last year's thr! eads and see what I can determine are the big issues. > I'll post a note to the list with the items and will ask for a "hm" > from the list as to whether the item stays or goes. If it goes, we'll > need help changing the draft to remove all text regarding that topic. > > If you disagree with the items I post - say so. If you agree with the > items - say so. That way I know people are reading the list and will > agree with what we produce as the final draft. > > Cool? > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 -- 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 005F50E485256D56_= Content-Type: text/html; charset="us-ascii"
What about the scoping issue?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

06/30/2003 23:18
Please respond to ietf-calendar

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: CAP draft - last call, etc.





Items that will be changed in the -11 version of the draft.

(1) Sorting is out per this WG. (I submitted my own add on draft).
(2) The ABNF will be fixed per the email on this WG.
(3) Various typos sent to me and this list.
(4) CS to generate FREEBUSY data (NOT CUA).

As of the San Francisco IETF meeting (-10 release) there have been no
other new CAP issues that seem to have reach consensus. The only
new issue seems to be if TARGET will default and I did not think
that made it past a couple of questions and opinions sent to the list.

Unless I missed something, all of the other issues are
all iCal/iTIP/iMIP issues.

PLEASE SPEAK UP if you think that something else should make the -11
version of the draft - I AM EDITING IT NOW.

Still To do:

(I) Beep profile.
(II) Document the 1:1 or 1:MANY replies.

Item (II) was discussed in S.F. and the thoughts were that
you would bundle all single TARGET replies in one blob,
and for each unique TARGET in the CS reply, the CS would
send another blob of data.

pregen@egenconsulting.com wrote:
>
> Well, there's been a lot of traffic going on about all sort of issues
> and topics.  However, it came to a halt when one note came up with what
> may be a "show-stopper."  So, I think we need to make a decision here.
>  Do we take items that are too hard to fix, remove them, and put in an
> addendum that says "the following items need to be resolved in the next
> version"?  Or do we try to take a stab at fixing them.  We need to get a
> version of CAP into RFC status.  We need to get people interoperating so
> we can see what's really working and what's really hosed badly.  I asked
> for a last call and that didn't work.  We really do need to get this out
> the door.  Therefore, I'm once again asking for a last hard look at what
> can stay and what needs to go in the current CAP draft.  If it's broken
> and needs a lot of work - it goes out.  I am going to go back over the
> last year's thr! eads and see what I can determine are the big issues.
>  I'll post a note to the list with the items and will ask for a "hm"
> from the list as to whether the item stays or goes.  If it goes, we'll
> need help changing the draft to remove all text regarding that topic.
>
> If you disagree with the items I post - say so.  If you agree with the
> items - say so.  That way I know people are reading the list and will
> agree with what we produce as the final draft.  
>
> Cool?
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652


--

 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 005F50E485256D56_=-- From owner-ietf-calendar@mail.imc.org Tue Jul 1 14:29:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10061 for ; Tue, 1 Jul 2003 14:29:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJhFK074254 for ; Tue, 1 Jul 2003 11:19:43 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61IJh7l074253 for ietf-calendar-bks; Tue, 1 Jul 2003 11:19:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJgFK074248 for ; Tue, 1 Jul 2003 11:19:42 -0700 (PDT) (envelope-from bobmah@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61IJhnO018186; Tue, 1 Jul 2003 14:19:43 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61IJhZl006733; Tue, 1 Jul 2003 14:19:43 -0400 (EDT) Received: from [18.18.1.170] (BOB.MIT.EDU [18.18.1.170]) (authenticated bits=0) (User authenticated as bobmah@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h61IJfU9000056; Tue, 1 Jul 2003 14:19:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: In-Reply-To: References: Date: Tue, 1 Jul 2003 14:19:39 -0400 To: Satya Vempati From: Bob Mahoney Subject: RE: CAP draft - last call, etc. Cc: "ietf-calendar@imc.org" Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Satya- Pat and I are pursuing an interpretation from one of the original authors, and hope to be able to shed some light on your questions soon... (i.e., "we hear you and we're working on it." :-) -Bob At 9:46 AM -0700 7/1/03, Satya Vempati wrote: > >Some of the iCAL/iTIP questions will impact the decisions on CAP. Especially, the outcome of the discussion on RECURRENCE-ID fundamentally affects the CAP spec based on how it is eventually resolved. >IMHO, one final draft (hopefully 11) to iron out the differences is required before going to RFC. From owner-ietf-calendar@mail.imc.org Tue Jul 1 15:16:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13086 for ; Tue, 1 Jul 2003 15:16:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61J7RFK079070 for ; Tue, 1 Jul 2003 12:07:27 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61J7RW5079069 for ietf-calendar-bks; Tue, 1 Jul 2003 12:07:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom 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.12.8) with ESMTP id h61J7QFK079061 for ; Tue, 1 Jul 2003 12:07:26 -0700 (PDT) (envelope-from Doug@Royer.com) 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 h61J7MOR031732 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Jul 2003 12:07:27 -0700 Message-ID: <3F01DBE5.2000703@Royer.com> Date: Tue, 01 Jul 2003 13:07:17 -0600 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 draft - last call, etc. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090404040407000103060003" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090404040407000103060003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: > Some of the iCAL/iTIP questions will impact the decisions on CAP. > Especially, the outcome of the discussion on RECURRENCE-ID fundamentally > affects the CAP spec based on how it is eventually resolved. I can see how that proposal could have effected the iTIP protocol but not the CAP protocol. It would indirectly effected CUAs that used CAP to store local CU data in the object across recurrence rule changes. No matter which way it went, it would not have effected the CAP 'protocol' at all. It would have effected all CUAs that used iTIP to process scheduling requests via iMIP, CAP, or any other transport. That proposal that in iCal version-next that the recurrence-id be tied to SEQUECEN:0 objects in order to be compatible with some vendors seems to have died. (read Bruce's last email on the subject). It was never necessary and I think that Burce agrees. Does any disagree? > IMHO, one final draft (hopefully 11) to iron out the differences is > required before going to RFC. -- 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 --------------ms090404040407000103060003 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MDExOTA3MTdaMCMGCSqGSIb3DQEJBDEWBBTM XGc0SXw9++FBN1Y5u7eeiGUciTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAhG5dhr7YQWPY 4hzvhTt+DtSsDJKSCn65/XBfHKlGzOZV7SKqgOsfQjh/DpY5vK2jCIa23oB5xqgLIyCyU87X V9QKndmRdKAVP0CJPG9ub7ihvFKQc0wWg7y3I2E+boCU104EC+f/L2qEyhucSGrlT/xbaje4 VUl30htf8XztScwlCkdR1XEzoF6xqxW5l7K3wm63Hlm/qUsjUpYxOx/Ywwnukow3xQo+MRsM COwxNbsYlUHWeyq2xtNSU1Aiu4dwXcQ51LLyA0rznFPWqegnqI8bVTnSLS5DTXhrU4q0Khze RAgJqMMcGZgs+RrG8MAFVoV1g9yUoWEn4JmJD44kIgAAAAAAAA== --------------ms090404040407000103060003-- From owner-ietf-calendar@mail.imc.org Tue Jul 1 17:10:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16561 for ; Tue, 1 Jul 2003 17:10:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61L05FK084414 for ; Tue, 1 Jul 2003 14:00:05 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61L0554084413 for ietf-calendar-bks; Tue, 1 Jul 2003 14:00:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61L03FK084408 for ; Tue, 1 Jul 2003 14:00:03 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h61L051J002735 for ; Tue, 1 Jul 2003 15:00:05 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h61L05aJ010460 for ; Tue, 1 Jul 2003 14:00:05 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HHD00C246C50Z@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Tue, 01 Jul 2003 14:00:05 -0700 (PDT) Date: Tue, 01 Jul 2003 14:00:04 -0700 From: Satya Vempati Subject: RE: CAP draft - last call, etc. To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rDmo6VzXCBFpWFXbK/ZOoA)"; DIFFERENCES=Content-Language Content-language: en-USA Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_rDmo6VzXCBFpWFXbK/ZOoA) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT From your mail to the news group on 6/19/03: "Fixating the recurrence-id to sequence zero prevents the recurrence rules from ever changing and will make CAP VCARs, NOTIFICATIONS, local CU VALARMs break in CAP. So I just do not see how that will work." Additionally, from the CAP draft 10: ----------- 6.1.1.17 Query by Date-Time range This query selects the entire content of every booked "VEVENT" component that has an instance greater than or equal to July 1st, 2000 00:00:00 UTC and less than or equal to July 31st, 2000 23:59:59 UTC. This includes single instance "VEVENT" components that do no explicitly contain a "RECURRENCE-ID" property. BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE RECURRENCE-ID >= '20000801T000000Z' AND RECURRENCE-ID <= '20000831T235959Z' AND STATE() = 'BOOKED' END:VQUERY --------------- If RECURRENCE-IDs stay rooted at their instantiated values, the query as formulated above will return erroneous results. I haven't seen an email in which Bruce Kahn conceded that RECURRENCE-IDs should change. -----Original Message----- From: Doug Royer [mailto:Doug@royer.com] Sent: Tuesday, July 01, 2003 12:07 PM To: ietf-calendar@imc.org Subject: Re: CAP draft - last call, etc. Satya Vempati wrote: > Some of the iCAL/iTIP questions will impact the decisions on CAP. > Especially, the outcome of the discussion on RECURRENCE-ID fundamentally > affects the CAP spec based on how it is eventually resolved. I can see how that proposal could have effected the iTIP protocol but not the CAP protocol. It would indirectly effected CUAs that used CAP to store local CU data in the object across recurrence rule changes. No matter which way it went, it would not have effected the CAP 'protocol' at all. It would have effected all CUAs that used iTIP to process scheduling requests via iMIP, CAP, or any other transport. That proposal that in iCal version-next that the recurrence-id be tied to SEQUECEN:0 objects in order to be compatible with some vendors seems to have died. (read Bruce's last email on the subject). It was never necessary and I think that Burce agrees. Does any disagree? > IMHO, one final draft (hopefully 11) to iron out the differences is > required before going to RFC. -- 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 --Boundary_(ID_rDmo6VzXCBFpWFXbK/ZOoA) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT From your mail to the news group on 6/19/03:
"Fixating the recurrence-id to sequence zero
prevents the recurrence rules from ever changing and will make CAP
VCARs, NOTIFICATIONS, local CU VALARMs break in CAP. So I just do
not see how that will work."
Additionally, from the CAP draft 10:
-----------
6.1.1.17 Query by Date-Time range
This query selects the entire content of every booked "VEVENT"
component that has an instance greater than or equal to July 1st,
2000 00:00:00 UTC and less than or equal to July 31st, 2000 23:59:59
UTC. This includes single instance "VEVENT" components that do no
explicitly contain a "RECURRENCE-ID" property.
BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT
WHERE RECURRENCE-ID >= '20000801T000000Z'
AND RECURRENCE-ID <= '20000831T235959Z'
AND STATE() = 'BOOKED'
END:VQUERY
---------------
If RECURRENCE-IDs stay rooted at their instantiated values, the query as formulated above will return erroneous results.
I haven't seen an email in which Bruce Kahn conceded that RECURRENCE-IDs should change.
-----Original Message-----
From: Doug Royer [mailto:Doug@royer.com]
Sent: Tuesday, July 01, 2003 12:07 PM
To: ietf-calendar@imc.org
Subject: Re: CAP draft - last call, etc.
Satya Vempati wrote:
> Some of the iCAL/iTIP questions will impact the decisions on CAP.
> Especially, the outcome of the discussion on RECURRENCE-ID fundamentally
> affects the CAP spec based on how it is eventually resolved.
I can see how that proposal could have effected the iTIP protocol
but not the CAP protocol. It would indirectly effected CUAs that used
CAP to store local CU data in the object across recurrence rule
changes. No matter which way it went, it would not have effected
the CAP 'protocol' at all. It would have effected all CUAs that
used iTIP to process scheduling requests via iMIP, CAP, or
any other transport.
That proposal that in iCal version-next that the recurrence-id
be tied to SEQUECEN:0 objects in order to be compatible with some
vendors seems to have died. (read Bruce's last email on the subject).
It was never necessary and I think that Burce agrees.
Does any disagree?
> IMHO, one final draft (hopefully 11) to iron out the differences is
> required before going to RFC.
--
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
--Boundary_(ID_rDmo6VzXCBFpWFXbK/ZOoA)-- From owner-ietf-calendar@mail.imc.org Tue Jul 1 18:37:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19525 for ; Tue, 1 Jul 2003 18:37:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61MPSFK089765 for ; Tue, 1 Jul 2003 15:25:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61MPSrC089764 for ietf-calendar-bks; Tue, 1 Jul 2003 15:25:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom 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.12.8) with ESMTP id h61MPQFK089759 for ; Tue, 1 Jul 2003 15:25:27 -0700 (PDT) (envelope-from Doug@Royer.com) 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 h61MPPOR001183 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Jul 2003 15:25:28 -0700 Message-ID: <3F020A4B.3030902@Royer.com> Date: Tue, 01 Jul 2003 16:25:15 -0600 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 draft - last call, etc. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030004020502000107050608" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030004020502000107050608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: > From your mail to the news group on 6/19/03: > "Fixating the recurrence-id to sequence zero > prevents the recurrence rules from ever changing and will make CAP > VCARs, NOTIFICATIONS, local CU VALARMs break in CAP. So I just do > not see how that will work." As in they get DELETED if the UID changes. Not the same as breaking the CAP protocol. > Additionally, from the CAP draft 10: > ----------- > 6.1.1.17 Query by Date-Time range > This query selects the entire content of every booked "VEVENT" > component that has an instance greater than or equal to July 1st, > 2000 00:00:00 UTC and less than or equal to July 31st, 2000 23:59:59 > UTC. This includes single instance "VEVENT" components that do no > explicitly contain a "RECURRENCE-ID" property. > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT * FROM VEVENT > WHERE RECURRENCE-ID >= '20000801T000000Z' > AND RECURRENCE-ID <= '20000831T235959Z' > AND STATE() = 'BOOKED' > END:VQUERY > --------------- > If RECURRENCE-IDs stay rooted at their instantiated values, the query as > formulated above will return erroneous results. > I haven't seen an email in which Bruce Kahn conceded that RECURRENCE-IDs > should change. In Bruces email dated: June 26 3:55PM ...The other way I described it also works but could mistakenly make some think that the CUA must preserve both the SEQUENCE:0 definition and then all the current ones and thats not necessary. Both ways will achieve the same effect. ... So, no. -- 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 --------------ms030004020502000107050608 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MDEyMjI1MTVaMCMGCSqGSIb3DQEJBDEWBBRl MkuiyWfko1TeZXIol8S2wTjf2zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAHM5dQxEx2ItL cDxQxXNk+4r4wz5A3Zhe1EFZ+FQHTwBwqF1ZHOCHcXRh/Rsvyz8INxzifdPlUiwew4yo3IWx Cd8AXlrhNH8x3f4cjcN22fOzBaIXaOsO7zoBvc/BjKD394aYwd/bSZvaf0pWeelTXjAqP+Ma p1hzK7MkaCl1D10QCnEXeIY3AdqbwrPLKsDZlvaE9HIOrCNBsT6jSlwuKFAmYUx5GT14hf+5 gXoGGXdYUb1kl/dZQvUpj8DRpd3iuN3rhBQLbalCJOD7RYInboubMFedIMaw/QpMnXN0kKJI u9a/nK2Hr1NZPFuwkOVyYF7l0s3dZjOdyAmeJn37nQAAAAAAAA== --------------ms030004020502000107050608-- From owner-ietf-calendar@mail.imc.org Tue Jul 1 19:13:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20315 for ; Tue, 1 Jul 2003 19:13:45 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61N3ZFK090876 for ; Tue, 1 Jul 2003 16:03:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61N3Zdv090875 for ietf-calendar-bks; Tue, 1 Jul 2003 16:03:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61N3XFK090870 for ; Tue, 1 Jul 2003 16:03:34 -0700 (PDT) (envelope-from satyanarayana.vempati@Sun.COM) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h61N3Zvc000575 for ; Tue, 1 Jul 2003 17:03:36 -0600 (MDT) Received: from phys-ha13sca-1 (phys-ha13sca-1.SFBay.Sun.COM [129.145.155.91]) by sfbaymail2sca.sfbay.sun.com (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h61N3ZaJ010844 for ; Tue, 1 Jul 2003 16:03:35 -0700 (PDT) Received: from pranav.red.iplanet.com (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HHD00CFVC1Z0Z@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Tue, 01 Jul 2003 16:03:35 -0700 (PDT) Date: Tue, 01 Jul 2003 16:03:35 -0700 From: Satya Vempati Subject: RE: CAP draft - last call, etc. To: "ietf-calendar@imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7BxBffSX5Kdt9DHzJbhqdg)"; DIFFERENCES=Content-Language Content-language: en-USA Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_7BxBffSX5Kdt9DHzJbhqdg) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT I might have misunderstood Bruce but I took it differently. Since RECURRENCE-ID "never" changes in his model, SEQUENCE:0 is not really required. All SEQUENCE numbers point to the same RECURRENCE-ID and there is no need to "preserve" SEQUENCE:0. -----Original Message----- From: Doug Royer [mailto:Doug@royer.com] Sent: Tuesday, July 01, 2003 3:25 PM To: ietf-calendar@imc.org Subject: Re: CAP draft - last call, etc. Satya Vempati wrote: > From your mail to the news group on 6/19/03: > "Fixating the recurrence-id to sequence zero > prevents the recurrence rules from ever changing and will make CAP > VCARs, NOTIFICATIONS, local CU VALARMs break in CAP. So I just do > not see how that will work." As in they get DELETED if the UID changes. Not the same as breaking the CAP protocol. > Additionally, from the CAP draft 10: > ----------- > 6.1.1.17 Query by Date-Time range > This query selects the entire content of every booked "VEVENT" > component that has an instance greater than or equal to July 1st, > 2000 00:00:00 UTC and less than or equal to July 31st, 2000 23:59:59 > UTC. This includes single instance "VEVENT" components that do no > explicitly contain a "RECURRENCE-ID" property. > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT * FROM VEVENT > WHERE RECURRENCE-ID >= '20000801T000000Z' > AND RECURRENCE-ID <= '20000831T235959Z' > AND STATE() = 'BOOKED' > END:VQUERY > --------------- > If RECURRENCE-IDs stay rooted at their instantiated values, the query as > formulated above will return erroneous results. > I haven't seen an email in which Bruce Kahn conceded that RECURRENCE-IDs > should change. In Bruces email dated: June 26 3:55PM ...The other way I described it also works but could mistakenly make some think that the CUA must preserve both the SEQUENCE:0 definition and then all the current ones and thats not necessary. Both ways will achieve the same effect. ... So, no. -- 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 --Boundary_(ID_7BxBffSX5Kdt9DHzJbhqdg) Content-id: 0 Content-type: TEXT/html; CHARSET=US-ASCII Content-language: en-USA Content-Transfer-Encoding: 7BIT
I might have misunderstood Bruce but I took it differently. Since RECURRENCE-ID "never" changes in his model, SEQUENCE:0 is not really required. All SEQUENCE numbers point to the same RECURRENCE-ID and there is no need to "preserve" SEQUENCE:0.
-----Original Message-----
From: Doug Royer [mailto:Doug@royer.com]
Sent: Tuesday, July 01, 2003 3:25 PM
To: ietf-calendar@imc.org
Subject: Re: CAP draft - last call, etc.
Satya Vempati wrote:
> From your mail to the news group on 6/19/03:
> "Fixating the recurrence-id to sequence zero
> prevents the recurrence rules from ever changing and will make CAP
> VCARs, NOTIFICATIONS, local CU VALARMs break in CAP. So I just do
> not see how that will work."
As in they get DELETED if the UID changes. Not the same as breaking
the CAP protocol.
> Additionally, from the CAP draft 10:
> -----------
> 6.1.1.17 Query by Date-Time range
> This query selects the entire content of every booked "VEVENT"
> component that has an instance greater than or equal to July 1st,
> 2000 00:00:00 UTC and less than or equal to July 31st, 2000 23:59:59
> UTC. This includes single instance "VEVENT" components that do no
> explicitly contain a "RECURRENCE-ID" property.
> BEGIN:VQUERY
> EXPAND:TRUE
> QUERY:SELECT * FROM VEVENT
> WHERE RECURRENCE-ID >= '20000801T000000Z'
> AND RECURRENCE-ID <= '20000831T235959Z'
> AND STATE() = 'BOOKED'
> END:VQUERY
> ---------------
> If RECURRENCE-IDs stay rooted at their instantiated values, the query as
> formulated above will return erroneous results.
> I haven't seen an email in which Bruce Kahn conceded that RECURRENCE-IDs
> should change.
In Bruces email dated: June 26 3:55PM
...The other way I described it also works but could mistakenly make some
think that the CUA must preserve both the SEQUENCE:0 definition and then
all the current ones and thats not necessary. Both ways will achieve
the same effect. ...
So, no.
--
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
--Boundary_(ID_7BxBffSX5Kdt9DHzJbhqdg)-- From owner-ietf-calendar@mail.imc.org Tue Jul 1 20:28:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22414 for ; Tue, 1 Jul 2003 20:28:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h620GtFK092817 for ; Tue, 1 Jul 2003 17:16:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h620GssF092816 for ietf-calendar-bks; Tue, 1 Jul 2003 17:16:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom 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.12.8) with ESMTP id h620GrFK092810 for ; Tue, 1 Jul 2003 17:16:53 -0700 (PDT) (envelope-from Doug@Royer.com) 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 h620GqOR002205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Jul 2003 17:16:55 -0700 Message-ID: <3F022466.7080406@Royer.com> Date: Tue, 01 Jul 2003 18:16:38 -0600 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 draft - last call, etc. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040401040906080609060805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040401040906080609060805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya Vempati wrote: > I might have misunderstood Bruce but I took it differently. Since > RECURRENCE-ID "never" changes in his model, SEQUENCE:0 is not really > required. All SEQUENCE numbers point to the same RECURRENCE-ID and there > is no need to "preserve" SEQUENCE:0. Ether way, it may break iTIP clients, but not the CAP protocol. And his belief is contrary to the text in iCAL/iTIP, he is simply telling people how he wants it, not how it is. Plus, the CUA can do a full REFRESH and ignore that rule anyway. -- 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 --------------ms040401040906080609060805 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MDIwMDE2MzhaMCMGCSqGSIb3DQEJBDEWBBR9 0dBn9MY+P9xPjb968XUmy1MDCDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAeqtVyiUPnqhi No7hY4D18L+dPEfSFQUSdKep9XubC7JQUARzmMjq6J7uASvxjKKh9y/ioROrLJ7Uf4dqN+0z OkW+I6jJTpiflNvTu0F2H2tu+XeiPzxLMeVj+TJZ5MJc8sUbyLPhedM9rTKeRbuCiSW5KHrT Bu3TsVmV8pqm2aDF670pQWYb3OXgutCUD+KfCQm5zxYFou6Si7A6cnS7lgK3hT3CFGfyuSt6 oawW4iXi00Kwm9BeoDj9u2L5/oV40RvvoegUY1mEJCoLOataE130W/oy5Z+VMW3es2g3TfcV E8zN6iNak4a8SMnrsANrW1ovkriVXLsialcaR2XvDwAAAAAAAA== --------------ms040401040906080609060805-- From owner-ietf-calendar@mail.imc.org Tue Jul 1 22:24:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25080 for ; Tue, 1 Jul 2003 22:24:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622DpFK096571 for ; Tue, 1 Jul 2003 19:13:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h622Dpgc096570 for ietf-calendar-bks; Tue, 1 Jul 2003 19:13:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622DnFK096559 for ; Tue, 1 Jul 2003 19:13:49 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: CAP draft - last call, etc. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 1 Jul 2003 22:13:52 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 07/01/2003 10:13:52 PM, Serialize complete at 07/01/2003 10:13:52 PM Content-Type: multipart/alternative; boundary="=_alternative 000C41D685256D57_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000C41D685256D57_= Content-Type: text/plain; charset="us-ascii" Doug, I don't believe that Bruce is telling people how he wants it - but rather how he "interprets" the draft. That's why we need an author of the original iTIP to tell us what they thought they meant. That's coming soon. 8-) ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 07/01/2003 20:16 Please respond to "ietf-calendar@imc.org" To: "ietf-calendar@imc.org" cc: Subject: Re: CAP draft - last call, etc. Satya Vempati wrote: > I might have misunderstood Bruce but I took it differently. Since > RECURRENCE-ID "never" changes in his model, SEQUENCE:0 is not really > required. All SEQUENCE numbers point to the same RECURRENCE-ID and there > is no need to "preserve" SEQUENCE:0. Ether way, it may break iTIP clients, but not the CAP protocol. And his belief is contrary to the text in iCAL/iTIP, he is simply telling people how he wants it, not how it is. Plus, the CUA can do a full REFRESH and ignore that rule anyway. -- 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 000C41D685256D57_= Content-Type: text/html; charset="us-ascii"
Doug, I don't believe that Bruce is telling people how he wants it - but rather how he "interprets" the draft.  That's why we need an author of the original iTIP to tell us what they thought they meant.  That's coming soon. 8-)
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

07/01/2003 20:16
Please respond to "ietf-calendar@imc.org"

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: CAP draft - last call, etc.





Satya Vempati wrote:
> I might have misunderstood Bruce but I took it differently. Since
> RECURRENCE-ID "never" changes in his model, SEQUENCE:0 is not really
> required. All SEQUENCE numbers point to the same RECURRENCE-ID and there
> is no need to "preserve" SEQUENCE:0.

Ether way, it may break iTIP clients, but not the CAP protocol.

And his belief is contrary to the text in iCAL/iTIP, he is simply
telling people how he wants it, not how it is.

Plus, the CUA can do a full REFRESH and ignore that rule anyway.


--

 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 000C41D685256D57_=-- From owner-ietf-calendar@mail.imc.org Tue Jul 1 23:14:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25963 for ; Tue, 1 Jul 2003 23:14:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6234SFK098035 for ; Tue, 1 Jul 2003 20:04:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6234SHk098034 for ietf-calendar-bks; Tue, 1 Jul 2003 20:04:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom 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.12.8) with ESMTP id h6234QFK098029 for ; Tue, 1 Jul 2003 20:04:27 -0700 (PDT) (envelope-from Doug@Royer.com) 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 h6234POR003580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Jul 2003 20:04:28 -0700 Message-ID: <3F024BB0.80706@Royer.com> Date: Tue, 01 Jul 2003 21:04:16 -0600 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 draft - last call, etc. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000506010307080909000705" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000506010307080909000705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > Doug, I don't believe that Bruce is telling people how he wants it - but > rather how he "interprets" the draft. You mean how he interprets" RFC 2446? It may effect CUA's that use CAP. But it will effect any iTIP CUA, it is not limited to CAP. -- 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 --------------ms000506010307080909000705 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MDIwMzA0MTZaMCMGCSqGSIb3DQEJBDEWBBTU EEyvcDmK7ZfdrtdDO8to3oTVQTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWx0p+Qs//OZG 60Zz7oICzoORaB+dpZsUlI6TxyeDZNEuLj6AXtNqs4zUjOtJLVkbbbCuYmEkwCsNStW0W7sC SEo9WYe61wbAX9xCu3PUS1aZHpBmZzVUSd5wXxLZfuUkWJ7alIhK029gJoLLyGGFbUoGkwr/ KNhCBlC5B90NhX72uSu4JigMGmnSi4EjpT/BtBZBbLg1o3sT9YFulmZI8LffuZfLihS8VLv2 y3FAx0hFiXlnfc9wz3DT4O2KqacNei9+gba1aXeB6nmqRay1s6LpVleYx+bT9hzLoomg092O 1bl2unW2nrPzciS56pjB2Ik0AX2lg6R+MqlG0+AhwQAAAAAAAA== --------------ms000506010307080909000705-- From owner-ietf-calendar@mail.imc.org Wed Jul 2 00:00:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27025 for ; Wed, 2 Jul 2003 00:00:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h623pAFK099284 for ; Tue, 1 Jul 2003 20:51:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h623pAmi099283 for ietf-calendar-bks; Tue, 1 Jul 2003 20:51:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom 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.12.8) with ESMTP id h623p7FK099277 for ; Tue, 1 Jul 2003 20:51:08 -0700 (PDT) (envelope-from Doug@Royer.com) 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 h623p4OR003946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Jul 2003 20:51:09 -0700 Message-ID: <3F02569C.6000804@Royer.com> Date: Tue, 01 Jul 2003 21:50:52 -0600 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: Changing iTIP RECURRECE rules [was CAP last call...] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060807090708000600070306" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060807090708000600070306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce - you are a friend - but in this debate I think you may be lost :-) Satya Vempati wrote: > I might have misunderstood Bruce but I took it differently. Since > RECURRENCE-ID "never" changes in his model, SEQUENCE:0 is not really > required. All SEQUENCE numbers point to the same RECURRENCE-ID and there > is no need to "preserve" SEQUENCE:0. His model is not iCAL or iTIP it is a NEW proposal for the next version of iCAL or iTIP. In iTIP: Hence, CUAs must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response. And what about the "ADD" method: 4.4.6 Add A New Instance To A Recurring Event This example adds a one-time additional instance to the recurring event. "Organizer" adds a second July meeting on the 15th. The text and examples CLEARLY show the SEQUENCE number being bumped and the new SEQUENCE has at least one instance in it that is NOT in SEQUENCE:0. Thus NO ONE CAN JOIN if you follow Burce's model and Bruce agrees. Then Bruce made a NEW assertion - that you MUST throw away the UID and start over. Sorry but his model is just not thought out. And what about: 4.4.7 Add A New Series of Instances To A Recurring Event ... Alternatively, if the "Organizer" is not concerned with per-instance updates, the entire event can be rescheduled using a "REQUEST". This is done by using the "UID" of the event to reschedule and including the modified "RRULE". Note, that since this is an entire rescheduling of the event, any instance-specific information will be lost. ^^^^^ ... It does not say, 'Throw away the UID', it says 'reschedule' using the 'UID' and 'any instance-specific information will be lost.'. Why is that confusing to anyone? If you follow the debate from the start by reading the archives I think you will agree that it started from an assertion that a specific vendor does it incorrectly and Bruce wanted to be compatible. For which I reply - you can be - ISSUE a full REFRESH and you are back in sync with that vendor. You do NOT need to re-issue an iTIP RFC removing MULTIPLE paragraphs saying you CAN reschedule. If that vendor throws away the UID - so what? It does not effect iTIP. It only effects those users who loose data - a point NOT disputed at all. My testing shows that that vendor CAN reschedule to an entirely different set of recurrence rules. No proof is provided from Bruce, just another assertion that if we break iTIP in this way it works in some new way and other things that were not busted are newly busted. Bruce has NOT shown any thing busted. He simply says that if you do something that is not documented (in a way that looks to me to be a way not to have to follow iTIP and bump the sequence number), then the undocumented way does not work. So what? Do it the documented way. This debate reminds me of a class project where you would get an 'A+' if you could so confuse a truth to make it appear to be a problem. Bruce gets an 'A++'. It is NOT busted! DO A REFRESH - AND the text in ITIP tells you HOW and WHEN to detect you need to do that REFRESH and for EXACTLY the reasons in this debate. Yet Burce has NEVER debated that fact. Bruce - you are a friend - but in this debate I think you may be lost :-) -- 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 --------------ms060807090708000600070306 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MDIwMzUwNTNaMCMGCSqGSIb3DQEJBDEWBBTY 2lNAIYUJF2c3GgFX92T0KZbuATBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEApfdSehtyBHm9 eEVWeVdXTZGj5efoCNrOZkHd28ssu1Pt+4+z6N4m6+xYTkZ1QilPV+Ba2womqHrdIPM8+CuG cGwDApoDlAzqgvOEJW94bJtY6AoM/KI8wxId9HrxwBHznl03KEw3cgmCfuKxC/E4+CLlbA51 csZB41qlh4rpIjLrKCVoPF6NACxzXXcgg2wkHs3FdHdPswG59c+3aZeFGwWgoySwIuy7FWSv ugYKypvsjh47Re47GG/vEXleNpmDhRawFG04PxaCCcGqkB9a+dSIr8rZ321KLn1uMUr1gMyP aKOcbnEhBvkTmFgCaw6QgcbzxeO5CJES32Z/0NG/HQAAAAAAAA== --------------ms060807090708000600070306-- From owner-ietf-calendar@mail.imc.org Wed Jul 2 13:44:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03819 for ; Wed, 2 Jul 2003 13:44:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62HTmFK070909 for ; Wed, 2 Jul 2003 10:29:48 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62HTmG3070908 for ietf-calendar-bks; Wed, 2 Jul 2003 10:29:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62HTkFK070897 for ; Wed, 2 Jul 2003 10:29:47 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: CAP draft - last call, etc. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: pregen@egenconsulting.com Date: Wed, 2 Jul 2003 13:29:51 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.12 |February 13, 2003) at 07/02/2003 01:29:48 PM, Serialize complete at 07/02/2003 01:29:48 PM Content-Type: multipart/alternative; boundary="=_alternative 00601E3485256D57_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00601E3485256D57_= Content-Type: text/plain; charset="us-ascii" Yes, I meant all the RFC's. And yes, if something is mis-interpretted, it affects a lot of things. Remember, all three drafts, iCalendar, iTIP and iMIP were written at different times and by different authors. So, to say there may be semantic issues is putting it mildly. And remember, we are in interop testing so that we can find these problems and resolve them. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 07/01/2003 23:04 Please respond to "ietf-calendar@imc.org" To: "ietf-calendar@imc.org" cc: Subject: Re: CAP draft - last call, etc. pregen@egenconsulting.com wrote: > > Doug, I don't believe that Bruce is telling people how he wants it - but > rather how he "interprets" the draft. You mean how he interprets" RFC 2446? It may effect CUA's that use CAP. But it will effect any iTIP CUA, it is not limited to CAP. -- 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 00601E3485256D57_= Content-Type: text/html; charset="us-ascii"
Yes, I meant all the RFC's.  And yes, if something is mis-interpretted, it affects a lot of things.  Remember, all three drafts, iCalendar, iTIP and iMIP were written at different times and by different authors.  So, to say there may be semantic issues is putting it mildly.  And remember, we are in interop testing so that we can find these problems and resolve them.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

07/01/2003 23:04
Please respond to "ietf-calendar@imc.org"

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: CAP draft - last call, etc.





pregen@egenconsulting.com wrote:
>
> Doug, I don't believe that Bruce is telling people how he wants it - but
> rather how he "interprets" the draft.

You mean how he interprets" RFC 2446?

It may effect CUA's that use CAP. But it will effect
any iTIP CUA, it is not limited to CAP.

--

 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 00601E3485256D57_=-- From owner-ietf-calendar@mail.imc.org Wed Jul 2 14:20:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05221 for ; Wed, 2 Jul 2003 14:20:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62I9rFK074268 for ; Wed, 2 Jul 2003 11:09:53 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62I9rwk074267 for ietf-calendar-bks; Wed, 2 Jul 2003 11:09:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62I9rFK074242; Wed, 2 Jul 2003 11:09:53 -0700 (PDT) (envelope-from arnaud.quillaud@sun.com) Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h62I9lKo002011; Wed, 2 Jul 2003 11:09:47 -0700 (PDT) Received: from gotmail-2.red.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by dm-usca15-11.red.iplanet.com (8.11.7+Sun/8.10.2/IPLANET,v1.2) with ESMTP id h62I9AN22835; Wed, 2 Jul 2003 11:09:10 -0700 (PDT) Received: from lamachine (vpn-129-150-17-197.SFBay.Sun.COM [129.150.17.197]) by we-gotmail.red.iplanet.com (Sun ONE Messaging Server 6.0 (built Jun 26 2003)) with ESMTP id <0HHE00L0FT490I30@we-gotmail.red.iplanet.com>; Wed, 02 Jul 2003 11:09:47 -0700 (PDT) Date: Wed, 02 Jul 2003 11:11:55 -0700 From: Arnaud Quillaud Subject: RE: CAP draft - last call, etc. To: "pregen@egenconsulting.com" , "ietf-calendar@imc.org" Cc: "owner-ietf-calendar@mail.imc.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bqfqwjAifsCoceXXXCenoQ)"; DIFFERENCES=Content-Language Content-language: en-USA Content-transfer-encoding: 8BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary_(ID_bqfqwjAifsCoceXXXCenoQ) Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-language: en-USA Content-Transfer-Encoding: QUOTED-PRINTABLE Talking about interop=85 =20 Are the results of the past interop meetings published somewhere ? Is there an =93official=94 list of tests ? When is the next interop meeting ? =20 Thanks, =20 Arnaud =20 -----Original Message----- From: pregen@egenconsulting.com [mailto:pregen@egenconsulting.com] Sent: Wednesday, July 02, 2003 9:30 AM To: ietf-calendar@imc.org Cc: owner-ietf-calendar@mail.imc.org Subject: Re: CAP draft - last call, etc. =20 Yes, I meant all the RFC's. And yes, if something is mis-interpretted, it affects a lot of things. Remember, all three drafts, iCalendar, iTIP and iMIP were written at different times and by different authors. So, to say there may be semantic issues is putting it mildly. And remember, we are in interop testing so that we can find these problems and resolve them. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652=20 =20 Doug Royer =20 Sent by: owner-ietf-calendar@mail.imc.org=20 07/01/2003 23:04=20 Please respond to "ietf-calendar@imc.org"=20 =20 To: "ietf-calendar@imc.org" =20 cc: =20 Subject: Re: CAP draft - last call, etc. pregen@egenconsulting.com wrote: >=20 > Doug, I don't believe that Bruce is telling people how he wants it - but= =20 > rather how he "interprets" the draft. You mean how he interprets" RFC 2446? It may effect CUA's that use CAP. But it will effect any iTIP CUA, it is not limited to CAP. --=20 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 --Boundary_(ID_bqfqwjAifsCoceXXXCenoQ) Content-id: 0 Content-type: TEXT/html; CHARSET=iso-8859-1 Content-language: en-USA Content-Transfer-Encoding: QUOTED-PRINTABLE =