Subject: Re: Proposal about multipart etc

From: [email-masked]
Date: Wed, 25 Sep 2002 13:18:35 -0400

Doug wrote on 09/12/2002 03:50:38 PM CST:
> If the endpoint does not want large iCalendar objects, it is
> free to set its size CAPABILITY to an acceptable limit. However
> if it is set to unlimited size, then the endpoint is saying that
> it *is* acceptable.

I think there is a difference between what is the maximum size object (ie: 
VEVENT) that a CUA/CS wants and the maximum size non-inlined ATTACHment or 
ALTREP data.  I for one would definitely NOT like to 'miss' a meeting 
because the large ATTACHment was over some limit when the actual VEVENT 
size is not.  This is poor design if that can happen!  Then again, if the 
CUA is pressed for space, it should consider NOT asking for ATTACHments...

In Draft 09b the relevant text is:

      MAX-COMPONENT-SIZE
                        1     A positive integer value that specifies
                              the size of the largest iCalendar
                              object that the server will accept in
                              octets. Objects larger than this will be
                              rejected. The absence of this attribute
                              indicates no limit. This is also the
                              maximum value of any BEEP payload
                              the CS will accept or send.

This is talking about an "iCalendar object" which does NOT necessarily 
include the related MIME body parts in a multipart stream.  This could 
relate to ATTACHments if they are inlined but this does NOT cover the size 
of ALTREPs (at least not as currently written).  Perhaps a 
MAX-ATTACHMENT-SIZE is necessary as well... (Would it be per ATTACHment or 
total?  I can see either side as being valid...) 

A new MAX-ATTACHMENT-SIZE would not cover any ALTREPs though so should 
they be folded into the MAX-COMPONENT-SIZE text or should we have another 
way to limit their size.  Since ALTREP can be added to several properties 
(including TBD ones from SKiCAL, etc) Im inclined to NOT factor them into 
the MAX-COMPONENT-SIZE.  Rather a something like a MAX-EXTERNAL-SIZE could 
be created to cover the largest size for all 'external' (to the iCalendar 
object yet still in the MIME stream)...

Also, if we adopt a MAX-ATTACHMENT-SIZE then we need to be explicit in how 
an inlined ATTACHment is factored into the octet counts: does it go under 
MAX-COMPONENT-SIZE or under MAX-ATTACHMENT-SIZE.  I for one would say that 
if its inlined then its under MAX-COMPONENT-SIZE and NOT under 
MAX-ATTACHMENT-SIZE...

> I think you got off of the path here, which was: *Only* when the
> other endpoint can not do multipart. If the other endpoint can
> do multipart, then multipart IS acceptable and no conversion
> to inline is needed.

Ok, just to be crytal clear on this (in case we actually draft up some 
text to cover it at some point): SHOULD/MUST the CS inline ATTACHments 
ONLY if the requestor is NOT multipart savy and has requested non-inlined 
ATTACHments?  Can the CS do the non-inline -> inline conversion at its 
whim or only for the non-multipart case.  That is, if I send multipart 
data to a multipart savy CS, will the CS have the option to inline the 
ATTACHments I send when I turn around and retrieve them back?  Or MUST it 
preserve the structure whenver possible?

I think we are in very close agreement on this and I have a bunch of other 
WG backlog to get thru but Im trying to avoid any vagueness on this in CAP 
so we dont have a repeat of the multipart pains from iCalendar.

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: Doug Royer <[email-masked]>
Date: Wed, 25 Sep 2002 12:39:52 -0600

> ONLY if the requestor is NOT multipart savy and has requested 
> non-inlined ATTACHments?  Can the CS do the non-inline -> inline 
> conversion at its whim or only for the non-multipart case.  That is, if 
> I send multipart data to a multipart savy CS, will the CS have the 
> option to inline the ATTACHments I send when I turn around and retrieve 
> them back?  Or MUST it preserve the structure whenver possible?

I would think it MUST preserve the structure whenever possible.
And in this context, that means if the CS gets it multipart, then
the CS MUST send it back multipart when the CUA supports multipart.

---

From: George Babics <[email-masked]>
Date: Thu, 26 Sep 2002 13:10:00 -0400

I like the idea, see comments below...

[email-masked] wrote:
> I think there is a difference between what is the maximum size object (ie: VEVENT) that a CUA/CS wants and the maximum size non-inlined ATTACHment or ALTREP data.  I for one would definitely NOT
> like to 'miss' a meeting because the large ATTACHment was over some limit when the actual VEVENT size is not.  This is poor design if that can happen!  Then again, if the CUA is pressed for space,
> it should consider NOT asking for ATTACHments...
> 
> This is talking about an "iCalendar object" which does NOT necessarily include the related MIME body parts in a multipart stream.  This could relate to ATTACHments if they are inlined but this does
> NOT cover the size of ALTREPs (at least not as currently written).  Perhaps a MAX-ATTACHMENT-SIZE is necessary as well... (Would it be per ATTACHment or total?  I can see either side as being

  We can even have a MAX-PROPERTY-SIZE ...

> valid...)
> 
> A new MAX-ATTACHMENT-SIZE would not cover any ALTREPs though so should they be folded into the MAX-COMPONENT-SIZE text or should we have another way to limit their size.  Since ALTREP can be added
> to several properties (including TBD ones from SKiCAL, etc) Im inclined to NOT factor them into the MAX-COMPONENT-SIZE.  Rather a something like a MAX-EXTERNAL-SIZE could be created to cover the
> largest size for all 'external' (to the iCalendar object yet still in the MIME stream)...
> 
> Also, if we adopt a MAX-ATTACHMENT-SIZE then we need to be explicit in how an inlined ATTACHment is factored into the octet counts: does it go under MAX-COMPONENT-SIZE or under MAX-ATTACHMENT-SIZE.
>  I for one would say that if its inlined then its under MAX-COMPONENT-SIZE and NOT under MAX-ATTACHMENT-SIZE...

  For inlined, we may want it under MAX-ATTACHMENT-SIZE. We may simply not
return the attachment, but still return the component, with an error letting
us know that the attachment was not sent because it was too big.

> Ok, just to be crytal clear on this (in case we actually draft up some text to cover it at some point): SHOULD/MUST the CS inline ATTACHments ONLY if the requestor is NOT multipart savy and has
> requested non-inlined ATTACHments?  Can the CS do the non-inline -> inline conversion at its whim or only for the non-multipart case.  That is, if I send multipart data to a multipart savy CS, will
> the CS have the option to inline the ATTACHments I send when I turn around and retrieve them back?  Or MUST it preserve the structure whenver possible?
> 
> I think we are in very close agreement on this and I have a bunch of other WG backlog to get thru but Im trying to avoid any vagueness on this in CAP so we dont have a repeat of the multipart pains
> from iCalendar.
> 
> Bruce
> Bruce Kahn                                INet: [email-masked]

George

---

From: Andrea Campi <[email-masked]>
Date: Thu, 26 Sep 2002 19:59:06 +0200

On Thursday, September 26, 2002, at 07:10 PM, George Babics wrote:
>> Also, if we adopt a MAX-ATTACHMENT-SIZE then we need to be explicit 
>> in how an inlined ATTACHment is factored into the octet counts: does 
>> it go under MAX-COMPONENT-SIZE or under MAX-ATTACHMENT-SIZE.
>>  I for one would say that if its inlined then its under 
>> MAX-COMPONENT-SIZE and NOT under MAX-ATTACHMENT-SIZE...
>

I agree with Bruce here - it should be under MAX-COMPONENT-SIZE and NOT 
under MAX-ATTACHMENT-SIZE. The rationale is that we want to know that 
we either get a component with the same content as was stored, or we 
get back an error - we don't want to get a partial component with an 
error state.

Besides, what would happen if we had:

attachment #1	50KB
attachment #2	100KB
attachment #3	1.1MB
altrep	  #1	10KB
altrep	  #2   100KB

and a limit of 150KB? We'd need enough details in the error to know 
what we lost, or it wouldn't be very useful...

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Thu, 26 Sep 2002 12:08:38 -0600

SIZE: It makes no difference if an attachment is inline or a body part,
as the endpoint can simply rewrite the object.

So, how about only these two:

	MAX-OBJECT-SIZE is the entire object size and includes
                         all mime body parts including all headers.

	MAX-BODYPART-SIZE could be for all NON-iCalendar objects. Meaning
                           that this is the max BLOB size that the endpoint
                           can handle outside of an iCalendar object.

	And maybe:

	MAX-COMPONENT-SIZE, Which only includes everything between
  		            the first BEGIN: and the last END:

And all -SIZE capabilities are in over the wire size. So if BASE64
encoding doubles the size of the object, then the capability specifies
the over the wire doubled size even when it could be stored in a
much smaller binary size.

---

From: George Babics <[email-masked]>
Date: Thu, 26 Sep 2002 14:47:06 -0400

> what we lost, or it wouldn't be very useful...

  Why not an error simply stating that some of the attachments could
not be downloaded. A user will still want to see the basic information
about an event even if some of the attachments are too big for his
CUA.

George

---

From: Doug Royer <[email-masked]>
Date: Fri, 27 Sep 2002 19:08:50 -0600

> about an event even if some of the attachments are too big for his

How about specifying that the endpoint MUST include the error
status and CID (or MID) for all items that could not be transfered
WITH their wire size in octets:

All three could be returned. Starting with attachment #3 in
the example above:

		3.x TOO BIG: 1100000 CID:123
		3.x TOO BIG: 10000 CID:456sdf
		3.x TOO BIG: 100000 CID:sfjjdsf

Then how about we extend CAL-QL and add something like:

		SELECT bodypart('CID:123') FROM VEVENT WHERE UID = 'abc'

And the results would be:

	<multipart/related? mime header>

	<text/calendar mime headers>

	BEGIN:VENENT
	..<needed stuff>..

	(For ATTACH body parts)
	ATTACH:CID:123	

	(and for an ALTREP)
	DESCRIPTION;ALTREP="CID:sfjjdsf":Project description ...

	END:VEVNET

	<bodypart 'CID:123' mime headers>
	...data...

With the size and the CID, the endpoint could determine for itself
if it wanted to fetch the body part. It would allow for ALTREP
and ATTACH. And if multiple 'bodypart()' functions are supplied, then
the properties and body parts must be in the order specified in the
query.