Subject: [Ietf-calsify] Question about attachment

From: Doug at Royer.com (Doug Royer)
Date: Thu Nov 10 00:50:23 2005

> I think that the inline binary enconded content option for ATTACH
 > property is somewhat broken anyway. As far as I know, it is not used
 > too often and it lacks essential standard metadata parameters such as
 > filename and size. Both would be useful at least in synchronization/
 > Do you think that this could be fixed in the revised spec?

The other form of attachement is CID and MID MIME attachements,
they contain the size and often (or always?) the filename.

They might not be used that often. However when there is
no common or secure place to store the attachment that is
for all the attendees, inline is the only way that works.

I do not think it is broke.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051110/34c66885/smime-0001.bin

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Fri Nov 11 03:18:12 2005

Hi,

Let me try to reformulate the problem I think Jyrki was describing. 
Let's say Bob gets a meeting invitation with three attachments, each in 
its own 'application/vnd.oasis.opendocument.presentation' MIME object, 
and each referenced in the VEVENT using ATTACH and CID URIs. Each MIME 
object (that arrived as part of a multipart) might also include other 
information in the MIME header, like a Content-Disposition header field 
of value attachment with a suggested filename, e.g. agenda.odp, 
previous_minutes.odp and Ideas for 2006.odp.

Now Bob exports his calendar and then imports it into another device. As 
I've understood it, import/export necessarily needs to use ATTACH with 
inline content rather than CID URLs (after all, the transport of the 
calendar data could be something other than MIME).

What happens is that only the content type is preserved as the FMTTYPE 
parameter. Everything else in the MIME header is lost. Granted, most 
things could be re-generated (multipart boundaries, Content-IDs, etc.) 
were the event be forwarded using MIME multipart, but some like the 
filename of each attachment can't.

So after the import, Bob has problems knowing which one of the 
attachments corresponds with which filename.

Cheers,
Aki

ext Doug Royer wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Nov 11 12:09:54 2005

Remember. Import and Export are not iCal concepts. And storing
ICS files with-OUT their MIME headers is also NOT an iCal concept.

iCal is a MIME format. So export your iCal MIME object with
the CID attachments intact. And make sure your iCal import
tools know how to read the iCal MIME objects.

Now the filenames are preserved.

More embedded below...

> calendar data could be something other than MIME).

That is up to the CUA. A CID and attachment CUA could post the
attachments to a web page and send out iCal objects with
the attachments set to HTTP and not CID.

> filename of each attachment can't.

Yep. filename is lost unless the CUA converts it to external
attachment in that case.

> attachments corresponds with which filename.

Only because you ripped out the CID parts of the iCal MIME
object from the original iCal MIME object. At the point
where the CUA pulled them out, it broke them, not iCal.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051111/65c8086f/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Nov 11 13:58:56 2005

> tools know how to read the iCal MIME objects.

Then why does rfc2445 say:
    This memo is formatted as a registration for a MIME media type per
    [RFC 2048]. However, the format in this memo is equally applicable
    for use outside of a MIME message content type.

iCalendar is applicable ouside the mime world. (look at apple ical, 
icalx.com, icalshare.com etc)

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Nov 11 16:42:19 2005

Michiel van Leeuwen wrote:

 > iCalendar is applicable ouside the mime world.

It does not however say that ripping out the 2/3 or more of the
original MIME object is the equivalent object.

Which is in effect what the poster said when they wanted to
take just the ICS part of the MIME object and disregard the reset 
(attachments) of iCal MIME object.

The poster indirectly said they wanted to covert the CIDs to inline
and throw away the filenames.

If you want to keep ALL of the data, then keep all of the data.

 > (look at apple ical, icalx.com, icalshare.com etc).

I do not think they support CID attachments, so they are not
tossing the file names.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051111/e7f706f1/smime.bin