Mmmm,
Having performed some testing with Google's CALDAV service, it would appear that Google could be the culprit.
I used their web interface to attach a file to an event using Google's CALDAV service, e.g. the file was called: demo.jpg
I then went back to iCal (configured to use the same Google CALDAV service) and noticed that the filename is not the same as what is diplayed via the web interface.
In iCal, a very long string appears like: "URQ56HtcQ4Qnf0.... "
Does this suggest that when uploading a file via Google's web interface, it obfuscates the process to include additional information associated with the CALDAV account?
I can completely understand why Google have done this.
When I open up the actual google created event and look at the raw syntax (simply drag the event from iCal to the desktop), it appears the attachment tag is denoted by "ATTACH;VALUE=URI:" where the info after URI: is a post/get http string that gets executed by Google's servers.
However, a local iCal event's attachment tag uses: "ATTACH;FMTTYPE=image/jpeg;VALUE=URI:file:/<path>/<to>/<file>".
i.e. the latter is literal and does not need to be executed by Google's "backend" servers to retrieve/process the file.
So it would appear that iCal ignores the attachment capability associated with Google's CALDAV service, knowing that the string needs to be executed by a web server before the file can be sort.
Would this suggest that Google are not conforming to standards? I don't think so because "helper apps" are mentioned in the RFC4791 (section 8.5) standard. And I'm assuming that Apple now use this approach with iCloud.
In the meantime, could someone running CALDAV on OS X server possibly do an attachment test with iCal and see what happens? I'm guessing there's no "Helper App" in this equation.
Cheers,