Subject: Re: MIME encapsulation of multipart responses

From: [email-masked]
Date: Mon, 9 Sep 2002 11:11:27 -0400

Doug replied:
>If I do a 'get me the entire VAGENDA', which do I want:
> 
>    (a) One massive blob in a multipart/related MIME object.
>    or
>    (b) A massive amount of small blobs each in a single
>             MIME object.
>    or
>    (c) A mixture of (a) and (b) with multiple icalobjects
>        in each (b) of the same METHOD.

What you as a CUA want may/will be different than what the CS wants for 
assorted reasons.  The CS may find it easier to do any of the above for 
various reasons (ie: "Dump whats in the cache first and then go find 
individuals that are not aready sent", "Process what I can in a given 
amount of time, send it and then go back and repeat until done", "Start 
with the first match, process it and find the next one to continue with", 
etc.).

To make a CUA implementors life easier some may wish for 'lots of little 
bite size data' because its less for them to worry about (ie: parsing 
large blocks of data in a timely manner, making correct/incorrect 
assumptions about the format of the data stream to be returned when they 
initially designed their engine, etc).  However this makes the CS 
implementors life worse as it implicitly forces some CS designs on them 
that may not be suitable for them (ie: it degrades scalablilty or 
efficiency).

Given that CS performance/scalability is of greater interest to me I would 
say that (c) is probably the route to take.  If we are NOT clear in the 
draft then we will run into the same kinds of assumptions like John made 
in his parser regarding mulitple icalobjects.

>Before we can decide on the ANS vs RPY. 

Doesnt this depend on which case is involved?  For (a) it would be a RPY 
but for (c) it would be an ANS, no??  (Ive still not fully absorbed BEEP 
nuances.)

>                                          Are there any
> of the above we can eliminate as valid (outside of BEEP)?
> Are there more?

Dont think so and not that I can see.

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: Tue, 10 Sep 2002 17:33:10 -0400

John wrote:
> >It has been a while so maybe it is multipart/mixed that I mean.
> >
> >Is multipart/related when you have the first part that can
> >contain CID's or MID's?
> >
> Yes.

Not strictly true.  Its possible to have CID/MID references in subparts of 
the multipart/related.  For example:

multipart/related
        multipart/alternative
                text/plain
                text/html
                application/ms-tnef
        image/gif
        image/gif

where the CID references are in the text/html or possibly the 
application/ms-tnef.

> >DESCRIPTION;ALTREP="CID:<[email-masked]>":Project
> >       XYZ Review Meeting will include the following agenda items: (a)
> >       Market Overview, (b) Finances, (c) Project Management
> >
> >   ...
> >
> >
> >So multipart/<something> must be valid.
> >
> Not necessarily.  A cid: URL can point to a body-part outside the 
> current message (see RFC-2392, section 1, paragraph 3).

Yes, thats allowed but not the normal/expected usage.  MTHML message tend 
to include the content in other body parts and the examples in RFC 2392 
use CIDs to point to other body parts in the same stream and MIDs to point 
to messages. 

Still, unless you can 100% guarantee that the externally referenced CID is 
still around and accesable by every CU then its very unsafe to just assume 
that you can use a CID to an ATTACHment or ALTREP that was sent out a 
while ago.  (If I didnt get the initial invitation then I certainly wont 
have the CID from it for you to refer to later on.)

I delete lots of older mail/docs/invites when newer ones arrive; otherwise 
my mail file would be much much larger than the 500M+ it is now.  I may be 
an anomoly but I know that many of our users dont keep 'older' copies of 
requests and the like around so Im not that unusual.

Also, unless you are advocating the return to 'deltas' in iCalendar you 
want/need to be sending full snapshots to invitees.  As such, since the 
ATTACHment and ALTREPs are part of that snapshot you should be resending 
them.

When referring to RFC 2392 you need to take into account that it was 
designed around the mail store which is NOT typically shared per user. 
That is, you cannot send me a CID that refers to a body part in a message 
in Dougs message store/calendar (even on the same CS).

Actually you could send it but I would certainly hope that your CS would 
prevent me from getting it (I certainly dont let everyone have direct 
access to my calendar!).  The CS is not logically equivalent to "the 
message store" from 2392; the calendar is.

The gist of all this is that yes a CID can refer to a body part in another 
message but A) its not safe to assume that everyone has that CID (for 
several reasons), B) the "message store" of RFC 2392 is not logically 
equivalent to the CS and C) the data the CID referneces still has to find 
some way to get to the CS and Ive yet to hear how you thinks that will 
happen.

Bruce
==========
=================================================================
Bruce Kahn                                INet: