Subject: [Ietf-calsify] Question about attachment

From: jyrki.hokkanen at nokia.com ([email-masked])
Date: Wed Nov 9 23:15:40 2005

Hi,

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?

Kind regards,
Jyrki Hokkanen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Lisa Dusseault
Sent: Thursday, November 10, 2005 4:13 AM
To: LinyiTian
Cc: shenhai; kangjiao; IETF-iCalendar
Subject: Re: [Ietf-calsify] Question about attachment

There really aren't many guidelines on this so far. If you have any implementation experience with limitations, information on that would be helpful as we revise iCalendar. 

Thanks! 
Lisa Dusseault 

On Nov 7, 2005, at 2:16 AM, LinyiTian wrote: 

Hi, All 
　I am a new comer. I have one question about attachment in iCalendar. Since attachment can be binary and external link in iCalendar.　Is there a principle when a attachment should be a external link? Size limited or based on user's preference? Can a doc with 10M size be attached internal? 
Best Regards 
Linyi Tian 
Application & Software Dept. 
Huawei Technologies Co., Ltd 
-------------------------------------------------- 
Office: +86-755-28974272 
Mobile: +86-13923718857 
Fax: +86-755-28976100 
Email: [email-masked] 
-------------------------------------------------- 

*************************************************************************************************** 
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! 
*************************************************************************************************** 
　　　　　　 

　　　　　　　　　　 　 
　　　　　　　　　　　　　　 

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

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Fri Nov 11 20:14:49 2005

I agree that the ATTACH property should provide support for
parameters to specify information like filename and size
the same way that RFC 2183 does for the Content-Disposition
header:

     disposition-parm := filename-parm
                       / creation-date-parm
                       / modification-date-parm
                       / read-date-parm
                       / size-parm
                       / parameter

We should discuss which parameter we would like iCalendar
to support? I'm not sure we need a "read-date" parameter...

Cheers,
Bernard

---

From: jyrki.hokkanen at nokia.com (Jyrki Hokkanen)
Date: Mon Nov 14 12:00:57 2005

Hi,

I was thinking about those same  RFC 2183 parameters also. I think the 
minimal set
would be filename and size. The others seem to be less relevant.

Regards,
Jyrki

ext Bernard Desruisseaux wrote:

>>?I am a new comer. I have one question about attachment in iCalendar. Since attachment can be binary and external link in iCalendar.?Is there a principle when a attachment should be a external link? Size limited or based on user's preference? Can a doc with 10M size be attached internal? 
>>Best Regards 
>>Linyi Tian 
>>?????? 
>>?????????? ? 
>>??????????????

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Nov 15 20:27:27 2005

If a new draft "iCal File Format" were the purpose of CALSIFY
and if such a draft existed, I could agree once I saw
the proposal.

However until such a document is created that also addresses
the other issues with using the ICS data format as a calendar
store, it would just be duplicating the MIME object data that
is easy to parse and understand now.

So I do agree that an iCal-File-Format draft would be useful.
I do not think that adding options to iCal at this point
is on-topic for CALSIFY.

I think we need to leave the file format for the implementation
at this point in time and continue to use MIME as the 2445
and 2446 format which already has those options.

> parameters to specify information like filename and size the same way
> that RFC 2183 does for the Content-Disposition header:

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/20051115/bd4cf7fb/smime.bin