Re: When to publish -12
| 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...