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

From: [email-masked]
Date: Mon, 5 Nov 2001 11:10:07 -0500

John Stracke wrote on 11/02/2001 01:02:34 PM:
> > 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.

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.

>                                               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.

Ok, given that Notes preceded MIME by ~5 years; how do you think that 
Notes can store its own data AND MIME data w/FULL fidelity?  Its all in 
how you design your storage system.  In my mail file alone I have "Notes 
Mail" and any number of MIME messages with full fidelity.  My calendar has 
> 3000 entries in it going back as far as 1996 and I can access any entry 
w/o any performance problems.  (Im NOT going to to turn this into Notes 
Architecture 101 so dont worry about that.  Im still unrepentant in my 
belief that NOT EVERYONE will build their CS using a relational dB as most 
seem to claim.  If other vendors want to, go for it.  Just dont make the 
implicit assumption that EVERYONE will and therefore stuff like the issues 
I keep raising will just go away.)

Since you brought up the issue of CS storage Ill persist a bit to 
demonstrate my point.  There is NOTHING precluding a Calendar Store from 
storing meta data in addition to the original, untainted data.  In fact 
thats what EVERYONE will have to do if they EVER want to support 
preservation of signatures on MIME data let alone.   No way around it. 
Even if you use the most high end, fanciest dB engine in the world you are 
going to need to build indexes on the data in addition to the actual data 
itself.  Whether you break it down into parts and store it in different 
tables in a relational dB or if you use a different model, you are going 
to have to have indexes/meta data. 

> > 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,

By implicit definition the CS _is_ a database.  However I suspect you are referring to relational dBs over any kind of 
other database format...

> True--which argues for the GENERATEUID approach, which I had conceded in 

> the message you were replying to.

Mea culpa.  Thats now how I understood your response to Alex.  In 
rereading it w/some caffine I think we are on the same page WRT this.

> > Also, if the data is encrypted then the CS 
> 
> ...will not be able to search it.

Unless you provide some of the data in unencrypted form for the CS's 
benefit.  I can easily argue that the CS does NOT need to know the 
DESCRIPTION of a very top secret meeting between Bill Gates and Lou 
Gerstner to discuss IBM buying out Microsoft product lines (FICTIONAL EVENT here to make a point).  It may need to know the DTSTART/DTEND so that 
their CUAs can query for events based on the time frame ("What entries are 
on my calendar for today?").  As such, the proposed CAP change (from 
Washington DC hall talks) to provide some information 'external' to the 
'original' iCalendar data can be a solution.  It does mean that there is 
some data redundency involved but it beats mandating that I have to give 
the decription keys to the CS OR precluding data encryption entirely. 
Nothing so far says that a CS cannot have a policy of rejecting 
signed/encrypted iCalendar w/a message like "Encrypted calendar entries 
are not allowed if they cannot be decrypted by the CS" or some appropriate 
response code/message...

Time to get my AM caffine dosage to wake up properly...

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Mon, 05 Nov 2001 13:49:37 -0700

[email-masked] wrote:
> > The difference is that it's feasible for a server to treat email messages
> 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.

Not for encrypted MIME body parts. That's the point of encrypting them.

> DESCRIPTION of a very top secret meeting between Bill Gates and Lou Gerstner
> to discuss IBM buying out Microsoft product lines (FICTIONAL EVENT here to
> make a point).

Sure, you can hide parts of the object, as long as it is still a valid
object (per the restriction tables).

>It may need to know the DTSTART/DTEND so that their CUAs can
> query for events based on the time frame ("What entries are on my calendar
> for today?").  As such, the proposed CAP change (from Washington DC hall
> talks) to provide some information 'external' to the 'original' iCalendar
> data can be a solution.  It does mean that there is some data redundency
> involved but it beats mandating that I have to give the decription keys to
> the CS OR precluding data encryption entirely.  Nothing so far says that a
> CS cannot have a policy of rejecting signed/encrypted iCalendar w/a message
> like "Encrypted calen! dar entries are not allowed if they cannot be
> decrypted by the CS" or some appropriate response code/message...

Yes there is such a restriction. If the CS can not parse the object,
it is not a valid object. Look at the restriction tables. If the CS
does not know if there is a UID, SUMMARY, DTSTART, ..., then it
is not a valid object. Are you proposing that some of the TEXT 
fields be encrypted and not the entire object? If so that might
make a great additional draft.

Perhaps with a 'encrypted=true' (or whatever) parameter to
properties that ~could~ have their values encrypted?

Again - out of scope for CAP. That may be an add on to iCal as
long as none of the iTIP/CAP needed fields are encrypted.

-Doug