Subject: Re: CAP / Busytime Restart

From: [email-masked]
Date: Fri, 4 Apr 2003 10:20:54 -0500

Hm, I think I agree.  I say this even though I know it opens a can of 
worms.  However, I for one think we need to have a decision on what to do 
with the FreeBusy updates.

[email-masked]
Sent by: [email-masked]
04/03/2003 17:43

        To:     [email-masked]
        cc: 
        Subject:        CAP / Busytime Restart

In trying to take a step back some background checking was in order.  Back 
in CAP-03 we had: 

[Editor's notes: Issues:
freebusy - a cap server should dynamically calculate
freebusy information - we recommend that you cannot create,
modify, or delete freebusy composers ]

and 

9.1.54.    VFREEBUSY schema
 An implementation may not actually have a VFREEBUSY table
as   the
 information may be produced dynamicly. However a CS MUST
appear to
 provide this table as this may be how a CUA chooses to
query     for
 VFREEBUSY information while using [CAP]. 

In CAP-05 another issue was added: 

   [EDITORS NOTE: Issues:
[Snip]
     - We should not be able to delete any VFREEBUSY components?

Somehow all this text was removed from CAP in CAP-06 without any WG 
discussion and I now find: 

   It is important to note that scheduled components do not show up in
  busy time as BUSY.  Only when they are booked does the TRANSP:OPAQUE
  property take effect.  A CS implementation MAY mark the time as
  TENTATIVE. 

This new text implys that the CS does the busytime maintenance and NOT 
anyone else but its not made clear or definitive.   

So sometime between July 2001 and Nov 2001 the Issue got quietly removed 
and we are now left floundering.  Unfortunately the latest CAP-10 Draft 
has loss even more text and the result is the current confusion. 

I think we should reinstate the Editors text as Draft Text and clearly and 
unambiguiously specify _THE_ way that busytime lookups are to be done in 
CAP and then we can go to Last Call! 

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: Fri, 4 Apr 2003 10:42:51 -0500

Here's an old issues list I found on my archive.  It's dated 7/16/2001.  I 
think it might be helpful as we go through CAP to make sure it's ready for 
Last Call.  Also, there is a section here on FREEBUSY (surprise).
---------------------
- A number of issues with the various restriction tables.
  See CAP.

- CS do not preserve data integrity.

  Explanation/example:  someone can store a multipart/signed vEvent on 
their
  own calendar via CAP but when the owner goes to read it back the sig is
  gone (or its been 'resigned' by the CS).  For multipart/encrypted, CS's 
may
  decrypt and later reencrypt data back but it data security/preservation 
is
  not available.  A by-product of this is that when an invite arrives in 
your
  calendar scheduling queue all you will be able to tell is that your 
server
  says the data got there in some safe manner; no info as to the original
  signature, etc.  As such anyone with a valid  signature can send the
  calendar owner  entries and the CAP server will say this was signed and 
CAP
  verified it was".  In eMail you can see the senders signature (somewhere 
in
  the UI); with CAP you have no visual way to see _WHO_ signed it.

  Another way to look at this is: you sign and save an entry.  Your AA or
  someone else w/access to it comes in and modifies it. You later go back 
and
  reopen the entry but you will  have no visual clue as to its been 
changed
  by someone else since _I_ signed and saved it since my CAP server only 
says
  "This was really signed when it was saved".  Is this OK? (from Bruce)

- Security issue - mutual trust model. Is it in the draft?

  CAP implicitly requires some form of mutual trust model.  Is this
  explicitly called out in the draft even though it is implict in the 
design?
  Once something is outside of a firewall it is out of your realm of 
control
  just like email. (from Bruce)

- JIT signing/encryption:

  For some cases we may wind up having signing/encryption done by
  'downstream' CS's as the request routes thru.  ie: Paul @ MIT sent a
  REQUEST to his CS w/your CalID as 1 TARGET.  He sends the data
  unsigned/encrypted to his CS.  It sees your TARGET and by some TBD CS
  policy it decides that the data must be signed/encrypted so that it can 
go
  over, say, iMIP.  His CS does not have his key so it simply uses its 
own.
  (Additionally, if his server fanned it out to outside the firewall 
before
  this happens, the signer/encryptor is not even his CS).  So the first CS
  that can sign it does and then that is trackable all the way to you 
[after
  resigning by each subsequent CS in the flow path is done] (from Bruce)

- "Fallback/fanout to iTIP" concerns:

  If CAP request must get turned into iTIP then some extra coding must 
occur
  (ie: rewriting the proper ATTENDEE and ORGANIZER values from cap://... 
to
  mailto:.. ).  Since this may happen anywhere down stream from the
  originating CS, it is not guaranteed that the mapping/rewrites are 
accurate
  or correct; they are 'assumed' to be usable ("or the request is bounced
  back.").  Unfortunately correctness is only positively done at the 
starting
  point and not @ Yahoo on the way to Lotus. There are also cases like 
signed
  or encrypted data that would prevent this from being either doable or 
run
  the risk of voiding the signature. (from Bruce)

- The workflow path may not be a true path:

  The iTIP workflow path was a just that; a path (msg flow out followed 
same
  logical flow back).  In CAP, if 'rerouting' over iTIP occurs then the 
path
  is now a loop (CUA1->CS1->iTIP to MUA2/CUA2->MUA1/(CUA1?).  The last leg 
of
  getting iTIP/iMIP replies from the MUA1 to CUA1 so it can stuff them 
into
  CS1 in the "proper place" is just handwaved (or "left up to the user or
  their tools to do").   There is no clear why/how CUA1 would stuff in
  iTIP/iMIP messages into own queue instead of having CUA1 watch the 
incoming
  MUA1 queue for iTIP msgs and pulling them in or having CS1 rewrite the
  address so that msgs return to it directly.

  Paul or Doug state that users would only be confused (at best) or not 
aware
  of (at worse) any kind of signature msgs / warnings that they may see on
  their receiving end.  Bruce feels email is stillok in that if my MUA can
  see the sig then it tells me "This msg was signed by Doug Royer and its
  valid".  He does not think there is any usefulness in seeing "This 
request
  was signed and I, your trusted CS says its valid!" (esp. if we allow
  downstream servers to sign 'on your behalf' or 'at your behest' via some
  TBD mechanism).  Is data integrity within the CS necessary? Do we trust 
the
  CS to enforce integrity or not. (from Bruce)

- Look at changes required by CAP to make it compatible with CRISP

- Add changes to iCalendar the are required for CAP

- Do we want/need the CAP server to auto-mangle (aka autoinsert) an
  incoming stream of data with a generated UID?  Especially if > 1
  operation is going to be needed (ie: "Put this on my calendar and
  send invitations to the ATTENDEEs" = 1 CREATE and 1 or more
  other operations).  Wouldn't it be simpler and more efficient to have 
the
  client request a UID and have the CAP server generate and return it (ala
  NNTP does with Message-IDs)?? 

  Besides, the client will _probably_ need to have the UID for other
  operations (like saving in its local store if is does sync work!). 
  (from Bruce)

ToDos:
======

- Review restriction tables.

- Review CAP Requirements doc to make sure that we have met
  all requirements.

- Make sure that CAP supports synch.

- Get CAP related changes into iCalendar

- Resolve issues with the various methods (e.g., how does one
  specify a specific attachment during an update).

- VTIMEZONE and IANA. (Doug's list)

- Remove unused definitions (Doug's list). I assume this means
  that we should remove all definitions that are in the definition
  section, but that are not used in the text.

- Document MAXSIZE and MAXRESULT (Doug's list).

- Document METHOD is stored in CS database (Doug's list).

- Only one 'CREATE' per UID (Doug's list).

- Multiple non-CREATE per UID (Doug's list).

- Fix the RESPONSE's to be consistent and multiple components,
  one for each TARGET (Doug's list).

- Section 2.4.4.2 - editor note: We need an example (Steve/Doug).
  Paul needs to read this note an example. (Doug's list).

- Merge changes Doug made into the doc. Some changes may no longer be
  appropriate (George).

- Section 2.6
  CALID - need to define that relative CALID must be consistent with
  the scheme specific part of URI as defined in RFC xxx. - Steve
  (Doug's list).

- Section 7.1.3
  Need to get IANA registration (Doug's list)

- Section 7.2.1.7
  Add an example of a partial result - we want to get something that
  matches some things, and on the ones you don't have access, you
  don't have rights to some of the components. George will write up
  something. (Doug's list).

- Section 8.0
  Response codes.  Need to make sure response codes in all drafts -
  iCal, iMip and iTip and examples. Error numbers need to be the same. Put
  text about error codes in comments below the examples (so that
  people don't look at them as being required in their text).  Pat
  will look at the codes. (Doug's list).

- Section 11.0
  DTN, DTSTAMP, etc are implementations that may need to be considered.
  Restrictions tables may resolve these issues. (Doug's list).

- Section 12.0 (was section 13)
  This section is not ready for prime time. Need Paul Hill.
  Need an editors note. (Doug's list).

- Section 15.1.4 (now section ?)
   Submit entity for approval - John submitted to list.  Need to find.
   Get John's text and add back into CAP draft.  John submitted as a
   separate draft document. Use the MIME appeal verbage with John's
   additional text. Point WG at John's draft and say it should be
   included in the draft.  We need to also submit to April Marine as
   well. (Doug's list)

- Editor note: Remove references to VDATA (mistake) (Doug's list)

- Editor note:
  GENERATE UID is not a method.  It's wrong in section 7.1.2.3
  Ditto with NOOP - Section 7.2.1.6 (Doug's list)

- Write ABNF for VQUERY. (George)

- There were a few changes made by Doug in an interim document.
  These changes did not make the doc we submitted since we worked
  from another version of the doc. Most of these changes were new
  examples, or small changes to existing text.

- Should we provide some kind of template to follow for all
  the application protocol commands (CREATE,  MODIFY, etc).
  All we have right now is a brief description followed by an
  example. Is there anywhere where the syntax or form that
  should be followed clearly specified?

- Need to register CAP port number. Prefered if number used is a small as 
possible.
  (Admins like to block whole rages of the higher port numbers.) May need 
to
  before CAP is an RFC before we can register it.

- Go through past posts to see if there are any other issues

- review syntax of all examples 

- may need to register the CAP URL (cap://) ??

Examples:
=========

- search
- security
- fanout using iMIP
- basic operations that a user may do during regular use (George)
- the minimum data required to create an entry
- an entire short session from login to download entries,
  to log out.
- errors
- The UIDs in our examples are different than the suggested format in
  iCAL.

From CAP document:
==================

- register "cap" service name for SASL with IANA
- DISCONNECT: should the client now wait for a response from the server 
before disconnecting?
- NOOP: should an unauthenticated and unidentified client be able to issue 
this command?
- NOOP: need to add NOOP in the state diagram?
- GENERATEUID: the example needs work. It's not packaged right.
- VQUERY: if the user does not have access to some, but not all of 
properties that were specified
          should the acessible properties be returned along with an error 
code
- Error codes: missing ones for 6.XXX
- What are the minimum component properties set required to 
  create a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, 
  SUMMARY and UID.
- What is the state of all undefined properties? PROPOSAL: 
  Not defined. So a query will not return them, if they are 
  selected.
- DELETE:
 
  - Currently CAP requires that the server return a response 
    status. However, if there are multiple components deleted, 
    should the UID also be returned?
 
  - VQUERY EXPAND and MAXSIZE parameters do not seem to apply to 
    deletion?
 
  - Can one use DELETE to remove all VALARMs and VTIMEZONEs that 
    match a certain search criteria and that belong to all 
    components, event though VALARMs and VTIMEZONEs never exist as 
    independent components? Or should one use MODIFY? If they can 
    be deleted, do we return the REQUEST-STATUS of their deletion 
    in a VEVENT or separately?
 
  - In the example in CAP where a calendar is deleted all the 
    server returns is 2.0, nothing else?

  - Can we delete multiple calendars?
 
  - Currently one can not delete a VCALENDAR and some other 
    component in the same DELETE command. This seems OK. Anyone 
    see any need to be able to do this?
 
  - Should the MAXRESULTS property of VQUERY apply to deletion? 
    We can use it to delete only the first n components that 
    match.

- FREEBUSY: a cap server should dynamically calculate freebusy 
  information we recommend that you cannot create, modify, or 
  delete  freebusy composers

- MOVE:
     1) Should one be able to move a calendar owned by person X 
    into a calendar owned by person Y. (Can these such rights be 
    specified in VCARs?)
     2) Should we also be able to move components from one 
    calendar to another? What if the calendars are owned by 
    different users? (With components one can do a copy, then 
    delete the original.)
     3) There was very little information about MOVE in CAP. Why 
    was it added? Was there some major need for it?
     4) Can one move multiple calendars into one calendar?

- MODIFY: how does one modify an attachment?

[email-masked]
Sent by: [email-masked]
04/04/2003 10:27

        To:     John Stracke <[email-masked]>
        cc:     [email-masked], [email-masked]
        Subject:        Re: CAP / Busytime Restart

John, I archived "most" of the IETF emails.  I just set the file to go 
create and index and I'll search it to see what I can find.  However, I 
think what happened is when the new editors took over working on the draft 

- they may have removed all the "Editors Comments" and not realized that 
nothing was in the text to resolve the issues.  I know they were focused 
on getting transport stuff out and using BEEP.  that's around the 06 
timeframe
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

John Stracke <[email-masked]>
Sent by: [email-masked]
04/04/2003 08:22

        To:     [email-masked]
        cc: 
        Subject:        Re: CAP / Busytime Restart

> discussion and I now find: 

[...]

> I think we should reinstate the Editors text as Draft Text and clearly 
> and unambiguiously specify _THE_ way that busytime lookups are to be 
> done in CAP and then we can go to Last Call! 

I agree--unless someone can find evidence that WG discussion occurred 
after all.  (No slam on Bruce here; the mailing list archive isn't that 
easy to search.  Someone who remembers the discussion, if there was one, 
or whoever removed the text, might know better what to search for.)

-- 
/============================================================\
|John Stracke      [email-masked]                     |
|Principal Engineer|http://www.centive.com                   |
|Centive           |My opinions are my own.                  |
|============================================================|
|"God does not play games with His loyal servants." "Whoo-ee,|
|where have you *been*?" --_Good Omens_                      |
\============================================================/

---

From: [email-masked]
Date: Fri, 4 Apr 2003 10:47:08 -0500

Bruce/John, my archives show a couple of discussions about FreeBusy.  One 
set occurred in the May/June 2002 timeframe and then in the July/August 
2001 timeframe and at the Pittsburg meeting.  You can find the discussion 
on the minutes for that meeting.  Here's a snippet of one of the July 2001 
discussions:

"Shannon J. Clark" wrote:
> 
> Well a few points about doing it all client-side OR via an outside 
scheduler
> (like cron).
> 
> 1. - this does not resolve how my SERVER should handle incoming events 
in
> the future - i.e. say I expand a "forever" event for the next 100 
instances
> (or any other arbitrary number) - if my FREEBUSY status is queried 
(which is
> a feature CS can and should - but not must - support) for a time past 
that
> arbitrary number then my server will return incorrect information.
> Admittedly this probably is far in the future - and may get corrected 
after
> my rule is expanded - but it changes the order of things in a strange 
(and
> probably confusing to an end user) manner.

If your server supports this extended functionality, that's a good server!

> 2. - many CUA's will NOT have access to tools like cron - sure unix 
clients
> have cron access easily - but such tools are confusing even for
> sophisticated users - and do not help CUA cases for mobile devices,
> notebooks, etc.

Tools like cron are very simple to write.  My wristwatch has a tool like
cron: I
can program it to beep at a specified time in the future.

> Furthermore - if the client application is responsible for
> expanding events - and then entering them into a calendar store - there
> still is a requirement for a method of DEFINING how to expand events - 
the
> purpose of a set of RRULES is to define a set of ALGORITHMS that can
> generate a set of future events - thus avoiding the requirement that a 
HUMAN
> "figure it out"

The problem is interoperabioty, and complete specification of corner 
cases.
By delegating solving that problem explicitly outside the scope of the
standard, the interoperability problem goes away. Recurring language is
reclassified to MAY status, and a way to specify which dialect you are
speaking is provided.  The world might wind up with only one dialect,
but it might wind up with many: by delegating the detail the standard
can support any possibility.

> Even simple cases if required to be entered by hand
> [...] shifting from RRULES on the server - to RRULES on the
> client feels like a step backwards.

Shifting functionality from the server to the client does not
mean entering by hand.  The client will still be a complex piece
of software.  Allowing variety in the client means more rocust
competition, to argue from a free-market perspective.

> (note on above, in the systems my company is designing we are indeed 
looking
> carefully at this issue - but still plan on having server side knowledge 
of
> the RRULES - even if we do some expansion of them in advance and cache 
it
> for performance)
> Shannon

I'll stand by what I recall my reccomendation here was, which, with
very slight improvement, was:

CS MUST accept multiple dates/times/locations for same event
CS MUST list what RRULES languages it knows in its CAPABILITY responses
CS SHOULD accept a minimal standard RRULES language which is fully defined
CS MAY accept an extended RRULES language, which the definition of
                 which is beyond the scope of this document.

04/04/2003 10:01

John wrote on 04/04/2003 08:22:30 AM:
> easy to search. 

None taken.  I have a personal archive of nearly all WG traffic going back 
to BOF days at Netscape.  Im sure I missed one or two msgs here or there 
over 6+ years but its virtually complete (AND its fully threaded!).   

Unfortunately I no longer have the ability to host that outside the 
Intranet (IBM security policy) so Ive given it to Pat.  Perhaps she can 
host it and the FT index so that anyone else can search as they like.   

If anyone out there has a Notes server and has ~190M of free disk Ill be 
happy to FTP it to ya... 

Bruce