Subject: [Ietf-calsify] List issues so far.

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 16:18:44 2004

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.

-- 

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/20040913/df195ac9/smime-0001.bin

---

From: oren at cac.washington.edu (Oren Sreebny)
Date: Mon Sep 13 17:37:22 2004

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

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 18:14:56 2004

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.

-- 

-------------- 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/20040913/16e7fe4f/smime-0001.bin

---

From: keith.macdonald at oracle.com (Keith MacDonald)
Date: Mon Sep 13 18:34:53 2004

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:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

---

From: TimHare at comcast.net ([email-masked])
Date: Mon Sep 13 20:18:13 2004

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.

>Does 1.1.1 include this issue?

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 14 06:44:34 2004

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

-- 

-------------- 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/20040914/755f8d31/smime.bin

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Tue Sep 14 07:39:43 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040914/db61ae68/smime-0001.obj

---

From: danw at novell.com (Dan Winship)
Date: Tue Sep 14 07:51:49 2004

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

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

>        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

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Tue Sep 14 07:53:32 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040914/2e063fad/smime.obj

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Tue Sep 14 08:03:30 2004

> 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
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 14 12:57:45 2004

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

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

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

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

-- 

-------------- 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/20040914/27833470/smime.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Tue Sep 14 15:13:22 2004

Hi Doug,

> found anything other than an RFC example of its usage.

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

---

From: Libby.Miller at bristol.ac.uk (Libby Miller)
Date: Wed Sep 15 01:02:12 2004

On Tue, 14 Sep 2004, Doug Royer wrote:
> tested over 40 calendar products or net accounts for calendars or PDAs, and 
> never

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

all the best

Libby

---

From: Doug at Royer.com (Doug Royer)
Date: Wed Sep 15 10:58:02 2004

Libby Miller wrote:

>> tested over 40 calendar products or net accounts for calendars or 
>> PDAs, and never

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.

-- 

-------------- 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/20040915/81666001/smime.bin

---

From: Libby.Miller at bristol.ac.uk (Libby Miller)
Date: Thu Sep 16 02:16:25 2004

hi Doug

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

Libby

On Wed, 15 Sep 2004, Doug Royer wrote:

>> Doug, is there any chance you could make this (raw) data available to us? 
>> It would be really helpful.
>> 
>> all the best 
>
>
> 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.
>
> -- 
>