Subject: Re: Proposal about multipart etc

From: [email-masked]
Date: Wed, 2 Oct 2002 15:58:40 -0400

George replied on 09/16/2002 09:43:13 AM:
> I know we have no such protocol. My point is that shouldn't the
> CUA be able to see the event (except for the attachment) even
> though the attachment is too big for it?

There are some possible courses of action for the CUA to take if it gets a 
failure response from the CS.  One it to rerequest w/o SELECTing the 
ATTACHments.  This is not 100% guaranteed since the cause may be the 
ALTREPs rather than just the ATTACHments.   We have no means to request no 
multipart data even if the CUA supports it because the entry exceedes the 
CUAs max size but that wont solve the case 100% either.  It could be that 
a different CUA w/a larger capacity created the entry and as such we have 
no clear course of action for the 'smaller' CUA to take short of taking 
'shots in the dark' about what to not request.

If we distinguished between the max iCalendar object size, max ATTACHment 
size (in total??) and max 'external' size (ie: all mulitipart body parts 
outside the iCalendar object) then that gives us a finer grain of control 
but it still wont solve the "my buffer is bigger than yours" issues.  We 
should codify some reasonable behaviours for CUAs to take when 
encountering this since we did create the concept of the limiting size.

Do you have any suggestions on how to deal w/this?

>   It may not even depend much on the implementation and how much the
> owner pays for bandwidth. It will depend much on usage. 

Id change that last line to be "It will depend much on users." since the 
CUs are the ones creating the entries.  Some folks consistanly put in lots 
more than others; kind of like email responses chains or discussions. 

>                                                          Most events 
will
> probably have a SUMMARY, a DTSTART, a DTEND/DURATION, a LOCATION, two or
> three attendees, an ORGANIZER, a UID, a VERSION, a PRODID, and not much 
more.

Well, minimally you will need what you listed (perhaps omitting LOCATION 
and ATTENDEEs if you are doing a non-workflow 'Appointment').  However in 
~5 years of having to look at folks calendars here to see why something 
didnt look right in their calendar or in the busytime system Ive seen 
entries all over the spectrum with no real common size or usage (usage 
being whats in properties like DESCRIPTION, etc).

A REQUEST to the mailing list members would have over 300 (400??) ATTENDEE 
properties alone and each could be longer than a single line if property 
parameters like CN, ROLE, RSVP, PART-STAT and others are included.  No 
ATTTACHments, just lots of data...

> How many bytes can that be? Not very much. However, once you add a huge
> attachment to the event, the CU will not be able to see it, if its CUA 
has
> limits to the sizes of objects.

Its not just a factor of large ATTACHments, its possible to have a very 
large entry w/o any ATTACHments or ALTREPs.  Try creating an "All Hands 
Meeting" entry for Oracle (or just your division) and see how big it 
gets...

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: Andrea Campi <[email-masked]>
Date: Thu, 3 Oct 2002 11:52:12 +0200

> CUAs max size but that wont solve the case 100% either.  It could be that 
[...]
> Do you have any suggestions on how to deal w/this?

One way would be adding a new value for OPTIONS, such that if the
first SEARCH failed, the CUA can retry with something like:

CMD;OPTIONS=STRIP:SEARCH

Which really means "ok, give me only the the absolute minimum to
satisfy the CU".

Not that I advocate this, it's just one possible solution...

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy