From owner-ietf-calendar@mail.imc.org Sat Apr 1 10:56:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09967 for ; Sat, 1 Apr 2000 10:56:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21524 for ietf-calendar-bks; Sat, 1 Apr 2000 07:38:45 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21520 for ; Sat, 1 Apr 2000 07:38:44 -0800 (PST) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA20457; Sat, 1 Apr 2000 10:57:44 -0500 (EST) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA04474; Sat, 1 Apr 2000 10:40:55 -0500 (EST) To: "Paul B. Hill" Cc: ietf-calendar@imc.org Subject: Re: Some notes on SASL X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Fri, 1 Apr 1988 10:38:02 -0500 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/01/2000 10:38:04 AM, Serialize complete at 04/01/2000 10:38:04 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0056734085255795_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056734085255795_= Content-Type: text/plain; charset="us-ascii" Paul: Thanks for the "health warning" ;-) -- Frank --=_alternative 0056734085255795_= Content-Type: text/html; charset="us-ascii"
Paul:

Thanks for the "health warning" ;-)

-- Frank --=_alternative 0056734085255795_=-- From owner-ietf-calendar@mail.imc.org Sun Apr 2 04:17:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23285 for ; Sun, 2 Apr 2000 04:17:49 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA00466 for ietf-calendar-bks; Sat, 1 Apr 2000 23:57:33 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00457 for ; Sat, 1 Apr 2000 23:57:30 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA11218 for ietf-calendar@imc.org; Sun, 2 Apr 2000 00:00:06 -0800 (PST) Date: Sun, 2 Apr 2000 00:00:06 -0800 (PST) From: Doug Royer Message-Id: <200004020800.AAA11218@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM ? Y ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@mail.imc.org Tue Apr 4 15:22:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13313 for ; Tue, 4 Apr 2000 15:22:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02747 for ietf-calendar-bks; Tue, 4 Apr 2000 11:44:52 -0700 (PDT) Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02743 for ; Tue, 4 Apr 2000 11:44:51 -0700 (PDT) Received: from ebusboom3 (ebusboom3.qualcomm.com [129.46.69.207]) by mail1.qualcomm.com (8.9.3/8.9.3/1.0) with SMTP id LAA21010; Tue, 4 Apr 2000 11:47:43 -0700 (PDT) Message-Id: <4.1.20000404111110.018fd220@donelly.qualcomm.com> X-Sender: ebusboom@donelly.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 04 Apr 2000 11:46:50 -0800 To: ietf-calendar@imc.org, libical@softwarestudio.org, facs@softwarestudio.org From: Eric Busboom Subject: iMIP demo server is online 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: alice@cal.softwarestudio.org is an iMIP-based CUA that will accept event REQUEST and PUBLISH messages and book them on her calendar. This server is intended for public testing. THIS IS AN ALPHA-QUALITY SYSTEM. Only the most basic cases work. You can try to break it ( please do! ) but you should only expect common things to work. Current restrictions include: One component per message. Only handles REQUEST and PUBLISH for VEVENTS Several errors in backslashing ';' REQUEST-STATUS are basically correct but not exact. All parsing and iTIP errors are fatal. Poor handling of time and timezones. Many, many more. To use the system, send one of the iMIP messages used as examples in rfc2446. Remember to: Set the To: header on the email and one ATTENDEE property to "alice@cal.softwarestudio.org" Set the From: and the ORGANIZER property to your email address. The system will send error responses immediately ( iTIP violations or parsing errors ) and will processes well-formed incoming messages every 2 minutes. I've been composing the messages in text and running "cat | /usr/lib/sendmail -t" on my UNIX machine. This service is mostly a test for my Open Source implementations of the iCal standards. There is a C library, libical, and a perl Module, Net::ICal. See http://www.softwarestudio.org/libical for more information, and go to ftp://ftp.softwarestudio.org/pub/studio2/ for the latest releases of the libraries. One use for the system is to verify iTIP conformance. If the component you send has any parse errors or violates iTIP restrictions in rfc2446, the system will send back and error message. If you trust the libical parser ( and you should not ) you can use this to validate components. eric. From owner-ietf-calendar@mail.imc.org Wed Apr 5 21:34:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18890 for ; Wed, 5 Apr 2000 21:34:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12800 for ietf-calendar-bks; Wed, 5 Apr 2000 18:13:39 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA12792 for ; Wed, 5 Apr 2000 18:13:37 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 Apr 2000 18:16:15 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id <2LKC3ASG>; Wed, 5 Apr 2000 18:16:16 -0700 Message-ID: <33D189919E89D311814C00805F1991F7E3B5F0@RED-MSG-08> From: Katia Hage To: "'ietf-calendar@imc.org'" Subject: CalConnect Payment Date: Wed, 5 Apr 2000 18:16:14 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Do we need to pay the registration fee in advance, or when we get there? Thanks. Katia From owner-ietf-calendar@mail.imc.org Sat Apr 8 16:52:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14560 for ; Sat, 8 Apr 2000 16:52:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05365 for ietf-calendar-bks; Sat, 8 Apr 2000 13:28:57 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05361 for ; Sat, 8 Apr 2000 13:28:56 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id OAA01976 for ; Sat, 8 Apr 2000 14:53:47 -0400 Message-ID: <38EF803B.610B30BE@ecal.com> Date: Sat, 08 Apr 2000 14:53:47 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Interesting Patent References: <386A9318.1825A3BB@ecal.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 In December, John Stracke wrote: > pregen@egenconsulting.com wrote: > > > John (Stracke), do you have some feedback you can share with us on this patent. > > Let me go talk to the lawyers... ...they still haven't given me anything I can say publicly, and I don't think they will. Broadly speaking, I've been hearing the usual sort of lawyer concern: even if you don't plan to enforce your patent, you might later; and, if you file suit, anything you said in the past can be used against you; so, either way, you keep your mouth shut. (I don't think I've heard all of this from our lawyers; this is a pastiche of things I've heard from various patent lawyers over the years.) I don't much like it, but I have go along with it. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"If nobody believes what I say, I feel | |francis@ecal.com|ineffective." "Oh, I don't believe that." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Sun Apr 9 03:14:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01479 for ; Sun, 9 Apr 2000 03:14:26 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA12313 for ietf-calendar-bks; Sat, 8 Apr 2000 23:56:57 -0700 (PDT) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA12306 for ; Sat, 8 Apr 2000 23:56:55 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA16375 for ietf-calendar@imc.org; Sun, 9 Apr 2000 00:00:05 -0700 (PDT) Date: Sun, 9 Apr 2000 00:00:05 -0700 (PDT) From: Doug Royer Message-Id: <200004090700.AAA16375@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM ? Y ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@mail.imc.org Mon Apr 10 12:35:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23191 for ; Mon, 10 Apr 2000 12:35:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17064 for ietf-calendar-bks; Mon, 10 Apr 2000 09:11:37 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17060 for ; Mon, 10 Apr 2000 09:11:35 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA25165 for ; Mon, 10 Apr 2000 12:31:31 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA07749 for ; Mon, 10 Apr 2000 12:14:32 -0400 (EDT) Subject: Re: CALSCH Action Items - - Error To: Doug Royer Cc: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Sun, 10 Apr 1988 12:11:08 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/10/2000 12:11:09 PM 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: Doug: The following item belongs as an assignment to the iMIP editors. Yet it says "Frank". I don't understand what is meant. Can you clarify? I-1 MIME alternate/related Frank ? MUST be supported. This was clearly an iMIP related clarification, not an iCalendar one. Do all you agree? -- Frank From owner-ietf-calendar@mail.imc.org Mon Apr 10 13:04:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25112 for ; Mon, 10 Apr 2000 13:04:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17785 for ietf-calendar-bks; Mon, 10 Apr 2000 09:47:17 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17781 for ; Mon, 10 Apr 2000 09:47:16 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000410165009.QLRA851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Mon, 10 Apr 2000 11:50:09 -0500 Message-ID: <38F1F72C.26BD5D35@Software.com> Date: Mon, 10 Apr 2000 08:45:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error 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 Frank_Dawson@lotus.com wrote: > > Doug: > The following item belongs as an assignment to the iMIP editors. Yet it > says "Frank". I don't understand what is meant. Can you clarify? > > I-1 MIME alternate/related Frank ? > MUST be supported. > > This was clearly an iMIP related clarification, not an iCalendar one. > > Do all you agree? An ATTACH can contain a MID or CID URI, so it applies to iCal. And iCal says that an iCal object is a MIME object. And I think we (WG) had agreed that ical MUST required it (around Chicago time frame), then all protocols using iCal MUST support it. Including iMIP and CAP. As I recall, it was discovered by informal interop testing between Lotus and Microsoft. And it was seen as a flaw in iCal. I think we want ALL iCal protocols to be able to understand multipart/related, multipart/mixed, and multipart/alternate (all known multipart/* MIME objects). -Doug From owner-ietf-calendar@mail.imc.org Mon Apr 10 14:24:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29014 for ; Mon, 10 Apr 2000 14:24:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19498 for ietf-calendar-bks; Mon, 10 Apr 2000 11:05:41 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA19494 for ; Mon, 10 Apr 2000 11:05:40 -0700 (PDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Apr 2000 11:08:44 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id <2LBGK1JT>; Mon, 10 Apr 2000 11:08:43 -0700 Message-ID: <7CD674FF54FBD21181D800805F57CD540C89BD51@RED-MSG-44> From: Katia Hage To: "'ietf-calendar@imc.org'" Subject: Room name Date: Mon, 10 Apr 2000 11:08:39 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am not sure if it was mentioned before, but what is the room name for the CalConnect meeting? Thanks. Katia From owner-ietf-calendar@mail.imc.org Mon Apr 10 14:34:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29453 for ; Mon, 10 Apr 2000 14:34:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19625 for ietf-calendar-bks; Mon, 10 Apr 2000 11:14:24 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA19621 for ; Mon, 10 Apr 2000 11:14:22 -0700 (PDT) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA24377; Mon, 10 Apr 00 14:19:40 EDT Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id OAA12750; Mon, 10 Apr 2000 14:17:49 -0400 (EDT) Received: from [18.177.1.27] (MAUI.MIT.EDU [18.177.1.27]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id OAA14646; Mon, 10 Apr 2000 14:17:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: bobmah@18.69.0.43 Message-Id: In-Reply-To: <7CD674FF54FBD21181D800805F57CD540C89BD51@RED-MSG-44> References: <7CD674FF54FBD21181D800805F57CD540C89BD51@RED-MSG-44> Date: Mon, 10 Apr 2000 14:17:26 -0400 To: Katia Hage From: Bob Mahoney Subject: Re: Room name Cc: "'ietf-calendar@imc.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Katia- We're going to be in E40-302 ("The Visitor's Center") This map should show where E40 is: http://whereis.mit.edu/bin/map?state=0&pri.x=411&pri.y=135 The sign over the front door says "Muckley Building". -Bob At 11:08 AM -0700 4/10/00, Katia Hage wrote: >I am not sure if it was mentioned before, but what is the room name for the >CalConnect meeting? Thanks. > >Katia From owner-ietf-calendar@mail.imc.org Mon Apr 10 14:35:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29520 for ; Mon, 10 Apr 2000 14:35:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19709 for ietf-calendar-bks; Mon, 10 Apr 2000 11:17:20 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19705 for ; Mon, 10 Apr 2000 11:17:19 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA07764; Mon, 10 Apr 2000 14:37:11 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA22919; Mon, 10 Apr 2000 14:20:05 -0400 (EDT) To: Doug.Royer@software.com Cc: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Mon, 10 Apr 2000 14:16:37 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/10/2000 02:16:44 PM, Serialize complete at 04/10/2000 02:16:44 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005FC343852568BD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005FC343852568BD_= Content-Type: text/plain; charset="us-ascii" >As I recall, it was discovered by informal interop testing between >Lotus and Microsoft. And it was seen as a flaw in iCal. Yes, but to be clear it was informal interop testing of iMIP. This is an iMIP issue, not an issue with the iCalendar spec. -- Frank --=_alternative 005FC343852568BD_= Content-Type: text/html; charset="us-ascii"
>As I recall, it was discovered by informal interop testing between
>Lotus and Microsoft. And it was seen as a flaw in iCal.

Yes, but to be clear it was informal interop testing of iMIP.

This is an iMIP issue, not an issue with the iCalendar spec.

-- Frank --=_alternative 005FC343852568BD_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 10 14:36:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29560 for ; Mon, 10 Apr 2000 14:36:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19669 for ietf-calendar-bks; Mon, 10 Apr 2000 11:15:55 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19665 for ; Mon, 10 Apr 2000 11:15:54 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA07424; Mon, 10 Apr 2000 14:35:49 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA22530; Mon, 10 Apr 2000 14:18:49 -0400 (EDT) To: Doug.Royer@software.com Cc: ietf-calendar@imc.org, deriks@microsoft.com Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Mon, 10 Apr 2000 14:15:22 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/10/2000 02:15:25 PM, Serialize complete at 04/10/2000 02:15:25 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005FA5D5852568BD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005FA5D5852568BD_= Content-Type: text/plain; charset="us-ascii" Doug: At the IETF meeting (may in Chicago as you suggest, but I think it was Oslo) we discussed errors to iCalendar/iTIP/iMIP. This error was in iMIP. iCalendar, RFC 2445, just defines a MIME type. This is NOT the place to specify how you encapsulate the MIME type. We just define here a text/calendar MIME content type. It is iMIP, RFC 2447, that defines how you send an iCalendar object in email. That email could be as a singleton, text/calendar MIME object or as a multipart object, such as multipart/mixed or such. This is where the requirement is absent. I suggest that we all go back and read the RFC 2447 spec. This is the one that specifies how you need to package the text/calendar object. This is where it currently only REQUIRES support for text/calendar and needs to also specify that you MUST be able to receive the text/calendar within a multipart/mixed. I strongly disagree that this needs to be added as a requirement in iCalendar, which is only the specification of a C&S content-type. -- Frank --=_alternative 005FA5D5852568BD_= Content-Type: text/html; charset="us-ascii"
Doug:

At the IETF meeting (may in Chicago as you suggest, but I think it was Oslo) we discussed errors to iCalendar/iTIP/iMIP. This error was in iMIP.

iCalendar, RFC 2445, just defines a MIME type. This is NOT the place to specify how you encapsulate the MIME type. We just define here a text/calendar MIME content type.

It is iMIP, RFC 2447, that defines how you send an iCalendar object in email. That email could be as a singleton, text/calendar MIME object or as a multipart object, such as multipart/mixed or such. This is where the requirement is absent. I suggest that we all go back and read the RFC 2447 spec. This is the one that specifies how you need to package the text/calendar object. This is where it currently only REQUIRES support for text/calendar and needs to also specify that you MUST be able to receive the text/calendar within a multipart/mixed.

I strongly disagree that this needs to be added as a requirement in iCalendar, which is only the specification of a C&S content-type.

-- Frank

--=_alternative 005FA5D5852568BD_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 10 14:56:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00120 for ; Mon, 10 Apr 2000 14:56:28 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA20205 for ietf-calendar-bks; Mon, 10 Apr 2000 11:36:58 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20201 for ; Mon, 10 Apr 2000 11:36:56 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000410183955.QPIA851310.mta1biz.bizmailsrvcs.net@Software.com>; Mon, 10 Apr 2000 13:39:55 -0500 Message-ID: <38F210DF.D3F45868@Software.com> Date: Mon, 10 Apr 2000 10:35:27 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: ietf-calendar@imc.org, deriks@microsoft.com Subject: Re: CALSCH Action Items - - Error References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms688A71713E869832C83D59AB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms688A71713E869832C83D59AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > > Doug: > > At the IETF meeting (may in Chicago as you suggest, but I think it was Oslo) > we discussed errors to iCalendar/iTIP/iMIP. This error was in iMIP. > > iCalendar, RFC 2445, just defines a MIME type. This is NOT the place to > specify how you encapsulate the MIME type. We just define here a > text/calendar MIME content type. iCalendar specifically supports CID's and MID's, from RFC2445: If iCal specifies CID's, then iCal MUST mandate multipart/* ? And it did not. I do understand that it was iMIP interop testing. That is the only current interoperability protocol. However the CID/MID issue is an iCalendar issue, below are excerpts from RFC2445. >From various parts of RFC2445: DESCRIPTION;ALTREP="CID:":Project XYZ Review Meeting will include the following agenda items: (a) Market Overview, (b) Finances, (c) Project Management ... ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com ... Description: Specific venues such as conference or meeting rooms may be explicitly specified using this property. An alternate representation may be specified that is a URI that points to directory information with more structured specification of the location. For example, the alternate representation may specify either an LDAP URI pointing to an LDAP server entry or a CID URI pointing to a MIME body part containing a vCard [RFC 2426] for the location. ... The following is an example of this property with an alternate representation of a MIME body part containing the contact information, such as a vCard [RFC 2426] embedded in a [MIME-DIR] content-type: CONTACT;ALTREP="CID=":Jim Dolittle\, ABC Industries, +1-919-555-1234 > It is iMIP, RFC 2447, that defines how you send an iCalendar object in email. > That email could be as a singleton, text/calendar MIME object or as a > multipart object, such as multipart/mixed or such. This is where the > requirement is absent. I suggest that we all go back and read the RFC 2447 > spec. This is the one that specifies how you need to package the > text/calendar object. This is where it currently only REQUIRES support for > text/calendar and needs to also specify that you MUST be able to receive the > text/calendar within a multipart/mixed. > > I strongly disagree that this needs to be added as a requirement in > iCalendar, which is only the specification of a C&S content-type. > > -- Frank --------------ms688A71713E869832C83D59AB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQxMDE3MzUzMFowIwYJKoZIhvcNAQkEMRYEFChL6jN0pASdhv3cv2jGI+gJ7JaC MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEAFJiuEhibT 8yzHgtQWO1IaXm+d1P3EWq0FNSFb2SGfND5P+yAQhHmGtqLpcFIRElSl8QCahNUH6354a/RO yt4a --------------ms688A71713E869832C83D59AB-- From owner-ietf-calendar@mail.imc.org Mon Apr 10 15:33:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01236 for ; Mon, 10 Apr 2000 15:33:46 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA21102 for ietf-calendar-bks; Mon, 10 Apr 2000 12:13:15 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21098 for ; Mon, 10 Apr 2000 12:13:13 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA15326 for ; Mon, 10 Apr 2000 15:33:09 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA28431 for ; Mon, 10 Apr 2000 14:55:59 -0400 (EDT) To: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Mon, 10 Apr 2000 14:52:31 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/10/2000 02:52:35 PM, Serialize complete at 04/10/2000 02:52:35 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00630CC3852568BD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00630CC3852568BD_= Content-Type: text/plain; charset="us-ascii" Doug: The support for multipart comes in when we begin to talk about interoperability of the scheduling semantics over email. This is where we ran into the problem between Lotus Organizer and Microsoft Outlook. I was the one who reported it. At one of the IETF meetings we addressed this under the discuss of errata against iMIP, not iCalendar. It was decided there that a change was needed to the iMIP spec. Please change it in your "Action Items" document to an iMIP related bug. The iCalendar spec interoperates fine without it, but the iMIP spec doesn't. The fact that the ATTACH property and the ALTREP parameter _can_ specify a CID or MID URI (as specified only in examples) for the URI based value doesn't mandate that an iCalendar implement MUST support multipart MIME entities. Indeed, the MID URI for an ATTACH property could specify an message identifier external to the current message. The standard specifies that the value is either a URI (which could be other URI types than a CID or MID) or an inline binary value. ALTREP is a URI value. Most probably NOT a CID or MID URI but more likely a HTTP URI. In fact, an iCalendar CUA is very likely to support inlined attachments and HTTP type URIs for alternate representation of text content. It is a big jump to say that all iCalendar implementations MUST support multipart. In fact an implementation that is using iCalendar for import/export won't be doing this. The point is that many implementations will conform to the RFC2445 just as a content definition. -- Frank --=_alternative 00630CC3852568BD_= Content-Type: text/html; charset="us-ascii"
Doug:

The support for multipart comes in when we begin to talk about interoperability of the scheduling semantics over email. This is where we ran into the problem between Lotus Organizer and Microsoft Outlook. I was the one who reported it.

At one of the IETF meetings we addressed this under the discuss of errata against iMIP, not iCalendar. It was decided there that a change was needed to the iMIP spec.

Please change it in your "Action Items" document to an iMIP related bug. The iCalendar spec interoperates fine without it, but the iMIP spec doesn't.

The fact that the ATTACH property and the ALTREP parameter _can_ specify a CID or MID URI (as specified only in examples) for the URI based value doesn't mandate that an iCalendar implement MUST support multipart MIME entities. Indeed, the MID URI for an ATTACH property could specify an message identifier external to the current message. The standard specifies that the value is either a URI (which could be other URI types than a CID or MID) or an inline binary value. ALTREP is a URI value. Most probably NOT a CID or MID URI but more likely a HTTP URI.

In fact, an iCalendar CUA is very likely to support inlined attachments and HTTP type URIs for alternate representation of text content.

It is a big jump to say that all iCalendar implementations MUST support multipart. In fact an implementation that is using iCalendar for import/export won't be doing this. The point is that many implementations will conform to the RFC2445 just as a content definition.

-- Frank

--=_alternative 00630CC3852568BD_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 10 16:58:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04209 for ; Mon, 10 Apr 2000 16:58:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22352 for ietf-calendar-bks; Mon, 10 Apr 2000 13:35:53 -0700 (PDT) Received: from capricorn.iris.com (capricorn.iris.com [198.112.211.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22347 for ; Mon, 10 Apr 2000 13:35:43 -0700 (PDT) From: Bruce_Kahn@iris.com To: Frank_Dawson@lotus.com Cc: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Mon, 10 Apr 2000 16:36:45 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_M2_03122000|March 12, 2000) at 04/10/2000 04:39:21 PM, Serialize complete at 04/10/2000 04:39:21 PM 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: Frank proposed: >ALTREP is a URI value. Most probably NOT a CID or MID URI but more likely a HTTP URI. Actually the converse is probably true here. If I have DESCRIPTION with an ALTREP Im VERY LIKELY going to put it into the same message as another MIME body part, NOT in a separate email that may get there in a different order (where it could be a non-sequeteur to the recipient!). 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... From owner-ietf-calendar@mail.imc.org Wed Apr 12 10:53:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23157 for ; Wed, 12 Apr 2000 10:53:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07454 for ietf-calendar-bks; Wed, 12 Apr 2000 07:20:02 -0700 (PDT) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07449 for ; Wed, 12 Apr 2000 07:19:54 -0700 (PDT) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: Question for list X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Wed, 12 Apr 2000 10:23:07 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 04/12/2000 10:23:34 AM, Serialize complete at 04/12/2000 10:23:34 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004F02D8852568BF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004F02D8852568BF_= Content-Type: text/plain; charset="us-ascii" During interoperability testing the following question has been asked. Can the list please discuss their thoughts (especially our editors). Thanks. "iCalendar says "no ORGANIZER" parameter. iTIP says "ORGANIZER" is a must." ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 004F02D8852568BF_= Content-Type: text/html; charset="us-ascii"
During interoperability testing the following question has been asked. Can the list please discuss their thoughts (especially our editors).  Thanks.

"iCalendar says "no ORGANIZER" parameter. iTIP says "ORGANIZER" is a must."

___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 004F02D8852568BF_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 10:58:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23334 for ; Wed, 12 Apr 2000 10:58:06 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA07548 for ietf-calendar-bks; Wed, 12 Apr 2000 07:24:46 -0700 (PDT) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07540 for ; Wed, 12 Apr 2000 07:24:42 -0700 (PDT) From: pregen@egenconsulting.com To: Frank_Dawson@lotus.com Cc: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Wed, 12 Apr 2000 10:28:13 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 04/12/2000 10:28:16 AM, Serialize complete at 04/12/2000 10:28:16 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004F7A9B852568BF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004F7A9B852568BF_= Content-Type: text/plain; charset="us-ascii" Frank, let me see if I understand what you and Doug are debating. Here's my example. Say we are scheduling an interoperability test in Boston. For this event, I send out calendar requests to the attendees with start and end dates and include an attachment that is a map to the facility. That now is a multipart document. All my client cares about is that it is an attachment. If I am doing this using CAP (eventually), wouldn't I want the transport mechanism to handle it (iTIP) instead of the mail transport (iMIP). In a mail message, what handles attachments today? Is it MIME, the mail client, or another protocol? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Frank_Dawson@lotus.com Sent by: owner-ietf-calendar@mail.imc.org 04/10/00 02:52 PM To: ietf-calendar@imc.org cc: Subject: Re: CALSCH Action Items - - Error Doug: The support for multipart comes in when we begin to talk about interoperability of the scheduling semantics over email. This is where we ran into the problem between Lotus Organizer and Microsoft Outlook. I was the one who reported it. At one of the IETF meetings we addressed this under the discuss of errata against iMIP, not iCalendar. It was decided there that a change was needed to the iMIP spec. Please change it in your "Action Items" document to an iMIP related bug. The iCalendar spec interoperates fine without it, but the iMIP spec doesn't. The fact that the ATTACH property and the ALTREP parameter _can_ specify a CID or MID URI (as specified only in examples) for the URI based value doesn't mandate that an iCalendar implement MUST support multipart MIME entities. Indeed, the MID URI for an ATTACH property could specify an message identifier external to the current message. The standard specifies that the value is either a URI (which could be other URI types than a CID or MID) or an inline binary value. ALTREP is a URI value. Most probably NOT a CID or MID URI but more likely a HTTP URI. In fact, an iCalendar CUA is very likely to support inlined attachments and HTTP type URIs for alternate representation of text content. It is a big jump to say that all iCalendar implementations MUST support multipart. In fact an implementation that is using iCalendar for import/export won't be doing this. The point is that many implementations will conform to the RFC2445 just as a content definition. -- Frank --=_alternative 004F7A9B852568BF_= Content-Type: text/html; charset="us-ascii"
Frank, let me see if I understand what you and Doug are debating.  Here's my example.  Say we are scheduling an interoperability test in Boston.  For this event, I send out calendar requests to the attendees with start and end dates and include an attachment that is a map to the facility.  That now is a multipart document.  All my client cares about is that it is an attachment.  If I am doing this using CAP (eventually), wouldn't I want the transport mechanism to handle it (iTIP) instead of the mail transport (iMIP).   In a mail message, what handles attachments today? Is it MIME, the mail client, or another protocol?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Frank_Dawson@lotus.com
Sent by: owner-ietf-calendar@mail.imc.org

04/10/00 02:52 PM

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: CALSCH Action Items - - Error



Doug:

The support for multipart comes in when we begin to talk about interoperability of the scheduling semantics over email. This is where we ran into the problem between Lotus Organizer and Microsoft Outlook. I was the one who reported it.

At one of the IETF meetings we addressed this under the discuss of errata against iMIP, not iCalendar. It was decided there that a change was needed to the iMIP spec.

Please change it in your "Action Items" document to an iMIP related bug. The iCalendar spec interoperates fine without it, but the iMIP spec doesn't.

The fact that the ATTACH property and the ALTREP parameter _can_ specify a CID or MID URI (as specified only in examples) for the URI based value doesn't mandate that an iCalendar implement MUST support multipart MIME entities. Indeed, the MID URI for an ATTACH property could specify an message identifier external to the current message. The standard specifies that the value is either a URI (which could be other URI types than a CID or MID) or an inline binary value. ALTREP is a URI value. Most probably NOT a CID or MID URI but more likely a HTTP URI.

In fact, an iCalendar CUA is very likely to support inlined attachments and HTTP type URIs for alternate representation of text content.

It is a big jump to say that all iCalendar implementations MUST support multipart. In fact an implementation that is using iCalendar for import/export won't be doing this. The point is that many implementations will conform to the RFC2445 just as a content definition.

-- Frank

--=_alternative 004F7A9B852568BF_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 11:03:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23544 for ; Wed, 12 Apr 2000 11:03:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA08081 for ietf-calendar-bks; Wed, 12 Apr 2000 07:41:21 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08075 for ; Wed, 12 Apr 2000 07:41:20 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA00437 for ; Wed, 12 Apr 2000 07:38:57 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FSWRM300.MN4; Wed, 12 Apr 2000 07:44:27 -0700 Message-ID: <38F48B89.EE03E87A@netscape.com> Date: Wed, 12 Apr 2000 07:43:21 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.73b1 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: pregen@egenconsulting.com CC: ietf-calendar@imc.org Subject: Re: Question for list References: Content-Type: multipart/mixed; boundary="------------0E29F7FF84BBA5FFD9FC38F8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0E29F7FF84BBA5FFD9FC38F8 Content-Type: multipart/alternative; boundary="------------82A96E083779F44D75E772F1" --------------82A96E083779F44D75E772F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > During interoperability testing the following question has been asked. > Can the list please discuss their thoughts (especially our editors). > Thanks. > > "iCalendar says "no ORGANIZER" parameter. I'm assuming you mean "property" > iTIP says "ORGANIZER" is a must." I thought we had all agreed that iCalendar simply specifies a schema, but it is up to individual protocols to specify the presence or absence of a specific property. The protocol knows best what it needs and doesn't need. That's why we did the restriction tables in iTIP. That's why we're going to do restriction tables for CAP. -Steve --------------82A96E083779F44D75E772F1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote:

During interoperability testing the following question has been asked. Can the list please discuss their thoughts (especially our editors).  Thanks.

"iCalendar says "no ORGANIZER" parameter.

I'm assuming you mean "property"
iTIP says "ORGANIZER" is a must."
I thought we had all agreed that iCalendar simply specifies a schema, but it is up to individual protocols to specify the presence or absence of a specific property. The protocol knows best what it needs and doesn't need.  That's why we did the restriction tables in iTIP.  That's why we're going to do restriction tables for CAP.

-Steve --------------82A96E083779F44D75E772F1-- --------------0E29F7FF84BBA5FFD9FC38F8 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------0E29F7FF84BBA5FFD9FC38F8-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 11:48:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24971 for ; Wed, 12 Apr 2000 11:48:00 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA09414 for ietf-calendar-bks; Wed, 12 Apr 2000 08:15:12 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09410 for ; Wed, 12 Apr 2000 08:15:11 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412151819.SFRJ851310.mta1biz.bizmailsrvcs.net@Software.com>; Wed, 12 Apr 2000 10:18:19 -0500 Message-ID: <38F48493.45DAA094@Software.com> Date: Wed, 12 Apr 2000 07:13:39 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: pregen@egenconsulting.com CC: ietf-calendar@imc.org Subject: Re: Question for list 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 pregen@egenconsulting.com wrote: > > During interoperability testing the following question has been asked. Can > the list please discuss their thoughts (especially our editors). Thanks. > > "iCalendar says "no ORGANIZER" parameter. iTIP says "ORGANIZER" is a must." I can't find the string 'no ORGANIZER' in RFC2445. Could you me more specific? Thanks! I think RFC2446 makes it clear: 3.7.2 Attendee Property Considerations The "ORGANIZER" property is required on published events, to-dos, and journal entries for two reasons. First, only the "Organizer" is allowed to update and redistribute an event or to-do component. It follows that the "ORGANIZER" property MUST be present in the event, to-do, or journal entry component so that the CUA has a basis for contact for anyone who receives a published component in case of problems. ... Note that above the word 'published' is not upper case. So it does *not* mean METHOD:PUBLISH. And from RFC2445: 4.8.4.3 Organizer ... Conformance: This property MUST be specified in an iCalendar object that specifies a group scheduled calendar entity. This property MUST be specified in an iCalendar object that specifies the publication of a calendar user's busy time. This property MUST NOT be specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but are entities only on a single user's calendar. ... I think the last part of the last sentence above is confusing: "...or that defines calendar entities that are not group scheduled entities, but are entities only on a single user's calendar." This means that ORGANIZER is only relevant when the object is pushed outside of the users original calendar. Although I don't see why it can't be there. -Doug From owner-ietf-calendar@mail.imc.org Wed Apr 12 11:49:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25042 for ; Wed, 12 Apr 2000 11:49:19 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA09640 for ietf-calendar-bks; Wed, 12 Apr 2000 08:21:21 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09636 for ; Wed, 12 Apr 2000 08:21:20 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412152428.SFWR851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 12 Apr 2000 10:24:28 -0500 Message-ID: <38F48604.B0DE15C2@Software.com> Date: Wed, 12 Apr 2000 07:19:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error 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 pregen@egenconsulting.com wrote: > > Frank, let me see if I understand what you and Doug are debating. > Here's my example. Say we are scheduling an interoperability test in > Boston. For this event, I send out calendar requests to the attendees > with start and end dates and include an attachment that is a map to the > facility. That now is a multipart document. All my client cares about > is that it is an attachment. If I am doing this using CAP (eventually), > wouldn't I want the transport mechanism to handle it (iTIP) instead of > the mail transport (iMIP). In a mail message, what handles attachments > today? Is it MIME, the mail client, or another protocol? Not sure of your question. If I am using CAP. Then I would use CAP. The object is still a MIME object and it would include any multipart attachments. You could fetch the appointment with CAP. Any inline or multipart attachments would have to be saved and retrieved via CAP as a multipart MIME object. If the object (a MIME object) is transported with CAP or iMIP, it's still the same object and it should look the same. It's just that in one case it will be moved by store and forward RFC821 and in the other CAP. How you display it (if that is your question) is not relevant to the protocol. And I agree with Bruce's email where he states that a CID or MID is very likely be the way to include attachments to appointments. -Doug > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 > > Frank_Dawson@lotus.com > Sent by: To: > owner-ietf-calendar@mail.imc.org ietf-calendar@imc.org > cc: > 04/10/00 02:52 PM Subject: Re: > CALSCH Action Items - - Error > > Doug: > > The support for multipart comes in when we begin to talk about > interoperability of the scheduling semantics over email. This is where > we ran into the problem between Lotus Organizer and Microsoft Outlook. > I was the one who reported it. > > At one of the IETF meetings we addressed this under the discuss of errata > against iMIP, not iCalendar. It was decided there that a change was > needed to the iMIP spec. > > Please change it in your "Action Items" document to an iMIP related bug. > The iCalendar spec interoperates fine without it, but the iMIP spec > doesn't. > > The fact that the ATTACH property and the ALTREP parameter _can_ specify a > CID or MID URI (as specified only in examples) for the URI based value > doesn't mandate that an iCalendar implement MUST support multipart MIME > entities. Indeed, the MID URI for an ATTACH property could specify an > message identifier external to the current message. The standard specifies > that the value is either a URI (which could be other URI types than a CID > or MID) or an inline binary value. ALTREP is a URI value. Most probably > NOT a CID or MID URI but more likely a HTTP URI. > > In fact, an iCalendar CUA is very likely to support inlined attachments and > HTTP type URIs for alternate representation of text content. > > It is a big jump to say that all iCalendar implementations MUST support > multipart. In fact an implementation that is using iCalendar for > import/export won't be doing this. The point is that many implementations > will conform to the RFC2445 just as a content definition. > > -- Frank From owner-ietf-calendar@mail.imc.org Wed Apr 12 12:45:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27103 for ; Wed, 12 Apr 2000 12:45:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA12008 for ietf-calendar-bks; Wed, 12 Apr 2000 09:22:26 -0700 (PDT) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12004 for ; Wed, 12 Apr 2000 09:22:25 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Cc: pregen@egenconsulting.com Subject: Re: Question for list X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Wed, 12 Apr 2000 12:27:28 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/12/2000 12:28:00 PM, Serialize complete at 04/12/2000 12:28:00 PM 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: Doug wrote a nice synposis and then wrote: >This means that ORGANIZER is only relevant when the object is pushed >outside of the users original calendar. Although I don't see why >it can't be there. An Organizer is used as the focal point in any group scheduling workflow. If I put a doctor appointment on my calendar for my reference only (and to block out busytime on searches) then what sense would ORGANIZER make then? None really. It COULD be there but its non-sensical, at least to me. The same can go for, say, an all day event like the Boston Marathon that I volunteer for. I want to put it on my calendar to remind me that Ive commited myself for the entire day and to block it out on any busytime searches and prevent me from scheduling work related meetings that day. Im NOT scheduling the Marathon w/anyone else, just putting it on my calendar. I fully grok the text of RFC 2446, Section 3.7.2 Attendee Property Considerations when it justifys WHY ORGANIZER is required (I probably argued for this @ one point myself Im sure). I do not think we fully covered EVERY possible scenario when we wrote it. That sections text requires that when I publish my Boston Marathon or doctors appointments using iTIP I MUST now include an ORGANIZER even if I dont have one on the entry originally! This is not necessarily a good idea. The crux of this dilemma: I cannot use iTIP to backup / restore (or 'publish') my calendar data via a METHOD:PUBLISH since not every entry has ORGANIZER and there would be no way to tell when the data can be removed on import. We have no other METHOD value to use for 'publishing' entries w/o using METHOD:PUBLISH; Perhaps a new one is in order for these cases and it would not have the current MUST requirement... 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... From owner-ietf-calendar@mail.imc.org Wed Apr 12 12:50:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27260 for ; Wed, 12 Apr 2000 12:50:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11858 for ietf-calendar-bks; Wed, 12 Apr 2000 09:18:27 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11852 for ; Wed, 12 Apr 2000 09:18:25 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA02666; Wed, 12 Apr 2000 12:38:33 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA11925; Wed, 12 Apr 2000 12:21:31 -0400 (EDT) To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 12:17:58 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 12:18:00 PM, Serialize complete at 04/12/2000 12:18:00 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0054F687852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054F687852557A0_= Content-Type: text/plain; charset="us-ascii" Pat: iCalendar Stuff =============== You can either have the value for the content be in the event definition (i.e., inline BINARY value content) or it can be external to the event definition (i.e., a URI value content). In the latter case, the URI could be a FTP, HTTP, FILE, CID, MID or whatever type of appropriate URI to specify an external content information. iCalendar is complete in specifying this semantic. iMIP Stuff ========== The issue came up when Lotus Organizer was testing with Microsoft Outlook. Lotus Organizer sent an invitation to Microsoft Outlook as a multipart/mixed message containing, first, a pretty text/plain description of the invitation and, second, a text/calendar iCalendar encoding of the invitation. The issue is that iMIP currently only mandates that a conforming implementation support a text/plain "singleton" MIME entity. In one of the IETF meetings, we discussed and later confirmed (I believe) a general WG consensus that the iMIP specification should be changed to mandate support for not only text/calendar content, but also text/calendar within a multipart MIME content type. What you are suggesting is that the iCalendar object includes a related attachment content (e.g., image/jpeg) with a map of the meeting venue. For argument sake, let's say this was passed as an attachment. This would probably be MIME encoded as a multipart/mixed or a multipart/related MIME entity consisting of the text/calendar and image/jpeg components. BUT, note that this could further be encapsulated into a multipart/mixed containing a short text/plain text note and also the multipart/mixed (or multipart/related) compound iCalendar component. My debate with Doug is his assertion that this support for "multipart" should be in the definition of the text/calendar content type, the iCalendar specification. I strongly disagree. Saying how the text/calendar content can be further (and secondarily) encapsulated is a transport wrapper matter. So, it belongs in the iMIP specification. Indeed, folks will be referencing the iCalendar standard as a standalone content definition. It should NOT be encumbered by a requirement to support MIME multipart wrapping of the text/calendar content. This is an issue for how you want to transport it. For example, for an operating system clipboard "binding" of iCalendar, we would probably say that the ATTACH property value would be a FILE type URI, pointing to the attachment within the operating system's file system. There would be absolutely no need to have the overhead of the additional support for the multipart form. BTW, within the iMIP specification, if we make this change happen, then we also need to state just how many levels of nesting we expect an iMIP recipient to parse the content. Right? I can fathom mandating support for the text/calendar being embedded one level, but farther down seems problematic. SO...Net-net: The change needs to be made to the iMIP, not iCalendar specification. We could, however, add some text to the iCalendar spec that says that text/calendar objects _can_ be further encapsulated into multipart MIME entities. But this is just an informative comment. -- Frank --=_alternative 0054F687852557A0_= Content-Type: text/html; charset="us-ascii"
Pat:

iCalendar Stuff

===============

You can either have the value for the content be in the event definition (i.e., inline BINARY value content) or it can be external to the event definition (i.e., a URI value content). In the latter case, the URI could be a FTP, HTTP, FILE, CID, MID or whatever type of appropriate URI to specify an external content information.

iCalendar is complete in specifying this semantic.

iMIP Stuff

==========

The issue came up when Lotus Organizer was testing with Microsoft Outlook. Lotus Organizer sent an invitation to Microsoft Outlook as a multipart/mixed message containing, first, a pretty text/plain description of the invitation and, second, a text/calendar iCalendar encoding of the invitation. The issue is that iMIP currently only mandates that a conforming implementation support a text/plain "singleton" MIME entity. In one of the IETF meetings, we discussed and later confirmed (I believe) a general WG consensus that the iMIP specification should be changed to mandate support for not only text/calendar content, but also text/calendar within a multipart MIME content type.

What you are suggesting is that the iCalendar object includes a related attachment content (e.g., image/jpeg) with a map of the meeting venue. For argument sake, let's say this was passed as an attachment. This would probably be MIME encoded as a multipart/mixed or a multipart/related MIME entity consisting of the text/calendar and image/jpeg components. BUT, note that this could further be encapsulated into a multipart/mixed containing a short text/plain text note and also the multipart/mixed (or multipart/related) compound iCalendar component.

My debate with Doug is his assertion that this support for "multipart" should be in the definition of the text/calendar content type, the iCalendar specification. I strongly disagree. Saying how the text/calendar content can be further (and secondarily) encapsulated is a transport wrapper matter.

So, it belongs in the iMIP specification.

Indeed, folks will be referencing the iCalendar standard as a standalone content definition. It should NOT be encumbered by a requirement to support MIME multipart wrapping of the text/calendar content. This is an issue for how you want to transport it.

For example, for an operating system clipboard "binding" of iCalendar, we would probably say that the ATTACH property value would be a FILE type URI, pointing to the attachment within the operating system's file system. There would be absolutely no need to have the overhead of the additional support for the multipart form.

BTW, within the iMIP specification, if we make this change happen, then we also need to state just how many levels of nesting we expect an iMIP recipient to parse the content. Right? I can fathom mandating support for the text/calendar being embedded one level, but farther down seems problematic.

SO...Net-net: The change needs to be made to the iMIP, not iCalendar specification. We could, however, add some text to the iCalendar spec that says that text/calendar objects _can_ be further encapsulated into multipart MIME entities. But this is just an informative comment.

-- Frank --=_alternative 0054F687852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 12:53:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27324 for ; Wed, 12 Apr 2000 12:53:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA12114 for ietf-calendar-bks; Wed, 12 Apr 2000 09:26:09 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12109; Wed, 12 Apr 2000 09:26:08 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA03955; Wed, 12 Apr 2000 12:46:14 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA12248; Wed, 12 Apr 2000 12:29:13 -0400 (EDT) To: sman@netscape.com (Steve Mansour) Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, pregen@egenconsulting.com Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 12:25:41 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 12:25:42 PM, Serialize complete at 04/12/2000 12:25:42 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0055AB4F852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0055AB4F852557A0_= Content-Type: text/plain; charset="us-ascii" I agree with Steve. BTW, I think Pat must have meant "property". But I am confused why she thinks it is a "no". We don't use the word "no" for such things in iCalendar. We use RFC2119 terms. Maybe Pat can clarify again what the context and specifics were. -- Frank --=_alternative 0055AB4F852557A0_= Content-Type: text/html; charset="us-ascii"
I agree with Steve.

BTW, I think Pat must have meant "property". But I am confused why she thinks it is a "no". We don't use the word "no" for such things in iCalendar. We use RFC2119 terms.

Maybe Pat can clarify again what the context and specifics were.

-- Frank --=_alternative 0055AB4F852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 12:54:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27384 for ; Wed, 12 Apr 2000 12:54:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA12397 for ietf-calendar-bks; Wed, 12 Apr 2000 09:33:11 -0700 (PDT) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12393 for ; Wed, 12 Apr 2000 09:33:09 -0700 (PDT) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: Further on "Question to List" X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Wed, 12 Apr 2000 12:36:43 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 04/12/2000 12:36:43 PM, Serialize complete at 04/12/2000 12:36:43 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005B3E42852568BF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B3E42852568BF_= Content-Type: text/plain; charset="us-ascii" Just to clarify my question to the list. This question is part of a discussion on parameters for the PUBLISH event. I believe Doug already has figured that out. Sorry for not adding that piece. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 005B3E42852568BF_= Content-Type: text/html; charset="us-ascii"
Just to clarify my question to the list.  This question is part of a discussion on parameters for the PUBLISH event.  I believe Doug already has figured that out.  Sorry for not adding that piece.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 005B3E42852568BF_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 12:55:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27424 for ; Wed, 12 Apr 2000 12:55:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA12492 for ietf-calendar-bks; Wed, 12 Apr 2000 09:36:30 -0700 (PDT) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12483 for ; Wed, 12 Apr 2000 09:36:28 -0700 (PDT) From: pregen@egenconsulting.com To: Frank_Dawson@lotus.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, sman@netscape.com (Steve Mansour) Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Wed, 12 Apr 2000 12:40:02 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 04/12/2000 12:40:02 PM, Serialize complete at 04/12/2000 12:40:02 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005B8BE8852568BF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B8BE8852568BF_= Content-Type: text/plain; charset="us-ascii" Frank, please see my newest note to the list. I am not "confused". I am posting the text exactly as it is being posted into a discussion database. What I left off was the subject of the post - That these are questions on parameters for the PUBLISH event. Doug figured that out and has responded in one of his texts. Thanks. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Frank_Dawson@lotus.com 04/12/88 12:25 PM To: sman@netscape.com (Steve Mansour) cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, pregen@egenconsulting.com Subject: Re: Question for list I agree with Steve. BTW, I think Pat must have meant "property". But I am confused why she thinks it is a "no". We don't use the word "no" for such things in iCalendar. We use RFC2119 terms. Maybe Pat can clarify again what the context and specifics were. -- Frank --=_alternative 005B8BE8852568BF_= Content-Type: text/html; charset="us-ascii"
Frank, please see my newest note to the list.  I am not "confused".  I am posting the text exactly as it is being posted into a discussion database.  What I left off was the subject of the post - That these are questions on parameters for the PUBLISH event.  Doug figured that out and has responded in one of his texts.  Thanks.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Frank_Dawson@lotus.com

04/12/88 12:25 PM

       
        To:        sman@netscape.com (Steve Mansour)
        cc:        ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, pregen@egenconsulting.com
        Subject:        Re: Question for list



I agree with Steve.

BTW, I think Pat must have meant "property". But I am confused why she thinks it is a "no". We don't use the word "no" for such things in iCalendar. We use RFC2119 terms.

Maybe Pat can clarify again what the context and specifics were.

-- Frank

--=_alternative 005B8BE8852568BF_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 12:58:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27527 for ; Wed, 12 Apr 2000 12:58:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA12551 for ietf-calendar-bks; Wed, 12 Apr 2000 09:38:21 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12547; Wed, 12 Apr 2000 09:38:19 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA05611; Wed, 12 Apr 2000 12:58:25 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA12863; Wed, 12 Apr 2000 12:41:24 -0400 (EDT) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, pregen@egenconsulting.com Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 12:37:52 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 12:37:53 PM, Serialize complete at 04/12/2000 12:37:53 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0056C904852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056C904852557A0_= Content-Type: text/plain; charset="us-ascii" Doug Royer wrote, in part: >This means that ORGANIZER is only relevant when the object is pushed >outside of the users original calendar. Although I don't see why >it can't be there. If you just have an "appointment" (i.e., a non-group scheduled event) on your calendar, then when you export into an iCalendar format the METHOD would have to be PUBLISH or CANCEL and there MUST be no ORGANIZER because it is not a group scheduled event. If you had an ORGANIZER than it should also have ATTENDEE properties or it is an invalid group scheduled event represented in the iCalendar format. By restricting the occurrence of ORGANIZER from non-group scheduled events, you minimize the chance of misinterpretation as an invalid group scheduled event. So the logic went... But I think this is not an unreasonable restriction. -- Frank --=_alternative 0056C904852557A0_= Content-Type: text/html; charset="us-ascii"
Doug Royer wrote, in part:

>This means that ORGANIZER is only relevant when the object is pushed
>outside of the users original calendar. Although I don't see why
>it can't be there.

If you just have an "appointment" (i.e., a non-group scheduled event) on your calendar, then when you export into an iCalendar format the METHOD would have to be PUBLISH or CANCEL and there MUST be no ORGANIZER because it is not a group scheduled event. If you had an ORGANIZER than it should also have ATTENDEE properties or it is an invalid group scheduled event represented in the iCalendar format.

By restricting the occurrence of ORGANIZER from non-group scheduled events, you minimize the chance of misinterpretation as an invalid group scheduled event.

So the logic went... But I think this is not an unreasonable restriction.

-- Frank --=_alternative 0056C904852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 13:02:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27733 for ; Wed, 12 Apr 2000 13:02:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA12665 for ietf-calendar-bks; Wed, 12 Apr 2000 09:42:45 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12660; Wed, 12 Apr 2000 09:42:43 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA05782; Wed, 12 Apr 2000 13:02:52 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA13168; Wed, 12 Apr 2000 12:45:51 -0400 (EDT) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 12:42:19 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 12:42:20 PM, Serialize complete at 04/12/2000 12:42:20 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0057317A852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057317A852557A0_= Content-Type: text/plain; charset="us-ascii" Doug Royer wrote, in part: >And I agree with Bruce's email where he states that a CID or MID >is very likely be the way to include attachments to appointments. This may be a very narrow view on the use of iCalendar. Certainly, for usage outside of email, the attachment may be specified as an external entity in a local file system (i.e., with a FILE type URL), as a network entity (i.e., with a HTTP type URL) or even passed inline (e.g., with usage over Bluetooth or IrDA). iCalendar, as a data dictionary, specified the semantics clearly. The ATTACH value can either be an inline BINARY value or a URI value. In the latter case, the attachment content is somewhere external to the iCalendar object. But to mandate that it be in a multipart content is clearly too restrictive. --=_alternative 0057317A852557A0_= Content-Type: text/html; charset="us-ascii"
Doug Royer wrote, in part:

>And I agree with Bruce's email where he states that a CID or MID
>is very likely be the way to include attachments to appointments.

This may be a very narrow view on the use of iCalendar. Certainly, for usage outside of email, the attachment may be specified as an external entity in a local file system (i.e., with a FILE type URL), as a network entity (i.e., with a HTTP type URL) or even passed inline (e.g., with usage over Bluetooth or IrDA).

iCalendar, as a data dictionary, specified the semantics clearly. The ATTACH value can either be an inline BINARY value or a URI value. In the latter case, the attachment content is somewhere external to the iCalendar object.

But to mandate that it be in a multipart content is clearly too restrictive. --=_alternative 0057317A852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 13:24:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28391 for ; Wed, 12 Apr 2000 13:24:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13278 for ietf-calendar-bks; Wed, 12 Apr 2000 10:04:53 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13274 for ; Wed, 12 Apr 2000 10:04:52 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA06642 for ; Wed, 12 Apr 2000 13:25:00 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA14349; Wed, 12 Apr 2000 13:07:59 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 13:04:26 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 01:04:28 PM, Serialize complete at 04/12/2000 01:04:28 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005937D5852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005937D5852557A0_= Content-Type: text/plain; charset="us-ascii" Bruce Kahn wrote, in part: >The crux of this dilemma: I cannot use iTIP to backup / restore (or >'publish') my calendar data via a METHOD:PUBLISH since not every entry has >ORGANIZER and there would be no way to tell when the data can be removed >on import. For backup, you definitely DON'T want to specify PUBLISH method for a group scheduled event. If you did, you would loose the fact that maybe the item was a REQUEST. You will need to preserver the original method for the event when you backup, other wise the restore will restore with the wrong scheduling semantics. -- Frank --=_alternative 005937D5852557A0_= Content-Type: text/html; charset="us-ascii"
Bruce Kahn wrote, in part:

>The crux of this dilemma: I cannot use iTIP to backup / restore (or
>'publish') my calendar data via a METHOD:PUBLISH since not every entry has
>ORGANIZER and there would be no way to tell when the data can be removed
>on import.

For backup, you definitely DON'T want to specify PUBLISH method for a group scheduled event. If you did, you would loose the fact that maybe the item was a REQUEST.

You will need to preserver the original method for the event when you backup, other wise the restore will restore with the wrong scheduling semantics.

-- Frank --=_alternative 005937D5852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 13:25:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28413 for ; Wed, 12 Apr 2000 13:25:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA13009 for ietf-calendar-bks; Wed, 12 Apr 2000 09:56:23 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13005 for ; Wed, 12 Apr 2000 09:56:22 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412165930.SIWE851310.mta1biz.bizmailsrvcs.net@Software.com>; Wed, 12 Apr 2000 11:59:30 -0500 Message-ID: <38F49C4A.71BABCBD@Software.com> Date: Wed, 12 Apr 2000 08:54:50 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org, pregen@egenconsulting.com Subject: Re: Question for list 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 Bruce_Kahn@iris.com wrote: > The crux of this dilemma: I cannot use iTIP to backup / restore (or > 'publish') my calendar data via a METHOD:PUBLISH since not every entry has > ORGANIZER and there would be no way to tell when the data can be removed > on import. We have no other METHOD value to use for 'publishing' entries > w/o using METHOD:PUBLISH; Perhaps a new one is in order for these cases > and it would not have the current MUST requirement... ALL METHOD:PUBLISH components MUST have an ORGANIZER per the iTIP restriction tables. Is there somewhere in iCal or iTIP that says otherwise? As to backup/restore - TRUE - that' one reason for CAP. :-) CAP itself does not address backup/restore itself. But it does allow you for synchronization to an external or roaming device. So in effect you MUST be able to pull all entries out via CAP and you must be able to put all in via CAP. There is just no way with iTIP to do this - and iTIP was specifically designed not to do this for security reasons. Again another reason for direct access to your calendar - CAP. -Doug From owner-ietf-calendar@mail.imc.org Wed Apr 12 13:39:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29277 for ; Wed, 12 Apr 2000 13:39:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13784 for ietf-calendar-bks; Wed, 12 Apr 2000 10:20:07 -0700 (PDT) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13780 for ; Wed, 12 Apr 2000 10:20:05 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Frank_Dawson@lotus.com Cc: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Wed, 12 Apr 2000 13:25:06 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/12/2000 01:25:41 PM, Serialize complete at 04/12/2000 01:25:41 PM 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: Frank fired: >This may be a very narrow view on the use of iCalendar. Not presently. Given that we are doing CalConnect NOW and have yet to finalize CAP (which will have a longer window for implementation than say this year) I think the VAST majority you will find in the near term WILL be CID. Otherwise we can expect greater interop problems when dealing with firewalls, Intranet vs Internet and other classic problems. Id prefer to get a MIME stream w/ALL the data in it rather than an iCalendar message that requires my CUA to go out and try to retrieve the data (from potentially inaccessible URIs!!). Besides, thats how MHTML (RFC 2557) and other rich content schemes work. Are you claiming that they too have too narrow a view? >Certainly, for usage outside of email, the attachment may be specified as an external entity in a >local file system (i.e., with a FILE type URL), as a network entity (i.e., with a HTTP type URL) >or even passed inline (e.g., with usage over Bluetooth or IrDA). For example #1, thats just an access problem waiting to happen! I grant 0% access to my local disk for both personal and work reasons. Just not a good example to even THINK about. Example #2 is good for intranets and possibly for some internet cases but it hand waves on the access problems that CAP is still mulling over. What are the odds that Microsoft would send you an HTTP URL to an internal server for you to read?? Example #3 is currently there but its ONLY usable for data types of URI like ATTACH but its totally off base WRT the example I used originally of DESCRIPTION;ALTREP=... where INLINE is NOT available!! VALUE=INLINE is NOT available for ALTREP= parameters last I checked. >But to mandate that it be in a multipart content is clearly too restrictive. We are too far afield from the original comment context. If I have a DESCRIPTION;ALTREP=, is it unreasonable to have it in another MIME body part that is sent w/this Content-Type: text/calendar? Hardly. Is it unreasonable to have it stored externally to the MIME stream and have the CUA retrieve it? Hardly. Which would be a more functional (or usable) way to convey my HTML alternate representation of DESCRIPTION: a URL that may or may not be accessible at any given time to those who need it or to have it in the same data stream as the entry that references it? Id bet the latter. (BTW: NOONE ever claimed that we mandated it be in multipart only. Where did you see that??) 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... From owner-ietf-calendar@mail.imc.org Wed Apr 12 13:49:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29526 for ; Wed, 12 Apr 2000 13:49:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA14014 for ietf-calendar-bks; Wed, 12 Apr 2000 10:29:04 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14010 for ; Wed, 12 Apr 2000 10:29:02 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412173211.SJUN851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 12 Apr 2000 12:32:11 -0500 Message-ID: <38F4A3F2.6E443FC2@Software.com> Date: Wed, 12 Apr 2000 09:27:30 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Frank_Dawson@lotus.com wrote: > > Doug Royer wrote, in part: > > >This means that ORGANIZER is only relevant when the object is pushed > >outside of the users original calendar. Although I don't see why > >it can't be there. > > If you just have an "appointment" (i.e., a non-group scheduled event) on > your calendar, then when you export into an iCalendar format the METHOD > would have to be PUBLISH or CANCEL and there MUST be no ORGANIZER because > it is not a group scheduled event. If you had an ORGANIZER than it should > also have ATTENDEE properties or it is an invalid group scheduled event > represented in the iCalendar format. Not true. A PUBLISH event MUST have an ORGANIZER (And iTIP clearly states that in the restriction tables) . Because you can PUBLISH for public view. And it might not have any ATTENDEEs: Example of such a PUBLISH: The local little league team is having try outs this Saturday - ORGANIZER:.... And there are NO attendees because you sent it out to all@local-town.org and you have no idea who is on the list, or who will be attending or not. Anyone wishing to attend the event now knows who the ORGANIZER is, and as the ORGANIZER is a cal-address, they can possibly look directly with their CUA and CAP (Assuming VCAR access allowed). They can also forward the object to anyone. And as the object contains an ORGANIZER, the new receptionist know who the ORGANIZER is, and that it is not necessarily the person that sent them the email. And iTIP specifies that ORGANIZER is a MUST for VEVENT, VTODO, and VJOURNAL PUBLISH objects. Bruces example although a real life issue, is out of scope for both iTIP and CAP. > By restricting the occurrence of ORGANIZER from non-group scheduled events, > you minimize the chance of misinterpretation as an invalid group scheduled > event. > > So the logic went... But I think this is not an unreasonable restriction. > > -- Frank From owner-ietf-calendar@mail.imc.org Wed Apr 12 13:55:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29591 for ; Wed, 12 Apr 2000 13:55:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA14133 for ietf-calendar-bks; Wed, 12 Apr 2000 10:33:29 -0700 (PDT) Received: from lotus.lotus.com (lotus.lotus.com [192.233.136.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14129 for ; Wed, 12 Apr 2000 10:33:27 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus.lotus.com (8.9.3/8.9.3) with ESMTP id NAA09651 for ; Wed, 12 Apr 2000 13:27:54 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA16335; Wed, 12 Apr 2000 13:36:17 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 13:32:45 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 01:32:46 PM, Serialize complete at 04/12/2000 01:32:46 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005BCF24852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005BCF24852557A0_= Content-Type: text/plain; charset="us-ascii" Bruce Kahn wrote, in part: >(BTW: NOONE ever claimed that we mandated it be in multipart only. >Where did you see that??) Bruce. The item in Doug's "action items" states: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. Unless I am mistaked this means the RFC2119 "MUST". Glad to see we agree on something. That this shouldn't be a MUST. But the original issue was with multipart/mixed, not multipart/alternate or multipart/related. We still have the issue of depth. -- Frank --=_alternative 005BCF24852557A0_= Content-Type: text/html; charset="us-ascii"
Bruce Kahn wrote, in part:


>(BTW: NOONE ever claimed that we mandated it be in multipart only.  
>Where did you see that??)
Bruce. The item in Doug's "action items" states:

Draft Action Item                                                                    Who                 Done (Y/N)
-----------------                                                                    ---                 ----------

I-1 MIME alternate/related                                                   Frank                 ?
    MUST be supported.

Unless I am mistaked this means the RFC2119 "MUST".

Glad to see we agree on something. That this shouldn't be a MUST.

But the original issue was with multipart/mixed, not multipart/alternate or multipart/related.

We still have the issue of depth.

-- Frank --=_alternative 005BCF24852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 14:48:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01023 for ; Wed, 12 Apr 2000 14:48:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15283 for ietf-calendar-bks; Wed, 12 Apr 2000 11:30:56 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15277 for ; Wed, 12 Apr 2000 11:30:55 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412183404.SLXJ851310.mta1biz.bizmailsrvcs.net@Software.com>; Wed, 12 Apr 2000 13:34:04 -0500 Message-ID: <38F4B273.BF2D8E09@Software.com> Date: Wed, 12 Apr 2000 10:29:23 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error 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 It does not however mean that all attachments MUST me CID's or MID's. It means that it is valid to send an attachments as a CID or MID and that it is MUST that you know how to deal with it. Unlike the one vendor that ignored all TEXT/CALENDAR objects that were part of MULTIPART/RELATED. -Doug Frank_Dawson@lotus.com wrote: > > Bruce Kahn wrote, in part: > > >(BTW: NOONE ever claimed that we mandated it be in multipart only. > >Where did you see that??) > > Bruce. The item in Doug's "action items" states: > > Draft Action Item > Who Done (Y/N) > ----------------- > --- ---------- > > I-1 MIME alternate/related > Frank ? > MUST be supported. > > Unless I am mistaked this means the RFC2119 "MUST". > > Glad to see we agree on something. That this shouldn't be a MUST. > > But the original issue was with multipart/mixed, not multipart/alternate or > multipart/related. > > We still have the issue of depth. > > -- Frank From owner-ietf-calendar@mail.imc.org Wed Apr 12 15:18:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01483 for ; Wed, 12 Apr 2000 15:18:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA16072 for ietf-calendar-bks; Wed, 12 Apr 2000 11:52:44 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16067 for ; Wed, 12 Apr 2000 11:52:42 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA18267 for ; Wed, 12 Apr 2000 15:12:51 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA04025 for ; Wed, 12 Apr 2000 14:55:51 -0400 (EDT) To: ietf-calendar@imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 14:52:19 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 02:52:20 PM, Serialize complete at 04/12/2000 02:52:20 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006317FF852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006317FF852557A0_= Content-Type: text/plain; charset="us-ascii" Doug: This is the problem. Thanks for clarifying this. iTIP deals with group scheduled events and to-dos. As you correctly pointed out, if you are are using iTIP to specify such a group scheduled PUBLISH event, you MUST have the ORGANIZER property. However, in my note, I was referring to an "appointment", not a "meeting". This would be for a non-group scheduled event. There would be no ORGANIZER, per se. When I copy this event to my clipboard, I would not expect to see an ORGANIZER property on it. After all, this type of event doesn't conform to iTIP. After all, the iTIP spec doesn't address non-group scheduled events. If I want to archive these "appointments" from my calendar, SHOULD we be specifying them without an ORGANIZER? I think so. And SHOULD we be specifying a METHOD. Hhmm. Isn't PUBLISH the correct method? I think os. In this case, we have an event that doesn't conform to iTIP, but correctly has a PUBLISH method and no ORGANIZER. -- Frank --=_alternative 006317FF852557A0_= Content-Type: text/html; charset="us-ascii"
Doug:

This is the problem. Thanks for clarifying this.

iTIP deals with group scheduled events and to-dos. As you correctly pointed out, if you are are using iTIP to specify such a group scheduled PUBLISH event, you MUST have the ORGANIZER property.

However, in my note, I was referring to an "appointment", not a "meeting". This would be for a non-group scheduled event. There would be no ORGANIZER, per se. When I copy this event to my clipboard, I would not expect to see an ORGANIZER property on it. After all, this type of event doesn't conform to iTIP. After all, the iTIP spec doesn't address non-group scheduled events.

If I want to archive these "appointments" from my calendar, SHOULD we be specifying them without an ORGANIZER? I think so. And SHOULD we be specifying a METHOD. Hhmm. Isn't PUBLISH the correct method? I think os.

In this case, we have an event that doesn't conform to iTIP, but correctly has a PUBLISH method and no ORGANIZER.

-- Frank --=_alternative 006317FF852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 16:10:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02369 for ; Wed, 12 Apr 2000 16:10:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA17085 for ietf-calendar-bks; Wed, 12 Apr 2000 12:38:10 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17081 for ; Wed, 12 Apr 2000 12:38:09 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412194118.SNVH851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 12 Apr 2000 14:41:18 -0500 Message-ID: <38F4C235.DF77772@Software.com> Date: Wed, 12 Apr 2000 11:36:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Frank_Dawson@lotus.com wrote: > > Doug: > > This is the problem. Thanks for clarifying this. > > iTIP deals with group scheduled events and to-dos. As you correctly pointed > out, if you are are using iTIP to specify such a group scheduled PUBLISH > event, you MUST have the ORGANIZER property. > > However, in my note, I was referring to an "appointment", not a "meeting". I disagree. I do not see any reason that you can not use iTIP to send an appointment to another person. With only one ATTENDEE and the ORGANIZER not attending. iTIP example: BEGIN:VEVENT METHOD:PUBLISH ... ORGANIZER: your boss ATTENDEE: you SUMMARY: cover the phone line for me - I am going on vacation. DTSTART:... DTEND:... ... END:VEVENT One attendee - no meeting - an appointment - not a group scheduled event. No reply needed or wanted - so sent as a PUBLISH. > This would be for a non-group scheduled event. There would be no ORGANIZER, > per se. When I copy this event to my clipboard, I would not expect to see an > ORGANIZER property on it. After all, this type of event doesn't conform to > iTIP. After all, the iTIP spec doesn't address non-group scheduled events. I don't know of any place in iCal or iIIP where this is specified. If you copy 'what' from your clipboard. Someone made the appointment? Someone knows what this means - yourself as both the ORGANIZER and the only ATTENDEE? > If I want to archive these "appointments" from my calendar, SHOULD we be > specifying them without an ORGANIZER? I think so. How you archive them is out of scope for iCalendar, iTIP, iMIP, and CAP. > And SHOULD we be > specifying a METHOD. Hhmm. Isn't PUBLISH the correct method? I think os. How you archive them is out of scope for iCalendar, iTIP, iMIP, and CAP. > In this case, we have an event that doesn't conform to iTIP, but correctly > has a PUBLISH method and no ORGANIZER. I can see that you do not want ORGANIZER when archiving. I still do not see that we need to change or extend iTIP. And I still see it as out of scope. -Doug From owner-ietf-calendar@mail.imc.org Wed Apr 12 16:18:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02480 for ; Wed, 12 Apr 2000 16:18:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16697 for ietf-calendar-bks; Wed, 12 Apr 2000 12:13:43 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16692 for ; Wed, 12 Apr 2000 12:13:40 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA23432 for ; Wed, 12 Apr 2000 15:33:44 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA17235; Wed, 12 Apr 2000 13:39:05 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 13:35:33 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 01:35:35 PM, Serialize complete at 04/12/2000 01:35:35 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005C1108852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C1108852557A0_= Content-Type: text/plain; charset="us-ascii" Bruce Kahn, wrote in part: >For example #1, thats just an access problem waiting to happen! I grant >0% access to my local disk for both personal and work reasons. Just not a >good example to even THINK about. Bruce. You had good counter arguments on many of your points. I concede! But on this one, the example was use for copy/paste from clipboard. When I am told to copy an event from a local storage to the OS clipboard. I will probably render the event with the ATTACH property specifying a FILE type URL or render the ATTACH content inline. But probably the former. I am not going to put it out as a multipart. I want to use the clipboard registered format identifier for text/calendar. This was my point. --=_alternative 005C1108852557A0_= Content-Type: text/html; charset="us-ascii"
Bruce Kahn, wrote in part:

>For example #1, thats just an access problem waiting to happen!  I grant
>0% access to my local disk for both personal and work reasons.  Just not a
>good example to even THINK about.

Bruce. You had good counter arguments on many of your points. I concede!

But on this one, the example was use for copy/paste from clipboard. When I am told to copy an event from a local storage to the OS clipboard. I will probably render the event with the ATTACH property specifying a FILE type URL or render the ATTACH content inline. But probably the former.

I am not going to put it out as a multipart. I want to use the clipboard registered format identifier for text/calendar.

This was my point. --=_alternative 005C1108852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 16:22:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02501 for ; Wed, 12 Apr 2000 16:22:03 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA17316 for ietf-calendar-bks; Wed, 12 Apr 2000 12:46:46 -0700 (PDT) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17311 for ; Wed, 12 Apr 2000 12:46:44 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Frank_Dawson@lotus.com Cc: ietf-calendar@imc.org, pregen@egenconsulting.com Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Wed, 12 Apr 2000 15:51:44 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/12/2000 03:52:21 PM, Serialize complete at 04/12/2000 03:52:21 PM 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: This started as a short msg but it grew long. Some technical tubbing happens so be forewarned! Frank wrote: >Lotus Organizer sent an invitation to Microsoft Outlook as a multipart/mixed message containing, >first, a pretty text/plain description of the invitation and, second, a text/calendar iCalendar >encoding of the invitation. This is a misuse of multipart/mixed. From RFC 2387, 3. Intended usage The Multipart/Related media type is intended for compound objects consisting of several inter-related body parts. In your example, the proper MIME type should have been multipart/alternative instead. From RFC 2046: 5.1.4. Alternative Subtype The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information. I hope that the current and past editors have properly used the right multipart/* subtypes in their drafts. >The issue is that iMIP currently only mandates that a conforming implementation support a >text/plain "singleton" MIME entity. Actually it has no such mandate. Check out 4.2 Using Multipart Alternative for Low Fidelity Clients This example shows how a client can emit a multipart message that includes both a plain text version as well as the full iCalendar object. Clients that do not support text/calendar will still be capable of rendering the plain text representation. This is strictly an example of HOW to do lower fidelity invites using multipart/alternative and text/plain. There is 0 requirement in iMIP for text/plain support. That kind of conformance is really a MIME compliance issue (best deferred to Chris Newman or some other MIME guru). >This would probably be MIME encoded as a multipart/mixed or a multipart/related MIME entity >consisting of the text/calendar and image/jpeg components. To KISS, Ill assume no alternate representation of the text/calendar. Checking RFC 2046 yeilds the following: 5.1.3. Mixed Subtype The "mixed" subtype of "multipart" is intended for use when the body parts are independent and need to be bundled in a particular order. Any "multipart" subtypes that an implementation does not recognize must be treated as being of subtype "mixed". Since our example is closer to the mixed world Id propose we clearly call this out and not cause further confusion with multipart/related. Chris can slap me silly if I have it backwards. In any case, the example nows boils down to: Content-Type: multipart/mixed Content-Type: text/calendar [The meeting invitation] Content-Type: image/jpeg [The attached map] >BUT, note that this could further be encapsulated into a multipart/mixed containing a short >text/plain text note and also the multipart/mixed (or multipart/related) compound iCalendar >component. Do you mean that there is a lower fidelity text/plain in the stream? That would simply change the structure to: Content-Type: multipart/mixed Content-Type: multipart/alternative Content-Type: text/plain [Low fideltiy description of meeting invitation] Content-Type: text/calendar [The meeting invitation] Content-Type: image/jpeg [The attached map] If your CUA wanted to get really really fancy then it could also include other alternative renderings in the Content-Type: multipart/alternative in the proper place (ie: application/ms-tnef, application/x-lotus-rtf, etc). This does not make the outer wrapper more complex. Adding ALTREP data to the DESCRIPTION does make it a bit nastier. My take on the MIME RFCs is that the structure for including ALTREP data would become: Content-Type: multipart/mixed Content-Type: multipart/related Content-Type: multipart/alternative Content-Type: text/plain [Low fideltiy description of meeting invitation] Content-Type: text/calendar [The meeting invitation] Content-Type: text/html [The HTML ALTREP for the DESCRIPTION property] Content-Type: image/jpeg [The attached map] Ok, so this KISS example is now definitely NOT KISS. Since this complex layout is what could be generated for even the most simplest of cases (an invite with an attachment) Id like to see A) the MIME wrappering confirmed/fixed by Chris Newman (or Paul H.) and B) added to the proper RFC updates! >Saying how the text/calendar content can be further (and secondarily) encapsulated is a transport >wrapper matter. Given that this affects all transports that convey the data, Id suggest that this belongs at the iTIP level rather than at the iMIP level. Otherwise it may get ignored or overlooked in other bindings of iTIP or not even considered when other transport methodologies are defined in the future. I do agree with Frank in that its probably not apropo for the iCalendar RFC since iCalendar is just the language definition, not a definition of HOW it is used. >For example, for an operating system clipboard "binding" of iCalendar, we would probably say that >the ATTACH property value would be a FILE type URI, pointing to the attachment within the >operating system's file system. There would be absolutely no need to have the overhead of the >additional support for the multipart form. It may be obvious to others but its not to me so Ill ask: Just how did the attachment get to the file system? Did it get magically put there when I selected "Save as" in response to bringing down the iCalendar? There are also assumptions that the file path is kept intact and that it will work on all platforms that the user has (ie: Mac, BeOS, Un*x w/ and w/o GUIs, Win32, etc). Lots of room for error or simple actions to break the 'link' between the file and the iCalendar data in this scenario. From an end users perspective, Id like to be able to do 1 action (Drag/Drop, File->Export, etc) and have my entry saved as a local file. This file would have all that I need to send the full notice to someone (ie: IrDA, File uploade in a browser, FTP, etc). End users (David Madeo can correct me if Im wrong here) do NOT want to have to keep track the files on their drives and any relationship between them: "I need to keep m12345.zip around since I still have Frank.ics on my drive but I deleted Hockey.ics so I can remove both NHL2000.doc and 7326345.zip". From an end users perspective I seriously suspect 1 file MUCH easier to deal with than separate ones! It may not be easier on us as implementors but users dont care about our pains just THEIRS!! >We could, however, add some text to the iCalendar spec that says that text/calendar objects _can_ >be further encapsulated into multipart MIME entities. But this is just an informative comment. Its always nice to end on a good note and while I disagree on iMIP being the place to make the additions, I do agree that iCalendar would benefit from said addition. 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... From owner-ietf-calendar@mail.imc.org Wed Apr 12 16:28:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02608 for ; Wed, 12 Apr 2000 16:28:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17671 for ietf-calendar-bks; Wed, 12 Apr 2000 13:05:46 -0700 (PDT) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17665 for ; Wed, 12 Apr 2000 13:05:42 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Doug Royer Cc: ietf-calendar@imc.org, pregen@egenconsulting.com Subject: Re: Question for list X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Wed, 12 Apr 2000 16:10:47 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/12/2000 04:11:21 PM, Serialize complete at 04/12/2000 04:11:21 PM 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: Doug responded: >ALL METHOD:PUBLISH components MUST have an ORGANIZER per >the iTIP restriction tables. Is there somewhere in iCal or iTIP >that says otherwise? I never claimed it did. I used a slightly OOS example that probably confused you. My apologies for that. Currently there is no way to simply 'export' my non-group calendar entires as iTIP messages since they do not currently contain an ORGANIZER property. This may be an small oversight in iTIP since I can 'export' (aka 'publish') those that do have an ORGANIZER property. That was what I was trying to convey. (Perhaps some text to this effect would be apropriate in iTIP, editors call really). 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... From owner-ietf-calendar@mail.imc.org Wed Apr 12 16:36:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02785 for ; Wed, 12 Apr 2000 16:36:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17788 for ietf-calendar-bks; Wed, 12 Apr 2000 13:12:27 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17783 for ; Wed, 12 Apr 2000 13:12:26 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412201535.SOSB851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 12 Apr 2000 15:15:35 -0500 Message-ID: <38F4CA3E.5C0A68CB@Software.com> Date: Wed, 12 Apr 2000 12:10:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Bruce_Kahn@iris.com wrote: > > Doug responded: > >ALL METHOD:PUBLISH components MUST have an ORGANIZER per > >the iTIP restriction tables. Is there somewhere in iCal or iTIP > >that says otherwise? > > I never claimed it did. I used a slightly OOS example that probably > confused you. My apologies for that. I thought Frank did. > Currently there is no way to simply 'export' my non-group calendar entires > as iTIP messages since they do not currently contain an ORGANIZER > property. This may be an small oversight in iTIP since I can 'export' > (aka 'publish') those that do have an ORGANIZER property. That > was what I was trying to convey. (Perhaps some text to this effect would > be apropriate in iTIP, editors call really). I still have not been convinced you can't add ORGANIZER to your product. I see it (so far) as an oversight in your product. I do not see anywhere in any of the RFCs a statement that says that you MUST NOT have organizer for non-group appointments. -Doug From owner-ietf-calendar@mail.imc.org Wed Apr 12 16:44:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02969 for ; Wed, 12 Apr 2000 16:44:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18397 for ietf-calendar-bks; Wed, 12 Apr 2000 13:25:05 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18393 for ; Wed, 12 Apr 2000 13:25:04 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA01269; Wed, 12 Apr 2000 16:45:12 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA16227; Wed, 12 Apr 2000 16:28:09 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, pregen@egenconsulting.com Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Wed, 12 Apr 2000 16:24:32 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 04:24:38 PM, Serialize complete at 04/12/2000 04:24:38 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006B899D852568BF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B899D852568BF_= Content-Type: text/plain; charset="us-ascii" Bruce: But isn't the common fallback to multipart/alternative and multipart/related a multipart/mixed? -- Frank --=_alternative 006B899D852568BF_= Content-Type: text/html; charset="us-ascii"
Bruce:

But isn't the common fallback to multipart/alternative and multipart/related a multipart/mixed?

-- Frank --=_alternative 006B899D852568BF_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 16:49:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03077 for ; Wed, 12 Apr 2000 16:49:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18484 for ietf-calendar-bks; Wed, 12 Apr 2000 13:28:15 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18480 for ; Wed, 12 Apr 2000 13:28:14 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412203123.SPCV851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 12 Apr 2000 15:31:23 -0500 Message-ID: <38F4CDF1.86DB519F@Software.com> Date: Wed, 12 Apr 2000 12:26:41 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error 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 Frank_Dawson@lotus.com wrote: > > Bruce Kahn, wrote in part: > > >For example #1, thats just an access problem waiting to happen! I grant > >0% access to my local disk for both personal and work reasons. Just not a > >good example to even THINK about. > > Bruce. You had good counter arguments on many of your points. I concede! > > But on this one, the example was use for copy/paste from clipboard. > When I am told to copy an event from a local storage to the OS clipboard. > I will probably render the event with the ATTACH property specifying a > FILE type URL or render the ATTACH content inline. But probably the former. You can if the intended recipient is local to your domain. Or if you export your filesystem to outside of your domain. No one is saying you MUST use a CID or MID when you create or transmit an iCalendar object with attachments. The point is that IF you as the 'recipient' (by whatever means) get an iCalendar object that contains a CID or MID attachment. THEN you MUST be able to handle it. As it is valid for anyone to transmit (by whatever means) a iCalendar object that contains CID's and MID's. This is true for CAP and iMIP. That's why I think it MUST be in iCalenar - as this applies to any transport method. If this were not the case (that the recipient MUST be able to handle a CID or MID). Then you could NEVER send one with a CID or MID and be interoperable. -Doug From owner-ietf-calendar@mail.imc.org Wed Apr 12 17:04:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03438 for ; Wed, 12 Apr 2000 17:04:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA19086 for ietf-calendar-bks; Wed, 12 Apr 2000 13:41:00 -0700 (PDT) Received: from lotus.lotus.com (lotus.lotus.com [192.233.136.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19079 for ; Wed, 12 Apr 2000 13:40:58 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus.lotus.com (8.9.3/8.9.3) with ESMTP id QAA18253; Wed, 12 Apr 2000 16:34:32 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA11643; Wed, 12 Apr 2000 16:05:25 -0400 (EDT) To: Doug Royer Cc: ietf-calendar@imc.org Subject: Re: CALSCH Action Items - - Error X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 12 Apr 1988 16:01:52 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 04:01:54 PM, Serialize complete at 04/12/2000 04:01:54 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00697625852557A0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00697625852557A0_= Content-Type: text/plain; charset="us-ascii" I still disagree that this should be part of iCalendar. It should be a change to iMIP. -- Frank --=_alternative 00697625852557A0_= Content-Type: text/html; charset="us-ascii"
I still disagree that this should be part of iCalendar. It should be a change to iMIP.

-- Frank --=_alternative 00697625852557A0_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 17:25:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03775 for ; Wed, 12 Apr 2000 17:25:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19540 for ietf-calendar-bks; Wed, 12 Apr 2000 14:01:08 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19536; Wed, 12 Apr 2000 14:01:07 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id RAA05581; Wed, 12 Apr 2000 17:21:15 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA17845; Wed, 12 Apr 2000 16:43:49 -0400 (EDT) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Wed, 12 Apr 2000 16:40:12 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/12/2000 04:40:18 PM, Serialize complete at 04/12/2000 04:40:18 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006CF8CA852568BF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CF8CA852568BF_= Content-Type: text/plain; charset="us-ascii" Doug Royer wrote, in part: >I disagree. I do not see any reason that you can not use iTIP >to send an appointment to another person. With only one ATTENDEE >and the ORGANIZER not attending. I think we do agree. Your example is not an appointment, but rather a meeting (i.e., a group scheduled event). Hence, iTIP is a good tool for sending this invitation. An appointment has no ORGANIZER or ATTENDEE. It just has the definition for the event start, end, summary and other stuff. But not any attendees. Hope this helps. -- Frank --=_alternative 006CF8CA852568BF_= Content-Type: text/html; charset="us-ascii"
Doug Royer wrote, in part:

>I disagree. I do not see any reason that you can not use iTIP
>to send an appointment to another person. With only one ATTENDEE
>and the ORGANIZER not attending.

I think we do agree. Your example is not an appointment, but rather a meeting (i.e., a group scheduled event). Hence, iTIP is a good tool for sending this invitation.

An appointment has no ORGANIZER or ATTENDEE. It just has the definition for the event start, end, summary and other stuff. But not any attendees.

Hope this helps.

-- Frank --=_alternative 006CF8CA852568BF_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 12 17:54:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04191 for ; Wed, 12 Apr 2000 17:54:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA20129 for ietf-calendar-bks; Wed, 12 Apr 2000 14:31:23 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20125 for ; Wed, 12 Apr 2000 14:31:22 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000412213431.SQQO851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 12 Apr 2000 16:34:31 -0500 Message-ID: <38F4DCBD.8D75153D@Software.com> Date: Wed, 12 Apr 2000 13:29:49 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Frank_Dawson@lotus.com wrote: > > Doug Royer wrote, in part: > > >I disagree. I do not see any reason that you can not use iTIP > >to send an appointment to another person. With only one ATTENDEE > >and the ORGANIZER not attending. > > I think we do agree. Your example is not an appointment, but rather a > meeting > (i.e., a group scheduled event). Hence, iTIP is a good tool for sending this > invitation. > > An appointment has no ORGANIZER or ATTENDEE. It just has the definition for > the event start, end, summary and other stuff. But not any attendees. Where in iTIP does it specify this? Where in iCalendar does it specify this? Where in iMIP does it specific this? Where in CAP-draft does it specify this? I can't find it. So it looks to me as if you are talking a vendor specific extension? If so - out of scope. If not - where is it? -Doug From owner-ietf-calendar@mail.imc.org Wed Apr 12 22:16:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07763 for ; Wed, 12 Apr 2000 22:16:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA05243 for ietf-calendar-bks; Wed, 12 Apr 2000 18:57:45 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05238 for ; Wed, 12 Apr 2000 18:57:41 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA14342 for ; Wed, 12 Apr 2000 18:57:56 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FSXMXF00.2HE; Wed, 12 Apr 2000 19:00:51 -0700 Message-ID: <38F52A10.776C21ED@netscape.com> Date: Wed, 12 Apr 2000 18:59:44 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.73b1 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org, pregen@egenconsulting.com Subject: Re: Question for list References: Content-Type: multipart/mixed; boundary="------------7F4C2DFAF57990832ACC26A6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7F4C2DFAF57990832ACC26A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > The crux of this dilemma: I cannot use iTIP to backup / restore (or > 'publish') my calendar data via a METHOD:PUBLISH since not every entry has > ORGANIZER and there would be no way to tell when the data can be removed > on import. We have no other METHOD value to use for 'publishing' entries > w/o using METHOD:PUBLISH; Perhaps a new one is in order for these cases > and it would not have the current MUST requirement... Bruce, why do you want to use iTIP for backup/restore? That's not the sort of operation it was designed for. -Steve --------------7F4C2DFAF57990832ACC26A6 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------7F4C2DFAF57990832ACC26A6-- From owner-ietf-calendar@mail.imc.org Thu Apr 13 11:10:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04167 for ; Thu, 13 Apr 2000 11:10:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA22560 for ietf-calendar-bks; Thu, 13 Apr 2000 07:35:59 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22556 for ; Thu, 13 Apr 2000 07:35:58 -0700 (PDT) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA03789 for ; Thu, 13 Apr 2000 10:39:11 -0400 Received: from pc-158.cst.ca (dyn24.int.cst.ca [192.168.1.24]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2X32ADDY; Thu, 13 Apr 2000 10:39:10 -0400 Message-Id: <4.3.0.20000413101117.00ae69e0@apollo> X-Sender: markp@apollo X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 13 Apr 2000 10:38:18 -0400 To: ietf-calendar@imc.org From: Mark Paterson Subject: Re: Question for list In-Reply-To: <38F4A3F2.6E443FC2@Software.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A PUBLISH event MUST have an ORGANIZER What is a non-group scheduled event? There seems to be a consensus from the email that's been flying back and forth that the distinction here is based on wether there is an attendee list or not. It may be that specs define this somewhere (I admit I don't know them backwards and forwards and can't recite lines from them as some of you can) but the real distinction I think is whether the event effects more than one person. In each of the examples that have been put forth in the last few emails on the subject (the softball tryouts, the boss informing his employee of his vacation) more than one person is being effected wether or not there is a real attendee list in the more traditional sense. So something may be a non-group scheduled event while it sits in your Agenda on your computer when you go to PUBLISH it you are in fact changing it to be an event that now effects a group of people wether or not these people are actually part of an attendee list or not. Therefore once you decide to send out a PUBLISH you now need an ORGANIZER so the recipient's CUA can properly keep track of it. Once again, as I mentioned above, I don't know the specs off by heart and I am not trying to interpret them here in any way but rather I am trying to take a step back and look at it from the consumer level of what makes common sense. Mark Paterson -- Mark Paterson (markp@cst.ca) Director, Client Development, CS&T - Lexacom From owner-ietf-calendar@mail.imc.org Thu Apr 13 12:52:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07637 for ; Thu, 13 Apr 2000 12:52:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24608 for ietf-calendar-bks; Thu, 13 Apr 2000 09:32:09 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24604 for ; Thu, 13 Apr 2000 09:32:07 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA24447 for ; Thu, 13 Apr 2000 09:29:49 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FSYREX00.K2E; Thu, 13 Apr 2000 09:35:21 -0700 Message-ID: <38F5F707.934261B3@netscape.com> Date: Thu, 13 Apr 2000 09:34:15 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.73b1 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Paterson CC: ietf-calendar@imc.org Subject: Re: Question for list References: <4.3.0.20000413101117.00ae69e0@apollo> Content-Type: multipart/mixed; boundary="------------EFD15699AF78899CB72310E3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EFD15699AF78899CB72310E3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > A PUBLISH event MUST have an ORGANIZER > > So something may be a non-group scheduled event while it sits in your > Agenda on your computer when you go to PUBLISH it you are in fact changing > it to be an event that now effects a group of people wether or not these > people are actually part of an attendee list or not. Therefore once you > decide to send out a PUBLISH you now need an ORGANIZER so the recipient's > CUA can properly keep track of it. This is the spirit of what we put into iTIP. In particular, the Organizer is required so that if you receive an updated version of the PUBLISH'd event, you have some basis for determining that the update is legitimate -- from a "role" point of view, not from a security point of view. Only the Organizer can change the event (see iTIP 6.1.1 Spoofing the "Organizer") Furthermore, if someone puts a copy of a published event into their calendar and does a REFRESH, we need to know where to direct the refresh request. It goes back to the Organizer. -Steve --------------EFD15699AF78899CB72310E3 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------EFD15699AF78899CB72310E3-- From owner-ietf-calendar@mail.imc.org Thu Apr 13 12:52:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07659 for ; Thu, 13 Apr 2000 12:52:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24152 for ietf-calendar-bks; Thu, 13 Apr 2000 09:13:44 -0700 (PDT) Received: from lotus.lotus.com (lotus.lotus.com [192.233.136.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24148 for ; Thu, 13 Apr 2000 09:13:43 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus.lotus.com (8.9.3/8.9.3) with ESMTP id MAA06208; Thu, 13 Apr 2000 12:08:11 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA07840; Thu, 13 Apr 2000 11:48:39 -0400 (EDT) To: Mark Paterson Cc: ietf-calendar@imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Thu, 13 Apr 2000 12:44:53 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/13/2000 11:45:06 AM, Serialize complete at 04/13/2000 11:45:06 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0057753A852568C0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057753A852568C0_= Content-Type: text/plain; charset="us-ascii" Mark: This seems to make sense to me. So, If I take a personal "appointment" on my calendar and export it to a file system, as a PUBLISH method iCalendar object, it needs to have the ORGANIZER specified (value set to my MAILTO URL) and then it becomes a group-scheduled event. I guess I could also emit the event as a non-iTIP iCalendar object (just conforming to RFC2445) without the ORGANIZER or the METHOD. Right? Thanks. -- Frank --=_alternative 0057753A852568C0_= Content-Type: text/html; charset="us-ascii"
Mark:

This seems to make sense to me.

So, If I take a personal "appointment" on my calendar and export it to a file system, as a PUBLISH method iCalendar object, it needs to have the ORGANIZER specified (value set to my MAILTO URL) and then it becomes a group-scheduled event.

I guess I could also emit the event as a non-iTIP iCalendar object (just conforming to RFC2445) without the ORGANIZER or the METHOD. Right?

Thanks.

-- Frank

--=_alternative 0057753A852568C0_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 13 13:38:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09170 for ; Thu, 13 Apr 2000 13:38:48 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA25674 for ietf-calendar-bks; Thu, 13 Apr 2000 10:17:23 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25667 for ; Thu, 13 Apr 2000 10:17:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA26634 for ; Thu, 13 Apr 2000 10:17:35 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FSYTI700.66I; Thu, 13 Apr 2000 10:20:31 -0700 Message-ID: <38F6019D.1C1CF936@netscape.com> Date: Thu, 13 Apr 2000 10:19:25 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.73b1 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Mark Paterson , ietf-calendar@imc.org Subject: Re: Question for list References: Content-Type: multipart/mixed; boundary="------------D2F2215643533B3F9D7073FF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D2F2215643533B3F9D7073FF Content-Type: multipart/alternative; boundary="------------CD02DD4CF28755784B120C2F" --------------CD02DD4CF28755784B120C2F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > > Mark: > > This seems to make sense to me. > > So, If I take a personal "appointment" on my calendar and export it to > a file system, as a PUBLISH method iCalendar object, it needs to have > the ORGANIZER specified (value set to my MAILTO URL) and then it > becomes a group-scheduled event. > > I guess I could also emit the event as a non-iTIP iCalendar object > (just conforming to RFC2445) without the ORGANIZER or the METHOD. > Right? Seems right to me. If I just wanted to archive a copy of an event for my personal use, there is no need to use iTIP verbs. It's only when the goal is to interoperate in a generic fashion that using the iTIP semantics comes into play. That way, all applications make the same assumptions about how things are done, what will be present and what won't. -Steve --------------CD02DD4CF28755784B120C2F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote:

 
Mark:

This seems to make sense to me.

So, If I take a personal "appointment" on my calendar and export it to a file system, as a PUBLISH method iCalendar object, it needs to have the ORGANIZER specified (value set to my MAILTO URL) and then it becomes a group-scheduled event.

I guess I could also emit the event as a non-iTIP iCalendar object (just conforming to RFC2445) without the ORGANIZER or the METHOD. Right?

Seems right to me. If I just wanted to archive a copy of an event for my personal use, there is no need to use iTIP verbs.  It's only when the goal is to interoperate in a generic fashion that using the iTIP semantics comes into play. That way, all applications make the same assumptions about how things are done, what will be present and what won't.

-Steve
  --------------CD02DD4CF28755784B120C2F-- --------------D2F2215643533B3F9D7073FF Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------D2F2215643533B3F9D7073FF-- From owner-ietf-calendar@mail.imc.org Thu Apr 13 15:36:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12034 for ; Thu, 13 Apr 2000 15:36:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28415 for ietf-calendar-bks; Thu, 13 Apr 2000 12:15:20 -0700 (PDT) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28411 for ; Thu, 13 Apr 2000 12:15:18 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: sman@netscape.com (Steve Mansour) Cc: ietf-calendar@imc.org, pregen@egenconsulting.com Subject: Re: Question for list X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Thu, 13 Apr 2000 15:18:26 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/13/2000 03:21:59 PM, Serialize complete at 04/13/2000 03:21:59 PM 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: Steve asked: >Bruce, why do you want to use iTIP for backup/restore? That's not the sort of operation it was designed for. It was an example that was partly OOS for the discussion. My use of backup/restore is beyond what iTIP can do. If I want to use iTIP to 'publish' my calendar entires that are NOT scheduled w/others (ie: my doctor appointment, my Boston Marathon schedule blocking entry, etc) then I CANNOT do it w/iTIP as it stands since iTIP PUBLISH (not publish) requires and ORGANIZER but my entries have none. I now consider this a loophole in iTIP... I merely used backup/restore as an extension to this thought of publishing (not PUBLISHing) and then reimporting to perform a backup/restore scenario. Please remove that part of the thread from your memory! 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... From owner-ietf-calendar@mail.imc.org Thu Apr 13 15:48:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12524 for ; Thu, 13 Apr 2000 15:48:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28543 for ietf-calendar-bks; Thu, 13 Apr 2000 12:22:45 -0700 (PDT) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28539 for ; Thu, 13 Apr 2000 12:22:43 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Thu, 13 Apr 2000 15:26:03 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/13/2000 03:29:25 PM, Serialize complete at 04/13/2000 03:29:25 PM 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: Doug replied: >I still have not been convinced you can't add ORGANIZER to >your product. I see it (so far) as an oversight in your product. It is NOT an oversight in my product (or anyones product) if there is no ORGANIZER for a personal calendar entry. The presence of an ORGANIZER implies that there is workflow or scheduling going on. Im simply blocking out Monday, 4/17/2000 on my calendar so I can volunteer for the Boston Marathon. Im _NOT_ scheduling the Marathon so Im not the ORGANIZER. If you recheck RFC 2445, 4.8.4.3 you will see: Conformance: This property MUST be specified in an iCalendar object that specifies a group scheduled calendar entity. This property MUST be specified in an iCalendar object that specifies the publication of a calendar user's busy time. This property MUST NOT be specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but are entities only on a single user's calendar. Red highlights mine; for those MIME impaired the last line is the key phrase. So, for a non-group scheduled entries like my private ones I dont (and MUST NOT) have an ORGANIZER. So just how can I use iTIP to PUBLISH it?!? I must be a bit slow this week if Im just not seeing it. Can someone explain how to publish my non group scheduled entries using iTIP? For now I claim it cannot be done and I consider it an oversight or loophole in iTIP. 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... From owner-ietf-calendar@mail.imc.org Thu Apr 13 16:18:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13101 for ; Thu, 13 Apr 2000 16:18:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA29057 for ietf-calendar-bks; Thu, 13 Apr 2000 12:59:34 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29053 for ; Thu, 13 Apr 2000 12:59:31 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000413200242.TMFF851310.mta1biz.bizmailsrvcs.net@Software.com>; Thu, 13 Apr 2000 15:02:42 -0500 Message-ID: <38F618AE.705EDB3D@Software.com> Date: Thu, 13 Apr 2000 11:57:50 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: Question for list 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 Bruce_Kahn@iris.com wrote: > If you recheck RFC 2445, 4.8.4.3 you will see: > > Conformance: This property MUST be specified in an iCalendar object > that specifies a group scheduled calendar entity. This property MUST > be specified in an iCalendar object that specifies the publication of > a calendar user's busy time. This property MUST NOT be specified in > an iCalendar object that specifies only a time zone definition or > that defines calendar entities that are not group scheduled entities, > but are entities only on a single user's calendar. > > Red highlights mine; for those MIME impaired the last line is the key > phrase. > > So, for a non-group scheduled entries like my private ones I dont (and > MUST NOT) have an ORGANIZER. So just how can I use iTIP to PUBLISH it?!? > I must be a bit slow this week if Im just not seeing it. Can someone > explain how to publish my non group scheduled entries using iTIP? For now > I claim it cannot be done and I consider it an oversight or loophole in > iTIP. Okay I understand your point. You are saying that because 2445 says if it does not have an ORGANIZER - then it's not a group appointment. Now consider this: IF we were to change it to say: "This property MUST NOT be specified in an iCalendar object that specifies only a time zone definition." I don't see how that would hurt anything. Can there be a group on ONE? I don't see why not. If so, what't the difference. Frank (I think) said that you could not tell if it was a group appointment. So what? Why is that a bad thing? If you are going to SCHEDULE it, then use iTIP and add ORGANIZER. If you want to get/put it - then use CAP. -OR- *IF* you were to add ORGANIZER to your group-of-one appointment. Why do you care? I do not see that anything in the protocol is busted. So far - I just hear "I don't want to". But I am sure there is a reason. I just do not see it yet. -Doug From owner-ietf-calendar@mail.imc.org Thu Apr 13 16:26:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13251 for ; Thu, 13 Apr 2000 16:26:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA29126 for ietf-calendar-bks; Thu, 13 Apr 2000 13:03:42 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29122 for ; Thu, 13 Apr 2000 13:03:39 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000413200652.TMHW851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Thu, 13 Apr 2000 15:06:52 -0500 Message-ID: <38F619A9.99842C9C@Software.com> Date: Thu, 13 Apr 2000 12:02:01 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Bruce_Kahn@iris.com wrote: > ... Can someone > explain how to publish my non group scheduled entries using iTIP? The whole concept of 'schedule' implies with someone or something else - so who would you be scheduling it with? > For now > I claim it cannot be done and I consider it an oversight or loophole in > iTIP. I see it (so far) as out of scope for iTIP - as it is not scheduling. It looks to me as if you are saying - You want to transfer a non-scheduling iCalendar object, with a scheduling protocol. Direct booking is a CAP thing - not an iTIP thing. There are also other things you can not do in iTIP, that't why CAP exits. -Doug From owner-ietf-calendar@mail.imc.org Thu Apr 13 17:22:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14290 for ; Thu, 13 Apr 2000 17:22:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA00287 for ietf-calendar-bks; Thu, 13 Apr 2000 13:58:33 -0700 (PDT) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00283 for ; Thu, 13 Apr 2000 13:58:31 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Doug Royer Cc: ietf-calendar@imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Thu, 13 Apr 2000 17:01:37 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/13/2000 05:05:13 PM, Serialize complete at 04/13/2000 05:05:13 PM 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: Doug also wrote: >-OR- *IF* you were to add ORGANIZER to your group-of-one appointment. >Why do you care? I do not see that anything in the protocol is busted. I care because there is a semantic difference. One involves no workflow, the other does. Are you suggesting we revise the RFCs to mandate ORGANZIER always be there for group and non-group entries?? As for busted, see my previous replys example about 10 missing entries. >So far - I just hear "I don't want to". But I am sure there is a reason. >I just do not see it yet. Ive been saying "Ya cant get there from here." So far you agree w/my example but the solution ("Use CAP") is not reasonable to the scenario. This is not an issue of real time access, etc; its an issue of not being able to publish my entire calendar (just those that Ive scheduled with other folks). "Use CAP" still wont allow me to publish my entire calendar to a file!!! FMI: Just what METHOD value would be used for those non-group entries?!?!? YOU DONT HAVE ONE WITH OR WITHOUT CAP SINCE CAP DOESNT ADDRESS THIS CASE EITHER! 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... From owner-ietf-calendar@mail.imc.org Thu Apr 13 18:05:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14936 for ; Thu, 13 Apr 2000 18:05:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01074 for ietf-calendar-bks; Thu, 13 Apr 2000 14:45:38 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01070 for ; Thu, 13 Apr 2000 14:45:37 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000413214851.TOQP851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Thu, 13 Apr 2000 16:48:51 -0500 Message-ID: <38F6318F.884054D8@Software.com> Date: Thu, 13 Apr 2000 13:43:59 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Bruce_Kahn@iris.com wrote: > > Doug also wrote: > >-OR- *IF* you were to add ORGANIZER to your group-of-one appointment. > >Why do you care? I do not see that anything in the protocol is busted. > > I care because there is a semantic difference. One involves no workflow, the other does. What workflow? I see nothing in iCalendar or iTIP using the word 'workflow'. Do you mean scheduling? If so, if the METHOD is CREATE as stored in the CS per CAP - then there is no scheduling to perform. If METHOD is REQUEST - then you have a REQUEST to act on. If METHOD is REPLY then you have reply that needs sent . . . > Are you suggesting > we revise the RFCs to mandate ORGANZIER always be there for group and > non-group entries?? No I am saying ether the current object needs action or it does not. And that iTIP is for scheduling - and not anything else. > As for busted, see my previous replys example about 10 missing entries. > > >So far - I just hear "I don't want to". But I am sure there is a reason. > >I just do not see it yet. > > Ive been saying "Ya cant get there from here." So far you agree w/my > example but the solution ("Use CAP") is not reasonable to the scenario. Why is it not reasonable? Out of scope for iTIP as iTIP is not direct booking - it is scheduling. iTIP is not busted - it's just that you wish to extend iTIP to do direct booking of non-scheduling objects - correct? > This is not an issue of real time access, etc; its an issue of not being > able to publish my entire calendar (just those that Ive scheduled with> > other folks). PUBLISH is in iTIP scheduling concept - that uses ORGANIZER. It is not a direct booking concept. > "Use CAP" still wont allow me to publish my entire calendar to a file!!! Not true. CAP will allow you to retrieve the entire contents via METHOD:READ PUBLISH? If you mean copy the contents to a file - not directly, but it can allow you to do that. Backup/Restore is out of scope for iTIP. The WG has already agreed backup/restore is out of scope for iTIP and CAP. > FMI: Just > what METHOD value would be used for those non-group entries?!?!? iTIP - None at all - as it is not a scheduling request. CAP - METHOD:CREATE to create it in your store. METHOD:READ with a VQUERY to pull it out. > YOU DONT HAVE ONE WITH OR WITHOUT CAP SINCE CAP DOESNT ADDRESS > THIS CASE EITHER! So far there is NO CAP restriction table - so why have you reached this conclusion? And you are incorrect as you CAN place a non-scheduling object into your CS using CAP. And you can pull them out. CAP can transfer scheduling METHODs into/from your calendar. It can also put/get (METHOD:CREATE/METHOD:READ) into/from your CS with CAP directly booking objects. This is precisely one of the primary reasons that CAP exists. What you do with it is up to you (file, ...). -Doug From owner-ietf-calendar@mail.imc.org Thu Apr 13 18:32:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15208 for ; Thu, 13 Apr 2000 18:32:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01634 for ietf-calendar-bks; Thu, 13 Apr 2000 15:12:23 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01629 for ; Thu, 13 Apr 2000 15:12:22 -0700 (PDT) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA08078; Thu, 13 Apr 2000 18:15:35 -0400 Received: from pc-158.cst.ca (dyn24.int.cst.ca [192.168.1.24]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2X32A1KB; Thu, 13 Apr 2000 18:15:34 -0400 Message-Id: <4.3.0.20000413180639.00ad95f0@apollo> X-Sender: markp@apollo X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 13 Apr 2000 18:14:42 -0400 To: Frank_Dawson@lotus.com From: Mark Paterson Subject: Re: Question for list Cc: ietf-calendar@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:44 PM 4/13/00 -0400, Frank_Dawson@lotus.com wrote:

Mark:

This seems to make sense to me.

So, If I take a personal "appointment" on my calendar and export it to a file system, as a PUBLISH method iCalendar object, it needs to have the ORGANIZER specified (value set to my MAILTO URL) and then it becomes a group-scheduled event.

I guess I could also emit the event as a non-iTIP iCalendar object (just conforming to RFC2445) without the ORGANIZER or the METHOD. Right?

Sure. That seems reasonable. After all you aren't really trying to schedule people in this sort of example so what you suggest does the trick as well.

Mark

--
Mark Paterson (markp@cst.ca)
Director, Client Development, CS&T - Lexacom From owner-ietf-calendar@mail.imc.org Thu Apr 13 18:32:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15221 for ; Thu, 13 Apr 2000 18:32:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01651 for ietf-calendar-bks; Thu, 13 Apr 2000 15:12:55 -0700 (PDT) Received: from capricorn.iris.com (capricorn.iris.com [198.112.211.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01646 for ; Thu, 13 Apr 2000 15:12:41 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Doug Royer Cc: ietf-calendar@imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Thu, 13 Apr 2000 16:44:20 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_M2_03122000|March 12, 2000) at 04/13/2000 06:16:37 PM, Serialize complete at 04/13/2000 06:16:38 PM, Serialize by Router on Capricorn/Iris(Build V60_M2_03122000|March 12, 2000) at 04/13/2000 06:16:38 PM 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: Doug proposed: >IF we were to change it to say: > > "This property MUST NOT be specified in an iCalendar object that > specifies only a time zone definition." > >I don't see how that would hurt anything. I think it would make it worse by making it even more vague and open to several possible interpretations. That makes interop harder, not easier. An alternative is to add a new method to iTIP that is akin to PUBLISH but does not require ORGANZIER. Im not suggesting we change PUBLISH! Its current definition has a good use (just not quite as comprehensive as we need it). The logic for the original 2446 requirements still stands. The case I presented is a new one that may merit a new method... 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... From owner-ietf-calendar@mail.imc.org Thu Apr 13 18:32:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15235 for ; Thu, 13 Apr 2000 18:32:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01645 for ietf-calendar-bks; Thu, 13 Apr 2000 15:12:41 -0700 (PDT) Received: from capricorn.iris.com (capricorn.iris.com [198.112.211.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01637 for ; Thu, 13 Apr 2000 15:12:28 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Build V60_04062000 April 06, 2000 Message-ID: Date: Thu, 13 Apr 2000 16:40:51 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_M2_03122000|March 12, 2000) at 04/13/2000 06:16:26 PM, Serialize complete at 04/13/2000 06:16:26 PM 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: Doug asked: >> ... Can someone >> explain how to publish my non group scheduled entries using iTIP? > >The whole concept of 'schedule' implies with someone or something >else - so who would you be scheduling it with? Ok, probably a misphrased term to use in this group. I was considering MY entire calendar (group entries and personal entries and reminders etc) to be my 'schedule' as in "How does your schedule look?" where you dont just consider those entries that involve you AND others but ALL your entries. I was using it in the sense of "a written or printed list, catalog, or inventory; also : TIMETABLE " rather than in the sense of "a procedural plan that indicates the time and sequence of each operation" or the process we are so intimately involved with. >It looks to me as if you are saying - You want to transfer >a non-scheduling iCalendar object, with a scheduling protocol. Not quite. Back up and reconsider the scenario I was using. I have a calendar with 100 entries; 90 are 'group' entries Ive scheduled (Dougs mind set) with others, 10 are entries Ive put on my calendar to block out time and serve as reminders, place holders, etc. The latter group has no ORGANIZER, the former group does. As the CIO I want to publish my schedule so that my direct reports can see when Im booked and when Im not. Using iTIP I can ONLY publish (yes PUBLISH) my 90 group entries. I have NO way to publish my other 10 entries that are also part of my calendar! So how would you suggest I publish those remaining 10? Some other means besides iTIP means iTIP for publishing calendars has a loophole where not all my available data can be presented. Is this a show stopper for now? Nope. Is it something that should be looked at eventually? Yes. We are updating 2445 and 2447 so why not 2446?? 'Nuf said on this topic and back to work... 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... From owner-ietf-calendar@mail.imc.org Thu Apr 13 21:41:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17088 for ; Thu, 13 Apr 2000 21:41:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA09305 for ietf-calendar-bks; Thu, 13 Apr 2000 18:18:57 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09298; Thu, 13 Apr 2000 18:18:55 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA28419; Thu, 13 Apr 2000 21:39:12 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA07178; Thu, 13 Apr 2000 21:22:09 -0400 (EDT) To: Doug Royer Cc: Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Thu, 13 Apr 2000 22:18:23 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/13/2000 09:18:33 PM, Serialize complete at 04/13/2000 09:18:33 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000820DC852568C1_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000820DC852568C1_= Content-Type: text/plain; charset="us-ascii" Doug Royer wrote, in part: >So far - I just hear "I don't want to". But I am sure there is a reason. >I just do not see it yet. The point was, why should we have to specify an Organizer for every instance. It makes no sense for an appointment. I am sure there will be other cases. In addition, many have repeated here in this mailing list that iCalendar is just a data dictionary for describing calendar information. Certainly, there are good reasons NOT to specify an ORGANIZER property on an appointment. There is no "organizer". It isn't a group meeting organized by anyone. It is just as arbitrary to require it for appointments. So your argument isn't any better. Haven't heard anyone say it shouldn't be there for an iCalendar object conforming to iTIP. But if you are a new application of iCalendar, I can't fathom why we would even consider arbitrarily mandating it. -- Frank --=_alternative 000820DC852568C1_= Content-Type: text/html; charset="us-ascii"
Doug Royer wrote, in part:

>So far - I just hear "I don't want to". But I am sure there is a reason.
>I just do not see it yet.

The point was, why should we have to specify an Organizer for every instance. It makes no sense for an appointment. I am sure there will be other cases. In addition, many have repeated here in this mailing list that iCalendar is just a data dictionary for describing calendar information.

Certainly, there are good reasons NOT to specify an ORGANIZER property on an appointment. There is no "organizer". It isn't a group meeting organized by anyone. It is just as arbitrary to require it for appointments. So your argument isn't any better.

Haven't heard anyone say it shouldn't be there for an iCalendar object conforming to iTIP. But if you are a new application of iCalendar, I can't fathom why we would even consider arbitrarily mandating it.

-- Frank --=_alternative 000820DC852568C1_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 13 21:43:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17164 for ; Thu, 13 Apr 2000 21:43:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA10217 for ietf-calendar-bks; Thu, 13 Apr 2000 18:22:44 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10212 for ; Thu, 13 Apr 2000 18:22:42 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA28723 for ; Thu, 13 Apr 2000 21:43:20 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA07490 for ; Thu, 13 Apr 2000 21:26:17 -0400 (EDT) To: ietf-calendar@imc.org Subject: Re: Question for list X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Thu, 13 Apr 2000 22:22:31 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/13/2000 09:22:41 PM, Serialize complete at 04/13/2000 09:22:41 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000881C5852568C1_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000881C5852568C1_= Content-Type: text/plain; charset="us-ascii" Doug: Your arguments are presuming support for CAP. This seems circular. I don't plan on supporting CAP, but I am planning on supporting the published C&S standards, iCalendar, iTIP and iMIP. They are independent of CAP. So, you can't argue for us to use CAP for these other things. I can just as easily just use iCalendar. -- Frank --=_alternative 000881C5852568C1_= Content-Type: text/html; charset="us-ascii"
Doug:

Your arguments are presuming support for CAP. This seems circular. I don't plan on supporting CAP, but I am planning on supporting the published C&S standards, iCalendar, iTIP and iMIP.

They are independent of CAP. So, you can't argue for us to use CAP for these other things. I can just as easily just use iCalendar.

-- Frank --=_alternative 000881C5852568C1_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 13 21:52:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18077 for ; Thu, 13 Apr 2000 21:52:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12269 for ietf-calendar-bks; Thu, 13 Apr 2000 18:33:11 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA12260 for ; Thu, 13 Apr 2000 18:33:10 -0700 (PDT) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA04192; Thu, 13 Apr 00 21:36:51 EDT Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id VAA10773 for ; Thu, 13 Apr 2000 21:36:55 -0400 (EDT) Received: from [216.254.65.44] (bobmah-2.dsl.speakeasy.net [216.254.65.44]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id VAA08786 for ; Thu, 13 Apr 2000 21:36:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: bobmah@18.69.0.43 Message-Id: In-Reply-To: References: Date: Thu, 13 Apr 2000 21:36:26 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Re: Question for list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just a reminder- it is not at all inconceivable that the CAP work will lead to changes in iCalendar. I'm not saying it necessarily will, but it's important to bear in mind that even those choosing not to pursue CAP may see the CAP work impact iCalendar down the road. -Bob From owner-ietf-calendar@mail.imc.org Fri Apr 14 16:03:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13669 for ; Fri, 14 Apr 2000 16:03:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04673 for ietf-calendar-bks; Fri, 14 Apr 2000 12:39:49 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04669 for ; Fri, 14 Apr 2000 12:39:48 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000414194307.UIXO851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Fri, 14 Apr 2000 14:43:07 -0500 Message-ID: <38F7658E.960F316D@Software.com> Date: Fri, 14 Apr 2000 11:38:06 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Bruce_Kahn@iris.com wrote: > > Doug proposed: > >IF we were to change it to say: > > > > "This property MUST NOT be specified in an iCalendar > object that > > specifies only a time zone definition." > > > >I don't see how that would hurt anything. > > I think it would make it worse by making it even more vague and open to > several possible interpretations. That makes interop harder, not easier. > An alternative is to add a new method to iTIP that is akin to PUBLISH but > does not require ORGANZIER. Im not suggesting we change PUBLISH! Its current definition has a good use I would agree that we need new methods for non-scheduling appointments. I do not think we should tweek with iTIP. It chould be seperate. From owner-ietf-calendar@mail.imc.org Fri Apr 14 16:03:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13681 for ; Fri, 14 Apr 2000 16:03:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04705 for ietf-calendar-bks; Fri, 14 Apr 2000 12:42:08 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04701 for ; Fri, 14 Apr 2000 12:42:07 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000414194526.UIZC851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Fri, 14 Apr 2000 14:45:26 -0500 Message-ID: <38F76619.F4058ACA@Software.com> Date: Fri, 14 Apr 2000 11:40:25 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: Question for list 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 Bruce_Kahn@iris.com wrote: > > Doug asked: > >> ... Can someone > >> explain how to publish my non group scheduled entries using iTIP? > > > >The whole concept of 'schedule' implies with someone or something > >else - so who would you be scheduling it with? > > Ok, probably a misphrased term to use in this group. I was considering MY > entire calendar (group entries and personal entries and reminders etc) to > be my 'schedule' as in "How does your schedule look?" where you dont just > consider those entries that involve you AND others but ALL your entries. I > was using it in the sense of "a written or printed list, catalog, or inventory; also : TIMETABLE " rather than in the sense of "a procedural plan that indicates the time and sequence of each operation" or the process we are so intimately involved with. I understand what you are doing. That is not what I am saying. I am saying that we had MANY of these discussions with the MANY iTIP drafts came out. And the WG decided iTIP was for scheduling. If we are going to do something, it needs to be new work. > >It looks to me as if you are saying - You want to transfer > >a non-scheduling iCalendar object, with a scheduling protocol. > > Is this a show stopper for now? Nope. Is it something that should be > looked at eventually? Yes. We are updating 2445 and 2447 so why not > 2446?? 'Nuf said on this topic and back to work... CAP address non-scheduling METHOD's, lets not invent yet another. -Doug From owner-ietf-calendar@mail.imc.org Fri Apr 14 16:08:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13759 for ; Fri, 14 Apr 2000 16:08:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04813 for ietf-calendar-bks; Fri, 14 Apr 2000 12:48:36 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04809 for ; Fri, 14 Apr 2000 12:48:35 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000414195154.UJDI851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Fri, 14 Apr 2000 14:51:54 -0500 Message-ID: <38F7679D.4A77C42D@Software.com> Date: Fri, 14 Apr 2000 11:46:53 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: Question for list 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 Frank_Dawson@lotus.com wrote: > > Doug: > > Your arguments are presuming support for CAP. This seems circular. I don't > plan on supporting CAP, but I am planning on supporting the published C&S > standards, iCalendar, iTIP and iMIP. 'non-scheduling iTIP' - is not on the WG charter. Currently we are defining ways to book non-scheduling items in a CS. > They are independent of CAP. So, you can't argue for us to use CAP for these > other things. I can just as easily just use iCalendar. I can argue for CAP :-) use CAP ;-) CAP in in process - if the new METHOD values can be used for other things great - but PLEASE lets not invent another way to represent the same thing! -Doug From owner-ietf-calendar@mail.imc.org Fri Apr 14 16:10:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13824 for ; Fri, 14 Apr 2000 16:10:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04821 for ietf-calendar-bks; Fri, 14 Apr 2000 12:49:45 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04817 for ; Fri, 14 Apr 2000 12:49:44 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000414195303.UJDX851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Fri, 14 Apr 2000 14:53:03 -0500 Message-ID: <38F767E2.52FD88EE@Software.com> Date: Fri, 14 Apr 2000 11:48:02 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Bob Mahoney wrote: > > Just a reminder- it is not at all inconceivable that the CAP work > will lead to changes in iCalendar. I'm not saying it necessarily > will, but it's important to bear in mind that even those choosing not > to pursue CAP may see the CAP work impact iCalendar down the road. Yes. And booking as we call it, it precisely what Bruce and Frank seem to want. -Doug From owner-ietf-calendar@mail.imc.org Fri Apr 14 16:13:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13878 for ; Fri, 14 Apr 2000 16:13:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04736 for ietf-calendar-bks; Fri, 14 Apr 2000 12:45:01 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04729 for ; Fri, 14 Apr 2000 12:45:00 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000414194819.UJAZ851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Fri, 14 Apr 2000 14:48:19 -0500 Message-ID: <38F766C6.A2E3F77C@Software.com> Date: Fri, 14 Apr 2000 11:43:18 -0700 From: Doug Royer Reply-To: ietf-calendar@mail.imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Frank_Dawson@lotus.com wrote: > > Doug Royer wrote, in part: > > >So far - I just hear "I don't want to". But I am sure there is a reason. > >I just do not see it yet. > > The point was, why should we have to specify an Organizer for every > instance. It makes no sense for an appointment. I am sure there will be > other cases. In addition, many have repeated here in this mailing list > that iCalendar is just a data dictionary for describing calendar > information. That is one of the primary reasons for CAP. > Certainly, there are good reasons NOT to specify an ORGANIZER property on an > appointment. There is no "organizer". It isn't a group meeting organized by > anyone. It is just as arbitrary to require it for appointments. So your > argument isn't any better. True - but these discussions a year ago on the WG list yielded that iTIP was for scheduling only. > Haven't heard anyone say it shouldn't be there for an iCalendar object > conforming to iTIP. But if you are a new application of iCalendar, I can't > fathom why we would even consider arbitrarily mandating it. Great! That's one of the things CAP does. It defines new methods for booked appointments. I have no problem if the new methods are usabale in other places than CAP. -Doug From owner-ietf-calendar@mail.imc.org Fri Apr 14 17:36:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14801 for ; Fri, 14 Apr 2000 17:36:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA06142 for ietf-calendar-bks; Fri, 14 Apr 2000 14:15:22 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06138 for ; Fri, 14 Apr 2000 14:15:20 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000414211839.ULBT851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Fri, 14 Apr 2000 16:18:39 -0500 Message-ID: <38F77BF1.317C0F8D@Software.com> Date: Fri, 14 Apr 2000 13:13:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Question for list 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 Bruce_Kahn@iris.com wrote: > Is this a show stopper for now? Nope. Is it something that should be > looked at eventually? Yes. We are updating 2445 and 2447 so why not > 2446?? 'Nuf said on this topic and back to work... We are updating 2445 for two reasons: (1) Errors found during interoperability testing. (2) New items found as a result of the WG chartered CAP work. It was felt (by the AD's? - Patricia/Bob?) that it would be better when we release CAP to include any changes (not additions) at the same time as item (1) above. Their idea was that it was better to not confuse people by incompatible specs. So we are not adding to iCalendar, nor should we add to iTIP. Is there a BUG list for iTIP? I personally do not have a problem with extending the charter for SKiCal or this new work. It's just currently out of scope if you read the WG charter. -Doug From owner-ietf-calendar@mail.imc.org Sun Apr 16 03:26:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03123 for ; Sun, 16 Apr 2000 03:26:38 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA06638 for ietf-calendar-bks; Sat, 15 Apr 2000 23:56:21 -0700 (PDT) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06634 for ; Sat, 15 Apr 2000 23:56:19 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA22248 for ietf-calendar@imc.org; Sun, 16 Apr 2000 00:00:04 -0700 (PDT) Date: Sun, 16 Apr 2000 00:00:04 -0700 (PDT) From: Doug Royer Message-Id: <200004160700.AAA22248@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM ? Y ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@mail.imc.org Sun Apr 16 12:34:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08843 for ; Sun, 16 Apr 2000 12:34:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22130 for ietf-calendar-bks; Sun, 16 Apr 2000 09:10:36 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22126 for ; Sun, 16 Apr 2000 09:10:35 -0700 (PDT) From: andrec@cst.ca Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA22325 for ; Sun, 16 Apr 2000 12:14:03 -0400 Received: by apollo.CST.CA with Internet Mail Service (5.5.2650.21) id <2X32AGVV>; Sun, 16 Apr 2000 12:14:03 -0400 Message-ID: To: ietf-calendar@imc.org Subject: CS&T/Lexacom support statement for CAP ! Date: Sun, 16 Apr 2000 12:14:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: People, Although the CS&T/Lexacom position on standards is well known, because of a public statement from Frank Dawson questioning the suitability of CAP and because of interrogations it raised, we felt it was appropriate to reiterate our strong support to the CALSCHED group and its on-going effort in producing CAP. At CS&T/Lexacom, we believe that the standardization process not only gives the consumer of the technology a greater choice of alternatives, it also allows the best developers of technology to stand out from the crowd. Because of that, CS&T has developed a competitive philosophy based on the support of the standardization efforts in the areas in which CS&T operates. Since the first meeting in 1996 we have been actively involved in the CALSCHED group. We are members of the WAP forum through our Lexacom division. More recently, we have joined the SyncML group. More information can be found in the following press releases: http://www.cst.ca/new/releases/IETF.htm http://www.cst.ca/new/releases/SyncML.html. http://www.lexacom.com/Lexacom/html/sitemap_frameset.html That being said, we believe one of the most important standardization going on in the CALSCHED group is the current CAP work. I am deeply convinced that CAP will finally address the client-to-server inter-changeability that the calendaring and scheduling world has been so desperately missing. Finally, the calendaring/scheduling industry will have its own "IMAP4"! Today, resources in our Product Development group are assigned to the support of CAP and we are looking forward with enthusiasm to a not so distant day where CAP will reach the RFC level. Once that happens we will be in a position to state our official road map for the availability of our products with CAP capabilities. Meanwhile, we will continue to support the work on CAP, and we will continue to invest resources towards its successful completion and acceptance. Having been involved in the calendaring world for many years now, I have no hesitation to say that CAP is an exceptional and outstanding piece of work. Andre Courtemanche CEO, CS&T/Lexacom From owner-ietf-calendar@mail.imc.org Tue Apr 18 16:56:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12041 for ; Tue, 18 Apr 2000 16:56:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09157 for ietf-calendar-bks; Tue, 18 Apr 2000 13:24:43 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09152 for ; Tue, 18 Apr 2000 13:24:41 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000418202806.WOGG851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Tue, 18 Apr 2000 15:28:06 -0500 Message-ID: <38FCB5EF.4BA8778A@Software.com> Date: Tue, 18 Apr 2000 12:22:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: VTIMEZONE and signular TZID 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 I am getting back to the IANA timezone data and converting the Olsen database into iCalendar format. I discovered that there can be more than one name for the 'same' time zone. Example: US/Pacific America/Los_Angeles I think that only one should be the IANA registered name. The other(s) some kind of alias. I see some possible solutions: (1) We submit both each with identical data. And only one with a TZID of '/' (The official one). The other with only From RFC2445: 4.2.19 Time Zone Identifier ... tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF tzidprefix = "/" ... BEGIN:VTIMEZONE TZID:/US/Pacific ... END:VTIMEZONE BEGIN:VTIMEZONE TZID:America/Los_Angeles ... END:VTIMEZONE (2) We allow multiple TZID properties and specify that only one can begin with tzidprefix. And that any others are alias for the same name. And there can only be more than one if exactly one has a tzidprefix. BEGIN:VTIMEZONE TZID:/US/Pacific TZID:America/Los_Angeles ... END:VTIMEZONE (3) We specify a new property for the alias: BEGIN:VTIMEZONE TZID:/US/Pacific TZIDALIAS:America/Los_angles ... END:VTIMEZONE (4) We could ignore the alias names and force people to migrate if they used another name. (5) Another way would be a variation of (1), except we tweak the non-standard name so that it is not valid sometime soon. An RRULE with an until value in the short future. I am leaning towards (2) - or maybe (4) COMMENTS? Problems with (2) - how many can we allowed to be registered for the same data? It should be discouraged to create new TZIDs just because you can. Another way would be a variation of (1), except we tweak the non-standard name so that it is not valid sometime soon. RRULE with an until value in the short future. -Doug From owner-ietf-calendar@mail.imc.org Tue Apr 18 18:19:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13300 for ; Tue, 18 Apr 2000 18:19:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA10118 for ietf-calendar-bks; Tue, 18 Apr 2000 14:56:07 -0700 (PDT) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10114 for ; Tue, 18 Apr 2000 14:56:05 -0700 (PDT) Received: from ross ([207.82.79.207]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id OAA22560 for ; Tue, 18 Apr 2000 14:59:11 -0700 (PDT) Message-Id: <3.0.6.32.20000418145640.0094fc40@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 18 Apr 2000 14:56:40 -0700 To: ietf-calendar@imc.org From: Ross Finlayson Subject: Re: VTIMEZONE and signular TZID In-Reply-To: <38FCB5EF.4BA8778A@Software.com> 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: > (4) We could ignore the alias names and force people to > migrate if they used another name. [...] >I am leaning towards (2) - or maybe (4) COMMENTS? I'd prefer (4): have each timezone known (as far as this iCalendar database is concerned) by just a single id. It makes things a lot easier all around... Ross. From owner-ietf-calendar@mail.imc.org Tue Apr 18 19:03:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13805 for ; Tue, 18 Apr 2000 19:03:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10518 for ietf-calendar-bks; Tue, 18 Apr 2000 15:31:34 -0700 (PDT) Received: from aristotle.whiskerfish.com (IDENT:root@w173.z209220133.sjc-ca.dsl.cnc.net [209.220.133.173]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10514 for ; Tue, 18 Apr 2000 15:31:29 -0700 (PDT) Received: from sartre (sartre.whiskerfish.com [209.220.133.164]) by aristotle.whiskerfish.com (8.9.3/8.9.3) with SMTP id PAA04869; Tue, 18 Apr 2000 15:33:32 -0700 Message-ID: <021301bfa985$d4ee6140$a485dcd1@whiskerfish.com> From: "Colin DuPlantis" To: , "Ross Finlayson" References: <3.0.6.32.20000418145640.0094fc40@shell7.ba.best.com> Subject: Re: VTIMEZONE and signular TZID Date: Tue, 18 Apr 2000 15:31:25 -0700 Organization: Critical Path, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A new voice to the topic - Colin DuPlantis of Critical Path (www.cp.net). I believe that a single approach to TZIDs would benefit. Fresh from the latest CalConnect conference at MIT, we discovered that allowing each app to define its own TZIDs is a royal pain. I say pick one method and make the world conform... - C ----- Original Message ----- From: "Ross Finlayson" To: Sent: Tuesday, April 18, 2000 2:56 PM Subject: Re: VTIMEZONE and signular TZID > > (4) We could ignore the alias names and force people to > > migrate if they used another name. > [...] > >I am leaning towards (2) - or maybe (4) COMMENTS? > > I'd prefer (4): have each timezone known (as far as this iCalendar database > is concerned) by just a single id. It makes things a lot easier all around... > > Ross. > From owner-ietf-calendar@mail.imc.org Tue Apr 18 20:04:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14775 for ; Tue, 18 Apr 2000 20:04:03 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA11123 for ietf-calendar-bks; Tue, 18 Apr 2000 16:39:33 -0700 (PDT) Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11119 for ; Tue, 18 Apr 2000 16:39:28 -0700 (PDT) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id TAA19749 for ; Tue, 18 Apr 2000 19:43:30 -0400 (EDT) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9561014061.019553; Tue, 18 Apr 00 19:43:26 -0400 Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id TAA19546 for ; Tue, 18 Apr 2000 19:43:26 -0400 (EDT) X-Authentication-Warning: pivsbh1.ms.com: Processed from queue /var/spool/mqueue-vs X-Authentication-Warning: pivsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf Received: from sasmh4.ms.com(144.14.193.5) by pivsbh1 via smap (4.1) id sma.9561013901.019301; Tue, 18 Apr 00 19:43:10 -0400 Received: from msdw.com (vector.morgan.com [144.14.16.149]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id TAA25909 for ; Tue, 18 Apr 2000 19:43:10 -0400 (EDT) Message-ID: <38FCF30D.6FAAD885@msdw.com> Date: Tue, 18 Apr 2000 19:43:09 -0400 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FCB5EF.4BA8778A@Software.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8F5A6788BCF8091A80391D64" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms8F5A6788BCF8091A80391D64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > I am getting back to the IANA timezone data and converting > the Olsen database into iCalendar format. I discovered > that there can be more than one name for the 'same' time zone. I'd suggest asking the olsen mailing list why they have so many names for the same timezone. I suspect it's because of cultural and political sensitivities. Perhaps this needs to be a numerically indexed (so as to not offend) while allowing whatever descriptive tag you'd like (with a default of course). This also has the benefit of allowing i18n. dmadeo --------------ms8F5A6788BCF8091A80391D64 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKbAYJKoZIhvcNAQcCoIIKXTCCClkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDUwggUTMIIEfKADAgECAhAmLAz9r3s0IQlzFUGDnfQHMA0GCSqGSIb3DQEBBAUAMIGPMR8w HQYDVQQKExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSkwJwYDVQQLFCBNb3JnYW4gU3Rhbmxl eSBEZWFuIFdpdHRlciAmIENvLjFBMD8GA1UECxQ4TW9yZ2FuIFN0YW5sZXkgRGVhbiBXaXR0 ZXIgJiBDby4gQ2xhc3MgMiAtIEluZGl2aWR1YWwgQ0EwHhcNMDAwMzMwMDAwMDAwWhcNMDEw MzMwMjM1OTU5WjCB4zEpMCcGA1UEChQgTW9yZ2FuIFN0YW5sZXkgRGVhbiBXaXR0ZXIgJiBD by4xIDAeBgNVBAsUF0NsYXNzIDIgLSBJbmRpdmlkdWFsIENBMUYwRAYDVQQLEz13d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2 MREwDwYDVQQMFAhFbXBsb3llZTEUMBIGA1UEAxMLRGF2aWQgTWFkZW8xIzAhBgkqhkiG9w0B CQEWFGRhdmlkLm1hZGVvQG1zZHcuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCz hjCOwOgqHm4CYiTiAseSXn0z+6zv6O/llTC1ToFiyN0+uXJK02NCfKxB641qLfi2aMZEkJXX KRrW0hLFAI2lzCrLkO4njbMFsr9E/jVTgTWHu5IlADSSgqVhL/v4a7K3SofP1iuzh0nd3S6q 1GvaXZnjTAM0jgMJeAR0iGm4BwIDAQABo4ICGDCCAhQwCQYDVR0TBAIwADBkBgNVHR8EXTBb MFmgV6BVhlNodHRwOi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9Nb3JnYW5TdGFubGV5RGVh bldpdHRlckNvQ2xhc3MySW5kaXZpZHVhbENBL0xhdGVzdENSTDALBgNVHQ8EBAMCB4AwgawG A1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEB Gj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3 IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDARBgpghkgBhvhFAQYJBAMBAf8wgb4GCmCG SAGG+EUBBg4Ega8WgaxPQ1hHYnFsaEtjRjhqVDN3REFwMDloNkhLdkozcm5INzhOeEo3N0po WnRaeGc5Y05oSXgwSTZZNXo4Ull0dmwrTXg5QzhpVG43VldFWmlFdmNRRmthemwwNFdIZFh6 QTRodWQ4RDNrMi9kNnZIY1o2Vm9yeW0rdXNOK3RqSExBdFR6VHUzNVVWY0t5ZExSd0pOdkxW NTdVY05MTytzS09zMzBJR2NINnhsQlk9MA0GCSqGSIb3DQEBBAUAA4GBAIRHJ1FbQ2mHYug2 H0ZI+2C2RT1cd2280GTtE4K1PK4uZhVKkAfLeKOktIp53BQhyP21gUQupXnWaOx5/lCCtQa9 EAg6z66++v9RFX0885mmpCJsT6/KOWoqWPkPIsKd27a3d+i7bYV35feb+ZZkvVzDO/hWyE5O JvK325pdQpC4MIIDGjCCAoOgAwIBAgIRAIx4wGZDfh2AKJUmqcr3Mn0wDQYJKoZIhvcNAQEE BQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5D bGFzcyAyIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDQz MDAwMDAwMFoXDTAzMDQzMDIzNTk1OVowgY8xHzAdBgNVBAoTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxKTAnBgNVBAsUIE1vcmdhbiBTdGFubGV5IERlYW4gV2l0dGVyICYgQ28uMUEwPwYD VQQLFDhNb3JnYW4gU3RhbmxleSBEZWFuIFdpdHRlciAmIENvLiBDbGFzcyAyIC0gSW5kaXZp ZHVhbCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtZlEfyqZK1R38UYr148tIZTe 29Jpr01x+6SNN9JvnCZGi2eFfCudAzDC7xDnDFzcFtBIRHk4i03axe1ZkDSHiGmuWTfL0Bmp elMtWYP0GOC6JrQXiBcJs9RpMjXJ8aHZNxx/FLAIYccTf6HzZTJhWIdVX/N8Bf78bkovu5L2 G+UCAwEAAaOBpDCBoTAoBgNVHREEITAfpB0wGzEZMBcGA1UEAxMQUHJpdmF0ZUxhYmVsMS00 NjARBglghkgBhvhCAQEEBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcBATAqMCgGCCsG AQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vUlBBMA8GA1UdEwQIMAYBAf8CAQAw CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAGOBvA7CnnJnpd7i/K2oXnazlmCQgEM7 Mur7kfsXgsHX+CLHR3IMTqg1FjXOM5wkLwQ62YcISPuqKIEBqFr7irLgTQiAfIF7sIy/RzK3 +JqekTP7DQ6J1b9V3N2XaQwfaVIKgatOAWkpnHB8vthizZC+f558u5eprm0m1XgTKZpIMYIB /zCCAfsCAQEwgaQwgY8xHzAdBgNVBAoTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxKTAnBgNV BAsUIE1vcmdhbiBTdGFubGV5IERlYW4gV2l0dGVyICYgQ28uMUEwPwYDVQQLFDhNb3JnYW4g U3RhbmxleSBEZWFuIFdpdHRlciAmIENvLiBDbGFzcyAyIC0gSW5kaXZpZHVhbCBDQQIQJiwM /a97NCEJcxVBg530BzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDQxODIzNDMwOVowIwYJKoZIhvcNAQkEMRYEFJyOIKZxeB+z VgGzvIFOFfhIkUIZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAUUnBM7fWVfGw/J9T9eJQSRNQ0J/PCMCMyuXAInl5yPPsmPAA/tYXR2DyP89hgtOl B0jjYhJB01/KoLiZlwuJdMhb9xMeXNHCIMqJTBnE+5Nr8C9Ex9o7eVwl2pgr90W0X7YsAa93 leYy4QjN2UUt9J+GBoG1ZAZgwJsl23Exo3U= --------------ms8F5A6788BCF8091A80391D64-- From owner-ietf-calendar@mail.imc.org Tue Apr 18 21:11:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15402 for ; Tue, 18 Apr 2000 21:11:51 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA11745 for ietf-calendar-bks; Tue, 18 Apr 2000 17:44:07 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA11741 for ; Tue, 18 Apr 2000 17:44:06 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000419004746.WTVT851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Tue, 18 Apr 2000 19:47:46 -0500 Message-ID: <38FCF2C9.FC010555@Software.com> Date: Tue, 18 Apr 2000 16:42:01 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FCB5EF.4BA8778A@Software.com> <38FCF30D.6FAAD885@msdw.com> Content-Type: multipart/mixed; boundary="------------1A1D947C9282AEE0873C9155" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1A1D947C9282AEE0873C9155 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Madeo wrote: > > Doug Royer wrote: > > > I am getting back to the IANA timezone data and converting > > the Olsen database into iCalendar format. I discovered > > that there can be more than one name for the 'same' time zone. > > I'd suggest asking the olsen mailing list why they have so many names for > the same timezone. I suspect it's because of cultural and political > sensitivities. I don't think they care about the name. They care if the data is accurate. So if there were 100 names for the same timezone, and they got them all - I think they would be happy. Fortunately it looks like there is only 2 or 3 max overlap for one time zone entry. They call then 'links'. I have attached 'links' with the 111 aliases. > Perhaps this needs to be a numerically indexed (so as to not offend) while > allowing whatever descriptive tag you'd like (with a default of course). > This also has the benefit of allowing i18n. We would have to change iCalendar - as it uses TZID as the unique ID. It is a text value, we could put a numeric value in text as the value. But then we would have to invent a new property for the name. We could in COMMENT or something - then we would have to update the iTIP restriction tables to allow comment in a VTIMEZONE. The TZID value is by default UTF-8. So it is already i18n ready. -Doug --------------1A1D947C9282AEE0873C9155 Content-Type: text/plain; charset=us-ascii; name="links" Content-Disposition: inline; filename="links" Content-Transfer-Encoding: 7bit Antarctica/McMurdo Antarctica/South_Pole America/Adak America/Atka America/Tijuana America/Ensenada America/Indianapolis America/Fort_Wayne America/Indiana/Knox America/Knox_IN America/St_Thomas America/Virgin Asia/Jerusalem Asia/Tel_Aviv Asia/Ulaanbaatar Asia/Ulan_Bator Australia/Sydney Australia/ACT Australia/Sydney Australia/Canberra Australia/Lord_Howe Australia/LHI Australia/Sydney Australia/NSW Australia/Darwin Australia/North Australia/Brisbane Australia/Queensland Australia/Adelaide Australia/South Australia/Hobart Australia/Tasmania Australia/Melbourne Australia/Victoria Australia/Perth Australia/West Australia/Broken_Hill Australia/Yancowinna America/Porto_Acre Brazil/Acre America/Noronha Brazil/DeNoronha America/Sao_Paulo Brazil/East America/Manaus Brazil/West America/Halifax Canada/Atlantic America/Winnipeg Canada/Central America/Regina Canada/East-Saskatchewan America/Montreal Canada/Eastern America/Edmonton Canada/Mountain America/St_Johns Canada/Newfoundland America/Vancouver Canada/Pacific America/Regina Canada/Saskatchewan America/Whitehorse Canada/Yukon America/Santiago Chile/Continental Pacific/Easter Chile/EasterIsland America/Havana Cuba Africa/Cairo Egypt Europe/Dublin Eire Europe/London GB Europe/London GB-Eire Etc/GMT+0 GMT+0 Etc/GMT-0 GMT-0 Etc/GMT0 GMT0 Etc/Greenwich Greenwich Asia/Hong_Kong Hongkong Atlantic/Reykjavik Iceland Asia/Tehran Iran Asia/Jerusalem Israel America/Jamaica Jamaica Asia/Tokyo Japan Pacific/Kwajalein Kwajalein Africa/Tripoli Libya America/Tijuana Mexico/BajaNorte America/Mazatlan Mexico/BajaSur America/Mexico_City Mexico/General America/Denver Navajo Pacific/Auckland NZ Pacific/Chatham NZ-CHAT Pacific/Pago_Pago Pacific/Samoa Asia/Shanghai PRC Europe/Warsaw Poland Europe/Lisbon Portugal Asia/Taipei ROC Asia/Seoul ROK Asia/Singapore Singapore Europe/Istanbul Turkey Etc/UCT UCT America/Anchorage US/Alaska America/Adak US/Aleutian America/Phoenix US/Arizona America/Chicago US/Central America/Indianapolis US/East-Indiana America/New_York US/Eastern Pacific/Honolulu US/Hawaii America/Indiana/Knox US/Indiana-Starke America/Detroit US/Michigan America/Denver US/Mountain America/Los_Angeles US/Pacific Pacific/Pago_Pago US/Samoa Etc/UTC UTC Etc/Universal Universal Europe/Moscow W-SU Etc/Zulu Zulu Etc/GMT GMT Etc/UTC Etc/Universal Etc/UTC Etc/Zulu Etc/GMT Etc/Greenwich Etc/GMT Etc/GMT-0 Etc/GMT Etc/GMT+0 Etc/GMT Etc/GMT0 Europe/Rome Europe/Vatican Europe/Rome Europe/San_Marino Europe/Oslo Arctic/Longyearbyen Europe/Prague Europe/Bratislava Europe/Istanbul Asia/Istanbul Europe/Belgrade Europe/Ljubljana Europe/Belgrade Europe/Sarajevo Europe/Belgrade Europe/Skopje Europe/Belgrade Europe/Zagreb America/Denver America/Shiprock America/Indianapolis America/Indiana/Indianapolis America/New_York EST5EDT America/Chicago CST6CDT America/Denver MST7MDT America/Los_Angeles PST8PDT America/Indianapolis EST America/Phoenix MST Pacific/Honolulu HST America/Los_Angeles US/Pacific-New Asia/Riyadh87 Mideast/Riyadh87 Asia/Riyadh88 Mideast/Riyadh88 Asia/Riyadh89 Mideast/Riyadh89 --------------1A1D947C9282AEE0873C9155-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 07:11:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03309 for ; Wed, 19 Apr 2000 07:11:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27744 for ietf-calendar-bks; Wed, 19 Apr 2000 03:50:20 -0700 (PDT) Received: from xenia.mc2.renault.fr (root@xenia.renault.fr [193.194.133.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27738 for ; Wed, 19 Apr 2000 03:49:17 -0700 (PDT) Received: from univers.mc2.renault.fr by xenia.mc2.renault.fr id MAA03396; Wed, 19 Apr 2000 12:53:08 +0200 (MET DST) Received: from renault.fr by univers.mc2.renault.fr id MAA19537; Wed, 19 Apr 2000 12:53:07 +0200 (MET DST) Message-ID: <38FD900D.6E100761@renault.fr> Date: Wed, 19 Apr 2000 12:53:01 +0200 From: Antoine Leca Organization: RENAULT (mais cette contribution est personnelle et n'engage pas RENAULT) X-Mailer: Mozilla 4.7 [ca] (Win95; I) X-Accept-Language: ca,fr MIME-Version: 1.0 To: David.Madeo@msdw.com CC: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FCB5EF.4BA8778A@Software.com> <38FCF30D.6FAAD885@msdw.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 David Madeo wrote: > > Doug Royer wrote: > > > I am getting back to the IANA timezone data and converting > > the Olsen database into iCalendar format. I discovered > > that there can be more than one name for the 'same' time zone. > > I'd suggest asking the olsen mailing list why they have so many names for > the same timezone. Some are already hearing you... > I suspect it's because of cultural and political sensitivities. I believe backward compatibility is the key reason. ( I was surprised to *not* see in Doug's list a link from Asia/Alma-Ata to Asia/Almaty, but it appears that did not include this particular link --and nobody minded ;-); anyway, this is an example of the problematic...) Also, we have a few links for small countries (like San Marin or Vatican) that did not, and as we can see will not, have proper history for time zones. Then, we have a few links for mnemonic or fame reasons, like Antartica/South_Pole (Africa/Timbuktu is another example: it is not a link, because LMT were different 80 years ago, but it is merely a joke to include it as a separate timezone). BTW, for Doug's example, the "official" one should be America/Los_Angeles, at least if the Olson scheme is obeyed. Antoine From owner-ietf-calendar@mail.imc.org Wed Apr 19 07:34:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03763 for ; Wed, 19 Apr 2000 07:34:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA28997 for ietf-calendar-bks; Wed, 19 Apr 2000 04:18:21 -0700 (PDT) Received: from xenia.mc2.renault.fr (root@xenia.renault.fr [193.194.133.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28993 for ; Wed, 19 Apr 2000 04:18:17 -0700 (PDT) Received: from univers.mc2.renault.fr by xenia.mc2.renault.fr id NAA11510 for ; Wed, 19 Apr 2000 13:22:22 +0200 (MET DST) Received: from renault.fr by univers.mc2.renault.fr id MAA20211 for ; Wed, 19 Apr 2000 12:54:43 +0200 (MET DST) Message-ID: <38FD906E.F38AF47F@renault.fr> Date: Wed, 19 Apr 2000 12:54:38 +0200 From: Antoine Leca Organization: RENAULT (mais cette contribution est personnelle et n'engage pas RENAULT) X-Mailer: Mozilla 4.7 [ca] (Win95; I) X-Accept-Language: ca,fr MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FCB5EF.4BA8778A@Software.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: > > (3) We specify a new property for the alias: > > BEGIN:VTIMEZONE > TZID:/US/Pacific > TZIDALIAS:America/Los_angles > ... > END:VTIMEZONE Just a though while browsing: why not using TZNAME here? Antoine From owner-ietf-calendar@mail.imc.org Wed Apr 19 10:32:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07161 for ; Wed, 19 Apr 2000 10:32:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA02587 for ietf-calendar-bks; Wed, 19 Apr 2000 07:01:41 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02583 for ; Wed, 19 Apr 2000 07:01:37 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA30614; Wed, 19 Apr 2000 10:05:31 -0400 Message-ID: <38FDBD29.DC43BABA@ecal.com> Date: Wed, 19 Apr 2000 10:05:29 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FCB5EF.4BA8778A@Software.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: > I think that only one should be the IANA registered name. > The other(s) some kind of alias. I think I need to disagree here--almost. My thoughts: First: we need to permit all the names, because people are using them (or, at least, we can't be sure that people aren't using them, which is just as bad). For example, Unix boxen generally have the Olsen database installed (on my RedHat6.2 box it's under /usr/share/zoneinfo); a program running on a Unix box ought to be able to look at the system's timezone and use that as its default. Since the database is installed with all the names, the program needs to be able to use any of them. Next: clearly, all the names need to be standardized; otherwise, it won't be safe to use the ones that aren't. So all the names need to be IANA registered. Next: I agree that it would be best to register each set of data just once (hence the "almost disagree"). So either we register some names with data, and some with pointers; or we register data with multiple names. (I don't have strong feelings either way here.) Either way, some of the names are aliases. Finally: I do not think that we should distinguish syntactically between canonical names and alias names (in your examples, by putting a slash in front of some but not others). This is, admittedly, partly just technical aesthetics, but there is also a practical reason: one nice use of the alias names is to permit future transitions. Suppose we know that Pennsylvania is planning to change its DST rules in a year or so, but the details aren't nailed down yet. We define an "America/Pennsylvania" alias, which points to EST5EDT, and start using it in iCalendars for events in Pennsylvania. When the DST rules are finalized, we change the alias to be a canonical name for the new data; suddenly, all the existing iCalendars for Pennsylvania events refer to the changed data. (This assumes that the legislature isn't dumb enough to change DST retroactively, so it's valid to change the data that the iCalendar refers to, since it's in the future. :-) If we had to distinguish between "America/Pennsylvania" and "/America/Pennsylvania", this wouldn't work; we'd have to go through all the existing iCalendars and change the TZIDs. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |If at first you don't succeed, don't go | |francis@ecal.com|skydiving. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 19 12:27:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09474 for ; Wed, 19 Apr 2000 12:27:19 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA04361 for ietf-calendar-bks; Wed, 19 Apr 2000 09:06:20 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04357 for ; Wed, 19 Apr 2000 09:06:19 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA10479; Wed, 19 Apr 2000 12:27:06 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA28387; Wed, 19 Apr 2000 12:09:54 -0400 (EDT) To: Doug Royer , dmadeo@ms.com Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Wed, 19 Apr 2000 12:05:56 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/19/2000 12:05:58 PM, Serialize complete at 04/19/2000 12:05:58 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0043EB28852568C6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0043EB28852568C6_= Content-Type: text/plain; charset="us-ascii" Doug (and David): I don't see that there is a problem with having numerous definitions for time zones with a different TZID or TZNAME but with the same time zone information. Time zones, by nature, are under local governmental control. If there are two or more locals at the same UTC offset, then they would fall under this case. A given time zone may have had its definition changed over time. This would account for multiple definitions for the same time zone, also. Likewise, the duplicate definitions could result from a change in the name or identifier of one or more of these time zone definitions. In any case, our role is merely to capture all the definitions in a common format. Not to become time zone tsars and redefine the time zone definitions, names or whatever. Right? -- Frank --=_alternative 0043EB28852568C6_= Content-Type: text/html; charset="us-ascii"
Doug (and David):

I don't see that there is a problem with having numerous definitions for time zones with a different TZID or TZNAME but with the same time zone information.

Time zones, by nature, are under local governmental control. If there are two or more locals at the same UTC offset, then they would fall under this case.

A given time zone may have had its definition changed over time. This would account for multiple definitions for the same time zone, also.

Likewise, the duplicate definitions could result from a change in the name or identifier of one or more of these time zone definitions.

In any case, our role is merely to capture all the definitions in a common format. Not to become time zone tsars and redefine the time zone definitions, names or whatever. Right?

-- Frank --=_alternative 0043EB28852568C6_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 12:30:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09531 for ; Wed, 19 Apr 2000 12:30:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA04380 for ietf-calendar-bks; Wed, 19 Apr 2000 09:06:40 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04376 for ; Wed, 19 Apr 2000 09:06:39 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA10607; Wed, 19 Apr 2000 12:27:31 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA28527; Wed, 19 Apr 2000 12:10:18 -0400 (EDT) To: "Colin DuPlantis" Cc: finlayson@live.com, ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Wed, 19 Apr 2000 12:06:20 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/19/2000 12:06:23 PM, Serialize complete at 04/19/2000 12:06:23 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0048F0F8852568C6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0048F0F8852568C6_= Content-Type: text/plain; charset="us-ascii" Both Colin and Ross indicated that they would prefer a single definition of a time zone. By time zone, I assume you mean the definition for a specific geographical locale. The definition of that "time zone" definition is outside our control. Time zone definitions are the domain of the locale governing authority. The registration in the IANA db would have to be open too, for other practical reasons (e.g., how can a registrar check the authorization of a submission?). May be we should discuss the registration process and the change control process? I have been assuming that it would be the same as is used for the MIME multimedia content type registrations. -- Frank --=_alternative 0048F0F8852568C6_= Content-Type: text/html; charset="us-ascii"
Both Colin and Ross indicated that they would prefer a single definition of a time zone.

By time zone, I assume you mean the definition for a specific geographical locale. The definition of that "time zone" definition is outside our control. Time zone definitions are the domain of the locale governing authority. The registration in the IANA db would have to be open too, for other practical reasons (e.g., how can a registrar check the authorization of a submission?).

May be we should discuss the registration process and the change control process? I have been assuming that it would be the same as is used for the MIME multimedia content type registrations.

-- Frank

--=_alternative 0048F0F8852568C6_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 12:33:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09624 for ; Wed, 19 Apr 2000 12:33:20 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA04367 for ietf-calendar-bks; Wed, 19 Apr 2000 09:06:23 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04362 for ; Wed, 19 Apr 2000 09:06:21 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA10519 for ; Wed, 19 Apr 2000 12:27:13 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA28407 for ; Wed, 19 Apr 2000 12:09:58 -0400 (EDT) To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Wed, 19 Apr 2000 12:05:57 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/19/2000 12:06:03 PM, Serialize complete at 04/19/2000 12:06:03 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00473EE8852568C6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00473EE8852568C6_= Content-Type: text/plain; charset="us-ascii" Doug Royer wrote, in part: >I am getting back to the IANA timezone data and converting >the Olsen database into iCalendar format. I discovered >that there can be more than one name for the 'same' time zone. This is normal. Nothing unusual about this. See my previous note. >I think that only one should be the IANA registered name. >The other(s) some kind of alias. Do we mean the TZNAME or TZID? iCalendar allows multiple TZNAMEs for the same time zone definition. In the OLSEN db, I believe the two concepts are merged into one. In iCalendar, there can be only one TZID for a given definition, but that definition can have multiple "names" or TZNAME properties. COMMENT property is also allowed. >I see some possible solutions: > > (1) We submit both each with identical data. > > And only one with a TZID of '/' (The official one). > The other with only > (2) We allow multiple TZID properties and specify that > only one can begin with tzidprefix. And that any > others are alias for the same name. And there can > only be more than one if exactly one has a tzidprefix. > (3) We specify a new property for the alias: > (4) We could ignore the alias names and force people to > migrate if they used another name. > (5) Another way would be a variation of (1), except we tweak > the non-standard name so that it is not valid sometime soon. > An RRULE with an until value in the short future. By "alias", we should mean a time zone definition created by someone other than the official owner for the given time zone definition (e.g., some programmer trying to make sense out of this historical mess ;-). Any of the official time zone definitions, captured by the OLSEN db should be retained as individual time zone definitions by the IANA registry. We should also recognize that as the geographical boundaries for legal locales gets redefined, the IANA will have new time zone definitions added that will possibly look like duplicate definitions for the same time zone (e.g., we could get two European definitions for Kosovo). May be some of the apparent cases of an "alias" are actually intended to be different time zone definitions. For example, there could be official, but historical changes to the names that result in two independent definitions for the same time zone. Both of these need to remain in the registry. Or, there could be two legal entities for the same "near geography". For example, a US definition for an antartic base, but a UN definition for the UN protectorate. Cases, such as these two independent definitions need to be remain distinct in the IANA registry also. In addition, once a definition is placed into the IANA registry, it should not be removed. >I am leaning towards (2) - or maybe (4) COMMENTS? What is wrong with (1)? This seems the only practical solution, given that we will have to have procedure for adding entries to the IANA registry and that any one of these additions could appear to be a duplicate definition for the same time zone definition. But, it might not be. It might be a definition for a legal time zone that has the same UTC offset as an existing entry in the IANA registry. >Problems with (2) - how many can we allowed to be registered for >the same data? It should be discouraged to create new TZIDs just >because you can. Since we don't control the definition of time zones, only the definition of how they are represented in the IANA registry, this is a moot question. If xyz country decides to define a time zone then we need to add it. If the xyz country has a brain fart and decides to redefine the time zone, then we need to add that one. We aren't time zone tsars. >Another way would be a variation of (1), except we tweak the >non-standard name so that it is not valid sometime soon. >RRULE with an until value in the short future. Again, do we mean "identifier" or "name". iCalendar allows the TZNAME property to be repeated any number of times for different display names, in a VTIMEZONE definition. -- Frank --=_alternative 00473EE8852568C6_= Content-Type: text/html; charset="us-ascii"
Doug Royer wrote, in part:

>I am getting back to the IANA timezone data and converting
>the Olsen database into iCalendar format. I discovered
>that there can be more than one name for the 'same' time zone.

This is normal. Nothing unusual about this. See my previous note.

<snip>

>I think that only one should be the IANA registered name.
>The other(s) some kind of alias.

Do we mean the TZNAME or TZID? iCalendar allows multiple TZNAMEs for the same time zone definition. In the OLSEN db, I believe the two concepts are merged into one. In iCalendar, there can be only one TZID for a given definition, but that definition can have multiple "names" or TZNAME properties. COMMENT property is also allowed.

>I see some possible solutions:
>
>                 (1) We submit both each with identical data.
>
>                     And only one with a TZID of '/'<name> (The official one).
>                     The other with only <name>

<snip>

>                 (2) We allow multiple TZID properties and specify that
>                     only one can begin with tzidprefix. And that any
>                     others are alias for the same name. And there can
>                     only be more than one if exactly one has a tzidprefix.

<snip>

>                 (3) We specify a new property for the alias:

<snip>

>                 (4) We could ignore the alias names and force people to
>                     migrate if they used another name.

<snip>

>                 (5) Another way would be a variation of (1), except we tweak
>                     the non-standard name so that it is not valid sometime soon.
>                     An RRULE with an until value in the short future.

By "alias", we should mean a time zone definition created by someone other than the official owner for the given time zone definition (e.g., some programmer trying to make sense out of this historical mess ;-). Any of the official time zone definitions, captured by the OLSEN db should be retained as individual time zone definitions by the IANA registry. We should also recognize that as the geographical boundaries for legal locales gets redefined, the IANA will have new time zone definitions added that will possibly look like duplicate definitions for the same time zone (e.g., we could get two European definitions for Kosovo).

May be some of the apparent cases of an "alias" are actually intended to be different time zone definitions. For example, there could be official, but historical changes to the names that result in two independent definitions for the same time zone. Both of these need to remain in the registry. Or, there could be two legal entities for the same "near geography". For example, a US definition for an antartic base, but a UN definition for the UN protectorate. Cases, such as these two independent definitions need to be remain distinct in the IANA registry also.

In addition, once a definition is placed into the IANA registry, it should not be removed.

>I am leaning towards (2) - or maybe (4) COMMENTS?

What is wrong with (1)? This seems the only practical solution, given that we will have to have procedure for adding entries to the IANA registry and that any one of these additions could appear to be a duplicate definition for the same time zone definition. But, it might not be. It might be a definition for a legal time zone that has the same UTC offset as an existing entry in the IANA registry.

>Problems with (2) - how many can we allowed to be registered for
>the same data? It should be discouraged to create new TZIDs just
>because you can.

Since we don't control the definition of time zones, only the definition of how they are represented in the IANA registry, this is a moot question. If xyz country decides to define a time zone then we need to add it. If the xyz country has a brain fart and decides to redefine the time zone, then we need to add that one. We aren't time zone tsars.

>Another way would be a variation of (1), except we tweak the
>non-standard name so that it is not valid sometime soon.
>RRULE with an until value in the short future.

Again, do we mean "identifier" or "name". iCalendar allows the TZNAME property to be repeated any number of times for different display names, in a VTIMEZONE definition.

-- Frank

--=_alternative 00473EE8852568C6_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 12:53:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09926 for ; Wed, 19 Apr 2000 12:53:09 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA04821 for ietf-calendar-bks; Wed, 19 Apr 2000 09:35:08 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04817 for ; Wed, 19 Apr 2000 09:35:06 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA30974 for ; Wed, 19 Apr 2000 12:39:01 -0400 Message-ID: <38FDE124.79E929DC@ecal.com> Date: Wed, 19 Apr 2000 12:39:00 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID 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 Frank_Dawson@lotus.com wrote: > Time zone definitions are the domain of the locale governing > authority. [...] > May be we should discuss the registration process and the > change control process? I have been assuming that it would be > the same as is used for the MIME multimedia content type > registrations. It could be close, but it couldn't be exactly the same. MIME type registration, like most IETF stuff, is driven by technical merit; time zone registration is driven by governments (indirectly, anyway). Technical merit still comes up, but in a different way. If a government changes its time zones, there must be a new registration done by the time the new rules go into effect. Under those circumstances, a technical review can say, "it doesn't match the new rules correctly; fix this bug", but not, "let's not register anything". -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |The Net was designed to survive nukes, but not| |francis@ecal.com|lawsuits. Wait a minute. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 19 13:20:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10454 for ; Wed, 19 Apr 2000 13:20:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05220 for ietf-calendar-bks; Wed, 19 Apr 2000 10:01:23 -0700 (PDT) Received: from xenia.mc2.renault.fr (root@xenia.renault.fr [193.194.133.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05214 for ; Wed, 19 Apr 2000 10:01:21 -0700 (PDT) Received: from univers.mc2.renault.fr by xenia.mc2.renault.fr id TAA24667; Wed, 19 Apr 2000 19:05:26 +0200 (MET DST) Received: from renault.fr by univers.mc2.renault.fr id TAA01887; Wed, 19 Apr 2000 19:05:25 +0200 (MET DST) Message-ID: <38FDE751.2991A2B3@renault.fr> Date: Wed, 19 Apr 2000 19:05:21 +0200 From: Antoine Leca Organization: RENAULT (mais cette contribution est personnelle et n'engage pas RENAULT) X-Mailer: Mozilla 4.7 [ca] (Win95; I) X-Accept-Language: ca,fr MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FDE124.79E929DC@ecal.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 John Stracke wrote: > > If a government changes its time zones, there must be a new > registration done by the time the new rules go into effect. Certainly. However, I do not expect a lot of "governments" (large meaning) to prepare submissions. Rather, Olson's database history is more matter of work from voluntarians; and I cannot see why things would go another way for the IANA registry (I hope I guess wrong, though). > Under those circumstances, a technical review can say, > "it doesn't match the new rules correctly; fix this bug", but > not, "let's not register anything". The current behaviour of the Olson group is a mix (but closer from the second option): usually, we have: - some user (usually not Joe User but rather Carlos Usario or Boris Ou... --don't know the word in Russian) complains to her/his sysadmin - the sysadmin figures from where the problem comes, and contacts Arthur Olson - Arthur Olson forward the mail from the sysadmin; at this point, we are off a few days with regard with the change - the group try to figure what the new rules are (looking at various sources, reading newspapers, etc.) - proposals for changes are submitted - ... and discussed, particularly if the change is not obvious - sometimes, the change is accepted (meaning that the patch is applied to the database and Arthur Olson issues a new version; but sometimes, the change is not accepted at all, and nothing is changed until next user complains... Other ways to make changes are: - informations collected by regulars in newspapers or similar resources - the bi-annual IATA (Planes' Agency) almanach always have new informations about timezones - also CIA or Naval Observatory issue(d) almaanch with these informations Antoine From owner-ietf-calendar@mail.imc.org Wed Apr 19 15:38:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12730 for ; Wed, 19 Apr 2000 15:38:15 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA07487 for ietf-calendar-bks; Wed, 19 Apr 2000 12:10:35 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07482 for ; Wed, 19 Apr 2000 12:10:31 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000419191414.XKCQ851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 19 Apr 2000 14:14:14 -0500 Message-ID: <38FDF614.3714063E@Software.com> Date: Wed, 19 Apr 2000 11:08:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FCB5EF.4BA8778A@Software.com> <38FD906E.F38AF47F@renault.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1053AAF104C5DDA6FAD94C1F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms1053AAF104C5DDA6FAD94C1F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Antoine Leca wrote: > > Doug Royer wrote: > > > > (3) We specify a new property for the alias: > > > > BEGIN:VTIMEZONE > > TZID:/US/Pacific > > TZIDALIAS:America/Los_angles > > ... > > END:VTIMEZONE > > Just a though while browsing: why not using TZNAME here? According to RFC2445, TZNAME only exists inside of a BEGIN:STANDARD or DAYLIGHT ... END:STANDARD or DAYLIGHT. We could modify VTIMEZONE to say that TZNAME could also included at the BEGIN:VTIMEZONE ... END:VTIMEZONE scope. Also, TZNAME is the equivalent of the ( Olson-FORMAT + Olson-Letter/s ). (vs Olson-Name == TZID), so we would be overloading the name. But there can be multiple TZNAME's per RFC2445-standardc and RFC2445-daylightc. And TZNAME's format is unregulated - so that might be a good suggestion. -Doug --------------ms1053AAF104C5DDA6FAD94C1F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQxOTE4MDgyMVowIwYJKoZIhvcNAQkEMRYEFEfv4cwU7TzH+kQ+pqQgz7eHexrc MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEAjW5pj47X7 KMBFrBj4HaFHO5/h4QbT++7Rk6WbYMS36QLPP6IKnrFXI/xUuKzxwM8dYILRWktXEQvKQuOo bz73 --------------ms1053AAF104C5DDA6FAD94C1F-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 16:03:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13375 for ; Wed, 19 Apr 2000 16:03:58 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA08048 for ietf-calendar-bks; Wed, 19 Apr 2000 12:36:48 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08044 for ; Wed, 19 Apr 2000 12:36:45 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000419194029.XKVG851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 19 Apr 2000 14:40:29 -0500 Message-ID: <38FDFC3D.FBA41067@Software.com> Date: Wed, 19 Apr 2000 11:34:37 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FCB5EF.4BA8778A@Software.com> <38FDBD29.DC43BABA@ecal.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msFC3B71E81EC6AE091F14C663" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msFC3B71E81EC6AE091F14C663 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > > > I think that only one should be the IANA registered name. > > The other(s) some kind of alias. > > I think I need to disagree here--almost. My thoughts: > > First: we need to permit all the names, because people are using them (or, > at least, we can't be sure that people aren't using them, which is just as > bad). I think we MUST be able to find a VTIMEZONE given common names. (1) However are you saying that ALL must be the 'standard' IANA registered name? (2) Or are you saying that only ONE (the Olson name) is the IANA name, and the others are just in there somewhere? I think I was saying - (2). > For example, Unix boxen generally have the Olsen database installed > (on my RedHat6.2 box it's under /usr/share/zoneinfo); a program running on > a Unix box ought to be able to look at the system's timezone and use that > as its default. Since the database is installed with all the names, the > program needs to be able to use any of them. Use all? - Yes. All names a standard name? - I think - no. I may have asked badly. I meant to ask, how do we specify the non-standard names so they are fetchable? -OR- do we specify all as standard? > Next: clearly, all the names need to be standardized; otherwise, it won't > be safe to use the ones that aren't. So all the names need to > be IANA registered. Or do we register that FOO is the standard name, and that FOO-OLD is another name that can be used to find the FOO VTIMEZONE data as part of the FOO registration? If a timezone server were setup. Could (should?) we: client: Ask server for FOO-OLD time zone. server: I know what FOO-OLD is. However it's not the official name, so I'll return: success - code followed by: BEGIN:VTIMEZONE TZID:FOO ... :FOO-OLD ... END:VTIMEZONE. So that you can get what you need, but are also informed of what you should ask for in the future (ask for FOO). > Next: I agree that it would be best to register each set of data just > once (hence the "almost disagree"). So either we register some names with > data, and some with pointers; or we register data with multiple names. (I > don't have strong feelings either way here.) Either way, some of the names > are aliases. (1) We currently do not have any way to do a 'pointer' inside if VTIMEZONE data. (2) I think you are asking the same question as me. > Finally: I do not think that we should distinguish syntactically between > canonical names and alias names (in your examples, by putting a slash in > front of some but not others). This is already part of RFC2445, search for the string 'tzidprefix'. It is how the WG already decided to identify IANA registered TZIDs. My question is do we register all (The Olson alias people seem so far to be saying - no - they exist for historical use), or just the current names. > This is, admittedly, partly just technical > aesthetics, but there is also a practical reason: one nice use of the alias > names is to permit future transitions. Suppose we know that Pennsylvania > is planning to change its DST rules in a year or so, but the details aren't > nailed down yet. We define an "America/Pennsylvania" alias, which points > to EST5EDT, and start using it in iCalendars for events in Pennsylvania. > When the DST rules are finalized, we change the alias to be a canonical > name for the new data; suddenly, all the existing iCalendars for > Pennsylvania events refer to the changed data. (This assumes that the > legislature isn't dumb enough to change DST retroactively, so it's valid to > change the data that the iCalendar refers to, since it's in the future. > :-) If we had to distinguish between "America/Pennsylvania" and > "/America/Pennsylvania", this wouldn't work; we'd have to go through all > the existing iCalendars and change the TZIDs. That's not exactly the way it works. Using your example, If 'America/Pennsylvania' already existed and was registered by IANA, then its IANA registered name (It's IANA TZID) is going to be '/America/Pennsylvania' (leading slash - per RFC2445). So if it were to be updated, the TZID could be the same. However the data inside would be updated. And the old value would have at least a new UNTIL to it's RRULE. And the DTSTAMP would be updated. (I think we need to make DTSTAMP a MUST for registration). If the name 'America/Pennsylvania' were not already registered. Then there is no conflict. Once it were to be registered, then 'that' new data 'is' the data and the TZID would be '/America/Pennsylvania'. So there would be no issue. It would NOT be possible to have 'America/Pennsylvania' and '/America/Pennsylvania' BOTH registered as the leading slash means it is registered. Asking for 'America/Pennsylvania' would be asking for any VTIMEZONE that had this name. being returned the same name with the 'tzidprefix' simply tells you it is a registered name. Or did I miss your point ;-) -Doug --------------msFC3B71E81EC6AE091F14C663 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQxOTE4MzQzOFowIwYJKoZIhvcNAQkEMRYEFIsXRtsplv60V2th31SW0JnAKblY MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEBtVrjhhdDk b8O6iopjcoHt/YpMlBZ7upAm4CbBpzr42Lmj4N7ykkpQlCwznoCZ6KOilHosdHs6GDQJwMtc cJXw --------------msFC3B71E81EC6AE091F14C663-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 16:11:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13457 for ; Wed, 19 Apr 2000 16:11:14 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA08179 for ietf-calendar-bks; Wed, 19 Apr 2000 12:47:05 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08175 for ; Wed, 19 Apr 2000 12:47:03 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000419195046.XLCS851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 19 Apr 2000 14:50:46 -0500 Message-ID: <38FDFEA6.778C3871@Software.com> Date: Wed, 19 Apr 2000 11:44:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4B365BF45AECBA4C7191A80C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms4B365BF45AECBA4C7191A80C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > > Doug (and David): > > I don't see that there is a problem with having numerous definitions > for time zones with a different TZID or TZNAME but with the same time > zone information. I agree with you "over the wire". I was thinking of IANA registration overhead. If one changes - how do the IANA people know they are "THE SAME" as another? Unless we have some out of band information? > > Time zones, by nature, are under local governmental control. If there > are two or more locals at the same UTC offset, then they would fall > under this case. I agree - Not the issue. US/Pacific is simply an old name for America/Los_Angeles. So it is NOT that I was asking for all gmt-offset values that have the same offset to be the same name. I was asking what do we do with the historical names? > A given time zone may have had its definition changed over time. This > would account for multiple definitions for the same time zone, also. Yes - those are easy. If the name is different - we register its different name. Each with there own unique data. > Likewise, the duplicate definitions could result from a change in the > name or identifier of one or more of these time zone definitions. Exactly the question! So how do we specify that XX == YY and only the name has changed? Using VTIMEZONE restrictions as defined by the IETF docs? > In any case, our role is merely to capture all the definitions in a common > format. Not to become time zone tsars and redefine the time zone > definitions, names or whatever. Right? We do NOT want to be the czar of timezones! We do want clients to be able to use existing and historical names to be able to understand and communicate iCalendar/VTIMEZONE data. -Doug --------------ms4B365BF45AECBA4C7191A80C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQxOTE4NDQ1NVowIwYJKoZIhvcNAQkEMRYEFG28wI5yda2VIS5hA+gNaHxtXDB9 MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEDhsGP3A/p4 KaC0D85nN34R3xFOhR0k8JYEOTCWwqFYSEAkbegbBAq7+MYcPNHXdmeikZvdAMA/rCrlaqt9 Y14c --------------ms4B365BF45AECBA4C7191A80C-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 16:27:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13769 for ; Wed, 19 Apr 2000 16:27:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08416 for ietf-calendar-bks; Wed, 19 Apr 2000 13:06:28 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08412 for ; Wed, 19 Apr 2000 13:06:27 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000419201011.XLRA851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 19 Apr 2000 15:10:11 -0500 Message-ID: <38FE0330.33DADDA2@Software.com> Date: Wed, 19 Apr 2000 12:04:16 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0C9619F6DB3C4B3D11216319" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms0C9619F6DB3C4B3D11216319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > > Both Colin and Ross indicated that they would prefer a single > definition of a time zone. I understood the email to say - throw away the old names. > By time zone, I assume you mean the definition for a specific geographical > locale. The definition of that "time zone" definition is outside our > control. Time zone definitions are the domain of the locale governing > authority. The registration in the IANA db would have to be open too, > for other practical reasons (e.g., how can a registrar check the > authorization of a submission?). True. Do we keep the old names also? > May be we should discuss the registration process and the change control > process? I have been assuming that it would be the same as is used for the > MIME multimedia content type registrations. Needed. --------------ms0C9619F6DB3C4B3D11216319 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQxOTE5MDQxN1owIwYJKoZIhvcNAQkEMRYEFA+Zt5oBy7SuRmtN/YOugeLFVkvx MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEBB/Z1TOZOl PtsngETHw+l65Hh1dLOJGLoZMtj3aR2VUGRSr4/zDL+RpTsiCjOB9Arw+841RCcwAiQoEqUa qA3+ --------------ms0C9619F6DB3C4B3D11216319-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 16:27:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13780 for ; Wed, 19 Apr 2000 16:27:11 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08450 for ietf-calendar-bks; Wed, 19 Apr 2000 13:08:33 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08446 for ; Wed, 19 Apr 2000 13:08:31 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000419201215.XLSH851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 19 Apr 2000 15:12:15 -0500 Message-ID: <38FE03AF.D3C963FA@Software.com> Date: Wed, 19 Apr 2000 12:06:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FDE124.79E929DC@ecal.com> <38FDE751.2991A2B3@renault.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3EB7D7BEB2D77286D664B1D7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms3EB7D7BEB2D77286D664B1D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Antoine Leca wrote: > > John Stracke wrote: > > > > If a government changes its time zones, there must be a new > > registration done by the time the new rules go into effect. > > Certainly. However, I do not expect a lot of "governments" > (large meaning) to prepare submissions. Rather, Olson's database > history is more matter of work from voluntarians; and I cannot > see why things would go another way for the IANA registry > (I hope I guess wrong, though). The same. --------------ms3EB7D7BEB2D77286D664B1D7 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQxOTE5MDYyNFowIwYJKoZIhvcNAQkEMRYEFNEPR/8lr3zNf6yZbhpNDr6+iivr MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEB4bUhJ0zqA dXMKZBaD/tADTEOUnelAtUWLOYVduVpSmRCZ7Y4Zvcx3kCChyLRqo0YYeZ7t0RZUMgpR0aCK Lft7 --------------ms3EB7D7BEB2D77286D664B1D7-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 16:27:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13796 for ; Wed, 19 Apr 2000 16:27:40 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08386 for ietf-calendar-bks; Wed, 19 Apr 2000 13:03:42 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08382 for ; Wed, 19 Apr 2000 13:03:40 -0700 (PDT) Received: from Software.com ([207.175.94.52]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000419200723.XLPI851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Wed, 19 Apr 2000 15:07:23 -0500 Message-ID: <38FE028B.7B1B45B3@Software.com> Date: Wed, 19 Apr 2000 12:01:31 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5A32D66AF9857417DD6025B0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms5A32D66AF9857417DD6025B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > > >I think that only one should be the IANA registered name. > >The other(s) some kind of alias. > > Do we mean the TZNAME or TZID? iCalendar allows multiple TZNAMEs for > the same time zone definition. In the OLSEN db, I believe the two > concepts are merged into one. In iCalendar, there can be only one TZID > for a given definition, but that definition can have multiple "names" > or TZNAME properties. COMMENT property is also allowed. Yes - but in the Olson database they have what they call 'Link's. And that allows them to define that (in iCal terms) TZID:1 == TZID:2 . TZNAME is(for example) PDT and PST, and they also have that in Olson (Olson-Format + Olson-Letter/s). Those can overlap and are only used to aid clients to format the data on the screen. TZNAMEs are not the IANA registered names described by tzid (tzidprefix) in RFC2445. > By "alias", we should mean a time zone definition created by someone other > than the official owner for the given time zone definition (e.g., some > programmer trying to make sense out of this historical mess ;-). Any of the > official time zone definitions, captured by the OLSEN db should be retained > as individual time zone definitions by the IANA registry. We should also > recognize that as the geographical boundaries for legal locales gets > redefined, the IANA will have new time zone definitions added that will > possibly look like duplicate definitions for the same time zone (e.g., we > could get two European definitions for Kosovo). Olson keeps both names (where both can be > 2) . I was trying to figure out how to keep both names. > May be some of the apparent cases of an "alias" are actually intended to be > different time zone definitions. ... No - in the Olson database they are simply alternate names for the same data. > > >I am leaning towards (2) - or maybe (4) COMMENTS? > > What is wrong with (1)? This seems the only practical solution, given > that we will have to have procedure for adding entries to the IANA > registry and that any one of these additions could appear to be a > duplicate definition for the same time zone definition. But, it might > not be. It might be a definition for a legal time zone that has the > same UTC offset as an existing entry in the IANA registry. Because in the Olson data base if I update America/Los_Angeles, then I am also updating US/Pacific. If we register them separately - they IANA will have to track that they are the same. And whenever one is updated, they will have to update the other. For how long? How will they know to do this? What if one gets out of sync with the other - which one is correct? > >Problems with (2) - how many can we allowed to be registered for > >the same data? It should be discouraged to create new TZIDs just > >because you can. > > Since we don't control the definition of time zones, only the definition > of how they are represented in the IANA registry, this is a moot > question. If xyz country decides to define a time zone then we need to > add it. If the xyz country has a brain fart and decides to redefine the > time zone, then we need to add that one. We aren't time zone tsars. True - but not the same question. What if xyz country decides to call the 'US/Pacific' timezone 'WestOfUs' because that is what they call the US/Pacific timezone in their country. Do we just keep adding aliases? Maybe. > >Another way would be a variation of (1), except we tweak the > >non-standard name so that it is not valid sometime soon. > >RRULE with an until value in the short future. > > Again, do we mean "identifier" or "name". iCalendar allows the TZNAME > property to be repeated any number of times for different display names, in a > VTIMEZONE definition. Yes we do - the question was not TZNAME - it was TZID. We could add the data in TZNAME. Someone else commented on that. However TZNAME only goes in daylightc or standardc. So where does US/Pacific go - in daylightc or standardc? We (so far) do not allow more that one identifier for each set of time zone data. -Doug --------------ms5A32D66AF9857417DD6025B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQxOTE5MDEzMlowIwYJKoZIhvcNAQkEMRYEFNFawEwXH5fkLMzyQYh1R+qQpWKr MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEDIOvsw+d3F jor8XpL3C5r9dibTJr2Ox8LOD7d4O34lTUyiDU7xOeb0nblptURcR35y3I4ke2gNSKmMiE/S Ajj9 --------------ms5A32D66AF9857417DD6025B0-- From owner-ietf-calendar@mail.imc.org Wed Apr 19 17:38:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14814 for ; Wed, 19 Apr 2000 17:38:45 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA09645 for ietf-calendar-bks; Wed, 19 Apr 2000 14:17:12 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09641 for ; Wed, 19 Apr 2000 14:17:10 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id RAA03762 for ; Wed, 19 Apr 2000 17:21:07 -0400 Message-ID: <38FE2341.ADE835CE@ecal.com> Date: Wed, 19 Apr 2000 17:21:05 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FCB5EF.4BA8778A@Software.com> <38FDBD29.DC43BABA@ecal.com> <38FDFC3D.FBA41067@Software.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: > John Stracke wrote: > > > First: we need to permit all the names, because people are using them (or, > > at least, we can't be sure that people aren't using them, which is just as > > bad). > > I think we MUST be able to find a VTIMEZONE given common names. > > (1) However are you saying that ALL must be the 'standard' IANA > registered name? I'm saying that all the names must be registered with IANA, whether they're aliases or not. (a) If only The Official Name is registered, then we have a uniqueness problem--IANA won't be able to protect us from registering a new Official Name that conflicts with an existing alias. (b) If aliases are not registered, then they can't be used, because the sender can't be sure the recipient can understand them. > > For example, Unix boxen generally have the Olsen database installed > > (on my RedHat6.2 box it's under /usr/share/zoneinfo); a program running on > > a Unix box ought to be able to look at the system's timezone and use that > > as its default. Since the database is installed with all the names, the > > program needs to be able to use any of them. > > Use all? - Yes. > All names a standard name? - I think - no. If they're going to be used, they have to be standardized. > If a timezone server were setup. Could (should?) we: > > client: Ask server for FOO-OLD time zone. > > server: I know what FOO-OLD is. However it's not the > official name, so I'll return: > > success - code followed by: > > BEGIN:VTIMEZONE > TZID:FOO > ... > :FOO-OLD > ... > END:VTIMEZONE. > > So that you can get what you need, but are also informed of what > you should ask for in the future (ask for FOO). That sounds good to me--except that we shouldn't advise clients to use FOO in the future. If someone typed in an alias, it may be for a good reason (as in my Pennsylvania scenario). > > Next: I agree that it would be best to register each set of data just > > once (hence the "almost disagree"). So either we register some names with > > data, and some with pointers; or we register data with multiple names. (I > > don't have strong feelings either way here.) Either way, some of the names > > are aliases. > > (1) We currently do not have any way to do a 'pointer' inside > if VTIMEZONE data. No, it'd have to be in the IANA registry somehow. > (2) I think you are asking the same question as me. Could be. > > Finally: I do not think that we should distinguish syntactically between > > canonical names and alias names (in your examples, by putting a slash in > > front of some but not others). > > This is already part of RFC2445, search for the string 'tzidprefix'. > It is how the WG already decided to identify IANA registered TZIDs. Fine, then they all need the prefix, since they all need to be registered. > If the name 'America/Pennsylvania' were not already registered. > Then there is no conflict. Once it were to be registered, then > 'that' new data 'is' the data and the TZID would be > '/America/Pennsylvania'. So there would be no issue. The point is that it should be possible to change a registration from an alias to a non-alias, for transition cases: create the alias to point to the current data, then change the registration when the new data is available. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"Dinner Special: Turkey $2.35; Chicken or Beef| |francis@ecal.com|$2.25; Children $2.00." | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 20 12:54:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15778 for ; Thu, 20 Apr 2000 12:54:31 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA04826 for ietf-calendar-bks; Thu, 20 Apr 2000 09:31:16 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04822; Thu, 20 Apr 2000 09:31:15 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA09408; Thu, 20 Apr 2000 12:52:13 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA08828; Thu, 20 Apr 2000 12:35:02 -0400 (EDT) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: VTIMEZONE and signular TZID X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Thu, 20 Apr 2000 12:30:58 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/20/2000 12:31:02 PM, Serialize complete at 04/20/2000 12:31:02 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0058D86F852568C7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058D86F852568C7_= Content-Type: text/plain; charset="us-ascii" >So how do we specify that XX == YY and only the name has changed? >Using VTIMEZONE restrictions as defined by the IETF docs? So...Here is a proposal. IANA (or the IETF designated facilitator for this registration) allocates the registered TZID names. As the registrar of the standard VTIMEZONE definitions, this is a reasonable restriction. However, for a given time zone definition, you can have multiple TZNAME property values. This is allowed by iCalendar. A registration for a VTIMEZONE registrar form would not include the TZID, as this is returned after successful completion of the registration process. To know that XX is the same as YY, you would get a time zone definition and find that both TZNAME=XX and TZNAME=YY are specified for TZID=. Sound okay? I think that this would solve your problem. NET-net: Only the IANA defines the TZIDs. This allows some level of assurance that duplicate TZID values for the same time zone definition (TZNAME aside) are avoided. TZNAMEs are specified by the individual making the registration. Multiple TZNAME values for a given time zone definition are allowed and welcomed. -- Frank --=_alternative 0058D86F852568C7_= Content-Type: text/html; charset="us-ascii"
>So how do we specify that XX == YY and only the name has changed?
>Using VTIMEZONE restrictions as defined by the IETF docs?

So...Here is a proposal. IANA (or the IETF designated facilitator for this registration) allocates the registered TZID names. As the registrar of the standard VTIMEZONE definitions, this is a reasonable restriction. However, for a given time zone definition, you can have multiple TZNAME property values. This is allowed by iCalendar.

A registration for a VTIMEZONE registrar form would not include the TZID, as this is returned after successful completion of the registration process.

To know that XX is the same as YY, you would get a time zone definition and find that both TZNAME=XX and TZNAME=YY are specified for TZID=<only IANA will specify this value>.

Sound okay? I think that this would solve your problem.

NET-net: Only the IANA defines the TZIDs. This allows some level of assurance that duplicate TZID values for the same time zone definition (TZNAME aside) are avoided. TZNAMEs are specified by the individual making the registration. Multiple TZNAME values for a given time zone definition are allowed and welcomed.

-- Frank

--=_alternative 0058D86F852568C7_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 20 14:14:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17796 for ; Thu, 20 Apr 2000 14:14:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05871 for ietf-calendar-bks; Thu, 20 Apr 2000 10:52:05 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05867 for ; Thu, 20 Apr 2000 10:52:03 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id NAA05873 for ; Thu, 20 Apr 2000 13:56:06 -0400 Message-ID: <38FF44B6.1CA6734F@ecal.com> Date: Thu, 20 Apr 2000 13:56:06 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID 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 Frank_Dawson@lotus.com wrote: > NET-net: Only the IANA defines the TZIDs. This allows some > level of assurance that duplicate TZID values for the same time > zone definition (TZNAME aside) are avoided. TZNAMEs are > specified by the individual making the registration. Multiple > TZNAME values for a given time zone definition are allowed and > welcomed. This sounds good to me. One clarification: would TZNAME values be unique? (That is, is it guaranteed that you don't have two TZNAMEs that map to the same TZID?) I think they need to be. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |A ship is safe in a harbor, but that's not what| |francis@ecal.com|a ship is for. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 20 15:02:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18823 for ; Thu, 20 Apr 2000 15:02:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06614 for ietf-calendar-bks; Thu, 20 Apr 2000 11:42:12 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06610 for ; Thu, 20 Apr 2000 11:42:11 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA23546; Thu, 20 Apr 2000 15:03:09 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA26471; Thu, 20 Apr 2000 14:45:58 -0400 (EDT) To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Thu, 20 Apr 2000 14:41:52 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/20/2000 02:41:57 PM, Serialize complete at 04/20/2000 02:41:57 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00673B12852568C7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00673B12852568C7_= Content-Type: text/plain; charset="us-ascii" John Stracke wrote, in part: >This sounds good to me. One clarification: would TZNAME values >be unique? (That is, is it guaranteed that you don't have two >TZNAMEs that map to the same TZID?) I think they need to be. TZNAMES have no such constraint. You look up by TZID. Doug Royer has suggested an iCalendar VTIMEZONE component extension be registered for a TZID-ALIAS text-valued property. This sounds good to me too. This is where the Olson time zone identifer names would be recorded. The TZID would be assigned by the "IANA VTIMEZONE registration coordinator". Ah, we need that registration process defined. -- Frank --=_alternative 00673B12852568C7_= Content-Type: text/html; charset="us-ascii"
John Stracke wrote, in part:

>This sounds good to me.  One clarification: would TZNAME values
>be unique? (That is, is it guaranteed that you don't have two
>TZNAMEs that map to the same TZID?) I think they need to be.

TZNAMES have no such constraint. You look up by TZID.

Doug Royer has suggested an iCalendar VTIMEZONE component extension be registered for a TZID-ALIAS text-valued property. This sounds good to me too. This is where the Olson time zone identifer names would be recorded. The TZID would be assigned by the "IANA VTIMEZONE registration coordinator". Ah, we need that registration process defined.

-- Frank
 --=_alternative 00673B12852568C7_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 20 15:10:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19156 for ; Thu, 20 Apr 2000 15:10:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06720 for ietf-calendar-bks; Thu, 20 Apr 2000 11:50:22 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06716 for ; Thu, 20 Apr 2000 11:50:20 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id OAA06167 for ; Thu, 20 Apr 2000 14:54:24 -0400 Message-ID: <38FF525E.261E1A00@ecal.com> Date: Thu, 20 Apr 2000 14:54:23 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID 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 Frank_Dawson@lotus.com wrote: > Doug Royer has suggested an iCalendar VTIMEZONE component > extension be registered for a TZID-ALIAS text-valued property. Sounds good, provided we can look up by ID without knowing whether the ID is a TZID or a TZID-ALIAS. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Go not to the Vorlons for advice, for they will| |francis@ecal.com|say both no and sherbert. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 20 15:18:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19326 for ; Thu, 20 Apr 2000 15:18:18 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA06737 for ietf-calendar-bks; Thu, 20 Apr 2000 11:51:18 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06733 for ; Thu, 20 Apr 2000 11:51:17 -0700 (PDT) Received: from Software.com ([207.175.94.147]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000420185505.YKGY851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Thu, 20 Apr 2000 13:55:06 -0500 Message-ID: <38FF4309.7A4CED16@Software.com> Date: Thu, 20 Apr 2000 10:48:57 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FF44B6.1CA6734F@ecal.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8CBFDB6E47AD2E3A5ECB351E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms8CBFDB6E47AD2E3A5ECB351E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Frank_Dawson@lotus.com wrote: > > > NET-net: Only the IANA defines the TZIDs. This allows some > > level of assurance that duplicate TZID values for the same time > > zone definition (TZNAME aside) are avoided. TZNAMEs are > > specified by the individual making the registration. Multiple > > TZNAME values for a given time zone definition are allowed and > > welcomed. > > This sounds good to me. One clarification: would TZNAME values > be unique? (That is, is it guaranteed that you don't have two > TZNAMEs that map to the same TZID?) I think they need to be. TZNAMEs are unique ONLY within a VTIMEZONE. They were never meant to be unique across VTIMEZONEs. Because of existing software and user expectations; I think that we need a TZALIAS for ALL the Olson names plus any other common names. Then let the IANA registrar pick (with recommendations) the official TZID name. In the future you should be able to query for a 'string'. Then a future server could give you all VTIMEZONEs where 'string' was in TZID, TZALIAS, or TZNAME. Or you could refine your search to a subset. Then the client + user could select which one they wanted. TZID - The Unique name for a timezone definition. Currently they are only unique within a VCALENDAR object when they do not start with tzidprefix. When they are prefixed with tzidprefix, then they are unique in IANA and across all VTIMEZONE definitions. We would be keeping the same definition and expectation for TZID. Currently NONE are registered (none should start with tzidprefix). I am working on the registration process now. TZNAME - Unique within a *single* VTIMEZONE (but not across VTIMEZONEs) that specifies which formatted name to use. (PDT, EST, CEST, ...). There could be multiple standardc or daylightc with the same TZNAME in one VTIMEZONE. They can only specify different recurrence rules for the same TZNAME. For example; one valid for 1900-1930, another with the same TZNAME valid for 1931-future). This is the current definition and expectation in iCalendar. TZALIAS - Names that GUI's, OS's, or people tend to use. (US/Pacific, PDT8PST, America/Los_Angles, GMT+8, ...). This is a user friendly string that is unique across all VTIMEZONEs. If we agree. Then I'll submit an IANA extension to iCalendar for a TZALIAS that will exist only at the VTIMEZONE scope. Possible new proposed ABNF for VTIMEZONE might be (comments removed - see RFC2445 section 4.6.5): timezonec = "BEGIN" ":" "VTIMEZONE" CRLF 2*( tzid / tzalias / last-mod / tzurl / standardc / daylightc / x-prop ) "END" ":" "VTIMEZONE" CRLF standardc = "BEGIN" ":" "STANDARD" CRLF tzprop "END" ":" "STANDARD" CRLF daylightc = "BEGIN" ":" "DAYLIGHT" CRLF tzprop "END" ":" "DAYLIGHT" CRLF tzprop = 3*(dtstart / tzoffsetto / tzoffsetfrom / comment / rdate / rrule / tzname / x-prop) TZNAME remains inside of tzprop (same as RFC2445). TZID is the same as it was in RFC2445, (above) TZALIAS added. Thanks Frank for you help! -Doug --------------ms8CBFDB6E47AD2E3A5ECB351E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQyMDE3NDkwMFowIwYJKoZIhvcNAQkEMRYEFJrNtrZT3RDaXC442Uwc+tCJlKjH MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEA0J6KlGaJ1 l/tnhbQrMiTB04BxpDRWAKEHWihQfF1VSSFgKPDX0Iw/K8Zm+7VMmkZ6eYhmhaRNp5Kohz/7 rAgk --------------ms8CBFDB6E47AD2E3A5ECB351E-- From owner-ietf-calendar@mail.imc.org Thu Apr 20 15:53:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20116 for ; Thu, 20 Apr 2000 15:52:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA07227 for ietf-calendar-bks; Thu, 20 Apr 2000 12:31:32 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07223 for ; Thu, 20 Apr 2000 12:31:30 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id PAA06255 for ; Thu, 20 Apr 2000 15:35:33 -0400 Message-ID: <38FF5C05.AC80D124@ecal.com> Date: Thu, 20 Apr 2000 15:35:33 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FF44B6.1CA6734F@ecal.com> <38FF4309.7A4CED16@Software.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: > In the future you should be able to query for a 'string'. > Then a future server could give you all VTIMEZONEs where > 'string' was in TZID, TZALIAS, or TZNAME. Or you could > refine your search to a subset. Then the client + user could > select which one they wanted. Or you could do an exact-match search for TZID or TZALIAS (the client might be a robot, with no user to exercise judgment; and the timezone server can serve an exact match more efficiently than a substring query). > TZID - The Unique name for a timezone definition. > TZALIAS - Names that GUI's, OS's, or people tend to use. Can we specify that the TZID and TZALIAS namespaces must not overlap? (A program that looks at the OS's timezone setting would like to be able to use that timezone name to look up the VTIMEZONE without knowing whether it's supposed to look up a TZID or a TZALIAS.) If so, this sounds great to me. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |The Net regards censorship as damage, and routes| |francis@ecal.com|around it. -- John Gilmore | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 20 17:14:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21513 for ; Thu, 20 Apr 2000 17:14:17 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA08235 for ietf-calendar-bks; Thu, 20 Apr 2000 13:50:58 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08231 for ; Thu, 20 Apr 2000 13:50:57 -0700 (PDT) Received: from Software.com ([207.175.94.147]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000420205446.YNCN851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Thu, 20 Apr 2000 15:54:46 -0500 Message-ID: <38FF5F18.1EDB67A6@Software.com> Date: Thu, 20 Apr 2000 12:48:40 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FF44B6.1CA6734F@ecal.com> <38FF4309.7A4CED16@Software.com> <38FF5C05.AC80D124@ecal.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms958221C9225B30C2D94D41B3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms958221C9225B30C2D94D41B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > > > In the future you should be able to query for a 'string'. > > Then a future server could give you all VTIMEZONEs where > > 'string' was in TZID, TZALIAS, or TZNAME. Or you could > > refine your search to a subset. Then the client + user could > > select which one they wanted. > > Or you could do an exact-match search for TZID or TZALIAS (the > client might be a robot, with no user to exercise judgment; and > the timezone server can serve an exact match more efficiently than > a substring query). I never said a substring query. I meant subset of the list. > > TZALIAS - Names that GUI's, OS's, or people tend to use. > > Can we specify that the TZID and TZALIAS namespaces must not overlap? Sounds good. A registered TZID MUST start with tzidprefix. A TZALIAS MUST NEVER start with a tzidprefix. Should solve the problem. > (A > program that looks at the OS's timezone setting would like to be able to use > that timezone name to look up the VTIMEZONE without knowing whether it's > supposed to look up a TZID or a TZALIAS.) If so, this sounds great to me. Exactly my thoughts! -Doug --------------ms958221C9225B30C2D94D41B3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQyMDE5NDg0MVowIwYJKoZIhvcNAQkEMRYEFKKL2Y4YMfCp+SHIquT4h6gIbD9X MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEBLqHssJCXX WLUSfP0YwN//aOTriszaeHDLOhxdmNH3h0IHShNamvXJG0AagUL+sm7a6bLShHlBkzgYXO2H ze6k --------------ms958221C9225B30C2D94D41B3-- From owner-ietf-calendar@mail.imc.org Fri Apr 21 11:13:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18740 for ; Fri, 21 Apr 2000 11:13:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA04178 for ietf-calendar-bks; Fri, 21 Apr 2000 07:48:30 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04174 for ; Fri, 21 Apr 2000 07:48:29 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA08431; Fri, 21 Apr 2000 10:53:05 -0400 Message-ID: <39006B4F.AD583ECB@ecal.com> Date: Fri, 21 Apr 2000 10:53:04 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FF44B6.1CA6734F@ecal.com> <38FF4309.7A4CED16@Software.com> <38FF5C05.AC80D124@ecal.com> <38FF5F18.1EDB67A6@Software.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: > I never said a substring query. I meant subset of the list. Ah--I misunderstood what you meant by "where 'string' was in". > > Can we specify that the TZID and TZALIAS namespaces must not overlap? > > Sounds good. > > A registered TZID MUST start with tzidprefix. > A TZALIAS MUST NEVER start with a tzidprefix. But then a given ID can't transition from one to the other (as in my Pennsylvania example). I was thinking of doing it by IANA management: they would maintain a single list of IDs; the entry for each would be either a VTIMEZONE or a TZID. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |For an engineer, paranoia is not an affliction;| |francis@ecal.com|it's a tool. | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 21 12:03:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19825 for ; Fri, 21 Apr 2000 12:03:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05216 for ietf-calendar-bks; Fri, 21 Apr 2000 08:42:11 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05212 for ; Fri, 21 Apr 2000 08:42:09 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA00686; Fri, 21 Apr 2000 12:03:14 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA26126; Fri, 21 Apr 2000 11:46:00 -0400 (EDT) To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Fri, 21 Apr 2000 11:41:55 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/21/2000 11:41:58 AM, Serialize complete at 04/21/2000 11:41:58 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0056C273852568C8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056C273852568C8_= Content-Type: text/plain; charset="us-ascii" John Stracke wrote, in part: >But then a given ID can't transition from one to the other (as in my Pennsylvania >example). I was thinking of doing it by IANA management: they would maintain a >single list of IDs; the entry for each would be either a VTIMEZONE or a TZID. The iCalendar spec says that prefixed TZID values are registered. We only have a single TZID per VTIMEZONE definition. The TZID-ALIAS is would not be a registered TZID, hence it can't have the prefix. The "transition" you mention would involve creating a new VTIMEZONE registration with the newly assigned TZID and include the old VTIMEZONE TZID value as a TZID-ALIAS value on the new VTIMEZONE registration. Wouldn't that work okay? -- Frank --=_alternative 0056C273852568C8_= Content-Type: text/html; charset="us-ascii"
John Stracke wrote, in part:

>But then a given ID can't transition from one to the other (as in my Pennsylvania
>example).  I was thinking of doing it by IANA management: they would maintain a
>single list of IDs; the entry for each would be either a VTIMEZONE or a TZID.

The iCalendar spec says that prefixed TZID values are registered. We only have a single TZID per VTIMEZONE definition. The TZID-ALIAS is would not be a registered TZID, hence it can't have the prefix. The "transition" you mention would involve creating a new VTIMEZONE registration with the newly assigned TZID and include the old VTIMEZONE TZID value as a TZID-ALIAS value on the new VTIMEZONE registration.

Wouldn't that work okay?

-- Frank

--=_alternative 0056C273852568C8_=-- From owner-ietf-calendar@mail.imc.org Fri Apr 21 12:25:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20360 for ; Fri, 21 Apr 2000 12:25:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA05532 for ietf-calendar-bks; Fri, 21 Apr 2000 09:02:03 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05527 for ; Fri, 21 Apr 2000 09:02:02 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA08500 for ; Fri, 21 Apr 2000 12:06:39 -0400 Message-ID: <39007C8E.649A716B@ecal.com> Date: Fri, 21 Apr 2000 12:06:39 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID 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 Frank_Dawson@lotus.com wrote: > The "transition" you mention would involve creating a new > VTIMEZONE registration with the newly assigned TZID and include > the old VTIMEZONE TZID value as a TZID-ALIAS value on the new > VTIMEZONE registration. > > Wouldn't that work okay? Uh...oh. Yes, it would. (An extra ongoing indirection layer, but fine--it's not going to be a *common* case.) OK, then. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |For an engineer, paranoia is not an affliction;| |francis@ecal.com|it's a tool. | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 21 13:19:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21640 for ; Fri, 21 Apr 2000 13:19:11 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA06463 for ietf-calendar-bks; Fri, 21 Apr 2000 09:56:41 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06459 for ; Fri, 21 Apr 2000 09:56:39 -0700 (PDT) Received: from Software.com ([207.175.94.127]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000421170033.ZAZZ851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Fri, 21 Apr 2000 12:00:33 -0500 Message-ID: <390079AC.3EA87022@Software.com> Date: Fri, 21 Apr 2000 08:54:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FF44B6.1CA6734F@ecal.com> <38FF4309.7A4CED16@Software.com> <38FF5C05.AC80D124@ecal.com> <38FF5F18.1EDB67A6@Software.com> <39006B4F.AD583ECB@ecal.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0CE09F73B7D7788A8A414A2A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms0CE09F73B7D7788A8A414A2A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > > > I never said a substring query. I meant subset of the list. > > Ah--I misunderstood what you meant by "where 'string' was in". > > > > Can we specify that the TZID and TZALIAS namespaces must not overlap? > > > > Sounds good. > > > > A registered TZID MUST start with tzidprefix. > > A TZALIAS MUST NEVER start with a tzidprefix. > > But then a given ID can't transition from one to the other (as in > my Pennsylvania example). I was thinking of doing it by IANA management: > they would maintain a single list of IDs; the entry for each would be > either a VTIMEZONE or a TZID. Not sure what you mean. Did you mean a TZALIAS or TZNAME when you said 'VTIMEZONE'? -Doug --------------ms0CE09F73B7D7788A8A414A2A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDQyMTE1NTQyMVowIwYJKoZIhvcNAQkEMRYEFOBidv73uDACltuyfoyr/6Z6ZN75 MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEDQC9Qa0f/F S1WP7W163HKj48kGMl8uHjDO4YJ60ceJxJHXCfHaDOE17leNUu8BChWrC3nwtFoXBh9vH1hH m5kA --------------ms0CE09F73B7D7788A8A414A2A-- From owner-ietf-calendar@mail.imc.org Fri Apr 21 13:45:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22196 for ; Fri, 21 Apr 2000 13:45:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06793 for ietf-calendar-bks; Fri, 21 Apr 2000 10:25:29 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06789 for ; Fri, 21 Apr 2000 10:25:27 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id NAA01025 for ; Fri, 21 Apr 2000 13:29:51 -0400 Message-ID: <3900900F.113A0652@ecal.com> Date: Fri, 21 Apr 2000 13:29:51 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID References: <38FF44B6.1CA6734F@ecal.com> <38FF4309.7A4CED16@Software.com> <38FF5C05.AC80D124@ecal.com> <38FF5F18.1EDB67A6@Software.com> <39006B4F.AD583ECB@ecal.com> <390079AC.3EA87022@Software.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: > > I was thinking of doing it by IANA management: > > they would maintain a single list of IDs; the entry for each would be > > either a VTIMEZONE or a TZID. > > Not sure what you mean. Did you mean a TZALIAS or TZNAME when > you said 'VTIMEZONE'? No, I meant VTIMEZONE. Some entries would be the actual data (i.e., VTIMEZONEs); others would be pointers to entries containing actual data (i.e., TZIDs). Just a clarification; as Frank has pointed out, we don't need to do it that way for the transition to work. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |A mime is a wonderful thing to waste. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Sun Apr 23 03:27:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02740 for ; Sun, 23 Apr 2000 03:27:18 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA08957 for ietf-calendar-bks; Sat, 22 Apr 2000 23:55:44 -0700 (PDT) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08953 for ; Sat, 22 Apr 2000 23:55:42 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA02425 for ietf-calendar@imc.org; Sun, 23 Apr 2000 00:00:03 -0700 (PDT) Date: Sun, 23 Apr 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200004230700.AAA02425@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM ? Y ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@mail.imc.org Mon Apr 24 16:15:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13889 for ; Mon, 24 Apr 2000 16:15:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA09248 for ietf-calendar-bks; Mon, 24 Apr 2000 12:40:22 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09244 for ; Mon, 24 Apr 2000 12:40:19 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA24962; Mon, 24 Apr 2000 15:43:34 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA04963; Mon, 24 Apr 2000 15:44:21 -0400 (EDT) To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Mon, 24 Apr 2000 16:31:04 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/24/2000 03:40:07 PM, Serialize complete at 04/24/2000 03:40:07 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006C83B9852568CB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C83B9852568CB_= Content-Type: text/plain; charset="us-ascii" John Stracke wrote, in part: >No, I meant VTIMEZONE. Some entries would be the actual data (i.e., >VTIMEZONEs); others would be pointers to entries containing actual data (i.e., >TZIDs). Actually, all entries in the IANA registry are valid VTIMEZONE component definitions. So, by definition, they must be complete (while they can be minimally complete) VTIMEZONE definitions. They would NOT be some empty component with only a TZID and TZID-ALIAS. Right, Doug? --=_alternative 006C83B9852568CB_= Content-Type: text/html; charset="us-ascii"
John Stracke wrote, in part:

>No, I meant VTIMEZONE.  Some entries would be the actual data (i.e.,
>VTIMEZONEs); others would be pointers to entries containing actual data (i.e.,
>TZIDs).

Actually, all entries in the IANA registry are valid VTIMEZONE component definitions. So, by definition, they must be complete (while they can be minimally complete) VTIMEZONE definitions. They would NOT be some empty component with only a TZID and TZID-ALIAS.

Right, Doug? --=_alternative 006C83B9852568CB_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 24 16:16:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13912 for ; Mon, 24 Apr 2000 16:16:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA09524 for ietf-calendar-bks; Mon, 24 Apr 2000 12:58:20 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09520 for ; Mon, 24 Apr 2000 12:58:18 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id QAA08500; Mon, 24 Apr 2000 16:02:54 -0400 Message-ID: <3904A86E.6C6EA827@ecal.com> Date: Mon, 24 Apr 2000 16:02:54 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID 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 Frank_Dawson@lotus.com wrote: > John Stracke wrote, in part: > > >No, I meant VTIMEZONE. Some entries would be the actual data > (i.e., > >VTIMEZONEs); others would be pointers to entries containing > actual data (i.e., > >TZIDs). > > Actually, all entries in the IANA registry are valid VTIMEZONE > component definitions. Um...it doesn't yet exist, right? So it doesn't have to be one way or another; it can be designed to be whatever seems to be The Right Thing. (Granted, if there are no entries the above is a true statement; but only in the same sense that all ten-mile-tall reindeer are green. :-) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |But this one goes to 11x. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Apr 24 16:37:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14439 for ; Mon, 24 Apr 2000 16:37:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09766 for ietf-calendar-bks; Mon, 24 Apr 2000 13:19:37 -0700 (PDT) Received: from lnsmtp.on.com (lnsmtp.on.com [207.18.216.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA09760 for ; Mon, 24 Apr 2000 13:19:35 -0700 (PDT) From: MCiavari@meetingmaker.com Received: by lnsmtp.on.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 852568CB.00704DB3 ; Mon, 24 Apr 2000 16:26:39 -0400 X-Lotus-FromDomain: ON TECHNOLOGY To: ietf-calendar@imc.org Message-ID: <852568CB.00704C76.00@lnsmtp.on.com> Date: Mon, 24 Apr 2000 16:16:17 -0400 Subject: VTIMEZONE duplicate entries Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I've been reading the emails on duplicate timezone entries in the database. My area of concern is with applications searching this database for a particular timezone. If we don't adhere to stricked rules limiting duplicate records, I'm concerned that this database could get quite large. I realize that our limitations and obligations are to the governing bodies of each country and what they preceive as their timezones which do require multiple entries for certain areas which we must account for but I feel we should not freely create duplicates. So, let's see if we can come up with the smallest set of timezones that accurately represent the world's current timezones for a first pass. Ok... From owner-ietf-calendar@mail.imc.org Mon Apr 24 17:17:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15278 for ; Mon, 24 Apr 2000 17:17:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA10170 for ietf-calendar-bks; Mon, 24 Apr 2000 13:54:46 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10166 for ; Mon, 24 Apr 2000 13:54:44 -0700 (PDT) Received: from Software.com ([207.175.94.127]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000424205830.JRA851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Mon, 24 Apr 2000 15:58:30 -0500 Message-ID: <3904A5D4.756C65F0@Software.com> Date: Mon, 24 Apr 2000 12:51:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE duplicate entries References: <852568CB.00704C76.00@lnsmtp.on.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 MCiavari@meetingmaker.com wrote: > > Hi all, I've been reading the emails on duplicate timezone entries in the > database. My area of concern is with applications searching this database > for a particular timezone. If we don't adhere to stricked rules limiting > duplicate records, I'm concerned that this database could get quite large. > I realize that our limitations and obligations are to the governing bodies > of each country and what they preceive as their timezones which do require > multiple entries for certain areas which we must account for but I feel we > should not freely create duplicates. > > So, let's see if we can come up with the smallest set of timezones that > accurately represent the world's current timezones for a first pass. DATA - Yes - let't not duplicate the data - I think this is your point? Converting the data is one of the steps. I do not see any reason to restrict what is converted. Once the data is converted any client could ask for only what it wanted. Any server could select what it would serve. It is a bit more complicated than that. If a servers intent was only to hold VTIMEZONE data for 1970 -> current date/time. It must provide more than one standardc and daylightc per VTIMEZONE to account for any changes over time for a given timezone. Also the format of the earliest VTIMEZONE can't be cut down simply because it started in 1969. If it did then it would pollute the registered name of that timezone. So a VTIEMZONE server would have some choices: (a) Return the TZID without the prefix - tzidprefix, and with a restricted set of data (1970->current). As the TZID with tzidprefix is the official set of data (tzidpreifx == full data). (b) Say 'NO' the VTIMEZONE registered name you asked for spans more time that that. I would envision a future TZ-server to be asked for one or more of: Current VTIMEZONE given a location (perhaps lat/lon or name of place) Any VTIMEZONE with a TZNAME, TZID, or TZALIAS of . Restrict the results to a date/time range. So you could find the correct VTIMEZONE for Phoenix AZ on Dec 1st 1971. With the client aware that it might get a non official result with stripped down data and a TZID without a tzidprefix. And of course it would assume the results were in the database. -Doug From owner-ietf-calendar@mail.imc.org Mon Apr 24 18:27:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16504 for ; Mon, 24 Apr 2000 18:27:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10995 for ietf-calendar-bks; Mon, 24 Apr 2000 15:06:04 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10990 for ; Mon, 24 Apr 2000 15:06:02 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id SAA13222 for ; Mon, 24 Apr 2000 18:09:23 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id SAA13017 for ; Mon, 24 Apr 2000 18:10:10 -0400 (EDT) To: ietf-calendar@imc.org Subject: Re: VTIMEZONE duplicate entries X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Mon, 24 Apr 2000 18:05:54 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/24/2000 06:05:56 PM, Serialize complete at 04/24/2000 06:05:56 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0079DBED852568CB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079DBED852568CB_= Content-Type: text/plain; charset="us-ascii" Doug Royer wrote, in part: > Current VTIMEZONE given a location > (perhaps lat/lon or name of place) Good point. Add GEO to your list of iCalendar "VTIMEZONE" component extensions! --=_alternative 0079DBED852568CB_= Content-Type: text/html; charset="us-ascii"
Doug Royer wrote, in part:

>                 Current VTIMEZONE given a location
>                 (perhaps lat/lon or name of place)

Good point. Add GEO to your list of iCalendar "VTIMEZONE" component extensions! --=_alternative 0079DBED852568CB_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 24 23:17:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22383 for ; Mon, 24 Apr 2000 23:17:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA01422 for ietf-calendar-bks; Mon, 24 Apr 2000 19:57:58 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA01418 for ; Mon, 24 Apr 2000 19:57:56 -0700 (PDT) Received: from Software.com ([207.175.94.127]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000425030208.QUT851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Mon, 24 Apr 2000 22:02:08 -0500 Message-ID: <3904FB0B.160B5B0F@Software.com> Date: Mon, 24 Apr 2000 18:55:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: VTIMEZONE and signular TZID 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 Frank_Dawson@lotus.com wrote: > > John Stracke wrote, in part: > > >No, I meant VTIMEZONE. Some entries would be the actual data (i.e., > >VTIMEZONEs); others would be pointers to entries containing actual data > (i.e., > >TZIDs). > > Actually, all entries in the IANA registry are valid VTIMEZONE component > definitions. So, by definition, they must be complete (while they can be > minimally complete) VTIMEZONE definitions. They would NOT be some empty > component with only a TZID and TZID-ALIAS. > > Right, Doug? I agree. I don't think we want to make a 'pointer' VTIMEZONE. I think the TZALIAS would work to solve that problem. -Doug From owner-ietf-calendar@mail.imc.org Tue Apr 25 00:16:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23649 for ; Tue, 25 Apr 2000 00:16:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA07305 for ietf-calendar-bks; Mon, 24 Apr 2000 20:52:19 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA07301 for ; Mon, 24 Apr 2000 20:52:18 -0700 (PDT) Received: from Software.com ([207.175.94.127]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000425035629.RTE851310.mta1biz.bizmailsrvcs.net@Software.com> for ; Mon, 24 Apr 2000 22:56:29 -0500 Message-ID: <390507C9.E45F709@Software.com> Date: Mon, 24 Apr 2000 19:49:45 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VTIMEZONE duplicate entries 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 Frank_Dawson@lotus.com wrote: > > Doug Royer wrote, in part: > > > Current VTIMEZONE given a location > > (perhaps lat/lon or name of place) > > Good point. Add GEO to your list of iCalendar "VTIMEZONE" component > extensions! We could do that. A GEO is one point, a VTIMEZONE is a set of points forming one or more polygons. Are you suggesting multiple GEO's each with multiple values. One GEO for each polygon. With each multivalue GEO set forming the points of the polygon? Someone on this list had an idea about using lat/long for determining your timezone. I think they sell the list. -Doug From owner-ietf-calendar@mail.imc.org Tue Apr 25 06:07:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07687 for ; Tue, 25 Apr 2000 06:07:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA28209 for ietf-calendar-bks; Tue, 25 Apr 2000 02:41:28 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28204 for ; Tue, 25 Apr 2000 02:41:26 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id FAA28665 for ; Tue, 25 Apr 2000 05:44:50 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id FAA04684 for ; Tue, 25 Apr 2000 05:45:38 -0400 (EDT) To: ietf-calendar@imc.org Subject: Re: VTIMEZONE duplicate entries X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 25 Apr 2000 05:41:19 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 04/25/2000 05:41:21 AM, Serialize complete at 04/25/2000 05:41:21 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0035B0EC852568CC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0035B0EC852568CC_= Content-Type: text/plain; charset="us-ascii" No. I would suggest that the GEO represent the centroid of the polygons forming the area associated with the VTIMEZONE. We did this on one GIS application that I worked on some time ago and it worked great. Then you just have to compute nearest-distance between your own GEO and that of a few VTIMEZONE candidates to figure out what the likelihood value for which one ought to be associated with you. Of course, there is always the case that the CU would manually select a time zone very far away, as would be the case when you want to associate yourself with US/Eastern, even though you are in Stuttgart, Germany! -- Frank --=_alternative 0035B0EC852568CC_= Content-Type: text/html; charset="us-ascii"
No. I would suggest that the GEO represent the centroid of the polygons forming the area associated with the VTIMEZONE.

We did this on one GIS application that I worked on some time ago and it worked great.

Then you just have to compute nearest-distance between your own GEO and that of a few VTIMEZONE candidates to figure out what the likelihood value for which one ought to be associated with you.

Of course, there is always the case that the CU would manually select a time zone very far away, as would be the case when you want to associate yourself with US/Eastern, even though you are in Stuttgart, Germany!

-- Frank --=_alternative 0035B0EC852568CC_=-- From owner-ietf-calendar@mail.imc.org Sun Apr 30 03:28:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00805 for ; Sun, 30 Apr 2000 03:28:42 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA15832 for ietf-calendar-bks; Sat, 29 Apr 2000 23:55:09 -0700 (PDT) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA15828 for ; Sat, 29 Apr 2000 23:55:07 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA11204 for ietf-calendar@imc.org; Sun, 30 Apr 2000 00:00:03 -0700 (PDT) Date: Sun, 30 Apr 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200004300700.AAA11204@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM ? Y ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com