Subject: [Ietf-calsify] UTC

From: TimHare at comcast.net ([email-masked])
Date: Wed Sep 15 21:11:50 2004

Most of the "travelling" scenarios that have been posted as arguments 
against UTC storage, seem to me to be workable with the date/time stored in 
UTC but the timezone of the event noted as a property, as someone 
suggested, allowing a client to look up the timezone and do the calculation 
if necessary.

Adding TZID to an event with a UTC time code, however,  is just the 
converse of using the ISO 8601 date/time format _with_ the timezone 
designator. 2004-09-15T23:59:00-0500  is basically the same as saying 
20040916T045900Z;TZID=EST isn't it?  RFC2445 section 4.3.5 specifically 
says not to use this format, although I don't know the reasoning behind 
that.  In any event, rather than having the client retain a lookup table to 
convert EST to "subtract five hours from Zulu", why don't we just send the 
offset value along with the date/time value. This has the added advantage 
of allowing implementors to borrow code from already working e-mail 
implementations, since it is the format used in mail headers. I'm sure 
there are disadvantages I've overlooked, but it does seem like an option 
(to me).

And for the record or consensus vote, I'm more comfortable with everything 
in UTC. I believe the clients can deal with it. Possibly they already do - 
most communicating clients using cell phone technology might record 
messages in local time, but if the billing folks aren't in the same time 
zone, some conversion must take place to log the call for billing purposes, 
I would think?

Tim Hare
Interested Bystander, Non-Inc.

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Sep 16 07:22:18 2004

Hi [email-masked],

--On Thursday, September 16, 2004 12:10 AM -0400 [email-masked] wrote:

> 20040916T045900Z;TZID=EST isn't it?

-0500 can map to several different timezones with different daylight 
savings rules, so it is not enough to just specify the numeric offset if 
the event is recurring and might span a dst change or there is any 
likelyhood the event could be moved across a dst change.

-- 
Cyrus Daboo

---

From: TimHare at comcast.net ([email-masked])
Date: Thu Sep 16 19:06:17 2004

To me, saying UTC minus 5 hours pretty specifically specifies the time 
adjustment - different timezone names might map to the same offset, but 
it's the offset that matters.  The name is merely a way to find the offset 
when you need to do the calculation. That said, I still think it is simpler 
to use UTC for storing and exchanging everything; though some property of 
where the event actual takes place is needed to map that into local time.

Tim Hare

---

From: harrie at inet.it (Harrie Hazewinkel)
Date: Fri Sep 17 00:04:36 2004

[email-masked] wrote:
> it's the offset that matters.  The name is merely a way to find the 
> offset when you need to do the calculation. That said, I still think it 
> is simpler to use UTC for storing and exchanging everything; though some 
> property of where the event actual takes place is needed to map that 
> into local time.

While I beleive it may be useful to have the name as the offset
(as mentioned different daylight savings rules), this technology is used 
more and more in small devices like phones and those do (at this moment)
not have huge space to store the 'named' offset. On top of that 
calculating time with the numeric offset is more simple and I believe
more supported.
Therefore, I beleive exchanging UTC is better and one could use the
LOCATION property to map it if a device is able to do that.

Harrie
>> savings rules, so it is not enough to just specify the numeric offset 
>> if the event is recurring and might span a dst change or there is any 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Sun Sep 19 07:56:29 2004

On Sep 17, 2004, at 4:05, [email-masked] wrote:
> adjustment - different timezone names might map to the same offset, 
> but it's the offset that matters.  The name is merely a way to find 
> the offset when you need to do the calculation.

No. One timezone name maps to various timezone offsets. The obvious 
second one, as Cyrus already mentioned, is daylight savings.
If you have a cyclic appointment which happens each monday at 11:00 
CET, this will be 11:00Z+0100 in winter and 11:00+0200 in summer. So 
actually the symbolic name is the important thing and the "calculation" 
we were talking about is not adding the offset, but calculating DSTs.

> That said, I still think it is simpler to use UTC for storing and 
> exchanging everything;

If a timezone name would be the same like an offset, that would be 
true. But a timezone name (unfortunately for us ;-) maps to different 
offsets.
Again: this _only_ matters for cyclic appointments. (well, it would 
also matter for Brazil time, but I consider that too obscure, does any 
other country change DST each year?).

Notably this is not just for summer/winter time, the daylight savings 
are decided by the governments and can (and did!) change over the years 
or when political situations change.

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

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Thu Sep 30 10:17:00 2004

On Sep 19, 2004, at 10:56 AM, Helge Hess wrote:

>> To me, saying UTC minus 5 hours pretty specifically specifies the 
>> time adjustment - different timezone names might map to the same 
>> offset, but it's the offset that matters.  The name is merely a way 
>> to find the offset when you need to do the calculation.
>
> actually the symbolic name is the important thing and the 
> "calculation" we were talking about is not adding the offset, but 
> calculating DSTs.

Once again, most of the complexities come from RRULES.  When you 
enumerate all the events in a set, it's easy to get the time right for 
each.  When you try to say it more succinctly, with a rule, everything 
gets absurdly complex.  If everything "on the wire" was specified as 
sets rather than rules, we wouldn't need time zones on the wire either. 
  -- Nathaniel

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Thu Sep 30 10:29:58 2004

On Sep 30, 2004, at 19:16, Nathaniel Borenstein wrote:
> Once again, most of the complexities come from RRULES.
> When you enumerate all the events in a set, it's easy to get the time 
> right for each.
> When you try to say it more succinctly, with a rule, everything gets 
> absurdly complex.

I think everyone can agree with that.

> If everything "on the wire" was specified as sets rather than rules, 
> we wouldn't need time zones on the wire either.

At the loss of functionality which is widely used, I suppose few will 
agree with removing rrules completely (would be fine for me though).

As mentioned before this issue might be resolved by putting rrules into 
an extension to a core spec, so that we have a base spec which only 
requires UTC which of course would be a huge simplification.

Greets,
   Helge

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Thu Sep 30 10:38:45 2004

Someone could write this up!  Often it takes a solid proposal for 
people to see the full effect of such a major simplification.

Lisa

On Sep 30, 2004, at 10:29 AM, Helge Hess wrote:

> As mentioned before this issue might be resolved by putting rrules 
> into an extension to a core spec, so that we have a base spec which 
> only requires UTC which of course would be a huge simplification.
>
> Greets,
>   Helge
> --

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Sep 30 11:45:20 2004

> only requires UTC which of course would be a huge simplification.

I agree. For protocols like CAP and CalDAV, that works. For iMIP there 
may be
no way in advance to know if the recipient will ignore or understand any 
extensions.

So I think that the base set needs to be 100% compatible at the iMIP level.

Perhaps we need to add an optional property that can be added to iCAL 
objects
that indicate the extensions supported by the sender. Then the recipient
will know how it can reply. And then the recipient also includes this
extension property so then the originator may then track which recipient
supports which features.  Such as:

    EXTENSIONS: XXXX,YYYY,ZZZZ

where XXXX, YYYY, and ZZZZ are RFC numbers that describe extensions.
This would be placed in the VCALENDAR objects. Then the recipient
of the object would know that the sender supports RFC-XXXX, RFC-YYYY,
and RFC-ZZZZ extensions.

Vendor specific extensions could be handled with a vendor specific
property such as X-EXTENSIONS that could follow the vendor specifications.

If the EXTENSIONS property is absent, then the sender only supports
RFC-'calsify-basic' which I think needs to be compatible with iCAL
and would not include the rrule properties.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

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

---

From: TimHare at comcast.net ([email-masked])
Date: Thu Sep 30 20:54:29 2004

I'd hate to give up the idea of some form of recurrence too easily. For the 
most common use cases - like weekly and monthly events - recurrence is a 
convenient and efficient shorthand. Perhaps we can adopt the following 
simplifications:

1. All components exchanged or published use UTC for date/time properties.
2. A new component is defined, VRECUR (or a better name) is defined for use 
only locally, which has simple properties for recurring events.
3. VRECUR does not allow infinite repetition
4. Components have a recurrence ID (RID - something I think was proposed 
before?) which can be null.
4. VRECUR dates and times use floating time to eliminate daylight savings 
time problems.
5. When exchanging VRECUR components, send the VRECUR with RID and 
beginning time converted to UTC, then convert to VEVENT/VTODO/etc. and UTC 
and send those, with the same RID.
6. Recipients can accept and store the VRECUR if capable, and ignore the 
events with that RID, or ignore the VRECUR and accept the events.
7. "Exchanging" also applies to publishing to a file.

This is a minor amount of overhead compared to just exchanging the 
individual events, yet allows both ends to use the more compact way of 
storing the recurring events if desired.  It leaves conversion from UTC to 
local time as a presentation problem. We would still have to define the 
"simple properties" for VRECUR. I think we would need to concentrate on the 
few use cases which are used by the majority of people. There's probably an 
80/20 rule there somewhere. Does anyone have a way to gather statistics on 
recurrence definitions? For example, where I work we use Notes and I'd bet 
80% of recurrence is "weekly".

If this seems like it's not solving the problem or introducing new ones, 
then I'd agree to "just UTC with no RRULEs in the base spec", and putting 
RRULEs elsewhere.

At 02:45 PM 9/30/04, Doug Royer wrote:

>I agree. For protocols like CAP and CalDAV, that works. For iMIP there may be
>Perhaps we need to add an optional property that can be added to iCAL objects

Tim Hare

Date: Thu, 30 Sep 2004 23:50:39 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] UTC

I'd hate to give up the idea of some form of recurrence too easily. For the 
most common use cases - like weekly and monthly events - recurrence is a 
convenient and efficient shorthand. Perhaps we can adopt the following 
simplifications:

1. All components exchanged or published use UTC for date/time properties.
2. A new component is defined, VRECUR (or a better name) is defined for use 
only locally, which has simple properties for recurring events.
3. VRECUR does not allow infinite repetition
4. Components have a recurrence ID (RID - something I think was proposed 
before?) which can be null.
4. VRECUR dates and times use floating time to eliminate daylight savings 
time problems.
5. When exchanging VRECUR components, send the VRECUR with RID and 
beginning time converted to UTC, then convert to VEVENT/VTODO/etc. and UTC 
and send those, with the same RID.
6. Recipients can accept and store the VRECUR if capable, and ignore the 
events with that RID, or ignore the VRECUR and accept the events.
7. "Exchanging" also applies to publishing to a file.

This is a minor amount of overhead compared to just exchanging the 
individual events, yet allows both ends to use the more compact way of 
storing the recurring events if desired.  It leaves conversion from UTC to 
local time as a presentation problem. We would still have to define the 
"simple properties" for VRECUR. I think we would need to concentrate on the 
few use cases which are used by the majority of people. There's probably an 
80/20 rule there somewhere. Does anyone have a way to gather statistics on 
recurrence definitions? For example, where I work we use Notes and I'd bet 
80% of recurrence is "weekly".

If this seems like it's not solving the problem or introducing new ones, 
then I'd agree to "just UTC with no RRULEs in the base spec", and putting 
RRULEs elsewhere.

At 02:45 PM 9/30/04, Doug Royer wrote:

>I agree. For protocols like CAP and CalDAV, that works. For iMIP there may be
>Perhaps we need to add an optional property that can be added to iCAL objects

Tim Hare

Date: Thu, 30 Sep 2004 12:45:02 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] UTC
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2004 18:45:17 -0000

This is a cryptographically signed message in MIME format.

--------------ms090703020303010105070100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-- 

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

--------------ms090703020303010105070100--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] UTC
Date: Thu, 30 Sep 2004 10:38:30 -0700
To: Helge Hess <[email-masked]>
Cc: [email-masked]

Lisa

> only requires UTC which of course would be a huge simplification.

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] UTC
Date: Thu, 30 Sep 2004 19:29:44 +0200
To: [email-masked]

Greets,
   Helge

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] UTC
Date: Thu, 30 Sep 2004 13:16:45 -0400
To: Helge Hess <[email-masked]>
Cc: [email-masked]

Date: Tue, 21 Sep 2004 23:32:42 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] Re: charter

Back on the 14th, there was some discussion about coming up with a charter, 
along with some discussion about "How it can be done" versus "How it is 
being done now".  I haven't seen much discussion since, though I have seen 
some more discussion attempting to summarized list issues so far.

Here's my proposal for a mission statement: "to find a set of iCalendar 
objects, and iTip verbs which can be used between any two calendaring 
products/tools and which will provide interoperability between any two 
calendaring products/tools".

To add to the  "How it ... " discussion,  and in conformance with my 
mission statement above, I would propose that even if a particular piece of 
software supports lots of complex interaction between its own clients and 
servers there exists the need to use a simplified interaction with other 
implementations.

Here are the cases I've thought of so far:

A:  Publishing (METHOD: PUBLISH) a file to be picked up by others, 
implementations unknown.
B: Using iTIP methods to interact with others,  in domains other than the 
current one,  implementations unknown.
C: Using iTIP methods to interact with others in the same domain, 
implementation can possibly be assumed.

In case A I would propose all dates be either UTC or floating, and that 
recurrence sets be expanded before publishing into many VEVENTS.

In case B I would propose all dates be UTC,  but the simplest forms of 
RRULEs be used (or not at all).

In case C use whatever features are implemented.

The implementation can determine what to do for each 
attendee/organizer/whatever based on whether the host name of that person 
matches the domain of the implementation - i.e., if I'm scheduling a 
meeting in Lotus Notes and all the attendees have the same host and domain 
name, I can assume they are also using Lotus Notes. If they have the same 
domain name but different host names, I can't make that assumption because 
many companies might have multiple different implementations such as 
Groupwise and Exchange.

Our simplification and interoperability problems come primarily from case 
B. Therefore, the simplest course to me would be to find the "greatest 
common factors" or "least common denominators" between implementations , 
then in a draft document specify that as the interoperability 
specification. We would have a document that described one way to 
interoperate, while we could continue to debate what to include/exclude to 
simplify things. Since, to interoperate, we would probably be describing 
mostly the simpler parts of the current RFCs we'd be unlikely to eliminate 
many of those parts as we reworked things.

When the first Interop report from the Calendaring & Scheduling Consortium 
comes out, we will have another data point to work from, also.

Tim Hare

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] UTC
Date: Sun, 19 Sep 2004 16:56:17 +0200
To: [email-masked]

best regards,
   Helge

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.
Date: Fri, 17 Sep 2004 19:33:47 +0200
Cc: 

--nextPart1242059.rRcZgWYXgS
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.

Most applications just ignore the seconds. So why should they be required i=
f=20
they are mostly ignored?

>        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>        are saying  want  to  do  this,  we  need  a  more  specific
>        proposal.

If that more specific proposal allows recurrences like "second tuesday in=20
September"...
=46or the more involved example of the US presidential election day, I don'=
t=20
think the issue is how to represent this in a GUI. I doubt that such a rule=
=20
would be entered by an ordinary user. But for centralized calendar=20
repositories, where people can subscribe to calendars, iCalendar (or howeve=
r=20
it will be called) needs to be able to express such a complex recurrence,=20
too.

>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?

This is needed to allow, for example last work day of the month/year.=20
Evolution currently supports this, so does Connect Daily, and I'm planning =
on=20
adding it to korganizer.

>        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  Thin CUA's
>        can not use it anyway and ignore it.  Having  this  property
>        does  not break CUAs that do not use it.  How many use this?

KOrganizer, for example, lets you attach URIs to your events and todo items=
=2E=20
They are shown in the event viewer / reminder dialog as links.=20
KOrganizer also lets you attach a link to a mail message in kmail (by simpl=
y=20
dragging the mail to the todo).

>        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.

Yes. Related-to is the current way to implement hierarchical todo-lists, li=
ke=20
KOrganizer does.

Just my 2 cents on this topic...

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * KOrganizer / KPilot maintainer, K Desktop Environment, http://www.kde.or=
g/

--nextPart1242059.rRcZgWYXgS
Content-Type: application/pgp-signature

--nextPart1242059.rRcZgWYXgS--

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] ISO Standard relevant to timezone and time representation discussions
Date: Fri, 17 Sep 2004 10:02:23 -0400
To: [email-masked]
Cc: [email-masked]

FYI, I'm the "at least one person" Dave refers to, and I found this (as  
I've told some of you) eye-opening.  I'm not sure that it will have any  
direct consequences for us, but I found it useful to look at a rather  
different perspective on the same problems we're focused on here.   
Anyway at $18, it's a cheap exercise in broadening one's perspective.   
-- Nathaniel

On Sep 16, 2004, at 10:26 PM, David C. Thewlis wrote:

> There's an ISO standard which I think is very relevant to the work  
> being
> done by the people on these discussion lists, in particular in  
> discussions
> of representation and management of time values.  The standard in  
> question
> is:
>
> ISO 19108 (2002), Geographic Information:  Temporal Schema
> developed by ISO/TC211, Geograhic Information/Geomatics
>
> The scope of this standard is described as:
>
> "This International Standard defines concepts for describing temporal
> characteristics of geographic information. It depends upon existing
> information technology standards for the interchange of temporal
> information. It provides a basis for defining temporal feature  
> attributes,
> feature operations, and feature associations, and for defining the  
> temporal
> aspects of metadata about geographic information. Since this standard  
> is
> concerned with the temporal characteristics of geographic information  
> as
> they are abstracted from the real world, it emphasises valid time  
> rather
> than transaction time."
>
> I know at least one person on this discussion list has looked at this
> standard and there may be others, if anyone else would care to comment  
> on
> its relevance.
>
> I'll put info below on how to get a copy.
>
> Dave Thewlis, Executive Director
> The Calendaring and Scheduling Consortium
> +1 707 840 9391 (voice)
> +1 415 946 3454 (fax)
> +1 707 498 2238 (mobile)
> [email-masked]
> www.calconnect.org
>
> ----------------------------------------------------------------------- 
> -----
> ---------------
>
> How to get a copy of ISO 19108
>
> You can purchse a copy of this standard for $18 by downloading it from  
> the
> ANSI webstore (you can also get a copy directly from ISO but it costs  
> 140
> Swiss Francs that way).
>
> Point your browser to:   
> http://webstore.ansi.org/ansidocstore/default.asp
>
> Enter "19108" in the top left "search" box and click go
>
> You'll be offered two choices:  "ISO 19108:2002" for $113.00" and
> "INCITS/ISO 19108:2002" for $18.  They are the same document; INCITS  
> (the
> U.S. national IT standards committee) has registered the international
> standard as a parallel national standard and can thus sell it at its  
> own
> charge, which it has set very low.
>
> The site will talk you through the process of purchasing a copy on a  
> credit
> card and downloading it.  Note that you have to agree on the copyright  
> and
> license agreement; the bottom line is you can't copy and distribute it  
> or
> make it available on a network (they want to you get a separate copy  
> for
> each person who will use it).
>
> But at $18 I'm not sure that is a serious impediment.
>
> Dave Thewlis
>

Date: Fri, 17 Sep 2004 09:04:26 +0200
From: Harrie Hazewinkel <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] UTC
Cc: [email-masked]

Harrie
> Interested Bystander, Non-Inc.

Date: Thu, 16 Sep 2004 19:26:20 -0700
From: "David C. Thewlis" <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] ISO Standard relevant to timezone and time representation discussions
Reply-To: [email-masked]

There's an ISO standard which I think is very relevant to the work being
done by the people on these discussion lists, in particular in discussions
of representation and management of time values.  The standard in question
is:

ISO 19108 (2002), Geographic Information:  Temporal Schema
developed by ISO/TC211, Geograhic Information/Geomatics

The scope of this standard is described as:

"This International Standard defines concepts for describing temporal
characteristics of geographic information. It depends upon existing
information technology standards for the interchange of temporal
information. It provides a basis for defining temporal feature attributes,
feature operations, and feature associations, and for defining the temporal
aspects of metadata about geographic information. Since this standard is
concerned with the temporal characteristics of geographic information as
they are abstracted from the real world, it emphasises valid time rather
than transaction time."

I know at least one person on this discussion list has looked at this
standard and there may be others, if anyone else would care to comment on
its relevance.

I'll put info below on how to get a copy.

Dave Thewlis, Executive Director 
The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice)
+1 415 946 3454 (fax)
+1 707 498 2238 (mobile)
[email-masked]
www.calconnect.org

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

How to get a copy of ISO 19108

You can purchse a copy of this standard for $18 by downloading it from the
ANSI webstore (you can also get a copy directly from ISO but it costs 140
Swiss Francs that way).

Point your browser to:  http://webstore.ansi.org/ansidocstore/default.asp

Enter "19108" in the top left "search" box and click go

You'll be offered two choices:  "ISO 19108:2002" for $113.00" and
"INCITS/ISO 19108:2002" for $18.  They are the same document; INCITS (the
U.S. national IT standards committee) has registered the international
standard as a parallel national standard and can thus sell it at its own
charge, which it has set very low.

The site will talk you through the process of purchasing a copy on a credit
card and downloading it.  Note that you have to agree on the copyright and
license agreement; the bottom line is you can't copy and distribute it or
make it available on a network (they want to you get a separate copy for
each person who will use it).  

But at $18 I'm not sure that is a serious impediment.

Dave Thewlis

Date: Thu, 16 Sep 2004 22:05:17 -0400
To: Cyrus Daboo <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] UTC
Cc: 

Tim Hare

Date: Thu, 16 Sep 2004 10:22:09 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Ietf-calsify] UTC
Cc: 

Hi [email-masked],

-- 
Cyrus Daboo

Date: Thu, 16 Sep 2004 10:16:12 +0100 (BST)
From: Libby Miller <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.
Sender: Libby Miller <[email-masked]>

hi Doug

Well, anything you feel happy sharing would be most welcome.

Libby

On Wed, 15 Sep 2004, Doug Royer wrote:

>
>
> Libby Miller wrote:
>
>> 
>> 
>> On Tue, 14 Sep 2004, Doug Royer wrote:
>> 
>>> I have seached thousands of VCALENDAR objects on the net and I have
>>> tested over 40 calendar products or net accounts for calendars or PDAs, 
>>> and never
>>> found anything other than an RFC example of its usage.
>>> 
>> 
>> Doug, is there any chance you could make this (raw) data available to us? 
>> It would be really helpful.
>> 
>> all the best 
>
>
> I can post a url to many of the .ICS files that I have found on the net 
> However many are uploaded
> at test time from sites and I do not have copies of them.  I used a tweaked 
> 'wget' to snag
> many and feed it into a program that counted the component, property, and 
> parameter
> types used and some values of specific properties. So in many cases I have 
> the results
> and not the raw data.
>
> -- 
>

Date: Thu, 16 Sep 2004 00:10:40 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] UTC

Tim Hare

Date: Wed, 15 Sep 2004 11:57:46 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2004 17:58:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms040207070307000207090709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Libby Miller wrote:

>
>
> On Tue, 14 Sep 2004, Doug Royer wrote:
>
>> I have seached thousands of VCALENDAR objects on the net and I have
>> tested over 40 calendar products or net accounts for calendars or 
>> PDAs, and never
>> found anything other than an RFC example of its usage.
>>
>
> Doug, is there any chance you could make this (raw) data available to 
> us? It would be really helpful.
>
> all the best 

I can post a url to many of the .ICS files that I have found on the net 
However many are uploaded
at test time from sites and I do not have copies of them.  I used a 
tweaked 'wget' to snag
many and feed it into a program that counted the component, property, 
and parameter
types used and some values of specific properties. So in many cases I 
have the results
and not the raw data.

-- 

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

--------------ms040207070307000207090709--

From: Dan Connolly <[email-masked]>
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Date: Wed, 15 Sep 2004 13:49:01 +0100
To: Leo Sauermann <[email-masked]>
Cc: [email-masked], [email-masked]

On Sep 14, 2004, at 3:41 PM, Leo Sauermann wrote:

>
>
>>
>> Also in the debate on this list was listing all entries in UTC.  This
>> would eliminate the need for VTIMEZONE in many (all?) components.
>> Yet the CUA still needs to do TZ math.  So this is a proposal on
>> how to have simple IANA registered time zones so that everyone does
>> the same math.
>
> uhhh..
> many of todays calendars in VCAL have errors about timezones.
> If mozilla/kde/whatever doesn't get it, we rdf developers won't get 
> it, too.

But mozilla/kde/whatever do get it, increasingly.

Don't let's fall into the trap of thinking that producing new 
specifications
will fix the fact that the old ones aren't implemented well.

> so I would recommend to always store time in local time format with 
> timezone, because any UI (cell phone, whatever) then may display it 
> without any math.

But if it can't tell that a meeting at 1pm NY time conflicts with a 
meeting at 12noon Chicago time, what good is that? Just use plain text 
if you don't want the computer to actually help.

-- 
Dan

Date: Wed, 15 Sep 2004 08:32:07 -0400 (EDT)
From: Charles McCathieNevile <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Cc: [email-masked]

On Tue, 14 Sep 2004, Elias Sinderson wrote:

>Charles McCathieNevile wrote:
>
>>On Tue, 14 Sep 2004, Leo Sauermann wrote:
>>
>>>[...] I would recommend to always store time in local time format with timezone, because any UI (cell phone, whatever) then may display it without any math.
>>>
>>[...] I don't think in real-world applications you can get away with not being able to do the maths.
>>
>+1
>
>>I have a cellphone and a laptop, and sync my calendars between them. I have
>>several problems:
>>
>>Some events have a different timezone for the start and end (most often,
>>aeroplane flights - the data I get gives the departure and arrival times as
>>local to the relevant airport.
>>
>Would it be acceptable for the client to display all the times in local
>time, whatever that may be? For example, in New York you would see the
>times for the flight displayed in New York time, and when  in Paris you
>would see the times as local to Paris. Personally I could live with
>this, especially if my client allowed me to dynamically switch the
>display timezone.

That's what I have at the moment. If I find a calendar program that does
better, I'll ditch the current one. The problem is as follows:

I am in Antibes, and I have a flight that goes from Frankfurt (same time zone
as Antibes in this case) to Shanghai (some other time), where I meet my
mother. She wants to know when I get to the airport. I'd like to have the
time blocked off for making appointments according to Antibes time (and so I
can see how many hours I will spend in the plane, but I want to be able to
quickly look up my arrival time in the most useful form, which is generally
going to be Shanghai time. (Not always, but IMHO there should be nothing to
stop me noting an event in UTC or something if I want to).

>>[...] recurrent events have their time specified in different time zones. For
>>instance I have one recurrent meeting with times expressed in France/Paris
>>time, and another expressed in US/Boston time.
>>
>It would seem that keeping all of these times in UTC would avoid you
>having to switch the timezone settings on your client.

Not really, unless you are prepared to switch each instance of a recurrent
event, checking when the changes to summer time are. In fact it is important
on some timezones to know what the original timezone was, since you can't
always predict in advance when timezones shift. (In 2000, the state of New
South Wales announced that it would introduce summer time many weeks earlier
than usual to allow for better TV programming times for the Olympics. I don't
want to have to then tell my calendar to recalculate everything that was
noted in sydney time originally by hand - if I have to tell it that Sydney is
already on summer time (I believe that I still have to do that currently)
that's more than enough hassle.

>>[...]
>If we agree that the canonical server representation MUST be in UTC,

I don't - I think the idea of keeping the thing in a local time and noting
its timezone is a good one. I just don't think that it achieves the goal of
avoiding the maths. On the other hand it achieves the goal of maintaining an
important data point so we can get the right result if we do the maths right,
in a way that seems (to me) likely to be less troubling in the long run than
always
relying on UTC.

cheers

Chaals

Date: Wed, 15 Sep 2004 09:02:02 +0100 (BST)
From: Libby Miller <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.
Sender: Libby Miller <[email-masked]>

On Tue, 14 Sep 2004, Doug Royer wrote:
> I have seached thousands of VCALENDAR objects on the net and I have
> tested over 40 calendar products or net accounts for calendars or PDAs, and 
> never
> found anything other than an RFC example of its usage.
>

Doug, is there any chance you could make this (raw) data available to 
us? It would be really helpful.

all the best

Libby

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Date: Wed, 15 Sep 2004 00:17:52 +0200
To: [email-masked]
Cc: [email-masked]

On Sep 14, 2004, at 23:57, Cyrus Daboo wrote:
> Displaying them in your local 'display' timezone is fine, but what 
> about editing them? If I enter a date-time with a specific timezone 
> and then go back to edit that, I want to see it in the timezone I 
> originally entered, not whatever my current 'display' timezone is.

-1.
I don't know in what situation that would be important. Sounds more 
like a free form history log for informational purposes (like "created 
as event 'blub' in Seattle, PST").

> If we do switch to using only UTC times I would like to suggest that 
> we preserve the original timezone info using a 'TZHINT' attribute on 
> the date-time property.

+1
Sounds good! An optional attribute which transports that information.

> That way clients would know what timezone to use when the user wants 
> to edit.

This is relevant for calculated cycles, in all other cases the user 
will probably expect the current view timezone to be used for edits as 
well (not to be discussed, opinions might differ ;-).

>  The question is whether that is really any different than what we 
> have now...

Yes it is! The storage/transport would be allowed to ignore the hint 
(which will be quite usual if you consider the amount of requests for 
UTC!), but systems supporting the hint could still provide the 
information.
Which is why I like the solution.

The "issue" to be solved are calculated cyclic appointments. I would 
personally vote to remove them, but I know that a lot of 
devices/clients already depend on it (eg Palm PDAs and Outlook). I see 
three levels of recurrence support:

a) no recurrences in the protocol (client must flatten cycles to 
individual events),
    implies that timezone info is not necessary anymore (hurray!)
b) recurrences allowed on creation, kept in storage (servers will 
return individual
    events on queries). Only needs timezone for recurrences on creation.
c) recurrences fully supported (current situation). Client and server 
need to be fully
    timezone aware and have consistent information on that.

Reducing to a) would certainly make the protocol/format a _whole_ lot 
easier. b) still gives a big boost in interoperability and is easier. 
But c) is actually required for a lot of systems.

best regards,
   Helge

Date: Tue, 14 Sep 2004 18:16:35 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.

Hi Doug,

--On Tuesday, September 14, 2004 1:57 PM -0600 Doug Royer <[email-masked]> 
wrote:

>> You need BYSETPOS to say "the first/last weekday of the month", which I
>> think is supported by more than one CUA.
>>
>>
> I have seached thousands of VCALENDAR objects on the net and I have
> tested over 40 calendar products or net accounts for calendars or PDAs,
> and never
> found anything other than an RFC example of its usage.
>
> If it is in use - great!

My client allows users to have a 'first' or 'last' bysetpos. Not that many 
people are using it right now, but I do have one event on my calendar that 
uses BYSETPOS - namely 'PAY DAY' - the last week day in the month!

RRULE:FREQ=MONTHLY;BYDAY=-1MO,-1TU,-1WE,-1TH,-1FR;BYSETPOS=-1

-- 
Cyrus Daboo

Date: Tue, 14 Sep 2004 17:57:40 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Cc: [email-masked]

Hi Elias,

--On Tuesday, September 14, 2004 1:00 PM -0700 Elias Sinderson 
<[email-masked]> wrote:

>> Some events have a different timezone for the start and end (most often,
>> aeroplane flights - the data I get gives the departure and arrival times
>> as local to the relevant airport.
>>
> Would it be acceptable for the client to display all the times in local
> time, whatever that may be? For example, in New York you would see the
> times for the flight displayed in New York time, and when  in Paris you
> would see the times as local to Paris. Personally I could live with this,
> especially if my client allowed me to dynamically switch the display
> timezone.

Displaying them in your local 'display' timezone is fine, but what about 
editing them? If I enter a date-time with a specific timezone and then go 
back to edit that, I want to see it in the timezone I originally entered, 
not whatever my current 'display' timezone is.

If we do switch to using only UTC times I would like to suggest that we 
preserve the original timezone info using a 'TZHINT' attribute on the 
date-time property. That way clients would know what timezone to use when 
the user wants to edit. The question is whether that is really any 
different than what we have now...

-- 
Cyrus Daboo

Date: Tue, 14 Sep 2004 14:00:26 -0700
From: "David C. Thewlis" <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Re: Testing and Interops
Reply-To: [email-masked]

Pat Egen posted to this list that she was waiting for the last of the
results from the testers before completing her detailed report on the
Interop at UCB.  The final results were sent to her late last week, but Pat
had just left on vacation trip.  I believe she returns around the 25th, so
we can hope for her final report shortly after that.  

Our apologies for the delay, but as Pat said she wanted to make the report
as complete as possible and clearly the results from all of the testers
were important.

Dave Thewlis
Executive Director
The Calendaring and Scheduling Consortium

Date: Tue, 14 Sep 2004 13:49:06 -0700
From: "David C. Thewlis" <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Testing and interops
Reply-To: [email-masked]

On 9/14/2004 at 14:32 Doug Royer wrote:

>And the 2nd point is that if we do not know what the vendors are doing
>then how can we declare anything interoperable? We only have a small
>number of vendors that could afford the commercial testing.

I presume by "commercial testing" you are referring to the Calconnect
Interops that The Calendaring and Scheduling Consortium was in part created
to conduct?  FYI we set the fee at $1500 for members and $2500 for
nonmembers, which is intended to be a revenue-neutral fee at the size we
expect an Interop to be.  Granted that's not *cheap* but it's not horribly
expensive either.

We have talked about doing virtual interops in the future (although I
gather the consensus from the last virtual interop was that overall the
in-person sessions are more productive), but don't have any current plans
for one.  

We'll be happy to start planning for the next one either virtual or real,
as soon as there's a need for one.  It hasn't been clear to me that we
would need further Interops on the current RFCs as opposed to what may come
of these discussions, but there's absolutely no reason we go ahead with one
now folks see a need.

Dave thewlis
Executive Director
The Calendaring and Scheduling Consortium

Date: Tue, 14 Sep 2004 14:32:38 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Re: charter
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 20:32:50 -0000

This is a cryptographically signed message in MIME format.

--------------ms030101050107070606060306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>> Fortunately this mailing list is not "how can it be done", its "how 
>> do people do it".
>
>
> This shows again why we need a clear charter -- for my part, I don't 
> think *either* of those characterize our goal very well, but I'm 
> closer to the former than the latter.

It was my understanding that the goal was interoperability. For that I read
(in the simple case) if a HUGE number of venders do SOMETHING
and SOMETHING is working. it would seem to me to be easier
to make the smaller number of vendors change to the SOMETHING method.
Of course things are never that simple.

And the 2nd point is that if we do not know what the vendors are doing
then how can we declare anything interoperable? We only have a small
number of vendors that could afford the commercial testing.

Which is why it seems to me to be "how do people do it".

There seems to be 3 basic types of iCAL usage:

  (1) iMIP

  (2) The HTTP/WEBDAV POST/GET of objects - or WEB calendars
         that import/export iCAL.

  (3) PDA's and synchronization (And the 3 CAP vendors).

What vendors put in each has some overlap.

VALARMS go into (2) and (3) and almost never in (1)

Several common custom properties go into (2) and (3) and a different
set of common custom properties tend to go into (1).

I think we need to figure out the MINIMUM set that works for everyone
(as in how they do it now) and that needs to go into the 'basic' ical draft.
And I think we need to recognize that some large vendors did not do
it as documented. And have failed to document how they do it. These
need to be weeded out as noise as no one can be compatible with
undocumented procedures.

Same with scheduling. We need to figure out the basic minimum for
scheduling and that needs to be in 'basic-scheduling draft'.

Everything else I think need to be in add-on drafts.

If this is an iCAL-next, I think we are opening up the scope to years
of debate - which is how I read "how can it be done".

-- 

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

--------------ms030101050107070606060306--

Date: Tue, 14 Sep 2004 13:00:20 -0700
From: Elias Sinderson <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Cc: [email-masked]
Reply-To: [email-masked]

Charles McCathieNevile wrote:

>On Tue, 14 Sep 2004, Leo Sauermann wrote:
>
>  
>
>>[...] I would recommend to always store time in local time format with timezone, because any UI (cell phone, whatever) then may display it without any math.
>>    
>>
>[...] I don't think in real-world applications you can get away with not being able to do the maths.
>  
>
+1

>I have a cellphone and a laptop, and sync my calendars between them. I have
>several problems:
>
>Some events have a different timezone for the start and end (most often,
>aeroplane flights - the data I get gives the departure and arrival times as
>local to the relevant airport.
>
Would it be acceptable for the client to display all the times in local 
time, whatever that may be? For example, in New York you would see the 
times for the flight displayed in New York time, and when  in Paris you 
would see the times as local to Paris. Personally I could live with 
this, especially if my client allowed me to dynamically switch the 
display timezone.

>[...] recurrent events have their time specified in different time zones. For
>instance I have one recurrent meeting with times expressed in France/Paris
>time, and another expressed in US/Boston time.
>
It would seem that keeping all of these times in UTC would avoid you 
having to switch the timezone settings on your client.

>[...] One-off Web events and the like are often specified in a local time based on
>where the guy writing the page is. This seems reasonable. But if I have
>to shift my software around to that timezone to enter the time, it's a pain,
>and any given person is unlikely to specify things in lots of timezones.
>  
>
If we agree that the canonical server representation MUST be in UTC, I 
propose adding the following text to the spec as well. "Clients SHOULD 
allow a user to specify times for events in any timezone." At any rate, 
changing the timezone setting on your client in order to enter an event 
seems warped. (No offense intended, clearly the calendar client you are 
using is forcing you to work around it's shortcomings.)

>I tried keeping one clock synched to UTC and doing everything based on that.
>As someone who changes timezones on average more than once a week I thought
>it would make sense, but it doesn't.
>
I've lived in multiple timezones simultaneously as well, keeping watches 
sync'd to different timezones. The real problems occurred when I was so 
tired that I put them on the wrong wrist...

>The maths is a bit more complex than straight addition/subtraction, but not very. Most of the complexity is to do with looking up tables. That sounds to me like the kind of maths that we
>should rely on computers to do [...]
>
+1

Regards,
Elias

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Date: Tue, 14 Sep 2004 21:58:56 +0200
To: [email-masked]
Cc: [email-masked]

On Sep 14, 2004, at 21:44, Elias Sinderson wrote:
> The math consists of a single lookup and a single addition or 
> subtraction, or the equivalent of a switch statement based on the 
> current client timezone... Even cell phones can do that without 
> difficulty, as can handhelds, etc.

The calculation itself isn't too difficult. But storing (and updating) 
the timezone information for all the years might be a storage problem 
for cell phones? (though cell phones nowadays have enough RAM, but your 
new cell phone watch might not ;-).

> Quite honestly, storing all times in UTC is the simplest solution. It 
> is well within the extent of client capabilities to translate times 
> from UTC to the local client setting.

Except that it doesn't work for (calculated) cyclic appointments which 
need to take into account daylight savings which in turn requires the 
timezone information.
Do I miss something? (I have the impression, because this was suggested 
several times now).

best regards,
   Helge

Date: Tue, 14 Sep 2004 13:57:32 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 19:57:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms020809080001000205000006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dan Winship wrote:

>On Mon, 2004-09-13 at 17:18 -0600, Doug Royer wrote:
>  
>
>>       (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>>       that allows this.  Deprecate it?
>>    
>>
>
>You need BYSETPOS to say "the first/last weekday of the month", which I
>think is supported by more than one CUA.
>  
>
I have seached thousands of VCALENDAR objects on the net and I have
tested over 40 calendar products or net accounts for calendars or PDAs, 
and never
found anything other than an RFC example of its usage.

If it is in use - great!

Maybe we need to start collecting:

    (A) A CUA feature list (released products only).
    (B)  An object contents list.

Then perhaps only then we can start throwing out the unused or knowing
what is incompatible.

>>       (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>>       want  to  do this
>>    
>>
>
>Really?
>
It did look to me as if the list was leaning to yes. Which is why I 
raised the point.

I for one think that we need to standardize on TZ's contents (hence my 
draft).
Standardized TZ's I think are needed ether way.

I also feel that everything in Z would be too much of a change. It just 
looked
to me as if people wanted it.

> I agree that there are several people on the list who want to do
>this, but I don't feel like there was any broad consensus reached. (I
>think that's actually true in general. None of the threads on this list
>so far has had the feel of a vote.)
>  
>
I agree.

>  
>
>>       (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>>       want to do this.
>>
>>       (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>>       values. (FBTYPE).  Do we need more discussion?
>>    
>>
>
>My understanding is that if we are trying to move iCalendar to draft
>standard status (which is what Lisa created this list for), then we
>can't add things; we can only clarify things, and remove the bits that
>aren't actually interoperably implemented.
>
>If our goal is broader than that, then we need to figure out what
>exactly our goal is, and what sort of backward-compatibility constraints
>we have. In particular, RFC 2445 says that TRANSP can be "OPAQUE" or
>"TRANSPARENT", and nothing else. So if we change that, would we have to
>change VERSION as well? Because that would suck.
>
VERSION is the version of the data format, not the contents. So no VERSION
would not have to change.

I think that CLASS needs to be deprecated completely. The resistance
to that idea seem to be to create new value types that have well
defined values. That would be my 2nd choice.

>  
>
>>       (1.1.4) 2445 - New VJOURNAL draft
>>    
>>
>
>Is there actually anyone who wants a new VJOURNAL draft? (As opposed to
>just dropping it.)
>
Let those that want VJOURNAL write the draft :-)
There are two products that I know of that use it.

-- 

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

--------------ms020809080001000205000006--

Date: Tue, 14 Sep 2004 12:44:38 -0700
From: Elias Sinderson <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Cc: [email-masked]
Reply-To: [email-masked]

Leo Sauermann wrote:

>> Also in the debate on this list was listing all entries in UTC [...]
>
> [...] I would recommend to always store time in local time format with 
> timezone

local to the client or local to the server? Assuming that you mean local 
to the client, this simply begs the question as to how one deals with:
* multiple clients in different timezones modifying the same calendar?
* a client, such as a cell phone, which moves between timezones?
Examples use cases provided upon request, there are many - I assume the 
reader can provide their own...

> because any UI (cell phone, whatever) then may display it without any 
> math.

The math consists of a single lookup and a single addition or 
subtraction, or the equivalent of a switch statement based on the 
current client timezone... Even cell phones can do that without 
difficulty, as can handhelds, etc.

Quite honestly, storing all times in UTC is the simplest solution. It is 
well within the extent of client capabilities to translate times from 
UTC to the local client setting. Further, this prevents servers from 
having to convert timezones for various clients in different timezones, 
makes the protocol easier to understand and, lastly, avoids unnecessary 
bloat on the wire.

Regards,
Elias

Date: Tue, 14 Sep 2004 13:29:52 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 19:30:04 -0000

This is a cryptographically signed message in MIME format.

--------------ms020803030400020703070007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

>
>
>Got to disagree with you Doug.  Unfortunately, the "replace all" set does
>not work with our product and interoperability testing (both external and
>internal) has shown that.
>
Odd. My testing with your product shows that it does work. Maybe we are not
talking the same thing.

(1) I send a REQUEST - you accept.
(2) I send another REQUES with updated information - you accept.

(1) has a UID of 'xxx', SEQ of 0
(2) Has a UID of 'xxx;  SEQ of 1

It works with your product - what does not work?

-- 

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

--------------ms020803030400020703070007--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Moderation in all things
Date: Tue, 14 Sep 2004 10:57:55 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Nathaniel Borenstein" <[email-masked]>, <[email-masked]>
Cc: 

As an interim co-chair and (therefore) default moderator of this list, I
want to thank Nathaniel for his reminder to all of us to keep our
discussion professional and kind.

When we invented the term "calsify", I volunteered to be a co-chair of
this working group, and our initial charter was agreed upon in our small
group to be this:

Simplify the existing iCal proposed standard (remove only - do not add)
to solve the confusion and interoperability headaches, with the ultimate
goal of bringing this new "simplified" iCal (eCal/sCal/...) to the state
of actual INTERNET STANDARD.

So far, our discussion has been focused on aspects of the spec which are
unclear and which are in need of simplification/clarification.  We have
identified many aspects which may need to be cut from the standard, and
many which may need to be less rigid, or more rigid.  We have also
identified good points for additions to a future standard, but which we
will not be pursuing in the context of this working group.  I fully
expect such ideas to spring from the current state of things.  

These have been by and large excellent, professional, and courteous
discussions.  LET'S KEEP IT THAT WAY.

Our ability to deliver on bringing calendaring to the internet with the
ubiquity of e-mail will largely depend on our ability to cooperate,
reason, and function as a group.  While opinions which runs contrary
about technical issues, schemas, functionality, scenarios, etc. are very
welcome - and will ultimately lead to a better standard... Opinions
which are aggressive or demeaning are NOT WELCOME, regardless of
intention.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nathaniel
Borenstein
Sent: Tuesday, September 14, 2004 10:28 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be
allowed

On Sep 13, 2004, at 5:14 PM, Doug Royer wrote:

> That make no sense at all.

If one can't make sense of something, it is imprudent to assume that's
necessarily because it makes no sense.  The problem can be on either
end.

> At his point I am going to consider your posts as trolling.
>
> Does any one (else) have any input on this topic?

Yes, I do.  While I have no opinion either way about the details of this
disagreement, I want to say that I consider it completely unacceptable
to dismiss someone else's politely-expressed opinions with a pejorative
-- especially one that seems to make no sense in context.  
What on earth would Tom [Ramsdell] be "trolling" for?  Arguments for the
sake of arguments?

On Sep 13, 2004, at 8:08 PM, Mark Swanson wrote:

> I would like to know what the process is for moving forward on issues 
> like this.... (Surely not the same process as the previous 
> ietf-calendar mailing
> list?)

I think the very first deliverable of this list, which we/I have
neglected so far, should be a proposed charter for a new working group. 
  Once that is established, we will get working group chairs, who will
be responsible for such disputatious-issue resolution.  Until then, I
don't really expect controversial issues to be *resolved*, and I see the
purpose of the current preliminary discussion as exploring the issues
and discussing which ones we should *try* to resolve -- which,
coincidentally, involves basically the same questions as drafting a
charter.

On Sep 13, 2004, at 8:20 PM, Doug Royer wrote:

> So far only Robert seem to think that the method he proposes is 
> documented, standardized, or compatible with many others.

The fact that only one person (or a few) speaks out about either side of
an issue does NOT mean that whoever is most aggressive gets to declare a
consensus.  For my part, I haven't expressed an opinion because I don't
yet consider myself well-informed enough to have one, and was looking
forward to clarification, explanation, and persuasion.  
If I had to take sides in the absence of these, I would be 
instinctively inclined to take the side that's being most polite.   My 
preference, however, would be to see the issues sufficiently well
thought-out and clearly spelled-out that I could confidently reach my
own conclusion.

More philosophically, this attitude isn't just because I hate conflict
(although I do).  It's because I believe that when issues are really
well explored, they are much less likely to end up in flat-out
disagreements that *require* voting.  Although I didn't participate in
much of the long history of the calsch group, the resulting documents
certainly look to me like too many arguments were somehow settled before
they were well-enough understood, perhaps by a "tyranny of the loudest."
I would really like to make sure that doesn't happen here.

> He did the same thing on the other mailing list and caused months of 
> delay.

If you are conjecturing that delay is his motive, I can tell you, as his
coworker, that this is just incorrect.  So either one of you is simply
flat-out wrong -- in which case you should eventually be able to
persuade people like me -- or there are subtleties that are not being
properly addressed or elucidated in this discussion.

> Fortunately this mailing list is not "how can it be done", its "how do

> people do it".

This shows again why we need a clear charter -- for my part, I don't
think *either* of those characterize our goal very well, but I'm closer
to the former than the latter.

> I do not think that the issue is stalled. I think that it is fairly 
> clear

The debate is *obviously* stalled, however clear the issues may be to
you -- "stalled" and "clear to you" are not antonyms.

On Sep 14, 2004, at 10:45 AM, [email-masked] wrote:

> You just are too stubborn to admit it.

Sigh.  Can we please try to keep this list free of ad hominem attacks on
*both* sides?  -- Nathaniel

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
Date: Tue, 14 Sep 2004 13:28:03 -0400
To: [email-masked]

On Sep 13, 2004, at 5:14 PM, Doug Royer wrote:

> That make no sense at all.

If one can't make sense of something, it is imprudent to assume that's 
necessarily because it makes no sense.  The problem can be on either 
end.

> At his point I am going to consider your posts as trolling.
>
> Does any one (else) have any input on this topic?

Yes, I do.  While I have no opinion either way about the details of 
this disagreement, I want to say that I consider it completely 
unacceptable to dismiss someone else's politely-expressed opinions with 
a pejorative -- especially one that seems to make no sense in context.  
What on earth would Tom [Ramsdell] be "trolling" for?  Arguments for 
the sake of arguments?

On Sep 13, 2004, at 8:08 PM, Mark Swanson wrote:

> I would like to know what the process is for moving forward on issues 
> like
> this.... (Surely not the same process as the previous ietf-calendar 
> mailing
> list?)

I think the very first deliverable of this list, which we/I have 
neglected so far, should be a proposed charter for a new working group. 
  Once that is established, we will get working group chairs, who will 
be responsible for such disputatious-issue resolution.  Until then, I 
don't really expect controversial issues to be *resolved*, and I see 
the purpose of the current preliminary discussion as exploring the 
issues and discussing which ones we should *try* to resolve -- which, 
coincidentally, involves basically the same questions as drafting a 
charter.

On Sep 13, 2004, at 8:20 PM, Doug Royer wrote:

> So far only Robert seem to think that the method he
> proposes is documented, standardized, or compatible with
> many others.

The fact that only one person (or a few) speaks out about either side 
of an issue does NOT mean that whoever is most aggressive gets to 
declare a consensus.  For my part, I haven't expressed an opinion 
because I don't yet consider myself well-informed enough to have one, 
and was looking forward to clarification, explanation, and persuasion.  
If I had to take sides in the absence of these, I would be 
instinctively inclined to take the side that's being most polite.   My 
preference, however, would be to see the issues sufficiently well 
thought-out and clearly spelled-out that I could confidently reach my 
own conclusion.

More philosophically, this attitude isn't just because I hate conflict 
(although I do).  It's because I believe that when issues are really 
well explored, they are much less likely to end up in flat-out 
disagreements that *require* voting.  Although I didn't participate in 
much of the long history of the calsch group, the resulting documents 
certainly look to me like too many arguments were somehow settled 
before they were well-enough understood, perhaps by a "tyranny of the 
loudest."  I would really like to make sure that doesn't happen here.

> He did the same thing on the other mailing list and caused months of 
> delay.

If you are conjecturing that delay is his motive, I can tell you, as 
his coworker, that this is just incorrect.  So either one of you is 
simply flat-out wrong -- in which case you should eventually be able to 
persuade people like me -- or there are subtleties that are not being 
properly addressed or elucidated in this discussion.

> Fortunately this mailing list is not "how can it be done", its "how do 
> people do it".

This shows again why we need a clear charter -- for my part, I don't 
think *either* of those characterize our goal very well, but I'm closer 
to the former than the latter.

> I do not think that the issue is stalled. I think that it is fairly 
> clear

The debate is *obviously* stalled, however clear the issues may be to 
you -- "stalled" and "clear to you" are not antonyms.

On Sep 14, 2004, at 10:45 AM, [email-masked] wrote:

> You just are too stubborn to admit it.

Sigh.  Can we please try to keep this list free of ad hominem attacks 
on *both* sides?  -- Nathaniel

Date: Tue, 14 Sep 2004 11:40:32 -0400 (EDT)
From: Charles McCathieNevile <[email-masked]>
To: Leo Sauermann <[email-masked]>
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Cc: [email-masked], [email-masked]

On Tue, 14 Sep 2004, Leo Sauermann wrote:

>> Also in the debate on this list was listing all entries in UTC.  This
>> would eliminate the need for VTIMEZONE in many (all?) components.
>> Yet the CUA still needs to do TZ math.  So this is a proposal on
>> how to have simple IANA registered time zones so that everyone does
>> the same math.
>
>uhhh..
>many of todays calendars in VCAL have errors about timezones.
>If mozilla/kde/whatever doesn't get it, we rdf developers won't get it, too.
>
>so I would recommend to always store time in local time format with
>timezone, because any UI (cell phone, whatever) then may display it
>without any math.

You mean something like "2004-10-04T09:00 TZID=Hungary/Budapest" or something
equivalent? That's useful to have, but I don't think in real-world
applications you can get away with not being able to do the maths.

I have a cellphone and a laptop, and sync my calendars between them. I have
several problems:

Some events have a different timezone for the start and end (most often,
aeroplane flights - the data I get gives the departure and arrival times as
local to the relevant airport. This is indeed the most comfortable way I have
found to deal with it. So to work out how to block out the right times as
"you're on the plane - you can't meet anyone for lunch" I need to
convert the time zone when I am entering the data (which is a pain) or do the
maths dynamically (which is a pain, but only for the tool developer...)

recurrent events have their time specified in different time zones. For
instance I have one recurrent meeting with times expressed in France/Paris
time, and another expressed in US/Boston time. Since these recur, it isn't
such a pain to change the time zone when I put them in, so I enter each of
them having set the machine to the relevant time zone. But in synching and in
shifting time zone bases for my tools they need to do the calculations making
sure that they don't blindly convert Boston time to Paris time (for a week or
two most years the difference is an hour more or less than it is the other
50-odd weeks) and let me miss a meeting.

One-off Web events and the like are often specified in a local time based on
where the guy writing the page is. This seems reasonable. But if I have
to shift my software around to that timezone to enter the time, it's a pain,
and any given person is unlikely to specify things in lots of timezones.

I tried keeping one clock synched to UTC and doing everything based on that.
As someone who changes timezones on average more than once a week I thought
it would make sense, but it doesn't. The maths is a bit more complex than
straight addition/subtraction, but not very. Most of the complexity is to do
with looking up tables. That sounds to me like the kind of maths that we
should rely on computers to do, since they are less likely to miss planes if
we think carefully three times and measure twice before we cut the code
(sorry to mix a carpenters metaphor) than if I have to continually do this...

cheers

Chaals

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] List issues so far.
Date: Tue, 14 Sep 2004 17:03:21 +0200
To: [email-masked]

On Sep 14, 2004, at 16:57, Dan Winship wrote:
>>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>>        want  to  do this
>
> Really? I agree that there are several people on the list who want to 
> do
> this, but I don't feel like there was any broad consensus reached. (I
> think that's actually true in general. None of the threads on this list
> so far has had the feel of a vote.)

Isn't it impossible to change all times to Z unless there is a solution 
for embeddding the timezone or the timezone rule in calculated 
recurring events? (which I would like to see).

best regards,
   Helge

To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
From: [email-masked]
Date: Tue, 14 Sep 2004 11:01:24 -0400

This is a multi-part message in MIME format...

--=_mixed 00524DDA85256F0F_=
Content-Type: multipart/alternative;
	boundary="----------=_1095174032-11730-130"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095174032-11730-130
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

doug wrote
>>I would propose that we (I'll volunteer) to setup some free testing.
>>Not sure what we need yet.  The results of the commercial testing
>>have not yet been provided.

Making your product the test for STANDARD is very strange since you seem 
to have a non-standard implementation.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 09:29 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed

So far this is no WG - this is just a mailing list.

The IETF has an ISSUE page/tool , I think that we should use that.

People will need to write drafts, submit them, and get feedback. That
is the process. Until there is a draft, there is nothing do decide.

A simple typo will be noteworthy, but not that relevant as there
will be new drafts written that may take some of the existing text.
A typo list can be used to verify the same mistakes are not taken again.

Another problem is that the compatibly testing has been very limited
so far. A small handful of vendor that could afford to pay the price
to attend is far from an exhaustive compatibility testing.

 I would propose that we (I'll volunteer) to setup some free testing.
Not sure what we need yet.  The results of the commercial testing
have not yet been provided.

Mark Swanson wrote:

>Thanks for the response.
>
>However, I really am wondering what the process is. For example, in the 
>simplest case where we want to fix a 2445 typo and we all agree. Is there 
a 
>person or group that will maintain _the_ fix list that will be accepted 
by 
>the IETF. Or is the list simply to be maintained ad-hoc by the people on 
the 
>mailing list. Or, what... ? I seem to have missed the memo.
>
>Thanks.
>
> 
>

-- 

------------=_1095174032-11730-130--

--=_mixed 00524DDA85256F0F_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 00524DDA85256F0F_=--

To: [email-masked]
Subject: Re: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
From: [email-masked]
Date: Tue, 14 Sep 2004 10:54:21 -0400

This is a multi-part message in MIME format...

--=_mixed 0051A89385256F0F_=
Content-Type: multipart/alternative; boundary="----------=_1095173611-11730-84"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095173611-11730-84
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

There is a very good example of multiple BEGIN VEVENT/ END VEVENT inside 
one VCalendar stream.
I have an already existing repeating meeting.  Several of the future 
events have had there addenda updated and or there times modified.
A new person joins the team.  I now want to invite that person to the 
entire set.
I have to send the Original Rule plus additional BEGIN/END VEVENTS for the 
instances that have been  changed.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 09:14 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
[Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?

I think its a new issue.

When transferring only booked entries one begin/end works.

However METHOD is global to BEGIN/END VCALENDAR and
you can not have a single BEGIN/END VCALENDAR that
contains more than one METHOD value type.

So, if you are transporting more than one METHOD,
you MUST use multiple BEGIN/END VCALENDAR objects.

iMIP  enforces only one METHOD per MIME object.
So you can not transfer an entire calendar in
one iMIP MIME object anyway.

CAP has a VCALSTORE component that can encapsulate
many VCALENDAR objects as a way to solve that problem.

Do we want to create a wrapper object (VCALSTORE?) so that
we can transfer multiple METHOD VCALENDAR objects?

If not, then implementations that do not accept multiple BEGIN/END
vcalendar objects can not transfer any iTIP object that might be
in a calendar in a single transfer.

Not an answer - just some info...

The question we need to ask is:

    Do we want to be able to transfer 'sync' an entire calendar in one 
pass?

If yes, then we have to allow multiple BEGIN/END per transfer.

I think the answer is yes.

Oren Sreebny wrote:

>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core
>Object is a collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped 
together."
>
>But implementations don't all support multiple VCALENDAR blocks - for
>instance, in Oracle Cal when you export iCalendar data it surrounds  each
>VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
>nor Outlook will accept that as an import format - they want all the
>VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
> 
>

-- 

------------=_1095173611-11730-84--

--=_mixed 0051A89385256F0F_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 0051A89385256F0F_=--

Subject: Re: [Ietf-calsify] List issues so far.
From: Dan Winship <[email-masked]>
To: [email-masked]
Date: Tue, 14 Sep 2004 10:57:29 -0400

On Mon, 2004-09-13 at 17:18 -0600, Doug Royer wrote:
>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?

You need BYSETPOS to say "the first/last weekday of the month", which I
think is supported by more than one CUA.

>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>        want  to  do this

Really? I agree that there are several people on the list who want to do
this, but I don't feel like there was any broad consensus reached. (I
think that's actually true in general. None of the threads on this list
so far has had the feel of a vote.)

>        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>        want to do this.
> 
>        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>        values. (FBTYPE).  Do we need more discussion?

My understanding is that if we are trying to move iCalendar to draft
standard status (which is what Lisa created this list for), then we
can't add things; we can only clarify things, and remove the bits that
aren't actually interoperably implemented.

If our goal is broader than that, then we need to figure out what
exactly our goal is, and what sort of backward-compatibility constraints
we have. In particular, RFC 2445 says that TRANSP can be "OPAQUE" or
"TRANSPARENT", and nothing else. So if we change that, would we have to
change VERSION as well? Because that would suck.

>        (1.1.4) 2445 - New VJOURNAL draft

Is there actually anyone who wants a new VJOURNAL draft? (As opposed to
just dropping it.)

-- Dan

To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
From: [email-masked]
Date: Tue, 14 Sep 2004 10:45:22 -0400

This is a multi-part message in MIME format...

--=_mixed 0050D5EF85256F0F_=
Content-Type: multipart/alternative; boundary="----------=_1095173068-11730-55"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095173068-11730-55
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Doug you asked for clarification from original authors on that issue. They 
came down on ,my side of argument.  You just are too stubborn to admit it.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 08:20 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed

So far only Robert seem to think that the method he
proposes is documented, standardized, or compatible with
many others.

He did the same thing on the other mailing list and caused
months of delay. I have found over 40 ical products that
can not use that method. Fortunately this mailing list is
not "how can it be done", its "how do people do it".

And currently the vast majority of products simply
replace the objects during an update keeping the same UID.

I do not think that the issue is stalled. I think
that it is fairly clear - replacing the objects
with an entire updated set with the same UID
works with all vendors (including the one that Roberts
company ships) I can find. Robert does not seem to
dispute this, he simply wants everyone to also do
it the 2nd way - and they do not.

>I would like to know what the process is for moving forward on issues 
like 
>this. I received a description of this mailing list's purpose but that's 
>about it. If a more detailed description of how conflicts are to be 
resolved 
>and how decisions are actually going to be made is available please point 
me 
>to it. (Surely not the same process as the previous ietf-calendar mailing 

>list?)
>Thank you.

-- 

------------=_1095173068-11730-55--

--=_mixed 0050D5EF85256F0F_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 0050D5EF85256F0F_=--

Date: Tue, 14 Sep 2004 16:41:25 +0200
From: Leo Sauermann <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
Cc: [email-masked]

>
> Also in the debate on this list was listing all entries in UTC.  This
> would eliminate the need for VTIMEZONE in many (all?) components.
> Yet the CUA still needs to do TZ math.  So this is a proposal on
> how to have simple IANA registered time zones so that everyone does
> the same math.

uhhh..
many of todays calendars in VCAL have errors about timezones.
If mozilla/kde/whatever doesn't get it, we rdf developers won't get it, too.

so I would recommend to always store time in local time format with 
timezone, because any UI (cell phone, whatever) then may display it 
without any math.

regards
Leo

To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.
From: [email-masked]
Date: Tue, 14 Sep 2004 10:40:25 -0400

This is a multi-part message in MIME format...

--=_mixed 005061FC85256F0F_=
Content-Type: multipart/alternative; boundary="----------=_1095172780-11730-20"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095172780-11730-20
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

microsoft uses setpos when repeat is 4 monday of month

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 07:18 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
[Ietf-calsify] List issues so far.

       List if ideas (in random order) on this list.

       (1). 2445 - (iCAL) Changes and fixes.

       (1.1) 2445 - Split into separate drafts

       This allows for separation of topics and allows each to make
       it or not to standard.

       (1.1.1) 2445 - Basic which includes VEVENT

       (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.

       (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
       want to do this, we need a more specific proposal.

       (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
       are saying  want  to  do  this,  we  need  a  more  specific
       proposal.

       (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
       that allows this.  Deprecate it?

       (1.1.2.3) 2445 - No more than one RRULE per component?  I think
       we  are  saying  we want to do this, we need a more specific
       proposal.

       (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
       want  to  do this, we need a more specific proposal and will
       involve time zone data being evaluated at CUA only.

       (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
       want to do this.

       (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
       values. (FBTYPE).  Do we need more discussion?

       (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
       this is a compatibility issue as a CUA can or can not use it
       and it does not effect the data or flow of data.  CUAs  that
       can  not  display  the  data  ignore it anyway.  Having this
       property does not break CUAs that do not use it.   How  many
       use this?

       (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
       this is a compatibility issue as a CUA can or can not use it
       and it does not effect the data or flow of data.  Thin CUA's
       can not use it anyway and ignore it.  Having  this  property
       does  not break CUAs that do not use it.  How many use this?

       This eliminates the need to send VTIMEZONE.

       (1.1.2.9) 2445 - Deprecate properties

       (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
       GREGORIAN in scope at this time.

       (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.

       (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
       undefined  meaning  must  be  deprecated  as  there  is   no
       interoperability.

       (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
       to keep this.  See "Access Control" below.

       (1.1.3) 2445 - New VTODO draft

       (1.1.4) 2445 - New VJOURNAL draft

       (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
       them.  Need an exhaustive discussion.

       (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
       proposal on new time zone format for CUAs  to  share  common
       time zone data.  Need more feedback.

       (2) 2446 - (iTIP) Changes and fixes.

       (2.1) 2446 - Simplify updates - settle on one way

       (3) 2447 - (iMIP) Changes and fixes.

       (3.1) 2447 - Specify minimum  MIME support needed

       (4)  New - Access Control

       The  access  control  over  iMIP  is not the same as access
       control needed for client/server transport of objects.  Need
       to define and document.

-- 

------------=_1095172780-11730-20--

--=_mixed 005061FC85256F0F_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 005061FC85256F0F_=--

Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
To: [email-masked]
From: [email-masked]
Date: Tue, 14 Sep 2004 10:23:36 -0400

Got to disagree with you Doug.  Unfortunately, the "replace all" set does
not work with our product and interoperability testing (both external and
internal) has shown that.

We're trying to find a middle ground so that we can consume this if we
receive it and it may or may not be an issue about the standard per se, but
what concerns me is that our implementation is vastly different (when
talking recurring reschedules) from other vendors, yet we all believe that
we follow the ical standard in our products.  So there's probably something
amiss with recurring reschedules in the proposed icalendar standard.

I think we should discuss this further in an open manner.  Does anyone else
have issues with recurring reschedules?
-CS

[email-masked] wrote on 09/13/2004 08:20:20 PM:

>
> So far only Robert seem to think that the method he
> proposes is documented, standardized, or compatible with
> many others.
>
> He did the same thing on the other mailing list and caused
> months of delay. I have found over 40 ical products that
> can not use that method. Fortunately this mailing list is
> not "how can it be done", its "how do people do it".
>
> And currently the vast majority of products simply
> replace the objects during an update keeping the same UID.
>
> I do not think that the issue is stalled. I think
> that it is fairly clear - replacing the objects
> with an entire updated set with the same UID
> works with all vendors (including the one that Roberts
> company ships) I can find. Robert does not seem to
> dispute this, he simply wants everyone to also do
> it the 2nd way - and they do not.
>
>
> >I would like to know what the process is for moving forward on issues
like
> >this. I received a description of this mailing list's purpose but that's

> >about it. If a more detailed description of how conflicts are to
beresolved
> >and how decisions are actually going to be made is available pleasepoint
me
> >to it. (Surely not the same process as the previous ietf-calendar
mailing
> >list?)
> >Thank you.
> [attachment "smime.p7s" deleted by Chris Stoner/Westford/IBM]

Date: Tue, 14 Sep 2004 07:59:25 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 13:59:38 -0000

This is a cryptographically signed message in MIME format.

--------------ms070804090906050901020201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>I agree with the question...
>
>  
>
>>The question we need to ask is:
>>
>>   Do we want to be able to transfer 'sync' an entire calendar in one
>>    
>>
>pass?
>  
>
>>If yes, then we have to allow multiple BEGIN/END per transfer.
>>    
>>
>
>But I disagree with your reasoning.
>
>Transferring an entire calendar in one pass - does not seem to require
>more than one METHOD. If I am publishing an entire calendar, then I have
>one VCALENDAR with METHOD=PUBLISH.  If I am sending a request for you to
>attend a whole calendar's worth of meetings, then I presume I have one
>VCALENDAR with METHOD=REQUEST. 
>
That is one mode of using calendars.

The other is that the data transfer -into- the calendar is automatic.
And the CUA reads from the calendar. For example it is possible
for iTIP REQUESTS to be stored in the CS until processed by the CUA.

Those are client/server CUA/CS's. They must transfer all iTIP methods
objects to/from the CS.  So if you send me a REQUEST, it will be stored
in my calendar, even when my CUA is not running. Later when I start
my CUA it will load my calendar (PUBLISH/REQUEST/ADD/whatever).

Those are the requirements for client/server implementations.

This is not an issue for  iMIP-CUA's as iMIP only allows one METHOD
per object anyway..  For non-iMIP CUAs this will be an issue. Both
models exists. CalDav looks to be a client/server model also.

Ether way it still does not solve the problem that some (1?) 
implementation(s)
split each VEVENT into a separate VCALENDAR objects, even when
all of the METHOD values are the same.

Or is it that only one implementation can not handle multiple BEGIN/END
VCALENDAR even when all have the same METHOD value ?

-- 

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

--------------ms070804090906050901020201--

Date: Tue, 14 Sep 2004 07:44:18 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 13:44:30 -0000

This is a cryptographically signed message in MIME format.

--------------ms090600000501010306050700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

>
> As for synchronization, none of the RFCs nor CAP name that as a 
> purpose, and I think we ought not to get into synchronizing endpoints 
> too much - not only for simplification reasons, but because many have 
> adopted SyncML as a standard and we don't need another one.

It was in the CAP requirements, original copy at:

    http://INET-Consulting.com/draft-ietf-calsch-capreq-04.txt

And it is on the calsch.org web site (at least it used to be).

-- 

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

--------------ms090600000501010306050700--

Date: Mon, 13 Sep 2004 23:15:58 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.

For simplification of transport between endpoints, I think the way that it 
is now is the simplest:
one object beginning with BEGIN:VCALENDAR and ending with END:VCALENDAR, 
everything within those bookends being processed by the same method.

If the object of 'send an entire calendar' is  'send all of the calendar 
objects in their current state', then METHOD:PUBLISH should suffice, 
although perhaps some might want to rename it to METHOD:STORETHISSTUFF 
.  All other METHODs seem to me to be intended to effect a change in a 
calendar. For that reason, I would, if I were writing a client, want to 
receive those in a separate transmission, or at least a separate MIME 
object if I'm receiving them via iMIP. Also remember that the order they're 
received in matters, you can't change an object you haven't received yet.

As for synchronization, none of the RFCs nor CAP name that as a purpose, 
and I think we ought not to get into synchronizing endpoints too much - not 
only for simplification reasons, but because many have adopted SyncML as a 
standard and we don't need another one.

At 08:31 PM 9/13/04, Oren Sreebny wrote:
>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core
>Object is a collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped together."
>
>But implementations don't all support multiple VCALENDAR blocks - for
>instance, in Oracle Cal when you export iCalendar data it surrounds  each
>VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
>nor Outlook will accept that as an import format - they want all the
>VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
>
>- Oren
>
>
>On Mon, 13 Sep 2004, Doug Royer wrote:
>
> >
> >        List if ideas (in random order) on this list.
> >
> >        (1). 2445 - (iCAL) Changes and fixes.
> >
> >        (1.1) 2445 - Split into separate drafts
> >
> >        This allows for separation of topics and allows each to make
> >        it or not to standard.
> >
> >        (1.1.1) 2445 - Basic which includes VEVENT
> >
> >        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
> >
> >        (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
> >        want to do this, we need a more specific proposal.
> >
> >        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
> >        are saying  want  to  do  this,  we  need  a  more  specific
> >        proposal.
> >
> >        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
> >        that allows this.  Deprecate it?
> >
> >        (1.1.2.3) 2445 - No more than one RRULE per component?  I think
> >        we  are  saying  we want to do this, we need a more specific
> >        proposal.
> >
> >        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
> >        want  to  do this, we need a more specific proposal and will
> >        involve time zone data being evaluated at CUA only.
> >
> >        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
> >        want to do this.
> >
> >        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
> >        values. (FBTYPE).  Do we need more discussion?
> >
> >        (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
> >        this is a compatibility issue as a CUA can or can not use it
> >        and it does not effect the data or flow of data.  CUAs  that
> >        can  not  display  the  data  ignore it anyway.  Having this
> >        property does not break CUAs that do not use it.   How  many
> >        use this?
> >
> >        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
> >        this is a compatibility issue as a CUA can or can not use it
> >        and it does not effect the data or flow of data.  Thin CUA's
> >        can not use it anyway and ignore it.  Having  this  property
> >        does  not break CUAs that do not use it.  How many use this?
> >
> >        This eliminates the need to send VTIMEZONE.
> >
> >        (1.1.2.9) 2445 - Deprecate properties
> >
> >        (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
> >        GREGORIAN in scope at this time.
> >
> >        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
> >
> >        (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
> >        undefined  meaning  must  be  deprecated  as  there  is   no
> >        interoperability.
> >
> >        (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
> >        to keep this.  See "Access Control" below.
> >
> >        (1.1.3) 2445 - New VTODO draft
> >
> >        (1.1.4) 2445 - New VJOURNAL draft
> >
> >        (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
> >        them.  Need an exhaustive discussion.
> >
> >        (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
> >        proposal on new time zone format for CUAs  to  share  common
> >        time zone data.  Need more feedback.
> >
> >
> >
> >        (2) 2446 - (iTIP) Changes and fixes.
> >
> >        (2.1) 2446 - Simplify updates - settle on one way
> >
> >
> >
> >        (3) 2447 - (iMIP) Changes and fixes.
> >
> >        (3.1) 2447 - Specify minimum  MIME support needed
> >
> >
> >        (4)  New - Access Control
> >
> >        The  access  control  over  iMIP  is not the same as access
> >        control needed for client/server transport of objects.  Need
> >        to define and document.
> >
> > --
> >

Tim Hare

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
Date: Mon, 13 Sep 2004 18:37:43 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

I agree with the question...

> The question we need to ask is:
> 
>    Do we want to be able to transfer 'sync' an entire calendar in one
pass?
>
> If yes, then we have to allow multiple BEGIN/END per transfer.

But I disagree with your reasoning.

Transferring an entire calendar in one pass - does not seem to require
more than one METHOD. If I am publishing an entire calendar, then I have
one VCALENDAR with METHOD=PUBLISH.  If I am sending a request for you to
attend a whole calendar's worth of meetings, then I presume I have one
VCALENDAR with METHOD=REQUEST.  

The scenario you describe above seems to never need more than one
method.  Only when batching multiple REQUEST/UPDATE/PUBLISH do we get
into needing multiple VCALENDARS. But this is not processing a calendar
so much as processing multiple transactions to a calendar.

Perhaps I'm looking at it more from a client transport interop
perspective again... But if so, then help me understand the real
scenario that leads us to this need.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Monday, September 13, 2004 6:15 PM
To: [email-masked]
Subject: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?

I think its a new issue.

When transferring only booked entries one begin/end works.

However METHOD is global to BEGIN/END VCALENDAR and you can not have a
single BEGIN/END VCALENDAR that contains more than one METHOD value
type.

So, if you are transporting more than one METHOD, you MUST use multiple
BEGIN/END VCALENDAR objects.

iMIP  enforces only one METHOD per MIME object.
So you can not transfer an entire calendar in one iMIP MIME object
anyway.

CAP has a VCALSTORE component that can encapsulate many VCALENDAR
objects as a way to solve that problem.

Do we want to create a wrapper object (VCALSTORE?) so that we can
transfer multiple METHOD VCALENDAR objects?

If not, then implementations that do not accept multiple BEGIN/END
vcalendar objects can not transfer any iTIP object that might be in a
calendar in a single transfer.

Not an answer - just some info...

The question we need to ask is:

    Do we want to be able to transfer 'sync' an entire calendar in one
pass?

If yes, then we have to allow multiple BEGIN/END per transfer.

I think the answer is yes.

Oren Sreebny wrote:

>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core Object is a 
>collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped
together."
>
>But implementations don't all support multiple VCALENDAR blocks - for 
>instance, in Oracle Cal when you export iCalendar data it surrounds  
>each VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither 
>Apple's iCal nor Outlook will accept that as an import format - they 
>want all the VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
>  
>

-- 

Date: Mon, 13 Sep 2004 20:51:58 -0400
From: Keith MacDonald <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.

We consider this to be a bug with our iCal implementation in a few of 
our client products and will almost certainly be changed.

-km

Oren Sreebny wrote:
> Does 1.1.1 include this issue?
> 
> ----------------------
> 
> 2445 says that "The Calendaring and Scheduling Core
> Object is a collection of calendaring and scheduling information.
> Typically, this information will consist of a single iCalendar object.
> However, multiple iCalendar objects can be sequentially grouped together."
> 
> But implementations don't all support multiple VCALENDAR blocks - for
> instance, in Oracle Cal when you export iCalendar data it surrounds  each
> VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
> nor Outlook will accept that as an import format - they want all the
> VEVENTs grouped within a single VCALENDAR block.
> 
> Or is this a new issue?
> 
> - Oren
> 
> 
> On Mon, 13 Sep 2004, Doug Royer wrote:
> 
> 
>>       List if ideas (in random order) on this list.
>>
>>       (1). 2445 - (iCAL) Changes and fixes.
>>
>>       (1.1) 2445 - Split into separate drafts
>>
>>       This allows for separation of topics and allows each to make
>>       it or not to standard.
>>
>>       (1.1.1) 2445 - Basic which includes VEVENT
>>
>>       (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
>>
>>       (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
>>       want to do this, we need a more specific proposal.
>>
>>       (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>>       are saying  want  to  do  this,  we  need  a  more  specific
>>       proposal.
>>
>>       (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>>       that allows this.  Deprecate it?
>>
>>       (1.1.2.3) 2445 - No more than one RRULE per component?  I think
>>       we  are  saying  we want to do this, we need a more specific
>>       proposal.
>>
>>       (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>>       want  to  do this, we need a more specific proposal and will
>>       involve time zone data being evaluated at CUA only.
>>
>>       (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>>       want to do this.
>>
>>       (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>>       values. (FBTYPE).  Do we need more discussion?
>>
>>       (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
>>       this is a compatibility issue as a CUA can or can not use it
>>       and it does not effect the data or flow of data.  CUAs  that
>>       can  not  display  the  data  ignore it anyway.  Having this
>>       property does not break CUAs that do not use it.   How  many
>>       use this?
>>
>>       (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>>       this is a compatibility issue as a CUA can or can not use it
>>       and it does not effect the data or flow of data.  Thin CUA's
>>       can not use it anyway and ignore it.  Having  this  property
>>       does  not break CUAs that do not use it.  How many use this?
>>
>>       This eliminates the need to send VTIMEZONE.
>>
>>       (1.1.2.9) 2445 - Deprecate properties
>>
>>       (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
>>       GREGORIAN in scope at this time.
>>
>>       (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
>>
>>       (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
>>       undefined  meaning  must  be  deprecated  as  there  is   no
>>       interoperability.
>>
>>       (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
>>       to keep this.  See "Access Control" below.
>>
>>       (1.1.3) 2445 - New VTODO draft
>>
>>       (1.1.4) 2445 - New VJOURNAL draft
>>
>>       (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
>>       them.  Need an exhaustive discussion.
>>
>>       (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
>>       proposal on new time zone format for CUAs  to  share  common
>>       time zone data.  Need more feedback.
>>
>>
>>
>>       (2) 2446 - (iTIP) Changes and fixes.
>>
>>       (2.1) 2446 - Simplify updates - settle on one way
>>
>>
>>
>>       (3) 2447 - (iMIP) Changes and fixes.
>>
>>       (3.1) 2447 - Specify minimum  MIME support needed
>>
>>
>>       (4)  New - Access Control
>>
>>       The  access  control  over  iMIP  is not the same as access
>>       control needed for client/server transport of objects.  Need
>>       to define and document.
>>
>>--
>>

--------------------------------------------------------
Software Development Manager, OCS Desktop Calendar Clients
Time management Platform, Server Technologies
Oracle Corp.

Date: Mon, 13 Sep 2004 19:29:20 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 01:29:30 -0000

This is a cryptographically signed message in MIME format.

--------------ms090504000209020309040503
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

So far this is no WG - this is just a mailing list.

The IETF has an ISSUE page/tool , I think that we should use that.

People will need to write drafts, submit them, and get feedback. That
is the process. Until there is a draft, there is nothing do decide.

A simple typo will be noteworthy, but not that relevant as there
will be new drafts written that may take some of the existing text.
A typo list can be used to verify the same mistakes are not taken again.

Another problem is that the compatibly testing has been very limited
so far. A small handful of vendor that could afford to pay the price
to attend is far from an exhaustive compatibility testing.

 I would propose that we (I'll volunteer) to setup some free testing.
Not sure what we need yet.  The results of the commercial testing
have not yet been provided.

Mark Swanson wrote:

>Thanks for the response.
>
>However, I really am wondering what the process is. For example, in the 
>simplest case where we want to fix a 2445 typo and we all agree. Is there a 
>person or group that will maintain _the_ fix list that will be accepted by 
>the IETF. Or is the list simply to be maintained ad-hoc by the people on the 
>mailing list. Or, what... ? I seem to have missed the memo.
>
>Thanks.
>
>  
>

-- 

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

--------------ms090504000209020309040503--

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
Date: Mon, 13 Sep 2004 21:16:28 -0400

Thanks for the response.

However, I really am wondering what the process is. For example, in the 
simplest case where we want to fix a 2445 typo and we all agree. Is there a 
person or group that will maintain _the_ fix list that will be accepted by 
the IETF. Or is the list simply to be maintained ad-hoc by the people on the 
mailing list. Or, what... ? I seem to have missed the memo.

Thanks.

-- 
Free SyncML-capable replacement for Exchange and Outlook
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb

Date: Mon, 13 Sep 2004 19:14:41 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 01:14:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms000201000906030001080200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I think its a new issue.

When transferring only booked entries one begin/end works.

However METHOD is global to BEGIN/END VCALENDAR and
you can not have a single BEGIN/END VCALENDAR that
contains more than one METHOD value type.

So, if you are transporting more than one METHOD,
you MUST use multiple BEGIN/END VCALENDAR objects.

iMIP  enforces only one METHOD per MIME object.
So you can not transfer an entire calendar in
one iMIP MIME object anyway.

CAP has a VCALSTORE component that can encapsulate
many VCALENDAR objects as a way to solve that problem.

Do we want to create a wrapper object (VCALSTORE?) so that
we can transfer multiple METHOD VCALENDAR objects?

If not, then implementations that do not accept multiple BEGIN/END
vcalendar objects can not transfer any iTIP object that might be
in a calendar in a single transfer.

Not an answer - just some info...

The question we need to ask is:

    Do we want to be able to transfer 'sync' an entire calendar in one pass?

If yes, then we have to allow multiple BEGIN/END per transfer.

I think the answer is yes.

Oren Sreebny wrote:

>Does 1.1.1 include this issue?
>
>----------------------
>
>2445 says that "The Calendaring and Scheduling Core
>Object is a collection of calendaring and scheduling information.
>Typically, this information will consist of a single iCalendar object.
>However, multiple iCalendar objects can be sequentially grouped together."
>
>But implementations don't all support multiple VCALENDAR blocks - for
>instance, in Oracle Cal when you export iCalendar data it surrounds  each
>VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
>nor Outlook will accept that as an import format - they want all the
>VEVENTs grouped within a single VCALENDAR block.
>
>Or is this a new issue?
>  
>

-- 

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

--------------ms000201000906030001080200--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] List issues so far.
Date: Mon, 13 Sep 2004 17:40:46 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Oren Sreebny" <[email-masked]>, <[email-masked]>
Cc: 

Good Catch Oren... Perhaps it hasn't been mentioned yet.  I heartily
agree that we should remove this "additionally confusing way" to group
calendar events.  Especially since there is no clear statement of what
it means to do so, or why a CUA would want to...

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Oren
Sreebny
Sent: Monday, September 13, 2004 5:31 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.

Does 1.1.1 include this issue?

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

2445 says that "The Calendaring and Scheduling Core Object is a
collection of calendaring and scheduling information.
Typically, this information will consist of a single iCalendar object.
However, multiple iCalendar objects can be sequentially grouped
together."

But implementations don't all support multiple VCALENDAR blocks - for
instance, in Oracle Cal when you export iCalendar data it surrounds
each VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's
iCal nor Outlook will accept that as an import format - they want all
the VEVENTs grouped within a single VCALENDAR block.

Or is this a new issue?

- Oren

On Mon, 13 Sep 2004, Doug Royer wrote:

>
>        List if ideas (in random order) on this list.
>
>        (1). 2445 - (iCAL) Changes and fixes.
>
>        (1.1) 2445 - Split into separate drafts
>
>        This allows for separation of topics and allows each to make
>        it or not to standard.
>
>        (1.1.1) 2445 - Basic which includes VEVENT
>
>        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
>
>        (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
>        want to do this, we need a more specific proposal.
>
>        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>        are saying  want  to  do  this,  we  need  a  more  specific
>        proposal.
>
>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?
>
>        (1.1.2.3) 2445 - No more than one RRULE per component?  I think
>        we  are  saying  we want to do this, we need a more specific
>        proposal.
>
>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>        want  to  do this, we need a more specific proposal and will
>        involve time zone data being evaluated at CUA only.
>
>        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>        want to do this.
>
>        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>        values. (FBTYPE).  Do we need more discussion?
>
>        (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  CUAs  that
>        can  not  display  the  data  ignore it anyway.  Having this
>        property does not break CUAs that do not use it.   How  many
>        use this?
>
>        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  Thin CUA's
>        can not use it anyway and ignore it.  Having  this  property
>        does  not break CUAs that do not use it.  How many use this?
>
>        This eliminates the need to send VTIMEZONE.
>
>        (1.1.2.9) 2445 - Deprecate properties
>
>        (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
>        GREGORIAN in scope at this time.
>
>        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
>
>        (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
>        undefined  meaning  must  be  deprecated  as  there  is   no
>        interoperability.
>
>        (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
>        to keep this.  See "Access Control" below.
>
>        (1.1.3) 2445 - New VTODO draft
>
>        (1.1.4) 2445 - New VJOURNAL draft
>
>        (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
>        them.  Need an exhaustive discussion.
>
>        (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
>        proposal on new time zone format for CUAs  to  share  common
>        time zone data.  Need more feedback.
>
>
>
>        (2) 2446 - (iTIP) Changes and fixes.
>
>        (2.1) 2446 - Simplify updates - settle on one way
>
>
>
>        (3) 2447 - (iMIP) Changes and fixes.
>
>        (3.1) 2447 - Specify minimum  MIME support needed
>
>
>        (4)  New - Access Control
>
>        The  access  control  over  iMIP  is not the same as access
>        control needed for client/server transport of objects.  Need
>        to define and document.
>
> --
>

Date: Mon, 13 Sep 2004 17:31:26 -0700 (PDT)
From: Oren Sreebny <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] List issues so far.

Does 1.1.1 include this issue?

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

2445 says that "The Calendaring and Scheduling Core
Object is a collection of calendaring and scheduling information.
Typically, this information will consist of a single iCalendar object.
However, multiple iCalendar objects can be sequentially grouped together."

But implementations don't all support multiple VCALENDAR blocks - for
instance, in Oracle Cal when you export iCalendar data it surrounds  each
VEVENT with a BEGIN:VCALENDAR and an END:VCALENDAR. Neither Apple's iCal
nor Outlook will accept that as an import format - they want all the
VEVENTs grouped within a single VCALENDAR block.

Or is this a new issue?

- Oren

On Mon, 13 Sep 2004, Doug Royer wrote:

>
>        List if ideas (in random order) on this list.
>
>        (1). 2445 - (iCAL) Changes and fixes.
>
>        (1.1) 2445 - Split into separate drafts
>
>        This allows for separation of topics and allows each to make
>        it or not to standard.
>
>        (1.1.1) 2445 - Basic which includes VEVENT
>
>        (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.
>
>        (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
>        want to do this, we need a more specific proposal.
>
>        (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
>        are saying  want  to  do  this,  we  need  a  more  specific
>        proposal.
>
>        (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
>        that allows this.  Deprecate it?
>
>        (1.1.2.3) 2445 - No more than one RRULE per component?  I think
>        we  are  saying  we want to do this, we need a more specific
>        proposal.
>
>        (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
>        want  to  do this, we need a more specific proposal and will
>        involve time zone data being evaluated at CUA only.
>
>        (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
>        want to do this.
>
>        (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
>        values. (FBTYPE).  Do we need more discussion?
>
>        (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  CUAs  that
>        can  not  display  the  data  ignore it anyway.  Having this
>        property does not break CUAs that do not use it.   How  many
>        use this?
>
>        (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
>        this is a compatibility issue as a CUA can or can not use it
>        and it does not effect the data or flow of data.  Thin CUA's
>        can not use it anyway and ignore it.  Having  this  property
>        does  not break CUAs that do not use it.  How many use this?
>
>        This eliminates the need to send VTIMEZONE.
>
>        (1.1.2.9) 2445 - Deprecate properties
>
>        (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
>        GREGORIAN in scope at this time.
>
>        (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.
>
>        (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
>        undefined  meaning  must  be  deprecated  as  there  is   no
>        interoperability.
>
>        (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
>        to keep this.  See "Access Control" below.
>
>        (1.1.3) 2445 - New VTODO draft
>
>        (1.1.4) 2445 - New VJOURNAL draft
>
>        (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
>        them.  Need an exhaustive discussion.
>
>        (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
>        proposal on new time zone format for CUAs  to  share  common
>        time zone data.  Need more feedback.
>
>
>
>        (2) 2446 - (iTIP) Changes and fixes.
>
>        (2.1) 2446 - Simplify updates - settle on one way
>
>
>
>        (3) 2447 - (iMIP) Changes and fixes.
>
>        (3.1) 2447 - Specify minimum  MIME support needed
>
>
>        (4)  New - Access Control
>
>        The  access  control  over  iMIP  is not the same as access
>        control needed for client/server transport of objects.  Need
>        to define and document.
>
> --
>

Date: Mon, 13 Sep 2004 18:20:20 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2004 00:20:37 -0000

This is a cryptographically signed message in MIME format.

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

So far only Robert seem to think that the method he
proposes is documented, standardized, or compatible with
many others.

He did the same thing on the other mailing list and caused
months of delay. I have found over 40 ical products that
can not use that method. Fortunately this mailing list is
not "how can it be done", its "how do people do it".

And currently the vast majority of products simply
replace the objects during an update keeping the same UID.

I do not think that the issue is stalled. I think
that it is fairly clear - replacing the objects
with an entire updated set with the same UID
works with all vendors (including the one that Roberts
company ships) I can find. Robert does not seem to
dispute this, he simply wants everyone to also do
it the 2nd way - and they do not.

>I would like to know what the process is for moving forward on issues like 
>this. I received a description of this mailing list's purpose but that's 
>about it. If a more detailed description of how conflicts are to be resolved 
>and how decisions are actually going to be made is available please point me 
>to it. (Surely not the same process as the previous ietf-calendar mailing 
>list?)
>
>Thank you.
>
>  
>

-- 

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

--------------ms040901020002060407050305--

From: Mark Swanson <[email-masked]>
Organization: Web Service Solutions, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
Date: Mon, 13 Sep 2004 20:08:56 -0400

On September 13, 2004 6:42 pm, Doug Royer wrote:
> At his point I am going to consider your posts as trolling.

I would like to know what the process is for moving forward on issues like 
this. I received a description of this mailing list's purpose but that's 
about it. If a more detailed description of how conflicts are to be resolved 
and how decisions are actually going to be made is available please point me 
to it. (Surely not the same process as the previous ietf-calendar mailing 
list?)

Thank you.

-- 
Free SyncML-capable replacement for Exchange and Outlook
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb

Date: Mon, 13 Sep 2004 17:18:25 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] List issues so far.
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 23:18:42 -0000

This is a cryptographically signed message in MIME format.

--------------ms030900010301080607050004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

       List if ideas (in random order) on this list.

       (1). 2445 - (iCAL) Changes and fixes.

       (1.1) 2445 - Split into separate drafts

       This allows for separation of topics and allows each to make
       it or not to standard.

       (1.1.1) 2445 - Basic which includes VEVENT

       (1.1.1.1) 2445 - Make seconds (SS) optional?  Looks like no.

       (1.1.2) 2445 - Simplify recursions.  I think we are  saying  we
       want to do this, we need a more specific proposal.

       (1.1.2.1) 2445 - Do  away  with multiple BY rules?  I think we
       are saying  want  to  do  this,  we  need  a  more  specific
       proposal.

       (1.1.2.2) 2445 - Do we allow BYSETPOS?  I can only find one CUA
       that allows this.  Deprecate it?

       (1.1.2.3) 2445 - No more than one RRULE per component?  I think
       we  are  saying  we want to do this, we need a more specific
       proposal.

       (1.1.2.4) 2445 - All dates to 'Z' ?  I think we are  saying  we
       want  to  do this, we need a more specific proposal and will
       involve time zone data being evaluated at CUA only.

       (1.1.2.5) 2445 - CLASS to new values?  I think we are saying we
       want to do this.

       (1.1.2.6) 2445 - TRANSP  This list wants this tied to free/busy
       values. (FBTYPE).  Do we need more discussion?

       (1.1.2.7) 2445 - ALTREP  I do not think  we  have  proven  that
       this is a compatibility issue as a CUA can or can not use it
       and it does not effect the data or flow of data.  CUAs  that
       can  not  display  the  data  ignore it anyway.  Having this
       property does not break CUAs that do not use it.   How  many
       use this?

       (1.1.2.8) 2445  - ATTACH   I  do  not think we have proven that
       this is a compatibility issue as a CUA can or can not use it
       and it does not effect the data or flow of data.  Thin CUA's
       can not use it anyway and ignore it.  Having  this  property
       does  not break CUAs that do not use it.  How many use this?

       This eliminates the need to send VTIMEZONE.

       (1.1.2.9) 2445 - Deprecate properties

       (1.1.2.9.1) 2445 - GEO  I think we are saying NO, however  only
       GREGORIAN in scope at this time.

       (1.1.2.9.2) 2445 - RELATED-TO  I think we are saying yes.

       (1.1.2.9.3) 2445 - CLASS   I  think  we agree that the current
       undefined  meaning  must  be  deprecated  as  there  is   no
       interoperability.

       (1.1.2.9.4) 2445 - New CLASS  There seems to be a strong desire
       to keep this.  See "Access Control" below.

       (1.1.3) 2445 - New VTODO draft

       (1.1.4) 2445 - New VJOURNAL draft

       (1.1.5) 2445 - NEW VALARM draft  Need to define  when  to  send
       them.  Need an exhaustive discussion.

       (1.1.6) 2445  - How  to  handle  time  zones in CUAs.  I have a
       proposal on new time zone format for CUAs  to  share  common
       time zone data.  Need more feedback.

       (2) 2446 - (iTIP) Changes and fixes.

       (2.1) 2446 - Simplify updates - settle on one way

       (3) 2447 - (iMIP) Changes and fixes.

       (3.1) 2447 - Specify minimum  MIME support needed

       (4)  New - Access Control

       The  access  control  over  iMIP  is not the same as access
       control needed for client/server transport of objects.  Need
       to define and document.

-- 

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

--------------ms030900010301080607050004--

Date: Mon, 13 Sep 2004 16:42:49 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 22:43:03 -0000

This is a cryptographically signed message in MIME format.

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

At his point I am going to consider your posts as trolling.

Does any one (else) have any input on this topic?

-- 

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

--------------ms000401070600010609030604--

To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
From: [email-masked]
Date: Mon, 13 Sep 2004 18:18:07 -0400

This is a multi-part message in MIME format...

--=_mixed 007A53DB85256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095113862-978-323"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095113862-978-323
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

because you said 

>I propose we deprecate that method of updates.

>Just send the new objects as a replacement set.

>Very few implementations support that model of changes. No real 
>interoperablity.
>Almost everyone sends entire replacement objects.

>The 'OR' is part of the problem. More than one way to do the
>same thing is causing some of the incompatibility problems.

Withoug RIDs, you can not make individule changes to instances.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 05:56 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed

[email-masked] wrote:

>by sending a NEW rule you are telling me everything I have is invalid. 
>Throw it away.
>Most of the time what we really want to do is just change a single 
>instance or maybe move the entire meeting set.  In either of these cases 
>we probably do not want to throw out any description changes that already 

>exist on individual instances. 
> 
>
Then why did you say:

>>Thus you should send a cancel and sent the new RULE with a new UID.
>>
>> 
>>
Which throws away the description among ALL other things ?

-- 

------------=_1095113862-978-323--

--=_mixed 007A53DB85256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 007A53DB85256F0E_=--

Date: Mon, 13 Sep 2004 15:56:33 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:56:45 -0000

This is a cryptographically signed message in MIME format.

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

[email-masked] wrote:

>by sending a NEW rule you are telling me everything I have is invalid. 
>Throw it away.
>Most of the time what we really want to do is just change a single 
>instance or maybe move the entire meeting set.  In either of these cases 
>we probably do not want to throw out any description changes that already 
>exist on individual instances. 
>  
>
Then why did you say:

>>Thus you should send a cancel and sent the new RULE with a new UID.
>>
>>    
>>
Which throws away the description among ALL other things ?

-- 

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

--------------ms000207030804010500060502--

To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
From: [email-masked]
Date: Mon, 13 Sep 2004 17:57:03 -0400

This is a multi-part message in MIME format...

--=_mixed 007865FA85256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095112598-978-244"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095112598-978-244
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

It is well documented and discussed last year. 
You mean your product does not use it.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 05:43 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed

[email-masked] wrote:

>You can make changes using the standard RID method.
> 
>
First - that methid is not documented in 244[567], and it is not 
'standard'.

Second - Almost ALL implementation do not do it that way.

So why should we bother considering it?

-- 

------------=_1095112598-978-244--

--=_mixed 007865FA85256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 007865FA85256F0E_=--

To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
From: [email-masked]
Date: Mon, 13 Sep 2004 17:46:18 -0400

This is a multi-part message in MIME format...

--=_mixed 007769EC85256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095111954-978-213"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095111954-978-213
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

by sending a NEW rule you are telling me everything I have is invalid. 
Throw it away.
Most of the time what we really want to do is just change a single 
instance or maybe move the entire meeting set.  In either of these cases 
we probably do not want to throw out any description changes that already 
exist on individual instances. 

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 05:14 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed

That make no sense at all. You effetely have declared
that no one can ever make changes.

I know of no product that does this, why would we want to
change to this method you propose? The idea of this mailing
list is to simplify and make compatible objects. This would make
a huge percentage of products incompatible with the current object
methods.

You would force two sets of objects - the cancel objets followed
by exactly what I said - a replacement set - except
the end CU/CUA would not know they are a replacement set.
What is the advantage over just sending a replacement set?

[email-masked] wrote:

>This is equivalent to sending a cancel on all the events and then 
>resetting the RID values with new dates.
>Thus you should send a cancel and sent the new RULE with a new UID.
> 
>
>------------------------------------------------------------------------
>

-- 

------------=_1095111954-978-213--

--=_mixed 007769EC85256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 007769EC85256F0E_=--

Date: Mon, 13 Sep 2004 15:43:02 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:43:13 -0000

This is a cryptographically signed message in MIME format.

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

[email-masked] wrote:

>You can make changes using the standard RID method.
>  
>
First - that methid is not documented in 244[567], and it is not 'standard'.

Second - Almost ALL implementation do not do it that way.

So why should we bother considering it?

-- 

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

--------------ms090902010104070506060508--

To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
From: [email-masked]
Date: Mon, 13 Sep 2004 17:33:30 -0400

This is a multi-part message in MIME format...

--=_mixed 00763DDF85256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095111187-978-170"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095111187-978-170
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

You can make changes using the standard RID method.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 05:14 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed

That make no sense at all. You effetely have declared
that no one can ever make changes.

I know of no product that does this, why would we want to
change to this method you propose? The idea of this mailing
list is to simplify and make compatible objects. This would make
a huge percentage of products incompatible with the current object
methods.

You would force two sets of objects - the cancel objets followed
by exactly what I said - a replacement set - except
the end CU/CUA would not know they are a replacement set.
What is the advantage over just sending a replacement set?

[email-masked] wrote:

>This is equivalent to sending a cancel on all the events and then 
>resetting the RID values with new dates.
>Thus you should send a cancel and sent the new RULE with a new UID.
> 
>
>------------------------------------------------------------------------
>

-- 

------------=_1095111187-978-170--

--=_mixed 00763DDF85256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 00763DDF85256F0E_=--

Date: Mon, 13 Sep 2004 15:14:21 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 21:14:35 -0000

This is a cryptographically signed message in MIME format.

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

That make no sense at all. You effetely have declared
that no one can ever make changes.

I know of no product that does this, why would we want to
change to this method you propose? The idea of this mailing
list is to simplify and make compatible objects. This would make
a huge percentage of products incompatible with the current object
methods.

You would force two sets of objects - the cancel objets followed
by exactly what I said - a replacement set - except
the end CU/CUA would not know they are a replacement set.
What is the advantage over just sending a replacement set?

[email-masked] wrote:

>This is equivalent to sending a cancel on all the events and then 
>resetting the RID values with new dates.
>Thus you should send a cancel and sent the new RULE with a new UID.
>  
>
>------------------------------------------------------------------------
>

-- 

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

--------------ms090909030406060503030009--

To: [email-masked]
From: [email-masked]
Date: Mon, 13 Sep 2004 16:14:09 -0400
Subject: [Ietf-calsify] sending new RRULE/RDATES should not be allowed 

This is a multi-part message in MIME format...

--=_alternative 006F0B0985256F0E_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

This is equivalent to sending a cancel on all the events and then 
resetting the RID values with new dates.
Thus you should send a cancel and sent the new RULE with a new UID.
--=_alternative 006F0B0985256F0E_=--

To: [email-masked]
Subject: Re: [Ietf-calsify] Changes by RID
From: [email-masked]
Date: Mon, 13 Sep 2004 16:07:17 -0400

This is a multi-part message in MIME format...

--=_mixed 006E590485256F0E_=
Content-Type: multipart/alternative;
	boundary="----------=_1095106011-26400-115"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095106011-26400-115
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I disagree.  Most implimentations allow reschedule/updates of instances 
using the RID values.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 03:58 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
[Ietf-calsify] Changes by RID

[email-masked] wrote:

>Or you just send update using UID/SEQ/DTSTAMP and RID.  The RID is the 
>instance you want to change.
> 
>

I propose we deprecate that method of updates.

Just send the new objects as a replacement set.

Very few implementations support that model of changes. No real 
interoperablity.
Almost everyone sends entire replacement objects.

The 'OR' is part of the problem. More than one way to do the
same thing is causing some of the incompatibility problems.

-- 

------------=_1095106011-26400-115--

--=_mixed 006E590485256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 006E590485256F0E_=--

Date: Mon, 13 Sep 2004 13:58:12 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Changes by RID
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 19:58:23 -0000

This is a cryptographically signed message in MIME format.

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

[email-masked] wrote:

>Or you just send update using UID/SEQ/DTSTAMP and RID.  The RID is the 
>instance you want to change.
>  
>

I propose we deprecate that method of updates.

Just send the new objects as a replacement set.

Very few implementations support that model of changes. No real 
interoperablity.
Almost everyone sends entire replacement objects.

The 'OR' is part of the problem. More than one way to do the
same thing is causing some of the incompatibility problems.

-- 

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

--------------ms060400010601040102010604--

To: [email-masked]
Subject: Re: [Ietf-calsify] reduced RRULE propsoal
From: [email-masked]
Date: Mon, 13 Sep 2004 15:47:06 -0400

This is a multi-part message in MIME format...

--=_mixed 006C7FE785256F0E_=
Content-Type: multipart/alternative; boundary="----------=_1095104800-26400-42"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1095104800-26400-42
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Or you just send update using UID/SEQ/DTSTAMP and RID.  The RID is the 
instance you want to change.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
09/13/2004 03:25 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] reduced RRULE propsoal

Cyrus Daboo wrote:

> Hi Doug,
>
> --On Monday, September 13, 2004 12:07 PM -0600 Doug Royer 
> <[email-masked]> wrote:
>
>> I also would like to restrict an object to zero or one RRULEs.
>>
>> Limit RRULE to one 'BY' rule (as someone else said).
>
>
> Do we do away with BYSETPOS? If so, that prevents a recurrence such as 
> 'the first weekday of the month'. If we keep BYSETPOS then we need to 
> allow it in addition to other BYxxx's in the RRULE.

Good question. I could go ether way.

>
>> We can already have 2 or more objects with the same UID, DTSTAMP,
>> and SEQUENCE that represents more instances of the same series
>> of meetings.  (As done by the ADD method).
>
>
> Here is a general question on the interpretation of the uniqueness of 
> UID/SEQ/RID: what you are suggesting above is that a calstore can have 
> multiple components with the same UID, but with perhaps differing SEQ. 

If they have different SEQ values then they are different revisions of 
the same
series of entries. The largest SEQ value is the newest revision. (see 
iTIP).

If they have the same UID/SEQ/DTSTAMP then they are all part of ONE entry:
If you have a meeting every Monday at 2pm in LOCATION: ROOM-1. Easy.

Now next week you have to meet in ROOM-2.

So you send TWO new objects. The original with an EXDATE of next week.
And a SECOND object with ONE instance for Monday 2pm of next week
with LOCATION: ROOM-2.  Both objects have the same UID/SEQ/DTSTAMP.

> If so, how are you supposed to do synchronisation (between CUA/CS) 
> with those since its not possible to tell the difference between them 
> other than by perhaps looking at the other properties in each component? 

That is the current model. You tell the difference because they all have 
the
same UID/SEQ/DTSTAMP values.

>
> My interpretation of ADD in iTIP was that the CUA that receives the 
> ADD adjusts its copy of the original (master) component by adding an 
> appropriate RDATE for the new instance and then adds a RECURRENCE-ID 
> to its copy of the new instance and stores that. That way the 
> UID/SEQ/RID properties remain unique in the client's store and each 
> component/instance can be uniquely addressed and synchronised.

ADD was added because other things can change and there is no  way
to represent the odd entry (one or more)  in one object (LOCATION for 
example). There
is no way to add LOCATION (for example) to the RDATE or EXDATE
so the only way is to represent that instance in a separate object with
the same UID/SEQ/DTSTAMP.

If multiple objects have the same UID;/SEQ/DTSTAMP then they are all
part of one logical entry. If they are 100% the same, then they are just
duplicates of each other.

You can meet every week day at 2pm in room-1.
Then if only Friday changes to room-2, you would modify
the original object to say Monday-Thursday, LOCATION:room-1
and ADD a second object for Friday only, LOCATION:room-2
All with the same UID/SEQ/DTSTAMP.

If the UID is not the same - not the same object.

If UID is the same and SEQ is not the same - the newer SEQ wins and 
older versions
are replaced.

If UID and SEQ are the same and  DTSTAMP is not the same,
then newer DTSTAMP wins and older DTSTAMPS are replaced as iTIP
says they are newer revisions of the same entry (perhaps spelling error 
fixed).

If UID/SEQ/DTSTAMP are the same - then they are all part
of the same logical entry.

The problem is when an appointment evolves over time. There
needed to be a way to represent that this series of entries really
is the same. You only need RDATE/RRULE/EXDATE when only the
date/time changes. When other things change then you have to
specify the series in multiple objects with same UID/SEQ/DTSTAMP.

-- 

------------=_1095104800-26400-42--

--=_mixed 006C7FE785256F0E_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 006C7FE785256F0E_=--

Date: Mon, 13 Sep 2004 13:25:59 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] reduced RRULE propsoal
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 19:26:12 -0000

This is a cryptographically signed message in MIME format.

--------------ms000701040708090808050100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cyrus Daboo wrote:

> Hi Doug,
>
> --On Monday, September 13, 2004 12:07 PM -0600 Doug Royer 
> <[email-masked]> wrote:
>
>> I also would like to restrict an object to zero or one RRULEs.
>>
>> Limit RRULE to one 'BY' rule (as someone else said).
>
>
> Do we do away with BYSETPOS? If so, that prevents a recurrence such as 
> 'the first weekday of the month'. If we keep BYSETPOS then we need to 
> allow it in addition to other BYxxx's in the RRULE.

Good question. I could go ether way.

>
>> We can already have 2 or more objects with the same UID, DTSTAMP,
>> and SEQUENCE that represents more instances of the same series
>> of meetings.  (As done by the ADD method).
>
>
> Here is a general question on the interpretation of the uniqueness of 
> UID/SEQ/RID: what you are suggesting above is that a calstore can have 
> multiple components with the same UID, but with perhaps differing SEQ. 

If they have different SEQ values then they are different revisions of 
the same
series of entries. The largest SEQ value is the newest revision. (see iTIP).

If they have the same UID/SEQ/DTSTAMP then they are all part of ONE entry:
If you have a meeting every Monday at 2pm in LOCATION: ROOM-1. Easy.

Now next week you have to meet in ROOM-2.

So you send TWO new objects. The original with an EXDATE of next week.
And a SECOND object with ONE instance for Monday 2pm of next week
with LOCATION: ROOM-2.  Both objects have the same UID/SEQ/DTSTAMP.

> If so, how are you supposed to do synchronisation (between CUA/CS) 
> with those since its not possible to tell the difference between them 
> other than by perhaps looking at the other properties in each component? 

That is the current model. You tell the difference because they all have the
same UID/SEQ/DTSTAMP values.

>
> My interpretation of ADD in iTIP was that the CUA that receives the 
> ADD adjusts its copy of the original (master) component by adding an 
> appropriate RDATE for the new instance and then adds a RECURRENCE-ID 
> to its copy of the new instance and stores that. That way the 
> UID/SEQ/RID properties remain unique in the client's store and each 
> component/instance can be uniquely addressed and synchronised.

ADD was added because other things can change and there is no  way
to represent the odd entry (one or more)  in one object (LOCATION for 
example). There
is no way to add LOCATION (for example) to the RDATE or EXDATE
so the only way is to represent that instance in a separate object with
the same UID/SEQ/DTSTAMP.

If multiple objects have the same UID;/SEQ/DTSTAMP then they are all
part of one logical entry. If they are 100% the same, then they are just
duplicates of each other.

You can meet every week day at 2pm in room-1.
Then if only Friday changes to room-2, you would modify
the original object to say Monday-Thursday, LOCATION:room-1
and ADD a second object for Friday only, LOCATION:room-2
All with the same UID/SEQ/DTSTAMP.

If the UID is not the same - not the same object.

If UID is the same and SEQ is not the same - the newer SEQ wins and 
older versions
are replaced.

If UID and SEQ are the same and  DTSTAMP is not the same,
then newer DTSTAMP wins and older DTSTAMPS are replaced as iTIP
says they are newer revisions of the same entry (perhaps spelling error 
fixed).

If UID/SEQ/DTSTAMP are the same - then they are all part
of the same logical entry.

The problem is when an appointment evolves over time. There
needed to be a way to represent that this series of entries really
is the same. You only need RDATE/RRULE/EXDATE when only the
date/time changes. When other things change then you have to
specify the series in multiple objects with same UID/SEQ/DTSTAMP.

-- 

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

--------------ms000701040708090808050100--

Date: Mon, 13 Sep 2004 14:49:40 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] reduced RRULE propsoal

Hi Doug,

--On Monday, September 13, 2004 12:07 PM -0600 Doug Royer <[email-masked]> 
wrote:

> I also would like to restrict an object to zero or one RRULEs.
>
> Limit RRULE to one 'BY' rule (as someone else said).

Do we do away with BYSETPOS? If so, that prevents a recurrence such as 'the 
first weekday of the month'. If we keep BYSETPOS then we need to allow it 
in addition to other BYxxx's in the RRULE.

> We can already have 2 or more objects with the same UID, DTSTAMP,
> and SEQUENCE that represents more instances of the same series
> of meetings.  (As done by the ADD method).

Here is a general question on the interpretation of the uniqueness of 
UID/SEQ/RID: what you are suggesting above is that a calstore can have 
multiple components with the same UID, but with perhaps differing SEQ. If 
so, how are you supposed to do synchronisation (between CUA/CS) with those 
since its not possible to tell the difference between them other than by 
perhaps looking at the other properties in each component?

My interpretation of ADD in iTIP was that the CUA that receives the ADD 
adjusts its copy of the original (master) component by adding an 
appropriate RDATE for the new instance and then adds a RECURRENCE-ID to its 
copy of the new instance and stores that. That way the UID/SEQ/RID 
properties remain unique in the client's store and each component/instance 
can be uniquely addressed and synchronised.

-- 
Cyrus Daboo

Date: Mon, 13 Sep 2004 12:07:10 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] reduced RRULE propsoal
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 18:07:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms060304090905080302080305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Curt Ellmann wrote:

>Would annual recurring events e.g. each year on July 4th be supported?
>Also, would biweekly or bimonthly events be allowed?
>

(1) Annual:

    BYMONTH allows for that.

        DTSTART: 20040101
        RRULE:FREQ=YEARLY;BYMONTH=1

   Or they could be a series of RDATEs.

(2) Weekly or more than once a week.

   The BYDAY rule allow for comma separated values already.

    DTSTART:20040913T120000Z
    RRULE;FREQ=WEEKLY;BYDAY=MO,TH

(3) Monthly or more than once a month:

    MYMONTHDAY supports a comma separated list of dates already.

    DTART:20040913T120000Z
    RRULE:FREQ=MONTHLY;BYMONTHDAY=1,13

I also would like to restrict an object to zero or one RRULEs.

Limit RRULE to one 'BY' rule (as someone else said).

We can already have 2 or more objects with the same UID, DTSTAMP,
and SEQUENCE that represents more instances of the same series
of meetings.  (As done by the ADD method).

Once we all agree, I can write up the new ABNF and submit it.

-- 

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

--------------ms060304090905080302080305--

Date: Mon, 13 Sep 2004 12:46:22 -0500
From: Curt Ellmann <[email-masked]>
Subject: RE: [Ietf-calsify] reduced RRULE propsoal
To: [email-masked]

Would annual recurring events e.g. each year on July 4th be supported?
Also, would biweekly or bimonthly events be allowed?

-curt.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Monday, September 13, 2004 11:37 AM
To: [email-masked]
Subject: [Ietf-calsify] reduced RRULE propsoal

I propose:

(1) We deprecate EXRULE. I have not seen a CUA that allows
the CU to create one. And it can be emulated with EXDATE.

(2) Allow recurrences only for:
      
    Day of month (Every 1st, 2nd, ...)
    Day of week  (Every Sunday, Monday, ...)

-- 

Date: Mon, 13 Sep 2004 11:36:43 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] reduced RRULE propsoal
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2004 17:37:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms050704090405020607050101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I propose:

(1) We deprecate EXRULE. I have not seen a CUA that allows
the CU to create one. And it can be emulated with EXDATE.

(2) Allow recurrences only for:
      
    Day of month (Every 1st, 2nd, ...)
    Day of week  (Every Sunday, Monday, ...)

-- 

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

--------------ms050704090405020607050101--

Date: Fri, 10 Sep 2004 18:08:11 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Cc: [email-masked]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sat, 11 Sep 2004 00:08:29 -0000

This is a cryptographically signed message in MIME format.

--------------ms000608000702030300070901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>I must say that seems like a strange thing to do, just when the
>various tools are starting to get it right. The spec for VTIMEZONE
>seems like a pretty good match for the widely-deployed Olsen
>timezone database. It's maybe slightly hairier than it
>needs to be, in theory; I can imagine pruning the allowed
>RRULE constructs a bit. But in practice, it seems to work
>nicely.
>
>  
>
Part of the debate on this list was to change RRULE. This effected
recurring events across time zones.  Also included in this debate was
how to have the client do TZ math. And VTIMEZONE contains
RRULEs and can include RDATEs.

Also in the debate on this list was listing all entries in UTC.  This
would eliminate the need for VTIMEZONE in many (all?) components.
Yet the CUA still needs to do TZ math.  So this is a proposal on
how to have simple IANA registered time zones so that everyone does
the same math.

I have modeled the proposed XML format to be compatible with the zdump 
output
format from the compiled Olson database. A simple hack to zdump should
be able to produce this XML object directly.

No need to pass the same time zone definition in each component
each time any more.

-- 

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

--------------ms000608000702030300070901--

Subject: Re: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)
From: Dan Connolly <[email-masked]>
To: Libby Miller <[email-masked]>
Organization: World Wide Web Consortium (http://www.w3.org/)
Date: Fri, 10 Sep 2004 17:24:29 -0500
Cc: [email-masked], [email-masked]

On Fri, 2004-09-10 at 02:43, Libby Miller wrote:
> from the new icalendar mailing list.

Have you told them about our repository of timezone data in XML?
 http://www.w3.org/2002/12/cal/#tzd

Would you please? If not you, is anybody else watching both lists?

Hmm... I think I'll just cross-post and hope for the best...

Doug Royer wrote:
> My idea is to deprecate the VTIMEZONE object in VCALENDAR objects

I must say that seems like a strange thing to do, just when the
various tools are starting to get it right. The spec for VTIMEZONE
seems like a pretty good match for the widely-deployed Olsen
timezone database. It's maybe slightly hairier than it
needs to be, in theory; I can imagine pruning the allowed
RRULE constructs a bit. But in practice, it seems to work
nicely.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Date: Fri, 10 Sep 2004 15:59:49 -0600
From: Doug Royer <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Cc: 
Subject: [Ietf-calsify] [Fwd: I-D ACTION:draft-royer-calsch-xmltz-00.txt]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2004 22:00:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms040808080002000408040301
Content-Type: multipart/mixed; boundary="------------050901010906080100080205"

This is a multi-part message in MIME format.
--------------050901010906080100080205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Time Zones in XML
	Author(s)	: D. Royer
	Filename	: draft-royer-calsch-xmltz-00.txt
	Pages		: 15
	Date		: 2004-9-10
	
The iCalendar data format is being updated and included in those
   discussions is the desire to update the time zone information. This
   is a proposal for time zone updates to iCalendar. The time zone
   information will be available in XML format. To comment on this
   document send email to [email-masked] .

   This document also specifies an IANA registration process for time
   zones. No attempt is made to specify any specific time zones as that
   is political information that is out of scope for this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-royer-calsch-xmltz-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-royer-calsch-xmltz-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-royer-calsch-xmltz-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 

--------------050901010906080100080205
Content-Type: Message/External-body;
 name="draft-royer-calsch-xmltz-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-royer-calsch-xmltz-00.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

--------------050901010906080100080205
Content-Type: text/plain;
 name="file:///tmp/nsmail.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="file:///tmp/nsmail.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------050901010906080100080205--

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

--------------ms040808080002000408040301--

Date: Thu, 09 Sep 2004 21:57:44 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] VTIMEZONE - replacement idea
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2004 03:57:56 -0000

This is a cryptographically signed message in MIME format.

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

I submitted draft-royer-calsch-xmltz-00.txt and it should
being showing up in a few days on the IETF announce list.

My idea is to deprecate the VTIMEZONE object in VCALENDAR objects
and only include the TZID.

Then allow applications to find IANA registered time zones
in XML format that describe the named time zone. They can
cache in local storage the TZID/revision and do the timezone
math much easier.

The XML format is a simplified and revision controlled time zone
definition. Instead of including RRULEs, it enumerates the exact
UTC date/time change and its offset in seconds. An application
would just need to find the TZID, scan for a matching time
range and add/subtract from UTC.

The draft has place holders for a URL specification for fetching
by TZID.

-- 

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

--------------ms040408030007050902050305--

Date: Thu, 09 Sep 2004 21:04:34 -0400
To: Nathaniel Borenstein <[email-masked]>
From: [email-masked]
Subject: Re: [Ietf-calsify] Aiding the process (I hope)
Cc: [email-masked]

Can we take the table that Nathaniel posted and/or the XML that I posted, 
and use that to decide which elements need simplification, revision, or 
omission? So far, the only thing that's come close to consensus is the idea 
of using only UTC when exchanging iCalendar objects. I'm sure there are 
others we can come close on. Another useful tactic might be to try to 
enumerate the _minimum_ functions needed based on use cases of "Joe User" 
and "Jane User" on different platforms and decide what elements are needed 
to accomplish those, rather than thinking about what elements are required 
to handle what currently exists in the various implementations. My view, as 
a user, is that even though there's a lot of function in the products out 
there, not all of that function is required for interoperability - perhaps 
there is a "lingua franca" for interoperability which will meet our 
simplification needs.

At 01:10 PM 8/28/04, Nathaniel Borenstein wrote:

>On Aug 26, 2004, at 12:22 AM, [email-masked] wrote:
>
>>In an effort to get a handle on things, I've built this file (attached) 
>>to document the major elements of RCF2445/6/7 and CAP-13. It's in XML, 
>>because....
>
>Although Tim's reasons for xml make sense, naturally the first thing I did 
>was convert it to an HTML table.  So I thought I'd share that with anyone 
>who hasn't actually tried to read the file yet...
>
>
>
>
>
>
>Thanks, Tim.  -- Nathaniel

Tim Hare

Date: Wed, 08 Sep 2004 11:50:44 -0400
From: Cyrus Daboo <[email-masked]>
To: Cameron Stillion <[email-masked]>, [email-masked]
Cc: 
Subject: [Ietf-calsify] Alarm properties and standalone alarm model, was Re: possible VALARM solution?

Hi Cameron,

--On Tuesday, September 7, 2004 11:22 PM -0700 Cameron Stillion 
<[email-masked]> wrote:

> I like the idea of the "off switch" for alarms, especially since we
> implement reminders that way internally... Perhaps this is an extension
> we should adopt in the standard in the spirit of simplicity in the
> flavor of interoperability.  But of course, clients should still be
> smart when alarms are not explicitly disabled.

In my client I ended up implementing two private x-props to handle alarms 
(in particular repeating alarms and alarms on recurring events/to-dos). The 
two are:

1) A status property with three possible values:

   - 'PENDING' - means the alarm is active and the client needs to monitor 
it to see
                 when it is triggered, or whether it should have already 
been triggered
                 (i.e. client session was started after trigger time). 
Determing the next
                 trigger is based on the 'LAST-TRIGGER' property described 
below.

   - 'COMPLETED' - means the alarm has been signaled to the user and there 
is no need
                   for the client to monitor it further. This provides a 
useful shortcut
                   for the client as it means it can ignore the alarm 
altogether - no need
                   to determine trigger time etc

   - 'DISABLED' - means the user has explicitly disabled the alarm so the 
client does not
                  need to monitor it.

2) A 'LAST-TRIGGER' property with a date-time value. This indicates the 
last time the alarm was triggered and is used to track which triggers in a 
repeating alarm have already been signaled. This provides a smart way for 
the client to know whether it needs to signal an alarm that would have 
occurred prior to the current session.

'LAST-TRIGGER' is a necessity in my mind for handling repeating/recurring 
alarms. I think the status indicator is also required, as this thread has 
shown.

In addition I would also like to argue for a change in the VALARM component 
- specifically the ability to have a VALARM be a 'primary' component like 
VEVENT/VTODO etc - i.e. its not limited to being embedded inside another 
component. Part of the current problem with alarms for one user 'leaking 
out' to others is that the alarm data is embedded in the event so it gets 
transported with that event. By separating the alarm from the event, there 
is a clear distinction between the two and less chance of leakage of 
per-user alarm data. The other advantage is that it allows for the option 
to use a 'library' of standard alarm behaviours (e.g. 'five minutes 
before', '30 minutes before' etc) which can then be linked to the 
events(i.e. one alarm component can be used to trigger multiple alarms on 
different events). I suspect most people use pretty much the same type of 
alarm behaviours time after time so this would save on storage.

The big disadvantage to the separate alarm model is maintaining the correct 
links between the alarms and the events/to-dos. Ideally the links should 
only be in the alarm component, say by the use of a 'RELATED-TO' property 
containing the UID of the event/to-do that the alarm applies to (multiple 
'RELATED-TO's would be allowed to enable the alarm 'library' capability).

Obviously this is a significant change to iCal - but I think it would be 
worth it. Note that the current design of caldav actually does split alarms 
out into a separate webdav collection, though there is some debate about 
that. Also, CAP had to go through all kinds of twists in order to be able 
to handle per-user alarms on shared events etc with the current embedded 
alarm model.

-- 
Cyrus Daboo

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Re: possible VALARM solution?
Date: Tue, 7 Sep 2004 23:22:33 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

I like the idea of the "off switch" for alarms, especially since we
implement reminders that way internally... Perhaps this is an extension
we should adopt in the standard in the spirit of simplicity in the
flavor of interoperability.  But of course, clients should still be
smart when alarms are not explicitly disabled.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, September 07, 2004 6:09 PM
To: [email-masked]
Subject: [Ietf-calsify] Re: possible VALARM solution?

[email-masked] wrote:

> Right - but _adding_  objects/components/properties takes us away from

> our simplification goal, and simplification is being discussed to 
> improve interoperability.

Yes it adds. Interoperability is the other goal. And that is part of
this debate.

Its simply a standardized way to tag the data so that cross vendors can
tell tell that the CU already answered your questions.

If you get a PUBLISH with a VALARM, the user says don't set them.
Do you delete the alarm and store the object without the alarm?
Or do you somehow remember that the alarm is to be ignored?

Now you get an update to that PUBLISHed object (which still contains its
valarm) , the LOCATION is changed, do you ask again?

Or do you remember that you said no to the alarm? How? Does your way
work with another vendor?

If you deleted the valarm then the new update looks like a new alarm -
correct?
So you ask again and delete it again?

The CAP solution was to store the VALARM with a ENABLE=FALSE parameter
and not delete the valarm. Now you know that UID:123 VALARM is to be
ignored from any vendors CUA no matter how may updates are sent to the
same object.

This also solves the problem of unwanted action types
(PROCEDURE/AUDIO/...) alarms
from imported alarms that may be updated over time. The CUA can always
set PROCEDURE alarms to disabled in a way that other CUAs can tell.

Its not simple if its not interoperable.

-- 

To: Elias Sinderson <[email-masked]>
Subject: Re: [Ietf-calsify] Event classes
From: [email-masked]
Date: Tue, 7 Sep 2004 21:44:19 -0400
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format...

--=_alternative 00098D3F85256F09_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I agree.

Elias wrote: 
<snip> 
>Defining new access control mechanisms for iCal 
>introduces unnecessary complexity, fractures the existing specification 
>landscape and takes us farther away from the stated goal of 
>interoperability and standardization.

Pregen

Elias Sinderson <[email-masked]> 
Sent by: [email-masked]
09/07/2004 13:00

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] Event classes

Doug Royer wrote:

> Great idea. New implementations will know what to do with them. RFC 
> 2445 defined the CLASS value to include 'iana-token'.
> Existing implementations should default to PUBLIC as defined in 2445 
> for CLASS when they do not understand the value.
> And we deprecate CONFIDENTIAL and PRIVATE. 

+1 - given that there is no interoperability wit respect to CONFIDENTIAL 
and PRIVATE event classes among existing implementations, they should be 
deprecated. Also, it should be noted that introducing additional event 
classes does not further the interoperability goals of the iCal 
standardization effort.

Personally, I do not feel that it is appropriate to definine access 
control mechanisms within this specification at all. Servers should 
implement and utilize existing interoperable access control mechanisms 
for iCal access. Defining new access control mechanisms for iCal 
introduces unnecessary complexity, fractures the existing specification 
landscape and takes us farther away from the stated goal of 
interoperability and standardization.

Regards,
Elias

--=_alternative 00098D3F85256F09_=--

Date: Tue, 07 Sep 2004 19:08:39 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Re: possible VALARM solution?
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2004 01:08:53 -0000

This is a cryptographically signed message in MIME format.

--------------ms020502010205020204030806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

> Right - but _adding_  objects/components/properties takes us away from 
> our simplification goal, and simplification is being discussed to 
> improve interoperability. 

Yes it adds. Interoperability is the other goal. And that is part of 
this debate.

Its simply a standardized way to tag the data so that cross vendors can tell
tell that the CU already answered your questions.

If you get a PUBLISH with a VALARM, the user says don't set them.
Do you delete the alarm and store the object without the alarm?
Or do you somehow remember that the alarm is to be ignored?

Now you get an update to that PUBLISHed object (which still
contains its valarm) , the LOCATION is changed, do you ask again?

Or do you remember that you said no to the alarm? How? Does your
way work with another vendor?

If you deleted the valarm then the new update looks like a new alarm - 
correct?
So you ask again and delete it again?

The CAP solution was to store the VALARM with a ENABLE=FALSE
parameter and not delete the valarm. Now you know that UID:123 VALARM is 
to be ignored
from any vendors CUA no matter how may updates are sent to the same object.

This also solves the problem of unwanted action types 
(PROCEDURE/AUDIO/...) alarms
from imported alarms that may be updated over time. The CUA can always set
PROCEDURE alarms to disabled in a way that other CUAs can tell.

Its not simple if its not interoperable.

-- 

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

--------------ms020502010205020204030806--

Date: Tue, 07 Sep 2004 20:05:35 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Fwd: Re: [Ietf-calsify] possible VALARM solution?]

Right - but _adding_  objects/components/properties takes us away from our 
simplification goal, and simplification is being discussed to improve 
interoperability.

The many pieces of CAP are there to try to accomodate almost everything 
that existing implementations do - which is a different way to accomplish 
interoperability, but not a simple one.

At 02:13 PM 9/7/04, Doug Royer wrote:

>CAP adds a LOCAL and ENABLE objects to VALARM for just that purpose

Tim Hare

Date: Tue, 07 Sep 2004 12:13:56 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: [Fwd: Re: [Ietf-calsify] possible VALARM solution?]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 18:14:10 -0000

This is a cryptographically signed message in MIME format.

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

[resend - sent to wrong list...]

[email-masked] wrote:

> It would be desirable for the UI of a CUA to ask you, at import/open 
> time, whether you want to:
>
>         1. Ignore alarms entirely - don't set them.
>         2. Import the alarms using client defaults
>         3. Ask the user what kind of alarm to set, for each one imported
>
> UIs of course, are outside of the scope of the simplification work - 
> but the above 3 choices would work whether we retain the transmission 
> of VALARMs, or we simplify by having a REMINDER=YES/NO 
> parameter/property.

CAP adds a LOCAL and ENABLE objects to VALARM for just that purpose.

-- 

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

--------------ms010708030404060606080403--

Date: Tue, 07 Sep 2004 11:42:57 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] (past alarms) possible VALARM solution?
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 17:43:14 -0000

This is a cryptographically signed message in MIME format.

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

Cameron Stillion wrote:

>The published calendar is more to the point.  Firing lots of past event
>alarms will not help you make the meeting, it will only cause noise that
>you will likely dismiss inadvertently to avoid the potentially many
>other pointless alarms.  Even so, this is a very small edge case of
>importing these events *just* as the event is starting.  Your CUA could
>realistically be smart enough to fire alarms for events that are also in
>process.
>  
>
That is an implementation detail - not a protocol issue or an object issue.

The purpose of iCAL is to define how to transport calendar objects.
Clearly VALARM is one of the successful objects being transported
at this time.

I can see a usage document for interpersonal calendaring describing
how/when/if a VALARM should be transported. However VALARM
is clearly compatible with many implementations at this time. So I do
not think that it is in scope to consider eliminating them entirely. And
if you can not transport them, that is the same effect.

I could PUBLISH a project calendar, with the alarms sending email
to the team members with the VEVENTS and VTODO and any VALARMs
being updated by the team leader. So again I can see a document
listing the pro's and con's of when to send VALARMs.

-- 

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

--------------ms080903010506080803060907--

Date: Tue, 07 Sep 2004 11:26:52 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] possible VALARM solution?
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2004 17:27:05 -0000

This is a cryptographically signed message in MIME format.

--------------ms080005000900040504020100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

> In response to both Cameron and Doug....
>
> I don't see a case for PDAs to use CAP that much - 

That was one of the CAP requirements.

And even if PDA's do not use CAP, many still use VCALENDAR objects.
And transporting the alarms is done at this time.

>
> Even if we _do_ want to use CAP, transporting VALARMS  is fraught with 
> other problems - since a PDA and sometimes other CUAs can be 
> implemented on different platforms from the CS, we have to add 
> complexity so that one end of the conversation can indicate what it 
> can/cannot do in relation to VALARMS ( "don't send me executables", "I 
> can't make sounds", and the like). 

In the client/server model - you have to transport VALARMS with CAP, 
else you have no alarms.
CAP only transports VALARMS to be used by one or more CUAs. So if CAP did
not transport them, you could not have any in your own calendar.

-- 

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

--------------ms080005000900040504020100--

Date: Tue, 07 Sep 2004 10:00:09 -0700
From: Elias Sinderson <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event classes

Doug Royer wrote:

> Great idea. New implementations will know what to do with them. RFC 
> 2445 defined the CLASS value to include 'iana-token'.
> Existing implementations should default to PUBLIC as defined in 2445 
> for CLASS when they do not understand the value.
> And we deprecate CONFIDENTIAL and PRIVATE. 

+1 - given that there is no interoperability wit respect to CONFIDENTIAL 
and PRIVATE event classes among existing implementations, they should be 
deprecated. Also, it should be noted that introducing additional event 
classes does not further the interoperability goals of the iCal 
standardization effort.

Personally, I do not feel that it is appropriate to definine access 
control mechanisms within this specification at all. Servers should 
implement and utilize existing interoperable access control mechanisms 
for iCal access. Defining new access control mechanisms for iCal 
introduces unnecessary complexity, fractures the existing specification 
landscape and takes us farther away from the stated goal of 
interoperability and standardization.

Regards,
Elias

Date: Tue, 07 Sep 2004 10:30:48 -0400
To: [email-masked]
From: [email-masked]
Subject: RE: [Ietf-calsify] possible VALARM solution?

It would be desirable for the UI of a CUA to ask you, at import/open time, 
whether you want to:

         1. Ignore alarms entirely - don't set them.
         2. Import the alarms using client defaults
         3. Ask the user what kind of alarm to set, for each one imported

UIs of course, are outside of the scope of the simplification work - but 
the above 3 choices would work whether we retain the transmission of 
VALARMs, or we simplify by having a REMINDER=YES/NO parameter/property.

I've left out option 4,  Import the alarms exacly as the server sent them. 
That can only work if there is enough other complexity to determine if the 
client is a compatible platform, so it doesn't work with our goal of 
simplification.

At 09:37 AM 9/7/04, you wrote:
>Let's walk through the rest of your scenario...
>
>If you mean, importing an entire list of shared events (a published
>calendar of customer meetings) into your own calendar, or accepting a
>meeting request for that customer meeting.
>
>The meeting request is more personal, and arguably SHOULD turn on an
>alarm, but using the client's defaults - not the senders.
>
>The published calendar is more to the point.  Firing lots of past event
>alarms will not help you make the meeting, it will only cause noise that
>you will likely dismiss inadvertently to avoid the potentially many
>other pointless alarms.  Even so, this is a very small edge case of
>importing these events *just* as the event is starting.  Your CUA could
>realistically be smart enough to fire alarms for events that are also in
>process.
>
>Cameron
>
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Doug Royer
>Sent: Monday, September 06, 2004 11:46 AM
>To: [email-masked]
>Subject: Re: [Ietf-calsify] possible VALARM solution?
>
>
> >But then, this very reasonable ask has gotten us right back where we
> >were - all VALARMS that occur in the past *should* be suppressed
> >(right?) - or else we have the less-than-desirable Netscape
> >experience... and then again, if I'm in a different building (or a
> >different time zone), I will likely want to adjust my reminders to be
> >earlier anyway.  The context of the reminder is very client-centric.
> >And once again, I find the feature dubious.
> >
> >
>I think that is a user preference. I may want to see what I forgot to go
>to when I get back late from a meeting.
>
>I would rather show up 5 minutes late to a meeting with a customer than
>not at all just because I was not running the CUA at the exact alarm
>trigger time.
>
>--
>

Tim Hare

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] possible VALARM solution?
Date: Tue, 7 Sep 2004 06:37:04 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

Let's walk through the rest of your scenario...

If you mean, importing an entire list of shared events (a published
calendar of customer meetings) into your own calendar, or accepting a
meeting request for that customer meeting.  

The meeting request is more personal, and arguably SHOULD turn on an
alarm, but using the client's defaults - not the senders.  

The published calendar is more to the point.  Firing lots of past event
alarms will not help you make the meeting, it will only cause noise that
you will likely dismiss inadvertently to avoid the potentially many
other pointless alarms.  Even so, this is a very small edge case of
importing these events *just* as the event is starting.  Your CUA could
realistically be smart enough to fire alarms for events that are also in
process.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Monday, September 06, 2004 11:46 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] possible VALARM solution?

>But then, this very reasonable ask has gotten us right back where we 
>were - all VALARMS that occur in the past *should* be suppressed
>(right?) - or else we have the less-than-desirable Netscape 
>experience... and then again, if I'm in a different building (or a 
>different time zone), I will likely want to adjust my reminders to be 
>earlier anyway.  The context of the reminder is very client-centric.
>And once again, I find the feature dubious.
>  
>
I think that is a user preference. I may want to see what I forgot to go
to when I get back late from a meeting.

I would rather show up 5 minutes late to a meeting with a customer than
not at all just because I was not running the CUA at the exact alarm
trigger time.

-- 

Date: Mon, 06 Sep 2004 22:01:53 -0400
To: [email-masked]
From: [email-masked]
Subject: RE: [Ietf-calsify] possible VALARM solution?

In response to both Cameron and Doug....

I don't see a case for PDAs to use CAP that much - they either seem to be 
their own Calendar Service (i.e. the user uses _only_ the PDA for 
calendaring), or they are an adjunct to the desktop CUA and the 
communication between PDA and desktop is more in the realm of SyncML. I 
could be wrong on this point, but that's how I see it.

Even if we _do_ want to use CAP, transporting VALARMS  is fraught with 
other problems - since a PDA and sometimes other CUAs can be implemented on 
different platforms from the CS, we have to add complexity so that one end 
of the conversation can indicate what it can/cannot do in relation to 
VALARMS ( "don't send me executables", "I can't make sounds", and the like).

So, while I don't necessarily think that transporting alarms is a good 
idea,   I think that transporting the need for an alarm is probably the 
best simplification we could come up with.

Tim Hare

Date: Mon, 06 Sep 2004 12:46:22 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] possible VALARM solution?
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 18:46:34 -0000

This is a cryptographically signed message in MIME format.

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

>But then, this very reasonable ask has gotten us right back where we
>were - all VALARMS that occur in the past *should* be suppressed
>(right?) - or else we have the less-than-desirable Netscape
>experience... and then again, if I'm in a different building (or a
>different time zone), I will likely want to adjust my reminders to be
>earlier anyway.  The context of the reminder is very client-centric.
>And once again, I find the feature dubious.
>  
>
I think that is a user preference. I may want to see what I forgot to go to
when I get back late from a meeting.

I would rather show up 5 minutes late to a meeting with a customer
than not at all just because I was not running the CUA at the exact
alarm trigger time.

-- 

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

--------------ms000303000305050008040902--

Date: Mon, 06 Sep 2004 12:42:13 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] possible VALARM solution?
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 18:42:25 -0000

This is a cryptographically signed message in MIME format.

--------------ms020909070107090402080207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

CAP adds the LOCAL parameter (boolean) to indicate if a VALARM
is to be local to the CS. They exist so that a CU can add VALARMs
that only they see. These VALARMs are never transported to
other CUs (however they may be transported to other CUAs or CSs.)

If I have a local VALARM on my desktop, I DO want it transported
to my PDA. however not when I transport the appointment
to a 2nd or 3rd party.

So VALARM do need to be able to be transported across vendor
implementations.

[email-masked] wrote:

> Here's an idea for simplification of the "VALARM problem".
>
> The originator of a calendar object (meeting, to-do item, appointment) 
> may desire that someone be reminded of such an event, which I feel is 
> a valid option to have - if I schedule a staff meeting on a regular 
> schedule, far in advance, I might like to indicate that all employees 
> be reminded of it on that day. However, as many have pointed out, the 
> methods of notification should be part of the UI.  My proposal for 
> simplification, then, is that each component have a simple, binary 
> property, or a parameter of the component, which is a YES/NO value for 
> 'remind the attendee/originator of this object'.  If that property is 
> set to YES, then the UI is responsible for asking the UI owner how 
> they want to be reminded about that object.

-- 

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

--------------ms020909070107090402080207--

Date: Mon, 06 Sep 2004 12:30:10 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event classes
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 18:30:24 -0000

This is a cryptographically signed message in MIME format.

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

Great idea. New implementations will know what to do with them.
RFC 2445 defined the CLASS value to include 'iana-token'.

Existing implementations should default to PUBLIC as defined in 2445
for CLASS when they do not understand the value.

And we deprecate CONFIDENTIAL and PRIVATE.

>
> OWNERONLY - as per your definition (2)
> DELEGATES - as per your definition (3) 

-- 

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

--------------ms020400060000020305010909--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] possible VALARM solution?
Date: Sun, 5 Sep 2004 20:47:17 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

I think having a sender-defined suggested reminder is a reasonable
feature, though I do not find it all that compelling.  Assuming we agree
that the standard should address this particular feature, I just want to
point out that the UI could also decide not to bother the poor user who
might easily be importing ALL 27 of his team's recurring events for the
lifetime of the product cycle (since he is just joining the team, for
instance).  We must think about these features in terms of scale.

But then, this very reasonable ask has gotten us right back where we
were - all VALARMS that occur in the past *should* be suppressed
(right?) - or else we have the less-than-desirable Netscape
experience... and then again, if I'm in a different building (or a
different time zone), I will likely want to adjust my reminders to be
earlier anyway.  The context of the reminder is very client-centric.
And once again, I find the feature dubious.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, September 05, 2004 7:28 PM
To: [email-masked]
Subject: [Ietf-calsify] possible VALARM solution?

Here's an idea for simplification of the "VALARM problem".

The originator of a calendar object (meeting, to-do item, appointment)
may desire that someone be reminded of such an event, which I feel is a
valid option to have - if I schedule a staff meeting on a regular
schedule, far in advance, I might like to indicate that all employees be
reminded of it on that day. However, as many have pointed out, the
methods of notification should be part of the UI.  My proposal for
simplification, then, is that each component have a simple, binary
property, or a parameter of the component, which is a YES/NO value for
'remind the attendee/originator of this object'.  If that property is
set to YES, then the UI is responsible for asking the UI owner how they
want to be reminded about that object.

Comments?

Tim Hare

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Event classes
Date: Sun, 5 Sep 2004 20:35:43 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: 

This is similar to the TRANSP problem - we have existing values that
don't quite match implementations and that are quite difficult to grasp.
We need better values to clarify, but we also want existing software to
not have to be rewritten.

PUBLIC is clearly understood and wants no clarification.  PRIVATE and
CONFIDENTIAL mean different things to different implementations - but
this is the whole reason why iCal is not yet a standard.  This is
EXACTLY why calsify exists!  Let us bring to bear the collective brains
of this forum to define these in a way that CAN make sense and that we
can call STANDARD.  All previous implementations will be struggling
anyway to interop, and it is very clear why.

Personally, I tend toward the three visibility labels also in use in
modern computer programming languages: 
	PUBLIC - visible to all
	PROTECTED - visible to me and a few other special entities
	PRIVATE - visible only to me

Various flavors of protected could be concocted, leading to the FRIEND
list and other client-specific notions, but the tag would suffice.  In
all honesty, I don't care if protected is named "CONFIDENTIAL", but I
find it clearer as it is stated above.  Maybe it's because I'm a
programmer, but isn't that really our audience here?

I think we can come to a fairly quick resolution on the names of these
values - but I think there is a more important question afoot.  When do
we transport these properties?  This comes back to the various reasons
we use iCal...

As usual, all these properties make sense to store and transport when
iCal is used by an individual to access their own store.  When I publish
a calendar to a "public" recipient, the answer is moot.  

But What about a private (or other *protected* flavor)? Do the events
reflect their initial visibility? Can the recipient tell if they can see
an appointment because they are special?  Even more interesting is the
meeting request/response case - perhaps an event is private to me
because of the nature of the meeting (e.g. legal consultation) so I mark
it as such.  Obviously the recipient of the request would also see the
event, but may or may not consider it the same level of visibility.  

I would suggest that shared data is always public as far as the
recipient is concerned, especially since the nature of this property is
explicitly NOT to enforce access or visibility but merely to suggest
ways the CUA / CS can avoid doing the wrong thing.  Also, because of
this nature, once data leaves the comfort of its home and goes across
the wire to another client, all bets are off.  Only crypto will solve
that problem, and that is beyond the scope of this property and this
standard.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Sunday, September 05, 2004 4:20 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ietf-calsify] Event classes

Hi Tim,

--On Sunday, September 5, 2004 4:45 PM -0400 [email-masked] wrote:

>          1. PUBLIC - anyone can read this item and see the details
>          2. PRIVATE- only myself and people I delegate can see the 
> details, others can see that time is blocked
>          3. CONFIDENTIAL- only I can see the details, others can see 
> that time is blocked

Your interpretation of PRIVATE & CONFIDENTIAL is not what others have. 
Personally I thought of those in the same way you do, however I found
out that some implementations treat them the other way around (i.e.
PRIVATE is owner only, CONFIDENTIAL is owner + delegates). So it may
well be that the current PRIVATE and CONFIDENTIAL values cannot be
explicitly defined in an interoperable way, and we may need new values,
e.g.:

OWNERONLY - as per your definition (2)
DELEGATES - as per your definition (3)

I don't think there is an issue with PUBLIC.

Date: Sun, 05 Sep 2004 22:28:15 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] possible VALARM solution?

Here's an idea for simplification of the "VALARM problem".

The originator of a calendar object (meeting, to-do item, appointment) may 
desire that someone be reminded of such an event, which I feel is a valid 
option to have - if I schedule a staff meeting on a regular schedule, far 
in advance, I might like to indicate that all employees be reminded of it 
on that day. However, as many have pointed out, the methods of notification 
should be part of the UI.  My proposal for simplification, then, is that 
each component have a simple, binary property, or a parameter of the 
component, which is a YES/NO value for 'remind the attendee/originator of 
this object'.  If that property is set to YES, then the UI is responsible 
for asking the UI owner how they want to be reminded about that object.

Comments?

Tim Hare

Date: Sun, 05 Sep 2004 22:21:34 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] transport format as subset of interactive format?

iTIP was the "transport-independent" format, and iCalendar was the format 
for the calendar objects - I think these two concepts are useful. I do 
think, however, that we are having serious problems trying to add outer 
layers to this (and I do think layered approaches work well, usually). In 
traditonal layered "things", each outer layer provides an envelope, and 
doesn't really care what the contents of the envelope are. In calendaring, 
however, it's hard to add an outer layer to exchange calendar objects, 
without reference to the objects - for example, you can't easily have a 
protocol layer for scheduling a meeting without the dates and times being 
exposed to that layer of the protocol.

I think that the interactive protocol (CAP) is _intended_  to be an outer 
layer for iTIP, but it does add a lot of new components, properties, and or 
values - and therefore a lot of complexity. I think that it's useful to 
consider how these all should relate - and perhaps IF we can layer these, 
rework things into layers. To that end, I would propose that we take the 
major elements list (and many thanks for the HTML table, by the way) and 
try to add two things to each element:

         A. What "protocol layer" the element has to be part of, if 
any,  using three(?) layers of iCalendar, iTIP, and the application layer
         B. What "level" the element has to be part of - level 0 being the 
most basic interoperability layer
             (and I guess we ought to define how many levels and what they are)

At 11:26 AM 8/30/04, Nathaniel Borenstein wrote:
>It's starting to sound to me like the transport format should be a 
>*subset* of the interactive access format.  Is that a useful thing to 
>consider in simplifying the documents?  -- Nathaniel
>
>On Aug 29, 2004, at 10:47 PM, Bernard Desruisseaux wrote:
>
>>Cameron Stillion wrote:
>>
>>>I would like to suggest the removal of VALARM from the iCal spec.
>>>  I have yet to hear or come up with a good scenario that includes sending
>>>alarm information from one client to another.
>>
>>Cameron,
>>
>>Here's a good scenario:
>>
>>1- I'm invited to a meeting.
>>
>>2- I synchronize my SyncML device.
>>
>>3- Since the calendar server knows that I want reminders
>>    with a 10 minutes lead time, the VEVENT uploaded to
>>    my SyncML device will contain a VALARM specifying an
>>    alarm 10 minutes prior the VEVENT start time.
>>
>>Don't ask me for a good scenario in the context of iTIP.
>>In my opinion, VALARM should not be used in the context
>>of iTIP. If you receive an iTIP message with a VALARM
>>just ignore it.
>>
>>Cheers,
>>Bernard
>>

Tim Hare

Date: Sun, 05 Sep 2004 19:19:54 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Ietf-calsify] Event classes
Cc: 

Hi Tim,

--On Sunday, September 5, 2004 4:45 PM -0400 [email-masked] wrote:

>          1. PUBLIC - anyone can read this item and see the details
>          2. PRIVATE- only myself and people I delegate can see the
> details, others can see that time is blocked
>          3. CONFIDENTIAL- only I can see the details, others can see that
> time is blocked

Your interpretation of PRIVATE & CONFIDENTIAL is not what others have. 
Personally I thought of those in the same way you do, however I found out 
that some implementations treat them the other way around (i.e. PRIVATE is 
owner only, CONFIDENTIAL is owner + delegates). So it may well be that the 
current PRIVATE and CONFIDENTIAL values cannot be explicitly defined in an 
interoperable way, and we may need new values, e.g.:

OWNERONLY - as per your definition (2)
DELEGATES - as per your definition (3)

I don't think there is an issue with PUBLIC.

-- 
Cyrus Daboo

Date: Sun, 05 Sep 2004 16:45:37 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] Event classes

In my opinion, there are two things to be done regarding CLASS:

         1. Define the meaning of the three values explicitly
         2. Let implementations handle the values

I'm not going to read the spec here, I'm going to reason from past 
experience (a mainframe calendaring product-that-was-not-PROFS) and say 
good definitions for the three values are:

         1. PUBLIC - anyone can read this item and see the details
         2. PRIVATE- only myself and people I delegate can see the details, 
others can see that time is blocked
         3. CONFIDENTIAL- only I can see the details, others can see that 
time is blocked

Use cases:
         1. PUBLIC - a meeting on my schedule
         2. PRIVATE- an appointment regarding contract negotiations on my 
schedule
         3. CONFIDENTIAL- an appointment for a medical screening

To me, the idea of CLASS is to indicate roughly how this item should be 
handled;  the implementation can use whatever mechanisms that they would 
like to provide this handling. There is no guarantee that a particular 
implementation will handle CONFIDENTIAL or PRIVATE correctly - but then, 
the market should take care of those cases, no? Or the legal system after 
Joe Users' CONFIDENTIAL appointment with his mistress is revealed to the 
PUBLIC (i.e.  Mrs. User!).

Tim Hare

To: <[email-masked]>
From: [email-masked]
Date: Fri, 3 Sep 2004 11:09:46 -0400
Subject: [Ietf-calsify] rfc 2445 VTimeZone document clarificatioin

This is a multi-part message in MIME format...

--=_alternative 005320FD85256F04_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

4.6.5 Time Zone Component
....

   The "VTIMEZONE" calendar component MUST be present if the iCalendar
   object contains an RRULE that generates dates on both sides of a time
   zone shift (e.g. both in Standard Time and Daylight Saving Time)
   unless the iCalendar object intends to convey a floating time (See
   the section "4.1.10.11 Time" for proper interpretation of floating
   time). It can be present if the iCalendar object does not contain
   such a RRULE. In addition, if a RRULE is present, there MUST be valid
   time zone information for all recurrence instances.

The last line "

In addition, if a RRULE is present, there MUST be valid
   time zone information for all recurrence instances."

should be removed. 
The description above that line is complete.  The last line only adds 
confusion about floating times.
Floating times are events such as I run from 8am to 9am no mater where I 
am.

--=_alternative 005320FD85256F04_=--

To: [email-masked]
From: [email-masked]
Date: Thu, 2 Sep 2004 16:03:52 -0400
Subject: [Ietf-calsify] Interop results

This is a multi-part message in MIME format...

--=_alternative 006E37CF85256F03_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I wanted to give the list a status update on the interop results.  I am 
waiting on a reply back from one of the participants of the interop.  They 
expect to have the results back to me within two weeks. They got caught up 
in "work" (surprise - don't we all) and they are traveling to boot.

I have enough details that I can post what is working/not working, (based 
on all 4 interops) but if I include their last minute details we have a 
bunch more data.  I'd like to include that information because it relates 
to TODO's. 

I'll post another status update early next week.
--=_alternative 006E37CF85256F03_=--

Date: Thu, 02 Sep 2004 09:02:43 +0200
From: Harrie Hazewinkel <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Cc: [email-masked]

Bernard Desruisseaux wrote:
> Harrie Hazewinkel wrote:
>> Bernard Desruisseaux wrote:
> 
> Would you mind sharing your custom properties?

It are 2 properties.

First property is telling the application if the user is the owner
  (that way we allow all operations).
Second property is telling the application which operation he may
do, invite/respond.

Maybe some duplication you have, but we also choose
a simple ACL mechanism handled by the application.
The server is more strict, but we believed it would not make
sense to provide to much ACL details to a user.

cheers,
Harrie

Date: Wed, 01 Sep 2004 17:15:03 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: All the ways we use iCal  (was:  [Ietf-calsify] Event class)
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2004 23:15:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms050508010206090406020606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>That is a great clarification of the EVENT CLASS problem.
>
>To answer the question - I am not building a CS, I'm building a CUA that
>talks to other CUAs, and I am in complete control of my Private and/or
>Confidential access lists.  But I see your point.
>  
>
'CS' is defined in iTIP to mean the other end of the connection when a CUA
is getting data from a CUA (such as iMIP) . CAP had not yet been invented.

The 'S' stands for SERVICE not server in iTIP.

The issue is can one vendor talk with another vendors data
in a way that everyone knows what to do with the data. It seems
to me the answer is "no" with respect to the CLASS property.

So again I think that the idea may be good if defined in an unambiguous
way. However there is no way to use the same name (CLASS) and
tell which (old or new) usage of the CLASS property is intended. I think
we need to deprecate CLASS and define CLASS2 . Then clearly
define CLASS2.

>And now that you mention it, I see that there are really three purposes
>that we are trying to use iCal for:
>
>1) Native file format for storage of calendars
>     [ I suppose this could be client or server. ]
>
agree.

>2) Transport format for exchanging calendars between users or CUAs
>	[ rich client model where server-involvement 
>	  is not required or even necessarily desired.
> 	  Business Logic is implemented on the client. ]
>
At  this level it looks to me as if not all vendors use the same meaning
of the CLASS value. Plus some transport the CLASS property, others do not.
This means that it is not an interoperable property - correct?

>3) Transport format for sending calendar data either:
>	from CS to CS, or from CS to CUA
>	[ thin client model where server-involvement
>	  is required, and business logic is implemented there. ]
>
>  
>
The transfer of data between a CUA and CAP-CS is an extension of 
transport (iTIP)
Not a replacement. So the same problem exists as in (2) above.

There is no CS to CS protocol defined yet.

And the business logic can be in the CS and CUA. It depends on the usage
of the calendar information and application.  Access control is in a 
CAP-CS - yes.

-- 

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

--------------ms050508010206090406020606--

Content-class: urn:content-classes:message
Subject: All the ways we use iCal  (was:  [Ietf-calsify] Event class)
Date: Wed, 1 Sep 2004 12:18:58 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

That is a great clarification of the EVENT CLASS problem.

To answer the question - I am not building a CS, I'm building a CUA that
talks to other CUAs, and I am in complete control of my Private and/or
Confidential access lists.  But I see your point.

And now that you mention it, I see that there are really three purposes
that we are trying to use iCal for:

1) Native file format for storage of calendars
     [ I suppose this could be client or server. ]
2) Transport format for exchanging calendars between users or CUAs
	[ rich client model where server-involvement 
	  is not required or even necessarily desired.
 	  Business Logic is implemented on the client. ]
3) Transport format for sending calendar data either:
	from CS to CS, or from CS to CUA
	[ thin client model where server-involvement
	  is required, and business logic is implemented there. ]

Looking at it this way, it seems that these three purposes are likely to
have slightly different needs, and it does seem that many of our
discussions get hung up on these differing purposes.

Is it possible to remove any of these purposes from our intention of
what iCal *should* be? Doug and Nathaniel have each mentioned at one
time or another that we should focus on the transport perspective, and
not the storage format. I also wonder if perspective #2 and #3 should be
considered separately - or one as a subset of the other...

Would it make sense to focus on these one at a time, or to differentiate
the support for specific properties based on these three dimensions?  I
realize I'm asking a broader question about the way we approach
resolving our differences surrounding the collective iCal standards -
but maybe we can move forward more easily with this kind of approach.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 31, 2004 10:07 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

>...
>In fact, I would expect that when a calendar is published or sent via 
>e-mail, my client had better exclude the events marked as PRIVATE or 
>CONFIDENTIAL (modulo some sort of override...)  It would be 
>unacceptable to include them and simply mark them as such.  Perhaps 
>this is another case of a property that should almost never be sent, 
>but that may be stored.
>
>  
>

I agree with both points. And the fact that  it is undefined and the
implementation specifics are disputed is the point. Patrice's
explanation is not consistent with yours. So would his CUA accessing
your CS give away your CONFIDENTIAL data?  It looks like yes as long as
who he wanted to iMIP it to, was in his trusted list.

Is the idea of CLASS useful - yes.
Is their consistent and interoperable usage of the CLASS property - no.

CLASS needs to be re-done in a way that new CUA's and CS's know exactly
what is expected, which (CUA or CS) is to enforce the access control.
And when to set it, forward it, or deny access to it.

--