Subject: Re: When to publish -12

From: [email-masked]
Date: Wed, 1 Oct 2003 16:49:10 -0400

Doug claimed on 09/23/2003 05:20:45 PM:
>> 1: Busytime in CAP 
> So what is the issue?

This was originally raised back ~ 31-Mar-2003 and briefly revisited in 
late July before the big digression and then we lost focus on it.  CAP 
12-e still claims:

1. Introduction

   This document specifies how a Calendar CUA interacts with a CS to
   manage calendar information. In particular, it specifies how to
   query, create, modify, and delete iCalendar components (e.g., events,
   to-dos, or daily journal entries). It further specifies how to search
   for available busy time information.

However I can find NOTHING in CAP that actually "specifies how to search 
for available busy time information".  In the process of researching this 
since I thought we had it covered at one time I found that it was in 
CAP-03 thru -05 but got removed in -06 for some reason.  There was NO WG 
discussion on the removal and we never quite reached any agreement more 
recently on the proposals on how to directly address this in CAP.

In searching CAP-12-e I find the word 'busy' only mentioned in the text 
above, as part of a response comment in Section 8.28 REQUEST-STATUS 
property and then in some text in Section 8.37 TRANSP Property but no 
actual specification I can find.  Perhaps Im just missing it..??

> > 2: 'Scoping' concerns raised by Preson in April 2003.
> >
> > I know for one that I did not agree w/Dougs summary of what he thought 

> > Craig proposed (ie: 'Use existing CMD:CREATE to store VFREEBUSY 
> > objects." ) ... 
> 
> Do *YOU* have  a proposal? Others did and their comments were 
incorporated.

As Ive said before, just because you find an issue does not mean you have 
to propose a solution.  I had to argue enough w/you on it originaly just 
to get you to recognize the problem (or at least I think you recognized it 
but I could be wrong).  Ill look at CAP-12-e to see if there is text that 
deals with breaking scoping of the SEARCH command.  Im quite interested in 
seeing what you wrote considering you never proposed any fixes for WG 
discussion yourself.

> Not all of CAP is in ABNF. Read the text and you will find out when it 
> is used.
> If you have ABNF proposals - please post them, if not it looks to me as 
> if CAP
> explains when they can be used.

For the base RFCs we had:

   The memo also includes a formal grammar for the content type based on
   the Internet ABNF defined in [RFC 2234]. This ABNF is required for
   the implementation of parsers and to serve as the definitive
   reference when ambiguities or questions arise in interpreting the
   descriptive prose definition of the memo.

but we dont seem to have anything like this in CAP.  Why is that?  What 
good is provding ABNF that is not accurate??  Text can be too imprecise 
and not useful for building systems on.  Thats why we provided an ABNF so 
we can have a definitive way to interpret the text.   I think the ABNF in 
CAP should be just like it was in iCalendar so we have something clear and 
precise to use.  Relying on vague text is too error prone.

Im not going to waste my time giving you new ABNF if you'll just ignore 
it.  If I thought it would be useful I would do it but I wont waste my 
time otherwise.

> I do not see any debate on dropping QUERYID, in fact the archive is full
> of discussions on how to use it, and what to name it and how to describe
> how to use it.

If you are not storing querys in the CS then you certainly dont need a 
QUERYID property to find it do you?  It belongs in the followon text that 
addresses stored queries, not in CAP 1.0 where it serves no use.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 01 Oct 2003 15:57:31 -0600

[email-masked] wrote:

> However I can find NOTHING in CAP that actually "specifies how to 
> search for available busy time information".  ...

How about the entire section  named: "10.12.1 Searching for VFREEBUSY" ?

-- 

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

                We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Wed, 01 Oct 2003 16:00:33 -0600

[email-masked] wrote:

> As Ive said before, just because you find an issue does not mean you 
> have to propose a solution.  I had to argue enough w/you on it 
> originaly just to get you to recognize the problem (or at least I 
> think you recognized it but I could be wrong).  Ill look at CAP-12-e 
> to see if there is text that deals with breaking scoping of the SEARCH 
> command.  Im quite interested in seeing what you wrote considering you 
> never proposed any fixes for WG discussion yourself.

I still have no clue what you are talking about when you say 'scoping' that
have not been addressed.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 01 Oct 2003 16:08:43 -0600

[email-masked] wrote:

> but we dont seem to have anything like this in CAP. 

No one believes that there is nothing like ABNF in CAP.

>  Why is that?  What good is provding ABNF that is not accurate?? 

It it accurate. If you want 100% of CAP to be in ABNF -  propose the ABNF
to the list. Just like the query reply, some things just do not make 
good ABNF.

> Im not going to waste my time giving you new ABNF if you'll just 
> ignore it.  If I thought it would be useful I would do it but I wont 
> waste my time otherwise.

Yea right. So, I am supposed to do 100% of this work with NO proposals 
at all.
No, I would get hate mail if I were to do all of that with no proposal 
at all
and then put it into CAP at this point. No proposal submitted means I am not
going to add it to CAP without a proposal and then only if the chairs 
call consensus on
that proposal.

The only changes going into CAP are typos, clarifications, fixing text 
or ABNF
that has issues unless the chairs call consensus for a proposal to be 
incorporated
into CAP.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 01 Oct 2003 16:10:22 -0600

[email-masked] wrote:

> QUERYID property to find it do you?  It belongs in the followon text 
> that addresses stored queries, not in CAP 1.0 where it serves no use.

Again - the auto execution of stored queries was removed per the 
overwhelming
WG discussion.

--

---

From: Mark Smith <[email-masked]>
Date: Wed, 01 Oct 2003 16:25:56 -0600

[email-masked] wrote:
> search for available busy time information".  In the process of
> researching this since I thought we had it covered at one time I found
> that it was in CAP-03 thru -05 but got removed in -06 for some reason.
>  There was NO WG discussion on the removal and we never quite reached
> any agreement more recently on the proposals on how to directly
> address this in CAP.
> 
> In searching CAP-12-e I find the word 'busy' only mentioned in the
> text above, as part of a response comment in Section 8.28
> REQUEST-STATUS property and then in some text in Section 8.37 TRANSP
> Property but no actual specification I can find.  Perhaps Im just
> missing it..??

See pages 124-125

---

From: [email-masked]
Date: Thu, 2 Oct 2003 11:19:02 -0400

> > Property but no actual specification I can find.  Perhaps Im just

Thanks for the poniter.  Perhaps it is just a labeling thing now, perhaps 
not.  You are referring to Section 10.12.1 Searching for VFREEBUSY yes? 
Thats actually on pages 125-126, at least in the TXT version. 

May I suggest we retitle Section 10.12.1 to be "Searching for busy time" 
since that makes finding it easier when just searching for phrases like 
"busy time" (to match the text in the ? 

This section is better than what we had before (which was nothing really) 
but its not complete or what I would consider totally correct (a different 
matter for discussion though).  For example the text in 12-e says:

   If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the
   "VFREEBUSY" component in the "COMPONENTS" value in a reply to the
   "GET-CAPABILITY" command, then it is the CS's responsibility and not
   the CUA's responsibility to provide the correct "VFREEBUSY"
   information for a calendar.  Therefore,

Umm, where is the rest of the last sentence?  Did it get cut off by the 
XML Conversion tool or was the thought not finished?

Ill read this section over and create a new thread for it accordingly 
since I see some other things to comment on.  Thanks again for the 
pointer.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 02 Oct 2003 11:48:53 -0600

[email-masked] wrote:

> Umm, where is the rest of the last sentence?  Did it get cut off by 
> the XML Conversion tool or was the thought not finished?

'Therefore,' -  removed.

--

---

From: [email-masked]
Date: Fri, 31 Oct 2003 13:49:37 -0500

> Again - the auto execution of stored queries was removed per the 

The proposal and agreement was on the removal of references to stored 
VQUERYs and that it be deferred to a later draft.   QUERYID is ONLY useful 
for stored VQUERYs so as such it to should be removed from CAP 1.0.  Its 
still in CAP-12-e.

The reference under Section 2.1.2 New Properties (summary) needs to be 
removed along w/Section 8.27 entirely.  They correctly belong to the draft 
that adds stored queries, not to CAP 1.0. 

Also, Section 3.2 Calendar Store Object Model shows stored VQUERYs in the 
Calendar Store diagram.  This too should be deferred to the followon 
draft. 

Bruce

---

From: [email-masked]
Date: Fri, 31 Oct 2003 14:14:21 -0500

> I still have no clue what you are talking about when you say 'scoping' 
that

Go check the archives for Presons posting on 04/03/2003 02:36:12 PM MST 
under the subject "How do you get the METHOD property on a SEARCH". There 
was a brief WG flurry about it but no actual resolution on it

Bruce
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Fri, 31 Oct 2003 13:23:09 -0700

[email-masked] wrote:

> Go check the archives for Presons posting on 04/03/2003 02:36:12 PM 
> MST under the subject "How do you get the METHOD property on a 
> SEARCH".   There was a brief WG flurry about it but no actual 
> resolution on it

Now go read the rest of the archives. you will find there was 
a solution sent to the list.

Do you have another proposal?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

---

From: [email-masked]
Date: Fri, 31 Oct 2003 14:09:25 -0500

> No one believes that there is nothing like ABNF in CAP.

Again I cant tell if you are purposely misreading what I said to draw 
things out or if you just didnt understand it.  I noted that CAP has NO 
paragraph in it like the cited one from 2445 that says the ABNF is 
definfitive over the text when interpreting the CAP text.  So when 
implementors try to implement CAP they have something to allow them to 
resolve issues.

Unfortunately CAP has nothing like this nor is the ABNF consistantly 
organized/formatted.  This means a CAP parser has nothing it can use to 
determine if the command / payload are properly constructed or not.  To me 
this is not goodness but perhaps Im the only one who thinks this...

> to the list. Just like the query reply, some things just do not make 

The ABNF is not considered more definitive ("accurate") than the prose 
when issues or questions arise.  That was the main point.

In reponse to your "If you want 100% of CAP to be in ABNF" quip, we all 
should want this.  By that I mean that there is nothing described in prose 
that is NOT represented in ABNF somewhere in CAP.  Otherwise you could 
have text with no ABNF that can be used in implementations to confirm 
validity.  I dont see how that would be a good thing so perhaps you could 
explain how it would be.

> Yea right. So, I am supposed to do 100% of this work with NO proposals 

If all you respond to is proposals or text that says "I propose" then Ill 
try that...

I propose that CAP Section 1 Introduction be changed to, somewhere, 
include the text:

I further propose that the ABNF currently in CAP be checked for 
consistancy of layout.  The ABNF for commands seems to vary in style which 
is probably legacy from the multiple editors we've had.  It is not that 
burdensome a think to ask of the editor given how prolific he is with 
spinning out additional CAP addon drafts is it? 

Bruce