Subject: CAP-12 - interm version 'E'

From: Doug Royer <[email-masked]>
Date: Wed, 01 Oct 2003 12:10:17 -0600

I have placed the latest edit of CAP for your review at:

	http://inet-consulting.com/draft-ietf-calsch-cap-12-e.txt

	http://inet-consulting.com/draft-ietf-calsch-cap-12-e.html

	http://inet-consulting.com/draft-ietf-calsch-cap-12-e.xml

-- 

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: Harrie Hazewinkel <[email-masked]>
Date: Tue, 7 Oct 2003 11:17:09 +0200

Hi,

> 	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

---

From: Doug Royer <[email-masked]>
Date: Tue, 07 Oct 2003 10:59:14 -0600

Harrie Hazewinkel wrote:

> to separate it?

There was  a decision to use BEEP.

In order for a protocol to use BEEP it requires that the protocol define
the BEEP profile. I do not think we can separate them.

> the way this draft uses those other RFCs. Now they just specify what

Trying to explain without repeating or accidentally redefining text is
difficult. [GUIDE] ties them together.

> 3) The first definition of section 1.3 seems od to me. The definition

An object has 3 states, one of which is booked. I'll update the text to be
more clear.

> However, section 8.9 has in the example also the scheme (protocol) part. 

I'll update the text to say and the scheme is included as ....

> then CAP is the only method to access a calendar. Not like 'ftp' and 
> 'http'

I do not follow your point.

--

---

From: Harrie Hazewinkel <[email-masked]>
Date: Fri, 17 Oct 2003 16:53:30 +0200

HI,

With respect to section "10.9 MODIFY Command".

1) at the end of page 115:
>    The format of the request is two components inside of "VCALENDAR"
>    component:

The example below looks to me to have 3 components, or is VQUERY not
a component?? Section 9.6 makes believe it is a component and so is the
text afterwards.

I believe you are referin to the 2 components (1, old values and 2, new 
values)
as those two.

2)
The format explanation after the formal definition end
with "END:CALENDAR" which must be "END:VCALENDAR"

3)
The text also mixes upper and lower case for old-values and new values.
Maybe all lower case?? Since it has only once "OLD-VALUES".

4)
The first example misses the "END:VCALENDAR".
The example als says "End of new data" which should be "Start of new 
data".

regards,

Harrie

---

From: Doug Royer <[email-masked]>
Date: Mon, 20 Oct 2003 13:33:53 -0600

>>    The format of the request is two components inside of "VCALENDAR"
Your right, itis three - fixed.

> I believe you are referin to the 2 components (1, old values and 2, 
> new values)
> as those two.
>
> 2)

thanks fixed.

> Maybe all lower case?? Since it has only once "OLD-VALUES". 

Thanks fixed - lower case,.

> The example als says "End of new data" which should be "Start of new 

Fixed - thanks.

--