Subject: Re: MIME encapsulation of multipart responses

From: [email-masked]
Date: Tue, 10 Sep 2002 11:14:23 -0400

John wrote:
> > In this case we are trying to represent the VAGENDA by lots of smaller 

> > blobs of data.
> 
> I'm not sure that's true.  We're trying to represent the answer to a 
> query such as "what objects are in the VAGENDA?".  That answer is not 
> the VAGENDA itself.

"Represent the VAGENDA by lots of smaller blobs of data" = "Represent the 
answer to the query such as 'what objects are in the VAGENDA?''  My phrase 
"represent the VAGENDA" was meant to be the same as your "What object are 
in the VAGENDA", I just didnt phrase it that way.  There are multiple 
objects in the VAGENDA is the point (I was not trying to factor in the 
properties of the VAGENDA when I used that phrase.)  Ill try to be even 
more precise in the future. 

However the example still stands: I have mutliple objects that make up the 
VAGENDA (or are contained by the VAGENDA if you prefer) and they are 
representable by smaller blobs of data.

> > If you look at RFC 2049 you will see:
> >
> >    A mail user agent that is MIME-conformant MUST:
> 
> I'll say it again: a CAP CUA is not necessarily an MUA.  This means that 

> RFC-2049 does not apply to CAP.  It applies to iMIP only because iMIP 
> runs over email, and so an iMIP implementation is necessarily an MUA.

Dont try to split hairs here!  Using that logic I could claim that my HTTP 
server and browsers dont have to be MIME complaint too just because the 
MIME RFCs use the term "A mail user agent" too!  That wont work though...

Since we are using MIME as our encoding framework we need to adhere to its 
rules for conformance.  As such CAP does not get any special "get out of 
MIME conformance free" card.

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: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 12:22:47 -0400

[email-masked] wrote:

> "Represent the VAGENDA by lots of smaller blobs of data" = "Represent 
> the answer to the query such as 'what objects are in the VAGENDA?'' 

They are not the same at all.  If you wanted a root for the latter, it 
would have to be the query.

> Dont try to split hairs here!  Using that logic I could claim that my 
> HTTP server and browsers dont have to be MIME complaint too

They aren't.  Go read RFC-2616: HTTP does not actually use MIME.  From 
the introduction:

   Messages are passed in a format similar to
   that used by Internet mail [9] as defined by the Multipurpose
   Internet Mail Extensions (MIME) [7].

Since RFC-2445 does not reference RFC-2049, there is no sensible basis 
for asserting that any iCalendar implementation is bound by RFC-2049. 
 Likewise, although BEEP does reference RFC-2045 (the basic MIME 
format), it does not reference RFC-2049--if it did, one could argue that 
CAP was bound by RFC-2049.

More to the point, there is no good reason for CAP implementations to be 
bound by RFC-2049.  The requirements of RFC-2049 are designed for MUAs; 
they do not make any sense at all for CUAs.  For example, RFC-2049 
requires text/plain.  What would it mean if a CS received a text/plain 
message? What would you expect it to do with it? Or how about 
message/rfc822, or application/octet-stream (the MUA must offer the 
ability to save the decoded body part into a file)?

The only content type that makes any sense at all in CAP is text/calendar.

-- 
/=====================================================\
|John Stracke      [email-masked]            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/