Subject: When to publish -12

From: Doug Royer <[email-masked]>
Date: Tue, 23 Sep 2003 11:31:12 -0600

As the MN IETF is coming up I plan to publish -12 about Oct 15 th.

-12-d has the latest typos and the updated BEEP profile in it.

I do not plan on putting the CALSCALE capability into CAP unless
the chairs call consensus on it to be added. It can be added later when (if)
someone publishes a new CALSCALE value.

Again I am down to zero CAP items.

-- 

 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: [email-masked]
Date: Tue, 23 Sep 2003 15:58:12 -0400

> Again I am down to zero CAP items.

Not so fast Doug.  There are at least 2 other known big issues still to be 
resolved, even if you refuse to track them.

1: Busytime in CAP
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." 
) and we never fully resolved the issue before the long argument over 
RECURRENCE-ID.

Other smaller issues include:

I see that despite my prior postings about the poor ABNF, some changes 
have yet to still be made regarding queryc.  According to the ABNF, the 
_only_ command that can have a VQUERY component in it is the CREATE 
command.  This is wrong and was already noted in May/June 2003 but still 
remains unfixed. 

An analysis of the ABNF shows that queryc is ONLY used in the create-comp 
which only occurs for the CREATE command.  As such, it is not legal by the 
ABNF to have a VQUERY inside a DELETE or SEARCH command.   Clearly this 
was not intended but its not been corrected yet either.  The ABNF for some 
commands like CREATE are well structured and have relatively clear request 
and reply sections but other commands like DELETE do not.  The ABNF needs 
to be cleaned up and made consistant.

The text of the CREATE command needs to be reordered a bit to be more 
logically correct.  Currently, right after the "Formal Defintiion" text is 
a block titled "Response:".  Further down is the text that describes the 
actual "request" (my lable).  This seems backwards; the "request" bit of 
the command should be described before the "response" bit unless you like 
confusing readers.  This same ordering check should be done to all 
commands.

Lastly, I also see some changes that did not get fully done in CAP-12-c or 
-d.  Some references to stored queries were removed but not all:

   QUERYID -  A unique id for a stored query. (Section 8.27)

can be removed along with all of Section 8.27 and any other references to 
queryid.

Section 9.6 VQUERY Component needs to be updated a bit more to justt:

9.6 VQUERY Component

   Component Name: VQUERY

   Purpose: A component to specify what is to be fetched from a CS.

   Formal Definition: A "VQUERY" component is defined by the following
   notation:

   queryc    =  "BEGIN" ":" "VQUERY" CRLF
                queryprop
                "END" ":" "VCAR" CRLF

   queryprop = 1*(
             ; the following MUST occur at least once
             ;
             query /

             ; 'expand' is OPTIONAL but MUST NOT occur
             ; more than once.

             expand /

             ; the following are OPTIONAL, and MAY occur
             ; more than once
             ;

             other-props
           )

   Description: A "VQUERY" contains properties that specify which
   properties and components the CS is requested to return during a
   SEARCH command.

   For examples, see Section 6.1.1.

Also, technically speaking a VQUERY is NOT just used "to specify what is 
to be _fetched_" because the VQUERY can be (once we fix it) used in more 
than the just the SEARCH command.  When used on some commands it "specifys 
a set of components to apply the command to", whatever the command is that 
uses it.  That is, it specifys the set of components to delete on the 
DELETE command, those to move with the MOVE command, etc.  Not every 
command "fetches" components so this Purpose is incorrect as it stands 
now.

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: Tue, 23 Sep 2003 15:20:45 -0600

[email-masked] wrote:

> Not so fast Doug.  There are at least 2 other known big issues still 
> to be resolved, even if you refuse to track them.
>
> 1: Busytime in CAP 

So what is the issue?

> Craig proposed (ie: 'Use existing CMD:CREATE to store VFREEBUSY 
> objects." ) ... 

Do *YOU* have  a proposal? Others did and their comments were incorporated.

> have yet to still be made regarding queryc.  According to the ABNF, 
> the _only_ command that can have a VQUERY component in it is the 
> CREATE command.  This is wrong and was already noted in May/June 2003 
> but still remains unfixed.  

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.

>
> Lastly, I also see some changes that did not get fully done in 
> CAP-12-c or -d.  Some references to stored queries were removed but 
> not all: 

On this topic I will wait for consensus to be called. The only thing I 
can find
is that auto-execute of queries was to be dropped was the topic. Not 
that some
components types could not be saved.

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.

--