Subject: Proposal about multipart etc

From: Andrea Campi <[email-masked]>
Date: Wed, 11 Sep 2002 13:32:44 +0200

Hi all,

I'm writing this as a proposal to help focus the discussion and above
all make sure I make my point clear. I think at least a few people
agree on my point of view, so I hope nobody finds this out of place.
I'm not asking to include this text in the draft unless people agree
on all of it. And please excuse my english but I'm not a native
speaker.

 1 Multipart in CAP	[note: addition/revision to 3.3.1 in current draft]

The BEEP data exchanged in CAP may take different forms depending on
the data being exchanged and the capabilities of the CUA and the CS.

If data can be sent in different forms, it is advisable to send it
as text/calendar. In particular, most commands can be sent as
test/calendar.

 1.1 text/calendar

If the payload of a BEEP packet is of type text/calendar, it MUST
conform to [iCAL] iCalendar format. This is the only format which
all CAP implementations MUST accept.

 1.2 multipart/related

If the exchanged packets contain multipart/related payload, they MUST
contain at least one text/calendar parts. If it contains more than
one, they are processed in the same order as they appear [note: I
have no strong opinion on this point]. Data in text/calendar parts
MUST conform to [iCAL] iCalendar format.
If a CUA or a CS don't support this form, they MUST respond with an
appropriate REQUEST-STATUS.

[note: obviously, text/calendar MAY be inside text/alternative, and
parts with unknown MIME types can be thrown away. I don't think we
need to state this here]

If needed, additional data can be transmitted in addidional body
parts using the appropriate MIME type; in particular, this can be
used for attachments. Additional body parts are referred to using
CID: etc.

 2 Multipart negotiation

A CUA and a CS SHOULD negotiate the level of multipart support.
This can be done using the GET-CAPABILITY command [note: we must
add a property for this].
A party should assume the other party can't do multipart, and send
a GET-CAPABILITY command as text/calendar. If the answer states that
the other party supports multipart, it can send subsequent commands
using the appropriate form.
As an alternative, a party may opt to start using multipart and switch
to the simpler text/calendar form if it receives an error.

 3 Considerations

 3.1 Graceful degradation

If both parties support multipart, each party may opt to use the
encoding it prefers. However, text/calendar support is mandatory,
which in particular means a CS MUST use text/calendar in replies
to commands if the party only supports that form, with no loss of
data except as indicated in 3.2.
In particular, if the CUA only supports text/calendar:

 - all replies to commands with multiple targets or multiple queries, as
well as replies containing separate components with different METHODs,
must be sent with different iCalendar objects in the same text/calendar

[note: add more here if we want to. I know this is already present
in iCal]

 3.2 Limitations

 3.2.1 cid: URI

A CUA or a CS which doesn't support multipart can't properly handle
properties with a cid: URI value; this affects ATTACH properties and
any property which allows the ALTREP parameter.

A limited CUA SHOULD inform the user that there is an attachment but
it is not able to access it. It should also provide alternative ways
to attach files to outgoing components. One method would be to store
the file on an appropriate file store and store the URI.

A limited CS SHOULD try not to lose ATTACHments. One method would be
to provide an iMIP+CAP client that stores attachments on any appropriate
file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
ATTACH properties to reference the appropriate URI. It is advisable
that CS which have no limitations, but want to support clients with
limited capabilities, do the same conversion, either at time or
retrieval time.

A final note: I purposefully don't address the problem of a limited
CUA or CS not being able to properly process an iMIP message. As some
people noted on the list, a CUA does not HAVE to know about iMIP, nor
does a CS; in fact, a CUA doesn't have to deal with email at all.

If the implementator wants iMIP support it can still use the same
approach as in 3.2.1, that is provide an iMIP+CAP client to do the
processing. This would probably take the form of a filter inside a
MTA or MUA application.

I think this proposal addresses all concerns presented on the list
by advocates of both approaches. An implementor is free to choose
to support limited or complete functionality without limiting the
user. At the same time, this doesn't in any way (that I know of)
violate or restrict any existent RFC.

I expect that complete applications like Outlook or Ximian Evolution
would support the whole enchilada (they have to, anyway), while light
clients (cell phones, CGI interfaces etc) can be much simpler.

Bye,
	Andrea

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

---

From: Gary Frederick <[email-masked]>
Date: Wed, 11 Sep 2002 16:08:28 -0500

I like the direction this gives. As I read it, it clarifies that any application talks text/calendar while letting the big guys support more.

> contain at least one text/calendar parts.

I feel there may still be a lot of conversation before all the 'parts' are sorted out.

I think Andrea's proposal fits with what Doug has been saying. ???

Gary

---

From: George Babics <[email-masked]>
Date: Thu, 12 Sep 2002 11:47:58 -0400

I do like the proposal. I have a few comments (see below).

> MUST conform to [iCAL] iCalendar format.

  Should we restrict it to one text/calendar part only? Is there a reason
to have more than one part? By specifying only one way, it may make
interoperability easier?

> appropriate REQUEST-STATUS.

  We would need to find a new response code for this.
  I think we still need to fix the response codes in CAP.
  Doug, I believe we decided to do this once CAP is close to
  being finalized?
  
> the file on an appropriate file store and store the URI.

  Is this needed? Can it be a MAY?

> limited capabilities, do the same conversion, either at time or

  Is this needed? Can it be a MAY?

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Sep 2002 10:19:40 -0600

> to have more than one part? By specifying only one way, it may make

Why would that make it easier?

	while (more-text-calendar) {
		process-text-calendar
	}

>   Doug, I believe we decided to do this once CAP is close to

Yes, however there may not be any need for any error.
The other endpoint would know this from the MULTIPART capability.

I would think that is would be okay for the CS in that
case to convert any CIDs to inline, thus no error needed?
And if the URI value is not local, then just return it as a URI.

>   Is this needed? Can it be a MAY?

I agree - MAY. And I would also like the CS to have the
option of making it an inline ATTACH.

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Sep 2002 10:42:05 -0600

> the file on an appropriate file store and store the URI.

I would think that if one endpoint does not support multipart,
then the other endpoint should convert all body part attachments
to inline - and not loose any data and transport them in one 
text/calendar object. We have size capabilities to limit
the size of objects. They will be storable or not.

I agree for ALTREP in a body part. The CUA must decide not
to store any of it, or break it up into what the CS can store
and inform the CU.

If a CUA can not support ALTREP in a body part, then the
CS should return the ALTREP exactly as it is in the
text/calendar object (CID:, ...) with no body part (return
a single text/calendar object). The CUA will know it can not do
multipart and can inform the user. The text/calendar object
can have an appropriate status code to let the CUA know
that the body part exists. CUAs are already going to have to deal
with non-existant CIDs, MIDs, FTPs, ... anyway.

> limited capabilities, do the same conversion, either at time or

There is never any reason to loose attachments, they
can be converted to INLINE by the other endpoint. And
if they are rejected by the endpoint because of size or VCAR,
then they can not be trasported between those endpoints anyway.

And for ALTREP, if the CS can not store the body part, then
it is the CUAs responsibility to store the data or reject
the iCalendar object. We don't need any special protocol
for this, just inform the CU that the CS can not store
the body part contents for the ALTREP and let the CU decide.

---

From: Andrea Campi <[email-masked]>
Date: Thu, 12 Sep 2002 18:55:34 +0200

> to have more than one part? By specifying only one way, it may make

As I noted, I don't feel very strongly about this, speaking in general.
I'd lean towards having only one text/calendar, but if somebody strongly
pushes in other direction, then so be it.

OTOH, I do feel that a command should be composed of only one
text/calendar containing one VCALENDAR object, thus limiting to exactly
one command per "transaction". But I definitely think that we should
first reach a consensus on the general format before.

>   Doug, I believe we decided to do this once CAP is close to

I agree. Also, if nobody else beats me to it, I think I will prepare
a proposal in a few days for the response codes every command can
generate (what can go wrong for each command); from then it should be
easier to build a final list.

>   Is this needed? Can it be a MAY?

Well, as a user, I'd like to be informed that my CUA is not showing me
everything I should know. OTOH, [iTIP] says a CUA can ignore ATTACH
properties, so I guess it can be MAY.

>   Is this needed? Can it be a MAY?

OK.

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

---

From: Andrea Campi <[email-masked]>
Date: Thu, 12 Sep 2002 19:09:38 +0200

> 	while (more-text-calendar) {

While that may be true (as I said, I wouldn't like different commands
in the same transaction), what would be the advantage?

> The other endpoint would know this from the MULTIPART capability.

I would agree if the negotiation is sent as piggyback upon opening a
BEEP channel. This would also be nice to have for other things, i.e.
locale etc.

Or we could make the GET-CAPABILITY negotiation mandatory as the
first command (ugly, as it would force the channel to be stateful).
This would be mean we'd need to introduce an error anyway (command
sent before negotiation), so no real advantage.

At worst, it could be 9.0 (command not recognized); but the nice
thing of having a new request status is that it would permit graceful
fallback.

> option of making it an inline ATTACH.

OK with me, that's why I said 'one method'.

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Sep 2002 11:51:29 -0600

> easier to build a final list.

We have tried the before. We need to wait until CAP is ready.
Otherwise they keep changing. I think we can agree
that that a code will exist - its value unspecified for now.

At the same time they need to be coordinated with 244[567].
Currently - they are not.

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Sep 2002 11:47:56 -0600

> in the same transaction), what would be the advantage?

Not different commands, multiple text/calendar objects in a reply.
Or multiple text/calendar in one command.
All limited to the CAPABILITY of the endpoint.

> BEEP channel. This would also be nice to have for other things, i.e.

Not part of BEEP, part of CAPABILITY.

> sent before negotiation), so no real advantage.

I have already proposed a MULTIPART capability:

	MULTIPART: related, alternate, mixed, ...

And if empty the endpoint does not support any multipart.

---

From: Andrea Campi <[email-masked]>
Date: Thu, 12 Sep 2002 21:00:51 +0200

> Not different commands, multiple text/calendar objects in a reply.

The text in parenthesis was an explication of why I said "may" - i.e.,
I wouldn't like it for commands, but I agree it's easy for replies.

> All limited to the CAPABILITY of the endpoint.

You didn't answer my query - what would be the advantage?
Not that I care to fight over this; I said I have no strong opinion
and it would be limited by the CAPABILITY. I just want to undertand.

> And if empty the endpoint does not support any multipart.

Then we must mandate that each endpoint must assume the other endpoint
does not support any until they do the GET-CAPABILITY handshaking.

With this provision, I agree and support your proposal.

Bye,
	Andrea

---

From: Andrea Campi <[email-masked]>
Date: Thu, 12 Sep 2002 20:56:48 +0200

OK.

> Currently - they are not.

I agree.

Bye,
	Andrea

---

From: [email-masked]
Date: Thu, 12 Sep 2002 17:12:50 -0400

>   Is this needed? Can it be a MAY?

Since this involves apparent loss of data (or at least poor fidelity) from 
the CUs perspective Id say that SHOULD is probably better have here. 

Is it better that a CUA should tell the CU that there is data that it 
cannot access or that that a CUA may or may not notify the CU that there 
is data that cannot be presented to them?  I think the CU should be told 
since it directly involves how they perceive the fidelity of the data 
being presented ("The description says 'Please review the attached proofs 
before the meeting' but I dont see any attached docs.  Did they not get 
sent?")

>   Is this needed? Can it be a MAY?

I think it is needed and that SHOULD is the proper choice (at least for 
the not losing ATTAChments bits).  See above for why.

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: Thu, 12 Sep 2002 17:22:51 -0400

Doug replied on 09/12/2002 12:19:40 PM:
>                And I would also like the CS to have the

I hope you dont like the idea of the CS inlining the 5M ZIP file.  The 
intent of inline was for _small_ binaries.  If my iCalendar parser has to 
parse and save off the inlined data just to get to the next property it 
will but thats just delaying my processing and rendering of it for the CU. 

I have no objections to inlining small binaries (we can nit pick over what 
"small" means later) but I do not like the idea of the CS inlining a 
possibly very large blob of data that delays my processing and rendering. 
I can always tell the CU "Sorry, you cannot view that MPEG yet as its not 
fully downloaded" if its in a separate body part that follows the 
iCalendar body part but I cannot render the iCalendar fully until the 
monster ATTACHment is 'uninlined' so I can get to the properties that come 
after it in the MIME stream (they just get to see the hourglass cursor 
while I stream it down from the CS and cache it off).

Why do you want the CS to inline (I presume) all ATTACHments instead of 
allowing them to be in other MIME body parts??  (I dont see a benefit/need 
here unless you have a backend engine in mind that cannot handle the 
concept of attachments otherwise...)

Bruce

---

From: [email-masked]
Date: Thu, 12 Sep 2002 17:33:54 -0400

> properties, so I guess it can be MAY.

Not so fast.  There is definite distinction between your "not able to 
access it" and "ignoring the ATTACHment". 

The former means the CUA tried to get it but could not.  The latter means 
that the CUA didnt even try. 

In the former case I, as a CU, would definitely want to know so I think 
SHOULD is in order for that situation.  For the case where the CUA does 
not try then Im flexible...

Bruce

---

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

[email-masked] wrote:
> intent of inline was for _small_ binaries.  If my iCalendar parser has
> to parse and save off the inlined data just to get to the next
> property it will but thats just delaying my processing and rendering
> of it for the CU.

I agree, but I like loosing data much less.
(And this also applies to a CUA that wishes to send to a CS that
 does not support multipart).

> I have no objections to inlining small binaries (we can nit pick over
> what "small" means later) but I do not like the idea of the CS
> inlining a possibly very large blob of data that delays my processing
> and rendering.  I can always tell the CU "Sorry, you cannot view that
> MPEG yet as its not fully downloaded" if its in a separate body part
> that follows the iCalendar body part but I cannot render the iCalendar
> fully until the monster ATTACHment is 'uninlined' so I can get to the
> properties that come after it in the MIME stream (they just get to see
> the hourglass cursor while I stream it down from the CS and cache it
> off).

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.

> Why do you want the CS to inline (I presume) all ATTACHments instead
> of allowing them to be in other MIME body parts??  (I dont see a
> benefit/need here unless you have a backend engine in mind that cannot
> handle the concept of attachments otherwise...)

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.

---

From: [email-masked]
Date: Thu, 12 Sep 2002 17:42:11 -0400

> the size of objects. They will be storable or not.

Hmm, so if my CS does not grok multipart and I want to save my ATTACHment 
I have to inline it but if that then exceedes the size limit (because I 
have a big DESCRIPTION, lots of ATTENDEEs, etc) then Im hosed?  Or are 
there other alternatives?

> to store any of it, or break it up into what the CS can store

Just how does the CUA 'break it up' for the CS??  We dont have a way to 
inline ALTREPs, just ATTACHments...

> then they can not be trasported between those endpoints anyway.

So a multipart savy CS may not be able to send a large ATTACHment to a 
multipart ignorant CUA because if it was inlined it would be too big for 
the CUA (I didnt see any text on size limits from the CUAs perspective, 
just the CS's)?..

> the iCalendar object. 

Just where is the CUA going to store ALTREPs if the CS does not accept 
them??  "The CS you are using does not accept multipart data so do you 
want me to use an external storage site and put the richer alternate 
content there?" prompting??

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Sep 2002 15:58:06 -0600

[email-masked] wrote:
> Hmm, so if my CS does not grok multipart and I want to save my
> ATTACHment I have to inline it but if that then exceedes the size
> limit (because I have a big DESCRIPTION, lots of ATTENDEEs, etc) then
> Im hosed?

If the endpoint says that the data is too big - your hosed.

> Just how does the CUA 'break it up' for the CS??  We dont have a way
> to inline ALTREPs, just ATTACHments...

True - I mean - the CUA does it - out of scope for CAP.
The CUA can store the ALTREP or not, but not with CAP.
(I think that a CS that could not handle multipart is busted,
 but some on this list want that, so it is lost, or the CUA
 stores it without CAP).

I do not know of any alternatives.

> multipart ignorant CUA because if it was inlined it would be too big
> for the CUA (I didnt see any text on size limits from the CUAs
> perspective, just the CS's)?..

The CAPABILITY is sent both directions. Which includes size.
A CUA MAY support CAPABILITY, if not, the the CUA is declaring
the defaults - unlimited sizes.

> them??

If a CS can not do it  - then a CS can not do it.

>  "The CS you are using does not accept multipart data so do you

I am saying that some on this list want support for multipart
to be a MAY, that means we have to say - sorry - the CUAs problem.
Do you have an alternate?

Keep in mind that not all ALTREPs are multipart/alternate or CIDs.
The multipart/alternate would be the only ones effected - correct?
(Or I guess they could be multipart/related).

---

From: George Babics <[email-masked]>
Date: Fri, 13 Sep 2002 10:51:56 -0400

> If the endpoint says that the data is too big - your hosed.

  Shouldn't the CUA be able to detect that an event has a large
inline attachment, and decide not to get the attachment but get
the rest of the event? Or if the attachment is too big for
the CUA, the attachment is not returned? The CUA can display a
message to the CU that the attachment was too big to download.
Should the CU not be able to see the event because the attachment
is too big?

  An inline attachment can easily get very big, especially, if the
CUA does not support multipart. However, how often can a DESCRIPTION,
SUMMARY, number of ATTENDEES, etc., be bigger than the maximum? What
would a typical maximum be? 1K, 10K, 100K?

> Do you have an alternate?

  Given ATTACHments and ALTREP are there still people out there who
think support for multipart should be a MAY? If yes, let us know.
(If there are people who say yes, I am fine with keeping it a
MAY!)

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Sep 2002 13:04:25 -0600

> Should the CU not be able to see the event because the attachment

How? We have no such protocol.
The CUA can ask for everything, and if it exceeds the size, it
will get a status error back. How would the CUA know it
was the ATTACH and not the total of all of the properties?

For a CUA that has serious size issues:
A CUA nows what properties it supports. I would assume that
if a CUA has serious size issues, it should only ask for the
properties that it supports. And if it also supports ATTACH and ALTREP,
then *perhaps* a limited memory CUA should separately ask for
those.

Multipart still does not solve the size problem. I do not
think there is a solution If you ask for all of a component,
the size of the result is the sum of all of its body parts. It
is not going to get smaller because the ATTACH or ALTREP value
is in another body part.

We have no way to say:

	SELECT * (except other body parts) FROM VEVENT

And I don't think we need to. Limited memory devices or those
limited to tiny bandwidths will need to just ask for want they
want.

> would a typical maximum be? 1K, 10K, 100K?

'Typical' depends on the implementation and how much the application
owner pays for bandwidth, not CAP the protocol.

> >...

---

From: George Babics <[email-masked]>
Date: Mon, 16 Sep 2002 09:43:13 -0400

> was the ATTACH and not the total of all of the properties?

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?
 
> owner pays for bandwidth, not CAP the protocol.

  It may not even depend much on the implementation and how much the
owner pays for bandwidth. It will depend much on usage. 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.
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.

  (Moreover, even though I did not claim that the typical size
may depend on the protocol, I think that it can. The protocol
can decide what properties you need to specify for which commands.
However, I this is a divergence from the main topic of this
thread that I do not have the time to get into.)

  However, as you stated earlier, and related to the "How To Handle
Attachments" thread, CUAs should be wary of attachments, especially
those with bandwidth or memory limits. A CUA may only want to first
detect if a component has an attachment. Then only if the user wants
the attachment, he may "click" on it. Then the CUA will try to download
the attachment. If it is past the CUAs limit, then it gets an error.
(We can do this with the proposal made in the "How To Handle Attachments"
thread.)

  It would also be helpful if we had some suggestions in CAP on how
attachments should be handled.

George

---

From: [email-masked]
Date: Wed, 25 Sep 2002 11:54:43 -0400

Georged replied on 09/13/2002 10:51:56 AM:
> the CUA, the attachment is not returned?

[Product deathmarches have a way of causing WG neglect so I appologize in 
advance if this is already been covered...]

We have no way to detect that kind of info in CAP last time I dived deep. 
Nor do we have any way to indicate this to the CS (or of the CS to 
indicate on the returend data "I would have sent you the 2 ATTACHments but 
they were both bigger than the size you said was your max allowed size.")

>                                            The CUA can display a

Perhaps you are thinking of IMAP where the MUA can retrieve the body 
structure of the message and then load down the parts it wants/needs... We 
dont have that in CAP though (although I think Pete put it in ICAP a few 
years ago...).

> Should the CU not be able to see the event because the attachment

No.  If the CUA cant handle ATTACHments then it should not ask for them. 

It would be poor CUA design to NOT download, say, a meeting for today just 
because my Palm does not have the space for the mongo attachment.  That 
would make me think that I was free at that time slot when in fact Im not 
and I would miss my meeting.

> CUA does not support multipart. 

That is why the _intended_ use of the inline ATTACHment is for SMALL 
ATTACHments.  It would be considered an abuse to inline the 5.8M 
PowerPoint presentation although its unspecifed exactly how "small" small 
is.  Common sense should be applied here.

>                                 However, how often can a DESCRIPTION,

With regard to properties that you need to make the entry meaningfull (ie: 
SUMMARY, DESCRIPTION) where there can be ALTREPs the story is a bit 
different.  We have never put a limit on their size but we (collectively) 
expected that SUMMARY is the short text that describes the event (ie: the 
Subject line in the iMIP message or that is rendered in the 'view' of the 
calendar that a CU sees such as in Organizer, Outlook, etc.)  The 
DESCRIPTION property is "a more complete description" than what you find 
in SUMMARY.  This is typically the bigger, more complex information (much 
like the body of an email vs the Subject line). 

There is no limit to their sizes or to the size of the ALTREPs.  Nor is 
there a limit to the complexity of the ALTREPs; they can be single MIME 
elements (ie: text/html) or multipart elements themselves (ie: 
multipart/alternative with text/html, application/ms-tnef and 
application/postscript subelements) but thats a sidenote really....

The properties like SUBJECT or DESCRIPTION are necessary to properly 
present the entry to the CU in some fashion.  If they are missing then the 
entry is probably not very meaningful ("Hmm, George invited me to an event 
but he didnt send any Summary or detailed info about it...").  If the 
ATTACHment was missing then at least I know something about the entry 
("Hmm, George invited me to discuss the CAP design for multiparts and 
ATTACHments...") so I can make a more informed choice as to what to do.

All this begs the question: Why does it matter what a typical size for 
something is?  Hopefully you aren't designing anything (CAP or CAP engine) 
so that there are hard limits...

> > The CUA can store the ALTREP or not, but not with CAP.

[This looks like Dougs response here but I missed it the 1st time 
around...]

Whoa!!!!  Why not _with_ CAP??  Ive yet to hear any good reason that a CUA 
cannot craft an entry that looks (in part) like:

multipart/related
    text/calendar (with CID:1.1)
        ...
        DESCRIPTION;ALTREP=CID:1.2:Agenda\n1) CAP design review\n...
        ...
    text/html (with CID:1.2)
        <HTML><HEAD><TITLE>CAP Design Review</TITLE></HEAD><BODY>
        <P><H1>Agenda:</H1><OL><LI>CAP Design</LI>...

Why cant a CUA send this to a CS using CAP?? 

The only reason I can think of is that the choice for a CS's back end 
storage is some dB engine/model that cant deal with multipart.  Sorry, 
thats not an acceptable justification to me or my users.  We no longer 
live in 'plain' ASCII email world and users are getting more and more used 
to richer data so I really really need to hear a very good reason that CAP 
should NOT support multipart.

> (If there are people who say yes, I am fine with keeping it a

I think that MAY is too weak myself given that iCalendar is already 
'multipart ready' (TM by me) with ATTACHments and ALTREPs.  I prefer 
SHOULD since its stronger and Ive yet to hear any reasons why we should 
NOT have multipart support out of the gates.  From 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

and

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

Given these Id say that supporting multipart definitely falls under 
"SHOULD" since multipart is NOT something that just 'enhances the product' 
unless you are coding to 1985 standards.  The concept of multipart has 
been in iCalendar since Day 1 (or maybe 2) and removing it in a followon 
protocol 4 years later is something that should be carefully weighted and 
not just (seemingly) arbitrarily done.

Bruce

---

From: [email-masked]
Date: Wed, 25 Sep 2002 13:55:49 -0400

> is not going to get smaller because the ATTACH or ALTREP value

I was with you up to this point.  The Draft 9b says:

      MAX-COMPONENT-SIZE
                        1     A positive integer value that specifies
                              the size of the largest iCalendar
                              object that the server will accept in
                              octets. [Snip]

An iCalendar object is defined as:

   Object -  A generic name for any component, property, parameter, or
      value type to be used in iCalendar.

As such, the ALTREP and ATTACHment data external to the 
BEGIN:VCALENDAR...END:VCALENDAR boundaries are not part of that 'object'. 
They are related to it but not part of it.

> limited to tiny bandwidths will need to just ask for want they

I can see a use for having a "NOT" in the selection process.  "Give me all 
properties except ATTACH and VALARM" is a quite logical desire.  Its MUCH 
shorter than expressly listing _every_ property except those... 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Sep 2002 12:25:58 -0600

> Whoa!!!!  Why not _with_ CAP??  Ive yet to hear any good reason that a 
> CUA cannot craft an entry that looks (in part) like:

The topic was when the other endpoint can not handle multipart
AND it can not transfer that large of an inline object.

Should the CUA throw it away? Or can (MAY) it store the
attachment its self?

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Sep 2002 12:48:57 -0600

So what are you proposing as the solution? Are you
saying that because an endpoint supports multipart
that it MUST allow for unlimited sizes in the body parts?

Or are you saying that we should define MAX-COMPONENT-SIZE
to include body parts?

[email-masked] wrote:
> BEGIN:VCALENDAR...END:VCALENDAR boundaries are not part of that 
> 'object'.  They are related to it but not part of it.

---

From: George Babics <[email-masked]>
Date: Thu, 26 Sep 2002 12:45:23 -0400

[email-masked] wrote:
> [Product deathmarches have a way of causing WG neglect so I appologize in advance if this is already been covered...]
> 
> We have no way to detect that kind of info in CAP last time I dived deep.  Nor do we have any way to indicate this to the CS (or of the CS to indicate on the returend data "I would have sent you the
> 2 ATTACHments but they were both bigger than the size you said was your max allowed size.")

  Yes, but it would be nice if we did have such a feature.

> Perhaps you are thinking of IMAP where the MUA can retrieve the body structure of the message and then load down the parts it wants/needs...  We dont have that in CAP though (although I think Pete
> put it in ICAP a few years ago...).

  I was thinking of being able to do it in CAP if we had the above mentioned
feature.

> No.  If the CUA cant handle ATTACHments then it should not ask for them.

  What if the CUA can only handle attachments up to a certain size?

> 
> It would be poor CUA design to NOT download, say, a meeting for today just because my Palm does not have the space for the mongo attachment.  That would make me think that I was free at that time
> slot when in fact Im not and I would miss my meeting.

  Then the CUA should somehow be able to detect that it should
not try to download the attachment because it is too big.

> That is why the _intended_ use of the inline ATTACHment is for SMALL ATTACHments.  It would be considered an abuse to inline the 5.8M PowerPoint presentation although its unspecifed exactly how
> "small" small is.  Common sense should be applied here.
> 
> With regard to properties that you need to make the entry meaningfull (ie: SUMMARY, DESCRIPTION) where there can be ALTREPs the story is a bit different.  We have never put a limit on their size but
> we (collectively) expected that SUMMARY is the short text that describes the event (ie: the Subject line in the iMIP message or that is rendered in the 'view' of the calendar that a CU sees such as
> in Organizer, Outlook, etc.)  The DESCRIPTION property is "a more complete description" than what you find in SUMMARY.  This is typically the bigger, more complex information (much like the body of
> an email vs the Subject line).
> 
> There is no limit to their sizes or to the size of the ALTREPs.  Nor is there a limit to the complexity of the ALTREPs; they can be single MIME elements (ie: text/html) or multipart elements
> themselves (ie: multipart/alternative with text/html, application/ms-tnef and application/postscript subelements) but thats a sidenote really....
> 
> The properties like SUBJECT or DESCRIPTION are necessary to properly present the entry to the CU in some fashion.  If they are missing then the entry is probably not very meaningful ("Hmm, George
> invited me to an event but he didnt send any Summary or detailed info about it...").  If the ATTACHment was missing then at least I know something about the entry ("Hmm, George invited me to discuss
> the CAP design for multiparts and ATTACHments...") so I can make a more informed choice as to what to do.
> 
> All this begs the question: Why does it matter what a typical size for something is?  Hopefully you aren't designing anything (CAP or CAP engine) so that there are hard limits...

  This question came up when discussing if a parameter that limits
the size of an iCalendar is sufficient to prevent sending iCalendars
with huge attachments to clients that can not support huge attachments.
My point was that a typical iCalendar, without attachments, would be
very small. In contrast attachments can be very big. We probably should
have a parameter to limit the size of the iCalendar and one for
the attachments. If the limit for the attachments would be exceeded
we would still return the event, but with an error message saying
that the attachment(s) could not be sent since they exceeded the limit.

> [This looks like Dougs response here but I missed it the 1st time around...]
> 
> Whoa!!!!  Why not _with_ CAP??  Ive yet to hear any good reason that a CUA cannot craft an entry that looks (in part) like:
> 
> multipart/related
> The only reason I can think of is that the choice for a CS's back end storage is some dB engine/model that cant deal with multipart.  Sorry, thats not an acceptable justification to me or my users.
>  We no longer live in 'plain' ASCII email world and users are getting more and more used to richer data so I really really need to hear a very good reason that CAP should NOT support multipart.
> 
> I think that MAY is too weak myself given that iCalendar is already 'multipart ready' (TM by me) with ATTACHments and ALTREPs.  I prefer SHOULD since its stronger and Ive yet to hear any reasons why
> we should NOT have multipart support out of the gates.  From 2119:
> 
> Given these Id say that supporting multipart definitely falls under "SHOULD" since multipart is NOT something that just 'enhances the product' unless you are coding to 1985 standards.  The concept
> of multipart has been in iCalendar since Day 1 (or maybe 2) and removing it in a followon protocol 4 years later is something that should be carefully weighted and not just (seemingly) arbitrarily
> done.
> 
> Bruce
> Bruce Kahn                                INet: [email-masked]

---

From: George Babics <[email-masked]>
Date: Thu, 26 Sep 2002 12:50:44 -0400

We can even make it a MUST. Lately, I have only seen people
who think it should be a SHOULD or a MUST. I propose we change
it unless someone objects. Any objectors?

George

---

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

> it unless someone objects. Any objectors?

I object to this. It would be fine having a SHOULD.

> Why cant a CUA send this to a CS using CAP??

I agree no real implementation of a CS would want to refuse this. 
Rather, the problem I see is the opposite. I can foresee a whole class 
of lightweight CUAs which will never send such complex objects, and 
would be greatly complicated if they HAD to implement a parser for 
multipart responses:

  - a CGI based "CUA" for reading agendas (think meetings for a user 
groups, baseball team matches, or look at how Apple iCal publishes 
agendas);
  - a WAP based CUA, be it read only or read/write;
  - even a J2ME CUA for today's mobile phones doesn't have a lot of 
memory at hand.

To these CUAs multipart is not very useful, and actually adds a lot of 
complexity for no benefit.

What's the reason you prefer MUST instead of SHOULD? Is there something 
my proposal for autonegotiating multipart support didn't address? 
Admittedly, it would add a small complexity, but IMHO it's minor 
compared to other parts.

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Thu, 26 Sep 2002 11:45:34 -0600

Are you asking that it be a MUST for all valid multipart types?
(multipart/related, multipart/alternate, multipart/mixed, ...)
Which would include nested multi parts (a multipart alternate
body part that contains a multipart related mime object, ...)?

I would like to see it a MUST for multipart support.

Then we can extend/modify the size capabilities to help
storage and/or bandwidth limited CS's and CUA's.

---

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

> Admittedly, it would add a small complexity, but IMHO it's minor

  A MUST would be preferable instead of a SHOULD because
there would only be one way to do it, and this may help
interoperability. Furthermore, it will remove some complexity.

  However, given the concerns for lightweight CUAs are more
important, I am fine with SHOULD.

George

---

From: Gary Frederick <[email-masked]>
Date: Fri, 27 Sep 2002 06:03:27 -0500

Are we getting to

  MUST for multipart support
  adding SIZE* for parts

if so???
  will a CUA can specify what parts it will take?
    can it specify it will not take multipart ever (small device)
    or will it specify individually/ each time

Gary