Re: CAP-12 - interm version 'E'

Hi,

On Wednesday, October 1, 2003, at 08:10 PM, Doug Royer wrote:
> I have placed the latest edit of CAP for your review at:
> 	http://inet-consulting.com/draft-ietf-calsch-cap-12-e.txt

While reading this draft, some comments (so far).
I apolagize if it opens old discussions.


1)
Why is the BEEP profile defined in this draft. Would it not be better
to seperate it?
Maybe it is also useful advancement of the standard.

2)
Section 1.2, Related documents could be a bit extended in explaining
the way this draft uses those other RFCs. Now they just specify what
they are.

3)
The first definition of section 1.3 seems od to me. The definition
is "BOOKED", but than it is actually a state which may have three
values, "UNPROCESSED", "BOOKED", "DELETED". IMHO, on should define
the definition state.
Now I can simply wonder why "UNPROCESSED" is not a definition either.

The part "marked for delete" I would restate as "deleted". First thought
was now, is 'marked' also a state?

I am neither sure if one already needs to specify  here the part of
'A "BOOKED" state entry is stored with the "CREATE" command.',
since there is nothing explained about command that would help the
reader here.

4)
Calendar Store Identifier (CSID) is defined by
'A CSID consists of the host and port portions of a "Common Internet
Scheme Syntax" part of a URL, as defined by [URL]'
However, section 8.9 has in the example also the scheme (protocol) part.

This looks to me a mixture with Calendar Identifier (CALID) that
start with "cap:". With respect the the "cap:" part we are aware that
then CAP is the only method to access a calender. Not like 'ftp' and 
'http'
that are different protocols but could access the same resource.

5) NIT
The reference of the RFCs have a URL not of http://www.ietf.org/rfc/
I am not fully sure what IETF policy is here.

Harrie