Robert suggested:
>Why not use the currently defined MIME types that are
>used in the browsers. This way new types can be defined
>when needed and all types currently in use are already
>defined.
This and the prior suggestion are good but there is one slight caveat to
consider. Since MIME has really 2 headers to tell the MUA what the data is
and how it should be used, we would have to greatly increase what propety
parameters we have in iCalendar to achieve the same level of functionality.
The PHOTO example from vCard is not 100% generic as it has an implied use
in vCard so no attachment name or disposition info is necessary. A more
generic example should be considered before making a change to iCalendar.
For example a simple JPEG typically has the following headers:
Content-Type: image/jpeg
Content-Disposition: attachment; filename=logo.jpg
To add the same information we would have to really make 'inline' binary
attachments look really ugly:
ATTACH;ENCODING=BASE64;VALUE=BINARY;ATTTYPE=image/jpeg;
DISPOSITION=Attach;ATTNAME=logo.jpg:MIICajCCAdOgAwIBAgICBEUwD
QYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjY
XBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvc
<...remainder of "BASE64" encoded binary data...>
>Nothing new would have to be designed then.
Well, adding this to ATTACH is a bit more than Id like to see with 'inline'
binary data. It defeats the use of 'inlining' the small binary data since
it just moves the MIME headers from another MIME body part into the
iCalendar property parameters.
Using my KISS principle I have to ask, is adding all this really worth it
over just using ALTREP=... instead?? My understanding of the adding of
'inline' binary data was to allow CUAs the option to put in _typically_
small data rather than take the hit of builidng a more complex
multipart/related message and using ALTREP=MID:... (Ye editors can verify
or deny this). I know they went back and forth on adding and removing this
in various drafts before now so perhaps they can better describe why it is
back in and what limitations there are for this initial release (ie: Is
DISPOSITION=Attach always assumed and as such, not necesssary? Is
DISPOSITION=Inline never allowed since you know know where to inline it?,
etc)...
Frank? Derik?
Bruce
===========================================================================
====
Bruce Kahn INet: Bruce_Kahn@iris.com
Iris Associates Phone: 978.392.5335
Westford, MA, USA 01886 FAX: and nothing but the
FAX...
Standard disclaimers apply, even where prohibited by law...
(See attached file: Kahn6.vcf)
Attachment:
Kahn6.vcf
Description: Binary data