Re: CAP -12 and LAST CALL (hopefully)

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug wrote on 08/11/2003 05:50:28 PM:
> If I do not get to it soon, feel free to use the diff tool of your
> choice and post them.

Not my job; thats something the editor
does.  

> Pat has just declared on this list that the CHAIRs
declare such a list,
> NOT the editors. Pat - do you have any open issues?

Thats NOT what she said.  She wrote:

>3.  Saying that no one responding to a comment
by Bruce stops the issue is
>the chairs call, not the editors.

Its the chairs call if the issue is
resolved or not; the list is not theirs to maintain.   Thats something
for the editor to do.  You did it before so you should be familiar
w/the process.

> > Examples of recenty issues:
> > 
> > The issue of searching scoping was raised and once the issue
was clear 
> > to everyone there was no discussion on resolving it.
> 
> It was addressed in CAP-11, the ABNF updates were made and I did
> comment in the CAP-11 announcement that no proposals were submitted.
> Bruce- did the updates in -11 solve the problem as you see it?

I did not see CAP 11.  As I said
I have too much to do to reread CAP 11 front to back to find the differences.
 Thats why I asked for a diff to be posted.  No diffs still for
10-11 so I was reposting what I could recall off hand.  I dont recall
seeing any WG discussion of some issues like the fact that queryc was only
in the CREATE command and no other.  I would expect that the ABNF
for all commands would be changed such that its clear what commands can
or cannot take queryc, etc but thats not something we talked about at all.

> > The issue of busytime lookups and maintenance
was rasied and I proposed 
> > a change but I dont know if it got into CAP 11 or the pending
12.
> 
> There have been lots of VFREEBUSY posts. Your proposal said
> for future use:
> 
>     ...I suspect that anything that can be CREATEd in your
queue needs to be
>     able to get searched for so you can remove 'em, process
'em, 
> etc.  Although
>     we dont have iMIP -> CAP designed now, it may be
possible in the future
>    (CAP creation is not the only way to get 'em into your
queue essentially).
> 
> I just re-read your reply and it did NOT include a proposal.
> Your (1) - was the reason I asked the question - when are they not
useless?
> Your (2) - is NOT what CAP does at this time. It does not get iMIP
>             messages.
> 
> So I'll ask - why do we want to store objects in CAP when NO tool
> can use  them? Why not add it later if need?

I had proposed that we reinstate the
text that was removed w/o WG discussion or approval that was in CAP-03
thru -05 that said that the CS maintained the busytime data (and other
stuff related to it).  I had even provided the snippets from 03 and
05 as reference.

Perhaps you missed that posting.

I want to be sure of what I think you
are saying:  Are you claiming as the current CAP author that we will
never support iMIP generated VFREEBUSY messages via CAP?  Thats what
I read you to say with "when are they not
useless?" but I could be
wrong

If its possible to have them ("useless"
!= "never") then CAP needs to be able to at least clean them
out if nothing else.  Even if the CS does not autoprocess them and
craft back some kind of iMIP VFREEBUSY REPLY, if they can get into your
queue then CAP MUST provide some way to find and remove them.  I would
expect that SEARCH with STATE()!='BOOKED' would mean this so STATE() may
be necessary for SEARCHing on VFREEBUSYs if only to remove them from your
queue.  Ideally the CS would handle processing of the requests (subject
to VCARs) and generate the proper iMIP REPLY but thats just an idea I have
and not actually in CAP...

You misunderstood (2).  If I can
CREATE a VFEEBUSY REQUEST in your queue by TARGETing it and the response
that the CS generates is "Yes, I created your VFREEBUSY REQUEST"
(which it logically means) then either A) CREATE needs to be reworked to
disallow this (assuming there is some other way to do busytime lookups!!)
or B) CREATE and SEARCH of VFREEBUSY components need to be beter codified
to their behaviour to distinguish exactly how busytime is searched for
in a CAP system.

And if you think no CAP client can use
a busytime system then you dont understand the use of busytime for dong
Scheduling.  Accurate busytime greatly improves the workflow process;
missing or inaccurate busytime greatly degrades the process.

> The XML->RFC tool may be busted. It is in
my XML here and it does
> not make it in to the TXT version, I'll hand edit CAP-12 (not from
the XML 
> source) to fix it until I can find the reason. (not sure when it
> got added as it did not show up in the TXT version).

This causes me some big concerns.  What
else may be missing?  What else may be in the XML version that disappears
in the TXT version that folks may object to but not know about?  As
long as the TXT is whats submitted then things may be ok but its sure gonna
make me leary of the TXT versions.  What about the HTML versions too??

> The missing text for SEARCH is (follows the ABNF):
> 
>     "The format of the request is the search command
(search-cmd) followed
>     by one or more (query) "VQUERY" components"
> 
> Followed by the 'Response' section and then examples of 'SEARCH'.

This is insufficient since this is not
reflected in the ABNF.  In previous drafts we've had text to the effect
of order of precedence:

   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 are missing it in CAP.  We
need something like this for resolving future disputes or to aid in interpreation.
 Otherwise its possible to generate ABNF accurate CAP payloads that
are nonsensical or conflict w/the prose and we have no way to resolve the
dispute.

Bruce
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.