Re: CAP draft goals

[George Babics <georgeb@xxxxxxxxxxx>]

  I agree. We need try to have a last call for CAP very soon and try
not to add any new features. We simply need to quickly resolve all open
issues. Hopefully, BEEP will be the last major change to CAP.

  We need more people to review the latest version of CAP.

  At the August IETF Ned Freed suggested that CAP use BEEP. Paul initially
looked at using BEEP, but did not have the time to do it. We took the
assignment. And in October it was agreed on the list to change CAP to
use BEEP.

  As a result many modifications had to be done to CAP. It required much
time and effort. We wanted it to be done as quickly as possible so that it
could be presented at the IETF in December 2001, so that we could soon
make a last call, and that we can get feedback quickly.

  When we changed CAP to use BEEP our intent was to follow generally
accepted practice among the BEEP community.

  The new version of CAP was well received at the IETF. It was even
reviewed by people who understand BEEP well. Its author told us that
our use of BEEP was correct.

  A beep profile must define the application layer. The BEEP framework 
itself handles the exchange of messages, authentication and encryption. 
These two levels are not equivalent to what was previously referred to 
as the transport layer and the application layer in the previous version
of CAP.

  When we changed CAP to a BEEP profile, CAP was partitioned in two
layers: a command layer and a data layer. The command layer uses the mime
content-type "application/beep+xml", and defines all the messages listed
in section 8 (the BEEP Profile Registration). The data layer uses iCalendar
to describe the components listed in section 2.2 (Calendar Store Object Model).

  These changes were highlighted in November, when the latest version
of CAP was announced. (See my post on the 21st of November 2001: "Latest
Version Of CAP".)

  Please read BEEP, RFC3080, for more information. Furthermore, you can look at
other drafts and RFCs that use BEEP to get a better understanding of how various
protocols use BEEP.

  If changes were made that are not directly related to BEEP and have changed
the protocol, please point them out. They can be fixed. Much had to be changed for
BEEP, and we may have inadvertently changed something due to misunderstanding,
haste, or oversight.

  Please review the latest version of the draft since many changes have been
done. So far we have received comments or corrections on the new draft from
only three (3) people. We need people to review the examples, definitions, text,
restriction tables, syntax, etc.

  The latest interim version of the draft is available at:

    http://www.calsch.org/ietf/drafts.html

  Let us try to get a last call for CAP that we can present at the IETF
in March.

George


pregen@xxxxxxxxxxxxxxxxxx wrote:
> 
> Hi, I just wanted to take a minute and solicit comments from the list regarding CAP.  We are
> really pushing hard to make a last call to the working group on CAP.  This is to occur by the
> middle of February so the draft can be discussed in Minn in March.  As is usual, there are always
> a few people that make comments - we need a lot of people making comments.  Please take the time
> to read the newest version (the one where we took at transport items).  I know Doug has been
> reading it as well, but I'd like to see other comments from the peanut gallery.  However, I do
> want to stress that we not "re-open" issues that have already been resolved.  The purpose of this
> note is to say read the draft - find obvious problems and let's fix them.  I appreciate your help.
>  Also, we can use assistance working on the draft.  Keep those cards and letters coming!!
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652