Calendaring and Scheduling

Doug Royer | 1 Jul 2003 05:18

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 <at> egenconsulting.com wrote:

(Continue reading)

headers

Satya Vempati | 1 Jul 2003 18:46

RE: CAP draft - last call, etc.

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 <at> royer.com]

Sent: Monday, June 30, 2003 8:19 PM

To: ietf-calendar <at> 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 <at> 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 <at> 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

headers

pregen | 1 Jul 2003 19:21

Re: CAP draft - last call, etc.

What about the scoping issue?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

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

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

To: ietf-calendar <at> 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 <at> 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 <at> 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

headers

Bob Mahoney | 1 Jul 2003 20:19

RE: CAP draft - last call, etc.


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.

headers

Doug Royer | 1 Jul 2003 21:07

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 <at> 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

Attachment (smime.p7s): application/x-pkcs7-signature, 4411 bytes

headers

Satya Vempati | 1 Jul 2003 23:00

RE: CAP draft - last call, etc.

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 <at> royer.com]

Sent: Tuesday, July 01, 2003 12:07 PM

To: ietf-calendar <at> 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 <at> 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

headers

Doug Royer | 2 Jul 2003 00:25

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 <at> 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

Attachment (smime.p7s): application/x-pkcs7-signature, 4411 bytes

headers

Satya Vempati | 2 Jul 2003 01:03

RE: CAP draft - last call, etc.

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 <at> royer.com]

Sent: Tuesday, July 01, 2003 3:25 PM

To: ietf-calendar <at> 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 <at> 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

headers

Doug Royer | 2 Jul 2003 02:16

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 <at> 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

Attachment (smime.p7s): application/x-pkcs7-signature, 4411 bytes

headers

pregen | 2 Jul 2003 04:13

Re: CAP draft - last call, etc.

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 <at> royer.com>
Sent by: owner-ietf-calendar <at> mail.imc.org

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

To: "ietf-calendar <at> imc.org" <ietf-calendar <at> 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 <at> 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

2	October 2009
1	August 2009
1	March 2009
2	December 2008
2	July 2008
1	March 2008
1	December 2007
1	August 2007
7	July 2007
2	May 2007
4	April 2007
1	March 2007
1	October 2006
2	April 2006
1	January 2006
2	December 2005
4	November 2005
15	October 2005
2	September 2005
13	August 2005
18	July 2005
13	June 2005
6	May 2005
11	April 2005
7	March 2005
2	February 2005
10	January 2005
4	December 2004
2	November 2004
6	October 2004
7	September 2004
37	August 2004
16	July 2004
39	June 2004
31	May 2004
14	April 2004
27	March 2004
23	February 2004
16	January 2004
118	December 2003
178	November 2003
60	October 2003
160	September 2003
394	August 2003
132	July 2003
96	June 2003
116	May 2003
131	April 2003
159	March 2003
135	February 2003
180	January 2003
35	December 2002
132	November 2002
177	October 2002
186	September 2002
98	August 2002
57	July 2002
94	June 2002
29	May 2002
17	April 2002
185	March 2002
576	February 2002
494	January 2002
131	December 2001
244	November 2001
74	October 2001
15	September 2001
161	August 2001
100	July 2001
70	June 2001
142	May 2001
103	April 2001
233	March 2001
202	February 2001
53	January 2001
58	December 2000
73	November 2000
52	October 2000
68	September 2000
168	August 2000
66	July 2000
51	June 2000
16	May 2000
100	April 2000
94	March 2000
119	February 2000
133	January 2000
31	December 1999
36	November 1999
115	October 1999
67	September 1999
173	August 1999
219	July 1999
99	June 1999
119	May 1999
73	April 1999
222	March 1999
44	February 1999
38	January 1999
65	December 1998
54	November 1998
20	October 1998
61	September 1998
21	August 1998
10	July 1998
15	June 1998
19	May 1998
50	April 1998
108	March 1998
31	February 1998
67	January 1998
125	December 1997
339	November 1997
81	October 1997
174	September 1997
191	August 1997
257	July 1997
19	June 1997
81	May 1997
72	April 1997
87	March 1997
84	February 1997
54	January 1997
296	December 1996
216	November 1996
38	October 1996
37	September 1996
80	August 1996
33	July 1996
1	March 1996

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31