Subject: Re: CAP: why do we need GENERATEUID?

From: "John Stracke" <[email-masked]>
Date: Thu, 1 Nov 2001 17:36:53 -0500

> Well then you will never be able to use it with signed or encrypted data 
in the store unless you gave the store the 
> your private keys so it can decrypt/reencrypt or resign the data as you.

I believe we've been over this before (for example, in San Diego): you are 
the only one who believes that the server will store the iCalendar objects 
as opaque MIME blobs, which could be signed by the sender.  The rest of us 
expect the data to be stored in a relational database.  The disconnect 
reflects our respective implementation experience: Notes is a MIME store, 
for flexibility; most other apps are built on databases, for performance.

In any case, signing seems to have nothing to do with GENERATEUID; as far 
as I can see, where the UIDs come from does not impact signing the 
iCalendar objects.

John Stracke
Principal Engineer
Incentive Systems, Inc.
[email-masked]

---

From: "John Stracke" <[email-masked]>
Date: Fri, 2 Nov 2001 13:02:34 -0500

> Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out 
the 'mail file'/'message store', we are doing the same in CAP. 

The difference is that it's feasible for a server to treat email messages 
as opaque blobs with a bit of machine-readable data.  An iCalendar object 
consists almost entirely of machine-readable data; the server needs to 
understand the semantics of that data, and store it in a way it can search 
quickly.

> You can pick your own back end store but not all implementors (Lotus / 
IBM, Open Source projects, etc) will be using someone elses backend store
> for the data for assorted reasons (ie: $$$, flexibility, ROI, etc).

Sure.  It's all tradeoffs.  Personally, I think the database approach is 
best, because it's cheaper (use postgresql if you think you can't afford a 
commercial DB); you lose some flexibility, but you can work around that. I 
don't think there's anyway to work around the performance problems of an 
opaque-blob store, though.  eCal built a server, based on an Oracle 
backend, that could handle one million users at less than $1 apiece in 
hardware costs; I don't believe a non-relational approach can come close 
to that.

(Granted, eCal subsequently went bankrupt; but the *technology* was sound. 
 :-)

> Ok, Ill try to be as concise as I can w/o caffine yet.  If the CS 
automagically updates the entry that the CUA just put into the store (ie: 
to put a UID on the entry for
> the CUA) then it will blow any signatures on the entry.

True--which argues for the GENERATEUID approach, which I had conceded in 
the message you were replying to.

> Also, if the data is encrypted then the CS 

...will not be able to search it.

John Stracke
Principal Engineer
Incentive Systems, Inc.

---

From: "John Stracke" <[email-masked]>
Date: Mon, 5 Nov 2001 11:34:43 -0500

Bruce Kahn wrote:

> John Stracke wrote on 11/02/2001 01:02:34 PM:
> > as opaque blobs with a bit of machine-readable data. 
>
> Not true of IMAP.  The IMAP server must be able to understand the 
structure of the entire MIME stream so that it can deal with IMAP clients 
that
> want to query the messages structure, etc.  They can also care about the 
contents in some cases such as statistics generation, attachment
> scanning (for virsues, confidentail info, etc) and other assorted 
'administrative' tasks. 

...none of which are possible on encrypted messages.  If you have an 
encrypted message, your IMAP server can tell you so, but it can't do any 
analysis for you.  Same for a CS--the difference being that analysis is 
the CS's *primary* function.

> Unless you provide some of the data in unencrypted form for the CS's 
benefit.

Mrphl.  I suppose you could do that...perhaps with a 
multipart/alternative, where the first alternative is the unencrypted 
text/calendar, with sensitive fields masked out, and the second is the 
encrypted version, which is complete.  Makes me kind of nervous, though; I 
don't like the idea that my calendar may wind up showing me inconsistent 
views.  If I've got a meeting where the SUMMARY is encrypted and the 
DTSTART/DTEND is not, then it'll show up on my monthly view; but, if I do 
a search by summary, I won't find it.  Bad usability.  No biscuit.

And interop remains the sticking point, since it's likely only Notes would 
be able to handle it.

John Stracke
Principal Engineer
Incentive Systems, Inc.