[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: How To Handle Attachments]
George Babics wrote:
> Yes, it can work in the case that the attachment has a CID, but will
> if the attachment is inline, then replacing an attachment with another
> can require much uploading and downloading.
> However, using inline attachments is not recommended. Even if a CUA
> gives the CS an inline attachment, the CS can return it with a CID
> and not inline. This way modifications to attachments can be easily done.
> Should we have text in the CAP draft recommending how attachments
> should be handled?
Some are going to prefer inline others CIDs. For small attachments
inline is fine, for huge attachments I would use a separate body parts.
If I want several components to ATTACH a small object, I could
use an FTP URI, IMAP URI, MID, or any other valid URI.
And you still have the same problem. The CU/CUA is not going to
know that it wants to delete or modify the ATTACH value
until it fetches it.
If the value is a CID, and the VQUERY has:
SELECT ATTACH FROM VEVENT ...
I would have to allow for and expect that I could get
a MIME object with one or two body parts. One text/calendar,
the other the CID contents (if they exist - and they should).
If the value is a MID, I would expect one or two body parts - depending
if the CS has the contents of the MID or not. This is no different
than e-mail. Just because a MIME object contains a CID or MID (or
any other URI), does not mean they exist, it means that at once they
should have existed at one time.
If it is an inline, I would expect one body part - text/calendar
with the embedded inline ATTACH value.
Ether way, if you fetch an ATTACH value, you are going to
get the contents inline or in another body part (if in the CS).
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
title:Chief Executive Manager