Subject: [Fwd: Re: I did a checkin of CAP]

From: Doug Royer <[email-masked]>
Date: Mon, 24 Jun 2002 09:45:51 -0600

I did some diffs and in total over the last view edits I
added as many of the items that I could find on the list
over the last few months that had not been included. Including:

	Adding how to tag VALARMs as local so they
        are not exported during a REQUEST or COUNTER
        (LOCAL parameter + SEQUENCE property) ((mid FEB on list)

        Added a note about the problem of exporting VALARMs.
 
        Added more CAP-QL notes that I found as bugs. I don't
        think they changed the protocol, they just were not
        noticed before (locale effecting query sort order
        for example).

        Added that UTF-8 MUST BE the initial charset and
        that the default locale is not specified. Now
        the CUA can query the CS and select a locale. Prior
        to this the locale information was in the CS, but
        there was no way for the CS to specify it at run time.
        Added the SET-LOCALE (and charset) command. This was 
        on the list as a topic - no specific proposal was
        given.

        Added text on how a CUA knows the charset and locale that
        a CS I did -not- add the part of that debate that described
        how a CUA should synchronize with a CS, from the list
        it appeared that no one agreed to that part of my proposal.

        Adding how to tag VALARMS that are global and
        received as part of a REQUEST from being acted on.
        (ENABLE parameter) (mid FEB on list). This includes
        additions/changed to the ABNF - only effects CAP
        protocol - not iTIP or iMIP.

        Added text on how to disambiguate the effect of query.
        This is controversial. However I think I answered all
        questions I could find. Some may not be happy that the
        way they wanted it is not spelled they way they want,
        but I think it addresses their concerns.

        Added ABNF to update the 'calprops' ABNF name 
        so we could add properties to CAP and still call
        them VCALENDAR objects (only effect CAP protocol
        and not ITIP or iMIP).

        The CHILD vs RELATED-TO properties in the VCALSTORE
        are there. There was no proposal on how one VCALSTORE
        relates to another, but there was a great deal of
        email about adding RELATED-TO to the VCALSTORE for
        relating one to another. I never did fully understand
        the issue - but I added them. (related to removing
        hierarchy - but despite all of the email, I could
        not find a specific proposal)

        I did not add the VCOMMAND from -05 because it was
        a wrapper to the modified METHOD values, which we rejected.
        If we needed to, some version of it can be added back.
        (The issue was that if we modified METHOD, we needed
        a wrapper [VCOMMAND] so a CUA/CS would not confuse
        the object with a iTIP object). I had thought that
        it would be added, but once METHOD only meant iTIP,
        then 100% of all VCOMMANDS only contained VCALENDAR
        objects anyway so it seemed it did not need to be
        re-added. 

        I removed the unpopular METHOD also contains state
        (I had proposed that method mean ITIP + booked + deleted)
        and replaced with the STATE() method that means one
        of those same three states. And added text saying
        that it is implementation specific on how the state
        is stored - no one could agree on how, now it is
        up to the implementation. On the list I could only
        find one objection to STATE().

        I removed the need for 100% pure iTIP objects to
        contain the CREATE command, as 100% of the time
        it means CREATE them in the UNPROCESSED state.

        I removed many examples that seemed to duplicate
        other examples or iTIP. Still the draft is 130 pages.

        I removed using the METHOD property for issuing commands
        per the unpopularity of my proposal. Added CMD.
        moved the latency from the beep layer into CMD.

        Added separate sections describing each command that
        was not described in the past. (some were missing)

        Added the VREPLY component per popular demand to
        wrap all replies.

        Pat had said that we may wish to have a separate draft
        showing examples. I think that is a good idea.
  
        Altered the section on how to submit new objects
        and alter existing object per the very old action
        item list. (method reviewer replaced with - do
        an rfc).
 
        Moved all text describing the effect of X- objects
        to one location.

        I converted the REPLY restriction tables to ABNF.
        for two reasons (1) size now smaller, (2) ABNF is
        the way to do it in drafts. The only restriction tables
        that remain are the ones that describe how they
        specifically are effected by the subject of the text
        (unique to VCALSTORE, VAGENDA, ...).

        [still not done] Consistency in error codes.

Beep:
        Removed many BEEP examples and replaced them with 
        text/calendar examples.

        Added text describing the effect of BEEP virtual
        hosting. This has not been discused on the list
        and I only added that a CS/CUA may wish to use
        that beep feature, and if they do, how it effects
        CAP. (see new properties - summary section - CSID).

        Added text describing how the localize (locale) can
        effect CAP and how CAP should use it.

        [not done] The BEEP profile for CAP.

Changed things for consistency.

        Changed some names for consistency. 'OWNER' vs 'OWNER(),
        vs OWNER property'. Several on the list said there should
        not be 2 ways to say the same thing.  Same with NONOWNER
        vs 'NOT OWNER()'. One person did not want them to
        be the same, others did. There is now OWNER property
        and OWNER() method and 'OWNER' is not overloaded.
        (Plus OWNER and NONOWNER dissallowed UPNs of the same name).
      
        Changed CURRENT-CALID() to CURRENT-TARGET(), because it
        matched the TARGET value, not the contained calendar.
        (VCARS would always match them selves) I did not
        change the meaning, just how it is spelled. And it always
        meant target.

        In many places the term 'calendar component' was used
        and in others 'component' was used. I removed 'calendar'.
        Similar for properties and parameters.

        Removed (changed) the word 'event' when it did not
        mean 'VEVENT'. Most changed to the word 'object' or
        'component'.

In process:

        I am still reviewing the draft for consistency. I think
        that GET-CAPABALITIES and the VCALSTORE properties may
        still have some problems.

        I am still re-reading the last few months of posts
        looking for forgotten issues and resolutions.