Subject: CAP Last call???

From: [email-masked]
Date: Wed, 12 Mar 2003 12:35:26 -0500

I've been watching the exchange of emails and many of them are bringing up
old topics.  At this point, I'd like to propose a last call on CAP.  Guys,
we need to get something out there for vendors to try to implement.  It's
only at that point that we really find out what does or does not work.  We
are NEVER going to have a perfect solution.  At this point, I'll take a
"mediocre" solution - because at least it's something.  So, that being
said, I am formally proposing a last call on CAP.  All those violently
opposed please respond to the list with specific reasons why you are
opposed.  Also, respond to the list if you are in favor of a last call.  We
can't do HMMMMs on the list - but we can do electronic "thumbs up".  Those
will work as well.  We'll talk more about this at the IETF meeting in SFO.
If you can not be there, try using the Jabber method to participate.

---

From: John Stracke <[email-masked]>
Date: Wed, 12 Mar 2003 14:45:51 -0500

[email-masked] wrote:

>So, that being
>opposed.
I am opposed to including sorting.  Server-side sorting:

    * Will increase CPU and buffering requirements on the server, which
      will hurt scalability.
    * Will increase latency.
    * Will not be of substantial benefit to clients.  Server-side
      sorting has been advocated as being helpful for
      resource-constrained clients such as PDAs; but, realistically, a
      client that cannot afford to sort a set of events is going to have
      difficulty displaying that set.
          o There is one narrow set of clients which are an exception
            here: Web-based CUAs.  Some simple UIs can be rendered more
            efficiently if the application can stream data down from the
            CS, transform each event it sees into HTML, and then discard
            the event without buffering; if the stream from the CS is
            not ordered, then it must be buffered and sorted.
          o However, this is less of a constraint than it seems.
             Normally, in a large-scale Web-based application, there are
            many Web servers and few database servers (or, in this case,
            few CAP servers); if the sorting has to be done, it should
            be done in the Web servers, to spread out the cost of
            sorting.  (Scalability again: it's normally cheaper to buy
            10 boxes with, say, 2 GIPS and 2G RAM apiece than to buy 1
            box with 10 GIPS and 10G RAM.)
    * Will actually increase costs for some constrained clients, such as
      wireless devices where connect time is charged by the minute.
       Increased latency means increased connect time, after all.

I realize that we've gone over this before; but, if Doug's dates are 
correct, then this is stuff I learned after we discussed it last, while 
building eCal's second-generation product.

-- 
/================================================================\
|John Stracke      [email-masked]                         |
|Principal Engineer|http://www.centive.com                       |
|Centive           |My opinions are my own.                      |
|================================================================|
|"There is also plenty of marine life in the Virgin Islands,     |
|although due to poor planning it is located underwater." -- Dave|
|Barry                                                           |
\================================================================/

---

From: [email-masked]
Date: Thu, 13 Mar 2003 14:47:50 -0500

Pat wrote on 03/12/2003 12:35:26 PM:
> old topics. 

Thats probably because we never reached concensus on some of them before 
moving on. 

I havent seen an updated CAP issues list in probably a year so its hard to 
tell if we've discussed them all and resolved them.  The last reference to 
it I can find (not an actual WG posting) was by George B. back on 
30-Jan-2002 under the heading "Updated CAP To Do and Issues List".  Until 
we can say we've at least covered THOSE issues I think we cannot go to 
Last Call.

> It's
> "mediocre" solution - because at least it's something. 

Id prefer a solution that while not perfect does not make fixing things in 
the future so Bisentine or impractical as to be nearly impossible.  No 
protocol has been "perfect" out of the shoot (POP3 is 3rd revision, 
IMAP4rev1 is 4th revision, etc) but before we can push the baby out the 
door we need to make sure we dont have just danging holes in it or cruft 
that is not relevant / useful anymore.

>                                                           All those 
violently
> opposed please respond to the list with specific reasons why you are

We have unresolved issues that have not been declared as resolved:

1: Stored queries (no demonstrated usefulness for PDAs or 'fat' clients 
alike given our query language).
2: Sorting (see John's postings as far back as 2000 even).
3: The BEEP examples and registration profiles (ie: Section 12.1. BEEP 
Profile Registration  of the Draft 10-17Feb2003) is not even filled in 
_let alone_ discussed at all in the WG.  It is still "TBD" in the latest 
draft.
4: We have not made sure that any CAP issues that we overlooked have been 
addressed.  Examples of this include those:
        A: Deletion vs 'marking for deletion".  Its totally unclear what 
the disction is, what benefit 'marked for deletion" is and if it possible 
to undelete, etc.
        B: Multipart MIME support.  There is no text or examples dealing 
with how multipart MIME should be properly dealt with in CAP.  I had hoped 
we would have learned from iTIP interop testing but so far no...
        C: CAP preservation of IANA or X- properties/parameters, etc. 
Unlike iTIP where some properties are not guaranteed to be preserved by 
different implementations, CAP is how a CUA accesses a store so it SHOULD 
preserve everything.  This is NOT clearly defined and proscribed for any 
CS.
5: We have made

The last posted CAP issues list was dated 03/15/2001 12:45:39 PM by George 
B.  There is an online one at the calsch web site that may or may not be 
insyc with that list and it has 25 unresolved issues on it with various 
assignments.  Im sure some have to have been done by now but I say we 
update that list to make sure we cover them all.

There are 'known issues' that we have decided to ignore for CAP 1.0 but 
they are NOT listed in any "Known Issues" section of CAP and they should 
be.  It is MUCH better for us to say "Here are the areas we know are 
touchy and have decided to punt on.  Implementations cover them at their 
own risk....".  Better to acknowledge all the big cow patties than to 
pretend they are not there!

>                We'll talk more about this at the IETF meeting in SFO.

I wont be in SFO and cannot make any promises about eAttendance.  Last 
time I tired it did not even limp along.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Thu, 13 Mar 2003 15:08:58 -0500

Pat wrote on 03/12/2003 12:35:26 PM:
>                                                All those violently

Another issue from WAAAY back was the proliferation of top level Response 
Codes in CAP.  From Section 10.11. Response Codes:

    Code              Description
    --------------------------------------------------------------
    2.0               Success. The parameters vary with the
                      operation and are specified.

    2.0.3             In response to the client issuing an
                      "abort" reply, this reply code indicates
                      that any command currently underway was
                      successfully aborted.

    3.1.4             Capability not supported.

    4.1               Calendar store access denied.

    6.1               Container not found.

    6.2               Attempt to create or modify an object
                      such that it would overlap another object
                      in either of the following two circumstances:

                      (a) One of the objects has a TRANSP
                      property set to OPAQUE-NOCONFLICT or
                      TRANSPARENT-NOCONFLICT.

                      (b) The calendar's ALLOW-CONFLICT
                      property is set to FALSE.

    6.3               Bad args.

    6.4               Permission denied - VCAR restriction.
                      A VCAR exists and the CS will not perform
                      the operation.

    7.0               A timeout has occurred. The server was
                      unable to complete the operation in the
                      requested time.

    8.0               A failure has occurred in the CS
                      that prevents the operation from
                      succeeding.

    8.1               A query was performed and the query is
                      too complex for the CS. The operation
                      was not performed.

    8.2               Used to signal that an iCalendar object has
                      exceeded the server's size limit

    8.3               A DATETIME value was too far in the future
                      represented on this Calendar.

    8.4               A DATETIME value was too far in the past
                      to be represented on this Calendar.

    8.5               An attempt was made to create a new
                      object but the unique UID specified is
                      already in use.

    9.0               An unrecognized command was received.
                      Or an unsupported command was received.

    10.4              The operation has not been performed
                      because it would cause the resources
                      (memory, disk, CPU, etc) to exceed the
                      allocated quota.

This adds 6, count 'em 6, new top level classes above and beyond the 4 
defined in RFC 2445:

     |==============+===============================================|
     | Short Return | Longer Return Status Description              |
     | Status Code  |                                               |
     |==============+===============================================|
     |    1.xx      | Preliminary success. This class of status     |
     |              | of status code indicates that the request has |
     |              | request has been initially processed but that |
     |              | completion is pending.                        |
     |==============+===============================================|
     |    2.xx      | Successful. This class of status code         |
     |              | indicates that the request was completed      |
     |              | successfuly. However, the exact status code   |
     |              | can indicate that a fallback has been taken.  |
     |==============+===============================================|
     |    3.xx      | Client Error. This class of status code       |
     |              | indicates that the request was not successful.|
     |              | The error is the result of either a syntax or |
     |              | a semantic error in the client formatted      |
     |              | request. Request should not be retried until  |
     |              | the condition in the request is corrected.    |
     |==============+===============================================|
     |    4.xx      | Scheduling Error. This class of status code   |
     |              | indicates that the request was not successful.|
     |              | Some sort of error occurred within the        |
     |              | calendaring and scheduling service, not       |
     |              | directly related to the request itself.       |
     |==============+===============================================|

Nowhere can I find a description of these new top level classes and what 
they mean. (What the hell is a class 9x. response code good food for and 
how does it compare with a class 10.x or 8.x???). 

I have previously noted that there is NO 5.x description or class but that 
has somehow been overlooked.  I have also noted that we have a 10.4 but no 
10.0, 10.1, 10.2 or 10.3.  Basically we need to take a cleanup pass over 
the new status codes to make sure we organzie them properly and cleanly.

We should clearly define these new top level classes (ala RFC 2445) and 
possibly consolidate them down so we have a deeper response tree than a 
flatter one.  After all that is why we defined the value to be 
hierarchical in the first place in iCalendar.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 13 Mar 2003 15:49:20 -0700

[email-masked] wrote:
> Another issue from WAAAY back was the proliferation of top level 
> Response Codes in CAP.  From Section 10.11. Response Codes:
> ...

So if you take the REQUEST-STATUS e-mail that I sent one or two
weeks ago and add that into cap - does that solve *this* issue?

It was a proposal on how to merge/fix/update the REQUEST-STATUS
codes. I do not recall that you responded. I got NO negative feedback
and some positive feedback. So I assume the rest of the WG felt
it addressed those issues?

-- 

  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: Doug Royer <[email-masked]>
Date: Thu, 13 Mar 2003 15:52:35 -0700

> _let alone_ discussed at all in the WG.  It is still "TBD" in the latest 

It has been discussed. Did you object to the conclusions? One to Many
or One to One replies? The issues were somewhat hot and you did
participate.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 13 Mar 2003 16:03:32 -0700

[email-masked] wrote:

> the disction is, what benefit 'marked for deletion" is and if it 
> possible to undelete, etc.

  CAP REQUIREMENTS:

    CAP MUST allow synchronization, meaning at a minimum that the CUA is
    able to find and retrieve new, modified or deleted entries for a
    given time period. The CUA MUST be able to find out which entries
    ...

The discussion that followed ...
You have to be able to tag the entries as deleted, so that a later
synchronization did not think they were new to the CS.

  CAP:

    When synchronizing with multiple CUAs, the marked for delete state
    could be used to inform the synchronization process that an object is
    to be deleted.  How synchronization is done is not specified in this
    memo.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 13 Mar 2003 16:07:28 -0700

> with how multipart MIME should be properly dealt with in CAP.  I had 
> hoped we would have learned from iTIP interop testing but so far no...

Could you please post what your know from the interop testing about
MIME support in iTIP?

I thought we agreed to not limit CAP to specific implementations.
So - all MIME multiplart (as specified in the CAPABILITY reply)
may be sent.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 13 Mar 2003 16:09:22 -0700

[email-masked] wrote:

> different implementations, CAP is how a CUA accesses a store so it 
> SHOULD preserve everything.  This is NOT clearly defined and proscribed 
> for any CS.

Good point. Are there any objects to saying that CAP MUST store
ALL components, properties, and parameters sent to it by the CUA
subject to VCAR rules?

--

---

From: John Stracke <[email-masked]>
Date: Fri, 14 Mar 2003 08:25:20 -0500

Doug Royer wrote:

> Are there any objects to saying that CAP MUST store

I just posted in favor; but then I thought of a clarification: we need 
to permit the CS to ban components for administrative reasons.  For 
example, it seems likely that someone will write a CUA that's equipped 
to spread viruses; once that happens, people will need to be able to 
build CSes that do virus filtering--and that's not something that can be 
expressed in a reasonable VCAR syntax.  ;-)

-- 
/=============================================================\
|John Stracke      [email-masked]                      |
|Principal Engineer|http://www.centive.com                    |
|Centive           |My opinions are my own.                   |
|=============================================================|
|The cheapest, fastest, most reliable components of a computer|
|system are those that aren't there.--Gordon Bell             |
\=============================================================/

---

From: John Stracke <[email-masked]>
Date: Fri, 14 Mar 2003 08:21:24 -0500

Doug Royer wrote:

>> CAP is how a CUA accesses a store so it SHOULD preserve everything.
>

Sounds good to me.

---

From: [email-masked]
Date: Fri, 14 Mar 2003 10:42:52 -0500

> or One to One replies? The issues were somewhat hot and you did

No it has not!  When I mentioned this months ago the response I got was 
"Later, we want to get the rest of CAP done first.". 

If it was discussed then under what heading and where is the prose?

Bruce

---

From: [email-masked]
Date: Fri, 14 Mar 2003 11:00:35 -0500

> weeks ago and add that into cap - does that solve *this* issue?

We were more focused on the issue of ordering responses in CREATE. Falling 
thru the cracks is a very good reason why we need to recheck and reupdate 
the issues list BEFORE we can go to Last Call dont you think?

I found your posting dated 02/22/2003 06:33:16 PM MST under 
"REQUEST-STATUS errors and issues for CAP" and I would have to say no, it 
does not solve the issue.  Here's why:

RFC 2445 does not define a top level 5 class of error but we somehow 
put/left them in RFC 2446.  This is a known issue with 2446 from, oh, 
about 2 or 3 years ago.  This should be fixed when we post errata or an 
update to 2445.  Neither 2446 NOR your posting has any prose on what a top 
level 5.x error code is.  Nothing close to the cited table from 2445 that 
clearly defines them. 

Nor does CAP have anything like it.  Nor does your message address the 
addition of 6 new top level classes in CAP without defining them either! 
Nor does your note address CAPs proliferation of so many near top level 
response codes.

So I guess that would be a definite, No your note does NOT solve _*this*_ 
issue.  If it does, could you point out what I missed so I can reconsider?

> it addressed those issues?

We were more involved with the ongoing discussion of ordering of results 
and CREATE and the UTF-8 issues in case you hadn't noticed.  I did not 
respond as it fell out of the active view of things.  In looking now I see 
no negative OR postitive responses.  When issues get squeezed out by more 
active and drawn out threads then silence is not always acceptance; it can 
be just a forgotten posting.

Bruce

---

From: [email-masked]
Date: Fri, 14 Mar 2003 12:09:52 -0500

> or One to One replies? The issues were somewhat hot and you did

Sorry, the discussion of 1-to-many or 1-to-1 is NOT the sole consideration 
for 12.1 BEEP Profile Registration. 

There is simply NO prose in that section and there has been none given 
since we adopted BEEP last year!  How can we have Last Call on NO PROSE? 
We could NOT have had ANY "hot" WG discussion on NO PROSE, at least not in 
this universe.

Bruce

---

From: [email-masked]
Date: Fri, 14 Mar 2003 12:35:14 -0500

> synchronization did not think they were new to the CS.

I am NOT talking about sync related issues.  Im talking about the overall 
CAP design and how deletions are dealt with in a consistant manner by ALL 
implementations..

Ive mentioned this distintion at least 2 times before and I guess its 
still not clear to some so thats probably a bad sign. 

There is NO prose anywhere describing all kinds of questions around 
deletions such as:

1: The ability to 'unDELETE' entries "marked for deletion".  Is this 
possible / allowed?  (This ability is essentially 'soft deletes' for those 
that recall that topic.)
1.1: Do I actually delete a 'marked for deletion' (MFD) entry from the CS 
by reissuing a DELETE with no MARK parameter or is there some other way to 
actually remove it?
1.2: Does changing the state of the MDF entry effectively undelete it 
(assuming thats possible in CAP)?
1.3: Can an MFD entry be modified in any way (using the right SELECT, 
etc)?

2: Must a CS support marking for deletion (and thus soft deletions) or can 
it just do actual deletions? 
2.1: If a CS does not support marking for deletion then should it treat 
the MARK parameter as optional OR should it fail the DELETE?

3: Is MFD a required feature of a CS or can it just support DELETE but no 
MARK paramter?
3: If soft deletions are NOT mandatory we need some clear prose to 
describe how implementations that do not support it should respond to soft 
delete requests.

4: What are the effects of actually deleting an entry and not just MARKing 
it for deletion? 
4.1: Can a CUA just do this arbitrarily or SHOULD a CUA use MARK all the 
time?
4.2: What is the proper CUA & CS behaviour for dealing with responses to 
either an MFD or actually deleted (irregardless if the CS knows it was 
deleted or if it never existed yet!) entry?
4.3: Should we use DELETE to mean "mark for later deletion" and a _new_ 
(and yet undefined) command like PURGE or EXPUNGE to actually remove 
marked entries?

5: If we cannot unDELETE an entry then why should the CUA distinguish 
between actually deleting it (no MARK parameter) and marking it?  As far 
as the CUA is concerned the entry is gone.  As far as sync goes a sync 
engine just cares if the state is DELETED or not.

6: When does an MFD entry actually get removed from the system?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 14 Mar 2003 10:48:13 -0700

> update to 2445.  Neither 2446 NOR your posting has any prose on what a 
> top level 5.x error code is.  Nothing close to the cited table from 2445 
> that clearly defines them.  

I am confused - part of my proposal was to renumber the error codes:

	I also propose that we call all 6.x codes CMD or CS codes
	and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to
	be 6.x codes.

  	We may also want to renumber some of these that are not
	used prior to CAP anyway.

So I agree. And please note that I proposed deleting the 5.x codes.
I also think we should/could re-map them into a 'command set' of
errors that are CAP specific.

>  Nor does your note address CAPs proliferation of so many near top level 

They were defined, example:

And I do not care if it is y.z or 9.x.

> So I guess that would be a definite, No your note does NOT solve 
> _*this*_ issue.  If it does, could you point out what I missed so I can 
> reconsider?
> 
> respond as it fell out of the active view of things.  In looking now I 
> see no negative OR postitive responses.  When issues get squeezed out by 
> more active and drawn out threads then silence is not always acceptance; 
> it can be just a forgotten posting.

Thanks Pat for calling for Last Call so Bruce would read and
respond to the e-mail :-)

--

---

From: [email-masked]
Date: Fri, 14 Mar 2003 14:03:54 -0500

> Could you please post what your know from the interop testing about

I know that Outlook does NOT support any kind of multipart MIME types in 
its CUA but its MUA is multipart savy.  As such I had to perform some 
funky MIME bundling to send a richer rendering of iCalendar OR to use 
ATTACHments (which they totally ignore). 

More details can be found in the published interop results (I assume they 
are somewhere to be found on the WG site or in the WG list archives).

Essentially because iMIP did NOT include any prose on multipart MIME 
support or any multipart MIME exmaples, some vendors chose to _only_ 
support text/calendar and thus make interop testing hard/kludgy!

> So - all MIME multiplart (as specified in the CAPABILITY reply)

Thats NOT the same as having actual text around how multipart would be 
structured or even an actual multipart example (I know we all hate to put 
them into prose as they become gospel but thats only because we fail to 
provide prose describing exactly how they should be handled/returned).

For example, having some prose around how the CS would construct and 
return a VEVENT with an ALTREP for the DESCRIPTION or an ATTACHment or 
even both.   As a combined example, a CUA would send the following to 
create a VEVENT on the CUs calendar (prefix all lines below with "C: " to 
be consistant w/CAP):

Content-Type: multipart/related; boundary=example-1

--example-1
Content-Type: text/calendar; charset=UTF-8

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Hand Hack Corp//NONSGML NotePad 6.0//EN
CMD;ID=creation01:CREATE
TARGET:Bruces_RedCross_Calendar
BEGIN:VTIMEZONE
TZID:Eastern
BEGIN:STANDARD
DTSTART:19501029T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19500402T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID="Eastern":20030407T190000
DTEND;TZID="Eastern":20030407T210000
TRANSP:OPAQUE
RDATE;VALUE=PERIOD:20030407T230000Z/20030408T010000Z,
 20030505T230000Z/20030506T010000Z,
 20030602T230000Z/20030603T010000Z,
 20030707T230000Z/20030708T010000Z,
 20030804T230000Z/20030805T010000Z,
 20030901T230000Z/20030902T010000Z,
 20031006T230000Z/20031007T010000Z
DTSTAMP:20030306T165203Z
CLASS:PUBLIC
DESCRIPTION;ALTREP="CID:<[email-masked]>":Regular FAS 
 Committee Meeting on the 1st Monday of every month without fail.\n\nYou 
 can drag/drop this onto your Outlook (NOT Outlook Express though sorry!)
 Calendar and it will appear there as a normal meeting.  If you have 
 other products like Lotus Notes it should appear there magically already.
SUMMARY:Monthly FAS Committee Meeting
LOCATION:Waltham Area Office
ORGANIZER;CN="Bruce Kahn":mailto:[email-masked]
UID:7B13A53223F7104C85256CE1005B90CD-Lotus_Notes_Generated
ATTACH;FMTTYPE=application/zip:CID:<[email-masked]>
END:VEVENT
END:VCALENDAR
--example-1
Content-Type: Application/zip
Content-Description: The zipped Agenda
Content-Transfer-Encoding: base64
Content-Id: <[email-masked]>

T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
NrIHF1YWNrCkUgSSBFIEkgTwo=
--example-1
Content-Type: text/html
Content-Id: <[email-masked]>

<html><body>
<p><b>Regular FAS Committee Meeting</b> on the <b>1st</b> Monday of every 
month without 
fail.\n\nYou can drag/drop this onto your Outlook (<B><I>NOT</I></B> 
Outlook Express though sorry!)
Calendar and it will appear there as a normal meeting.  If you have other 
products like <B>Lotus Notes</B> 
it should appear there magically already.<img 
src=http://www.host.com/images/smiley.gif>
</p>
</body></html>
--example-1--

A more complex example could be to replace the last MIME parth with one 
that was of Content-Type: multipart/related and that contained the both 
the text/html AND the image/gif that the HTML refers to!

An alternate way to construct the workflow so that non-CUAs at least 
RENDER it properly is to construct the entry so that the text/calendar is 
part of a multipart/alternative like:

Content-Type: multipart/alternative; boundary=------_alternative_1

        ------_=_alternative_1
        Content-Transfer-Encoding: 7bit
        Content-Type: text/plain; charset="us-ascii"

            Summary: Monthly FAS Committee Meeting
              Start: Mon, 04 Mar 2003 07:00 PM
                End: Mon, 03 Mar 2003 09:00 PM
            Repeats: Every 1st Monday of the month thru October
           Location: Waltham Area Office
        Description: Regular FAS...

        ------_=_alternative_1
        Content-Transfer-Encoding: 7bit
        Content-Type: text/html; charset="us-ascii"

        <pre>
            Summary: Monthly FAS Committee Meeting
              Start: Mon, 04 Mar 2003 07:00 PM
                End: Mon, 03 Mar 2003 09:00 PM
            Repeats: Every 1st Monday of the month thru October
           Location: Waltham Area Office
        Description: Regular FAS...
        </pre>
        ------_=_alternative_1
        Content-Type: text/calendar; charset=UTF-8
 
        BEGIN:VCALENDAR
        VERSION:2.0
        PRODID:-//Hand Hack Corp//NONSGML NotePad 6.0//EN
        CMD;ID=creation01:CREATE
        TARGET:Bruces_RedCross_Calendar
        ...
        ------_=_alternative_1--

This latter snippet is really geared towards Scheduling messages rather 
than Calendaring ones but it is still legal and valid to do in both cases.

One unanswered question is how the CUA can tell the CS it only wants the 
text/calendar version / body part  when is uses "SELECT *  FROM VEVENT 
WHERE UID = "7B13A53223F7104C85256CE1005B90CD-Lotus_Notes_Generated"". Or 
will the CUA just get back the text/calendar bits and never see the 
text/html again?  I never found a way to tell the CS "yes send me the 
ALTREPs on DESCRIPTION" or "No, I want just the DESCRIPTION in 7-bit form 
and NO ALTREP this time."

<DIGRESSION>
Also, is there some way for the CUA to say SELECT all properties EXCEPT, 
say, the ATTACHments so that the CUA does not have to itterate over ALL 
possible properties in the SELECT clause and possibly miss or overlook 
some (ie: some extension or other iana-prop)??
</DIGRESSION>

Bruce

---

From: [email-masked]
Date: Fri, 14 Mar 2003 14:12:41 -0500

John wrote on 03/14/2003 08:25:20 AM:
> to permit the CS to ban components for administrative reasons. 

That would probably fall under the "subject to VCAR rules" clause Doug 
suggested.

I for one am in favor of Dougs proposal.

>                                       people will need to be able to 

> expressed in a reasonable VCAR syntax.  ;-)

Since when does someone call our VCAR syntax reasonable?  Actually, its 
quite powerful and could easily be used to prevent someone saving 
ATTACHments or other properties and there is nothing preventing a CS from 
rejecting a CREATE or MODIFY command because the contents of the payload 
were infected.  Thats a good reason use for the new 5.x error class 
("Server Error", ie 5.13.2.9: "Command failed due to administrative 
restriction.")

Or perhaps you are proposing we amend the clause to be "subject to VCARs 
or administrative policies"?

Bruce

---

From: John Stracke <[email-masked]>
Date: Fri, 14 Mar 2003 14:42:17 -0500

[email-masked] wrote:

> Since when does someone call our VCAR syntax reasonable?  Actually, 
> its quite powerful and could easily be used to prevent someone saving 
> ATTACHments or other properties

Can it check for a virus signature?

> Or perhaps you are proposing we amend the clause to be "subject to 
> VCARs or administrative policies"?

Yes, that's all.

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|This is not a self-referential .signature.|
\==========================================/

---

From: Doug Royer <[email-masked]>
Date: Fri, 14 Mar 2003 12:56:25 -0700

[email-masked] wrote:

> possible / allowed?  (This ability is essentially 'soft deletes' for 
> those that recall that topic.)

In CAP Requirements:

       4.3.1   Deferred Requirements for Operations on a Calendar
	...
    	- How to undelete a calendar.

       4.4.3   Deferred Requirements for Component Management
	...
  	- Undelete and purge deleted calendar entries.

       4.5.5   Deferred Requirements for Search
	...
         - How to fetch all components marked for deletion in a certain
           range. This could include components somehow marked for deletion
           but not yet purged from the CS.

So - out of scope?

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 14 Mar 2003 13:06:10 -0700

[email-masked] wrote:
> ...lots of feedback...

Would you be willing to write a draft on how to use Multipart
with iCalendar - perhaps a FYI? It is more than a CAP issue.

I *think* the WG would endorse it!?

Then we do not have to decide for CAP, just decide that we will
support multipart. Right now as you point out that knowledge
is not written down. This would help the those implementing
and help CAP ship sooner.

--

---

From: [email-masked]
Date: Fri, 14 Mar 2003 15:24:46 -0500

> I am confused - part of my proposal was to renumber the error codes:

Sorry, I dont see any such proposal in your "REQUEST-STATUS errors and 
issues for CAP" posting 
(http://www.imc.org/ietf-calendar/mail-archive/msg05916.html).  Did I just 
miss it?

> errors that are CAP specific.

I dont think we need to delete 5.x codes, we merely need to clearly define 
their class ala RFC 2445 did for 1.x thru 4.x.  Then we could start using 
it.  We may want to make 5.x for "Server Errors" akin to the 3.xx class. 
You may want to collapse the 6.x thru 10.x codes down into 4.x since that 
is already defined in 2445 as for "Scheduling Error".

(After all why have 1.x thru 4.x and then 6.x but NO 5.x??)

>                            Or an unsupported command was received.

This defines the code for 9.0, not the overall 9.x class.  An unrecognized 
command can be classified as a server error OR a client error (esp. if the 
client can tell what the server supports).  An unsupported command sounds 
like a 3.14 case ("Unsupported capability") and thats already defined in 
iTIP.

The same goes for the rest of the 6.x thru 10.x cases; they are defined as 
explcit values (ala iTIP) but not as an overall class (ala iCalendar).  I 
think if we consolidate them down and clearly define the 5.x (and 6.x?) 
cases then we can properly reassign them and consolidate accordingly.  In 
any case it needs to be done before Last Call.

> respond to the e-mail :-)

This was not a Last Call call, it was a query to see if we should go to 
Last Call.  Dont put the RFC before the draft...

For the longest time your server was sending out CAP issues list postings. 
 Have you gone over that to make sure all are resolved in the latest 
draft??

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 14 Mar 2003 15:16:55 -0700

[email-masked] wrote:
>  > I am confused - part of my proposal was to renumber the error codes:   >-+
>                                                                             |
> Sorry, I dont see any such proposal in your "REQUEST-STATUS errors and      |
> issues for CAP" posting                                                     |
> (http://www.imc.org/ietf-calendar/mail-archive/msg05916.html).  Did I       |
> just miss it?                                                               |
>                                                                             |
>  >    I also propose that we call all 6.x codes CMD or CS codes             |
>  >    and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to                |
>  >    be 6.x codes.                                                         |
>  >                                                                          |
>  >      We may also want to renumber some of these that are not <-----------+

The above text is from my post.

> I dont think we need to delete 5.x codes, we merely need to clearly 
> define their class ala RFC 2445 did for 1.x thru 4.x.  Then we could 
> start using it.  We may want to make 5.x for "Server Errors" akin to the 
> 3.xx class.  You may want to collapse the 6.x thru 10.x codes down into 
> 4.x since that is already defined in 2445 as for "Scheduling Error".
> 

Yea - I do not care what the numbers are.

> For the longest time your server was sending out CAP issues list 
> postings.  Have you gone over that to make sure all are resolved in the 
> latest draft??

I was asked to stop sending it. Perhaps because it was getting old. I
will happily start sending it again.

--

---

From: [email-masked]
Date: Mon, 17 Mar 2003 11:25:39 -0500

> > those that recall that topic.)

I cant find my expired copy of this nor is it on the WG web site.  Ill 
assume the cited blocks are accurate unless someone w/a copy can say 
otherwise.

>            but not yet purged from the CS.

Not entirely.

4.4.3 does not cover the questions like "If my AA DELETEs a VEVENT and 
then I come in and try to modify it, what happens?"  Nor does it address 
all of my posted questions.  Those still uncovered are:

(4.3 is semi answered but not entirely.)

CAP currently has some prose that says how to do exactly what 4.5.5 says 
is NOT covered:

1.3.  Definitions
BOOKED - 
        An object in the calendar store has one of three conceptual 
states. It is in the "UNPROCESSED" state, "BOOKED" state, or marked for 
deletion which is the "DELETED" state. How the implementation stores the 
state of any object is not a protocol issues and is not discussed. An 
object can be said to be booked, unprocessed, or marked for delete. 
[Snip, snip]
        3.      A "DELETED" state entry is created by sending a "DELETE" 
command with the "OPTION" parameter value set to "MARK". To retrieve any 
deleted object, simply do a query asking for any objects that were stored 
in the "DELETED" state. 

and

6.1.1.5.  STATE()
        Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" 
depending on the state of the object. Used in a CAL-QUERY "WHERE" clause. 
Where "DELETED" is a component in the marked for delete state. Components 
that have been removed from the store are never returned. 

so #3 and 6.1.1.5 do what 4.5.5 says is not covered.  Guess we need to 
remove it from CAP then (or revise the requirements??)

CAP Requirements are NOT going to RFC so any "Items we are not covering in 
CAP 1.0" should become some part of the CAP RFC so that readers will 
understand why there are apparent holes in the design or unanswered 
questions.  To some extent we have this with lines like:

How synchronization is done is not specified in this memo. 

Perhaps we should fold in the CAP requirements bits on what is "out of 
scope" in to some section so that we set reader expectations accordingly.

Bruce

---

From: [email-masked]
Date: Mon, 17 Mar 2003 11:30:38 -0500

> with iCalendar - perhaps a FYI? It is more than a CAP issue.

If I had more time I would but as it stands now my available WG time is 
dwindling as others start to take the load from me. 

Its definitely NOT just a CAP issue but Id like to make sure that CAP is 
very clear on the issue/usage given the interop issues from iTIP alone.  I 
would dearly love to make sure CAP fixes that oversight before it goes to 
Last Call.

> support multipart. 

PLEASE include at least 1 (preferably a few more) examples using multipart 
so that CAP readers will have something to get their heads around as they 
implement it (correctly).  Even if it is NOT mine, something rich... 
Please!!

>                      Right now as you point out that knowledge

Much of it should be in the CalConnect I - III notes somewhere.  I know it 
was in the notes we sent to Pat/Bob at least once...

Bruce

---

From: [email-masked]
Date: Mon, 17 Mar 2003 11:34:43 -0500

> The above text is from my post.

Not in the posting I saw.  Instead of including it inline Ill just send 
the archive URL: 
http://www.imc.org/ietf-calendar/mail-archive/msg05916.html

I see no such copy of that prose in that message.  Am I going blind?

> will happily start sending it again.

It may be a bit old but it still has issues that need to be resolved (or 
marked as resolved) before we can go to Last Call.  After all the intent 
was to make sure we dont overlook any issues, yes?  Maybe we just dont 
need it automated every week...

Im sure that some issues are not on it as the list has not been updated 
publically since 2001 but we should fix that too...

Bruce