Subject: [Ietf-calsify] Clarification on section 6 iCalendar objects in draft-cstoner-rfc2445bis-00

From: PStephenson at gw.novell.com (Preston Stephenson)
Date: Thu Nov 17 10:53:48 2005

Can you give an example of what it means to have multiple iCalendar
objects?

Is section 4.4 Multiple Similar Components in
draft-ietf-calsify-rfc2447bis-00.txt in
compliance or not?

Thanks.
Preston

---

From: tianlinyi at huawei.com (Linyi Tian)
Date: Thu Nov 17 11:03:48 2005

Hi, All

     I find the "the calendaring and scheduling consortium" which website is http://www.calconnect.org/. Since it address the same topic with our group, i am confused.

Can anybody tell me that what is the relationship between it and our group?  Is there some overlap between two activities?

Best Regards
Linyi Tian
Huawei Technologies Co., Ltd

----- Original Message ----- 
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 17, 2005 7:00 PM
Subject: [Ietf-calsify] Clarification on section 6 iCalendar objects indraft-cstoner-rfc2445bis-00

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

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Thu Nov 17 11:41:49 2005

Hello Linyi Tian,

The CalConnect consortium is definitely working on very related topics, 
and there is also overlap in discussions, but the work is done together 
with the IETF, rather than in competition.   The CalConnect consortium 
has no plans to develop standards as the IETF WGs do, but instead to 
gather information about standards requirements, issues, 
implementations and interoperability.  The interoperability testing 
role is quite important because IETF WGs don't always manage to take 
that work on for free yet it's quite important to IETF decisions.

All the information we use to develop standards will be provided on the 
open IETF mailing lists, which is why there will continue to be topic 
overlap -- frequently we'll see issues discussed in CalConnect 
re-raised on the IETF list, and vice versa.  But the standards 
development work certainly doesn't depend on anyone's membership in 
CalConnect.

I hope this helps reduce confusion,

Lisa

On Nov 17, 2005, at 11:02 AM, Linyi Tian wrote:

> Hi, All
>
>      I find the "the calendaring and scheduling consortium" which 
> website is http://www.calconnect.org/. Since it address the same topic 
> with our group, i am confused.
>
> Can anybody tell me that what is the relationship between it and our 
> group?  Is there some overlap between two activities?
>
> Best Regards
> Linyi Tian

---

From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Thu Nov 17 12:28:58 2005

Lisa, thank you for responding to this post.

I'd like to add that there is a fair amount of overlap between those 
involved in CalConnect and those involved in the calendaring WGs and 
activities in the IETF - both in the sense of individuals and of 
organizations. 

Calconnect was formed to help move calendaring forward into the 
"mainstream of computing".  We certainly do generate requirements, 
issues, use cases, etc. to assist the standards developers in how the 
standards evolve.  As Lisa said, we offer interoperability testing 
between implementations, and against the standards/specifications. And 
we have a goal to promote interoperable calendaring both in the IT 
community and to the technology-using world at large.

The membership is made up of vendors large and small, open source 
organizations, major academic institutions, etc., and CalConnect 
functions as a partnership between all of us to jointly work to further 
interoperable calendaring and scheduling.

Dave Thewlis
Executive Director

Lisa Dusseault wrote:

> Hello Linyi Tian,
>
> The CalConnect consortium is definitely working on very related 
> topics, and there is also overlap in discussions, but the work is done 
> together with the IETF, rather than in competition.   The CalConnect 
> consortium has no plans to develop standards as the IETF WGs do, but 
> instead to gather information about standards requirements, issues, 
> All the information we use to develop standards will be provided on 
> the open IETF mailing lists, which is why there will continue to be 
> topic overlap -- frequently we'll see issues discussed in CalConnect 
>> website is http://www.calconnect.org/. Since it address the same 
>> topic with our group, i am confused.
>>

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) ? +1 707 498 2238 (mobile)
http://www.calconnect.org ? [email-masked] 
<mailto:[email-masked]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051117/0f3d8a72/attachment.html

Date: Thu, 17 Nov 2005 12:28:50 -0800
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Confusion
Cc: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------020107010106050407090102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Lisa, thank you for responding to this post.

I'd like to add that there is a fair amount of overlap between those 
involved in CalConnect and those involved in the calendaring WGs and 
activities in the IETF - both in the sense of individuals and of 
organizations. 

Calconnect was formed to help move calendaring forward into the 
"mainstream of computing".  We certainly do generate requirements, 
issues, use cases, etc. to assist the standards developers in how the 
standards evolve.  As Lisa said, we offer interoperability testing 
between implementations, and against the standards/specifications. And 
we have a goal to promote interoperable calendaring both in the IT 
community and to the technology-using world at large.

The membership is made up of vendors large and small, open source 
organizations, major academic institutions, etc., and CalConnect 
functions as a partnership between all of us to jointly work to further 
interoperable calendaring and scheduling.

Dave Thewlis
Executive Director

Lisa Dusseault wrote:

> Hello Linyi Tian,
>
> The CalConnect consortium is definitely working on very related 
> topics, and there is also overlap in discussions, but the work is done 
> together with the IETF, rather than in competition.   The CalConnect 
> consortium has no plans to develop standards as the IETF WGs do, but 
> instead to gather information about standards requirements, issues, 
> All the information we use to develop standards will be provided on 
> the open IETF mailing lists, which is why there will continue to be 
> topic overlap -- frequently we'll see issues discussed in CalConnect 
>> website is http://www.calconnect.org/. Since it address the same 
>> topic with our group, i am confused.
>>

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

--------------020107010106050407090102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Lisa, thank you for responding to this post.<br>
<br>
I'd like to add that there is a fair amount of overlap between those
involved in CalConnect and those involved in the calendaring WGs and
activities in the IETF - both in the sense of individuals and of
organizations.&nbsp; <br>
<br>
Calconnect was formed to help move calendaring forward into the
"mainstream of computing".&nbsp; We certainly do generate requirements,
issues, use cases, etc. to assist the standards developers in how the
standards evolve.&nbsp; As Lisa said, we offer interoperability testing
between implementations, and against the standards/specifications. And
we have a goal to promote interoperable calendaring both in the IT
community and to the technology-using world at large. <br>
<br>
The membership is made up of vendors large and small, open source
organizations, major academic institutions, etc., and CalConnect
functions as a partnership between all of us to jointly work to further
interoperable calendaring and scheduling.<br>
<br>
Dave Thewlis<br>
Executive Director<br>
<br>
Lisa Dusseault wrote:
<blockquote cite="[email-masked]"
 type="cite">Hello Linyi Tian,
  <br>
  <br>
The CalConnect consortium is definitely working on very related topics,
and there is also overlap in discussions, but the work is done together
with the IETF, rather than in competition.&nbsp;&nbsp; The CalConnect consortium
has no plans to develop standards as the IETF WGs do, but instead to
gather information about standards requirements, issues,
implementations and interoperability.&nbsp; The interoperability testing
role is quite important because IETF WGs don't always manage to take
that work on for free yet it's quite important to IETF decisions.
  <br>
  <br>
All the information we use to develop standards will be provided on the
open IETF mailing lists, which is why there will continue to be topic
overlap -- frequently we'll see issues discussed in CalConnect
re-raised on the IETF list, and vice versa.&nbsp; But the standards
development work certainly doesn't depend on anyone's membership in
CalConnect.
  <br>
  <br>
I hope this helps reduce confusion,
  <br>
  <br>
Lisa
  <br>
  <br>
On Nov 17, 2005, at 11:02 AM, Linyi Tian wrote:
  <br>
  <br>
  <blockquote type="cite">Hi, All
    <br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp; I find the "the calendaring and scheduling consortium" which
website is <a class="moz-txt-link-freetext" href="http://www.calconnect.org/">http://www.calconnect.org/</a>. Since it address the same topic
with our group, i am confused.
    <br>
    <br>
Can anybody tell me that what is the relationship between it and our
group?&nbsp; Is there some overlap between two activities?
    <br>
    <br>
Best Regards
    <br>
Linyi Tian
    <br>
Huawei Technologies Co., Ltd
    <br>
    <br>
    <br>
----- Original Message -----
    <br>
From: "Preston Stephenson" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
    <br>
To: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
    <br>
Sent: Thursday, November 17, 2005 7:00 PM
    <br>
Subject: [Ietf-calsify] Clarification on section 6 iCalendar objects
indraft-cstoner-rfc2445bis-00
    <br>
    <br>
    <br>
    <blockquote type="cite">Can you give an example of what it means to
have multiple iCalendar
      <br>
objects?
      <br>
      <br>
Is section 4.4 Multiple Similar Components in
      <br>
draft-ietf-calsify-rfc2447bis-00.txt in
      <br>
compliance or not?
      <br>
      <br>
Thanks.
      <br>
Preston
      <br>
      <br>
_______________________________________________
      <br>
Ietf-calsify mailing list
      <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
      <br>
<a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a>
      <br>
    </blockquote>
_______________________________________________
    <br>
Ietf-calsify mailing list
    <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
<a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a>
    <br>
  </blockquote>
  <br>
_______________________________________________
  <br>
Ietf-calsify mailing list
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
  <br>
<a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a>
  <br>
  <br>
  <br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------020107010106050407090102--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Confusion
Date: Thu, 17 Nov 2005 11:41:42 -0800
To: Linyi Tian <[email-masked]>
Cc: [email-masked]

Hello Linyi Tian,

Lisa

>> draft-ietf-calsify-rfc2447bis-00.txt in

Date: Thu, 17 Nov 2005 19:02:42 +0000
From: Linyi Tian <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Confusion

Hi, All

Best Regards
Linyi Tian

----- Original Message ----- 
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 17, 2005 7:00 PM
Subject: [Ietf-calsify] Clarification on section 6 iCalendar objects indraft-cstoner-rfc2445bis-00

> draft-ietf-calsify-rfc2447bis-00.txt in

Date: Thu, 17 Nov 2005 12:00:23 -0700
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-calsify] Clarification on section 6 iCalendar objects in draft-cstoner-rfc2445bis-00

Thanks.
Preston

Date: Thu, 17 Nov 2005 11:09:46 -0700
From: "Preston Stephenson" <[email-masked]>
To: "Reinhold Kainhofer" <[email-masked]>, <[email-masked]>
Subject: Re: [Ietf-calsify] rrule question from draft-cstoner-rfc2445bis-00

I don't want to belabor the point.
I just want to make a couple of observations to see if I understand.
the problem from my point of view.

In our mail system, when a recurrence set is delivered,
we create all of the instances. We don't have one master
appointment and generate the instance on the day of the recurrence.
The start and end time will already be adjusted to be for the first
Monday of the month of each occurrence, then stored as Sunday 22:30
UTC.
This is the way that we will need to work for the time being.

The server stores start and end time in UTC.
It up to the client to adjust the time when it displays one of the
appointments
to the user.

I guess I can't see how the time stored on Sunday 22:30 UTC will not
be displayed by the client as the first Monday of the month 00:30
CEST.

Thanks.
Preston

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thursday 17 November 2005 18:09, Preston Stephenson wrote:
> > In section 8.3.5  Recurrence Rule, it states:
> >                                                            When
used
> > with a recurrence rule,
> >    the "DTSTART" and "DTEND" properties MUST be specified in
local
> > time
> >    and the appropriate set of "VTIMEZONE" calendar components
MUST
> > be
> >    included.
> >
> > I understand the MUST including the VTIMEZONE, but why is local
time
> > required. Why can't it be UTC time also?
> 
> Because Recurrence rules are highly time-zone dependent.
> E.g. take an event that recurs very monday at 0:30 Central European
Summer 
> Time (UTC+2). If you shift the times to UTC, the event recurs at
22:30 every 
> SUNDAY in UTC.
> 
> For weekly recurrences that RRULE might be adjusted to UTC, but
e.g. if you 
> have a recurrence every first monday of the month at 0:30 CEST, you
can't 
> express this in UTC any more at all (because the sunday before the
first 
> monday of a month is not necessarily the first sunday of the
month).
> Cheers,
> Reinhol
> - -- 
> -
------------------------------------------------------------------
> Reinhold Kainhofer, Vienna University of Technology, Austria
> email: [email-masked], http://reinhold.kainhofer.com/ 
>  * Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at/ 
>  * K Desktop Environment, http://www.kde.org, KOrganizer
maintainer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> 
> iD8DBQFDfLu6TqjEwhXvPN0RAu01AKDIrRSebfNHpz/UVISom42YxrGP+gCfZQbl
> QmUAKqU4A3kNzlFSMla07Qw=
> =gfQu
> -----END PGP SIGNATURE-----

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] rrule question from draft-cstoner-rfc2445bis-00
Date: Thu, 17 Nov 2005 18:19:47 +0100

On Thursday 17 November 2005 18:09, Preston Stephenson wrote:
> In section 8.3.5  Recurrence Rule, it states:
>                                                            When used
> with a recurrence rule,
>    the "DTSTART" and "DTEND" properties MUST be specified in local
> time
>    and the appropriate set of "VTIMEZONE" calendar components MUST
> be
>    included.
>
> I understand the MUST including the VTIMEZONE, but why is local time
> required. Why can't it be UTC time also?

Because Recurrence rules are highly time-zone dependent.
E.g. take an event that recurs very monday at 0:30 Central European Summer 
Time (UTC+2). If you shift the times to UTC, the event recurs at 22:30 every 
SUNDAY in UTC.

For weekly recurrences that RRULE might be adjusted to UTC, but e.g. if you 
have a recurrence every first monday of the month at 0:30 CEST, you can't 
express this in UTC any more at all (because the sunday before the first 
monday of a month is not necessarily the first sunday of the month).

Cheers,
Reinhol

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

Date: Thu, 17 Nov 2005 10:09:33 -0700
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-calsify] rrule question from draft-cstoner-rfc2445bis-00

In section 8.3.5  Recurrence Rule, it states:
                                                           When used
with a recurrence rule,
   the "DTSTART" and "DTEND" properties MUST be specified in local
time
   and the appropriate set of "VTIMEZONE" calendar components MUST
be
   included.

I understand the MUST including the VTIMEZONE, but why is local time
required. Why can't it be UTC time also?

Thanks.
Preston

Subject: Re: [Ietf-calsify] DTEND clarification in	draft-ietf-calsify-rfc2445bis-00.txt
To: "Preston Stephenson" <[email-masked]>
Date: Thu, 17 Nov 2005 11:38:07 -0500
From: "Robert Ransdell" <[email-masked]>
Cc: [email-masked], [email-masked]

My current thinking for Notes is as follows:

When there is no DTEND
     DTSTART is date   --- all day event
     DTSTART has a time component -- treat as alarm -- no busy time

             "Preston                                                      
             Stephenson"                                                   
             <[email-masked]                                          To 
             ovell.com>                <[email-masked]>    
             Sent by:                                                   cc 
             ietf-calsify-boun                                             
             ces@osafoundation                                     Subject 
             .org                      [Ietf-calsify] DTEND clarification  
                                       in                                  
                                       draft-ietf-calsify-rfc2445bis-00.tx 
             11/17/2005 11:31          t                                   
             AM                                                            

In section 7.1 Event Component, it states:
  The "DTEND" property for a "VEVENT" calendar component specifies
the non-inclusive end of the event.

In section 7.4  Free/Busy Component, it states:
  the "DTSTART" and "DTEND" properties specify an inclusive time
window
  that surrounds the busy time information;

It would seem that this implies DTEND is inclusive not
non-inclusive.
Isn't DTEND non-inclusive in this case?

In section 8.2.15.2  Date/Time End, it states:
   Description: Within the "VEVENT" calendar component, this
property
   defines the date and time by which the event ends.  The value MUST
be
   later in time than the value of the "DTSTART" property.

but in section 7.1.  Event Component it states:
   For cases where a "VEVENT" calendar component
   specifies a "DTSTART" property with a DATE-TIME data type but no
   "DTEND" property, the event ends on the same calendar date and
time
   of day specified by the "DTSTART" property.

and also section 10.  Recommended Practices it states:
   2.  A calendar entry with a "DTSTART" property but no "DTEND"
   property does not take up any time.  It is intended to represent
an
   event that is associated with a given calendar date and time of
day,
   such as an anniversary.  Since the event does not take up any
time,
   it MUST NOT be used to record busy time no matter what the value
for
   the "TRANSP" property.

If not having a DTEND, it is defined to be the same as DTSTART,
why can't DTEND be defined to be the same as DTEND?

Or is it a matter of clarifying that you either have a DTEND
or you can't have a DTEND, if DTEND is the same as DTSTART?

Just my two bits.
Thanks.
Preston

Date: Thu, 17 Nov 2005 09:37:46 -0700
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-calsify] DTEND clarification in draft-ietf-calsify-rfc2445bis-00.txt

In section 7.1 Event Component, it states:
  The "DTEND" property for a "VEVENT" calendar component specifies
the non-inclusive end of the event.

In section 7.4  Free/Busy Component, it states:
  the "DTSTART" and "DTEND" properties specify an inclusive time
window
  that surrounds the busy time information;

It would seem that this implies DTEND is inclusive not
non-inclusive.
Isn't DTEND non-inclusive in this case?

In section 8.2.15.2  Date/Time End, it states:
   Description: Within the "VEVENT" calendar component, this
property
   defines the date and time by which the event ends.  The value MUST
be
   later in time than the value of the "DTSTART" property.

but in section 7.1.  Event Component it states:
   For cases where a "VEVENT" calendar component 
   specifies a "DTSTART" property with a DATE-TIME data type but no
   "DTEND" property, the event ends on the same calendar date and
time
   of day specified by the "DTSTART" property.

and also section 10.  Recommended Practices it states:
   2.  A calendar entry with a "DTSTART" property but no "DTEND"
   property does not take up any time.  It is intended to represent
an
   event that is associated with a given calendar date and time of
day,
   such as an anniversary.  Since the event does not take up any
time,
   it MUST NOT be used to record busy time no matter what the value
for
   the "TRANSP" property.

If not having a DTEND, it is defined to be the same as DTSTART,
why can't DTEND be defined to be the same as DTEND?

Or is it a matter of clarifying that you either have a DTEND
or you can't have a DTEND, if DTEND is the same as DTSTART?

Just my two bits.
Thanks.
Preston

Date: Tue, 15 Nov 2005 21:31:44 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] variations and options
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070702030607000909030301
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Cyrus Daboo wrote:
> Hi Dave,
> 
> --On November 15, 2005 2:52:10 PM -0800 Dave Crocker <[email-masked]> 
> wrote:
> 
>> these statements raise such a large red flag with me, i feel compelled to
>> bother the list about it. especially since this issue has struck me as
>> being a chronic issue with the calendaring work.
>>
>> the more variations and options an Internet specification has, the higher
>> the barrier to implementation and interoperability and, therefore, to 
>> use.
>>
>> why is that not a concern here?
> 
> 
> I have to say that I am concerned about all the options and requirements 
> in the iTIP document, and I think it would make sense to try and do 
> something about that. One solution is to only document what is different 
> from the base iCal requirements, rather than repeating those in many cases.

The syntax tables in iTIP along with the text description describe
procedures as well as content. So even if the 'unordered" ABNF
extension were added that you proposed, I still think it would be very
difficult to document iTIP in ABNF.

So I think that your proposal would fix iCal ABNF, I do not see
how it will it could help iTIP syntax tables. Because the iTIP
syntax tables describe when to include the iCal ABNF optional
elements.

-- 

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

               We Do Standards - You Need Standards

--------------ms070702030607000909030301
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070702030607000909030301--

Date: Tue, 15 Nov 2005 21:27:23 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Question about attachment
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010703000506080802070607
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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.

> 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:

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

               We Do Standards - You Need Standards

--------------ms010703000506080802070607
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010703000506080802070607--

Date: Tue, 15 Nov 2005 22:29:14 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Ietf-calsify] variations and options

Hi Dave,

--On November 15, 2005 2:52:10 PM -0800 Dave Crocker <[email-masked]> 
wrote:

> these statements raise such a large red flag with me, i feel compelled to
> bother the list about it. especially since this issue has struck me as
> being a chronic issue with the calendaring work.
>
> the more variations and options an Internet specification has, the higher
> the barrier to implementation and interoperability and, therefore, to use.
>
> why is that not a concern here?

I have to say that I am concerned about all the options and requirements in 
the iTIP document, and I think it would make sense to try and do something 
about that. One solution is to only document what is different from the 
base iCal requirements, rather than repeating those in many cases.

That said I do want to comment on one issue with ABNF and iCalendar. 
Currently 2445 uses what I call a pseudo-ABNF to describe the syntax for 
components. Its an ABNF like syntax that uses interspersed comments to 
define the restrictions, e.g.:

     eventprop  = *(

                ; the following are optional,
                ; but MUST NOT occur more than once

                class / created / description / dtstart / geo /
                last-mod / location / organizer / priority /
                dtstamp / seq / status / summary / transp /
                uid / url / recurid /

                ; either 'dtend' or 'duration' may appear in
                ; a 'eventprop', but 'dtend' and 'duration'
                ; MUST NOT occur in the same 'eventprop'

                dtend / duration /

                ; the following are optional,
                ; and MAY occur more than once

                attach / attendee / categories / comment /
                contact / exdate / exrule / rstatus / related /
                resources / rdate / rrule / x-prop

                )

I would much rather see the restrictions spelled out explicitly in ABNF (I 
guess I've spent too much time with protocols that do use ABNF that way).

The problem is that ABNF is missing a construct that iCalendar needs: 
namely an 'unordered list' construct that would allow the enclosed elements 
to appear in any order within the list, though with the prescribed 
restrictions on the number of times they may appear in the list.

If we assume that curly braces were used to indicate such a construct, then 
the example above would become:

     eventprop  = {

                ; the following are optional,
                ; but MUST NOT occur more than once

                *1class *1created *1description *1dtstart *1geo
                *1last-mod *1location *1organizer *1priority
                *1dtstamp *1seq *1status *1summary *1transp
                *1uid *1url *1recurid

                ; either 'dtend' or 'duration' may appear in
                ; a 'eventprop', but 'dtend' and 'duration'
                ; MUST NOT occur in the same 'eventprop'

                *1(dtend / duration)

                ; the following are optional,
                ; and MAY occur more than once

                *attach *attendee *categories *comment
                *contact *exdate *exrule *rstatus *related
                *resources *rdate *rrule *x-prop

                }

An ABNF syntax checker that understood the new construct would be able to 
verify an  the syntax of an eventprop element without having to understand 
the comments.

Do you think there is any need for such an extension to ABNF?

There are other places where such a construct might be useful. For example, 
RFC2822 Section 3.6 has a table that is very similar to the ones in iTIP. 
With a new construct it ought to be possible to express that in ABNF too.

-- 
Cyrus Daboo

From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Subject: Re: [Ietf-calsify] variations and options
Date: Tue, 15 Nov 2005 17:07:00 -0800
To: [email-masked]
Cc: [email-masked]

On Nov 15, 2005, at 2:52 PM, Dave Crocker wrote:

>
>
>> With all of the variations and options available in iTIP
>> the ABNF would be almost impossible to specify. ...
>> Trying to specify all of the iTIP rules in ABNF would create
>> a huge ABNF syntax table that would be difficult to verify
>> as accurate.
>
>
> Folks,
>
> oh boy.
>
> these statements raise such a large red flag with me, i feel compelled=20=

> to bother the list about it. especially since this issue has struck me=20=

> as being a chronic issue with the calendaring work.
>
> the more variations and options an Internet specification has, the=20
> higher the barrier to implementation and interoperability and,=20
> therefore, to use.
>
> why is that not a concern here?

+1

Well put Dave.

Thanks,

Tantek

--
Tantek =C7elik
Chief Technologist, Technorati, Inc.

Date: Tue, 15 Nov 2005 14:52:10 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: [Ietf-calsify] variations and options
Reply-To: [email-masked]

> With all of the variations and options available in iTIP
> the ABNF would be almost impossible to specify. ...
> Trying to specify all of the iTIP rules in ABNF would create
> a huge ABNF syntax table that would be difficult to verify
> as accurate.

Folks,

oh boy.

these statements raise such a large red flag with me, i feel compelled to 
bother the list about it. especially since this issue has struck me as being 
a chronic issue with the calendaring work.

the more variations and options an Internet specification has, the higher 
the barrier to implementation and interoperability and, therefore, to use.

why is that not a concern here?

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

Date: Tue, 15 Nov 2005 12:36:59 -0800
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Registration open for Calconnect Roundtable and Interop Testing Event,  January 2006 - The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------060701080109050707060605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

------------------------------------------------------------------------

* Date:*

	 12/2/2004 07:52

* From:*

	 David C. Thewlis

* To:*

	 "calconnect-l reflector" <[email-masked]>, "ietf-caldav 
reflector" <[email-masked]>, "IETF CALSCH" 
<[email-masked]>, "ietf-calsify reflector" 
<[email-masked]>, "www-rdf-calendar reflector" 
<[email-masked]>

* Copy:*

	 "Robert Tolmach - WellGood Group" <[email-masked]>, "Brian 
Dear" <[email-masked]>, "John Carbone" <[email-masked]>, 
[email-masked], [email-masked]

* Subject:*

	 Call for Participantion -- Second Calconnect Interop - 11-12 January 
2005 - Seattle, Washington

------------------------------------------------------------------------

Received: from psmtp.com (exprod6mx6.postini.com [64.18.1.146]) by 
home.humboldt1.com (8.12.10/8.12.10) with SMTP id iB2Fq3mR014814 for 
<[email-masked]> Thu, 2 Dec 2004 07:52:03 -0800 (PST)
Received: from source ([208.31.106.91]) by exprod6mx6.postini.com 
([64.18.5.10]) with SMTP; Thu, 02 Dec 2004 07:52:02 PST
Received: from aix2.egenconsulting.com (localhost [127.0.0.1]) by 
aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlvWi018040 for 
<[email-masked]> Thu, 2 Dec 2004 10:47:57 -0500
Received: (from majordom@localhost) by aix2.egenconsulting.com 
(8.13.1/8.13.1/Submit) id iB2FlvFI018426 for calconnect-l-list; Thu, 2 
Dec 2004 10:47:57 -0500
X-Authentication-Warning: aix2.egenconsulting.com: majordom set sender 
to [email-masked] using -f
Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net 
[68.230.241.35]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP 
id iB2FlcTM019480; Thu, 2 Dec 2004 10:47:38 -0500
Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net 
(InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id 
<20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23> Thu, 2 Dec 2004 
10:48:33 -0500
Message-ID: <[email-masked]>
References: <[email-masked]>
X-Mailer: Calypso Version 3.30.00.00 (4)
Date: Thu, 02 Dec 2004 07:48:00 -0800
Reply-To: [email-masked]
From: "David C. Thewlis" <[email-masked]>
To: "calconnect-l reflector" <[email-masked]>, "ietf-caldav 
reflector" <[email-masked]>, "IETF CALSCH" 
<[email-masked]>, "ietf-calsify reflector" 
<[email-masked]>, "www-rdf-calendar reflector" 
<[email-masked]>
Cc: "Robert Tolmach - WellGood Group" <[email-masked]>, 
"Brian Dear" <[email-masked]>, "John Carbone" 
<[email-masked]>, [email-masked], [email-masked]
Subject: Call for Participantion -- Second Calconnect Interop - 11-12 
January 2005 - Seattle, Washington
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====_11020024806334=_"
Sender: [email-masked]
Precedence: bulk
X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 
C:98.9754 )
X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c
X-pstn-addresses: from <[email-masked]> forward (user good) 
[2395/93]

/Please note that this announcement is being posted on multiple 
calendaring-related reflectors and to the Calconnect mailing lists to 
ensure as wide a distribution as possible.  Our apologies if you receive 
multiple copies.

/
//*CALCONNECT INTEROP TESTING EVENT -  09-10 January 2006*

*CALCONNECT ROUNDTABLE V - 10-12 January 2006*
 *
*
 
CalConnect - The Calendaring and Scheduling Consortium - invites you to 
our January 2006 Roundtable and to the associated Calendaring and 
Scheduling Interop Testing Event, to be held 9-12 January, 2006 in 
Provo, Utah, hosted by Novell, Inc.

_Registration is now open for these events as of 15 November 2005._

In a departure from previous events, the Interop and Roundtable will be 
held serially instead of in parallel, to ensure that Interop 
participants can actively participate in the Roundtable. 

The *Interop* will take place 09-10 January, all day the 9th and until 
lunch on the 10th.  It will offer multiple Interop Testing Scenarios 
including

    * extensive CalDAV testing,
    * RFC (iCalendar, iMIP, iTIP) interoperability and RFC conformance
      testing
    * CALSIFY minimum interoperability testing. 

Participating organizations may choose one or more than one scenario for 
testing -- however these scenarios will be going on simultaneously so 
you will probably need a person for each scenario you participate in. 

Interop participation is _open to all_ interested organizations that 
wish to test calendaring and scheduling implementations, and _is not 
limited to members of the Consortium _(although members receive a 
significant discount on the Interop participation fee).

More information about the Interop is available at 
http://www.calconnect.org/iopjan2006.html. 
<http://www.calconnect.org/iopjan2006.html>

The *Roundtable* will commence after lunch on Tuesday 10 January and run 
through lunch on Thursday 12 January (Roundtable participants are 
invited to lunch on Tuesday prior to the opening of the Roundtable).  It 
will feature Technical Committee meetings, ad hoc meetings, and a full 
Plenary of the Consortium.  You must represent a member of CalConnect to 
attend the Roundtable _unless_ your organization chooses to participate 
as an Observer (a non-member who wishes to attend a Roundtable to 
evaluate participation in the Consortium).

More information about the Roundtable is available at 
http://www.calconnect.org/roundtable5.html. 
<http://www.calconnect.org/roundtable5.html>

*
REGISTRATION FEES

**Interop:* $1500 for Consortium members and $2500 for non-members.  The 
registration fee covers two individuals; additional individuals are $150 
each for members or non-members.  (If you are planning to participate in 
more than one Interop scenario, you may need additional people.)  **
 
*Roundtable:*  $275 per individual until 01 January and $325 
thereafter.  The Roundtable is limited to representatives of Consortium 
members or declared Observers (an non-member that wishes to attend a 
Roundtable to evaluate participation in the Consortium).   /

A combined registration fee for both the Interop and Roundtable is 
available; please see http://www.calconnect.org/iopfees.html. 
<http://www.calconnect.org/iopfees.html>
/ 
*
*
 
*ADDITIONAL DETAILS AND REGISTRATION INFORMATION*

Information on the Roundtable, including logistics, current schedule and 
agenda planning, and registration information is available on the 
Consortium website at http://www.calconnect.org/roundtable5.html.  More 
information on the Interop including logistics, planning, and 
registration information is available on the Consortium website at 
http://www.calconnect.org/iopjan2006.html. 
<http://www.calconnect.org/iopjan2006.html>

You may also go to Consortium site at http://www.calconnect.org and 
select "Coming Events" from the sidebar to find logistics, planning and 
registration information for both the Roundtable and the Interop.

For questions and additional information please contact the Consortium's 
Executive Director, Dave Thewlis, via the contact information listed below.

Space will be limited, so register as soon as possible.

Best Regards,

Dave Thewlis

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile) � +1 415 946 3454 (fax)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

--------------060701080109050707060605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- Inserted by Calypso -->
<table id="_CalyPrintHeader_" style="display: none; color: black;"
 border="0" cellpadding="0" cellspacing="2" rules="none" width="100%">
  <tbody>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Date:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;12/2/2004 07:52<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;From:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;David C. Thewlis<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;To:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Copy:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"Robert Tolmach - WellGood Group" <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Subject:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso --><!-- Inserted by Calypso -->
<table id="_CalyMsgHeader_" style="display: none; color: rgb(0, 0, 0);"
 bgcolor="#c0c0c0" border="1" cellpadding="2" cellspacing="2"
 rules="none" width="100%">
  <tbody>
    <tr bgcolor="#c0c0c0">
      <td><font color="#000000" face="VERDANA,ARIAL,HELVETICA" size="-2">Received:
from psmtp.com (exprod6mx6.postini.com [64.18.1.146]) by
home.humboldt1.com (8.12.10/8.12.10) with SMTP id iB2Fq3mR014814 for <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004 07:52:03 -0800 (PST)<br>
Received: from source ([208.31.106.91]) by exprod6mx6.postini.com
([64.18.5.10]) with SMTP; Thu, 02 Dec 2004 07:52:02 PST<br>
Received: from aix2.egenconsulting.com (localhost [127.0.0.1]) by
aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlvWi018040
for <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004
10:47:57 -0500<br>
Received: (from majordom@localhost) by aix2.egenconsulting.com
(8.13.1/8.13.1/Submit) id iB2FlvFI018426 for calconnect-l-list; Thu, 2
Dec 2004 10:47:57 -0500<br>
X-Authentication-Warning: aix2.egenconsulting.com: majordom set sender
to <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>
using -f<br>
Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net
[68.230.241.35]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP
id iB2FlcTM019480; Thu, 2 Dec 2004 10:47:38 -0500<br>
Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net
(InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id
&lt;20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23&gt; Thu, 2 Dec
2004 10:48:33 -0500<br>
Message-ID: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
References: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
X-Mailer: Calypso Version 3.30.00.00 (4)<br>
Date: Thu, 02 Dec 2004 07:48:00 -0800<br>
Reply-To: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
From: "David C. Thewlis" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
To: "calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF
CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
Cc: "Robert Tolmach - WellGood Group" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
Subject: Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
Mime-Version: 1.0<br>
Content-Type: multipart/alternative; boundary="=====_11020024806334=_"<br>
Sender: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
Precedence: bulk<br>
X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624
C:98.9754 )<br>
X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c <br>
X-pstn-addresses: from <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
forward
(user good) [2395/93] <br>
      </font><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso -->
<div><em>Please note that this announcement is being posted on multiple
calendaring-related reflectors and to the Calconnect mailing lists to
ensure as wide a distribution as possible.&nbsp; Our apologies if you
receive multiple copies.<br>
<br>
</em></div>
<div><em></em><strong>CALCONNECT INTEROP TESTING EVENT -&nbsp;
09-10 January 2006</strong><br>
<br>
<strong>CALCONNECT ROUNDTABLE V - 10-12 January 2006</strong><br>
</div>
<div>&nbsp;<strong><br>
</strong></div>
<div>&nbsp;<br>
CalConnect - The Calendaring and Scheduling Consortium - invites you to
our January 2006 Roundtable and to the associated Calendaring and
Scheduling
Interop Testing Event, to be held 9-12 January, 2006 in Provo, Utah,
hosted by Novell, Inc.<br>
<br>
<u>Registration is now open for these events as of 15 November 2005.</u><br>
</div>
<br>
In a departure from previous events, the Interop and Roundtable will be
held serially instead of in parallel, to ensure that Interop
participants can actively participate in the Roundtable.&nbsp; <br>
<br>
The <b>Interop</b> will take place 09-10 January, all day the 9th and
until lunch on the 10th.&nbsp; It will offer
multiple Interop Testing Scenarios including <br>
<ul>
  <li>extensive CalDAV testing, <br>
  </li>
  <li>RFC (iCalendar, iMIP, iTIP) interoperability and RFC conformance
testing</li>
  <li>CALSIFY minimum interoperability testing.&nbsp; <br>
  </li>
</ul>
Participating organizations may choose one or more than one scenario
for testing -- however these scenarios will be going on
simultaneously so you will probably need a person for each scenario you
participate in.&nbsp; <br>
<br>
Interop participation is <u>open to all</u> interested organizations
that wish to test calendaring and scheduling implementations, and <u>is
not limited to members of the Consortium </u>(although members receive
a significant discount on the Interop participation fee). <br>
<br>
More information about the Interop is available at <a
 href="http://www.calconnect.org/iopjan2006.html">http://www.calconnect.org/iopjan2006.html.</a><br>
<br>
The <b>Roundtable</b> will commence after lunch on Tuesday 10 January
and run through lunch on Thursday 12 January (Roundtable participants
are invited to lunch on Tuesday prior to the opening of the
Roundtable).&nbsp; It will feature Technical
Committee meetings, ad hoc meetings, and a full Plenary of the
Consortium.&nbsp; You must represent a member of CalConnect to attend the
Roundtable <u>unless</u> your organization chooses to participate as
an Observer (a non-member who wishes to attend a Roundtable to evaluate
participation in the Consortium).<br>
<br>
More information about the Roundtable is available at <a
 href="http://www.calconnect.org/roundtable5.html">http://www.calconnect.org/roundtable5.html.</a><br>
<br>
<div><strong><br>
REGISTRATION FEES<br>
<br>
</strong><b>Interop:</b> $1500 for Consortium
members and $2500 for non-members.&nbsp; The registration fee covers two
individuals; additional individuals are $150 each for members or
non-members.&nbsp; (If you are planning to participate in more than one
Interop scenario, you may need
additional people.)&nbsp; <strong></strong><br>
&nbsp;<br>
<b>Roundtable:</b>&nbsp; $275 per individual until 01 January and $325
thereafter.&nbsp; The Roundtable is limited to representatives
of Consortium members or declared Observers (an non-member that wishes
to attend a Roundtable to evaluate participation in the Consortium). &nbsp; <i><br>
<br>
A combined registration fee for both the Interop and Roundtable is
available; please see <a href="http://www.calconnect.org/iopfees.html">http://www.calconnect.org/iopfees.html.</a><br>
</i>&nbsp;</div>
<div><b><br>
</b></div>
<div>&nbsp;<br>
</div>
<div><b>ADDITIONAL DETAILS AND REGISTRATION INFORMATION</b><br>
<br>
Information on the Roundtable, including logistics, current
schedule and agenda planning, and registration information is available
on the Consortium website at <a
 href="http://www.calconnect.org/roundtable5.html">http://www.calconnect.org/roundtable5.html</a>.&nbsp;
More information on the Interop including logistics, planning, and
registration information is available on the Consortium website at <a
 href="http://www.calconnect.org/iopjan2006.html">http://www.calconnect.org/iopjan2006.html.</a><br>
<br>
You may also go to Consortium site at <a
 href="http://www.calconnect.org">http://www.calconnect.org</a>
and select "Coming Events" from the sidebar to find logistics,
planning and registration information for both the Roundtable and the
Interop.<br>
</div>
<br>
For questions and additional information please contact the
Consortium's Executive Director, Dave Thewlis, via the contact
information listed below. <br>
<div><br>
Space will be limited, so register as soon as possible. <br>
<br>
</div>
<div>Best Regards,</div>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile) &middot; +1 415 946 3454
(fax)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a>
&middot; <a href="mailto:[email-masked]">[email-masked]</a><br>
<br>
</div>
</body>
</html>

--------------060701080109050707060605--

Date: Mon, 14 Nov 2005 22:00:47 +0200
From: Jyrki Hokkanen <[email-masked]>
To: ext Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Question about attachment
Cc: [email-masked]

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 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
>
>[email-masked] wrote:
>  
>
>>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. 
>>-------------------------------------------------- 
>>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! 
>>*************************************************************************************************** 
>>　　　　　　 
>>
>>
>>　　　　　　　　　　 　 
>>　　　　　　　　　　　　　　 
>>
>>
>>
>>

Date: Fri, 11 Nov 2005 23:14:35 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Question about attachment
Cc: [email-masked]

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

[email-masked] wrote:
> 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 
> $B!!(BI am a new comer. I have one question about attachment in iCalendar. Since attachment can be binary and external link in iCalendar.$B!!(BIs 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. 
> -------------------------------------------------- 
> 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! 
> *************************************************************************************************** 
> $B!!!!!!!!!!!!(B 
> 
> 
> $B!!!!!!!!!!!!!!!!!!!!(B $B!!(B 
> $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B 
> 
> 
> 
> 

Date: Fri, 11 Nov 2005 17:42:15 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: Question about attachment
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080800090907060102020408
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Michiel van Leeuwen wrote:

 > Doug Royer wrote:
 >
 >>
 >> 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.
 >
 >
 >
 > 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.

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.

-- 

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

               We Do Standards - You Need Standards

--------------ms080800090907060102020408
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080800090907060102020408--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Fri, 11 Nov 2005 22:54:40 +0100
Lines: 19
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: Question about attachment

Doug Royer wrote:
> 
> 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.

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

Date: Fri, 11 Nov 2005 13:09:50 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Question about attachment
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms060008050108090907020601
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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...

Aki Niemi wrote:
> 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).

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.

> 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.

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

> So after the import, Bob has problems knowing which one of the 
> 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.

-- 

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

               We Do Standards - You Need Standards

--------------ms060008050108090907020601
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060008050108090907020601--

Date: Fri, 11 Nov 2005 13:18:01 +0200
From: Aki Niemi <[email-masked]>
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Question about attachment

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:
> 
> 
>  > 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.
> 
> 
> ------------------------------------------------------------------------
> 

From: Helge Hess <[email-masked]>
Subject: Re: [Fwd: Re: [Ietf-calsify] Question about attachment]
Date: Thu, 10 Nov 2005 17:35:09 +0100
To: Calsify <[email-masked]>

On 10. Nov 2005, at 17:21 Uhr, [email-masked] wrote:
> When sending meeting invitations through email, it is nice to send in
> several alternatives  (text/calendar and text/html) so that recipients
> viewing the email with software not rendering the iCalendar can  
> still see
> the meeting information.

Outlook only detects iMIP mails when the top-level content type is  
text/calendar, so in practice multipart is often a no go :-|

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Subject: Re: [Fwd: Re: [Ietf-calsify] Question about attachment]
To: Calsify <[email-masked]>
Cc: Calsify <[email-masked]>, [email-masked]
Date: Thu, 10 Nov 2005 11:21:29 -0500
From: [email-masked]

When sending meeting invitations through email, it is nice to send in
several alternatives  (text/calendar and text/html) so that recipients
viewing the email with software not rendering the iCalendar can still see
the meeting information.  Part of the critical information would be any
attachments.   That said, the preferred MIME for the email would have the
attachment as a mulipart/mixed and have it referenced in the html and the
iCalendar with its CID.

             Doug Royer                                                    
             <[email-masked]>                                              
             Sent by:                                                   To 
             ietf-calsify-boun         Calsify                             
             ces@osafoundation         <[email-masked]>    
             .org                                                       cc 
                                                                           
                                                                   Subject 
             11/10/2005 03:51          [Fwd: Re: [Ietf-calsify] Question   
             AM                        about attachment]                   

             Please respond to                                             
                  Calsify                                                  
             <ietf-calsify@osa                                             
              foundation.org>                                              

The other problem is that sometimes there is no place to
publish the attachment. Or perhaps for security reasons
you only want to iMIP the calendar appointment and its
attachment.

There is really no way to determine in advance why
the user elected to inline the attachment.

Lissa Dusseault wrote:

  > 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?

--

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

               We Do Standards - You Need Standards

Date: Thu, 10 Nov 2005 01:51:42 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: [Fwd: Re: [Ietf-calsify] Question about attachment]
Reply-To: Calsify <[email-masked]>

The other problem is that sometimes there is no place to
publish the attachment. Or perhaps for security reasons
you only want to iMIP the calendar appointment and its
attachment.

There is really no way to determine in advance why
the user elected to inline the attachment.

Lissa Dusseault wrote:

  > 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?

-- 

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

               We Do Standards - You Need Standards

Date: Thu, 10 Nov 2005 01:50:18 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: RE: [Ietf-calsify] Question about attachment
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms000001020309060008090100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 > 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

--------------ms000001020309060008090100
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000001020309060008090100--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Question about attachment
Date: Thu, 10 Nov 2005 09:15:36 +0200
From: <[email-masked]>
To: <[email-masked]>

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.=20

Thanks!=20
Lisa Dusseault=20

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

Hi, All=20
=1B$B!!=1B(JI am a new comer. I have one question about attachment in =
iCalendar. Since attachment can be binary and external link in =
iCalendar.=1B$B!!=1B(JIs 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?=20
Best Regards=20
Linyi Tian=20
Application & Software Dept.=20
Huawei Technologies Co., Ltd=20
--------------------------------------------------=20
Office: +86-755-28974272=20
Mobile: +86-13923718857=20
Fax: +86-755-28976100=20
Email: [email-masked]=20
--------------------------------------------------=20

*************************************************************************=
**************************=20
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!=20
*************************************************************************=
**************************=20
=1B$B!!!!!!!!!!!!=1B(J=20

=1B$B!!!!!!!!!!!!!!!!!!!!=1B(J =1B$B!!=1B(J=20
=1B$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!=1B(J=20

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

Date: Wed, 09 Nov 2005 21:25:00 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] The 4.4 example is not valid.
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms020901080604080503010900
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The iCal object shown in 4.4 of -08 is no a valid
iCal object.

Two VEVENTs an not have the same UID. That is what
METHOD:ADD is for.

-- 

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

               We Do Standards - You Need Standards

--------------ms020901080604080503010900
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020901080604080503010900--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Question about attachment
Date: Wed, 9 Nov 2005 18:13:14 -0800
To: LinyiTian <[email-masked]>
Cc: shenhai <[email-masked]>, kangjiao <[email-masked]>, IETF-iCalendar <[email-masked]>

--Apple-Mail-4-810255527
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=ISO-2022-JP;
	delsp=yes;
	format=flowed

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
>  
> $B!!(BI am a new comer. I have one question about attachment in iCalendar.  
> Since attachment can be binary and external link in iCalendar.$B!!(BIs  
> 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.
> --------------------------------------------------
> 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!
> *********************************************************************** 
> ****************************
>  
>  $B!!!!!!!!!!!!(B          
>                        
>
> $B!!!!!!!!!!!!!!!!!!!!(B  $B!!(B   
> $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B
>
>
>

--Apple-Mail-4-810255527
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=ISO-2022-JP

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:

<excerpt><fontfamily><param>Arial</param><smaller>Hi, All</smaller></fontfamily>

<fontfamily><param>Hiragino Kaku Gothic Pro</param><smaller>$B!!(B</smaller></fontfamily><fontfamily><param>Arial</param><smaller>I
am a new comer. I have one question about attachment in iCalendar.
Since attachment can be binary and external link in
iCalendar.</smaller></fontfamily><fontfamily><param>Hiragino Kaku Gothic Pro</param><smaller>$B!!(B</smaller></fontfamily><fontfamily><param>Arial</param><smaller>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?</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Best Regards     </smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Linyi Tian </smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Application & Software Dept.</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Huawei Technologies Co., Ltd</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>--------------------------------------------------</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Office:  +86-755-28974272</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Mobile: +86-13923718857</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Fax:     +86-755-28976100</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Email:
<color><param>0000,0000,EEEE</param>[email-masked]</color></smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>--------------------------------------------------</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>***************************************************************************************************</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>  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!</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>***************************************************************************************************</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller> </smaller></fontfamily><fontfamily><param>Hiragino Kaku Gothic Pro</param><smaller>$B!!!!!!!!!!!!(B          

$B!!!!!!!!!!!!!!!!!!!!(B </smaller></fontfamily><fontfamily><param>Arial</param><smaller>
</smaller></fontfamily><fontfamily><param>Hiragino Kaku Gothic Pro</param><smaller>$B!!(B   

$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B

</smaller></fontfamily>_______________________________________________

</excerpt>
--Apple-Mail-4-810255527--

Date: Tue, 08 Nov 2005 14:29:31 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] METHOD in iCalendar object
Reply-To: Calsify <[email-masked]>

On the Jabber room, Cyrus quoted Benard as saying:

> Bernard: if no "method", then you're just sending an object
> and not doing iMIP

Not quite: If no METHOD property is supplied your not doing
iTIP.

-- 

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

               We Do Standards - You Need Standards

Date: Tue, 08 Nov 2005 14:27:40 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] MIME type in iCal objects

This is a cryptographically signed message in MIME format.

--------------ms070501080605030206030707
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

In the Jabber room, Cyrus said:

 > cyrus_daboo: The method= MIME parameter is simply a hint to the
 > client about what is inside.

And I think this is busted. I think the METHOD needs to be
a 'MAY'. And when not supplied, means that more than
one METHOD is included for complex entries like
this one:

	BEGIN:VCALENDAR
	METHOD:PUBLISH               < -------
	BEGIN:VEVENT
	UID: uid-1
	SEQUENCE:0
	DTSTART: 2005=NOV-01 1pm
	DURATION: 1 hour
	LOCATION: room A
	RRULE:FREQ=WEEKLY;COUNT=52
	...
	EXDATE: 22-NOV-01 1pm
	END:VEVENT
	END:VCALENDAR
	
	BEGIN:VCALENDAR
	METHOD:ADD                   < ------
	BEGIN:VEVENT
	UID: uid-1
	SEQUENCE:1
	DTSTART: 22-NOV-01 1pm
	LOCATION: room B
	...
	END:VEVENT
	END:VCALENDAR

With method in the MIME header, how can you have two or more
distinct METHOD values? This was pointed out just before
2445 was pubished. And never resolved.

-- 

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

               We Do Standards - You Need Standards

--------------ms070501080605030206030707
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070501080605030206030707--

Date: Tue, 08 Nov 2005 14:11:29 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] ABNF vs tables.
Reply-To: [email-masked]

On the Jabber room, Cyrus said:
 >  1. Format of abnf vs tables. In 2445 pseudo abnf is used to describe
 > which components are allowed etc.
 >
 > In iTIP tables are used to describe the same thing.
 >
 > We should ideally standardise on one format or the other. What do
 > people think?

With all of the variations and options available in iTIP
the ABNF would be almost impossible to specify. A generic
ABNF is in iCal. The details of how and when to use specific
properties and parameters is described in iTIP tables.

Trying to specify all of the iTIP rules in ABNF would create
a huge ABNF syntax table that would be difficult to verify
as accurate.

It what is needed is clarification and reduction of iTIP entries
in things likes COUNTER. Many optional properties are included
with no guidline when they would be included or when they
should be excluded.

-- 

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

               We Do Standards - You Need Standards

Date: Mon, 07 Nov 2005 18:16:34 +0800
From: LinyiTian <[email-masked]>
To: IETF-iCalendar <[email-masked]>
Cc: shenhai <[email-masked]>, kangjiao <[email-masked]>
Subject: [Ietf-calsify] Question about attachment

This is a multi-part message in MIME format.

--Boundary_(ID_YUCfcxaRMOEI5Hi8Jk8YGw)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

--Boundary_(ID_YUCfcxaRMOEI5Hi8Jk8YGw)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: base64

--Boundary_(ID_YUCfcxaRMOEI5Hi8Jk8YGw)--