From owner-ietf-calendar@mail.imc.org Fri Oct 5 08:58:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20935 for ; Fri, 5 Oct 2001 08:58:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f95CdOF14505 for ietf-calendar-bks; Fri, 5 Oct 2001 05:39:24 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f95CdMD14501 for ; Fri, 5 Oct 2001 05:39:23 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id IAA14166; Fri, 5 Oct 2001 08:39:18 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f95CdHT25599; Fri, 5 Oct 2001 08:39:17 -0400 (EDT) Message-ID: <3BBDAA10.A5C864D6@steltor.com> Date: Fri, 05 Oct 2001 08:39:44 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: Filing of components Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit CAP doesn't allow calendar users to move components between calendars. Currently, the MOVE command can only be "used to move a calendar within the CS's hierarchy of calendars". If calendar users use multiple calendars for filing purposes, it is not clear that they will want to let other calendar users choose which calendar to address their scheduling commands to, since they won't be able to moved the components in the calendar of their choice afterwards. Although calendar users could use access rights (VCAR) to control which calendars other users can address their commands to, that would only allow filing based on users. I understand that allowing users to move components between calendars would prevent other calendar users to find these components directly in the calendars they expect. Obviously, it wouldn't be reasonable to notify other calendar users each time a component is moved between calendars, but on the other hand, what would be the usefulness of specifying the calendar address of ATTENDEEs in VEVENTs if one can't rely on them? I would like to propose the addition of a new container, say VFOLDER (for lack of a better name), to allow filing of components within calendars, in such a way that moving components between these new containers would not change the calendar address where these components can be found. The MOVE command would have to be changed to allow components to be moved between these new containers. Scheduling commands could be addressed to calendars only, while calendaring commands could be addressed to both calendars and VFOLDERs. Calendars and VFOLDERs could both contain other VFOLDERs but not other calendars. The addition of this new container will probably reduce the number of calendars a user may want, and consequently expose to other calendar users, which will reduce the confusion that may arise when a calendar user want to invite a calendar user that has multiple calendars. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri Oct 5 21:57:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06324 for ; Fri, 5 Oct 2001 21:57:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f96154Z21470 for ietf-calendar-bks; Fri, 5 Oct 2001 18:05:04 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f96153D21465 for ; Fri, 5 Oct 2001 18:05:03 -0700 (PDT) Received: from 192.168.10-104.masq (192.168.10-104.masq [192.168.10.104]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id VAA06072 for ; Fri, 5 Oct 2001 21:05:01 -0400 Subject: Specifying RRULE UNTIL parameter for events using DATE or floating times From: Damon Chaplin To: ietf-calendar@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15.99 (Preview Release) Date: 05 Oct 2001 21:04:14 -0400 Message-Id: <1002330254.1016.14.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The spec states that if an RRULE UNTIL parameter is specified as a DATE-TIME value, then it must be in UTC. However, what happens if the event's DTSTART is a floating time? How can you specify the last occurrence as a UTC time when the time of the occurrence changes depending on what timezone you are in? (I'm not totally sure I understand how DATE values and floating values are supposed to work, btw.) Damon From owner-ietf-calendar@mail.imc.org Mon Oct 8 16:49:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01576 for ; Mon, 8 Oct 2001 16:49:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f98KTWF14815 for ietf-calendar-bks; Mon, 8 Oct 2001 13:29:32 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f98KTVD14811 for ; Mon, 8 Oct 2001 13:29:31 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA24781; Mon, 8 Oct 2001 13:28:55 -0700 (PDT) Message-ID: <3BC20BA7.DBFA3BB6@Royer.com> Date: Mon, 08 Oct 2001 14:25:11 -0600 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Damon Chaplin CC: ietf-calendar@imc.org Subject: Re: Specifying RRULE UNTIL parameter for events using DATE or floatingtimes References: <1002330254.1016.14.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit UNTIL means repeat until that date/time. So if you say repeat this floating appointment UNTIL 20011225T000000Z, then it will not and MUST NOT repeat after Dec 25th 2001 at 00:00:00 UTC. That is the purpose and reason for UNTIL. Are you sure you don't want DTEND or DURATION? -Doug Damon Chaplin wrote: > > The spec states that if an RRULE UNTIL parameter is specified as a > DATE-TIME value, then it must be in UTC. > > However, what happens if the event's DTSTART is a floating time? > How can you specify the last occurrence as a UTC time when the > time of the occurrence changes depending on what timezone you are in? > > (I'm not totally sure I understand how DATE values and floating > values are supposed to work, btw.) > > Damon From owner-ietf-calendar@mail.imc.org Mon Oct 8 17:28:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02678 for ; Mon, 8 Oct 2001 17:28:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f98LCNr15844 for ietf-calendar-bks; Mon, 8 Oct 2001 14:12:23 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f98LCKD15836 for ; Mon, 8 Oct 2001 14:12:20 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA25389; Mon, 8 Oct 2001 14:11:50 -0700 (PDT) Message-ID: <3BC2155C.A3CF8C9D@Royer.com> Date: Mon, 08 Oct 2001 15:06:36 -0600 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Desruisseaux , "ietf-calendar@imc.org" Subject: Re: CAP: Filing of components References: <3BBDAA10.A5C864D6@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit You invite users, not calendars. If a user had multiple calendars, they would have to specify their preferred calendar. This is no different than email. If you have more than one email address, persons wishing to reach you need to know where to send the email, or they may email to all of your addresses. Failing that (read included text below): Bernard Desruisseaux wrote: > > CAP doesn't allow calendar users to move components between > calendars. Currently, the MOVE command can only be "used to > move a calendar within the CS's hierarchy of calendars". True, as a MOVE could not be done across calendar stores, perhaps across vendor implementations, firewalls, domains, ... (The same EFFECT is still possible - see my reply below). > If calendar users use multiple calendars for filing purposes, > it is not clear that they will want to let other calendar users > choose which calendar to address their scheduling commands to, > since they won't be able to moved the components in the calendar > of their choice afterwards. Yes and No. Perhaps the user only has access to your company calendar (company-cal). You however keep everything impotant to you on your ISP provided personal calendar (my-cal). There are two kinds of entries. Those made by the owner and unprocessed invitations deposited by non-owners. The unprocessed invitations are initially not committed to by the calendar owner/user they are simply stored there until processed by the calendar owner. So, if someone drops a calendar appointment request (METHOD == REQUEST) asking you to attend the school play into your work calendar (company-cal), your USER AGENT assumes the responsibility (with user input) to determine what to do, which might be: (1) Decide if you wish to attend. (1.a) No - delete it. (1.b) Yes - go to (2). (2) Copy the entry into YOUR preferred calendar (my-cal). (3) Delete it from company-cal calendar. (4) Reply (METHOD == REPLY), and confirm you are attending. Setting you REPLY-TO value to be 'my-cal'. Your UA will have to look into all of your calendars for legitimate invitations anyway. And you UA will have to be able to create new entries anyway. No new CAP code needed. Does this address your issue? > Although calendar users could use access rights (VCAR) to control > which calendars other users can address their commands to, that > would only allow filing based on users. Which may also be all you have if all your friends and busisness associates do not have a username/password to all of your calendars. Or if some are behind firewalls and have limited access. For example, you PUBLIC-calendar may be outside your firewall and you personal-calendar may be inside a firewall. Then they could only make requests to your PUBLIC-calendar > I understand that allowing users to move components between > calendars would prevent other calendar users to find these > components directly in the calendars they expect. Obviously, > it wouldn't be reasonable to notify other calendar users each > time a component is moved between calendars, but on the other > hand, what would be the usefulness of specifying the calendar > address of ATTENDEEs in VEVENTs if one can't rely on them? At the time you METHOD == REPLY to an entry from someone else, it MAY include a reply-to paramater which CAN BE a CAP address. That is how they are informed on how and where to send updates to you/your calendar. If YOU invide people to an event, THEN IF 'YOU' move the event's calendar, then YES YOU MUST notify them, or else they can not reply. That is done with a METHOD == UPDATE. > I would like to propose the addition of a new container, say > VFOLDER (for lack of a better name), to allow filing of components > within calendars, in such a way that moving components between > these new containers would not change the calendar address where > these components can be found. The MOVE command would have to be > changed to allow components to be moved between these new containers. Given what I said above, do you feel this is still needed? > Scheduling commands could be addressed to calendars only, while > calendaring commands could be addressed to both calendars and > VFOLDERs. > > Calendars and VFOLDERs could both contain other VFOLDERs but not > other calendars. > > The addition of this new container will probably reduce the > number of calendars a user may want, and consequently expose > to other calendar users, which will reduce the confusion that > may arise when a calendar user want to invite a calendar user > that has multiple calendars. > > Regards, > Bernard > -- > Bernard Desruisseaux mailto:bernard@steltor.com > Research & Development Tel. : +1 514 733-8500 x4213 > Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Oct 9 21:27:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16507 for ; Tue, 9 Oct 2001 21:27:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9A12Bo18304 for ietf-calendar-bks; Tue, 9 Oct 2001 18:02:11 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9A129D18106 for ; Tue, 9 Oct 2001 18:02:09 -0700 (PDT) Received: from 192.168.10-104.masq (192.168.10-104.masq [192.168.10.104]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id VAA20492; Tue, 9 Oct 2001 21:01:20 -0400 Subject: Re: Specifying RRULE UNTIL parameter for events using DATE or floatingtimes From: Damon Chaplin To: Doug Royer Cc: ietf-calendar@imc.org In-Reply-To: <3BC20BA7.DBFA3BB6@Royer.com> References: <1002330254.1016.14.camel@localhost.localdomain> <3BC20BA7.DBFA3BB6@Royer.com> Content-Type: multipart/alternative; boundary="=-DSMiHtaM698gLq7MpBYQ" X-Mailer: Evolution/0.15.99 (Preview Release) Date: 09 Oct 2001 21:00:29 -0400 Message-Id: <1002675629.3811.2.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-DSMiHtaM698gLq7MpBYQ Content-Type: text/plain Content-Transfer-Encoding: 7bit The problem is that if you have a floating event, then setting the UNTIL time as a UTC time means that you may get a different number of occurrences, depending upon which timezone the floating time is 'resolved' in. The user probably wants to say something like 'the last occurence is at 3PM on 25th Jan (in whatever timezone I am in - these are floating times)', but that is impossible using a UTC UNTIL DATE-TIME. Damon On Mon, 2001-10-08 at 16:25, Doug Royer wrote: > > UNTIL means repeat until that date/time. So if you say repeat > this floating appointment UNTIL 20011225T000000Z, then it will not > and MUST NOT repeat after Dec 25th 2001 at 00:00:00 UTC. That is the > purpose and reason for UNTIL. > > Are you sure you don't want DTEND or DURATION? > > -Doug > > > Damon Chaplin wrote: > > > > The spec states that if an RRULE UNTIL parameter is specified as a > > DATE-TIME value, then it must be in UTC. > > > > However, what happens if the event's DTSTART is a floating time? > > How can you specify the last occurrence as a UTC time when the > > time of the occurrence changes depending on what timezone you are in? > > > > (I'm not totally sure I understand how DATE values and floating > > values are supposed to work, btw.) > > > > Damon --=-DSMiHtaM698gLq7MpBYQ Content-Type: text/html; charset=utf-8
The problem is that if you have a floating event, then setting the UNTIL time as a UTC time means that you may get a different number of occurrences, depending upon which timezone the floating time is 'resolved' in.

The user probably wants to say something like 'the last occurence is at 3PM on 25th Jan (in whatever timezone I am in - these are floating times)', but that is impossible using a UTC UNTIL DATE-TIME.

Damon

On Mon, 2001-10-08 at 16:25, Doug Royer wrote: 
> 
> UNTIL means repeat until that date/time. So if you say repeat
> this floating appointment UNTIL 20011225T000000Z, then it will not
> and MUST NOT repeat after Dec 25th 2001 at 00:00:00 UTC. That is the
> purpose and reason for UNTIL.
> 
> Are you sure you don't want DTEND or DURATION?
> 
> -Doug
> 
> 
> Damon Chaplin wrote:
> > 
> > The spec states that if an RRULE UNTIL parameter is specified as a
> > DATE-TIME value, then it must be in UTC.
> > 
> > However, what happens if the event's DTSTART is a floating time?
> > How can you specify the last occurrence as a UTC time when the
> > time of the occurrence changes depending on what timezone you are in?
> > 
> > (I'm not totally sure I understand how DATE values and floating
> > values are supposed to work, btw.)
> > 
> > Damon
--=-DSMiHtaM698gLq7MpBYQ-- From owner-ietf-calendar@mail.imc.org Wed Oct 10 15:18:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18934 for ; Wed, 10 Oct 2001 15:18:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9AJ1kZ16036 for ietf-calendar-bks; Wed, 10 Oct 2001 12:01:46 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9AJ1jD16031 for ; Wed, 10 Oct 2001 12:01:45 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA02275; Wed, 10 Oct 2001 12:01:40 -0700 (PDT) Message-ID: <3BC49A3F.7DE304D8@Royer.com> Date: Wed, 10 Oct 2001 12:58:07 -0600 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: Specifying RRULE UNTIL parameter for events using DATE or floatingtimes References: <1002330254.1016.14.camel@localhost.localdomain> <3BC20BA7.DBFA3BB6@Royer.com> <1002675629.3811.2.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="------------EC12B1FA83D4314F706683FA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EC12B1FA83D4314F706683FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Damon Chaplin wrote: > > The problem is that if you have a floating event, then setting the UNTIL > time as a UTC time means that you may get a different number of > occurrences, depending upon which timezone the floating time > is 'resolved' in. Well, as everyone knows 'Christmas' is in local time. So if you say repeat Christmas every 25th local time until Dec 25 2001 UTC then yes, but then that is what you told it to do. If you say repeat yearly every dec 25th Christmas local time until Dec 31 2001 UTC, then no. > The user probably wants to say something like 'the last occurence is > at 3PM on 25th Jan (in whatever timezone I am in - these are floating > times)', but that is impossible using a UTC UNTIL DATE-TIME. Then don't use it for that :-) --------------EC12B1FA83D4314F706683FA Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------EC12B1FA83D4314F706683FA-- From owner-ietf-calendar@mail.imc.org Wed Oct 10 17:56:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22083 for ; Wed, 10 Oct 2001 17:56:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9ALcfS20532 for ietf-calendar-bks; Wed, 10 Oct 2001 14:38:41 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9ALceD20528 for ; Wed, 10 Oct 2001 14:38:41 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA14694; Wed, 10 Oct 2001 17:38:37 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9ALcaT29457; Wed, 10 Oct 2001 17:38:36 -0400 (EDT) Message-ID: <3BC4BFFE.9ABF0100@steltor.com> Date: Wed, 10 Oct 2001 17:39:10 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: Doug Royer , ietf-calendar@imc.org Subject: Re: CAP: Filing of components References: <3BBDAA10.A5C864D6@steltor.com> <3BC2155C.A3CF8C9D@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > You invite users, not calendars. Calendaring and scheduling commands must be addressed to calendars and not to calendar users, as VCOMMANDs apply to calendars not to users. To invite users, you must address a VCOMMAND to one (or more) of their calendars by specifying a calendar address in the TARGET property. > If a user had multiple > calendars, they would have to specify their preferred > calendar. This is no different than email. If you have > more than one email address, persons wishing to reach you > need to know where to send the email, or they may email > to all of your addresses. But currently, users willing to file their components in different containers will end up with many more calendar addresses than email addresses. In the case of email, messages sent to your email address are delivered by SMTP to your mailbox. In addition to this mailbox, which is considered to be your primary mailbox, known as your "INBOX", IMAP allows you to have a hierarchy of mailboxes to file your messages as you want. We must notice that SMTP is not aware of all these other mailboxes (e.g., a user cannot send you a messages directly to one of your IMAP mailbox). Moreover, you don't get a new email address each time your create a new IMAP mailbox. IMAP has no notion of email addresses (other than the fact that messages contain email addresses in their header). The same way SMTP only has access to your primary mailbox (i.e., INBOX), I've proposed to limit scheduling commands to calendars, and the same way IMAP has access to your primary mailbox and all your other mailboxes, I've proposed to give calendaring commands access to both calendars and VFOLDERs. > > Failing that (read included text below): > > Bernard Desruisseaux wrote: > > > > CAP doesn't allow calendar users to move components between > > calendars. Currently, the MOVE command can only be "used to > > move a calendar within the CS's hierarchy of calendars". > > True, as a MOVE could not be done across calendar stores, > perhaps across vendor implementations, firewalls, domains, ... > (The same EFFECT is still possible - see my reply below). Currently, the MOVE command cannot be used to move calendars across calendar stores either. Since it has been decided that the first version of CAP would not address issues related to fanout, I don't see this has a big problem. Isn't it acceptable for the MOVE command to operate locally only? > > > If calendar users use multiple calendars for filing purposes, > > it is not clear that they will want to let other calendar users > > choose which calendar to address their scheduling commands to, > > since they won't be able to moved the components in the calendar > > of their choice afterwards. > > Yes and No. Perhaps the user only has access to your company > calendar (company-cal). You however keep everything impotant > to you on your ISP provided personal calendar (my-cal). > > There are two kinds of entries. Those made by the owner and unprocessed > invitations deposited by non-owners. The unprocessed invitations > are initially not committed to by the calendar owner/user they > are simply stored there until processed by the calendar owner. > > So, if someone drops a calendar appointment request (METHOD == REQUEST) > asking you to attend the school play into your work calendar (company-cal), > your USER AGENT assumes the responsibility (with user input) to determine > what to do, which might be: > > (1) Decide if you wish to attend. > (1.a) No - delete it. > (1.b) Yes - go to (2). > > (2) Copy the entry into YOUR preferred calendar (my-cal). > (3) Delete it from company-cal calendar. > (4) Reply (METHOD == REPLY), and confirm you are attending. > Setting you REPLY-TO value to be 'my-cal'. There is no mention of the REPLY-TO parameter in iCalendar and the current CAP draft. Could you provide us with more information on how this parameter would actually be used? > > Your UA will have to look into all of your calendars for legitimate > invitations anyway. And you UA will have to be able to create new > entries anyway. No new CAP code needed. > > Does this address your issue? I can understand the cost and complexity of moving component between calendars, such as "company-cal" and "my-cal". But the goal of my proposition is exactly to reduce the cost and complexity required when moving components only for filing purposes. Let's say that underneath my "company-cal" I have the sub- calendars "team-meetings" and "boring-meetings". Why would I have to let everybody know that I moved a meeting from "company-cal" to "boring-meetings"? Even though relcalid are supposed to be opaque, other users could probably still be able to find the names of my calendar (i.e., "boring-meetings"). > > > Although calendar users could use access rights (VCAR) to control > > which calendars other users can address their commands to, that > > would only allow filing based on users. > > Which may also be all you have if all your friends and busisness > associates do not have a username/password to all of your calendars. > Or if some are behind firewalls and have limited access. > For example, you PUBLIC-calendar may be outside your firewall > and you personal-calendar may be inside a firewall. Then they > could only make requests to your PUBLIC-calendar > > > I understand that allowing users to move components between > > calendars would prevent other calendar users to find these > > components directly in the calendars they expect. Obviously, > > it wouldn't be reasonable to notify other calendar users each > > time a component is moved between calendars, but on the other > > hand, what would be the usefulness of specifying the calendar > > address of ATTENDEEs in VEVENTs if one can't rely on them? > > At the time you METHOD == REPLY to an entry from someone else, > it MAY include a reply-to paramater which CAN BE a CAP address. > That is how they are informed on how and where to send updates > to you/your calendar. > > If YOU invide people to an event, THEN IF 'YOU' move the event's > calendar, then YES YOU MUST notify them, or else they can not reply. > That is done with a METHOD == UPDATE. Moving a calendar within the CS's hierarchy of calendars (i.e., not across CS) shouldn't affect the address of the calendar. So there is no need to notify the invited people in this case. > > > I would like to propose the addition of a new container, say > > VFOLDER (for lack of a better name), to allow filing of components > > within calendars, in such a way that moving components between > > these new containers would not change the calendar address where > > these components can be found. The MOVE command would have to be > > changed to allow components to be moved between these new containers. > > Given what I said above, do you feel this is still needed? Yes. Given that scheduling commands are required whenever a component is moved from one calendar to another, I don't think that calendars are the right containers to do filing. In my opinion, the way I file my components shouldn't have any impact on other users. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri Oct 12 07:49:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22505 for ; Fri, 12 Oct 2001 07:49:16 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9CBAF427812 for ietf-calendar-bks; Fri, 12 Oct 2001 04:10:15 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CBADD27808 for ; Fri, 12 Oct 2001 04:10:14 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21406; Fri, 12 Oct 2001 07:10:09 -0400 (EDT) Message-Id: <200110121110.HAA21406@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-many-xcal-00.txt Date: Fri, 12 Oct 2001 07:10:08 -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : iCalendar DTD Document (xCal) Author(s) : F. Dawson Jr., S. Reddy, D. Royer, E. Plamondon Filename : draft-ietf-calsch-many-xcal-00.txt Pages : 50 Date : 11-Oct-01 This memo defines a [XML] Document Type Definition (DTD) that corresponds to the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by [RFC 2445]. This DTD provides equivalent functionality to the standard format defined by [RFC 2445]. Documents structured in accordance with this DTD may also be known as 'XML iCalendar' documents or 'xCal'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-calsch-many-xcal-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-many-xcal-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011011132641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-many-xcal-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-many-xcal-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011011132641.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Fri Oct 12 08:14:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23370 for ; Fri, 12 Oct 2001 08:14:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9CBg8428607 for ietf-calendar-bks; Fri, 12 Oct 2001 04:42:08 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CBg7D28603 for ; Fri, 12 Oct 2001 04:42:07 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id HAA03830 for ; Fri, 12 Oct 2001 07:42:03 -0400 Received: from c1085 ([101.1.46.19]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9CBg2T06071 for ; Fri, 12 Oct 2001 07:42:02 -0400 (EDT) From: "Eric R. Plamondon" To: Subject: XML iCal draft changes Date: Fri, 12 Oct 2001 07:39:18 -0400 Message-ID: <002601c15312$87828840$132e0165@in.steltor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Good Morning, The XML iCal draft has recently been resubmitted through the Calendaring and Scheduling Working Group. http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt This is only an initial draft to restart (re-ignite?) the discussion on a possible representation of iCal in XML. Since the older draft expired, the goal, with the OK from Patricia Egen and Bob Mahoney, was to bring the draft back into the discussion, since many people have be asking about. The original authors will be contacted to determine whether they want to continue work on the draft. Having gone through the archives, there were a number of issues with the previous drafts. This version does not attempt to correct them, but rather reopen the discussion on them. Goal ---- The goal of the XML DTD (and schema) is to represent ical in XML. The names, formats, and structures should be a direct mapping from the iCalendar RPC. It is not the goal to change or improve on the iCalendar RPC. There were a few changes made to this reposting, from the previous draft-many-ical-xmldoc-01 document, outlined below. Summary of Changes ------------------ - Renamed the file from draft-many-ical-xmldoc-01 to draft-ietf-calsch-many-xcal-00 - Renamed the document from "iCalendar DTD Document" to "iCalendar DTD Document (xCal)" - removed references to "ICALXML" and replaced with "xCal" - changed the FPI for the DTD from -//IETF//DTD ICALXML/iCalendar XML//EN to -//IETF//DTD XCAL/iCalendar XML//EN - changed the FPI for standard value types from -//IETF/NOTATION ICALXML/Value Type/xxx/EN to -//IETF/NOTATION XCAL/Value Type/xxx/EN NOTE: these changes where made to the DTD as well. - changed all references from draft-many-ical-xmldoc-01 to draft-many-xcal-00 - changed the iCal namespace to xCal - changed the proposed MIME type from text/x-icalxml to text/x-xcal - In some of the examples, the xml formatting was removed (the XML version of the draft, using the DTD from rfc2629, failed to parse properly Property Parameters - the following property parameters where change to reflect their iCal counterpart - delfrom to delegated-from - delto to delegated-to - lang to language - trigtype to related - sentby to sent-by Component Properties - the following component properties where change to reflect their iCal counterpart - desc to description - end to dtend - start to dtstart - fbdata to freebusy - recurid to recurrence-id - related to related-to - last-mod to last-modified - seq to sequence - rstatus to request-status Structure Properties - the following structure properties where change to reflect their iCal counterpart - ical to vcalendar - event to vevent - todo to vtodo - journal to vjournal - freebusy to vfreebusy - timezone to vtimezone - alarm to valarm Issues to be discussed ====================== - should all the names be returned to upper case (or named case, as in XML schema). - there are a few places where attributes are used instead of child elements (e.g. in the vCalendar element the version, prodid, calscale, and method) - include an XML schema in this specification - resolve other errors in the draft document - correct the differences with "related" and "related-to" within the DTD - does the name "xCal" conflict too much with the X-Windows calendar program by the same name - If the original authors wish to continue work, their business information must be updated. - Provide a wbxml binding for xcal. Thanks, Eric ------------------------------- Eric R. Plamondon Steltor - Chief Web Architect 2000 Peel Street, 4th Floor Montreal, Quebec mailto:ericp@steltor.com http://www.steltor.com From owner-ietf-calendar@mail.imc.org Fri Oct 12 09:21:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26083 for ; Fri, 12 Oct 2001 09:21:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9CD28A00383 for ietf-calendar-bks; Fri, 12 Oct 2001 06:02:08 -0700 (PDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CD26D00379 for ; Fri, 12 Oct 2001 06:02:06 -0700 (PDT) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Fri, 12 Oct 2001 14:01:58 +0100 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 15s1wE-0005Il-00; Fri, 12 Oct 2001 14:01:18 +0100 Date: Fri, 12 Oct 2001 14:01:18 +0100 (BST) From: Libby Miller X-Sender: ecemm@mail.ilrt.bris.ac.uk To: "Eric R. Plamondon" cc: ietf-calendar , www-rdf-calendar@w3.org Subject: Re: XML iCal draft changes In-Reply-To: <002601c15312$87828840$132e0165@in.steltor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Eric We've been working on drafts of an RDF/XML calendar schema based on iCalendar[1], [2]. It looks like we should liaise with you guys, since our goals are similar, perhaps to produce a stylesheet which converts between the two, for example. Your message prompts me to ask a question: is there a model described anywhere for the work in icalendar or in xcal? Michael Arick did a brilliant job turning icalendar into UML[3], but I'd be interested to supplement this with what the thoughts were of the icalendar group _while_ the icalendar RFC was being created, if these are described anywhere. It doesn't have to be UML, just a summary diagram or description of the objects and properties. all the best Libby [1] http://ilrt.org/discovery/2001/04/calendar/ (RDF calendar homepage) [2] http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf (current schema draft, unstable) [3] http://www.cse.ucsc.edu/~marick/iCalendarUML.html -- Dr Libby Miller From owner-ietf-calendar@mail.imc.org Fri Oct 12 09:57:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27878 for ; Fri, 12 Oct 2001 09:57:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9CDdkk01217 for ietf-calendar-bks; Fri, 12 Oct 2001 06:39:46 -0700 (PDT) Received: from liffey.metamatrix.se (liffey.metamatrix.se [213.88.195.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CDdiD01213 for ; Fri, 12 Oct 2001 06:39:44 -0700 (PDT) Received: from foo (unknown [192.168.168.13]) by liffey.metamatrix.se (Postfix) with SMTP id 0C4432016E; Fri, 12 Oct 2001 15:39:38 +0200 (CEST) From: "Greg FitzPatrick" To: "Libby Miller" , "Eric R. Plamondon" Cc: "ietf-calendar" , Subject: XML iCal draft changes Date: Fri, 12 Oct 2001 15:39:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C15334.24E6E100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C15334.24E6E100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit this DTD corrects the "desc" "description" inconsistancy - Libby, did you include that in your version? - Somebody decided that description should be desc instead but forgot to correct that in an entitiy declaration. Hi Eric We've been working on drafts of an RDF/XML calendar schema based on iCalendar[1], [2]. It looks like we should liaise with you guys, since our goals are similar, perhaps to produce a stylesheet which converts between the two, for example. Your message prompts me to ask a question: is there a model described anywhere for the work in icalendar or in xcal? Michael Arick did a brilliant job turning icalendar into UML[3], but I'd be interested to supplement this with what the thoughts were of the icalendar group _while_ the icalendar RFC was being created, if these are described anywhere. It doesn't have to be UML, just a summary diagram or description of the objects and properties. all the best Libby [1] http://ilrt.org/discovery/2001/04/calendar/ (RDF calendar homepage) [2] http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf (current schema draft, unstable) [3] http://www.cse.ucsc.edu/~marick/iCalendarUML.html -- Dr Libby Miller ------=_NextPart_000_0005_01C15334.24E6E100 Content-Type: text/xml; name="2445-b.dtd" Content-Disposition: attachment; filename="2445-b.dtd" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0005_01C15334.24E6E100-- From owner-ietf-calendar@mail.imc.org Fri Oct 12 10:39:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29874 for ; Fri, 12 Oct 2001 10:39:47 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9CEKqE02005 for ietf-calendar-bks; Fri, 12 Oct 2001 07:20:52 -0700 (PDT) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CEKpD02001 for ; Fri, 12 Oct 2001 07:20:51 -0700 (PDT) To: ietf-calendar@imc.org Subject: RE-submission of iCalendar XML DTD draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 12 Oct 2001 10:20:50 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 10/12/2001 10:20:35 AM, Serialize complete at 10/12/2001 10:20:35 AM Content-Type: multipart/alternative; boundary="=_alternative 004EE3DC85256AE3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004EE3DC85256AE3_= Content-Type: text/plain; charset="us-ascii" The working group has resubmitted the expired draft that defines an XML DTD that compliments iCalendar. This draft was previously submitted with a different name. We have included calsch in the name to show that the group supports this draft and that we will add it to our charter based on the increased interest in XML. This is the url for this draft: http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt --=_alternative 004EE3DC85256AE3_= Content-Type: text/html; charset="us-ascii"
The working group has resubmitted the expired draft that defines an XML DTD that compliments iCalendar.  This draft was previously submitted with a different name.  We have included calsch in the name to show that the group supports this draft and that we will add it to our charter based on the increased interest in XML.

This is the url for this draft: http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt
 --=_alternative 004EE3DC85256AE3_=-- From owner-ietf-calendar@mail.imc.org Fri Oct 12 16:53:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09373 for ; Fri, 12 Oct 2001 16:53:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9CKZY116008 for ietf-calendar-bks; Fri, 12 Oct 2001 13:35:34 -0700 (PDT) Received: from gcs02 ([209.220.51.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CKZVD16001 for ; Fri, 12 Oct 2001 13:35:31 -0700 (PDT) Received: from dan3480 ([208.176.67.205]) by gcs02 with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 12 Oct 2001 13:26:14 +0100 From: "Dan Kohn" To: Cc: , , , "MURATA Makoto" , "'Simon St.Laurent'" Subject: MIME type in draft-ietf-calsch-many-xcal-00.txt Date: Fri, 12 Oct 2001 13:35:27 -0700 Message-ID: <005e01c1535d$6ec93ab0$cd43b0d0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt http://www.normos.org/ietf/rfc/rfc3023.txt As a co-author of RFC 3023, I urge you to reconsider your use of text/x-xcal (referred to in Section 5.12) as the MIME type for XML iCalendar entities. Specifically, I believe you will find in RFC 3023 the many reasons that application/calendar+xml is a much better approach. It's even mentioned as an example in the appendix. Please cc me on any replies, as I am not on the list. - dan -- Dan Kohn From owner-ietf-calendar@mail.imc.org Fri Oct 12 17:36:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10085 for ; Fri, 12 Oct 2001 17:36:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9CLKgk17163 for ietf-calendar-bks; Fri, 12 Oct 2001 14:20:42 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CLKfD17157 for ; Fri, 12 Oct 2001 14:20:41 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13159; Fri, 12 Oct 2001 14:20:11 -0700 (PDT) Message-ID: <3BC75DB4.D39ED0CA@Royer.com> Date: Fri, 12 Oct 2001 15:16:36 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Eric R. Plamondon" CC: ietf-calendar@imc.org Subject: Re: XML iCal draft changes References: <002601c15312$87828840$132e0165@in.steltor.com> Content-Type: multipart/mixed; boundary="------------E54AEDBEDEC330D7C78473CC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E54AEDBEDEC330D7C78473CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think that it would be a good idea. However we might want to consider XML/Schema (if it is close to ready) and not DTD. And only if there are schema parsers and validators that are available. ( http://www.w3.org/XML/Schema ) -Doug "Eric R. Plamondon" wrote: > > Good Morning, > > The XML iCal draft has recently been resubmitted > through the Calendaring and Scheduling Working Group. > > http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt > > This is only an initial draft to restart (re-ignite?) > the discussion on a possible representation of iCal > in XML. Since the older draft expired, the goal, > with the OK from Patricia Egen and Bob Mahoney, was to > bring the draft back into the discussion, since > many people have be asking about. The original authors > will be contacted to determine whether they want to > continue work on the draft. > > Having gone through the archives, there were a number > of issues with the previous drafts. This version does > not attempt to correct them, but rather reopen the > discussion on them. > > Goal > ---- > The goal of the XML DTD (and schema) is to represent > ical in XML. The names, formats, and structures should > be a direct mapping from the iCalendar RPC. It is not > the goal to change or improve on the iCalendar RPC. > > There were a few changes made to this reposting, > from the previous draft-many-ical-xmldoc-01 document, > outlined below. > > Summary of Changes > ------------------ > - Renamed the file from > draft-many-ical-xmldoc-01 > to > draft-ietf-calsch-many-xcal-00 > - Renamed the document from > "iCalendar DTD Document" > to > "iCalendar DTD Document (xCal)" > - removed references to "ICALXML" and replaced > with "xCal" > - changed the FPI for the DTD from > -//IETF//DTD ICALXML/iCalendar XML//EN > to > -//IETF//DTD XCAL/iCalendar XML//EN > - changed the FPI for standard value types from > -//IETF/NOTATION ICALXML/Value Type/xxx/EN > to > -//IETF/NOTATION XCAL/Value Type/xxx/EN > NOTE: these changes where made to the DTD as well. > - changed all references from > draft-many-ical-xmldoc-01 > to > draft-many-xcal-00 > - changed the iCal namespace to xCal > - changed the proposed MIME type from > text/x-icalxml > to > text/x-xcal > - In some of the examples, the > xml formatting was removed (the XML version > of the draft, using the DTD from rfc2629, > failed to parse properly > > Property Parameters > - the following property parameters where change to > reflect their iCal counterpart > - delfrom to delegated-from > - delto to delegated-to > - lang to language > - trigtype to related > - sentby to sent-by > > Component Properties > - the following component properties where change to > reflect their iCal counterpart > - desc to description > - end to dtend > - start to dtstart > - fbdata to freebusy > - recurid to recurrence-id > - related to related-to > - last-mod to last-modified > - seq to sequence > - rstatus to request-status > > Structure Properties > - the following structure properties where change to > reflect their iCal counterpart > - ical to vcalendar > - event to vevent > - todo to vtodo > - journal to vjournal > - freebusy to vfreebusy > - timezone to vtimezone > - alarm to valarm > > Issues to be discussed > ====================== > - should all the names be returned to upper case > (or named case, as in XML schema). > - there are a few places where attributes are used > instead of child elements (e.g. in the vCalendar > element the version, prodid, calscale, and method) > - include an XML schema in this specification > - resolve other errors in the draft document > - correct the differences with "related" and "related-to" > within the DTD > - does the name "xCal" conflict too much with the > X-Windows calendar program by the same name > - If the original authors wish to continue work, their > business information must be updated. > - Provide a wbxml binding for xcal. > > Thanks, > Eric > > ------------------------------- > Eric R. Plamondon > Steltor - Chief Web Architect > 2000 Peel Street, 4th Floor > Montreal, Quebec > mailto:ericp@steltor.com > http://www.steltor.com --------------E54AEDBEDEC330D7C78473CC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------E54AEDBEDEC330D7C78473CC-- From owner-ietf-calendar@mail.imc.org Mon Oct 15 07:25:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23692 for ; Mon, 15 Oct 2001 07:25:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9FB35219054 for ietf-calendar-bks; Mon, 15 Oct 2001 04:03:05 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FB30D19043 for ; Mon, 15 Oct 2001 04:03:04 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id HAA30794; Mon, 15 Oct 2001 07:02:17 -0400 Received: from c1085 ([101.1.46.19]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9FB2ET01867; Mon, 15 Oct 2001 07:02:15 -0400 (EDT) From: "Eric R. Plamondon" To: "'Dan Kohn'" , Cc: , , "'MURATA Makoto'" , "'Simon St.Laurent'" , "'Eric R. Plamondon'" Subject: RE: MIME type in draft-ietf-calsch-many-xcal-00.txt Date: Mon, 15 Oct 2001 06:59:14 -0400 Message-ID: <001501c15568$6f1daca0$132e0165@in.steltor.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C15546.E80C0CA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <005e01c1535d$6ec93ab0$cd43b0d0@skymoonventures.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C15546.E80C0CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good Morning, after reading RFC 3023, I agree that the MIME type should be changed. So, I'll go along with "application/calendar+xml" and "application/calendar+wbxml" (as per Frank Dawson's wanting to include a wbxml version for the WAP, wireless, and SyncML communities). Any objections? Eric ------------------------------- Eric R. Plamondon Steltor - Chief Web Architect 2000 Peel Street, 4th Floor Montreal, Quebec mailto:ericp@steltor.com http://www.steltor.com > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of Dan Kohn > Sent: Friday, October 12, 2001 4:35 PM > To: ietf-calendar@imc.org > Cc: Frank_Dawson@lotus.com; skreddy@us.oracle.com; > ericp@steltor.com; MURATA Makoto; 'Simon St.Laurent' > Subject: MIME type in draft-ietf-calsch-many-xcal-00.txt > > > http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt http://www.normos.org/ietf/rfc/rfc3023.txt As a co-author of RFC 3023, I urge you to reconsider your use of text/x-xcal (referred to in Section 5.12) as the MIME type for XML iCalendar entities. Specifically, I believe you will find in RFC 3023 the many reasons that application/calendar+xml is a much better approach. It's even mentioned as an example in the appendix. Please cc me on any replies, as I am not on the list. - dan -- Dan Kohn ------=_NextPart_000_0016_01C15546.E80C0CA0 Content-Type: text/x-vcard; name="Eric Plamondon.vcf" Content-Disposition: attachment; filename="Eric Plamondon.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Plamondon;Eric FN:Eric Plamondon ORG:;Steltor TITLE:Developer (Client) TEL;WORK;VOICE:(514) 733-8500 x272 TEL;CELL;VOICE:+15149108500 EMAIL;PREF;INTERNET:EricP@Steltor.com REV:20010725T112905Z END:VCARD ------=_NextPart_000_0016_01C15546.E80C0CA0-- From owner-ietf-calendar@mail.imc.org Mon Oct 15 11:20:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02391 for ; Mon, 15 Oct 2001 11:20:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9FF0w603058 for ietf-calendar-bks; Mon, 15 Oct 2001 08:00:58 -0700 (PDT) Received: from eeyore.jsoft.com (mail.jsoft.com [24.240.234.245] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FF0vD03054 for ; Mon, 15 Oct 2001 08:00:57 -0700 (PDT) Received: from jsoft.com (IDENT:ggf@eeyore.jsoft.com [192.168.1.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id f9FEwfA01809; Mon, 15 Oct 2001 09:58:41 -0500 Message-ID: <3BCAF9A0.50701@jsoft.com> Date: Mon, 15 Oct 2001 09:58:40 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: "Eric R. Plamondon" , ietf-calendar@imc.org Subject: Re: XML iCal draft changes References: <002601c15312$87828840$132e0165@in.steltor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Great! (re-ignite :-)) I have been working on XML versions of iCalendar data. I tend to keep what I do 'loose' so when (not if) a standard came out, I could fit my work into the standard. I have a patch to the libical libarary that reads an iCalendar file and outputs XML. The XML uses tags from RFC 2445, 'component', 'property', 'value' with a 'name' attribute to identify each tag. The XML format (I call it iCal...) is awkward. I played a bit with an XSLT stylesheet to translate to xCal. It may be useful to the rest of us to see some of what I did. I'll clean things up a bit and pass on to those interested. Gary === an iCal fragment -//StarSchedule//NONSGML ?#\"StarOffice 5.2\"//EN ... 882998/5524/250 Starting Homeschooling Free Workshop at The Homeschool Store.\nStarting Homeschooling - It\'s a Piece of Cake!\nLearn the basics and get off to a great start.\n713-683-8894\nwww.thehomeschoolstore.com HSEvents 1 PUBLIC === a version of an XSLT stylesheet that prints xCal Test listing xcs Date start:
Date end:
Summary:
Location:
Eric R. Plamondon wrote: > Good Morning, > > The XML iCal draft has recently been resubmitted > through the Calendaring and Scheduling Working Group. > > http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt > > This is only an initial draft to restart (re-ignite?) > the discussion on a possible representation of iCal > in XML. Since the older draft expired, the goal, > with the OK from Patricia Egen and Bob Mahoney, was to > bring the draft back into the discussion, since > many people have be asking about. The original authors > will be contacted to determine whether they want to > continue work on the draft. > > Having gone through the archives, there were a number > of issues with the previous drafts. This version does > not attempt to correct them, but rather reopen the > discussion on them. > > Goal > ---- > The goal of the XML DTD (and schema) is to represent > ical in XML. The names, formats, and structures should > be a direct mapping from the iCalendar RPC. It is not > the goal to change or improve on the iCalendar RPC. > > There were a few changes made to this reposting, > from the previous draft-many-ical-xmldoc-01 document, > outlined below. > > Summary of Changes > ------------------ > - Renamed the file from > draft-many-ical-xmldoc-01 > to > draft-ietf-calsch-many-xcal-00 > - Renamed the document from > "iCalendar DTD Document" > to > "iCalendar DTD Document (xCal)" > - removed references to "ICALXML" and replaced > with "xCal" > - changed the FPI for the DTD from > -//IETF//DTD ICALXML/iCalendar XML//EN > to > -//IETF//DTD XCAL/iCalendar XML//EN > - changed the FPI for standard value types from > -//IETF/NOTATION ICALXML/Value Type/xxx/EN > to > -//IETF/NOTATION XCAL/Value Type/xxx/EN > NOTE: these changes where made to the DTD as well. > - changed all references from > draft-many-ical-xmldoc-01 > to > draft-many-xcal-00 > - changed the iCal namespace to xCal > - changed the proposed MIME type from > text/x-icalxml > to > text/x-xcal > - In some of the examples, the > xml formatting was removed (the XML version > of the draft, using the DTD from rfc2629, > failed to parse properly > > Property Parameters > - the following property parameters where change to > reflect their iCal counterpart > - delfrom to delegated-from > - delto to delegated-to > - lang to language > - trigtype to related > - sentby to sent-by > > Component Properties > - the following component properties where change to > reflect their iCal counterpart > - desc to description > - end to dtend > - start to dtstart > - fbdata to freebusy > - recurid to recurrence-id > - related to related-to > - last-mod to last-modified > - seq to sequence > - rstatus to request-status > > Structure Properties > - the following structure properties where change to > reflect their iCal counterpart > - ical to vcalendar > - event to vevent > - todo to vtodo > - journal to vjournal > - freebusy to vfreebusy > - timezone to vtimezone > - alarm to valarm > > Issues to be discussed > ====================== > - should all the names be returned to upper case > (or named case, as in XML schema). > - there are a few places where attributes are used > instead of child elements (e.g. in the vCalendar > element the version, prodid, calscale, and method) > - include an XML schema in this specification > - resolve other errors in the draft document > - correct the differences with "related" and "related-to" > within the DTD > - does the name "xCal" conflict too much with the > X-Windows calendar program by the same name > - If the original authors wish to continue work, their > business information must be updated. > - Provide a wbxml binding for xcal. > > Thanks, > Eric > > ------------------------------- > Eric R. Plamondon > Steltor - Chief Web Architect > 2000 Peel Street, 4th Floor > Montreal, Quebec > mailto:ericp@steltor.com > http://www.steltor.com > From owner-ietf-calendar@mail.imc.org Mon Oct 15 11:29:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02684 for ; Mon, 15 Oct 2001 11:29:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9FFBBx03346 for ietf-calendar-bks; Mon, 15 Oct 2001 08:11:11 -0700 (PDT) Received: from eeyore.jsoft.com (mail.jsoft.com [24.240.234.245] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FFB9D03340 for ; Mon, 15 Oct 2001 08:11:09 -0700 (PDT) Received: from jsoft.com (IDENT:ggf@eeyore.jsoft.com [192.168.1.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id f9FF9lA01853; Mon, 15 Oct 2001 10:09:47 -0500 Message-ID: <3BCAFC3B.3040900@jsoft.com> Date: Mon, 15 Oct 2001 10:09:47 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar , www-rdf-calendar@w3.org Subject: Re: XML iCal draft changes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I like what I had seen of the RDF/XML calendar work. The thought that kept coming up for me was that there were at least two 'parts' that could come out of all the work. One a description (dtd) of iCalendar based on RFC 2445 and another that was the rest of the calendaring standards in RDF. Then you would have eg as part of the iCalendar dtd and RDF that described relationships etc from RFC 2446 etc. Gary Libby Miller wrote: > Hi Eric > > We've been working on drafts of an RDF/XML calendar schema based on > iCalendar[1], [2]. It looks like we should liaise with you guys, since > our goals are similar, perhaps to produce a stylesheet which converts > between the two, for example. > > Your message prompts me to ask a question: is there a model described > anywhere for the work in icalendar or in xcal? Michael Arick did a > brilliant job turning icalendar into UML[3], but I'd be interested to > supplement this with what the thoughts were of the icalendar group > _while_ the icalendar RFC was being created, if these are described > anywhere. It doesn't have to be UML, just a summary diagram or > description of the objects and properties. > > > all the best > > Libby > > > [1] http://ilrt.org/discovery/2001/04/calendar/ (RDF calendar homepage) > [2] http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf > (current schema draft, unstable) > [3] http://www.cse.ucsc.edu/~marick/iCalendarUML.html > > > -- > Dr Libby Miller > > > From owner-ietf-calendar@mail.imc.org Mon Oct 15 11:42:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03099 for ; Mon, 15 Oct 2001 11:42:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9FFR9b03782 for ietf-calendar-bks; Mon, 15 Oct 2001 08:27:09 -0700 (PDT) Received: from eeyore.jsoft.com (mail.jsoft.com [24.240.234.245] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FFR8D03777 for ; Mon, 15 Oct 2001 08:27:08 -0700 (PDT) Received: from jsoft.com (IDENT:ggf@eeyore.jsoft.com [192.168.1.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id f9FFPkA02161 for ; Mon, 15 Oct 2001 10:25:46 -0500 Message-ID: <3BCAFFFA.3060800@jsoft.com> Date: Mon, 15 Oct 2001 10:25:46 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: What should the xCal tag names case be? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Playing with examples of xCal brought up an issue, the case of the xCal tags. The xCal examples use mostly lowercase. I have been using StarOffice and Evolution as example applications that generate iCalendar and they both use UPPERCASE. However, StarOffice uses lowercase in their xcs files. The examples in RFC 2445 use UPPERCASE. RFC 2445 states: "All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated." The XML tag names will be case sensitive. If we pick all lower or all UPPER for all the tags, it may make things a bit easier when translating from iCalendar to xCal. i think lower case looks better. ymmv Gary From owner-ietf-calendar@mail.imc.org Mon Oct 15 12:14:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03973 for ; Mon, 15 Oct 2001 12:14:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9FFutV07840 for ietf-calendar-bks; Mon, 15 Oct 2001 08:56:55 -0700 (PDT) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FFurD07830 for ; Mon, 15 Oct 2001 08:56:53 -0700 (PDT) To: ericp@steltor.com Cc: "'Dan Kohn'" , "'Eric R. Plamondon'" , Frank_Dawson@lotus.com, ietf-calendar@imc.org, "'MURATA Makoto'" , owner-ietf-calendar@mail.imc.org, "'Simon St.Laurent'" , skreddy@us.oracle.com Subject: RE: MIME type in draft-ietf-calsch-many-xcal-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_10092001 October 09, 2001 Message-ID: From: Robert_Ransdell@iris.com Date: Mon, 15 Oct 2001 12:06:11 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 10/15/2001 12:03:09 PM Content-Type: multipart/mixed; boundary="=_mixed 00571ADD85256AE6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 00571ADD85256AE6_= Content-Type: multipart/alternative; boundary="=_alternative 00571ADD85256AE6_=" --=_alternative 00571ADD85256AE6_= Content-Type: text/plain; charset="US-ASCII" Just curious, If I enhance my code to understand both types ; would I set up the mime layer as: multipart alternative text/plain text/html text/calendar application/calendar+xml end alternative "Eric R. Plamondon" Sent by: owner-ietf-calendar@mail.imc.org 10/15/2001 06:59 AM To: "'Dan Kohn'" , cc: , , "'MURATA Makoto'" , "'Simon St.Laurent'" , "'Eric R. Plamondon'" , (bcc: Robert Ransdell/Iris) Subject: RE: MIME type in draft-ietf-calsch-many-xcal-00.txt Good Morning, after reading RFC 3023, I agree that the MIME type should be changed. So, I'll go along with "application/calendar+xml" and "application/calendar+wbxml" (as per Frank Dawson's wanting to include a wbxml version for the WAP, wireless, and SyncML communities). Any objections? Eric ------------------------------- Eric R. Plamondon Steltor - Chief Web Architect 2000 Peel Street, 4th Floor Montreal, Quebec mailto:ericp@steltor.com http://www.steltor.com > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of Dan Kohn > Sent: Friday, October 12, 2001 4:35 PM > To: ietf-calendar@imc.org > Cc: Frank_Dawson@lotus.com; skreddy@us.oracle.com; > ericp@steltor.com; MURATA Makoto; 'Simon St.Laurent' > Subject: MIME type in draft-ietf-calsch-many-xcal-00.txt > > > http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt http://www.normos.org/ietf/rfc/rfc3023.txt As a co-author of RFC 3023, I urge you to reconsider your use of text/x-xcal (referred to in Section 5.12) as the MIME type for XML iCalendar entities. Specifically, I believe you will find in RFC 3023 the many reasons that application/calendar+xml is a much better approach. It's even mentioned as an example in the appendix. Please cc me on any replies, as I am not on the list. - dan -- Dan Kohn --=_alternative 00571ADD85256AE6_= Content-Type: text/html; charset="US-ASCII"
Just curious, If I enhance my code to understand both types ; would I set up the mime layer as:
multipart alternative
  text/plain
  text/html
  text/calendar
  application/calendar+xml
end alternative



"Eric R. Plamondon" <ericp@steltor.com>
Sent by: owner-ietf-calendar@mail.imc.org

10/15/2001 06:59 AM

       
        To:        "'Dan Kohn'" <dan@dankohn.com>, <ietf-calendar@imc.org>
        cc:        <Frank_Dawson@lotus.com>, <skreddy@us.oracle.com>, "'MURATA Makoto'" <mmurata@trl.ibm.co.jp>, "'Simon St.Laurent'" <simonstl@simonstl.com>, "'Eric R. Plamondon'" <ericp@steltor.com>, (bcc: Robert Ransdell/Iris)
        Subject:        RE: MIME type in draft-ietf-calsch-many-xcal-00.txt



Good Morning,

after reading RFC 3023, I agree that the MIME type should be changed.
So, I'll go along with "application/calendar+xml" and
"application/calendar+wbxml" (as per Frank Dawson's wanting to
include a wbxml version for the WAP, wireless, and SyncML communities).

Any objections?

Eric

-------------------------------
Eric R. Plamondon
Steltor - Chief Web Architect
2000 Peel Street, 4th Floor
Montreal, Quebec
mailto:ericp@steltor.com
http://www.steltor.com


> -----Original Message-----
> From: owner-ietf-calendar@mail.imc.org
> [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of Dan Kohn
> Sent: Friday, October 12, 2001 4:35 PM
> To: ietf-calendar@imc.org
> Cc: Frank_Dawson@lotus.com; skreddy@us.oracle.com;
> ericp@steltor.com; MURATA Makoto; 'Simon St.Laurent'
> Subject: MIME type in draft-ietf-calsch-many-xcal-00.txt
>
>
>
http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt
http://www.normos.org/ietf/rfc/rfc3023.txt

As a co-author of RFC 3023, I urge you to reconsider your use of
text/x-xcal (referred to in Section 5.12) as the MIME type for XML
iCalendar entities.  Specifically, I believe you will find in RFC 3023
the many reasons that application/calendar+xml is a much better
approach.  It's even mentioned as an example in the appendix.

Please cc me on any replies, as I am not on the list.

                                 - dan
--
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

--=_alternative 00571ADD85256AE6_=-- --=_mixed 00571ADD85256AE6_= Content-Type: application/octet-stream; name="Eric Plamondon.vcf" Content-Disposition: attachment; filename="Eric Plamondon.vcf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOlBsYW1vbmRvbjtFcmljDQpGTjpFcmljIFBsYW1v bmRvbg0KT1JHOjtTdGVsdG9yDQpUSVRMRTpEZXZlbG9wZXIgKENsaWVudCkNClRFTDtXT1JLO1ZP SUNFOig1MTQpIDczMy04NTAwIHgyNzINClRFTDtDRUxMO1ZPSUNFOisxNTE0OTEwODUwMA0KRU1B SUw7UFJFRjtJTlRFUk5FVDpFcmljUEBTdGVsdG9yLmNvbQ0KUkVWOjIwMDEwNzI1VDExMjkwNVoN CkVORDpWQ0FSRA0K --=_mixed 00571ADD85256AE6_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 15 18:02:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13772 for ; Mon, 15 Oct 2001 18:02:29 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9FLkr117404 for ietf-calendar-bks; Mon, 15 Oct 2001 14:46:53 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FLkqD17400 for ; Mon, 15 Oct 2001 14:46:52 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA11274; Mon, 15 Oct 2001 14:46:53 -0700 (PDT) Message-ID: <3BCB5827.D31927BF@Royer.com> Date: Mon, 15 Oct 2001 15:41:59 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: XML iCal draft changes References: <002601c15312$87828840$132e0165@in.steltor.com> <3BCAF9A0.50701@jsoft.com> Content-Type: multipart/mixed; boundary="------------A503EB4A280650A7C2FACB31" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A503EB4A280650A7C2FACB31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would be in favor of the use of namesapces, something like: -//StarSchedule//NONSGML ?#\"StarOffice 5.2\"//EN -//StarSchedule//NONSGML ?#\"StarOffice 5.2\"//EN Starting Homeschooling Free Workshop at The Homeschool Store.\nStarting Homeschooling - It\'s a Piece of Cake!\nLearn the basics and get off to a great start.\n713-683-8894\nwww.thehomeschoolstore.com HSEvents 1 PUBIC --------------A503EB4A280650A7C2FACB31 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------A503EB4A280650A7C2FACB31-- From owner-ietf-calendar@mail.imc.org Mon Oct 15 20:53:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16331 for ; Mon, 15 Oct 2001 20:53:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9G0YMS20198 for ietf-calendar-bks; Mon, 15 Oct 2001 17:34:22 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9G0YKD20194 for ; Mon, 15 Oct 2001 17:34:20 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA13823; Mon, 15 Oct 2001 17:34:20 -0700 (PDT) Message-ID: <3BCB7F39.1948F17E@Royer.com> Date: Mon, 15 Oct 2001 18:28:41 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Filing of components References: <3BBDAA10.A5C864D6@steltor.com> <3BC2155C.A3CF8C9D@Royer.com> <3BC4BFFE.9ABF0100@steltor.com> Content-Type: multipart/mixed; boundary="------------2431FC96DE44F0690ED3F576" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2431FC96DE44F0690ED3F576 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > You invite users, not calendars. > > Calendaring and scheduling commands must be addressed to > calendars and not to calendar users, as VCOMMANDs apply > to calendars not to users. Yes, but before you do that, you wanted to schedule with a ATTENDEE, and you had to choose which calendar to select in order to invite the user. (Work, Personal, Team, Project, ...). And in the current world, you have to know that information directly or by looking into some directory service. > To invite users, you must address a VCOMMAND to one (or > more) of their calendars by specifying a calendar address > in the TARGET property. Yes, but it must be a METHOD:REQUEST to invite the ATTENDEE. And the ATTENDEE MUST BE known in advance. And the ATTENDEE can be a calendar, email address, UPN, or whatever else is defined as a valid ATTENDEE. > > If a user had multiple > > calendars, they would have to specify their preferred > > calendar. This is no different than email. If you have > > more than one email address, persons wishing to reach you > > need to know where to send the email, or they may email > > to all of your addresses. > > But currently, users willing to file their components in > different containers will end up with many more calendar > addresses than email addresses. Yes they can, but I suspect that calendar users that are persons will consolidate the information into one calendar or a few calendars that contains only things they care about. > In the case of email, messages sent to your email address > are delivered by SMTP to your mailbox. In addition to this > mailbox, which is considered to be your primary mailbox, > known as your "INBOX", IMAP allows you to have a hierarchy > of mailboxes to file your messages as you want. > > We must notice that SMTP is not aware of all these other > mailboxes (e.g., a user cannot send you a messages directly > to one of your IMAP mailbox). Moreover, you don't get a > new email address each time your create a new IMAP mailbox. > IMAP has no notion of email addresses (other than the fact > that messages contain email addresses in their header). The calendering world is somewhat the opposite problem of email. We export multiple calendars based on who the CU wishes to see the calendar. I don't think that my customers want to see my personal appointments. So I don't put personal booked events into my public calendar. However the scheduled and not booked events, could be placed into a non-personal calendar and my CUA can then be directed to place them in my personal calendar, accept, and update the SENT-BY parameter in the ATTENDEE property. If you choose to METHOD:CREATE, then YES you have to know the exact name of the calendar and you have to have permission to book an event. However if you METHOD:REQUEST, it only has to be in any calendar available to the intended ATTENDEE for which you have a METHOD:REQUEST VCAR. You DO NOT NEED to know the final destination calendar as you are scheduling with the ATTENDEE by using a specific calendar for which you know the intended invited ATTENDEE scans. The CS for that calendar would have to make sure that ATTENDEE has READ and DELETE or UPDATE permission in that calendar in addition to the ORGINIZERs ability to do a METHOD:REQUEST into that calendar. Then it is a valid scheduling request and may be stored. You, your CUA, or the protocol does not need to know if it is the primary calendar for the targeted ATTENDEE(s). The difference between inboxes/folders and calendars is that with calendars you can have a finer grain of access. I may give anyone a VCAR to schedule in my ~top~ calendar. And perhaps only my boss (and me) has the ability to book in my work calendar. As he would not schedule with me, he may just inform me of the events. I would not want to give my boss an open VCAR to write ANY component using a METHOD:CREATE into my personal calendar. I could limit it to VEVENT or VTODO or whatever by correct usage of a VCAR, but I can't control the intended content of the VEVENT or VTODO using VCAR's. Plus the CUA used by my boss might not be able to book the event if the CS's do not allow overlapped booking - there would be no way for a boss to book the events with possible conflicts on a large number of work calendars for multiple users. His CUA would be scanning a large number of calendar, trying to book, only to find conflicts. Only to find that no one is busy at 2-3am :-) The only way to do this is to give the boss a calendar to book into. > The same way SMTP only has access to your primary mailbox > (i.e., INBOX), I've proposed to limit scheduling commands > to calendars, and the same way IMAP has access to your primary > mailbox and all your other mailboxes, I've proposed to give > calendaring commands access to both calendars and VFOLDERs. I don't understand, you can schedule (METHOD:REQUEST) any calendar already. (You say: "I've proposed to limit..."). > > > > Failing that (read included text below): > > > > Bernard Desruisseaux wrote: > > > > > > CAP doesn't allow calendar users to move components between > > > calendars. Currently, the MOVE command can only be "used to > > > move a calendar within the CS's hierarchy of calendars". > > > > True, as a MOVE could not be done across calendar stores, > > perhaps across vendor implementations, firewalls, domains, ... > > (The same EFFECT is still possible - see my reply below). > > Currently, the MOVE command cannot be used to move calendars > across calendar stores either. Since it has been decided that > the first version of CAP would not address issues related to > fanout, I don't see this has a big problem. Isn't it acceptable > for the MOVE command to operate locally only? Fanout is orthogonal. You can't move across CS's because it would require all kinds of locking and access problems between the CS's that would have to have an account/password between them, it would require the CS's to spoof the other user ids, store (or temporarily lend) their passwords (A BIG NO NO!), and then a complete recovery protocol if things failed. Are you assuming that all calendars (for the move) have the same login/password on the same host and in the same process? That works now. If they are not in the same process, you are doing part of fanout. To move an event across CS's: copy the event. If it works, delete the old one. If the item is booked (vs scheduled), then send an updated METOD:REPLY with an updated SENT-BY in the ATTENDEE. > > > > > If calendar users use multiple calendars for filing purposes, > > > it is not clear that they will want to let other calendar users > > > choose which calendar to address their scheduling commands to, > > > since they won't be able to moved the components in the calendar > > > of their choice afterwards. > > > > Yes and No. Perhaps the user only has access to your company > > calendar (company-cal). You however keep everything impotant > > to you on your ISP provided personal calendar (my-cal). > > > > There are two kinds of entries. Those made by the owner and unprocessed > > invitations deposited by non-owners. The unprocessed invitations > > are initially not committed to by the calendar owner/user they > > are simply stored there until processed by the calendar owner. > > > > So, if someone drops a calendar appointment request (METHOD == REQUEST) > > asking you to attend the school play into your work calendar (company-cal), > > your USER AGENT assumes the responsibility (with user input) to determine > > what to do, which might be: > > > > (1) Decide if you wish to attend. > > (1.a) No - delete it. > > (1.b) Yes - go to (2). > > > > (2) Copy the entry into YOUR preferred calendar (my-cal). > > (3) Delete it from company-cal calendar. > > (4) Reply (METHOD == REPLY), and confirm you are attending. > > Setting you REPLY-TO value to be 'my-cal'. > > There is no mention of the REPLY-TO parameter in iCalendar > and the current CAP draft. Could you provide us with more > information on how this parameter would actually be used? Sorry, I meant the SENT-BY parameter to the ATTENDEE property. That is the reason SENT-BY exists, to redirect the calendar items back to the SENT-BY value for the ATTENDEE (or ORGANIZER) And in CAP (or not yet in CAP :-), was the idea that we were updating SENT-BY to be an email address, URI, or calendar. As it is the ONLY way to update users of calendar name changes for booked items and scheduled requests. > > > > Your UA will have to look into all of your calendars for legitimate > > invitations anyway. And you UA will have to be able to create new > > entries anyway. No new CAP code needed. > > > > Does this address your issue? > > I can understand the cost and complexity of moving component > between calendars, such as "company-cal" and "my-cal". But > the goal of my proposition is exactly to reduce the cost > and complexity required when moving components only for > filing purposes. > > Let's say that underneath my "company-cal" I have the sub- > calendars "team-meetings" and "boring-meetings". Why would > I have to let everybody know that I moved a meeting from > "company-cal" to "boring-meetings"? Even though relcalid > are supposed to be opaque, other users could probably still > be able to find the names of my calendar (i.e., "boring-meetings"). You don't have to let them know - IF all they are doing is scheduling commands - are you busy - and maybe to find out why. If they created the item in "my-cal" with a METHOD:REQUEST, then you move it to "boring-meetings" and never tell them. Because any update will go to "my-cal" and your CUA already looks there and in "boring-meetings" (and all of your other calendars) and it knows that UID:12345 is booked in "boring-meetings", your CUA can acknowledge any update and never tell anyone. If you do want to tell them update the ATTENDEE:...SENT-BY... in the METHOD:REPLY. If you decided not to attend the meeting and do a METHOD:REPLY, then the CU/CUA can keep it in the "my-cal" calendar, store it in a hidden look-aside calendar used to store dead requests for a while. It can be moved to "boring-meetings" and marked no, ... If you are going to allow them to book the item, then yes you MUST tell them the exact calendar name. For the most part, only the CU/OWNER will do direct booking. > > > > > Although calendar users could use access rights (VCAR) to control > > > which calendars other users can address their commands to, that > > > would only allow filing based on users. > > > > Which may also be all you have if all your friends and busisness > > associates do not have a username/password to all of your calendars. > > Or if some are behind firewalls and have limited access. > > For example, you PUBLIC-calendar may be outside your firewall > > and you personal-calendar may be inside a firewall. Then they > > could only make requests to your PUBLIC-calendar > > > > > I understand that allowing users to move components between > > > calendars would prevent other calendar users to find these > > > components directly in the calendars they expect. Obviously, > > > it wouldn't be reasonable to notify other calendar users each > > > time a component is moved between calendars, but on the other > > > hand, what would be the usefulness of specifying the calendar > > > address of ATTENDEEs in VEVENTs if one can't rely on them? > > > > At the time you METHOD == REPLY to an entry from someone else, > > it MAY include a reply-to paramater which CAN BE a CAP address. > > That is how they are informed on how and where to send updates > > to you/your calendar. > > > > If YOU invide people to an event, THEN IF 'YOU' move the event's > > calendar, then YES YOU MUST notify them, or else they can not reply. > > That is done with a METHOD == UPDATE. > > Moving a calendar within the CS's hierarchy of calendars > (i.e., not across CS) shouldn't affect the address of the > calendar. So there is no need to notify the invited people > in this case. It does if the move is to the ORGANIZERs calendar as the ORGANIZER cal-address has changed which can be a CAP-address. If you move item ABC from CAL-one into CAL-two. When the users do a reply with a METHOD:UPDATE directed to CAl-one, it no longer exists. The ORGANIZER MUST notify the ATTENDEEs of the change if it expects any METHOD:REPLY. Which can be sent for ANY and ALL METHOD:REQUESTs, so I would argue that if it is moved and the ORGANIZER address is a CAP-address, then the ORGANIZER MUST update the ATTENDEEs. Or it MUST BE done if you wish to redirect all updates to a new cal-address and you are the ATTENDEE. > > > > > I would like to propose the addition of a new container, say > > > VFOLDER (for lack of a better name), to allow filing of components > > > within calendars, in such a way that moving components between > > > these new containers would not change the calendar address where > > > these components can be found. The MOVE command would have to be > > > changed to allow components to be moved between these new containers. > > > > Given what I said above, do you feel this is still needed? > > Yes. Given that scheduling commands are required whenever > a component is moved from one calendar to another, I don't > think that calendars are the right containers to do filing. > In my opinion, the way I file my components shouldn't have > any impact on other users. It only has to care when they are doing direct booking. It does not effect scheduling requests. And as there MUST BE a way to do direct booking (or NO CUA could function), don't invite ATTENDEEs and use non-scheduling CAP direct booking. Use CAP-Scheduling methods (iTIP scheduling methods). --------------2431FC96DE44F0690ED3F576 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------2431FC96DE44F0690ED3F576-- From owner-ietf-calendar@mail.imc.org Mon Oct 15 21:16:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16455 for ; Mon, 15 Oct 2001 21:16:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9G0xfI20506 for ietf-calendar-bks; Mon, 15 Oct 2001 17:59:41 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9G0xeD20502 for ; Mon, 15 Oct 2001 17:59:40 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA14217; Mon, 15 Oct 2001 17:59:40 -0700 (PDT) Message-ID: <3BCB850D.FDAAB863@Royer.com> Date: Mon, 15 Oct 2001 18:53:33 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: SENT-BY / cal-address - we forgot to update. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In the recent discussion of Filing of components discussion, I went to prove a point only to find the point was never written down. With CAP the ATTENDEE and ORGANIZER properties needed to have a way to specify the reply target calendar. So the list agreed to update the SENT-BY in CAP to specify that a 'cal-address' (as originally defined in 2445) can also be a CAP URI or UPN. This also effects the SENT-BY parameter. I don't think anything has changed, so to whoever is keeping the TO-DO list, I think this is a TO-DO in the draft. -Doug From owner-ietf-calendar@mail.imc.org Tue Oct 16 01:27:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22769 for ; Tue, 16 Oct 2001 01:26:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9G58O023692 for ietf-calendar-bks; Mon, 15 Oct 2001 22:08:24 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [129.42.241.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9G58MD23682 for ; Mon, 15 Oct 2001 22:08:22 -0700 (PDT) Received: from internet2.lotus.com (internet2 [172.16.131.236]) by lotus2.lotus.com (8.11.4/8.11.4) with ESMTP id f9G59We01896 for ; Tue, 16 Oct 2001 01:09:32 -0400 (EDT) Received: from cammail05.lotus.com (cammail05.lotus.com [9.95.4.170]) by internet2.lotus.com (8.11.4/8.11.2) with ESMTP id f9G58Lw13966 for ; Tue, 16 Oct 2001 01:08:21 -0400 (EDT) Subject: Heidi Wulkow/CHI/Lotus is out of the office. From: Heidi_Wulkow@lotus.com To: "ietf-calendar@imc.org" Message-ID: Date: Tue, 16 Oct 2001 01:01:10 -0400 X-MIMETrack: Serialize by Router on CAMMAIL05/CAM/M/Lotus(Build V509_10092001 |October 9, 2001) at 10/16/2001 01:01:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I will be out of the office starting 10/12/2001 and will not return until 10/22/2001. I will be out of the office on personal leave beginning today and will not have access to email or voicemail. I will return on Monday October 22nd. If you have an urgent situation please contact Rick Sizemore or Kris Honkola. Thank you. From owner-ietf-calendar@mail.imc.org Tue Oct 16 01:27:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22805 for ; Tue, 16 Oct 2001 01:27:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9G58XC23698 for ietf-calendar-bks; Mon, 15 Oct 2001 22:08:33 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [129.42.241.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9G58WD23693 for ; Mon, 15 Oct 2001 22:08:32 -0700 (PDT) Received: from internet2.lotus.com (internet2 [172.16.131.236]) by lotus2.lotus.com (8.11.4/8.11.4) with ESMTP id f9G59We01890 for ; Tue, 16 Oct 2001 01:09:32 -0400 (EDT) Received: from cammail05.lotus.com (cammail05.lotus.com [9.95.4.170]) by internet2.lotus.com (8.11.4/8.11.2) with ESMTP id f9G58Kw13963 for ; Tue, 16 Oct 2001 01:08:20 -0400 (EDT) Subject: Heidi Wulkow/CHI/Lotus is out of the office. From: Heidi_Wulkow@lotus.com To: ietf-calendar@imc.org Message-ID: Date: Tue, 16 Oct 2001 01:01:10 -0400 X-MIMETrack: Serialize by Router on CAMMAIL05/CAM/M/Lotus(Build V509_10092001 |October 9, 2001) at 10/16/2001 01:01:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I will be out of the office starting 10/12/2001 and will not return until 10/22/2001. I will be out of the office on personal leave beginning today and will not have access to email or voicemail. I will return on Monday October 22nd. If you have an urgent situation please contact Rick Sizemore or Kris Honkola. Thank you. From owner-ietf-calendar@mail.imc.org Tue Oct 16 12:13:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08279 for ; Tue, 16 Oct 2001 12:13:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9GFX6G27109 for ietf-calendar-bks; Tue, 16 Oct 2001 08:33:06 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GFX4D27105 for ; Tue, 16 Oct 2001 08:33:05 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA29037; Tue, 16 Oct 2001 11:33:00 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9GFWuT18638; Tue, 16 Oct 2001 11:32:56 -0400 (EDT) Message-ID: <3BCC5326.C1EC40EC@steltor.com> Date: Tue, 16 Oct 2001 11:32:54 -0400 From: George Babics X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: CAP and BEEP [Was: Re: BEEP Protocol and Internationalization: Interim meeting?] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, We are going to rewrite the transport layer of CAP to use BEEP (RFC 3080). It will help us resolve many issues and help us avoid reinventing the wheel. If anyone has any concerns please let us know now. George Bob Mahoney wrote: > > Folks- > > We've been asked to look at two issues by our Area Directors. > > 1) Internationalization is becoming increasingly high-profile, and it > is *not* an optional concern for us. In depth conversations between > Patrik and the Kerberos WG indicates there are issues we have yet to > deal with. > > The guess is that we have some work to do for this. > > 2) Ned attended our meeting in London, and after a detailed reading > of the CAP draft, suggested (with reluctance given the late date) > that we look closer at the BEEP work. He suggested we consider using > BEEP, or perhaps just move some of our overhead down into the > "payload", to simplify a future conversion to BEEP. > > Casual conversations in London indicate that we may be able to deal > with this quickly, given the right folks focusing on it for a short > time. > > We asked Patrik and Ned if they would object to an interim meeting to > focus on these two points, and they were fine with that. > > So, would people be open to an interim meeting on the east coast > someplace, in an early October November time frame? I can probably > get space at MIT without difficulty, if that is acceptable. > > Please let us know. > > -Bob > > Some drafts to read: > > BEEP > > Mapping the BEEP Core onto TCP (RFC 3081) http://www.ietf.org/rfc/rfc3081.txt > The Blocks Extensible Exchange Protocol Core (RFC 3080) > http://www.ietf.org/rfc/rfc3080.txt > > IDN > > Internationalizing Host Names In Applications (IDNA) > http://search.ietf.org/internet-drafts/draft-ietf-idn-idna-03.txt From owner-ietf-calendar@mail.imc.org Wed Oct 17 17:54:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08120 for ; Wed, 17 Oct 2001 17:54:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9HKxvJ20921 for ietf-calendar-bks; Wed, 17 Oct 2001 13:59:57 -0700 (PDT) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9HKxtD20916 for ; Wed, 17 Oct 2001 13:59:55 -0700 (PDT) To: ietf-calendar@imc.org Subject: CalConnectIII update MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 17 Oct 2001 16:59:29 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 10/17/2001 04:59:29 PM, Serialize complete at 10/17/2001 04:59:29 PM Content-Type: multipart/alternative; boundary="=_alternative 00737A1085256AE8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00737A1085256AE8_= Content-Type: text/plain; charset="us-ascii" Because of events of September 11th and the business environment since then, we are not going to hold our CalConnect III in Montreal. Instead, we are in the process of working up an electronic or "virtual" interop test to happen on the same days - 11/29-30. The fee will be nominal (just to cover teleconferencing) and will be posted to the list as soon as that is available. Those parties who have not already contacted me and are interested in participating on the interop testing should let me know before the end of the month so we can include this in our plans. Three of the vendors have already stated that the virtual concept would be fine with them. Stay tuned for more details. On another note, Eric Busboom who was acting as our iCalendar editor has moved into another direction. As such we have an "opening" in the ranks. Anyone interested in working as an Editor on iCalendar should contact either myself or Bob Mahoney (bobmah@mit.edu) or noted so on the list. Thanks for your support! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 00737A1085256AE8_= Content-Type: text/html; charset="us-ascii"
Because of events of September 11th and the business environment since then, we are not going to hold our CalConnect III in Montreal.  Instead, we are in the process of working up an electronic or "virtual" interop test to happen on the same days - 11/29-30.  The fee will be nominal (just to cover teleconferencing) and will be posted to the list as soon as that is available.  Those parties who have not already contacted me and are interested in participating on the interop testing should let me know before the end of the month so we can include this in our plans.  Three of the vendors have already stated that the virtual concept would be fine with them.  Stay tuned for more details.

On another note, Eric Busboom who was acting as our iCalendar editor has moved into another direction.  As such we have an "opening" in the ranks.  Anyone interested in working as an Editor on iCalendar should contact either myself or Bob Mahoney (bobmah@mit.edu) or noted so on the list.  Thanks for your support!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 00737A1085256AE8_=-- From owner-ietf-calendar@mail.imc.org Thu Oct 18 12:41:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14761 for ; Thu, 18 Oct 2001 12:41:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IGI2W21546 for ietf-calendar-bks; Thu, 18 Oct 2001 09:18:02 -0700 (PDT) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IGI0D21542 for ; Thu, 18 Oct 2001 09:18:00 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA30088; Thu, 18 Oct 2001 11:17:01 -0500 From: "Shannon J. Clark" To: , Subject: RE: CalConnectIII update Date: Thu, 18 Oct 2001 11:17:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C157C6.88AC0300" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C157C6.88AC0300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In looking at the website (at software studio) there appears to be a problem with the Message id links on the issues page (they are all linking to the same message - which is an ad not the issues being discussed. Or they are links to a page that "can not be found" Any way I can help fix this? thanks, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com Sent: Wednesday, October 17, 2001 3:59 PM To: ietf-calendar@imc.org Subject: CalConnectIII update Because of events of September 11th and the business environment since then, we are not going to hold our CalConnect III in Montreal. Instead, we are in the process of working up an electronic or "virtual" interop test to happen on the same days - 11/29-30. The fee will be nominal (just to cover teleconferencing) and will be posted to the list as soon as that is available. Those parties who have not already contacted me and are interested in participating on the interop testing should let me know before the end of the month so we can include this in our plans. Three of the vendors have already stated that the virtual concept would be fine with them. Stay tuned for more details. On another note, Eric Busboom who was acting as our iCalendar editor has moved into another direction. As such we have an "opening" in the ranks. Anyone interested in working as an Editor on iCalendar should contact either myself or Bob Mahoney (bobmah@mit.edu) or noted so on the list. Thanks for your support! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 ------=_NextPart_000_001F_01C157C6.88AC0300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In = looking at the=20 website (at software studio) there appears to be a problem with the = Message id=20 links on the issues page (they are all linking to the same message - = which is an=20 ad not the issues being discussed.
 
Or = they are links to=20 a page that "can not be found"
 
Any = way I can help=20 fix this?
 
thanks,
 
Shannon
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of=20 pregen@egenconsulting.com
Sent: Wednesday, October 17, = 2001 3:59=20 PM
To: ietf-calendar@imc.org
Subject: = CalConnectIII=20 update


Because of events=20 of September 11th and the business environment since then, we are not = going to=20 hold our CalConnect III in Montreal.  Instead, we are in the = process of=20 working up an electronic or "virtual" interop test to happen on the = same days=20 - 11/29-30.  The fee will be nominal (just to cover = teleconferencing) and=20 will be posted to the list as soon as that is available.  Those = parties=20 who have not already contacted me and are interested in participating = on the=20 interop testing should let me know before the end of the month so we = can=20 include this in our plans.  Three of the vendors have already = stated that=20 the virtual concept would be fine with them.  Stay tuned for more = details.

On another = note, Eric=20 Busboom who was acting as our iCalendar editor has moved into another=20 direction.  As such we have an "opening" in the ranks. =  Anyone=20 interested in working as an Editor on iCalendar should contact either = myself=20 or Bob Mahoney (bobmah@mit.edu) or noted so on the list.  Thanks = for your=20 support!
___________________
Patricia Egen=20 = Consulting
www.egenconsulting.com
423-875-2652
<= /BODY> ------=_NextPart_000_001F_01C157C6.88AC0300-- From owner-ietf-calendar@mail.imc.org Thu Oct 18 13:32:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16150 for ; Thu, 18 Oct 2001 13:32:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IH8kC22499 for ietf-calendar-bks; Thu, 18 Oct 2001 10:08:46 -0700 (PDT) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IH8hD22494 for ; Thu, 18 Oct 2001 10:08:43 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA30170 for ; Thu, 18 Oct 2001 12:07:44 -0500 From: "Shannon J. Clark" To: Subject: Email Archive at IMC website Date: Thu, 18 Oct 2001 12:08:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C157CD.9EC35C40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C157CD.9EC35C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It appears that the email archive has been corrupted - large sections of the past messages have somehow been overwritten by a handful of email spams - who manages the IMC archive site? Perhaps it can be restored or rebuilt from other copies of the mailing list? http://www.imc.org/ietf-calendar/mail-archive/mail2.html - appears good, but look at mail5.html through mail12.html which are constant repetitions of a handful of spams. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Shannon J. Clark Sent: Thursday, October 18, 2001 11:18 AM To: pregen@egenconsulting.com; ietf-calendar@imc.org Subject: RE: CalConnectIII update In looking at the website (at software studio) there appears to be a problem with the Message id links on the issues page (they are all linking to the same message - which is an ad not the issues being discussed. Or they are links to a page that "can not be found" Any way I can help fix this? thanks, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com Sent: Wednesday, October 17, 2001 3:59 PM To: ietf-calendar@imc.org Subject: CalConnectIII update Because of events of September 11th and the business environment since then, we are not going to hold our CalConnect III in Montreal. Instead, we are in the process of working up an electronic or "virtual" interop test to happen on the same days - 11/29-30. The fee will be nominal (just to cover teleconferencing) and will be posted to the list as soon as that is available. Those parties who have not already contacted me and are interested in participating on the interop testing should let me know before the end of the month so we can include this in our plans. Three of the vendors have already stated that the virtual concept would be fine with them. Stay tuned for more details. On another note, Eric Busboom who was acting as our iCalendar editor has moved into another direction. As such we have an "opening" in the ranks. Anyone interested in working as an Editor on iCalendar should contact either myself or Bob Mahoney (bobmah@mit.edu) or noted so on the list. Thanks for your support! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 ------=_NextPart_000_0025_01C157CD.9EC35C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It = appears that the=20 email archive has been corrupted - large sections of the past messages = have=20 somehow been overwritten by a handful of email spams - who manages the = IMC=20 archive site? Perhaps it can be restored or rebuilt from other copies of = the=20 mailing list?
 
http://= www.imc.org/ietf-calendar/mail-archive/mail2.html -=20 appears good, but look at mail5.html through mail12.html which are = constant=20 repetitions of a handful of spams.
 
Shannon
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Shannon = J.=20 Clark
Sent: Thursday, October 18, 2001 11:18 = AM
To:=20 pregen@egenconsulting.com; ietf-calendar@imc.org
Subject: = RE:=20 CalConnectIII update

In = looking at the=20 website (at software studio) there appears to be a problem with the = Message id=20 links on the issues page (they are all linking to the same message - = which is=20 an ad not the issues being discussed.
 
Or = they are links=20 to a page that "can not be found"
 
Any = way I can help=20 fix this?
 
thanks,
 
Shannon
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of=20 pregen@egenconsulting.com
Sent: Wednesday, October 17, = 2001=20 3:59 PM
To: ietf-calendar@imc.org
Subject: = CalConnectIII=20 update


Because of=20 events of September 11th and the business environment since then, we = are not=20 going to hold our CalConnect III in Montreal.  Instead, we are = in the=20 process of working up an electronic or "virtual" interop test to = happen on=20 the same days - 11/29-30.  The fee will be nominal (just to = cover=20 teleconferencing) and will be posted to the list as soon as that is=20 available.  Those parties who have not already contacted me and = are=20 interested in participating on the interop testing should let me = know before=20 the end of the month so we can include this in our plans. =  Three of the=20 vendors have already stated that the virtual concept would be fine = with=20 them.  Stay tuned for more details.

On another note, Eric Busboom who was = acting as our=20 iCalendar editor has moved into another direction.  As such we = have an=20 "opening" in the ranks.  Anyone interested in working as an = Editor on=20 iCalendar should contact either myself or Bob Mahoney = (bobmah@mit.edu) or=20 noted so on the list.  Thanks for your=20 support!
___________________
Patricia Egen=20 = Consulting
www.egenconsulting.com
423-875-2652
<= /BLOCKQUOTE> ------=_NextPart_000_0025_01C157CD.9EC35C40-- From owner-ietf-calendar@mail.imc.org Thu Oct 18 13:56:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16801 for ; Thu, 18 Oct 2001 13:56:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IHb0M23217 for ietf-calendar-bks; Thu, 18 Oct 2001 10:37:00 -0700 (PDT) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IHaxD23211 for ; Thu, 18 Oct 2001 10:36:59 -0700 (PDT) To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: Re: Email Archive at IMC website MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10142001 Beta 4 October 14, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 18 Oct 2001 13:42:03 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 10/18/2001 01:42:11 PM, Serialize complete at 10/18/2001 01:42:11 PM Content-Type: multipart/alternative; boundary="=_alternative 006056AB85256AE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006056AB85256AE9_= Content-Type: text/plain; charset="US-ASCII" > It appears that the email archive has been corrupted - large > sections of the past messages have somehow been overwritten by a > handful of email spams - who manages the IMC archive site? Perhaps That would be Paul Hoffman (mailto:phoffman@imc.org). Ill make sure he sees your note. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006056AB85256AE9_= Content-Type: text/html; charset="US-ASCII"
> It appears that the email archive has been corrupted - large
> sections of the past messages have somehow been overwritten by a
> handful of email spams - who manages the IMC archive site? Perhaps

That would be Paul Hoffman (mailto:phoffman@imc.org).  Ill make sure he sees your note.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006056AB85256AE9_=-- From owner-ietf-calendar@mail.imc.org Thu Oct 18 14:17:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17357 for ; Thu, 18 Oct 2001 14:17:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9II0oE23769 for ietf-calendar-bks; Thu, 18 Oct 2001 11:00:50 -0700 (PDT) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9II0mD23765 for ; Thu, 18 Oct 2001 11:00:48 -0700 (PDT) To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: RE: CalConnectIII update MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 18 Oct 2001 14:00:14 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 10/18/2001 02:00:19 PM, Serialize complete at 10/18/2001 02:00:19 PM Content-Type: multipart/alternative; boundary="=_alternative 0063020085256AE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063020085256AE9_= Content-Type: text/plain; charset="us-ascii" Shannon, Eric manages that particular page. He's the one we need to work with. Since we now have moved my calsch web pages to the MIT server, we can probably put them there. Right Bob? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Shannon J. Clark" 10/18/01 12:17 PM To: , cc: Subject: RE: CalConnectIII update In looking at the website (at software studio) there appears to be a problem with the Message id links on the issues page (they are all linking to the same message - which is an ad not the issues being discussed. Or they are links to a page that "can not be found" Any way I can help fix this? thanks, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com Sent: Wednesday, October 17, 2001 3:59 PM To: ietf-calendar@imc.org Subject: CalConnectIII update Because of events of September 11th and the business environment since then, we are not going to hold our CalConnect III in Montreal. Instead, we are in the process of working up an electronic or "virtual" interop test to happen on the same days - 11/29-30. The fee will be nominal (just to cover teleconferencing) and will be posted to the list as soon as that is available. Those parties who have not already contacted me and are interested in participating on the interop testing should let me know before the end of the month so we can include this in our plans. Three of the vendors have already stated that the virtual concept would be fine with them. Stay tuned for more details. On another note, Eric Busboom who was acting as our iCalendar editor has moved into another direction. As such we have an "opening" in the ranks. Anyone interested in working as an Editor on iCalendar should contact either myself or Bob Mahoney (bobmah@mit.edu) or noted so on the list. Thanks for your support! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0063020085256AE9_= Content-Type: text/html; charset="us-ascii"
Shannon, Eric manages that particular page.  He's the one we need to work with.  Since we now have moved my calsch web pages to the MIT server, we can probably put them there. Right Bob?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


"Shannon J. Clark" <shannon@jigzaw.com>

10/18/01 12:17 PM

       
        To:        <pregen@egenconsulting.com>, <ietf-calendar@imc.org>
        cc:        
        Subject:        RE: CalConnectIII update



In looking at the website (at software studio) there appears to be a problem with the Message id links on the issues page (they are all linking to the same message - which is an ad not the issues being discussed.
 
Or they are links to a page that "can not be found"
 
Any way I can help fix this?
 
thanks,
 
Shannon
-----Original Message-----
From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com
Sent: Wednesday, October 17, 2001 3:59 PM
To: ietf-calendar@imc.org
Subject: CalConnectIII update

Because of events of September 11th and the business environment since then, we are not going to hold our CalConnect III in Montreal.  Instead, we are in the process of working up an electronic or "virtual" interop test to happen on the same days - 11/29-30.  The fee will be nominal (just to cover teleconferencing) and will be posted to the list as soon as that is available.  Those parties who have not already contacted me and are interested in participating on the interop testing should let me know before the end of the month so we can include this in our plans.  Three of the vendors have already stated that the virtual concept would be fine with them.  Stay tuned for more details.

On another note, Eric Busboom who was acting as our iCalendar editor has moved into another direction.  As such we have an "opening" in the ranks.  Anyone interested in working as an Editor on iCalendar should contact either myself or Bob Mahoney (bobmah@mit.edu) or noted so on the list.  Thanks for your support!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

--=_alternative 0063020085256AE9_=-- From owner-ietf-calendar@mail.imc.org Thu Oct 18 14:19:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17389 for ; Thu, 18 Oct 2001 14:19:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9II59623908 for ietf-calendar-bks; Thu, 18 Oct 2001 11:05:09 -0700 (PDT) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9II57D23898 for ; Thu, 18 Oct 2001 11:05:07 -0700 (PDT) To: "Shannon J. Clark" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Email Archive at IMC website MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 18 Oct 2001 14:04:32 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 10/18/2001 02:04:38 PM, Serialize complete at 10/18/2001 02:04:38 PM Content-Type: multipart/alternative; boundary="=_alternative 006366C085256AE9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006366C085256AE9_= Content-Type: text/plain; charset="us-ascii" Shannon, as Bruce said, Paul Hoffman manages the IMC website. I forwarded your note to him asking is he might know what was going on. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Shannon J. Clark" Sent by: owner-ietf-calendar@mail.imc.org 10/18/01 01:08 PM To: cc: Subject: Email Archive at IMC website It appears that the email archive has been corrupted - large sections of the past messages have somehow been overwritten by a handful of email spams - who manages the IMC archive site? Perhaps it can be restored or rebuilt from other copies of the mailing list? http://www.imc.org/ietf-calendar/mail-archive/mail2.html - appears good, but look at mail5.html through mail12.html which are constant repetitions of a handful of spams. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Shannon J. Clark Sent: Thursday, October 18, 2001 11:18 AM To: pregen@egenconsulting.com; ietf-calendar@imc.org Subject: RE: CalConnectIII update In looking at the website (at software studio) there appears to be a problem with the Message id links on the issues page (they are all linking to the same message - which is an ad not the issues being discussed. Or they are links to a page that "can not be found" Any way I can help fix this? thanks, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com Sent: Wednesday, October 17, 2001 3:59 PM To: ietf-calendar@imc.org Subject: CalConnectIII update Because of events of September 11th and the business environment since then, we are not going to hold our CalConnect III in Montreal. Instead, we are in the process of working up an electronic or "virtual" interop test to happen on the same days - 11/29-30. The fee will be nominal (just to cover teleconferencing) and will be posted to the list as soon as that is available. Those parties who have not already contacted me and are interested in participating on the interop testing should let me know before the end of the month so we can include this in our plans. Three of the vendors have already stated that the virtual concept would be fine with them. Stay tuned for more details. On another note, Eric Busboom who was acting as our iCalendar editor has moved into another direction. As such we have an "opening" in the ranks. Anyone interested in working as an Editor on iCalendar should contact either myself or Bob Mahoney (bobmah@mit.edu) or noted so on the list. Thanks for your support! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 006366C085256AE9_= Content-Type: text/html; charset="us-ascii"
Shannon, as Bruce said, Paul Hoffman manages the IMC website.  I forwarded your note to him asking is he might know what was going on.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


"Shannon J. Clark" <shannon@jigzaw.com>
Sent by: owner-ietf-calendar@mail.imc.org

10/18/01 01:08 PM

       
        To:        <ietf-calendar@imc.org>
        cc:        
        Subject:        Email Archive at IMC website



It appears that the email archive has been corrupted - large sections of the past messages have somehow been overwritten by a handful of email spams - who manages the IMC archive site? Perhaps it can be restored or rebuilt from other copies of the mailing list?
 
http://www.imc.org/ietf-calendar/mail-archive/mail2.html - appears good, but look at mail5.html through mail12.html which are constant repetitions of a handful of spams.
 
Shannon
-----Original Message-----
From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Shannon J. Clark
Sent: Thursday, October 18, 2001 11:18 AM
To: pregen@egenconsulting.com; ietf-calendar@imc.org
Subject: RE: CalConnectIII update
In looking at the website (at software studio) there appears to be a problem with the Message id links on the issues page (they are all linking to the same message - which is an ad not the issues being discussed.
 
Or they are links to a page that "can not be found"
 
Any way I can help fix this?
 
thanks,
 
Shannon
-----Original Message-----
From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com
Sent: Wednesday, October 17, 2001 3:59 PM
To: ietf-calendar@imc.org
Subject: CalConnectIII update

Because of events of September 11th and the business environment since then, we are not going to hold our CalConnect III in Montreal.  Instead, we are in the process of working up an electronic or "virtual" interop test to happen on the same days - 11/29-30.  The fee will be nominal (just to cover teleconferencing) and will be posted to the list as soon as that is available.  Those parties who have not already contacted me and are interested in participating on the interop testing should let me know before the end of the month so we can include this in our plans.  Three of the vendors have already stated that the virtual concept would be fine with them.  Stay tuned for more details.

On another note, Eric Busboom who was acting as our iCalendar editor has moved into another direction.  As such we have an "opening" in the ranks.  Anyone interested in working as an Editor on iCalendar should contact either myself or Bob Mahoney (bobmah@mit.edu) or noted so on the list.  Thanks for your support!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

--=_alternative 006366C085256AE9_=-- From owner-ietf-calendar@mail.imc.org Thu Oct 18 14:21:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17512 for ; Thu, 18 Oct 2001 14:21:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IHxo223731 for ietf-calendar-bks; Thu, 18 Oct 2001 10:59:50 -0700 (PDT) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IHxmD23727 for ; Thu, 18 Oct 2001 10:59:48 -0700 (PDT) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id NAA20769; Thu Oct 18 13:57:01 2001 Subject: Re: Email Archive at IMC website MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 18 Oct 2001 14:00:48 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 10/18/2001 02:00:49 PM, Serialize complete at 10/18/2001 02:00:49 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >It appears that the email archive has been corrupted - large sections of the past messages have somehow >been overwritten by a handful of email spams - who manages the IMC archive site? Perhaps it can be >restored or rebuilt from other copies of the mailing list? > >http://www.imc.org/ietf-calendar/mail-archive/mail2.html - appears good, but look at mail5.html through >mail12.html which are constant repetitions of a handful of spams. No, there's real stuff in there, hidden among the spam. Admittedly, I don't remember getting this many copies of the spam from the list in February 2000, but I suppose it could've been blocked at the list somehow, and still gotten into the archive. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Fri Oct 19 13:42:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25663 for ; Fri, 19 Oct 2001 13:42:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JHLUT28626 for ietf-calendar-bks; Fri, 19 Oct 2001 10:21:30 -0700 (PDT) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JHLSD28622 for ; Fri, 19 Oct 2001 10:21:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Fri, 19 Oct 2001 10:21:10 -0700 To: ietf-calendar@imc.org From: Paul Hoffman / IMC Subject: Re: Email Archive at IMC website Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MHonArc, the mail archiving program we use, sometimes trips over a message and makes a mess. That is what happened in this instance. I believe I have fixed it now; let me know if it happens again. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-calendar@mail.imc.org Mon Oct 22 12:26:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22007 for ; Mon, 22 Oct 2001 12:26:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9MFsSH20244 for ietf-calendar-bks; Mon, 22 Oct 2001 08:54:28 -0700 (PDT) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MFsQ820234 for ; Mon, 22 Oct 2001 08:54:26 -0700 (PDT) Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.140.169.29]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 3C606EC; Mon, 22 Oct 2001 17:53:53 +0200 (METDST) Received: from eiach.bbn.hp.com (eiach.bbn.hp.com [15.140.168.10]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id RAA27861; Mon, 22 Oct 2001 17:54:13 +0200 (METDST) Received: from 15.140.168.10 by eiach.bbn.hp.com (InterScan E-Mail VirusWall NT); Mon, 22 Oct 2001 17:54:13 +0200 (W. Europe Daylight Time) Received: by eiach.bbn.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Oct 2001 17:54:12 +0200 Message-ID: From: "NITSCH,FRANK (HP-Germany,ex1)" To: "'Eric R. Plamondon'" , ietf-calendar@imc.org Subject: RE: XML iCal draft changes Date: Mon, 22 Oct 2001 17:54:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I'm happy that this community re-started its efforts in XML. I personally believe that XML is really important enough to deal with it in iCalendar. Hopefully there will be some good progress in future - this would definitely help iCalendar to find more acceptance "outside". About "Schemas": as far as I know there's little support in terms of tools etc. but under Windows. A standard DTD should therefore be included in the spec; not only a Schema. Just my 2... Best Regards Frank -- ==================================================================== Frank Nitsch mailto:frank_nitsch@hp.com -------------------------------------------------------------------- Hewlett-Packard GmbH | http://www.hewlett-packard.de Mailstop ASM-NGP, Building B32/3M17 | HP-Telnet 777-2135 Herrenberger Strasse 110-140 | Phone (+49) 07031/14-2135 D-71034 Boeblingen | Fax (+49) 07031/14-8253 ==================================================================== Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus, Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081 ==================================================================== > -----Original Message----- > From: Eric R. Plamondon [mailto:ericp@steltor.com] > Sent: Friday, 12 October, 2001 13:39 > To: ietf-calendar@imc.org > Subject: XML iCal draft changes > > > > Good Morning, > > The XML iCal draft has recently been resubmitted > through the Calendaring and Scheduling Working Group. > > http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt > > This is only an initial draft to restart (re-ignite?) > the discussion on a possible representation of iCal > in XML. Since the older draft expired, the goal, > with the OK from Patricia Egen and Bob Mahoney, was to > bring the draft back into the discussion, since > many people have be asking about. The original authors > will be contacted to determine whether they want to > continue work on the draft. > > Having gone through the archives, there were a number > of issues with the previous drafts. This version does > not attempt to correct them, but rather reopen the > discussion on them. > > Goal > ---- > The goal of the XML DTD (and schema) is to represent > ical in XML. The names, formats, and structures should > be a direct mapping from the iCalendar RPC. It is not > the goal to change or improve on the iCalendar RPC. > > There were a few changes made to this reposting, > from the previous draft-many-ical-xmldoc-01 document, > outlined below. > > Summary of Changes > ------------------ > - Renamed the file from > draft-many-ical-xmldoc-01 > to > draft-ietf-calsch-many-xcal-00 > - Renamed the document from > "iCalendar DTD Document" > to > "iCalendar DTD Document (xCal)" > - removed references to "ICALXML" and replaced > with "xCal" > - changed the FPI for the DTD from > -//IETF//DTD ICALXML/iCalendar XML//EN > to > -//IETF//DTD XCAL/iCalendar XML//EN > - changed the FPI for standard value types from > -//IETF/NOTATION ICALXML/Value Type/xxx/EN > to > -//IETF/NOTATION XCAL/Value Type/xxx/EN > NOTE: these changes where made to the DTD as well. > - changed all references from > draft-many-ical-xmldoc-01 > to > draft-many-xcal-00 > - changed the iCal namespace to xCal > - changed the proposed MIME type from > text/x-icalxml > to > text/x-xcal > - In some of the examples, the > xml formatting was removed (the XML version > of the draft, using the DTD from rfc2629, > failed to parse properly > > Property Parameters > - the following property parameters where change to > reflect their iCal counterpart > - delfrom to delegated-from > - delto to delegated-to > - lang to language > - trigtype to related > - sentby to sent-by > > Component Properties > - the following component properties where change to > reflect their iCal counterpart > - desc to description > - end to dtend > - start to dtstart > - fbdata to freebusy > - recurid to recurrence-id > - related to related-to > - last-mod to last-modified > - seq to sequence > - rstatus to request-status > > Structure Properties > - the following structure properties where change to > reflect their iCal counterpart > - ical to vcalendar > - event to vevent > - todo to vtodo > - journal to vjournal > - freebusy to vfreebusy > - timezone to vtimezone > - alarm to valarm > > Issues to be discussed > ====================== > - should all the names be returned to upper case > (or named case, as in XML schema). > - there are a few places where attributes are used > instead of child elements (e.g. in the vCalendar > element the version, prodid, calscale, and method) > - include an XML schema in this specification > - resolve other errors in the draft document > - correct the differences with "related" and "related-to" > within the DTD > - does the name "xCal" conflict too much with the > X-Windows calendar program by the same name > - If the original authors wish to continue work, their > business information must be updated. > - Provide a wbxml binding for xcal. > > Thanks, > Eric > > ------------------------------- > Eric R. Plamondon > Steltor - Chief Web Architect > 2000 Peel Street, 4th Floor > Montreal, Quebec > mailto:ericp@steltor.com > http://www.steltor.com > From owner-ietf-calendar@mail.imc.org Mon Oct 22 14:22:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26076 for ; Mon, 22 Oct 2001 14:22:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9MI11o28758 for ietf-calendar-bks; Mon, 22 Oct 2001 11:01:01 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MI10828742 for ; Mon, 22 Oct 2001 11:01:00 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9MI15Q17160 for ; Mon, 22 Oct 2001 13:01:05 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Oct 2001 13:01:01 -0500 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 22 Oct 2001 13:01:00 -0500 content-class: urn:content-classes:message Subject: RE: MIME type in draft-ietf-calsch-many-xcal-00.txt Date: Mon, 22 Oct 2001 13:01:00 -0500 Message-ID: <15A85922ED48294F80973D83F95074B64E0444@daebe006.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: MIME type in draft-ietf-calsch-many-xcal-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcFVbSn1t/DHRMFfEdWpXQBQi2kYTQFtngiA From: "Dawson Frank (NMP/Irving)" To: "'ext Eric R. Plamondon'" , "'Dan Kohn'" , Cc: , , "'MURATA Makoto'" , "'Simon St.Laurent'" X-OriginalArrivalTime: 22 Oct 2001 18:01:00.0814 (UTC) FILETIME=[821F0AE0:01C15B23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9MI10828753 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sounds good. > -----Original Message----- > From: ext Eric R. Plamondon [mailto:ericp@steltor.com] > Sent: Monday, October 15, 2001 05:59 > To: 'Dan Kohn'; ietf-calendar@imc.org > Cc: Frank_Dawson@lotus.com; skreddy@us.oracle.com; 'MURATA Makoto'; > 'Simon St.Laurent'; 'Eric R. Plamondon' > Subject: RE: MIME type in draft-ietf-calsch-many-xcal-00.txt > > > Good Morning, > > after reading RFC 3023, I agree that the MIME type should be changed. > So, I'll go along with "application/calendar+xml" and > "application/calendar+wbxml" (as per Frank Dawson's wanting to > include a wbxml version for the WAP, wireless, and SyncML > communities). > > Any objections? > > Eric From owner-ietf-calendar@mail.imc.org Mon Oct 22 23:15:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05656 for ; Mon, 22 Oct 2001 23:15:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9N2rRC10946 for ietf-calendar-bks; Mon, 22 Oct 2001 19:53:27 -0700 (PDT) Received: from virginia.yamato.ibm.co.jp (virginia.yamato.ibm.co.jp [203.141.89.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9N2rM810942 for ; Mon, 22 Oct 2001 19:53:22 -0700 (PDT) Received: from ns.trl.ibm.com (ns.trl.ibm.com [9.116.48.18]) by virginia.yamato.ibm.co.jp (8.11.6/3.7W/GW3.3) with ESMTP id f9N2r4127340; Tue, 23 Oct 2001 11:53:04 +0900 Received: from localhost by ns.trl.ibm.com (AIX4.3/8.9.3/TRL4.5SRV) id LAA22508; Tue, 23 Oct 2001 11:53:03 +0900 Date: Tue, 23 Oct 2001 11:56:21 +0900 (JST) Message-Id: <20011023.115621.01368074.mmurata@trl.ibm.com> To: Frank.Dawson@nokia.com Cc: ericp@steltor.com, dan@dankohn.com, ietf-calendar@imc.org, Frank_Dawson@lotus.com, skreddy@us.oracle.com, mmurata@trl.ibm.co.jp, simonstl@simonstl.com Subject: Re: MIME type in draft-ietf-calsch-many-xcal-00.txt From: Murata Makoto In-Reply-To: <15A85922ED48294F80973D83F95074B64E0444@daebe006.NOE.Nokia.com> References: <15A85922ED48294F80973D83F95074B64E0444@daebe006.NOE.Nokia.com> X-Mailer: Mew version 2.0.57 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id f9N2rN810943 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm sending this message again, since my previous message was blocked by an anti-smap filter. Paul, thanks for adding me to the "OK to post" list. --------------------------------------------------------------------- I am wondering why you need application/calendar+wbxml. Unless ebXML does not create its own variation of XML, I do not see any requirements for application/calendar+wbxml. Cheers, Makoto From owner-ietf-calendar@mail.imc.org Thu Oct 25 15:58:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28737 for ; Thu, 25 Oct 2001 15:58:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PJZfp28476 for ietf-calendar-bks; Thu, 25 Oct 2001 12:35:41 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PJZd828471 for ; Thu, 25 Oct 2001 12:35:39 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PJZjQ25150 for ; Thu, 25 Oct 2001 14:35:45 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Oct 2001 14:35:41 -0500 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 25 Oct 2001 14:35:40 -0500 content-class: urn:content-classes:message Subject: RE: What should the xCal tag names case be? Date: Thu, 25 Oct 2001 14:35:32 -0500 Message-ID: <15A85922ED48294F80973D83F95074B64E0500@daebe006.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: What should the xCal tag names case be? Thread-Index: AcFVlxqg5DvNBcGFEdWxLwAIx6TWeAH9HeaA From: "Dawson Frank (NMP/Irving)" To: "'ext Gary Frederick'" , X-OriginalArrivalTime: 25 Oct 2001 19:35:40.0834 (UTC) FILETIME=[3AEA9020:01C15D8C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9PJZe828472 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > The XML tag names will be case sensitive. > Yes. This is XML requirement. > If we pick all lower or all UPPER for all the tags, it may > make things a > bit easier when translating from iCalendar to xCal. > I don't follow this logic. For xCal to iCalendar the mapping is one way. For iCalendar to xCal the mapping is one way too, but you must use case insensitive string comparison. In any case, this is not a problem. > i think lower case looks better. ymmv > This is just one of three possible opinions? I see DTDs with all UPPER case, as older SGML DTD styles used. I also see all lower case, as you advocate. But I also see derivatives of hungarian notation. Looks is not really an argument but an opinion of style. However, perception when reading through XML source might make sense as an argument. I believe research has shown that mixed case is easier to read. From owner-ietf-calendar@mail.imc.org Thu Oct 25 16:21:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29270 for ; Thu, 25 Oct 2001 16:21:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PJtYS28776 for ietf-calendar-bks; Thu, 25 Oct 2001 12:55:34 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PJtX828772 for ; Thu, 25 Oct 2001 12:55:33 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PJtcQ27459 for ; Thu, 25 Oct 2001 14:55:38 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Oct 2001 14:55:34 -0500 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 25 Oct 2001 14:55:36 -0500 content-class: urn:content-classes:message Subject: RE: XML iCal draft changes Date: Thu, 25 Oct 2001 14:55:26 -0500 Message-ID: <15A85922ED48294F80973D83F95074B6176787@daebe006.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: XML iCal draft changes Thread-Index: AcFTF7dBRjGz3b8JEdWrxQAIx6S5QwKdR7BQ From: "Dawson Frank (NMP/Irving)" To: "'ext Eric R. Plamondon'" , X-OriginalArrivalTime: 25 Oct 2001 19:55:36.0020 (UTC) FILETIME=[034D7940:01C15D8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9PJtX828773 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > The XML iCal draft has recently been resubmitted > through the Calendaring and Scheduling Working Group. > Great. > Summary of Changes > ------------------ > - changed the FPI for standard value types from > -//IETF/NOTATION ICALXML/Value Type/xxx/EN > to > -//IETF/NOTATION XCAL/Value Type/xxx/EN > NOTE: these changes where made to the DTD as well. Suggest we remove requirement for NOTATION declarations. These don't seem to be used very much and the support for this little used XML feature just makes the DTD overly complex. Also suggest getting rid of the entity declarations which were used to allow redefintion of the DTD for the same reason; mainly simplicity. > - changed the proposed MIME type from > text/x-icalxml > to > text/x-xcal As may have been mentioned, this ought to be text/xcal+xml or even better application/xcal+xml. > Property Parameters > - the following property parameters where change to > reflect their iCal counterpart > - delfrom to delegated-from > - delto to delegated-to > - lang to language > - trigtype to related > - sentby to sent-by > > Component Properties > - the following component properties where change to > reflect their iCal counterpart > - desc to description > - end to dtend > - start to dtstart > - fbdata to freebusy > - recurid to recurrence-id > - related to related-to > - last-mod to last-modified > - seq to sequence > - rstatus to request-status > > Structure Properties > - the following structure properties where change to > reflect their iCal counterpart > - ical to vcalendar > - event to vevent > - todo to vtodo > - journal to vjournal > - freebusy to vfreebusy > - timezone to vtimezone > - alarm to valarm > Why? Shorter element type names are simplier to remember and use. It also makes the lines of xCal more likely to fit on a single line, rather than be broken across lines. I don't support the idea of making the names the same as in iCalendar just for "sameness" sake. > Issues to be discussed > ====================== > - should all the names be returned to upper case > (or named case, as in XML schema). No. Mixed case to ease in readability. > - there are a few places where attributes are used > instead of child elements (e.g. in the vCalendar > element the version, prodid, calscale, and method) Make the DTD simple. Avoid all attribute lists, except standard XML attributes. > - include an XML schema in this specification Why? The XML schema doesn't even use the same date/time format as in iCalendar. > - resolve other errors in the draft document > - does the name "xCal" conflict too much with the > X-Windows calendar program by the same name Is there a trademark issue? Otherwise, xCal or xCalendar is cool. > - If the original authors wish to continue work, their > business information must be updated. Yes. Attribute business affilliation with Nokia and to this email address. > - Provide a wbxml binding for xcal. This requires some thinking. You will want to map most commonly used elements into the first page, next most commonly used into the next page, etc. This will make is more terse a tokenized form. Thanks again for kicking this back off. -- Frank From owner-ietf-calendar@mail.imc.org Thu Oct 25 16:47:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29860 for ; Thu, 25 Oct 2001 16:47:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PKS8129765 for ietf-calendar-bks; Thu, 25 Oct 2001 13:28:08 -0700 (PDT) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PKS6829761 for ; Thu, 25 Oct 2001 13:28:06 -0700 (PDT) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id QAA12248; Thu Oct 25 16:23:57 2001 Subject: RE: What should the xCal tag names case be? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 25 Oct 2001 16:28:12 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 10/25/2001 04:28:24 PM, Serialize complete at 10/25/2001 04:28:24 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I believe > research has shown that mixed case is easier to read. That certainly accords with my own experience. People who SHOUT, or who type everything in lower case, are harder to read. Mixed case gives your eyes clues as they parse along. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Thu Oct 25 17:11:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00408 for ; Thu, 25 Oct 2001 17:11:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PKqZl00688 for ietf-calendar-bks; Thu, 25 Oct 2001 13:52:35 -0700 (PDT) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PKqX800684 for ; Thu, 25 Oct 2001 13:52:33 -0700 (PDT) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id QAA15738; Thu Oct 25 16:48:27 2001 Subject: RE: XML iCal draft changes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 25 Oct 2001 16:52:42 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 10/25/2001 04:52:54 PM, Serialize complete at 10/25/2001 04:52:54 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Structure Properties > > - the following structure properties where change to > > reflect their iCal counterpart > > - ical to vcalendar > > - event to vevent > > - todo to vtodo > > - journal to vjournal > > - freebusy to vfreebusy > > - timezone to vtimezone > > - alarm to valarm > > > > Why? Shorter element type names are simplier to remember and use. It > also makes the lines of xCal more likely to fit on a single line, rather > than be broken across lines. I don't support the idea of making the > names the same as in iCalendar just for "sameness" sake. In the short term, this could work; but, in the long term, it effectively means we have to maintain two separate namespaces. Worse, any translation code has to maintain a mapping table, which will get out of date whenever something is added to iCalendar. Consider this scenario: you have FooCal 3.5, which supports all the latest iCalendar features, but doesn't grok the XML encoding. So you have a helper app that transforms application/xcal+xml (*) into text/calendar. If the XML encoding is simply a uniform mapping, with identical names, and with uniform rules for how to represent parameters, then that helper app can be written once and forgotten, not updated every time something's added to iCalendar. (*) I'm not too thrilled with the notion of calling it xCal, by the way. This is just supposed to be a different encoding for iCalendar; anything else will lead to interop problems (as we discussed back in 1999)--and, once you give something its own name, it becomes harder not to think of it as a first-order entity. I would prefer for the MIME type to be "application/icalendar+xml", to emphasize that it really is iCalendar-in-XML, and the common name to be something like "iCalendar XML", maybe shortened to "iCXML" or some such. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Thu Oct 25 17:47:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00831 for ; Thu, 25 Oct 2001 17:47:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PLVcj01852 for ietf-calendar-bks; Thu, 25 Oct 2001 14:31:38 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PLVb801848 for ; Thu, 25 Oct 2001 14:31:37 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PLVhQ10365 for ; Thu, 25 Oct 2001 16:31:43 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Oct 2001 16:31:39 -0500 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 25 Oct 2001 16:31:41 -0500 content-class: urn:content-classes:message Subject: RE: XML iCal draft changes Date: Thu, 25 Oct 2001 16:31:31 -0500 Message-ID: <15A85922ED48294F80973D83F95074B64E050D@daebe006.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: XML iCal draft changes Thread-Index: AcFdmiTW+e98j8mMEdWBTgBQi2X+DwAAfLtw From: "Dawson Frank (NMP/Irving)" To: "'ext John Stracke'" , X-OriginalArrivalTime: 25 Oct 2001 21:31:41.0219 (UTC) FILETIME=[6FA10730:01C15D9C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9PLVb801849 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit John: Helper application is a simple table translation. I think a script could do this. Not a strong argument. However, having to carry unnecessary iCalendar naming conventions makes not sense. Neither does it to leverage some simple features of XML. I see no logical requirement to require xCal property names to be the same as in iCalendar. There is also no reason to do an isomeric mapping of property and parameter right from iCalendar into xCal. The requirement is that the mappings be semantically isomeric, as far as possible. -- Frank From owner-ietf-calendar@mail.imc.org Thu Oct 25 18:05:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01104 for ; Thu, 25 Oct 2001 18:05:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PLeqS02057 for ietf-calendar-bks; Thu, 25 Oct 2001 14:40:52 -0700 (PDT) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PLep802052 for ; Thu, 25 Oct 2001 14:40:51 -0700 (PDT) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA22447; Thu Oct 25 17:36:44 2001 Subject: RE: XML iCal draft changes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 25 Oct 2001 17:40:59 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 10/25/2001 05:41:11 PM, Serialize complete at 10/25/2001 05:41:11 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Frank Dawson wrote: > Helper application is a simple table translation. I think a script could > do this. Not a strong argument. The point is that that table then needs to be updated over time. We're better off if the script only needs to know rules, not data. > However, having to carry unnecessary iCalendar naming conventions makes > not sense. What harm does it do? The primary goal here is not to create the ideal XML syntax, which accords with everybody's ideas of what an XML syntax should be. That'd be nice, but it must be subordinate to the goal of minimizing the impedance mismatch between application/icalendar+xml and text/calendar. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Thu Oct 25 19:05:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01790 for ; Thu, 25 Oct 2001 19:05:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PMf9Q03401 for ietf-calendar-bks; Thu, 25 Oct 2001 15:41:09 -0700 (PDT) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PMf7803396 for ; Thu, 25 Oct 2001 15:41:07 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id RAA08586 for ; Thu, 25 Oct 2001 17:40:01 -0500 From: "Shannon J. Clark" To: Subject: How does each standard "fit" together Date: Thu, 25 Oct 2001 17:41:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, Bearing in mind the Guide to Internet Calendaring - I have a question for the list. How does all of the various standards that we are currently and are proposing to use all "fit" together? That is - with the adoption of BEEB for CAP - how does/does not this impact iTIP, iMIP, iRIP, iCAL, CAP, MIME or any other standards that are employed in the proposals of this working group? I suggest that people's responses to this question be collated and made available at www.calsch.org among other places. Shannon Shannon J. Clark JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Thu Oct 25 19:09:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01817 for ; Thu, 25 Oct 2001 19:09:03 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9PMeUT03355 for ietf-calendar-bks; Thu, 25 Oct 2001 15:40:30 -0700 (PDT) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PMeS803351 for ; Thu, 25 Oct 2001 15:40:28 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id RAA08582 for ; Thu, 25 Oct 2001 17:39:22 -0500 From: "Shannon J. Clark" To: Subject: Issues List - request for issues Date: Thu, 25 Oct 2001 17:40:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello all, I have volunteered to lead the editing of iCalendar, replacing Eric Busboom who has done a great job. One of my first tasks is to prepare and make available to CALSCH an updated and useful "Issues" list. The recent mail archive "hiccup" means that the current Issues list links to mail messages also need to be updated. Please start at the following URL: http://www.softwarestudio.org/iCal/2445Issues.html - last updated Aug 15th, 2001. If you know the status of a given issue - please update the list If you know the exact mail messages that the issue relates to - please email me privately at shannon@jigzaw.com - I will update the list accordingly and make a new version available shortly. If you have or are aware of other issues please bring them to the list's attention. This list is for RFC2445 specifically - I am willing to maintain these lists for the other standards and documents as well - there are some issues facing the group that cross each standard. Current issues I know of: Internationalization - impact on each standard - impact of Unicode use (very related) Adoption of BEEB by CAP - does it impact iCalendar? iTIP?, iMIP?, iRIP? Guide to Internet Calendaring? - any other documents? SKiCal - many proposals, suggestions, requirements XML discussion - what is goal of conversation about XML? - how to use XML in relationship to iCalendar, iMIP, iTIP, CAP? Bruce has submitted many typos and points that I will be adding to the issues list as well. Anything else??? thanks to all, Shannon Shannon J. Clark JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Fri Oct 26 07:58:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28760 for ; Fri, 26 Oct 2001 07:58:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QBccB24159 for ietf-calendar-bks; Fri, 26 Oct 2001 04:38:38 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QBca824155 for ; Fri, 26 Oct 2001 04:38:37 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id HAA25793 for ; Fri, 26 Oct 2001 07:38:30 -0400 Received: from c1085 ([101.1.46.19]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9QBcUH28502 for ; Fri, 26 Oct 2001 07:38:30 -0400 (EDT) From: "Eric R. Plamondon" To: Subject: RE: XML iCal draft changes Date: Fri, 26 Oct 2001 07:34:23 -0400 Message-ID: <001701c15e12$292753b0$132e0165@in.steltor.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C15DF0.A215B3B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C15DF0.A215B3B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good Morning, I believe it's important to keep the naming differences between iCal and xCal to a minimum. Changing propery and parameter names between iCal and xCal, from a coding perspective has relatively little impact (it's just code...), but will only provide a point of confusion for those people trying to adopt it. The base specification is the iCalendar one. As for the issue of case, I'm for mixed case, to ease readability. No reason, other than a style preference (even though it conflicts with my statement about remaining consistant with iCal). The MIME types outlined so far are application/calendar+xml application/icalendar+xml application/xcal+xml text/xcal+xml I still prefer application/calendar+xml, since it is closer to the iCal MIME type of text/calendar. However any of then are acceptable. Can anyone think of a reason to discount either of these? With respect to the DTD / Schema issue, it really looks like there is interest for both. Eric ------------------------------- Eric R. Plamondon Steltor - Chief Web Architect 2000 Peel Street, 4th Floor Montreal, Quebec mailto:ericp@steltor.com http://www.steltor.com ------=_NextPart_000_0018_01C15DF0.A215B3B0 Content-Type: text/x-vcard; name="Eric Plamondon.vcf" Content-Disposition: attachment; filename="Eric Plamondon.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Plamondon;Eric FN:Eric Plamondon ORG:;Steltor TITLE:Developer (Client) TEL;WORK;VOICE:(514) 733-8500 x272 TEL;CELL;VOICE:+15149108500 EMAIL;PREF;INTERNET:EricP@Steltor.com REV:20010725T112905Z END:VCARD ------=_NextPart_000_0018_01C15DF0.A215B3B0-- From owner-ietf-calendar@mail.imc.org Fri Oct 26 09:20:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02603 for ; Fri, 26 Oct 2001 09:20:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QCwnu03436 for ietf-calendar-bks; Fri, 26 Oct 2001 05:58:49 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QCwm803427 for ; Fri, 26 Oct 2001 05:58:48 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9QCxJQ15982 for ; Fri, 26 Oct 2001 07:59:19 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Oct 2001 07:58:44 -0500 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 26 Oct 2001 07:57:37 -0500 content-class: urn:content-classes:message Subject: RE: XML iCal draft changes Date: Fri, 26 Oct 2001 07:57:46 -0500 Message-ID: <15A85922ED48294F80973D83F95074B64E0510@daebe006.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: XML iCal draft changes Thread-Index: AcFeFsB9wo9XFcoJEdWBTgBQi2X+DwABa8XA From: "Dawson Frank (NMP/Irving)" To: "'ext Eric R. Plamondon'" , X-OriginalArrivalTime: 26 Oct 2001 12:57:37.0814 (UTC) FILETIME=[C9F0AB60:01C15E1D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9QCwm803430 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > I believe it's important to keep the naming > differences between iCal and xCal to a minimum. Have not seen any reason to make this a design requirement for the mapping of the XML, alternative syntax (ie, xCal). > Changing propery and parameter names between > iCal and xCal, from a coding perspective has > relatively little impact (it's just code...), > but will only provide a point of confusion for > those people trying to adopt it. The base > specification is the iCalendar one. Confusion to what? Not the parser. And to the developer? As long as there is a well defined mapping (ie, explicit table and also descriptive prose), then there is no discernable confusion created. > > As for the issue of case, I'm for mixed case, > to ease readability. No reason, other than a > style preference (even though it conflicts with > my statement about remaining consistant with > iCal). > The "prime directive" for consistency with iCalendar is based on the purpose for this specification. That is, it addresses a requirement for an ALTERNATIVE, XML representation for iCalendar. It is NOT an alternative IETF calendaring and scheduling semantic. SO, the important design requirement is that the semantics need to remain aligned with RFC2445. But there SHOULD BE no requirement to align the syntax, unless there is a strong requirement that can be made for such. This argument that we need to align case and tokens with the standard syntax (ie, RFC2445) implies that we just don't need an XML, alternative syntax. Yet, I think a strong argument has been made for such an alternative syntax. > The MIME types outlined so far are > application/calendar+xml > application/icalendar+xml > application/xcal+xml > text/xcal+xml > I still prefer application/calendar+xml, since it > is closer to the iCal MIME type of text/calendar. However > any of then are acceptable. Can anyone think of > a reason to discount either of these? I believe our lessons with iMIP encoding into MIME has taught us that we should have listened to our area director's comments and gone with "applicatin/calendar" over "text/calendar" for the MIME media subtype for RFC2445. Keeping that in mind, I believe that the "application/calendar+xml" makes more sense. As it would be the XML form of the iCalendar semantics. As a matter of fact, to avoid confusion with the MIME media subtype for the revision to RFC2445, maybe we should make it's MIME media subtype "application/calendar". Another way that we can filter iCalendar from iCalendar v2? > > With respect to the DTD / Schema issue, it really > looks like there is interest for both. > Given that the use of the market for the Schema has not panned out and that the use of a data representation format that conflicts with primary data type definitions that iCalendar uses (ie, date/time), I don't see what benefit comes from integration of the schema into the DTD. As a matter of fact, it makes the implementation of the xCal DTD that much more complex. -- Frank From owner-ietf-calendar@mail.imc.org Fri Oct 26 10:24:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04807 for ; Fri, 26 Oct 2001 10:24:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QE3r209108 for ietf-calendar-bks; Fri, 26 Oct 2001 07:03:53 -0700 (PDT) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QE3q809104 for ; Fri, 26 Oct 2001 07:03:52 -0700 (PDT) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA05045; Fri Oct 26 10:00:24 2001 Subject: RE: XML iCal draft changes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 26 Oct 2001 10:04:42 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 10/26/2001 10:04:55 AM, Serialize complete at 10/26/2001 10:04:55 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > With respect to the DTD / Schema issue, it really > looks like there is interest for both. If it's specified two different ways, you have to be absolutely certain that they agree with each other--and that they continue to agree every time the spec is revved. Really, this is the same issue as keeping the names the same between XML and text/calendar: don't specify the same thing twice. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Fri Oct 26 10:24:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04820 for ; Fri, 26 Oct 2001 10:24:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QE7Ke09217 for ietf-calendar-bks; Fri, 26 Oct 2001 07:07:20 -0700 (PDT) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QE7I809206 for ; Fri, 26 Oct 2001 07:07:19 -0700 (PDT) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA05412; Fri Oct 26 10:03:08 2001 Subject: Re: How does each standard "fit" together MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 26 Oct 2001 10:07:26 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 10/26/2001 10:07:39 AM, Serialize complete at 10/26/2001 10:07:39 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > That is - with the adoption of BEEB for CAP - That's BEEP. > how does/does not this impact > iTIP, iMIP, iRIP, iCAL, CAP, MIME or any other standards that are employed > in the proposals of this working group? It obviously does not impact iTIP, iMIP, iCalendar, or MIME at all. iRIP is dead, replaced by CRISP. Its impact on CAP (and CRISP) is obvious, because it's CAP that will be modified. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Fri Oct 26 13:44:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12618 for ; Fri, 26 Oct 2001 13:44:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QHOu425177 for ietf-calendar-bks; Fri, 26 Oct 2001 10:24:56 -0700 (PDT) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QHOs825171 for ; Fri, 26 Oct 2001 10:24:54 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA09505 for ; Fri, 26 Oct 2001 12:23:26 -0500 From: "Shannon J. Clark" To: Subject: Discussion on Calendaring in other forums Date: Fri, 26 Oct 2001 12:24:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just to bring it to the attention of this group: There is a discussion of Calendaring (and scheduling) going on at Slashdot today, sparked by a donation of code to the Mozilla project. http://slashdot.org/article.pl?sid=01/10/26/141247&mode=nested A handful of interesting points - 1 - among a fairly highly technical audience there is considerable lack of awareness of CALSCH and the standards we are pursuing - only minor mentions of "iCal import" as a feature 2 - considerable variation in this audience as to what they are looking for in a Calendaring product - one common theme does appear to be a simple one to use and deploy - vs. "bloatware" as they put it. Thought it would be a useful discussion for people here to take a look at - it is easy to forget that the standards we are working on have to be able to solve real user's real problems if they will ever be adopted and employed by the users, software developers, and vendors. Shannon Shannon J. Clark JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Fri Oct 26 14:00:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13320 for ; Fri, 26 Oct 2001 14:00:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QHclO25426 for ietf-calendar-bks; Fri, 26 Oct 2001 10:38:47 -0700 (PDT) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QHcj825422 for ; Fri, 26 Oct 2001 10:38:45 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA09526; Fri, 26 Oct 2001 12:37:16 -0500 From: "Shannon J. Clark" To: "John Stracke" , Subject: RE: How does each standard "fit" together Date: Fri, 26 Oct 2001 12:38:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, Thanks for correcting my typo re BEEP. Well I guess my concern is if migrating CAP to use BEEP requires any changes/additions to the data structures that we require (to handle something security related?) - then it would impact the other standards - does anyone here understand what is involved in substituting BEEP for the current transport sections of CAP enough to check for this type of issue? Also, I suspect - but have not yet confirmed - that there may need to be minor changes to some of the discussions in the other standards about how CAP works with the various standards - perhaps not if the substitution of BEEP does not alter anything fundamental about how CAP will work. In any case this change to CAP may impact documents such as the Guide to Internet Calendaring. Just thinking we should take a careful luck to see if there are any unforeseen places that are impacted (which may also point out sections that perhaps should be modified in the various documents) Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Friday, October 26, 2001 9:07 AM To: ietf-calendar@imc.org Subject: Re: How does each standard "fit" together > That is - with the adoption of BEEB for CAP - That's BEEP. > how does/does not this impact > iTIP, iMIP, iRIP, iCAL, CAP, MIME or any other standards that are employed > in the proposals of this working group? It obviously does not impact iTIP, iMIP, iCalendar, or MIME at all. iRIP is dead, replaced by CRISP. Its impact on CAP (and CRISP) is obvious, because it's CAP that will be modified. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Fri Oct 26 14:05:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13551 for ; Fri, 26 Oct 2001 14:05:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QHjts25638 for ietf-calendar-bks; Fri, 26 Oct 2001 10:45:55 -0700 (PDT) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QHjs825632 for ; Fri, 26 Oct 2001 10:45:54 -0700 (PDT) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id NAA12102; Fri Oct 26 13:40:49 2001 Subject: RE: How does each standard "fit" together MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 26 Oct 2001 13:45:08 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 10/26/2001 01:45:21 PM, Serialize complete at 10/26/2001 01:45:21 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Well I guess my concern is if migrating CAP to use BEEP requires any > changes/additions to the data structures that we require (to handle > something security related?) - then it would impact the other standards - It shouldn't--that's what layering means. CAP carries iCalendar objects, including iTIP messages, on top of its transport layer. Replacing that layer with BEEP should not have any impact on the payloads. (As for security--CAP is our only spec with any security in it at all; we can gut it entirely without having any security impact on iCalendar or i?IP.) John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Fri Oct 26 18:15:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20022 for ; Fri, 26 Oct 2001 18:15:24 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9QLw7j02338 for ietf-calendar-bks; Fri, 26 Oct 2001 14:58:07 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QLw6802334 for ; Fri, 26 Oct 2001 14:58:06 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA00266; Fri, 26 Oct 2001 14:58:05 -0700 (PDT) Message-ID: <3BD9DB9C.5F7CFC9@Royer.com> Date: Fri, 26 Oct 2001 15:54:36 -0600 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: XML iCal draft changes References: Content-Type: multipart/mixed; boundary="------------51FFA4F7732AEF5962011880" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------51FFA4F7732AEF5962011880 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > > > Structure Properties > > > - the following structure properties where change to > > > reflect their iCal counterpart > > > - ical to vcalendar > > > ... > In the short term, this could work; but, in the long term, it effectively > means we have to maintain two separate namespaces. Worse, any translation > code has to maintain a mapping table, which will get out of date whenever > something is added to iCalendar. On the other hand, it might keep people from just throwing in junk and calling it new-iCalendar tags :-) > (*) I'm not too thrilled with the notion of calling it xCal, > ... I agree, lets not make people think it is a separate standard. -Doug --------------51FFA4F7732AEF5962011880 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------51FFA4F7732AEF5962011880-- From owner-ietf-calendar@mail.imc.org Fri Oct 26 18:19:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20054 for ; Fri, 26 Oct 2001 18:19:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QLt3V02299 for ietf-calendar-bks; Fri, 26 Oct 2001 14:55:03 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QLt2802295 for ; Fri, 26 Oct 2001 14:55:02 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA00187; Fri, 26 Oct 2001 14:54:52 -0700 (PDT) Message-ID: <3BD9DADD.28EBBB9B@Royer.com> Date: Fri, 26 Oct 2001 15:51:25 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: XML iCal draft changes References: <001701c15e12$292753b0$132e0165@in.steltor.com> Content-Type: multipart/mixed; boundary="------------FEF4B3D59010BFB59CF9412E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FEF4B3D59010BFB59CF9412E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Eric R. Plamondon" wrote: > > Good Morning, > > I believe it's important to keep the naming > differences between iCal and xCal to a minimum. > Changing propery and parameter names between > iCal and xCal, from a coding perspective has > relatively little impact (it's just code...), > but will only provide a point of confusion for > those people trying to adopt it. The base > specification is the iCalendar one. I am hoping to send both xCal and vCard/XML to small memory devices - I am in favor of short names. these? > > With respect to the DTD / Schema issue, it really > looks like there is interest for both. I think we should look into Schema, but if that takes too long or would slow the process down, I am happy with DTDs. --------------FEF4B3D59010BFB59CF9412E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------FEF4B3D59010BFB59CF9412E-- From owner-ietf-calendar@mail.imc.org Fri Oct 26 18:25:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20123 for ; Fri, 26 Oct 2001 18:25:12 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9QM66802493 for ietf-calendar-bks; Fri, 26 Oct 2001 15:06:06 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QM65802488 for ; Fri, 26 Oct 2001 15:06:05 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA00362; Fri, 26 Oct 2001 15:06:06 -0700 (PDT) Message-ID: <3BD9DD6C.88BB624@Royer.com> Date: Fri, 26 Oct 2001 16:02:20 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: How does each standard "fit" together References: Content-Type: multipart/mixed; boundary="------------37987D2945764083A4A003E0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------37987D2945764083A4A003E0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Hello, > > Bearing in mind the Guide to Internet Calendaring - I have a question for > the list. > > How does all of the various standards that we are currently and are > proposing to use all "fit" together? > > That is - with the adoption of BEEB for CAP - how does/does not this impact > iTIP, iMIP, iRIP, iCAL, CAP, MIME or any other standards that are employed > in the proposals of this working group? No impact at all to the objects. No added security issues (I am still digesting BEEP - so maybe there are some). BEEP will delay CAP as there MUST BE review time! > I suggest that people's responses to this question be collated and made > available at www.calsch.org among other places. That is what the mailing list is for... :-) --------------37987D2945764083A4A003E0 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------37987D2945764083A4A003E0-- From owner-ietf-calendar@mail.imc.org Fri Oct 26 18:26:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20142 for ; Fri, 26 Oct 2001 18:26:36 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9QM8ca02542 for ietf-calendar-bks; Fri, 26 Oct 2001 15:08:38 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QM8a802538 for ; Fri, 26 Oct 2001 15:08:37 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA00435 for ; Fri, 26 Oct 2001 15:08:27 -0700 (PDT) Message-ID: <3BD9DDF0.4DEBA530@Royer.com> Date: Fri, 26 Oct 2001 16:04:32 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Discussion on Calendaring in other forums References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Just to bring it to the attention of this group: > > There is a discussion of Calendaring (and scheduling) going on at Slashdot > today, sparked by a donation of code to the Mozilla project. > ... > 2 - considerable variation in this audience as to what they are looking for > in a Calendaring product - one common theme does appear to be a simple one > to use and deploy - vs. "bloatware" as they put it. Most people think only calendaring. The scheduling and interacting with others makes it bloat. I'll bet if they want scheduling, it get BIG. From owner-ietf-calendar@mail.imc.org Fri Oct 26 18:26:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20143 for ; Fri, 26 Oct 2001 18:26:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QM1sR02408 for ietf-calendar-bks; Fri, 26 Oct 2001 15:01:54 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QM1q802404 for ; Fri, 26 Oct 2001 15:01:52 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA00350; Fri, 26 Oct 2001 15:01:54 -0700 (PDT) Message-ID: <3BD9DC76.4422A7B0@Royer.com> Date: Fri, 26 Oct 2001 15:58:14 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: XML iCal draft changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > With respect to the DTD / Schema issue, it really > > looks like there is interest for both. > > If it's specified two different ways, you have to be absolutely certain > that they agree with each other--and that they continue to agree every > time the spec is revved. > > Really, this is the same issue as keeping the names the same between XML > and text/calendar: don't specify the same thing twice. I am not in favor of both. Lets look at both. And on the other hand - DTD's are going to ~slowly~ go away when schema takes hold. We need to be prepared. -Doug From owner-ietf-calendar@mail.imc.org Fri Oct 26 18:28:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20171 for ; Fri, 26 Oct 2001 18:28:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QMBvl02609 for ietf-calendar-bks; Fri, 26 Oct 2001 15:11:57 -0700 (PDT) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QMBu802605 for ; Fri, 26 Oct 2001 15:11:56 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA00511 for ; Fri, 26 Oct 2001 15:11:57 -0700 (PDT) Message-ID: <3BD9DEBD.2365C26E@Royer.com> Date: Fri, 26 Oct 2001 16:07:57 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: How does each standard "fit" together References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > John, > > Thanks for correcting my typo re BEEP. > > Well I guess my concern is if migrating CAP to use BEEP requires any > changes/additions to the data structures that we require (to handle > something security related?) - then it would impact the other standards - > does anyone here understand what is involved in substituting BEEP for the > current transport sections of CAP enough to check for this type of issue? We went to great pains to separate the transport from the objects. Any changes we may find as a result of going to BEEP are probably bugs we have not yet found. > Also, I suspect - but have not yet confirmed - that there may need to be > minor changes to some of the discussions in the other standards about how > CAP works with the various standards - perhaps not if the substitution of > BEEP does not alter anything fundamental about how CAP will work. CAP writes directly to the store + it can handle iTIP methods. BEEP is just the transport. NOTHONG in iTIP, iMIP, or iCalendar needs to change as a result of going to BEEP. From owner-ietf-calendar@mail.imc.org Fri Oct 26 19:17:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20425 for ; Fri, 26 Oct 2001 19:17:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QMqMF03351 for ietf-calendar-bks; Fri, 26 Oct 2001 15:52:22 -0700 (PDT) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QMqK803344 for ; Fri, 26 Oct 2001 15:52:20 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id RAA10159 for ; Fri, 26 Oct 2001 17:50:47 -0500 From: "Shannon J. Clark" To: Subject: RE: How does each standard "fit" together Date: Fri, 26 Oct 2001 17:52:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BD9DD6C.88BB624@Royer.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, Thanks - I guess what I am getting at is that in this sea of abbreviations and standards it would be very helpful to prepare a short, concise, and up-to-date explanation of the actual role of each standard in relation to the others. For example - it is easy to view iCalendar as "just" a storage/data format - but it specifically also mentions Methods and a discussion of actions/access to it, as well as has a discussion about responses and some about access rights (i.e. "Only the ORGANIZER of an event can make changes to it, ATTENDEES can only change data about their own status" - this moves iCalendar out of "just" being a data storage and into a realm of interaction. It also assumes certain types of use cases. Further confusing matters are that iTip and CAP both make reference to certain impacts onto iCalendar (with CAP being the worst offender in going ahead and defining changes to iCalendar in the CAP draft). With the addition of BEEP to the picture - I think a vendor or developer could be easily forgiven being more a tad confused as to what to read to create a compliant application. I.E. if you coded your data structures from RFC2445, then started to look at the access pieces of your application by reading iTIP and CAP (and iMIP if mail would be an access means to your system) - you then have to go back into your data structures and make changes. The Guide to Internet Calendaring is a very useful document - and helpful - my thought is that we may want to take the opportunity presented by rolling BEEP into CAP to look closely at all of the drafts and see if we can clarify/simplify them to make the implementation process easier. Yes - these are standards which should be implementation neutral - but as it currently stands we have over 400 pages of standards (with BEEP getting close to 500 pages) which are closely interlocked into each other - the Guide is helpful but is only scratching the surface. thanks again! Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Friday, October 26, 2001 5:02 PM To: ietf-calendar@imc.org Subject: Re: How does each standard "fit" together "Shannon J. Clark" wrote: > > Hello, > > Bearing in mind the Guide to Internet Calendaring - I have a question for > the list. > > How does all of the various standards that we are currently and are > proposing to use all "fit" together? > > That is - with the adoption of BEEB for CAP - how does/does not this impact > iTIP, iMIP, iRIP, iCAL, CAP, MIME or any other standards that are employed > in the proposals of this working group? No impact at all to the objects. No added security issues (I am still digesting BEEP - so maybe there are some). BEEP will delay CAP as there MUST BE review time! > I suggest that people's responses to this question be collated and made > available at www.calsch.org among other places. That is what the mailing list is for... :-) From owner-ietf-calendar@mail.imc.org Sat Oct 27 11:55:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14499 for ; Sat, 27 Oct 2001 11:55:05 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9RFQht28424 for ietf-calendar-bks; Sat, 27 Oct 2001 08:26:43 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9RFQf828420 for ; Sat, 27 Oct 2001 08:26:42 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA09161 for ; Sat, 27 Oct 2001 11:26:37 -0400 Received: from c1085 ([101.1.46.19]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9RFQaH26703 for ; Sat, 27 Oct 2001 11:26:36 -0400 (EDT) From: "Eric R. Plamondon" To: Subject: RE: XML iCal draft changes Date: Sat, 27 Oct 2001 11:22:23 -0400 Message-ID: <000b01c15efb$2d88d930$132e0165@in.steltor.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000C_01C15ED9.A67BCD10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3BD9DADD.28EBBB9B@Royer.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C15ED9.A67BCD10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of Doug Royer > Sent: Friday, October 26, 2001 5:51 PM > To: ietf-calendar@imc.org > Subject: Re: XML iCal draft changes > > > > > "Eric R. Plamondon" wrote: > > > > Good Morning, > > > > I believe it's important to keep the naming > > differences between iCal and xCal to a minimum. > > Changing propery and parameter names between > > iCal and xCal, from a coding perspective has > > relatively little impact (it's just code...), > > but will only provide a point of confusion for > > those people trying to adopt it. The base > > specification is the iCalendar one. > > I am hoping to send both xCal and vCard/XML to small memory > devices - I am in favor of short names. these? What about using a WBXML encoding of the xCal/xCard proposed specifications, this would greatly reduce the size of data sent. Eric ------------------------------- Eric R. Plamondon Steltor - Chief Web Architect 2000 Peel Street, 4th Floor Montreal, Quebec mailto:ericp@steltor.com http://www.steltor.com ------=_NextPart_000_000C_01C15ED9.A67BCD10 Content-Type: text/x-vcard; name="Eric Plamondon.vcf" Content-Disposition: attachment; filename="Eric Plamondon.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Plamondon;Eric FN:Eric Plamondon ORG:;Steltor TITLE:Developer (Client) TEL;WORK;VOICE:(514) 733-8500 x272 TEL;CELL;VOICE:+15149108500 EMAIL;PREF;INTERNET:EricP@Steltor.com REV:20010725T112905Z END:VCARD ------=_NextPart_000_000C_01C15ED9.A67BCD10-- From owner-ietf-calendar@mail.imc.org Sun Oct 28 18:24:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16878 for ; Sun, 28 Oct 2001 18:24:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9SN3sf24517 for ietf-calendar-bks; Sun, 28 Oct 2001 15:03:54 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9SN3p824507 for ; Sun, 28 Oct 2001 15:03:52 -0800 (PST) To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: Discussion on Calendaring in other forums MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Sun, 28 Oct 2001 19:03:12 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 10/28/2001 06:03:55 PM, Serialize complete at 10/28/2001 06:03:55 PM Content-Type: multipart/alternative; boundary="=_alternative 0000760785256AF4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0000760785256AF4_= Content-Type: text/plain; charset="us-ascii" Correcto-mundo. Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 10/26/01 06:04 PM Please respond to "ietf-calendar@imc.org" To: "ietf-calendar@imc.org" cc: Subject: Re: Discussion on Calendaring in other forums "Shannon J. Clark" wrote: > > Just to bring it to the attention of this group: > > There is a discussion of Calendaring (and scheduling) going on at Slashdot > today, sparked by a donation of code to the Mozilla project. > ... > 2 - considerable variation in this audience as to what they are looking for > in a Calendaring product - one common theme does appear to be a simple one > to use and deploy - vs. "bloatware" as they put it. Most people think only calendaring. The scheduling and interacting with others makes it bloat. I'll bet if they want scheduling, it get BIG. --=_alternative 0000760785256AF4_= Content-Type: text/html; charset="us-ascii"
Correcto-mundo.



Doug Royer <Doug@royer.com>
Sent by: owner-ietf-calendar@mail.imc.org

10/26/01 06:04 PM
Please respond to "ietf-calendar@imc.org"

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: Discussion on Calendaring in other forums






"Shannon J. Clark" wrote:
>
> Just to bring it to the attention of this group:
>
> There is a discussion of Calendaring (and scheduling) going on at Slashdot
> today, sparked by a donation of code to the Mozilla project.
> ...

> 2 - considerable variation in this audience as to what they are looking for
> in a Calendaring product - one common theme does appear to be a simple one
> to use and deploy - vs. "bloatware" as they put it.

Most people think only calendaring. The scheduling and interacting
with others makes it bloat. I'll bet if they want scheduling, it
get BIG.

--=_alternative 0000760785256AF4_=-- From owner-ietf-calendar@mail.imc.org Sun Oct 28 21:17:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17769 for ; Sun, 28 Oct 2001 21:17:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9T20iT27319 for ietf-calendar-bks; Sun, 28 Oct 2001 18:00:44 -0800 (PST) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T20g827314 for ; Sun, 28 Oct 2001 18:00:43 -0800 (PST) Received: from 192.168.10-104.masq (garm.ximian.com [141.154.95.2]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id VAA02215 for ; Sun, 28 Oct 2001 21:00:36 -0500 Subject: DATE values question From: Damon Chaplin To: "ietf-calendar@imc.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99 (Preview Release) Date: 28 Oct 2001 20:58:21 -0500 Message-Id: <1004320701.1054.6.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit If I have a VEVENT like this: DTSTART;VALUE=DATE:20010910 DTEND;VALUE=DATE:20011310 (i.e. from 9th Oct to 13th Oct) Does it: a) include the 13th October entirely, up to midnight. or b) stop at 12am on 13th. Damon From owner-ietf-calendar@mail.imc.org Mon Oct 29 14:41:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25047 for ; Mon, 29 Oct 2001 14:41:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TJEck10254 for ietf-calendar-bks; Mon, 29 Oct 2001 11:14:38 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TJEa810250 for ; Mon, 29 Oct 2001 11:14:36 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id NAA13285 for ; Mon, 29 Oct 2001 13:11:45 -0600 From: "Shannon J. Clark" To: Subject: XML Basics reference Date: Mon, 29 Oct 2001 13:14:31 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Given the conversations that have been occurring about XML - in particular DTD vs. Schema etc I thought the following article might be of help to people seeking to understand the differences. http://www.25hoursaday.com/StoringAndQueryingXML.html It was just linked to by Slashdot - so I would recommend referencing it late today or tomorrow - it is a lengthy and detailed discussion of XML and XML related standards (DTD, Schema, XSL, XSD etc) - very helpful as an introduction and reference to a new sea of TLAs. Shannon From owner-ietf-calendar@mail.imc.org Mon Oct 29 19:48:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01067 for ; Mon, 29 Oct 2001 19:48:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9U0IkB21081 for ietf-calendar-bks; Mon, 29 Oct 2001 16:18:46 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U0Ii821075 for ; Mon, 29 Oct 2001 16:18:44 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA13655 for ; Mon, 29 Oct 2001 18:15:47 -0600 From: "Shannon J. Clark" To: Subject: Issues List - General CALSCH issues Date: Mon, 29 Oct 2001 18:18:40 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A more formal version of this will be documented in the next weeks. This email covers CALSCH general group issues - please respond with additional issues and/or status reports. The issues are NOT in an particular order, but will be numbered moving forward. CALSCH Issues - General List Oct 29th, 2001 by Shannon Clark for CALSCH group: 1. Internationalization - impact on all standards (from CALSCH editors call and feedback from IETF 2. Integration of BEEP into CAP (see CAP Issues List) - does this impact any other CALSCH group documents? (i.e. Guide to Internet Calendaring) 3. XML & CALSCH group - impact and goals? (from many emails to group) 4. CAL Connect III - When? (see emails from Pat to group) 5. CAL Connect III - Where? (see emails from Pat to group) 6. Updated Interoperability Matrix for CAL Connects (discussed in CALSCH editors call) 7. Co-ordination of editors for CALSCH documents 8. Last Call for Guide to Internet Calendaring 9. CALSCH business prior to December 2001 IETF meeting All of the above are open and unresolved. Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 20:10:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01358 for ; Mon, 29 Oct 2001 20:10:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U0k5b21650 for ietf-calendar-bks; Mon, 29 Oct 2001 16:46:05 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U0k3821646 for ; Mon, 29 Oct 2001 16:46:03 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA13680 for ; Mon, 29 Oct 2001 18:43:06 -0600 From: "Shannon J. Clark" To: Subject: Issues list - CAP Oct 29th, 2001 Date: Mon, 29 Oct 2001 18:45:59 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is a start at a separate issues list for CAP. This needs to be extended and added to, numbering is started as of today and reflects no specific ordering. There are likely MANY typo type issues missing from this list. Issues - summary on Oct 29th, 2001 by Shannon Clark for CALSCH group 1. Integration of BEEP into CAP 2. Internationalization - impact on CAP 3. Update CAP draft for BEEP changes (re-number again?) 4. Status of CAP re IETF in general (still Internet Draft?) 5. Impact of XML discussions on CAP (does it? would it? should it?) 6. Solidify proposed iCalendar changes for integration into next draft of iCalendar Shannon J. Clark President, JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 20:13:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01398 for ; Mon, 29 Oct 2001 20:13:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9U0nmd21710 for ietf-calendar-bks; Mon, 29 Oct 2001 16:49:48 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U0nk821706 for ; Mon, 29 Oct 2001 16:49:46 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA13685 for ; Mon, 29 Oct 2001 18:46:50 -0600 From: "Shannon J. Clark" To: Subject: Issues list - iMIP Oct 29th, 2001 Date: Mon, 29 Oct 2001 18:49:43 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is an attempt to create an issues list for iMIP - please add to it any known specific issues (esp. typos) that are not on this list. The numbering is not in any particular order. A more refined version of this list should be available in a few weeks on the CALSCH website (www.calsch.org). Issues List - iMIP Oct 29th, 2001 by Shannon Clark for CALSCH working group 1. Internationalization - impact on iMIP 2. Confirm that BEEP addition to CAP does not impact iMIP (shouldn't but we should check) 3. Confirm that no changes to iCalendar impact iMIP 4. Status of iMIP? 5. Define and publish Interoperability Matrix for iMIP - needed for CAL Connect testing Shannon J. Clark President, JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 20:16:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01417 for ; Mon, 29 Oct 2001 20:16:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9U0rqe21803 for ietf-calendar-bks; Mon, 29 Oct 2001 16:53:52 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U0rn821795 for ; Mon, 29 Oct 2001 16:53:50 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA13694 for ; Mon, 29 Oct 2001 18:50:52 -0600 From: "Shannon J. Clark" To: Subject: Issues List - iTIP Oct 29th, 2001 Date: Mon, 29 Oct 2001 18:53:45 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is a start at an issues list for iTIP, please add any known typos or other known issues. Numbering is as of Oct 29th, 2001 and in no particular order. A more formal version of this list should be available on the CALSCH website (www.calsch.org) in a few weeks. Issues List - iTIP Oct 29th, 2001 by Shannon Clark for CALSCH working group 1. Internationalization - impact on iTIP 2. Confirm no impact of BEEP adoption in CAP on iTIP (shouldn't be but we should check) 3. Status of iTIP? 4. Define and publish Interoperability Matrix for iTIP - needed for CAL Connect testing 5. Check that proposed changes to iCalendar (i.e. for CAP etc) do not impact iTIP Shannon J. Clark President, JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 20:53:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01973 for ; Mon, 29 Oct 2001 20:53:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U1XvG22870 for ietf-calendar-bks; Mon, 29 Oct 2001 17:33:57 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U1Xt822866 for ; Mon, 29 Oct 2001 17:33:55 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id TAA13758 for ; Mon, 29 Oct 2001 19:30:57 -0600 From: "Shannon J. Clark" To: Subject: issues List - iCalendar (RFC 2445) Oct 29th 2001 Date: Mon, 29 Oct 2001 19:33:51 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Below is an attempt to update the issues list for iCalendar, this is long and does not contain most issues raised SINCE May 3rd, 2001. Please email shannon@jigzaw.com with specific corrections/links/additional - cc: ietf-calendar@imc.org if you are raising a new issue. Also note that email references need to be updated due to renumbering of mailing list - help in doing this much appreciated! Note that many of these issues have been open for over a year (some over 2 years)! This is a summary of the OPEN issues that have been raised with iCalendar. A full and more detailed list will be available on the CALSCH website (www.calsch.org) in the next few weeks. Issues List - iCalendar (RFC 2445) Oct 29th, 2001 updated by Shannon Clark for CALSCH working group Type Codes - Typo = typographical error(s); ICR - informal change request; ERR - error # Entered Type Summary ---------------------------------------------------------------------------- ------ 4 7/13/99 Typo Ordering of Parameters in ABNF 10 12/23/99 Typo Conflict in Multiple occurrence of DESCRIPTION 20 8/20/00 ICR Add New CAP components to spec 41 9/24/00 Typo Adjust ABNF to accommodate extension 42 10/12/00 Typo Typos in examples 46 2/7/01 ERR Conflict in DTSTART Conformance 48 2/10/01 ICR Add way to specify extensions to iCalendar 49 3/5/01 ICR Vtodo conflict between DUE and DURATION 50 3/15/01 Typo No linefeeds in example on page 136 52 3/27/01 ICR DTSTART/END that fall on TZ shift ambiguous 53 3/28/01 ICR DURATION allowed for DTSTART;VALUE=DATE? 54 4/1/01 ICR Explain difference between DTEND and DURATION 55 4/26/01 ICR 4.2.17 RSVP Expectation. Be explicit about when required to return a reply 56 4/26/01 ICR Multiple TZIDs conflict 57 5/3/01 ICR RDATE in VTIMEZONE: Local or UTC 58 10/29/01 ICR Internationalization - impact on iCalendar 59 10/29/01 ICR Incorporate ALL CAP proposed changes 60 10/29/01 Typo Typos from Bruce Kahn @ IRIS (ABNF typos) - need to mail to list 61 10/29/01 Typo Typo in Trigger p128 (missing space) ---------------------------------------------------------------------------- ------- thanks to all for your help and additions! Shannon J. Clark President, JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 21:09:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02232 for ; Mon, 29 Oct 2001 21:09:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U1rXH23334 for ietf-calendar-bks; Mon, 29 Oct 2001 17:53:33 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U1rV823330 for ; Mon, 29 Oct 2001 17:53:31 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id UAA03049; Mon, 29 Oct 2001 20:53:28 -0500 Received: from steltor.com ([101.0.0.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9U1rOH18725; Mon, 29 Oct 2001 20:53:25 -0500 (EST) Message-ID: <3BDE0869.73D8888E@steltor.com> Date: Mon, 29 Oct 2001 20:54:49 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" CC: ietf-calendar@imc.org Subject: Re: Issues list - CAP Oct 29th, 2001 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit There is up to date CAP issues list at the calsch.org web site: http://calsch.org/ietf/cap-ToDo.txt George "Shannon J. Clark" wrote: > > This is a start at a separate issues list for CAP. This needs to be extended > and added to, numbering is started as of today and reflects no specific > ordering. There are likely MANY typo type issues missing from this list. > > Issues - summary on Oct 29th, 2001 > by Shannon Clark for CALSCH group > > 1. Integration of BEEP into CAP > > 2. Internationalization - impact on CAP > > 3. Update CAP draft for BEEP changes (re-number again?) > > 4. Status of CAP re IETF in general (still Internet Draft?) > > 5. Impact of XML discussions on CAP (does it? would it? should it?) > > 6. Solidify proposed iCalendar changes for integration into next draft of > iCalendar > > Shannon J. Clark > President, JigZaw, Inc > 1.800.4.JIGZAW (454.4929) > shannon@jigzaw.com > www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 21:17:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02326 for ; Mon, 29 Oct 2001 21:17:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9U208m23472 for ietf-calendar-bks; Mon, 29 Oct 2001 18:00:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U207823467 for ; Mon, 29 Oct 2001 18:00:07 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id VAA03077; Mon, 29 Oct 2001 21:00:04 -0500 Received: from steltor.com ([101.0.0.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9U200H19001; Mon, 29 Oct 2001 21:00:01 -0500 (EST) Message-ID: <3BDE09F7.CB5B924A@steltor.com> Date: Mon, 29 Oct 2001 21:01:27 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" CC: ietf-calendar@imc.org Subject: Re: Issues list - CAP Oct 29th, 2001 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > This is a start at a separate issues list for CAP. This needs to be extended > and added to, numbering is started as of today and reflects no specific > ordering. There are likely MANY typo type issues missing from this list. > > Issues - summary on Oct 29th, 2001 > by Shannon Clark for CALSCH group > > 1. Integration of BEEP into CAP We are going ahead with this. It was proposed a while ago and there have been no objections. We hope to have something ready for review by next month. > > 2. Internationalization - impact on CAP Are there any impacts on CAP? Perhaps the impacts are only at the data level, i.e., iCalendar? > > 3. Update CAP draft for BEEP changes (re-number again?) Any update to an internet draft involves its number being incremented. > > 4. Status of CAP re IETF in general (still Internet Draft?) Yes, its still an internet draft. We are working on a last call. > > 5. Impact of XML discussions on CAP (does it? would it? should it?) As far as I know, there have been no such discussions. We are too close to last call. > > 6. Solidify proposed iCalendar changes for integration into next draft of > iCalendar Yes, we need to compile a list of these changes. Its on the issues list. George > > Shannon J. Clark > President, JigZaw, Inc > 1.800.4.JIGZAW (454.4929) > shannon@jigzaw.com > www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 21:18:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02343 for ; Mon, 29 Oct 2001 21:18:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U21wo23515 for ietf-calendar-bks; Mon, 29 Oct 2001 18:01:58 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U21u823511 for ; Mon, 29 Oct 2001 18:01:56 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id TAA13805; Mon, 29 Oct 2001 19:58:27 -0600 From: "Shannon J. Clark" To: "George Babics" Cc: Subject: RE: Issues list - CAP Oct 29th, 2001 Date: Mon, 29 Oct 2001 20:01:22 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3BDE0869.73D8888E@steltor.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit George, Thanks - glad to see that. A few suggestions. One - can we link directly to the Issues list from the CALSCH main page - the issues list is somewhat buried (I thought that IETF Documents meant - "link to the IETF's website") Two - I think that a date on the Issues list (and perhaps on each issue) would be helpful. Both as an indication that the list is "up-to-date" and as a reminder that some issues have been pending for a very long time (see "Add CAP changes to iCalendar" for an example) Three - if we get the mechanics of maintaining Issues lists clarified, cleaned up, and more scripted than at present - I would suggest that the maintainers of each list exchange best practices, tools, etc and start using the same visual format, layout, and notes - should help drive action forward. Shannon -----Original Message----- From: George Babics [mailto:georgeb@steltor.com] Sent: Monday, October 29, 2001 7:55 PM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: Re: Issues list - CAP Oct 29th, 2001 There is up to date CAP issues list at the calsch.org web site: http://calsch.org/ietf/cap-ToDo.txt George "Shannon J. Clark" wrote: > > This is a start at a separate issues list for CAP. This needs to be extended > and added to, numbering is started as of today and reflects no specific > ordering. There are likely MANY typo type issues missing from this list. > > Issues - summary on Oct 29th, 2001 > by Shannon Clark for CALSCH group > > 1. Integration of BEEP into CAP > > 2. Internationalization - impact on CAP > > 3. Update CAP draft for BEEP changes (re-number again?) > > 4. Status of CAP re IETF in general (still Internet Draft?) > > 5. Impact of XML discussions on CAP (does it? would it? should it?) > > 6. Solidify proposed iCalendar changes for integration into next draft of > iCalendar > > Shannon J. Clark > President, JigZaw, Inc > 1.800.4.JIGZAW (454.4929) > shannon@jigzaw.com > www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 21:36:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03521 for ; Mon, 29 Oct 2001 21:36:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U2J1j24039 for ietf-calendar-bks; Mon, 29 Oct 2001 18:19:01 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U2J0824035 for ; Mon, 29 Oct 2001 18:19:00 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id VAA03185; Mon, 29 Oct 2001 21:18:56 -0500 Received: from steltor.com ([101.0.0.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9U2IoH19951; Mon, 29 Oct 2001 21:18:51 -0500 (EST) Message-ID: <3BDE0E60.9F4DF72D@steltor.com> Date: Mon, 29 Oct 2001 21:20:16 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" CC: ietf-calendar@imc.org Subject: Re: Issues list - CAP Oct 29th, 2001 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > George, > > Thanks - glad to see that. > > A few suggestions. > > One - can we link directly to the Issues list from the CALSCH main page - > the issues list is somewhat buried (I thought that IETF Documents meant - > "link to the IETF's website") I'll change the links name. The link points to various calsched documents. > > Two - I think that a date on the Issues list (and perhaps on each issue) > would be helpful. Both as an indication that the list is "up-to-date" and as > a reminder that some issues have been pending for a very long time (see "Add > CAP changes to iCalendar" for an example) Good idea. I'll add a date to all the new issues and add the date the document was last updated. > > Three - if we get the mechanics of maintaining Issues lists clarified, > cleaned up, and more scripted than at present - I would suggest that the > maintainers of each list exchange best practices, tools, etc and start using > the same visual format, layout, and notes - should help drive action > forward. What do you want to script? I simply use a text editor and send an e-mail out the the mailing list whenever the document is updated. I am not sure I see a real value in having the same format and layout. George > > Shannon > > -----Original Message----- > From: George Babics [mailto:georgeb@steltor.com] > Sent: Monday, October 29, 2001 7:55 PM > To: Shannon J. Clark > Cc: ietf-calendar@imc.org > Subject: Re: Issues list - CAP Oct 29th, 2001 > > There is up to date CAP issues list at the calsch.org web site: > > http://calsch.org/ietf/cap-ToDo.txt > > George > > "Shannon J. Clark" wrote: > > > > This is a start at a separate issues list for CAP. This needs to be > extended > > and added to, numbering is started as of today and reflects no specific > > ordering. There are likely MANY typo type issues missing from this list. > > > > Issues - summary on Oct 29th, 2001 > > by Shannon Clark for CALSCH group > > > > 1. Integration of BEEP into CAP > > > > 2. Internationalization - impact on CAP > > > > 3. Update CAP draft for BEEP changes (re-number again?) > > > > 4. Status of CAP re IETF in general (still Internet Draft?) > > > > 5. Impact of XML discussions on CAP (does it? would it? should it?) > > > > 6. Solidify proposed iCalendar changes for integration into next > draft of > > iCalendar > > > > Shannon J. Clark > > President, JigZaw, Inc > > 1.800.4.JIGZAW (454.4929) > > shannon@jigzaw.com > > www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 21:50:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03617 for ; Mon, 29 Oct 2001 21:50:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U2S9J24250 for ietf-calendar-bks; Mon, 29 Oct 2001 18:28:09 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U2S7824244 for ; Mon, 29 Oct 2001 18:28:07 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id UAA13856; Mon, 29 Oct 2001 20:24:38 -0600 From: "Shannon J. Clark" To: "George Babics" Cc: Subject: RE: Issues list - CAP Oct 29th, 2001 Date: Mon, 29 Oct 2001 20:27:32 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3BDE0E60.9F4DF72D@steltor.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit George, Great - glad my suggestions are helpful. In terms of having the issues in the same (or at least similar) format - my thought would be that for people trying to navigate/orient through the collected standards it would be helpful to know how to move between the issues list, the mailing list, and the documents. If we created tools that made it easy to link the issues list to specific emails for example - I would think that they would be helpful to each document's editors. In fact I am slightly surprised that there isn't already an IETF (perhaps there is?) set of best practices and tools with regard to handling issues lists/corrections/suggestions/changes to drafts - seems like something every working group struggles with. Shannon -----Original Message----- From: George Babics [mailto:georgeb@steltor.com] Sent: Monday, October 29, 2001 8:20 PM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: Re: Issues list - CAP Oct 29th, 2001 "Shannon J. Clark" wrote: > > George, > > Thanks - glad to see that. > > A few suggestions. > > One - can we link directly to the Issues list from the CALSCH main page - > the issues list is somewhat buried (I thought that IETF Documents meant - > "link to the IETF's website") I'll change the links name. The link points to various calsched documents. > > Two - I think that a date on the Issues list (and perhaps on each issue) > would be helpful. Both as an indication that the list is "up-to-date" and as > a reminder that some issues have been pending for a very long time (see "Add > CAP changes to iCalendar" for an example) Good idea. I'll add a date to all the new issues and add the date the document was last updated. > > Three - if we get the mechanics of maintaining Issues lists clarified, > cleaned up, and more scripted than at present - I would suggest that the > maintainers of each list exchange best practices, tools, etc and start using > the same visual format, layout, and notes - should help drive action > forward. What do you want to script? I simply use a text editor and send an e-mail out the the mailing list whenever the document is updated. I am not sure I see a real value in having the same format and layout. George > > Shannon > > -----Original Message----- > From: George Babics [mailto:georgeb@steltor.com] > Sent: Monday, October 29, 2001 7:55 PM > To: Shannon J. Clark > Cc: ietf-calendar@imc.org > Subject: Re: Issues list - CAP Oct 29th, 2001 > > There is up to date CAP issues list at the calsch.org web site: > > http://calsch.org/ietf/cap-ToDo.txt > > George > > "Shannon J. Clark" wrote: > > > > This is a start at a separate issues list for CAP. This needs to be > extended > > and added to, numbering is started as of today and reflects no specific > > ordering. There are likely MANY typo type issues missing from this list. > > > > Issues - summary on Oct 29th, 2001 > > by Shannon Clark for CALSCH group > > > > 1. Integration of BEEP into CAP > > > > 2. Internationalization - impact on CAP > > > > 3. Update CAP draft for BEEP changes (re-number again?) > > > > 4. Status of CAP re IETF in general (still Internet Draft?) > > > > 5. Impact of XML discussions on CAP (does it? would it? should it?) > > > > 6. Solidify proposed iCalendar changes for integration into next > draft of > > iCalendar > > > > Shannon J. Clark > > President, JigZaw, Inc > > 1.800.4.JIGZAW (454.4929) > > shannon@jigzaw.com > > www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Oct 29 22:50:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05160 for ; Mon, 29 Oct 2001 22:50:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U3VfM25539 for ietf-calendar-bks; Mon, 29 Oct 2001 19:31:41 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U3Ve825535 for ; Mon, 29 Oct 2001 19:31:40 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KA2L0RTKI80013KR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-calendar@imc.org; Mon, 29 Oct 2001 19:31:41 -0800 (PST) Date: Mon, 29 Oct 2001 19:29:17 -0800 (PST) From: ned+ietf-calendar@mrochek.com Subject: Re: Issues list - CAP Oct 29th, 2001 In-reply-to: "Your message dated Mon, 29 Oct 2001 21:01:27 -0500" <3BDE09F7.CB5B924A@steltor.com> To: George Babics Cc: "Shannon J. Clark" , ietf-calendar@imc.org Message-id: <01KA32730GQE0013KR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > 1. Integration of BEEP into CAP > We are going ahead with this. It was proposed a while ago and > there have been no objections. We hope to have something ready for > review by next month. I suppose it isn't surprising that I support this since I specifically brought it up at the London meeting, but in any case I thought I should say that I'm delighted to hear this is happening. Ned From owner-ietf-calendar@mail.imc.org Tue Oct 30 07:31:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25695 for ; Tue, 30 Oct 2001 07:31:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UBqor09063 for ietf-calendar-bks; Tue, 30 Oct 2001 03:52:50 -0800 (PST) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UBqn809058 for ; Tue, 30 Oct 2001 03:52:49 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 30 Oct 2001 11:52:28 +0000 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 15yXOu-0005Br-00 for ietf-calendar@imc.org; Tue, 30 Oct 2001 11:49:48 +0000 Date: Tue, 30 Oct 2001 11:49:48 +0000 (GMT) From: Libby Miller X-Sender: ecemm@mail.ilrt.bris.ac.uk To: ietf-calendar@imc.org Subject: RE: Events schema (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: forwarded at Shannon's request. -----Original Message----- From: www-rdf-calendar-request@w3.org [mailto:www-rdf-calendar-request@w3.org]On Behalf Of Libby Miller Sent: Monday, October 29, 2001 5:00 PM To: Judith Pearce Cc: DC-GENERAL@JISCMAIL.AC.UK; www-rdf-calendar@w3.org; rss-dev@yahoogroups.com Subject: Re: Events schema [sorry about the cross-post] hi Judith, We've been working on something that sounds like what you want in the rdf calendar taskforce [1][2]. We have a draft version of icalendar [3], the main standard for calendaring, in RDF [4], and I've started to separate out this very long schema into sections, to make it easier for people to use. There's a very draft "core" set of properties and classes [5] as an experiment to see if these are useful as a group. They could be used in an rss 1.0 channel for example [6]. I've done some content examples for various conferences [7] illustrating how different namespaces could be combined for describing calendar events, but note that the schema is in flux and may not be consistent. Relatedly, there is also an XML DTD for icalendar [8], and for a simpler rss channel version see the proposed rss events module [9]. I hope this helps - I'd be interested to know what you think. all the best Libby Miller [1] www-rdf-calendar@w3.org [2] http://ilrt.org/discovery/2001/04/calendar [3] http://www.imc.org/rfc2445 [4] http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf [5] http://ilrt.org/discovery/2001/10/cal-drafts/cal-core.rdf [6] http://swordfish.rdfweb.org/discovery/2001/10/rss-cal/ [7] http://ilrt.org/discovery/2001/06/content/ [8] http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-00.txt [9] http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_event.html On Fri, 19 Oct 2001, Judith Pearce wrote: > I've asked this question before, but I'm still looking for a simple schema > for describing events. I know from previous responses that there's great > work going on in relation to event modelling but I'm after something much > more basic - data elements for describing human events - seminars, meetings, > exhibitions, projects. MARC21 has a format for community information but it > is too rich. We need something simpler in terms of data element choices but > with the granularity to interface with other scheduling systems. > > As an example of an application where such a schema would be useful see > http://www.nla.gov.au/apps/events/. This is generated from a database for > which we have our own internal schema but we would like to start exchanging > information about events with other cultural organisations - eg - to provide > combined calendars of events. > > There are some calendar standards but they tend to focus on standards for > exchanging date/time information rather than information about the events > themselves - eg. agents having a role in relation to the event, location, > description, etc. > > People are also using DC to describe events - and that's fine if you want to > describe a mixture of resources, events, services, etc on a website using a > single metadata standard - but it doesn't extend to address this need. > > > > > Judith Pearce > Director, Web Services > National Library of Australia > CANBERRA ACT 2601 > Australia > > Phone: +61 2 62621425 > Fax: +61 2 6273 3648 > Email: jpearce@nla.gov.au > NLA Web Site: http://www.nla.gov.au > From owner-ietf-calendar@mail.imc.org Tue Oct 30 09:21:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01047 for ; Tue, 30 Oct 2001 09:21:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UDwHm15771 for ietf-calendar-bks; Tue, 30 Oct 2001 05:58:17 -0800 (PST) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UDwF815767 for ; Tue, 30 Oct 2001 05:58:15 -0800 (PST) Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.140.169.29]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 27BD3E3; Tue, 30 Oct 2001 14:57:50 +0100 (MET) Received: from isar.bbn.hp.com (isar.bbn.hp.com [15.140.168.13]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id OAA18297; Tue, 30 Oct 2001 14:58:13 +0100 (MET) Received: from 15.140.168.13 by isar.bbn.hp.com (InterScan E-Mail VirusWall NT); Tue, 30 Oct 2001 14:58:12 +0100 (W. Europe Standard Time) Received: by isar.bbn.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Oct 2001 14:58:12 +0100 Message-ID: From: "NITSCH,FRANK (HP-Germany,ex1)" To: "'John Stracke'" , ietf-calendar@imc.org Subject: RE: What should the xCal tag names case be? Date: Tue, 30 Oct 2001 14:58:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > I believe > > research has shown that mixed case is easier to read. Well, reading a book is of course easier than reading C code... ;-) > That certainly accords with my own experience. People who > SHOUT, or who > type everything in lower case, are harder to read. Mixed > case gives your > eyes clues as they parse along. You should take into account that coding XML by hand will be much less error-prone if everything is either lower or upper case. However I agree that upper case is not really a desired option... It looks just annoying and using Shift or Caps Lock all the time is also a hassle for those who type xCal by hand. If you now think that coding xCal by hand is not an important use-case I'd like to ask you: who do you think should read raw XML? What's the most important issue the decision should be based on? Is it a developer who want's to verify the output of his GUI by inspecting the XML source or a developer who constructs a test xCal event in XML in his ASCII editor? For whose "ease of use" do we make this decision? BTW: I'd vote for all lower case! ;-) Regards Frank