Re: When to publish -12

[email protected]
Newsgroups gmane.ietf.calendar
Message-ID <OF8C1707F8.CDBD5F6B-ON85256DB2.006F7311-85256DB2.0071EBCA@notesdev.ibm.com>
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 protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.