Subject: [Ietf-calsify] iMip design questions

From: chao at osafoundation.org (Chih-Chao Lam)
Date: Thu Dec 30 16:28:36 2004

At OSAF (www.osafoundation.org), we're developing Chandler, a PIM 
client including email, calendaring and task management applications. 
We are at an early stage of evaluating how we should support iMip and 
had a few design/workflow questions. Lisa Dusseault suggested that this 
forum would be highly useful. I only have a cursory understanding of 
the iCalendar, iTip and iMip RFCs, so apologies if I am not getting 
something obvious. Here're our main queries:

We would like event invitations that can be modified by any attendee 
and rebroadcasted (via email) to all attendees and the organizer of the 
event.
     * Is this possible under iMip?
     * Or is the Organizer the only person that can modify and update 
the event?
     * Are there workarounds to make this possible and yet allow 
interoperability with existing clients?

     * What does iMIP have to say about forwarded invitations?
     * How is forwarded an iMIP invitation different from adding 
attendees to the same invitation?

     * Can an attendee have two different email addresses? and thus 
reply from a different email address from the one specified by the 
organizer?

     * MUST support for iMip mean we have to support S/MIME? (as my 
reading of the spec indicates?)

     * Does iMIP support VJOURNAL in addition to VEVENT and VTASK?

Answers to the above questions are highly appreciated, especially from 
the following 2 context:
    1. What does the theoretical RFCs have to say?
    2. What are the pragmatic interoperability issues with today's 
existing clients?

Thanks,
chao

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Dec 30 17:59:42 2004

Chih-Chao Lam wrote:
> At OSAF (www.osafoundation.org), we're developing Chandler, a PIM client 
> including email, calendaring and task management applications. We are at 
> an early stage of evaluating how we should support iMip and had a few 
> design/workflow questions. Lisa Dusseault suggested that this forum 
> would be highly useful. I only have a cursory understanding of the 
> iCalendar, iTip and iMip RFCs, so apologies if I am not getting 
> We would like event invitations that can be modified by any attendee and 
> rebroadcasted (via email) to all attendees and the organizer of the event.

Using iTIP (RFC-2446), the attendee reply back to the organizer, then
the organizer can rebroadcast

>     * Or is the Organizer the only person that can modify and update the 
> event?

The Organizer is a role that is often one person.

The RFC-2446 Organizer role is the only person that has the authority
to update the authoritative event. If not then calendars and
scheduling would be hackers heaven for CAL-SPAM as they added
spam like attendees.

> interoperability with existing clients?

Many are working on interoperability. That is what the CALSIFY mailing
list is about.

>     * What does iMIP have to say about forwarded invitations?

That is covered in iTIP (RFC-2445), they are allowed. The organizer
may elect to reject them.

> attendees to the same invitation?

Only the organizer can add attendees. Others may send a REPLY
message to the organizer as if they had been invited. The organizer
may accept or reject those replies.

> 
>     * Can an attendee have two different email addresses? and thus reply 
> from a different email address from the one specified by the organizer?

The data in the ATTENDEE property specifies the email address
the the organizer will use to send email to the attendee. So if
they want updates, the organizer will have to be using the same
email address.

A person could have two or more entries, that might be a pain
for the attendee that had to accept and reject all of them.

> reading of the spec indicates?)

It says yes. Almost no one does S/MIME.

>     * Does iMIP support VJOURNAL in addition to VEVENT and VTASK?

Yes to VJOURNAL and VEVENT and yes to VTODO (not VTASK).

>    2. What are the pragmatic interoperability issues with today's 

The problems are mostly with scheduling (iTIP / RFC-2446). Some 
implementations
did not comply with the specifications. Some did not comply
with iCalendar (RFC-2445).

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | 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/20041230/0425560b/smime.bin

Date: Thu, 30 Dec 2004 18:59:28 -0700
From: Doug Royer <[email-masked]>
To: Chih-Chao Lam <[email-masked]>
Subject: Re: [Ietf-calsify] iMip design questions
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.48 on 127.0.0.1
Cc: OSAF Development <[email-masked]>, [email-masked]
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, 31 Dec 2004 01:59:40 -0000

This is a cryptographically signed message in MIME format.

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

Chih-Chao Lam wrote:
> At OSAF (www.osafoundation.org), we're developing Chandler, a PIM client 
> including email, calendaring and task management applications. We are at 
> an early stage of evaluating how we should support iMip and had a few 
> design/workflow questions. Lisa Dusseault suggested that this forum 
> would be highly useful. I only have a cursory understanding of the 
> iCalendar, iTip and iMip RFCs, so apologies if I am not getting 
> We would like event invitations that can be modified by any attendee and 
> rebroadcasted (via email) to all attendees and the organizer of the event.

Using iTIP (RFC-2446), the attendee reply back to the organizer, then
the organizer can rebroadcast

>     * Or is the Organizer the only person that can modify and update the 
> event?

The Organizer is a role that is often one person.

The RFC-2446 Organizer role is the only person that has the authority
to update the authoritative event. If not then calendars and
scheduling would be hackers heaven for CAL-SPAM as they added
spam like attendees.

> interoperability with existing clients?

Many are working on interoperability. That is what the CALSIFY mailing
list is about.

>     * What does iMIP have to say about forwarded invitations?

That is covered in iTIP (RFC-2445), they are allowed. The organizer
may elect to reject them.

> attendees to the same invitation?

Only the organizer can add attendees. Others may send a REPLY
message to the organizer as if they had been invited. The organizer
may accept or reject those replies.

> 
>     * Can an attendee have two different email addresses? and thus reply 
> from a different email address from the one specified by the organizer?

The data in the ATTENDEE property specifies the email address
the the organizer will use to send email to the attendee. So if
they want updates, the organizer will have to be using the same
email address.

A person could have two or more entries, that might be a pain
for the attendee that had to accept and reject all of them.

> reading of the spec indicates?)

It says yes. Almost no one does S/MIME.

>     * Does iMIP support VJOURNAL in addition to VEVENT and VTASK?

Yes to VJOURNAL and VEVENT and yes to VTODO (not VTASK).

>    2. What are the pragmatic interoperability issues with today's 

The problems are mostly with scheduling (iTIP / RFC-2446). Some 
implementations
did not comply with the specifications. Some did not comply
with iCalendar (RFC-2445).

-- 

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

               We Do Standards - You Need Standards

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

--------------ms030807060004050506090204--

To: OSAF Development <[email-masked]>, [email-masked]
From: Chih-Chao Lam <[email-masked]>
Date: Thu, 30 Dec 2004 16:28:26 -0800
Cc: 
Subject: [Ietf-calsify] iMip design questions

Thanks,
chao

Date: Thu, 30 Dec 2004 12:14:35 -0700
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.48 on 127.0.0.1
Subject: [Ietf-calsify] The guts of recurrence rules as implemented
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: Thu, 30 Dec 2004 19:14:56 -0000

This is a cryptographically signed message in MIME format.

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

(A) Looking at the data used by vendors, there seems to be 4 ways
     vendors deal with recurring rules:

(A.1) Only keep the original object and expand the instances
       dynamically.

(A.2) Only keep the expanded instances and toss the original.
       Makes infinitely expanding object break.

(A.3) Keep both the original and expanded instances. And they
       dynamically expand and cache the expanded instances as needed.

(A.4) Ignore any recurrence rules.
       Makes much break.

(B) And there are 2 ways vendors do DTSTART and RECURRENCE-ID on
     expanded instances.

  (B.1) In the expanded instance, they keep DTSTART
        the same as in the original object (iTIP 4.5.7.2 & 4.5.7.2).
        Set the RECURRENCE-ID value equal to the effective start
        time of the instance.

  (B.2) Set the DTSTART value and the RECURRENCE-ID value
        equal to each other all of the time. For those
        that do (A.2) they later notice they are unable
        to reschedule some types of requests under specific
        circumstances.

(C) A solution to (A.*) is to suggest that both the expanded and
     unexpended objects be sent by default. And we pick some limit
     for infinite or large expanding rules. (I had suggested
     a way to represent that on this list earlier - IS-SUB-SET
     parameter)

Now for what will be the debate. (B.*).

   (B.2) I see no advantage to always setting the DTSTART and
         RECURRENCE-ID value to be equal to the value of the other.
         The vendor data that I have seen that does this does not
         store the raw ICS files anyway (as their primary cal-store).
         So translating to/from the iTIP way does not seem like a burden.

         Doing the math to compute the start time is easy on any
         system including PDAs. That has been converted. If you
         do not remember, new to the list or can not find it, post
         a message for the details.

   (B.1) By doing (B.1) any single instance has all of the information
         needed to reschedule under any circumstances. Except: when
         the vendor stores in (A.2) format.

In the past there has been a large debate on this. I went back
and re-read the debate and in every case that I could find
(after looking to see how the vendor really did it) was a mixture
of (B.1) and (A.2) where things broke.

So, I think that (C) solves the problem. Everyone gets what
they want PLUS they have to do the simple math if they
store their data in (A.2) format.

If we do (C) and (B.2) then people that do not do (A.2) can
not correctly store their data and other specific combinations
of things break later in scheduling.

In a simple example. A 3 day recurring VEVENT would send a total
of 3 VEVENTs when exchanging calendar information (by default).
In all three objects the DTSTART value would be the DTSTART value
of the first instance (B.1 method). The RECURRENCE-ID value would
be the effective start date of the specific instance. And all
recurrence rules would be included in all objects. More
bandwidth - but as far as I can tell 100% interoperate with
anyone that even comes close to complying with 2445 and 2446.

Right now (B.2) implementations already have to do the math, they
just do it when sending objects. And (B.1) implementations already
do the math when getting objects.

By adding some unique property (Like the EXTENSIONS one I propose) then
everyone can tell that the sender is conforming to the 'new' standard.

The other solution is for the 3 day VEVENT to send 4 objects.
The original, then include 3 more VEVENTs in (B.2) format.

-- 

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

               We Do Standards - You Need Standards

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

--------------ms080100010609060505040100--

Date: Wed, 29 Dec 2004 19:25:38 -0700
From: Doug Royer <[email-masked]>
To: "[email-masked]" <[email-masked]>, [email-masked], CalDAV DevList <[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.48 on 127.0.0.1
Cc: 
Subject: [Ietf-calsify] iCal-Basic - draft 00
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: Thu, 30 Dec 2004 02:26:12 -0000

This is a cryptographically signed message in MIME format.

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

I have taken the discussion on the CALSIFY mailing list and edited
RFC-2445 into a proposal for iCal-Basic.

Recurrence rules are not in iCal-Basic. iCal-Basic allows
for extension that include specific sub-sets of future
extensions (like recurrence rules that are likely to be
added).

An off mailing list discussion requested that RDATE be
added to iCal-Basic as it would be very simple to implement.

I have submitted draft-royer-ical-basic-00.txt and would
appreciate any feedback.

Thanks!

-- 

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

               We Do Standards - You Need Standards

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

--------------ms070605020908040607000407--

To: [email-masked]
Subject: Re: [Ietf-calsify] another thought for simplification / levels
From: [email-masked]
Date: Wed, 29 Dec 2004 10:50:59 -0500
Cc: [email-masked], [email-masked]

Hi Tim.  Sorry for the delay in posting to the list.  I'm weeding through 
my emails - message here is don't go away for the holidays - it kills you 
later - 8-( 

I agree with you that other projects are in the works and probably already 
have come up with implementations that don't follow the standards. Indeed, 
working code will always override standards, unfortunately (or fortunately 
- depending on your point of view.) 

I am still, as I have always been, an end user (not a calendar developer) 
who has been waiting, since 1989, for good calendar interoperability and a 
way to search peoples schedules - anywhere.  And when I talk to other 
users/companies, that's all they want as well (for now).

I am working with a client right now who is a large organization and who 
runs three - count them three - different calendaring systems.  This is 
because of recent mergers.  It's not what they want but moving large 
amounts of people to one calendar is not feasible, economically,  in the 
near future.  So, they are back to using the phone to set up meetings 
among the three groups.  To them, they have gone backwards in time.

Yes, with the extended reach of the internet, we can start looking at 
exciting ways to do calendar searches, etc.  However, right now, several 
organizations would simply be happy with "my calendar product talks to 
your calendar product."  Easily.  Without magic mirrors and addon 
products.  Whatever we do to get there - standards or not - will work in 
our books. 

[email-masked] 
Sent by: [email-masked]
12/21/2004 05:41 PM

To
[email-masked]
cc
[email-masked]
Subject
Re: [Ietf-calsify] another thought for simplification / levels

Just to clear something up - my XML was just an example, not the 
definitive 
way to do it; obviously it would take a lot of thought to get the XML 
right.

And in answer to other posts -  I think I agree that XML-calendar is 
another project, different from calendar simplification; however if 
simplification doesn't happen in a relatively short time frame, those who 
are working on calendaring in other venues (RDF Calendar being just one 
example) may produce something that works, in XML,  before simplification 
and interoperability are complete for our set of RFCs. And in my 
not-so-humble opinion of the industry as a whole,  working stuff trumps 
IETF standards - even if the working protocols later get written up as 
standards.  I haven't seen a lot of work on the 
simplification/interoperability front lately on this list (it may be 
happening elsewhere, though).

At 10:12 PM 12/20/04, Doug Royer wrote:

>[email-masked] wrote:
>
>>There are several advantages to this idea in my opinion:
>>
>>         1. We could use XML to group things from different levels 
>> together (this is just an example)
>>             <vcalendar>
>>               <vevent>
>>                 <basic-event-info>
>>                   (whatever we decide level 0 stuff is goes here)
>>                  </basic-event-info>
>>                  <extended-stuff>
>>                    (more advanced items go here)
>>                  </extended-stuff>
>>               </vevent>
>>             </vcalendar>
>>
>
>If (an example) if RRULE were in an extended set, what would be the 
advantage
>of wrapping it with another tag?   Other than making it visually 
separate, 
>what would
>be the advantage?
>
>In 2445 when you do not know a component, property, or parameter name, 
you
>are suppose to ignore it anyway.
>
>And it is more complicated than that. Some properties may be in one RFC
>an not another or some extended properties may exist in newer RFC's 
causing
>yet more extensions.
>
>The extensions method must be a non-linier solution that can include
>or exclude future RFCs. Just adding the <extended-stuff> wrapper
>will cause only a delay and not a solution to the problem.
>
>--
>
>Doug Royer                     | http://INET-Consulting.com
>-------------------------------|-----------------------------
>[email-masked]                 | Office: (208)612-4638
>http://Royer.com               | Fax:    (866)594-8574
>                               | Cell:   (208)520-4044
>
>              We Do Standards - You Need Standards
>
>
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

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

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] 2445 next - and is contents
Date: Mon, 27 Dec 2004 22:27:45 +0100

--nextPart2731628.29uNvRVZUi
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Montag, 27. Dezember 2004 05:06 schrieb Doug Royer:
> (2) Do we need the ability for an individual VALARM to repeat itself?
>      I do not think so. I think we can deprecate the REPEAT property.
>
>      Just casually looking, I do not see any implementation
>      that allows the user to specify that an individual
>      VALARM is repeated.

Evolution has repeating alarms. And for KOrganizer I seriously consider add=
ing=20
it (but it won't go into KDE 3.4, but maybe into KDE 4.0).

Reinhold

=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain=
er

--nextPart2731628.29uNvRVZUi
Content-Type: application/pgp-signature

--nextPart2731628.29uNvRVZUi--

Date: Sun, 26 Dec 2004 21:06:38 -0700
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.48 on 127.0.0.1
Subject: [Ietf-calsify] 2445 next - and is contents
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: Mon, 27 Dec 2004 04:06:49 -0000

This is a cryptographically signed message in MIME format.

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

I think we need to move the scheduling information in 2445 into
2446-next. And I do not think that anyone uses the REPEAT property
in a VALARM.

(1) In addition to moving recurrence rule into a separate draft, I think
     that scheduling objects in 2445 need to be moved from 2445
     into 2446-next.

For example,

	SENT-BY
	DELEGATED-TO
	DELEGATED-FROM
	RSVP

I do not think these have much of a meaning without scheduling.

So I propose they get moved to 2446-next and are not included
in 2445-next.

(2) Do we need the ability for an individual VALARM to repeat itself?
     I do not think so. I think we can deprecate the REPEAT property.

     Just casually looking, I do not see any implementation
     that allows the user to specify that an individual
     VALARM is repeated.

     Same with the DURATION property in a VALARM.

-- 

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

               We Do Standards - You Need Standards

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

--------------ms010500010600020300010504--

Date: Tue, 21 Dec 2004 17:41:42 -0500
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] another thought for simplification / levels
Cc: [email-masked]

Just to clear something up - my XML was just an example, not the definitive 
way to do it; obviously it would take a lot of thought to get the XML right.

And in answer to other posts -  I think I agree that XML-calendar is 
another project, different from calendar simplification; however if 
simplification doesn't happen in a relatively short time frame, those who 
are working on calendaring in other venues (RDF Calendar being just one 
example) may produce something that works, in XML,  before simplification 
and interoperability are complete for our set of RFCs. And in my 
not-so-humble opinion of the industry as a whole,  working stuff trumps 
IETF standards - even if the working protocols later get written up as 
standards.  I haven't seen a lot of work on the 
simplification/interoperability front lately on this list (it may be 
happening elsewhere, though).

At 10:12 PM 12/20/04, Doug Royer wrote:

>[email-masked] wrote:
>
>>There are several advantages to this idea in my opinion:
>>
>>         1. We could use XML to group things from different levels 
>> together (this is just an example)
>>             <vcalendar>
>>               <vevent>
>>                 <basic-event-info>
>>                   (whatever we decide level 0 stuff is goes here)
>>                  </basic-event-info>
>>                  <extended-stuff>
>>                    (more advanced items go here)
>>                  </extended-stuff>
>>               </vevent>
>>             </vcalendar>
>>
>
>If (an example) if RRULE were in an extended set, what would be the advantage
>of wrapping it with another tag?   Other than making it visually separate, 
>what would
>be the advantage?
>
>In 2445 when you do not know a component, property, or parameter name, you
>are suppose to ignore it anyway.
>
>And it is more complicated than that. Some properties may be in one RFC
>an not another or some extended properties may exist in newer RFC's causing
>yet more extensions.
>
>The extensions method must be a non-linier solution that can include
>or exclude future RFCs. Just adding the <extended-stuff> wrapper
>will cause only a delay and not a solution to the problem.
>
>--
>
>Doug Royer                     | http://INET-Consulting.com
>-------------------------------|-----------------------------
>[email-masked]                 | Office: (208)612-4638
>http://Royer.com               | Fax:    (866)594-8574
>                               | Cell:   (208)520-4044
>
>              We Do Standards - You Need Standards
>
>
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Date: Mon, 20 Dec 2004 20:18:32 -0700
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] another thought for simplification / levels
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.48 on 127.0.0.1
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, 21 Dec 2004 03:18:43 -0000

This is a cryptographically signed message in MIME format.

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

Cameron Stillion wrote:

>Back to the current state of affairs, I believe the calsify endeavor is
>to add nothing to the existing standard, but only to simplify it to the
>point of standard-application-usability and interoperability.  I suggest
>that a new and separate endeavor should pursue the xml-ified variation.
>
>That's my take...
>  
>
Yes, I completely agree, we have to solve the problem  of what is in the 
basic and
extended objects regardless of XML or iCal format.

And as I have been told many times by the IESG, they will not allow an 
XML-iCal
that is not compatible with 2445 formats.  We can not throw away existing
implementations, we have to first clarify existing standards.  Then we can
extend iCal. And iCal or XML format will not matter until that is solved.

-- 

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

              We Do Standards - You Need Standards

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

--------------ms050005070204030408090408--

Date: Mon, 20 Dec 2004 20:12:00 -0700
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] another thought for simplification / levels
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.48 on 127.0.0.1
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, 21 Dec 2004 03:13:01 -0000

This is a cryptographically signed message in MIME format.

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

[email-masked] wrote:

>There are several advantages to this idea in my opinion:
>
>	1. We could use XML to group things from different levels together (this is just an example)
>	    <vcalendar>
>	      <vevent>
>	        <basic-event-info>
>	          (whatever we decide level 0 stuff is goes here)
>	         </basic-event-info>
>	         <extended-stuff>
>	           (more advanced items go here)
>	         </extended-stuff>
>	      </vevent>
>	    </vcalendar>
>  
>

If (an example) if RRULE were in an extended set, what would be the 
advantage
of wrapping it with another tag?   Other than making it visually 
separate, what would
be the advantage?

In 2445 when you do not know a component, property, or parameter name, you
are suppose to ignore it anyway.

And it is more complicated than that. Some properties may be in one RFC
an not another or some extended properties may exist in newer RFC's causing
yet more extensions.

The extensions method must be a non-linier solution that can include
or exclude future RFCs. Just adding the <extended-stuff> wrapper
will cause only a delay and not a solution to the problem.

-- 

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

              We Do Standards - You Need Standards

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

--------------ms030704070802090701050706--

Content-Class: urn:content-classes:message
Subject: RE: [Ietf-calsify] another thought for simplification / levels
Date: Mon, 20 Dec 2004 18:44:25 -0800
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: Jonathan Boarman <[email-masked]>

XML does bring some advantages to the table that frankly, ought to be
considered for any new standard - the first and most significant, I
think, is that no new parsers need to be written.  Or at least, the
number of encoding and parsing errors that are likely to occur are
significantly decreased.  Internationalization is comparitively easy,
and no low-level description of the format would need be discussed. One
can focus on the schema instead.

Your suggestion that there exists support for XML in existing
applications is fair, but be wary about overcommitting libraries that
you are not intimately familiar with.  I suspect that there are several
XML parsers within many large codebases, but I cannot say whether any of
them are of sufficient or desirable to use in these circumstances.
Obviously it behooves vendors to develop good low-level support for
parsing XML, and it may very well be arguably good to push them in that
direction anyway.  Assuming they are there already might be bolder than
you think.

In general, I like your idea, but I think it is most meaningful for new
standards, and I see your suggestion as a new standard:  xCalendar
perhaps.  This might be very compelling especially for calendar
publishing software that could also provide transforms for these types
of data and thereby provide glowing chrome to navigate a .xcal on a web
site, for example. icalshare.com or icalx.com might both decide to do
some cool fancy things with that, especially if a vendor or two adopted
it.  My suspicion is that only some compelling new features would bring
vendors to the state of wanting to.  (e.g. support for
mime-type-specified bodies <DESCRIPTION
TYPE="text/xhtml">....</DESCRIPTION>, non-gregorian recurrences <RRULE
TYPE="lunar">...</RRULE> and the like)

Back to the current state of affairs, I believe the calsify endeavor is
to add nothing to the existing standard, but only to simplify it to the
point of standard-application-usability and interoperability.  I suggest
that a new and separate endeavor should pursue the xml-ified variation.

That's my take...

++cam;

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, December 20, 2004 6:09 PM
To: [email-masked]
Cc: Jonathan Boarman
Subject: [Ietf-calsify] another thought for simplification / levels

This idea was inspired by someone who asked about my XML-with-calendar
guideline draft; I'm posting it here because I think this may be the
most appropriate place to begin this discussion.

We've had some discussion about having various levels of iCalendar to
allow simplification. This would of course require a mechanism that
allowed one to know what levels were supported by sender and receiver.
There are also quite a few people that are thinking about and working on
events/scheduling information in XML - which makes sense because of the
large number of XML tools available to developers and its growing use as
an interchange mechanism. This has prompted me to think that perhaps the
"simplified" version of iCalendar ought to be an XML version instead? 

There are several advantages to this idea in my opinion:

	1. We could use XML to group things from different levels
together (this is just an example)
	    <vcalendar>
	      <vevent>
	        <basic-event-info>
	          (whatever we decide level 0 stuff is goes here)
	         </basic-event-info>
	         <extended-stuff>
	           (more advanced items go here)
	         </extended-stuff>
	      </vevent>
	    </vcalendar>

	2. XML allows developers to use namespaces for extensions and
additions
	3. XML tools are prevalent in many development packages and
databases systems, easing development
	4. XML is understood at some level by many more developers 
	5. We can always "down-convert" an XML representation to
iCalendar through XSLT
	6. For events calendars and the like: the structure of XML would
make it easier to create search tools for events

There of course will be negatives - one of which is the addition of code
to existing products that support iCalendar, to also support the new
XML-based format. My instincts tell me that many of these products
already support XML  in some ways, so  that much of the software
infrastructure to support XML is already there (for example, MS Office
supports XML for quite a few things now); but I am not a software
vendor, so take that with a grain of salt unless vendor representatives
on this list would care to comment.

I posting this a discussion-generator. This being the holidays,  I don't
expect a lot of discussion right at the moment, but please, let's kick
this one around for a bit.

Tim Hare
Interested Bystander, Non-Inc. 
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: [email-masked]
To: [email-masked]
Date: Tue, 21 Dec 2004 02:08:39 +0000
Cc: Jonathan Boarman <[email-masked]>
Subject: [Ietf-calsify] another thought for simplification / levels

This idea was inspired by someone who asked about my XML-with-calendar guideline draft; I'm posting it here because I think this may be the most appropriate place to begin this discussion.

We've had some discussion about having various levels of iCalendar to allow simplification. This would of course require a mechanism that allowed one to know what levels were supported by sender and receiver. There are also quite a few people that are thinking about and working on events/scheduling information in XML - which makes sense because of the large number of XML tools available to developers and its growing use as an interchange mechanism. This has prompted me to think that perhaps the "simplified" version of iCalendar ought to be an XML version instead? 

There are several advantages to this idea in my opinion:

	1. We could use XML to group things from different levels together (this is just an example)
	    <vcalendar>
	      <vevent>
	        <basic-event-info>
	          (whatever we decide level 0 stuff is goes here)
	         </basic-event-info>
	         <extended-stuff>
	           (more advanced items go here)
	         </extended-stuff>
	      </vevent>
	    </vcalendar>

	2. XML allows developers to use namespaces for extensions and additions
	3. XML tools are prevalent in many development packages and databases systems, easing development
	4. XML is understood at some level by many more developers 
	5. We can always "down-convert" an XML representation to iCalendar through XSLT
	6. For events calendars and the like: the structure of XML would make it easier to create search tools for events

There of course will be negatives - one of which is the addition of code to existing products that support iCalendar, to also support the new XML-based format. My instincts tell me that many of these products already support XML  in some ways, so  that much of the software infrastructure to support XML is already there (for example, MS Office supports XML for quite a few things now); but I am not a software vendor, so take that with a grain of salt unless vendor representatives on this list would care to comment.

I posting this a discussion-generator. This being the holidays,  I don't expect a lot of discussion right at the moment, but please, let's kick this one around for a bit.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Sat, 04 Dec 2004 06:16:26 -0800
From: "David C. Thewlis" <[email-masked]>
To: "ietf-calsify reflector" <[email-masked]>
Subject: [Ietf-calsify] Meeting Notice: CalConnect Roundtable II -- The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

Our apologies if you receive multiple copies of this announcement.  We've
had requests from non-members for notification of Consortium events so we
are circulating this notice widely. 

MEETING NOTICE:  CALCONNECT ROUNDTABLE II

The second Calendaring and Scheduling Consortium Roundtable will be held
Tuesday-Thursday, 11-13 January, 2005, hosted by the University of
Washington on the UW Campus in Seattle, Washington.  We expect to have
space for 25-30 people so early notification of intent to participate will
be important.

This three-day event will include Consortium Technical Committee Meetings
for all TCs which wish to meet in person, and a full Roundtable of all
participants to consider TC reports, evaluate progress, and establish next
steps and directions in working towards interoperable Calendaring and
Scheduling.  There will also be a co-located Interop Testing Event on
Tuesday and Wednesday, which will run three different testing scenarios
(please see the information for this Interop on the Consortium website).  

This event is open to Consortium members only.   Participation in the
co-located Interop is open to both members and non-members.  Non-members
interested in the Consortium may join the Consortium prior to the
Roundtable or onsite (including non-members participating in the Interop
event) and attend the Consortium activities.

SCHEDULE

The general schedule is:

Interops (in parallel) - all day Tuesday, Wednesday morning
TC meetings - all day Tuesday, Wednesday morning, and afternoon as needed
Group Dinner - Wednesday evening
Roundtable - may begin Wednesday mid-afternoon; Thursday until 3:00

REGISTRATION FEE

There is a nominal registration fee for the Roundtable to cover meeting
facilities, food and breaks, and the group dinner.  If your organization is
a Consortium member participating in the co-located Interop, and you are
covered by the Interop Registration Fee, you need not pay a separate
registration fee for the Roundtable.

MORE INFORMATION AND REGISTRATION

More information about this event, including logistics information, venues,
fees, etc. is posted on the Consortium website.  Please go to
www.calconnect.org and select Membership Activities-->Next Roundtable.   If
you are interested in participating in the Interop, please see
Interops-->Jan 2005. 

The event hotel is the Seattle Watertown:  www.watertownseattle.com,  The
cutoff date for the group rate (group name "calconnect" is 20 December
2004.

If you wish to attend the Roundtable, please contact me directly (contact
information below) to register and to arrange payment of registration fees.
 Remember that space is limited by the size of the venue meeting room;
early registration is advised.  

If you plan to attend the Interop, please use the registration form on the
Consortium website; see Interops-->Register.  If you will attend both the
Interop and the Roundtable, please contact me directly to be sure you are
included in planning for both events.

Please contact me if you have any questions.

Best Regards,

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

Date: Thu, 02 Dec 2004 07:50:40 -0800
From: "David C. Thewlis" <[email-masked]>
To: "ietf-calsify reflector" <[email-masked]>
Subject: [Ietf-calsify] Call for Participantion -- Second Calconnect Interop - 11-12 January 2005 - Seattle, Washington
Reply-To: [email-masked]

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

CALL FOR PARTICIPATION -- SECOND INTEROP TESTING EVENT -  11-12 January
2005

The second Interop of The Calendaring and Scheduling Consortium
(CALCONNECT.ORG) will take place Tuesday and Wednesday, January 11-12,
2005.  It will be hosted by the University of Washington and the venue will
be on the UW Campus in Seattle, Washington.

This event will feature three separate Interop testing scenarios.
Participating organizations are welcome to test against one, two, or all
three scenarios.  Please note however that these scenarios will be going on
simultaneously so you will probably need a team for each scenario you
participate in.

Space will be limited so early notification and registration is advised.

INTEROP SCENARIOS

(a) Full scale interop: against iCal, iMIP, iTIP, essentially the same
scenario as the one done in July 2004.  The goal is to get results from
testing by more implementations to augment the data from July -- at the
July event Oracle and IBM tested; it would be very useful to have results
from other vendors to augment the understanding of the RFCs gained from the
July (and earlier) Interops.

(b) Min-IOP Interop:  The Min-IOP Technical Committee of the Consortium was
formed to identify and define the "Minimum Interoperable Subset" for
iCalendar as part of the work towards the Calsify effort in the IETF.  This
Interop scenario is for implementations to test against that subset.  The
goal is to help define baseline requirements for the CALSIFY effort and to
determine what the real world common subset actually is, so the more
implementations tested against this common subset the more realistic and
useful the results will be.

(c) CalDAV Interop:  Oracle Corporation will provide a prototype CalDAV
server for client testing, and work is progressing on the definition of the
test cases for the scenario.  Some vendors have expressed interest in being
able to do a CalDAV Interop as soon as possible.  This will provide early
feedback to the server implementors, the CalDAV specification authors, and
the client implementors.

WHO MAY PARTICIPATE IN THE INTEROPS

Any vendor or organization wishing to test a calendaring and scheduling
implementation is welcome to attend whether or not they are a Consortium
member. Note that Consortium members do receive a substantial discount on
their Interop participation fee (see below).

CONSORTIUM ROUNDTABLE II

Technical committee meetings of the Calendaring and Scheduling Consortium
are also planned for 11-12 January at the same location, followed by an
all-hands Consortium Roundtable on Thursday 13 January.  Interop
participants who are not Consortium members will not be able to participate
in the other Consortium activities as they are reserved to members.
However, a non-member Interop Participant can join the Consortium at the
event and become a member immediately and be able to participate in the
technical committee and roundtable meetings.

REGISTRATION FEE

The registration fee for the Interop is $1500 for Consortium members and
$2500 for non-members.  The registration fee covers two individuals;
additional individuals are $150 each for members or non-members.  (If you
are planning to participate in more than one Interop scenario you may need
more than two people.)

Members:  Please note that the Interop Registration Fee for Members also
covers the registration fee for participation in the Consortium events for
the interop participants.

HOW TO REGISTER AND FURTHER INFORMATION

Detailed information including logistics will be posted on the Consortium
website as as it becomes available; go to http://www.calconnect.org and
select "Interops Future".  You may also register online on the website by
selecting "Interops Registration".

For questions or more information, or to inform us of your plan to
participate in the Interop, please contact me at the Consortium.

Best Regards,

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