From owner-ietf-calendar@mail.imc.org Tue Aug 1 14:13: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 OAA15565 for ; Tue, 1 Aug 2000 14:13:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12868 for ietf-calendar-bks; Tue, 1 Aug 2000 10:42:52 -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 KAA12864 for ; Tue, 1 Aug 2000 10:42:50 -0700 (PDT) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA27665; Tue, 1 Aug 00 13:46:16 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 NAA02186 for ; Tue, 1 Aug 2000 13:40:16 -0400 (EDT) Received: from [147.73.135.28] (wireless-135-28.ietf.marconi.com [147.73.135.28]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id NAA28204 for ; Tue, 1 Aug 2000 13:40:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: Date: Tue, 1 Aug 2000 13:37:20 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: FYI: Implementor's Guide URL & possible name change Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1) For some reason, this draft isn't available via the drafts search page, but is directly via: http://www.ietf.org/internet-drafts/draft-ietf-calsch-imp-guide-01.txt 2) There has been some sentiment to changing the draft name, to better reflect the content and intent, to: "A Guide to Internet Calendaring Standards" Comments welcome. -Bob From owner-ietf-calendar@mail.imc.org Tue Aug 1 14:43:46 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 OAA19462 for ; Tue, 1 Aug 2000 14:43:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13737 for ietf-calendar-bks; Tue, 1 Aug 2000 11:23:27 -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 LAA13733 for ; Tue, 1 Aug 2000 11:23:26 -0700 (PDT) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: iRIP draft - not resubmitting X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Message-ID: Date: Tue, 1 Aug 2000 14:26:56 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 08/01/2000 02:26:58 PM, Serialize complete at 08/01/2000 02:26:58 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006509BA8525692E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006509BA8525692E_= Content-Type: text/plain; charset="us-ascii" WE are not going to resubmit the expired iRIP draft. Anyone opposed to that idea, please post now. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 006509BA8525692E_= Content-Type: text/html; charset="us-ascii"
WE are not going to resubmit the expired iRIP draft.  Anyone opposed to that idea, please post now.

___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 006509BA8525692E_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 1 15:44: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 PAA26422 for ; Tue, 1 Aug 2000 15:44:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15031 for ietf-calendar-bks; Tue, 1 Aug 2000 12:07:57 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15024 for ; Tue, 1 Aug 2000 12:07:51 -0700 (PDT) Received: from grand-central-station.MIT.EDU (GRAND-CENTRAL-STATION.MIT.EDU [18.69.0.34]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA03328 for ; Tue, 1 Aug 2000 15:11:23 -0400 (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 PAA28610 for ; Tue, 1 Aug 2000 15:11:23 -0400 (EDT) Received: from [147.73.135.28] (wireless-135-28.ietf.marconi.com [147.73.135.28]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA26070 for ; Tue, 1 Aug 2000 15:11:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: Date: Tue, 1 Aug 2000 15:08:35 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: iCalendar objects wanted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: During a discussion of planning for the next CalConnect (with a November target), it was suggested that it would be useful to assemble a collection of good example iCal objects, illustrating as wide a range of operations as possible, to facilitate testing. The idea is that we have a shared repository of agreed-to-be-valid objects that can assist in interoperability testing. Both the crafting and subsequent testing of these objects would likely be illustrative. To that end, if you have objects you are using in test suites, or ones you can craft to illustrate a particular part of the grammar, please send them to the list. Pat and I will collect these and make them available in some easy to find place, so that people can begin to test their implementations. Obviously, November is still a ways off, but starting soon will allow us to go through the "we all agree these objects are valid iCalendar" process on the mailing list.. -Bob From owner-ietf-calendar@mail.imc.org Tue Aug 1 16:01: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 QAA28808 for ; Tue, 1 Aug 2000 16:01:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15697 for ietf-calendar-bks; Tue, 1 Aug 2000 12:39:19 -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 MAA15693 for ; Tue, 1 Aug 2000 12:39:18 -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 PAA02076; Tue, 1 Aug 2000 15:42:24 -0400 Received: by apollo.CST.CA with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 15:42:24 -0400 Message-ID: <0E0B2A774561D411845A00104B6D1D8F189B0B@apollo.CST.CA> To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: RE: iRIP draft - not resubmitting Date: Tue, 1 Aug 2000 15:42:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFBF0.9D449F8A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFFBF0.9D449F8A Content-Type: text/plain; charset="iso-8859-1" Could we have a short rational on the list about this decision? -----Original Message----- From: pregen@egenconsulting.com [mailto:pregen@egenconsulting.com] Sent: Tuesday, August 01, 2000 2:27 PM To: ietf-calendar@imc.org Subject: iRIP draft - not resubmitting WE are not going to resubmit the expired iRIP draft. Anyone opposed to that idea, please post now. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 ------_=_NextPart_001_01BFFBF0.9D449F8A Content-Type: text/html; charset="iso-8859-1"
Could we have a short rational on the list about this decision?
-----Original Message-----
From: pregen@egenconsulting.com [mailto:pregen@egenconsulting.com]
Sent: Tuesday, August 01, 2000 2:27 PM
To: ietf-calendar@imc.org
Subject: iRIP draft - not resubmitting


WE are not going to resubmit the expired iRIP draft.  Anyone opposed to that idea, please post now.

___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
------_=_NextPart_001_01BFFBF0.9D449F8A-- From owner-ietf-calendar@mail.imc.org Tue Aug 1 16:16: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 QAA00664 for ; Tue, 1 Aug 2000 16:16:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16023 for ietf-calendar-bks; Tue, 1 Aug 2000 12:56:53 -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 MAA16019 for ; Tue, 1 Aug 2000 12:56:50 -0700 (PDT) From: csatir@meetingmaker.com Received: by lnsmtp.on.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 8525692E.006E2D84 ; Tue, 1 Aug 2000 16:03:26 -0400 X-Lotus-FromDomain: ON TECHNOLOGY To: ietf-calendar@imc.org cc: pregen@egenconsulting.com Message-ID: <8525692E.006E2D58.00@lnsmtp.on.com> Date: Tue, 1 Aug 2000 15:51:56 -0400 Subject: RE: iRIP and CAP 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: I think we should renew iRIP as well. I agree, we may want to include iRIP functionality in CAP andrec@cst.ca on 07/18/2000 12:34:20 PM To: francis@ecal.com, ietf-calendar@imc.org cc: (bcc: Cengiz Satir/ON Technology) Subject: RE: iRIP and CAP I think we should renew iRIP. At a minumum, it contains good information should we want to include iRIP style functionality in CAP. -----Original Message----- From: John Stracke [mailto:francis@ecal.com] Sent: Tuesday, July 18, 2000 12:05 PM To: ietf-calendar@imc.org Subject: Re: iRIP and CAP Bruce_Kahn@iris.com wrote: > So it sounds like 1 vote to let iRIP expire. Or did I misread > your meaning? Mmm...I would actually prefer to see iRIP exist; I think real-time iTIP has value. But, if we can't do iRIP, then we should do the subset. Hmm. OK, so Bruce and I want to finish iRIP. I'm willing to work on it; Bruce, are you? Does anybody have any objections to seeing iRIP completed and standardized? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Solipsists have all the fun. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 1 16:44: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 QAA03921 for ; Tue, 1 Aug 2000 16:44:18 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA16327 for ietf-calendar-bks; Tue, 1 Aug 2000 13:18:00 -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 NAA16323 for ; Tue, 1 Aug 2000 13:17:58 -0700 (PDT) From: pregen@egenconsulting.com To: csatir@meetingmaker.com Cc: ietf-calendar@imc.org Subject: RE: iRIP and CAP X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Message-ID: Date: Tue, 1 Aug 2000 16:21:29 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 08/01/2000 04:21:31 PM, Serialize complete at 08/01/2000 04:21:31 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006F88928525692E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F88928525692E_= Content-Type: text/plain; charset="us-ascii" Ok. That's what I needed to hear. I had only heard a couple of "Keep" the draft - and more "let it go away." One group says that most if not all the iRIP functionality is in CAP - therefore we don't need iRIP. The pieces that are not there should be in a "short doc" and John Stracke has volunteered to work on such a document. I can not speak for him - but watch for something soon. However, I have no particular interest either way. I have no problem resubmitting the draft if there is a strong concensus to do so. No problem at all. We just need to make sure we have editors assigned - resubmitting means new draft number, etc. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 csatir@meetingmaker.com 08/01/00 03:51 PM To: ietf-calendar@imc.org cc: pregen@egenconsulting.com Subject: RE: iRIP and CAP I think we should renew iRIP as well. I agree, we may want to include iRIP functionality in CAP andrec@cst.ca on 07/18/2000 12:34:20 PM To: francis@ecal.com, ietf-calendar@imc.org cc: (bcc: Cengiz Satir/ON Technology) Subject: RE: iRIP and CAP I think we should renew iRIP. At a minumum, it contains good information should we want to include iRIP style functionality in CAP. -----Original Message----- From: John Stracke [mailto:francis@ecal.com] Sent: Tuesday, July 18, 2000 12:05 PM To: ietf-calendar@imc.org Subject: Re: iRIP and CAP Bruce_Kahn@iris.com wrote: > So it sounds like 1 vote to let iRIP expire. Or did I misread > your meaning? Mmm...I would actually prefer to see iRIP exist; I think real-time iTIP has value. But, if we can't do iRIP, then we should do the subset. Hmm. OK, so Bruce and I want to finish iRIP. I'm willing to work on it; Bruce, are you? Does anybody have any objections to seeing iRIP completed and standardized? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Solipsists have all the fun. | |francis@ecal.com| | \==============================================================/ --=_alternative 006F88928525692E_= Content-Type: text/html; charset="us-ascii"
Ok. That's what I needed to hear.  I had only heard a couple of "Keep" the draft - and more "let it go away."  One group says that most if not all the iRIP functionality is in CAP - therefore we don't need iRIP.  The pieces that are not there should be in a "short doc" and John Stracke has volunteered to work on such a document.  I can not speak for him - but watch for something soon.

However, I have no particular interest either way. I have no problem resubmitting the draft if there is a strong concensus to do so.  No problem at all.  We just need to make sure we have editors assigned - resubmitting means new draft number, etc.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


csatir@meetingmaker.com

08/01/00 03:51 PM

       
        To:        ietf-calendar@imc.org
        cc:        pregen@egenconsulting.com
        Subject:        RE: iRIP and CAP




I think we should renew iRIP as well.  I agree, we may want to include iRIP
functionality in CAP







andrec@cst.ca on 07/18/2000 12:34:20 PM
                                                                         
                                                                         
                                                                         


                                                             
                                                             
                                                             
To:      francis@ecal.com, ietf-calendar@imc.org            
                                                             
cc:      (bcc: Cengiz Satir/ON Technology)                  
                                                             
                                                             
                                                             
Subject: RE: iRIP and CAP                                    
                                                             









I think we should renew iRIP. At a minumum, it contains
good information should we want to include iRIP style
functionality in CAP.


-----Original Message-----
From: John Stracke [mailto:francis@ecal.com]
Sent: Tuesday, July 18, 2000 12:05 PM
To: ietf-calendar@imc.org
Subject: Re: iRIP and CAP


Bruce_Kahn@iris.com wrote:

> So it sounds like 1 vote to let iRIP expire.  Or did I misread
> your meaning?

Mmm...I would actually prefer to see iRIP exist; I think
real-time iTIP has value.  But, if we can't do iRIP, then we
should do the subset.

Hmm.  OK, so Bruce and I want to finish iRIP.  I'm willing to
work on it; Bruce, are you? Does anybody have any objections to
seeing iRIP completed and standardized?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Solipsists have all the fun.                 |
|francis@ecal.com|                                             |
\==============================================================/

--=_alternative 006F88928525692E_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 1 22:41: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 WAA14597 for ; Tue, 1 Aug 2000 22:41:19 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA00847 for ietf-calendar-bks; Tue, 1 Aug 2000 19:20:00 -0700 (PDT) Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA00839 for ; Tue, 1 Aug 2000 19:19:59 -0700 (PDT) Received: from xxx.com (wired-128-106.ietf.marconi.com [147.73.128.106]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id WAA05193; Tue, 1 Aug 2000 22:27:31 -0400 (EDT) Message-ID: <39878611.89CAE519@xxx.com> Date: Tue, 01 Aug 2000 22:23:13 -0400 From: xxx Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: csatir@meetingmaker.com, ietf-calendar@imc.org Subject: Re: iRIP and CAP References: <8525692E.006E2D58.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 csatir@meetingmaker.com wrote: > I think we should renew iRIP as well. I agree, we may want to include iRIP > functionality in CAP iRIP functionallity is already in CAP. Do you know of something that's not in CAP? - Doug Royer (On IETF terminal room computer) From owner-ietf-calendar@mail.imc.org Wed Aug 2 09:43: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 JAA15732 for ; Wed, 2 Aug 2000 09:43:09 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA05921 for ietf-calendar-bks; Wed, 2 Aug 2000 06:16:26 -0700 (PDT) Received: from localhost.localdomain (wired-129-175.ietf.marconi.com [147.73.129.175]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05916 for ; Wed, 2 Aug 2000 06:16:24 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id JAA06647 for ; Wed, 2 Aug 2000 09:21:13 -0400 Message-ID: <39882047.579DACEA@ecal.com> Date: Wed, 02 Aug 2000 09:21:11 -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: iRIP and CAP References: Content-Type: multipart/mixed; boundary="------------DD945ED324D6FAE604CC8C56" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DD945ED324D6FAE604CC8C56 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > Ok. That's what I needed to hear. I had only heard a couple of > "Keep" the draft - and more "let it go away." One group says > that most if not all the iRIP functionality is in CAP - > therefore we don't need iRIP. The pieces that are not there > should be in a "short doc" and John Stracke has volunteered to > work on such a document. I can not speak for him - but watch > for something soon. OK, so here's the story: CAP already contains iTIP functionality. All commands and responses are embedded in iCalendars; while there are some CAP-specific commands (e.g., QUERY), the full set of iTIP is also available. The problem, though, is that, for interdomain scheduling, you don't necessarily want to expose your CAP server--it would be like having to expose your IMAP server in order to accept SMTP traffic. (Sure, some people do expose their IMAP or POP servers, so their users can get in--but they have the choice; and they have the ability to apply different security rules.) An iRIP server would be more limited; it would only accept iTIP. So what I did was to write up a profile for CAP, a subset which supports only iTIP functionality. This way, we don't have to maintain two full-sized protocols; moreover, a site can smoothly transition their public server between full CAP and iTIP only. I didn't call the subset iRIP, because of the possibility for confusion. Instead, I called it CRISP: CAP Real-time iTIP-based Scheduling Profile. As it turned out, the profile was fairly easy; about all I had to do was specify the capability set that makes a CAP server a CRISP server. (I also had to define a new capability value of NONE for a couple of mandatory features; but the CAP editors have said they don't object to adding those to the CAP spec, if the WG agrees.) The I-D is attached. The version number is -xx because I can't submit it for publication until after the meeting, so we might have to change it before the the -00 version. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |No matter how tempting the prospect of unlimited| |francis@ecal.com|power, I will not consume any energy field | | |bigger than my head. | \=================================================================/ --------------DD945ED324D6FAE604CC8C56 Content-Type: text/plain; charset=us-ascii; name="draft-stracke-calsch-crisp-xx.txt" Content-Disposition: inline; filename="draft-stracke-calsch-crisp-xx.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force J. Stracke INTERNET DRAFT eCal draft-stracke-calsch-crisp-xx.txt August 2000 Expires: February 2001 CAP Realtime iTIP-based Scheduling Profile (CRISP) 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document and related documents are discussed on the calsch mail- ing list. 2. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 3. Abstract This document sets forth a restricted profile of [CAP], one which supports no operations beyond the scheduling functionality of [iTIP]. The motivation is to permit use of CAP's real-time iTIP functionality without exposing the calendar access functionality (which may require stricter security controls than iTIP). Stracke [Page 1] CRISP May 2000 4. Introduction [iTIP] defines a scheduling protocol based on exchanging specially formatted [iCalendar] messages. iTIP is defined to be independent of transport protocol. At present, there is one standard binding of iTIP to a transport protocol, [iMIP], which carries iTIP messages in email. This is a useful base level capability (email can reach vir- tually any user on the Net), but can involve considerable latencies. A real-time binding for iTIP would be useful; it would permit appli- cation developers to give users better feedback on the progress of the iTIP operations. Since CAP includes full iTIP functionality, one option would be to permit full access to CAP; to schedule an event with a remote user, one would then make a CAP connection to their CS. The problem is that such a connection may be considered a security risk in some organizations; even though the CS has ACLs to prevent the client from performing non-iTIP operations, it would be better if client simply could not attempt such operations. (It's as if mail administrators were told that an SMTP server outside the firewall had to include IMAP functionality as well.) Thus, this document defines a profile of CAP, a subset which does not support non-iTIP operations. 5. Profile Definition A CRISP server is a CAP server with the following capabilities: * ITIPVERSION=1.0 * CAPVERSION=1.0 * CAR=NONE * QUERYLEVEL=NONE In addition, various AUTH capabilities are expected. Other capabili- ties which apply to iTIP operations may be specified; e.g., MAXDATE and MAXICALOBJECTSIZE. Note that NONE is not a legal value for CAR or QUERYLEVEL in the cur- rent draft of CAP. This will have to be resolved. A CRISP server MUST NOT accept any iCalendar component which is not a valid iTIP component. 6. Firewall Application Clearly, it would be undesirable for an organization with a CAP server to have a CRISP server implemented completely separately, but Stracke [Page 2] CRISP May 2000 having access to the same database. Such duplication would increase development costs, maintenance costs, and security exposure. On the other hand, it would be possible to build a CRISP server which han- dles all operations by proxying them to the CAP server. Such a proxy could be placed in the "no-man's-land" common in firewalls; the fire- wall would permit CAP connections from the outside to the proxy, and from the proxy to the internal CAP server. The proxy would review all incoming iCalendar components and validate that they were legiti- mate iTIP operations; no non-iTIP components would be forwarded to the CAP server. Similarly, if necessary, the proxy might censor the iTIP replies coming from the CAP server. 7. Security Considerations The protocol defined in this document is a subset of [CAP], and accordingly inherits all of CAP's security analysis. However, new analysis does need to be done for the subset, especially since the whole point of the subset is to address security concerns. 8. Author's Address: John Stracke Chief Scientist eCal Corp. Email: francis@ecal.com 9. References [iTIP] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- Independent Interoperability Protocol (iTIP)", RFC 2446, November 1998 [iMIP] Dawson, Mansour, Silverberg, "iCalendar Message-Based Interop- erability Protocol (iMIP)", RFC 2445, November 1998 [CAP] Mansour, Dawson, Royer, Taler, Hill, "Calendar Access Protocol (CAP)", draft-ietf-calsch-cap-03.txt, July 2000. Work in progress. [iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998 Stracke [Page 3] --------------DD945ED324D6FAE604CC8C56-- From owner-ietf-calendar@mail.imc.org Wed Aug 2 10:54: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 KAA09619 for ; Wed, 2 Aug 2000 10:54:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA09952 for ietf-calendar-bks; Wed, 2 Aug 2000 07:35:47 -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 HAA09948 for ; Wed, 2 Aug 2000 07:35:45 -0700 (PDT) From: pregen@egenconsulting.com To: csatir@meetingmaker.com Cc: ietf-calendar@imc.org Subject: RE: iRIP and CAP X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Message-ID: Date: Wed, 2 Aug 2000 10:39:19 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 08/02/2000 10:39:22 AM, Serialize complete at 08/02/2000 10:39:22 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00502F648525692F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00502F648525692F_= Content-Type: text/plain; charset="us-ascii" Have you had an opportunity to read John Stracke's most recent post. Do you think it makes you feel more comfortable with us not resubmitting iRIP. John's document makes it more of an informational document. This way we are not tasked with trying to keep up with mulitple drafts - i.e. when changes are made, we must get all editors to complete the changes, etc. I am not saying we don't want to have multiple drafts because of work efforts - I'm saying it would be better not to duplicate text/functionality that may well live in a document that has "evolved" past the original set of text. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 00502F648525692F_= Content-Type: text/html; charset="us-ascii"
Have you had an opportunity to read John Stracke's most recent post.  Do you think it makes you feel more comfortable with us not resubmitting iRIP.  John's document makes it more of an informational document.  This way we are not tasked with trying to keep up with mulitple drafts - i.e. when changes are made, we must get all editors to complete the changes, etc.  I am not saying we don't want to have multiple drafts because of work efforts - I'm saying it would be better not to duplicate text/functionality that may well live in a document that has "evolved" past the original set of text.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 00502F648525692F_=-- From owner-ietf-calendar@mail.imc.org Wed Aug 2 11:01:23 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 LAA12018 for ; Wed, 2 Aug 2000 11:01:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10093 for ietf-calendar-bks; Wed, 2 Aug 2000 07:40:39 -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 HAA10085 for ; Wed, 2 Aug 2000 07:40:38 -0700 (PDT) From: pregen@egenconsulting.com To: Bob Mahoney Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: FYI: Implementor's Guide URL & possible name change X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Message-ID: Date: Wed, 2 Aug 2000 10:44:09 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 08/02/2000 10:44:14 AM, Serialize complete at 08/02/2000 10:44:14 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0050A3F78525692F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0050A3F78525692F_= Content-Type: text/plain; charset="us-ascii" I like the new name change ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0050A3F78525692F_= Content-Type: text/html; charset="us-ascii"
I like the new name change
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0050A3F78525692F_=-- From owner-ietf-calendar@mail.imc.org Wed Aug 2 11:04: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 LAA13186 for ; Wed, 2 Aug 2000 11:04:08 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA10256 for ietf-calendar-bks; Wed, 2 Aug 2000 07:44:17 -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 HAA10251 for ; Wed, 2 Aug 2000 07:44:15 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id HAA13319 for ietf-calendar@imc.org; Wed, 2 Aug 2000 07:47:55 -0700 (PDT) Date: Wed, 2 Aug 2000 07:47:55 -0700 (PDT) From: Doug Royer Message-Id: <200008021447.HAA13319@royer.com> To: ietf-calendar@imc.org Subject: Editor NOTES (At end) 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 draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) 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! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ 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 Tuesday discussion: Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Wed Aug 2 12:25:16 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 MAA13111 for ; Wed, 2 Aug 2000 12:25:15 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA17325 for ietf-calendar-bks; Wed, 2 Aug 2000 08:59:21 -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 IAA17321 for ; Wed, 2 Aug 2000 08:59:20 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e72FvIj24175 for ; Wed, 2 Aug 2000 08:57:18 -0700 (PDT) Received: from netscape.com ([205.217.228.207]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id FYO9W700.AUB; Wed, 2 Aug 2000 09:02:31 -0700 Message-ID: <39884667.96116957@netscape.com> Date: Wed, 02 Aug 2000 09:03:51 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP Restriction Table - initial proposal Content-Type: multipart/mixed; boundary="------------00B04DFA3B465BE7DDA830DA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------00B04DFA3B465BE7DDA830DA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, Here's a first whack at a CAP restriction table. We did the example for the CREATE command. It's generated two day's worth of discussion here at the ietf meeting. Have a look at it and send your comments. Once we get it pretty much as we want it for CREATE, we'll clone it and add it for the rest of the commands. -Steve -------------------------------------------- CAP Restriction Tables This is the proposed format for CAP restriction tables. Their purpose is to define the composition of commands sent to a CAP server and the composition of the command replies. While the tables list every property, it is not meant to define the meaning of the property. It is meant to define presence or absence of a property. There will be a RESPONSE-STATUS for each VCALENDAR and/or component created, modified, deleted, or requested. The number of response status values returned MUST be equal to the number of TARGETS times the number of objects in the command. The responses MUST be ordered first by TARGET then by the order of the objects as supplied in the command. Client Restriction Table for the Create command Component/Property Presence Comment ------------------- -------- -------------------------------------- VCALENDAR 1+ CMDID 0 or 1 If CMDID is not supplied, then there must not be pending replies to previous command. VERSION 1 MUST be 2.0 VCOMMAND METHOD 1 MUST be CREATE. TARGET 1+ VCALENDAR 0+ CALMASTER 1 NAME 0 or 1 The user friendly name, localizable. OWNER 1+ RELCALID 1 This is only present when creating a new calendar. This is the name of the calid to create. TZID 0 or 1 VCAR 0+ CARID 0 or 1 A reference name DENY 0+ permissions denied. Note, there must be at least one GRANT or DENY within the VCAR. GRANT 0+ permissions granted. Note, there must be at least one GRANT or DENY within the VCAR. VQUERY 0+ EXPAND 0 or 1 Expand recurrences or not MAXRESULTS 0 or 1 Limit the solution set to no more than this many enries. MAXSIZE 0 or 1 Maximum number of octets to transfer QUERYNAME 1 Name by which this query is referenced QUERY 1 The query VEVENT 0+ ATTENDEE 0+ SEQUENCE 0 or 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTEND 0 or 1 if present DURATION MUST NOT be present DTSTAMP 1 DTSTART 1 DURATION 0 or 1 if present DTEND MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ORGANIZER 1 PRIORITY 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUSSSSS 0+ RESOURCES 0 or 1 This property MAY contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED TRANSP 0 or 1 URL 0 or 1 X-PROPERTY 0+ [IANA-PROP] 0+ any IANA registered property VTODO 0+ ATTENDEE 0+ SEQUENCE 0 or 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null. UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTSTAMP 1 DTSTART 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ORGANIZER 1 PRIORITY 1 PERCENT-COMPLEEEEETE 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUSSSSS 0 RESOURCES 0 or 1 This property may contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- PROCESS/CANCELLED URL 0 or 1 X-PROPERTY 0+ [IANA-PROP] 0+ any IANA registered property VJOURNAL 0+ METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ATTENDEE 0 DESCRIPTION 1 Can be null. DTSTAMP 1 DTSTART 1 ORGANIZER 1 UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property MAY contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 EXDATE 0+ EXRULE 0+ LAST-MODIFIED 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ RRULE 0+ SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. MUST be present if non-zero. MAY be present if zero. STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED SUMMARY 0 or 1 Can be null URL 0 or 1 X-PROPERTY 0+ VALARM 0+ ACTION 1 ALARMID 0 or 1 MUST be 1 if multiple VALARMs are present in same component. ATTACH 0+ DESCRIPTION 0 or 1 DURATION 0 or 1 if present REPEAT MUST be present REPEAT 0 or 1 if present DURATION MUST be present SUMMARY 0 or 1 TRIGGER 1 X-PROPERTY 0+ VFREEBUSY 0 VTIMEZONE 0+ MUST be present if any date/time refers to timezone DAYLIGHT 0+ MUST be one or more of either STANDARD or DAYLIGHT COMMENT 0 or 1 DTSTART 1 MUST be local time format RDATE 0+ if present RRULE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present TZNAME 0 or 1 TZOFFSET 1 TZOFFSETFROM 1 TZOFFSETTO 1 X-PROPERTY 0+ LAST-MODIFIED 0 or 1 STANDARD 0+ MUST be one or more of either STANDARD or DAYLIGHT COMMENT 0 or 1 DTSTART 1 MUST be local time format RDATE 0+ if present RRULE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present TZNAME 0 or 1 TZOFFSETFROM 1 TZOFFSETTO 1 X-PROPERTY 0+ TZID 1 TZURL 0 or 1 X-PROPERTY 0+ Server Restriction Table for the CREATE command Component/Property Presence Comment ------------------- -------- -------------------------------------- VCALENDAR 1+ TARGET 1 VERSION 1 MUST be 2.0 CMDID 0 or 1 MUST be returned if the request contained a CMDID VALARM 0 RESPONSE-STATUS 0 if not creating a calendar 1+ if creating a calendar VCAR 0+ RESPONSE-STATUS 1+ * 0 No other VCAR properties are present VCOMMAND 0 VEVENT 0+ RESPONSE-STATUS 1+ * 0 No other VEVENT properties are present VFREEBUSY 0+ RESPONSE-STATUS 1+ * 0 No other VFREEBUSY properties are present VJOURNAL 0+ RESPONSE-STATUS 1+ * 0 No other VJOURNAL properties are present VQUERY 0+ RESPONSE-STATUS 1+ * 0 No other VQUERY properties are present VTODO 0+ RESPONSE-STATUS 1+ * 0 No other VTODO properties are present Issues: freebusy - a cap server should dynamically calculate freebusy information we recommend that you cannot create, modify, or delete freebusy composers --------------00B04DFA3B465BE7DDA830DA 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:TRUE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------00B04DFA3B465BE7DDA830DA-- From owner-ietf-calendar@mail.imc.org Wed Aug 2 14:53: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 OAA00479 for ; Wed, 2 Aug 2000 14:53:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20358 for ietf-calendar-bks; Wed, 2 Aug 2000 11:22:49 -0700 (PDT) Received: from localhost.localdomain (wired-129-58.ietf.marconi.com [147.73.129.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20354 for ; Wed, 2 Aug 2000 11:22:48 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id OAA08108 for ; Wed, 2 Aug 2000 14:27:38 -0400 Message-ID: <3988681A.407CE5CC@ecal.com> Date: Wed, 02 Aug 2000 14:27:38 -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: iRIP and CAP 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: > Have you had an opportunity to read John Stracke's most recent post. Do you think it makes you feel more comfortable with us not resubmitting iRIP. John's document makes it more of an informational document. I wouldn't really consider it an Informational; it'd probably have to be standards track, because it specifies a way to interoperate. But it would be a fairly small delta over the CAP RFC. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I'm on a Mission From God to Save The World from| |francis@ecal.com|megalomania! | \=================================================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 5 23:02:41 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 XAA17776 for ; Sat, 5 Aug 2000 23:02:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA17032 for ietf-calendar-bks; Sat, 5 Aug 2000 19:38:33 -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 TAA17027 for ; Sat, 5 Aug 2000 19:38:32 -0700 (PDT) Received: (from sman@localhost) by royer.com (8.9.1/8.9.1) id TAA19687 for ietf-calendar@imc.org; Sat, 5 Aug 2000 19:42:21 -0700 (PDT) Date: Sat, 5 Aug 2000 19:42:21 -0700 (PDT) From: Steve Mansour Message-Id: <200008060242.TAA19687@royer.com> To: ietf-calendar@imc.org Subject: CAP draft update Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAP draft files have been updated on: ftp://royer.com/pub/CALSCH The current cap drafit is: ftp://royer.com/pub/CALSCH/cap.txt.gz Nroff and other source files including cap.txt: ftp://royer.com/pub/CALSCH/sources.tar.gz From owner-ietf-calendar@mail.imc.org Sun Aug 6 03:20: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 DAA02102 for ; Sun, 6 Aug 2000 03:20:31 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA27889 for ietf-calendar-bks; Sat, 5 Aug 2000 23:56:05 -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 XAA27885 for ; Sat, 5 Aug 2000 23:56:03 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA23180 for ietf-calendar@imc.org; Sun, 6 Aug 2000 00:00:03 -0700 (PDT) Date: Sun, 6 Aug 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200008060700.AAA23180@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 draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) 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! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ 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 Tuesday discussion: DONE Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. DONE Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). DONE Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) DONE Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. DONE Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text DONE Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 DONE Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. DONE Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Mon Aug 7 01:56: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 BAA27284 for ; Mon, 7 Aug 2000 01:56:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA08813 for ietf-calendar-bks; Sun, 6 Aug 2000 22:27:34 -0700 (PDT) Received: from agony.busboom.org (IDENT:root@24-25-198-225.san.rr.com [24.25.198.225]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA08808 for ; Sun, 6 Aug 2000 22:27:32 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id WAA30155; Sun, 6 Aug 2000 22:31:32 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Sun, 6 Aug 2000 22:31:30 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Bob Mahoney cc: ietf-calendar@imc.org Subject: Re: iCalendar objects wanted In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 1 Aug 2000, Bob Mahoney wrote: > To that end, if you have objects you are using in test suites, or > ones you can craft to illustrate a particular part of the grammar, > please send them to the list. Pat and I will collect these and make > them available in some easy to find place, so that people can begin > to test their implementations. I extracted the components from RFC2445 and 2446 and put them online as 2445.ics and 2446.ics at ftp://ftp.softwarestudio.org/pub/studio2/. These are not exact copies of the components in the RFCs -- I fixed numerous errors, but everything else is the same. There are many other example components, including the RECUR specifications from RFC2445, in the latest libical distribution. Libical now implements nearly all of RFC2445 and RFC2446. See http://softwarestudio.org/libical/index.html for more information. eric. From owner-ietf-calendar@mail.imc.org Tue Aug 8 19:16: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 TAA21188 for ; Tue, 8 Aug 2000 19:16:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18022 for ietf-calendar-bks; Tue, 8 Aug 2000 15:44:38 -0700 (PDT) Received: from agony.busboom.org (IDENT:root@24-25-201-226.san.rr.com [24.25.201.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18018 for ; Tue, 8 Aug 2000 15:44:36 -0700 (PDT) From: eric@softwarestudio.org Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id PAA32677; Tue, 8 Aug 2000 15:48:43 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Tue, 8 Aug 2000 15:48:42 -0700 (PDT) X-Sender: eric@agony.busboom.org To: sman@netscape.com, Doug@Royer.com cc: ietf-calendar@imc.org Subject: Questions about CAP draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAP draft seems to be progressing nicely, and I have a few questions/requests regarding the latest version. 1) Why is the METHOD property in the parent container of a VEVENT in RFC2446, but in the VEVENT in CAP? The METHOD is easy enough to move when you store a component, but then you have to know where you got a component from to know where to look for the method; it will be in a different place in a component received in a CUA from iMIP than for one received via CAP. Can we have the METHOD property in the same place in both? I'd suspect that this is a planned change for the iCalendar-2 draft, but I did not see it in the list. 2) The current example of the AUTHENTICATE command in section 7.1.3 of the latest CAP draft shows the capabilities being returned in a VCALENDAR container, but the capabilities are not in RFC2445 format == They have "=" separating the name from the value. Furthermore, they are in a different format than if they were returned from the CAPABILITIES command -- the CAPABILITIES command does not contain them in a VCALENDAR. Can we have these two forms be the same, and have them in RFC2445 format -- that is, make all of the capabilities be properties? I really don't want to have a different parser to handle these when they are nearly identical to properties except for the "=" character. thanks, eric. From owner-ietf-calendar@mail.imc.org Tue Aug 8 19:48: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 TAA06414 for ; Tue, 8 Aug 2000 19:48:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18749 for ietf-calendar-bks; Tue, 8 Aug 2000 16:25:47 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18745 for ; Tue, 8 Aug 2000 16:25:46 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Tue, 8 Aug 2000 16:29:40 -0700 Message-ID: <399097E3.A3853F09@home.royer.com> Date: Tue, 08 Aug 2000 16:29:39 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: eric@softwarestudio.org, ietf-calendar@imc.org Subject: Re: Questions about CAP draft 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 eric@softwarestudio.org wrote: > > The CAP draft seems to be progressing nicely, and I have a few > questions/requests regarding the latest version. > > 1) Why is the METHOD property in the parent container of a VEVENT in > RFC2446, but in the VEVENT in CAP? The METHOD is easy enough to move > when you store a component, but then you have to know where you got a > component from to know where to look for the method; it will be in a > different place in a component received in a CUA from iMIP than for one > received via CAP. Can we have the METHOD property in the same place in > both? I think you are referring to the schema or query? In the store you are going to have to know the difference between iTIP data that has not been processed by the CUA and data that has been processed by the CUA. There was debate in Montreal last year about storing all unprocessed iTIP data in a separate table, then as the CUA would process the data; move it to the store, delete it, and respond with any required responses. The other model was store everything in one schema with a tag that indicated the status of the data. We debated what this tag should be, then concluded that it was identical to iTIP METHOD + one tag for "done". We call the "done" tag booked or METHOD:CREATE as it is identical to a CUA depositing a non-iTIP'd component directly in the CS. So on the wire iTIP/iMIP VEVENT does not have a method. And even a CUA that does a VQUERY to get a VEVENT does not see the METHOD inside the VEVENT. Or - we have a typo bug in the spec ? :-) > I'd suspect that this is a planned change for the iCalendar-2 draft, > but I did not see it in the list. No. It is not a change. If it's not the schema or VQUERY, it may be a spec bug. > 2) The current example of the AUTHENTICATE command in section 7.1.3 of > the > latest CAP draft shows the capabilities being returned in a > VCALENDAR container, but the capabilities are not in RFC2445 > format == They have "=" separating the name from the value. > Furthermore, they are in a different format than if they were > returned from the CAPABILITIES command -- the CAPABILITIES > command does not contain them in a VCALENDAR. > Can we have these two forms be the same, and have them in RFC2445 format > -- that is, make all of the capabilities be properties? I really don't > want to have a different parser to handle these when they are nearly > identical to properties except for the "=" character. > Excellent catch (= vs :) Cut/Paste too many hours on the keyboard error. I also think they should use ":" and the values returned by the CAPABILITIES command should be in a VCALENDAR (with ":") If there are no objections - I'll make that change in the doc. From owner-ietf-calendar@mail.imc.org Thu Aug 10 08:31: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 IAA18201 for ; Thu, 10 Aug 2000 08:31:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA08431 for ietf-calendar-bks; Thu, 10 Aug 2000 05:09:39 -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 FAA08426 for ; Thu, 10 Aug 2000 05:09:37 -0700 (PDT) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA17705; Thu, 10 Aug 00 08:09:05 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 IAA20469 for ; Thu, 10 Aug 2000 08:08:56 -0400 (EDT) Received: from [18.18.1.172] (airport.bobmah.com [216.254.65.43] (may be forged)) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id IAA21487 for ; Thu, 10 Aug 2000 08:08:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: Date: Thu, 10 Aug 2000 08:06:43 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In case anyone missed this morning's announcement- this is John's draft that came out of the CAP/iRIP discussion. -Bob >To: IETF-Announce:;@loki.ietf.org >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-stracke-calsch-crisp-00.txt >Date: Thu, 10 Aug 2000 06:51:44 -0400 >Sender: nsyracus@cnri.reston.va.us > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : CAP Realtime iTIP-based Scheduling Profile (CRISP) > Author(s) : J. Stracke > Filename : draft-stracke-calsch-crisp-00.txt > Pages : 3 > Date : 09-Aug-00 > >This document sets forth a restricted profile of [CAP], one which >supports no operations beyond the scheduling functionality of [iTIP]. >The motivation is to permit use of CAP's real-time iTIP functionality >without exposing the calendar access functionality (which may require >stricter security controls than iTIP). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-stracke-calsch-crisp-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-stracke-calsch-crisp-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-stracke-calsch-crisp-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > From owner-ietf-calendar@mail.imc.org Thu Aug 10 18:20: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 SAA15222 for ; Thu, 10 Aug 2000 18:20:29 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA16335 for ietf-calendar-bks; Thu, 10 Aug 2000 14:52:48 -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 OAA16331 for ; Thu, 10 Aug 2000 14:52:47 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7ALkBj25882 for ; Thu, 10 Aug 2000 14:46:11 -0700 (PDT) Received: from netscape.com ([192.18.125.171]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FZ3JE100.6OK; Thu, 10 Aug 2000 14:51:37 -0700 Message-ID: <39932418.CE1A2657@netscape.com> Date: Thu, 10 Aug 2000 14:52:24 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF , deweydev@netscape.com, Naveen Kachroo , Katia Hage , Bruce Kahn Subject: Updates to iTIP/iMIP RFCs Content-Type: multipart/mixed; boundary="------------39FAD938993DB4A2C915865B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------39FAD938993DB4A2C915865B Content-Type: multipart/alternative; boundary="------------A37E2011B17E0C42B6055FDD" --------------A37E2011B17E0C42B6055FDD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, I'm going to update the iTIP / iMIP RFCs based on some problems that people have reported over the last year or so. Below is the list of problems and proposed solutions. If you have any comments on the proposals, please reply. PLEASE respond to issue #2 and let us know which of the two proposals you like best. Also, if you are aware of any other issues, please let me know about them now and we should be able to get them into the revisions. -------------------------------- 1. Overloading iTIP REQUEST: Problem: Currently, the REQUEST method is used for invite, reschedule, update, confirm, reply to refresh. A reschedule and/or update are semantically different than a confirm or a reply to REFRESH. Proposal: Add a new method: CONFIRM. It would be used to (a) reply to a REFRESH and (b) notify participants of any changes to ATTENDEE or ORGANIZER. All other "reschedule" or "update" changes MUST use REQUEST method. 2. Identify sender of iTIP COUNTER: Problem: You can't identify which Attendee a COUNTER message came from because all of the Attendees will appear in the component. Proposal 1: Restrict the COUNTER message so that it can only specify the ORGANIZER and countering ATTENDEE. Note: You can still forward (party crashing, remember? :-) or delegate a REQUEST to change participants. However, only the ORGANIZER can remove a participant. The down side to this approach is that you can't change the Attendees. This removes functionality. The up side is that it requires no changes to iCalendar. Proposal 2: Add a new parameter to the ATTENDEE property: ATTCOUNTER. It can only be specified (a) when the component method is COUNTER and (b) for the one Attendee who issued the COUNTER. Note: The good news is that no functionality is lost -- you can suggest a different attendee list. The down side is that we have to update iCalendar with a new parameter. 3. Adding/deleting ATTENDEEs Problem: If the Organizer adds or deletes an ATTENDEE, do they really have to send the reschedule to all of the other ATTENDEEs? The iTIP specification is not clear on this point. Proposal: No, the Organizer can send the REQUEST w/the new ATTENDEE info to just the new ATTENDEE. It is up to the CUA. It is an implementation dependent issue if the SEQUENCE number needs to be incremented when you add/delete an ATTENDEE. iCalendar does not require an updated SEQUENCE number if a new ATTENDEE is added so this won't break iCalendar as it stands today. 4. Intolerant iMIP receivers. Problem: MIP specifies numerous MIME encapsulations for iCal/iTIP msgs. It doesn't require that an implementation MUST be able to receive each of them. This is leading to interop problems. Proposal: A conforming iMIP implementation MUST be able to receive each of the MIME encapsulations shown in the iMIP examples.; It does not have to GENERATE them, but it must be able to RECEIVE them. --------------A37E2011B17E0C42B6055FDD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Folks,

I'm going to update the iTIP / iMIP RFCs based on some problems that people have reported over the last year or so.  Below is the list of problems and proposed solutions.

If you have any comments on the proposals, please reply.  PLEASE respond to issue #2 and let us know which of the two proposals you like best.

Also, if you are aware of any other issues, please let me know about them now and we should be able to get them into the revisions.

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

1. Overloading iTIP REQUEST:

Problem: Currently, the REQUEST method is used for invite, reschedule, update, confirm, reply to refresh. A reschedule and/or update are semantically different than a confirm or a reply to REFRESH.

Proposal: Add a new method: CONFIRM. It would be used to (a) reply to a REFRESH and (b) notify participants of any changes to ATTENDEE or ORGANIZER.  All other "reschedule" or "update" changes MUST use REQUEST method.

2. Identify sender of iTIP COUNTER:
Problem: You can't identify which Attendee a COUNTER message came from because all of the Attendees will appear in the component.

Proposal 1:  Restrict the COUNTER message so that it can only specify the ORGANIZER and countering ATTENDEE.

Note: You can still forward (party crashing, remember? :-) or delegate a REQUEST to change participants. However, only the ORGANIZER can remove a participant.  The down side to this approach is that you can't change the Attendees. This removes functionality.  The up side is that it requires no changes to iCalendar.

Proposal 2: Add a new parameter to the ATTENDEE property:  ATTCOUNTER.  It can only be specified (a) when the component method is COUNTER and (b) for the one Attendee who issued the COUNTER.

Note: The good news is that no functionality is lost -- you can suggest a different attendee list.  The down side is that we have to update iCalendar with a new parameter.

3. Adding/deleting ATTENDEEs
Problem: If the Organizer adds or deletes an ATTENDEE, do they really have to send the reschedule to all of the other ATTENDEEs?  The iTIP specification is not clear on this point.

Proposal: No, the Organizer can send the REQUEST w/the new ATTENDEE info to just the new ATTENDEE.  It is up to the CUA.  It is an implementation dependent issue if the SEQUENCE number needs to be incremented when you add/delete an ATTENDEE.  iCalendar does not require an updated SEQUENCE number if a new ATTENDEE is added so this won't break iCalendar as it stands today.

4. Intolerant iMIP receivers.
Problem: MIP specifies numerous MIME encapsulations for iCal/iTIP msgs.  It doesn't require that an implementation MUST be able to receive each of them.  This is leading to interop problems.

Proposal: A conforming iMIP implementation MUST be able to receive each of the MIME encapsulations shown in the iMIP examples.;  It does not have to GENERATE them, but it must be able to RECEIVE them.

--------------A37E2011B17E0C42B6055FDD-- --------------39FAD938993DB4A2C915865B 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 tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------39FAD938993DB4A2C915865B-- From owner-ietf-calendar@mail.imc.org Fri Aug 11 01:02: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 BAA23148 for ; Fri, 11 Aug 2000 01:02:26 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA13964 for ietf-calendar-bks; Thu, 10 Aug 2000 21:47:35 -0700 (PDT) Received: from agony.busboom.org (IDENT:root@24-25-201-226.san.rr.com [24.25.201.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13960 for ; Thu, 10 Aug 2000 21:47:33 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id VAA07592; Thu, 10 Aug 2000 21:46:37 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 10 Aug 2000 21:46:36 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Steve Mansour cc: CalSched IETF , deweydev@netscape.com, Naveen Kachroo , Katia Hage , Bruce Kahn Subject: Re: Updates to iTIP/iMIP RFCs In-Reply-To: <39932418.CE1A2657@netscape.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 10 Aug 2000, Steve Mansour wrote: > Folks, > > Also, if you are aware of any other issues, please let me know about > them now and we should be able to get them into the revisions. Um, Recurrence rules? I send this mail to Doug Royer this morning, but I think it is worth posting to the list again. The problems with recurrence rules were summarized best by Damon Chaplin in http://www.imc.org/ietf-calendar/mail-archive/msg03656.html, reposted ( and edited) here: o The BYDAY modifier is ambiguous. In a YEARLY frequency with BYMONTH and/or BYWEEKNO set, does the BYDAY modifier apply to the year day, the month day, or the week day? o Should BYWEEKNO and BYMONTH be mutually exclusive? They make no sense together. (This would also avoid part of the previous problem.) o Is it possible to use BYMONTHDAY in a WEEKLY frequency, or BYYEARDAY in a MONTHLY or WEEKLY frequency? o BYSETPOS is limited to 366 values (or maybe 999 values if the comment doesn't count as part of the spec!), yet a complete expansion for every second in every day of the year would result in much larger sets. o The algorithm to calculate the first week in the year may be awkward, since some people/countries may be used to other numbering schemes. I proposed this text (in http://www.imc.org/ietf-calendar/mail-archive/msg03512.html )to solve some of these problems: -------------------- There are two types of BYxxx rules; date BYxxx rule parts that specify time periods equal to or longer than a day, and time BYxxx rule parts that specify the time within a day. The day BYxxx rule parts are : BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY. The time BYxxx rule parts are BYHOUR, BYMINUTE, and BYSECOND. BYSETPOS is neither a date rule part nor a time rule part. Not all date BYxxx rule parts can appear simultaneously in a single recurrence rule. Date BYxxx rule part restrictions are: If the BYYEARDAY appears, no other date rule part may appear. BYWEEKNO and BYMONTH rule parts may not both appear. Furthermore, not all date rule parts may be used with all recurrence intervals. For MONTHLY recurrences (FREQ=MONTHLY) neither BYYEARDAY nor BYWEEKNO may appear. For WEEKLY recurrences (FREQ=WEEKLY) neither BYMONTHDAY nor BYYEARDAY may appear. There are no restrictions regarding use of date rule parts and time rule parts. There are no restrictions with using any combination of time rule parts ----------------------- The complete list of emails I know about for this topic are: From Damon Chaplin: http://www.imc.org/ietf-calendar/mail-archive/msg03656.html From Bruce: http://www.imc.org/ietf-calendar/mail-archive/msg03549.html http://www.imc.org/ietf-calendar/mail-archive/msg03510.html From me: http://www.imc.org/ietf-calendar/mail-archive/msg03507.html http://www.imc.org/ietf-calendar/mail-archive/msg03507.html http://www.imc.org/ietf-calendar/mail-archive/msg03549.html eric. From owner-ietf-calendar@mail.imc.org Fri Aug 11 01:26: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 BAA26377 for ; Fri, 11 Aug 2000 01:26:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA15968 for ietf-calendar-bks; Thu, 10 Aug 2000 22:08:40 -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 WAA15964 for ; Thu, 10 Aug 2000 22:08:39 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7B51xj22887 for ; Thu, 10 Aug 2000 22:01:59 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id FZ43KD00.B1C; Thu, 10 Aug 2000 22:07:25 -0700 Message-ID: <39938ADF.65C9E591@netscape.com> Date: Thu, 10 Aug 2000 22:10:55 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Eric Busboom CC: CalSched IETF , deweydev@netscape.com, Naveen Kachroo , Katia Hage , Bruce Kahn Subject: Re: Updates to iTIP/iMIP RFCs References: Content-Type: multipart/mixed; boundary="------------51B0306372892A099AF26BC3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------51B0306372892A099AF26BC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric Busboom wrote: > On Thu, 10 Aug 2000, Steve Mansour wrote: > > Folks, > > > > Also, if you are aware of any other issues, please let me know about > > them now and we should be able to get them into the revisions. > > Um, Recurrence rules? ... right. But this would be an iCalendar update. Pat is working on signing up a responsible party for iCalendar. I was referring specifically to iTIP and iMIP. -Steve --------------51B0306372892A099AF26BC3 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 tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------51B0306372892A099AF26BC3-- From owner-ietf-calendar@mail.imc.org Fri Aug 11 12:35: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 MAA24847 for ; Fri, 11 Aug 2000 12:35:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29169 for ietf-calendar-bks; Fri, 11 Aug 2000 09:11:01 -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 JAA29165 for ; Fri, 11 Aug 2000 09:10:59 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA06989; Fri, 11 Aug 2000 12:11:38 -0400 Message-ID: <399425BA.B2030BAB@ecal.com> Date: Fri, 11 Aug 2000 12:11:38 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF CC: deweydev@netscape.com, Naveen Kachroo , Katia Hage , Bruce Kahn Subject: Re: Updates to iTIP/iMIP RFCs References: <39932418.CE1A2657@netscape.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 Steve Mansour wrote: > Proposal: Add a new method: CONFIRM. It would be used > to (a) reply to a REFRESH and (b) notify participants > of any changes to ATTENDEE or ORGANIZER. All other > "reschedule" or "update" changes MUST use REQUEST > method. > Is this really necessary? Since there are some deployed iMIP implementations (right?), it would require us to support both modes. > 2. Identify sender of iTIP COUNTER: > Proposal 2: Add a new parameter to the ATTENDEE property: > ATTCOUNTER. It can only be specified (a) when the component > method is COUNTER and (b) for the one Attendee who issued the > COUNTER. I favor this approach. > Note: The good news is that no functionality is lost > -- you can suggest a different attendee list. > Plus, it's really easy to support both versions: you take the old code that had to guess, and make it check ATTCOUNTER before it guesses. > The down side is that we have to update iCalendar > with a new parameter. > Yeah, but we've got procedures for that. Better to find out how well they work now than later. :-) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"The Reality Check's in the mail." --L. Peter| |francis@ecal.com|Deutsch | \==============================================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 12 16:03: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 QAA05583 for ; Sat, 12 Aug 2000 16:03:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA24713 for ietf-calendar-bks; Sat, 12 Aug 2000 12:43:10 -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 MAA24708 for ; Sat, 12 Aug 2000 12:43:03 -0700 (PDT) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: Pittsuburg Minutes - pointer X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: Date: Sat, 12 Aug 2000 15:42:23 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 08/12/2000 03:42:41 PM, Serialize complete at 08/12/2000 03:42:41 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006C433A85256939_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C433A85256939_= Content-Type: text/plain; charset="us-ascii" Here's the URL to the minutes of the CALSCH working group meeting at the Pittsburg IETF. http://www.egenconsulting.com/ietf/pitts-minutes.htm --=_alternative 006C433A85256939_= Content-Type: text/html; charset="us-ascii"
Here's the URL to the minutes of the CALSCH working group meeting at the Pittsburg IETF.

http://www.egenconsulting.com/ietf/pitts-minutes.htm
 --=_alternative 006C433A85256939_=-- From owner-ietf-calendar@mail.imc.org Sun Aug 13 03:16: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 DAA01729 for ; Sun, 13 Aug 2000 03:16:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA26865 for ietf-calendar-bks; Sun, 13 Aug 2000 00:00:45 -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 AAA26855 for ; Sun, 13 Aug 2000 00:00:41 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA01711 for ietf-calendar@imc.org; Sun, 13 Aug 2000 00:00:03 -0700 (PDT) Date: Sun, 13 Aug 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200008130700.AAA01711@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 draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) 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! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ 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 Tuesday discussion: DONE Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. DONE Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). DONE Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) DONE Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. DONE Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text DONE Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 DONE Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. DONE Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Sun Aug 13 16:49: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 QAA12998 for ; Sun, 13 Aug 2000 16:49:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA06205 for ietf-calendar-bks; Sun, 13 Aug 2000 13:30:13 -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 NAA06175; Sun, 13 Aug 2000 13:30:05 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA20694; Sun, 13 Aug 2000 16:30:50 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA24763; Sun, 13 Aug 2000 16:29:08 -0400 (EDT) To: John Stracke Cc: Bruce Kahn , deweydev@netscape.com, CalSched IETF , Katia Hage , Naveen Kachroo , owner-ietf-calendar@mail.imc.org Subject: Re: Updates to iTIP/iMIP RFCs X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Sun, 13 Aug 2000 16:28:42 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08072000 |August 7, 2000) at 08/13/2000 04:28:45 PM, Serialize complete at 08/13/2000 04:28:45 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006E0EF58525693A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E0EF58525693A_= Content-Type: text/plain; charset="us-ascii" > Proposal: Add a new method: CONFIRM. It would be used > to (a) reply to a REFRESH and (b) notify participants > of any changes to ATTENDEE or ORGANIZER. All other > "reschedule" or "update" changes MUST use REQUEST > method. > Is this really necessary? Since there are some deployed iMIP implementations (right?), it would require us to support both modes. John: We talked about this some time ago. Just didn't act on it. The rationale was that the iTIP REQUEST method was overloaded as a verb for both invite, reschedule, as well as confirm and attendee status confirmations. -- Frank --=_alternative 006E0EF58525693A_= Content-Type: text/html; charset="us-ascii"
>      Proposal: Add a new method: CONFIRM. It would be used
>      to (a) reply to a REFRESH and (b) notify participants
>      of any changes to ATTENDEE or ORGANIZER.  All other
>      "reschedule" or "update" changes MUST use REQUEST
>      method.
>
Is this really necessary? Since there are some deployed iMIP
implementations (right?), it would require us to support both
modes.

John:

We talked about this some time ago. Just didn't act on it.

The rationale was that the iTIP REQUEST method was overloaded as a verb for both invite, reschedule, as well as confirm and attendee status confirmations.

-- Frank

--=_alternative 006E0EF58525693A_=-- From owner-ietf-calendar@mail.imc.org Sun Aug 13 17:19: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 RAA13145 for ; Sun, 13 Aug 2000 17:19:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07964 for ietf-calendar-bks; Sun, 13 Aug 2000 14:06:46 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07959 for ; Sun, 13 Aug 2000 14:06:45 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Sun, 13 Aug 2000 14:06:12 -0700 Message-ID: <39970DC4.205A2E1@home.royer.com> Date: Sun, 13 Aug 2000 14:06:12 -0700 From: Doug Royer Reply-To: Doug@Royer.com X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: John Stracke , Bruce Kahn , deweydev@netscape.com, CalSched IETF , Katia Hage , Naveen Kachroo , owner-ietf-calendar@mail.imc.org Subject: Re: Updates to iTIP/iMIP RFCs 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: > > > Proposal: Add a new method: CONFIRM. It would be used > > to (a) reply to a REFRESH and (b) notify participants > > of any changes to ATTENDEE or ORGANIZER. All other > > "reschedule" or "update" changes MUST use REQUEST > > method. > > > Is this really necessary? Since there are some deployed iMIP > implementations (right?), it would require us to support both > modes. > > John: > > We talked about this some time ago. Just didn't act on it. > > The rationale was that the iTIP REQUEST method was overloaded as a verb > for both invite, reschedule, as well as confirm and attendee status > confirmations. John, We knew that RFC 2445 would not be a standard until there were multiple interoperable implementations. We also knew that interoperability testing would find bugs. This is one that was found. Frank, Do you have a list of these kind of issues? (For iCal, iTIP, iMIP)? I don't thing the WG has a full list. -Doug From owner-ietf-calendar@mail.imc.org Mon Aug 14 05:42: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 FAA02555 for ; Mon, 14 Aug 2000 05:42:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA04844 for ietf-calendar-bks; Mon, 14 Aug 2000 02:24:30 -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 CAA04839 for ; Mon, 14 Aug 2000 02:24:29 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id FAA21757; Mon, 14 Aug 2000 05:25:19 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id FAA21130; Mon, 14 Aug 2000 05:23:36 -0400 (EDT) To: Doug@Royer.com Cc: CalSched IETF Subject: Re: Updates to iTIP/iMIP RFCs X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 14 Aug 2000 05:23:08 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08072000 |August 7, 2000) at 08/14/2000 05:23:14 AM, Serialize complete at 08/14/2000 05:23:14 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 003394D38525693B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 003394D38525693B_= Content-Type: text/plain; charset="us-ascii" Doug: I am out of my office but will check on return on Wednesday. I believe that the addition of the CONFIRM verb was the only "feature enhancement" that I had for iTIP (other than the multipart support that was moved to iCalendar...). But will check. I also have an extensive list of typos that folks have been sending me. Most of these were put in the iCalendar Internet-Draft from last year. I need to resubmit it with the other typos that were found since the last Internet-Draft was sent. I should also create a document that specifies all of these by section. Hope this helps. -- Frank --=_alternative 003394D38525693B_= Content-Type: text/html; charset="us-ascii"
Doug:

I am out of my office but will check on return on Wednesday. I believe that the addition of the CONFIRM verb was the only "feature enhancement" that I had for iTIP (other than the multipart support that was moved to iCalendar...). But will check.

I also have an extensive list of typos that folks have been sending me. Most of these were put in the iCalendar Internet-Draft from last year. I need to resubmit it with the other typos that were found since the last Internet-Draft was sent. I should also create a document that specifies all of these by section.

Hope this helps.

-- Frank --=_alternative 003394D38525693B_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 15 15:57: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 PAA23182 for ; Tue, 15 Aug 2000 15:57:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12213 for ietf-calendar-bks; Tue, 15 Aug 2000 12:32:37 -0700 (PDT) Received: from arista.iris.com ([198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12209 for ; Tue, 15 Aug 2000 12:32:34 -0700 (PDT) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt X-Mailer: Lotus Notes Build V60_08132000 August 13, 2000 Message-ID: Date: Tue, 15 Aug 2000 15:35:39 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/15/2000 03:32:24 PM, Serialize complete at 08/15/2000 03:32:24 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006B57AE8525693C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B57AE8525693C_= Content-Type: text/plain; charset="us-ascii" 2 Quick questions come to mind after reading this preliminary draft: 1: Is a CRISP server intended to be an iTIP->CAP bridge ONLY or is it intended to be iTIP<->CAP (ie: a bidirectional transcoder)?? 2: Is CRISP an attempt to try to make a realtime ONLY iTIP bridge to CAP or is there any intenet/expectation to do iMIP bridging? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B57AE8525693C_= Content-Type: text/html; charset="us-ascii"
2 Quick questions come to mind after reading this preliminary draft:

1: Is a CRISP server intended to be an iTIP->CAP bridge ONLY or is it intended to be iTIP<->CAP (ie: a bidirectional transcoder)??

2: Is CRISP an attempt to try to make a realtime ONLY iTIP bridge to CAP or is there any intenet/expectation to do iMIP bridging?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006B57AE8525693C_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 15 17:33: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 RAA27657 for ; Tue, 15 Aug 2000 17:33:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14684 for ietf-calendar-bks; Tue, 15 Aug 2000 14:15:53 -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 OAA14676 for ; Tue, 15 Aug 2000 14:15:51 -0700 (PDT) Received: from Software.com ([207.175.94.179]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000815211703.WXHJ459995.mta1biz.bizmailsrvcs.net@Software.com> for ; Tue, 15 Aug 2000 16:17:03 -0500 Message-ID: <3999A1FB.C151609B@Software.com> Date: Tue, 15 Aug 2000 13:03:07 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt 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: > > 2 Quick questions come to mind after reading this preliminary draft: > > 1: Is a CRISP server intended to be an iTIP->CAP bridge ONLY or is it > intended to be iTIP<->CAP (ie: a bidirectional transcoder)?? > > 2: Is CRISP an attempt to try to make a realtime ONLY iTIP bridge to CAP > or is there any intenet/expectation to do iMIP bridging? CRISP is a CAP server that is limited to iTIP functionality. It is in response to several peoples desire to keep iRIP alive. So a client expecting to talk to a CRISP server could also talk to a CAP server and everything would work. -Doug From owner-ietf-calendar@mail.imc.org Wed Aug 16 11:37: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 LAA28230 for ; Wed, 16 Aug 2000 11:37:25 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA26624 for ietf-calendar-bks; Wed, 16 Aug 2000 08:15: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 IAA26608 for ; Wed, 16 Aug 2000 08:15:05 -0700 (PDT) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt X-Mailer: Lotus Notes Build V60_08132000 August 13, 2000 Message-ID: Date: Wed, 16 Aug 2000 11:18:33 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/16/2000 11:19:27 AM, Serialize complete at 08/16/2000 11:19:27 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0053CE048525693D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053CE048525693D_= Content-Type: text/plain; charset="us-ascii" Doug replied: >> 1: Is a CRISP server intended to be an iTIP->CAP bridge ONLY or is it >> intended to be iTIP<->CAP (ie: a bidirectional transcoder)?? >> >> 2: Is CRISP an attempt to try to make a realtime ONLY iTIP bridge to CAP >> or is there any intenet/expectation to do iMIP bridging? > >CRISP is a CAP server that is limited to iTIP functionality. >It is in response to several peoples desire to keep iRIP alive. >So a client expecting to talk to a CRISP server could also >talk to a CAP server and everything would work. I got most of that from the abstract but its not clear from the text if CRISP is intended to be 'an iTIP service provider for CAP servers' or just 'a bridge to provide iTIP access to a CAP server'. If the former case then the draft is incomplete. If the latter case then the text should indicate that CRISP is just meant for that purpose alone. The text about proxying thru firewalls could be interpreted as the former case and so Im asking to avoid confusion later. John, can you clarify this intent/ability in the next draft update?? Ill guess that the answer to #2 is "realtime ONLY iTIP" (ie: iRIP) and not 'iMIP bridging'. "CAP server that is limited to iTIP functionality" implies iMIP is possible (iTIP fanout anyone??) but "[CRISP] is in response to several peoples desire to keep iRIP alive" implies more strongly iRIP only. If Ive misguessed, Im sure Ill hear about it. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0053CE048525693D_= Content-Type: text/html; charset="us-ascii"
Doug replied:
>> 1: Is a CRISP server intended to be an iTIP->CAP bridge ONLY or is it
>> intended to be iTIP<->CAP (ie: a bidirectional transcoder)??
>>
>> 2: Is CRISP an attempt to try to make a realtime ONLY iTIP bridge to CAP
>> or is there any intenet/expectation to do iMIP bridging?
>
>CRISP is a CAP server that is limited to iTIP functionality.
>It is in response to several peoples desire to keep iRIP alive.
>So a client expecting to talk to a CRISP server could also
>talk to a CAP server and everything would work.

I got most of that from the abstract but its not clear from the text if CRISP is intended to be 'an iTIP service provider for CAP servers' or just 'a bridge to provide iTIP access to a CAP server'.  If the former case then the draft is incomplete.  If the latter case then the text should indicate that CRISP is just meant for that purpose alone.  The text about proxying thru firewalls could be interpreted as the former case and so Im asking to avoid confusion later.  

John, can you clarify this intent/ability in the next draft update??

Ill guess that the answer to #2 is "realtime ONLY iTIP" (ie: iRIP) and not 'iMIP bridging'.  "CAP server that is limited to iTIP functionality" implies iMIP is possible (iTIP fanout anyone??) but "[CRISP] is in response to several peoples desire to keep iRIP alive" implies more strongly iRIP only.  If Ive misguessed, Im sure Ill hear about it.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0053CE048525693D_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 17 09:43: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 JAA26526 for ; Thu, 17 Aug 2000 09:43:26 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA13416 for ietf-calendar-bks; Thu, 17 Aug 2000 06:25:51 -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 GAA13407 for ; Thu, 17 Aug 2000 06:25:49 -0700 (PDT) From: pregen@egenconsulting.com To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: Date: Thu, 17 Aug 2000 09:25:39 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 08/17/2000 09:25:44 AM, Serialize complete at 08/17/2000 09:25:44 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0049C53A8525693E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0049C53A8525693E_= Content-Type: text/plain; charset="us-ascii" Bruce, I actually thought the text might be incomplete as well. If this is intended to be iTIP provider, then I thought the draft was too brief. John, your comments? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bruce_Kahn@iris.com Sent by: owner-ietf-calendar@mail.imc.org 08/16/00 11:18 AM To: ietf-calendar@imc.org cc: Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt Doug replied: >> 1: Is a CRISP server intended to be an iTIP->CAP bridge ONLY or is it >> intended to be iTIP<->CAP (ie: a bidirectional transcoder)?? >> >> 2: Is CRISP an attempt to try to make a realtime ONLY iTIP bridge to CAP >> or is there any intenet/expectation to do iMIP bridging? > >CRISP is a CAP server that is limited to iTIP functionality. >It is in response to several peoples desire to keep iRIP alive. >So a client expecting to talk to a CRISP server could also >talk to a CAP server and everything would work. I got most of that from the abstract but its not clear from the text if CRISP is intended to be 'an iTIP service provider for CAP servers' or just 'a bridge to provide iTIP access to a CAP server'. If the former case then the draft is incomplete. If the latter case then the text should indicate that CRISP is just meant for that purpose alone. The text about proxying thru firewalls could be interpreted as the former case and so Im asking to avoid confusion later. John, can you clarify this intent/ability in the next draft update?? Ill guess that the answer to #2 is "realtime ONLY iTIP" (ie: iRIP) and not 'iMIP bridging'. "CAP server that is limited to iTIP functionality" implies iMIP is possible (iTIP fanout anyone??) but "[CRISP] is in response to several peoples desire to keep iRIP alive" implies more strongly iRIP only. If Ive misguessed, Im sure Ill hear about it. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0049C53A8525693E_= Content-Type: text/html; charset="us-ascii"
Bruce, I actually thought the text might be incomplete as well.  If this is intended to be iTIP provider, then I thought the draft was too brief.  John, your comments?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Bruce_Kahn@iris.com
Sent by: owner-ietf-calendar@mail.imc.org

08/16/00 11:18 AM

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt



Doug replied:
>> 1: Is a CRISP server intended to be an iTIP->CAP bridge ONLY or is it
>> intended to be iTIP<->CAP (ie: a bidirectional transcoder)??
>>
>> 2: Is CRISP an attempt to try to make a realtime ONLY iTIP bridge to CAP
>> or is there any intenet/expectation to do iMIP bridging?
>
>CRISP is a CAP server that is limited to iTIP functionality.
>It is in response to several peoples desire to keep iRIP alive.
>So a client expecting to talk to a CRISP server could also
>talk to a CAP server and everything would work.

I got most of that from the abstract but its not clear from the text if CRISP is intended to be 'an iTIP service provider for CAP servers' or just 'a bridge to provide iTIP access to a CAP server'.  If the former case then the draft is incomplete.  If the latter case then the text should indicate that CRISP is just meant for that purpose alone.  The text about proxying thru firewalls could be interpreted as the former case and so Im asking to avoid confusion later.  

John, can you clarify this intent/ability in the next draft update??

Ill guess that the answer to #2 is "realtime ONLY iTIP" (ie: iRIP) and not 'iMIP bridging'.  "CAP server that is limited to iTIP functionality" implies iMIP is possible (iTIP fanout anyone??) but "[CRISP] is in response to several peoples desire to keep iRIP alive" implies more strongly iRIP only.  If Ive misguessed, Im sure Ill hear about it.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0049C53A8525693E_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 17 11:23: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 LAA28493 for ; Thu, 17 Aug 2000 11:23:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17835 for ietf-calendar-bks; Thu, 17 Aug 2000 08:08:03 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17831 for ; Thu, 17 Aug 2000 08:07:59 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Thu, 17 Aug 2000 08:07:42 -0700 Message-ID: <399BFFBE.F799728E@home.royer.com> Date: Thu, 17 Aug 2000 08:07:42 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt 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 > I got most of that from the abstract but its not clear from the text if > CRISP is intended to be 'an iTIP service provider for CAP servers' or > just 'a bridge to provide iTIP access to a CAP server'. If the former > case then the draft is incomplete. If the latter case then the text > should indicate that CRISP is just meant for that purpose alone. The > text about proxying thru firewalls could be interpreted as the former > case and so Im asking to avoid confusion later. I do not understand the difference in the two questions. What is "an iTIP service provider for CAP servers" ? > John, can you clarify this intent/ability in the next draft update?? > > Ill guess that the answer to #2 is "realtime ONLY iTIP" (ie: iRIP) and > not 'iMIP bridging'. What is "iMIP bridging" ? > "CAP server that is limited to iTIP functionality" > implies iMIP is possible (iTIP fanout anyone??) but "[CRISP] is in > response to several peoples desire to keep iRIP alive" implies more > strongly iRIP only. If Ive misguessed, Im sure Ill hear about it. Who ever said that iRIP could not do iMIP? In fact I think the ORGANIZER and ATTENDEE properties in iRIP were MUST == mailto urls. So what is the difference? -Doug From owner-ietf-calendar@mail.imc.org Thu Aug 17 12:30: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 MAA29637 for ; Thu, 17 Aug 2000 12:30:27 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA24800 for ietf-calendar-bks; Thu, 17 Aug 2000 09:07:15 -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 JAA24796 for ; Thu, 17 Aug 2000 09:07:14 -0700 (PDT) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt X-Mailer: Lotus Notes Build V60_08132000 August 13, 2000 Message-ID: Date: Thu, 17 Aug 2000 12:10:44 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/17/2000 12:07:12 PM, Serialize complete at 08/17/2000 12:07:13 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/17/2000 12:07:13 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005894518525693E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005894518525693E_= Content-Type: text/plain; charset="us-ascii" Doug asked: >What is "an iTIP service provider for CAP servers" ? An iTIP service provider is a task/process/library/module that services the iTIP needs of its caller/user. In this case, it could be that the CAP server does not need to do any iTIP work of its own, it would just "load and use" the CRISP server to do any iTIP work for it. This is difference between being a simplified iTIP (nee iRIP) gateway INTO a CAP server/service and an "iTIP service provider" FOR a CAP server/service. The former is inbound oriented, the latter is outbound oriented. >What is "iMIP bridging" ? Pardon that phrase; its my mental notation for trying to categorize the boundaries of a CRISP servers functionality. Taking a step back to clarify this a bit. Doug wrote "CRISP is a CAP server that is limited to iTIP functionality." so this implys it supports all iTIP bindings: both iMIP and iRIP. As such CRISP could be construed as "the iTIP engine or gateway" for a CAP server. However Im getting the distinct feeling (at least from Doug) that CRISP is intended ONLY for iRIP ("It is in response to several peoples desire to keep iRIP alive." plus its name"CAP Realtime iTIP-based..." ) As such, a CRISP server does not deal with any iMIP messages. If that is so, then the text should be updated to reflect the iRIP only focus so that someone does not get the mistaken impression that CRISP "can do iMIP" since iMIP is a binding of iTIP. >Who ever said that iRIP could not do iMIP? I claim that they are separate critters: iMIP is "store and forward" (aka email) and iRIP is "realtime" (aka HTTP like). As such, once an "iRIP server" passed the request to an "iMIP server" (ie: a fallback of some kind) then iRIP is no longer being used, iMIP is. So its a bit of a strech to say "iRIP can do iMIP"... I guess one could build a "realtime" server over email but I think they'd have a hard time convincing customers it was "realtime". >So what is the difference? Whats the difference between store-and-forward and realtime sending of data? I wont get into the addressing issues between CAP & iTIP; they've already been raised at least once before... John: Care to clarify the air or do you prefer to watch Doug and I discuss this further?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005894518525693E_= Content-Type: text/html; charset="us-ascii"
Doug asked:
>What is "an iTIP service provider for CAP servers" ?

An iTIP service provider is a task/process/library/module that services the iTIP needs of its caller/user.  In this case, it could be that the CAP server does not need to do any iTIP work of its own, it would just "load and use" the CRISP server to do any iTIP work for it.  

This is difference between being a simplified iTIP (nee iRIP) gateway INTO a CAP server/service and an "iTIP service provider" FOR a CAP server/service.

The former is inbound oriented, the latter is outbound oriented.

>What is "iMIP bridging" ?

Pardon that phrase; its my mental notation for trying to categorize the boundaries of a CRISP servers functionality.  Taking a step back to clarify this a bit.  

Doug wrote "CRISP is a CAP server that is limited to iTIP functionality." so this implys it supports all iTIP bindings: both iMIP and iRIP.  As such CRISP could be construed as "the iTIP engine or gateway" for a CAP server.  However Im getting the distinct feeling (at least from Doug) that CRISP is intended ONLY for iRIP ("It is in response to several peoples desire to keep iRIP alive." plus its name"CAP Realtime iTIP-based..." )  As such, a CRISP server does not deal with any iMIP messages.  If that is so, then the text should be updated to reflect the iRIP only focus so that someone does not get the mistaken impression that CRISP "can do iMIP" since iMIP is a binding of iTIP.

<DIGRESSION FROM CRISP>
>Who ever said that iRIP could not do iMIP?

I claim that they are separate critters: iMIP is "store and forward" (aka email) and iRIP is "realtime" (aka HTTP like).  As such, once an "iRIP server" passed the request to an "iMIP server" (ie: a fallback of some kind) then iRIP is no longer being used, iMIP is.  So its a bit of a strech to say "iRIP can do iMIP"...  I guess one could build a "realtime" server over email but I think they'd have a hard time convincing customers it was "realtime".

>So what is the difference?

Whats the difference between store-and-forward and realtime sending of data?

I wont get into the addressing issues between CAP & iTIP; they've already been raised at least once before...
</DIGRESSION>

John:  Care to clarify the air or do you prefer to watch Doug and I discuss this further??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005894518525693E_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 17 13:26: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 NAA00900 for ; Thu, 17 Aug 2000 13:26:23 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA26612 for ietf-calendar-bks; Thu, 17 Aug 2000 10:08:14 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26607 for ; Thu, 17 Aug 2000 10:08:12 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Thu, 17 Aug 2000 10:08:06 -0700 Message-ID: <399C1BF6.1DA4BC91@home.royer.com> Date: Thu, 17 Aug 2000 10:08:06 -0700 From: Doug Royer X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt 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: > >What is "an iTIP service provider for CAP servers" ? > > An iTIP service provider is a task/process/library/module that services > the iTIP needs of its caller/user. In this case, it could be that the > CAP server does not need to do any iTIP work of its own, it would just > "load and use" the CRISP server to do any iTIP work for it. Okay - where in CRISP does it say that? Or what in CRISP makes you think that is what it is? > This is difference between being a simplified iTIP (nee iRIP) gateway > INTO a CAP server/service and an "iTIP service provider" FOR a CAP > server/service. I have not seen any such proposal on this list. > The former is inbound oriented, the latter is outbound oriented. > > >What is "iMIP bridging" ? > > Pardon that phrase; its my mental notation for trying to categorize the > boundaries of a CRISP servers functionality. Taking a step back to > clarify this a bit. > > Doug wrote "CRISP is a CAP server that is limited to iTIP functionality." > so this implys it supports all iTIP bindings: both iMIP and iRIP. As > such CRISP could be construed as "the iTIP engine or gateway" for a CAP > server. However Im getting the distinct feeling (at least from Doug) > that CRISP is intended ONLY for iRIP ("It is in response to several > peoples desire to keep iRIP alive." plus its name"CAP Realtime > iTIP-based..." ) As such, a CRISP server does not deal with any iMIP > messages. I'll answer as many differant ways as I can because I still am not sure why you think that CRISP would do more than CAP or iRIP. CRISP, CAP, and iIRIP servers do not not act as an MTA and gather iMIP messages. CRISP and CAP servers can generate iMIP messages. You can not send an iMIP message to: CAP, CRISP, or iRIP servers. As they all (at least) support iTIP. None of them support iMIP being sent directly to them. I don't recall if iRIP could generate an iMIP message. So both CAP and CRISP servers do deal with iMIP - generate only. > If that is so, then the text should be updated to reflect the > iRIP only focus so that someone does not get the mistaken impression that > CRISP "can do iMIP" since iMIP is a binding of iTIP. Nether could iRIP. So why do you think that CAP or CRISP could? > > >Who ever said that iRIP could not do iMIP? > > I claim that they are separate critters: iMIP is "store and forward" (aka > email) and iRIP is "realtime" (aka HTTP like). As such, once an "iRIP > server" passed the request to an "iMIP server" (ie: a fallback of some > kind) then iRIP is no longer being used, iMIP is. iRIP never specified how the data would get to the end user. I don't recall it ever saying that an iRIP server would pass the request to an iMIP server (By that do you mean MTA?). > So its a bit of a > strech to say "iRIP can do iMIP"... I guess one could build a "realtime" > server over email but I think they'd have a hard time convincing > customers it was "realtime". I don't recall CAP, CRISP, or iRIP saying that. I did not mean to say that. Are you asking for that to be added to CAP/CRISP? > >So what is the difference? > > Whats the difference between store-and-forward and realtime sending of > data? I see you as asking: "Something that no one has talked about or posted - does crisp do that?". -Doug From owner-ietf-calendar@mail.imc.org Thu Aug 17 17:17: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 RAA04826 for ; Thu, 17 Aug 2000 17:17:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA01708 for ietf-calendar-bks; Thu, 17 Aug 2000 13:56:06 -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 NAA01704 for ; Thu, 17 Aug 2000 13:56:05 -0700 (PDT) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7HKntY11537 for ; Thu, 17 Aug 2000 13:49:56 -0700 (PDT) Received: from netscape.com (h-192-18-125-198.red.iplanet.com [192.18.125.198]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id OAA52579 for ; Thu, 17 Aug 2000 14:02:22 -0700 (PDT) Message-ID: <399C5150.67A0964@netscape.com> Date: Thu, 17 Aug 2000 13:55:44 -0700 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Updated restriction table text Content-Type: multipart/mixed; boundary="------------8B55465FC5551EEDDCF7F710" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8B55465FC5551EEDDCF7F710 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is an updated version of the restriction table for the Create command. It is definitely has a ways to go. As always, comments are appreciated. -Steve --------------8B55465FC5551EEDDCF7F710 Content-Type: text/plain; charset=us-ascii; name="restriction.txt" Content-Disposition: inline; filename="restriction.txt" Content-Transfer-Encoding: 7bit Restriction Tables Commands are sent to CAP servers encapsulated in iCalendar objects. The reply to these commands are also encapsulated in iCalendar objects. The restriction tables listed in the commands below describe the composition of these commands and replies. The Presence column uses the following values to assert whether a property is required, is optional and the number of times it may appear in the iCalendar object. A Comment may be provided to further clarify the presence criteria. The table below defines the values for the Presence column. Presence Value Description ------------------------------------------------------------------- 1 One instance MUST be present 1+ At least one instance MUST be present 0 Instances of this property Must NOT be present 0+ Multiple instances MAY be present 0 or 1 Up to 1 instance of this property MAY be present ------------------------------------------------------------------- While the tables list every component and property, their purpose is not to define the meaning of the component or property. There will be a RESPONSE-STATUS for each VCALENDAR and component created, modified, deleted, or requested. The number of RESPONSE-STATUS values returned MUST be equal to the number of TARGETS times the number of objects in the command. The responses MUST be ordered first by TARGET then by the order of the objects as supplied in the command. Client Restriction Table for the Create command Component/Property Presence Comment ------------------- -------- -------------------------------------- VCALENDAR 1+ The CUA can send up PIPELINE commands without processing a response CMDID 0 or 1 If CMDID is not supplied, then there must not be pending replies to previous command. VERSION 1 MUST be 2.0 VCOMMAND 1 MUST at least one container (VCALENDAR, VCAR, VQUERY, VEVENT, VTODO, VJOURNAL, V METHOD 1 MUST be CREATE. TARGET 1+ MUST be a the CSID or CALID VCALENDAR 0+ CALMASTER 0 or 1 NAME 0 or 1 The user friendly name, localizable. OWNER 1+ RELCALID 1 TZID 0 or 1 VCAR 0+ CARID 0 or 1 A reference name DENY 0+ permissions denied. Note, there must be at least one GRANT or DENY within the VCAR. GRANT 0+ permissions granted. Note, there must be at least one GRANT or DENY within the VCAR. VQUERY 0+ EXPAND 0 or 1 Expand recurrences or not MAXRESULTS 0 or 1 Limit the solution set to no more than this many enries. MAXSIZE 0 or 1 Maximum number of octets to transfer QUERYNAME 1 Name by which this query is referenced QUERY 1 The query VEVENT 0+ ATTENDEE 0+ SEQUENCE 0 or 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTEND 0 or 1 if present DURATION MUST NOT be present DTSTAMP 1 DTSTART 1 DURATION 0 or 1 if present DTEND MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ORGANIZER 1 PRIORITY 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUS 0+ RESOURCES 0 or 1 This property MAY contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED TRANSP 0 or 1 URL 0 or 1 X-PROPERTY 0+ [IANA-PROP] 0+ any IANA registered property VALARM 0+ ACTION 1 ALARMID 0 or 1 MUST be 1 if multiple VALARMs are present in same component. ATTACH 0+ DESCRIPTION 0 or 1 DURATION 0 or 1 if present REPEAT MUST be present REPEAT 0 or 1 if present DURATION MUST be present SUMMARY 0 or 1 TRIGGER 1 X-PROPERTY 0+ VTODO 0+ ATTENDEE 0+ SEQUENCE 0 or 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null. UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTSTAMP 1 DTSTART 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ORGANIZER 1 PRIORITY 1 PERCENT-COMPLETE 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUS 0 RESOURCES 0 or 1 This property may contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- PROCESS/CANCELLED URL 0 or 1 X-PROPERTY 0+ [IANA-PROP] 0+ any IANA registered property VALARM 0+ ACTION 1 ALARMID 0 or 1 MUST be 1 if multiple VALARMs are present in same component. ATTACH 0+ DESCRIPTION 0 or 1 DURATION 0 or 1 if present REPEAT MUST be present REPEAT 0 or 1 if present DURATION MUST be present SUMMARY 0 or 1 TRIGGER 1 X-PROPERTY 0+ VJOURNAL 0+ METHOD 1 MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE. ATTENDEE 0 DESCRIPTION 1 Can be null. DTSTAMP 1 DTSTART 1 ORGANIZER 1 UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property MAY contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 EXDATE 0+ EXRULE 0+ LAST-MODIFIED 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ RRULE 0+ SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. MUST be present if non-zero. MAY be present if zero. STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED SUMMARY 0 or 1 Can be null URL 0 or 1 X-PROPERTY 0+ VFREEBUSY 0 VTIMEZONE 0+ MUST be present if any date/time refers to timezone DAYLIGHT 0+ MUST be one or more of either STANDARD or DAYLIGHT COMMENT 0 or 1 DTSTART 1 MUST be local time format RDATE 0+ if present RRULE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present TZNAME 0 or 1 TZOFFSET 1 TZOFFSETFROM 1 TZOFFSETTO 1 X-PROPERTY 0+ LAST-MODIFIED 0 or 1 STANDARD 0+ MUST be one or more of either STANDARD or DAYLIGHT COMMENT 0 or 1 DTSTART 1 MUST be local time format RDATE 0+ if present RRULE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present TZNAME 0 or 1 TZOFFSETFROM 1 TZOFFSETTO 1 X-PROPERTY 0+ TZID 1 TZURL 0 or 1 X-PROPERTY 0+ Server Restriction Table for the CREATE command Component/Property Presence Comment ------------------- -------- -------------------------------------- VCALENDAR 1+ TARGET 1 VERSION 1 MUST be 2.0 CMDID 0 or 1 MUST be returned if the request contained a CMDID VALARM 0 RESPONSE-STATUS 0 if not creating a calendar 1+ if creating a calendar VCAR 0+ RESPONSE-STATUS 1+ * 0 No other VCAR properties are present VCOMMAND 0 VEVENT 0+ RESPONSE-STATUS 1+ * 0 No other VEVENT properties are present VFREEBUSY 0+ RESPONSE-STATUS 1+ * 0 No other VFREEBUSY properties are present VJOURNAL 0+ RESPONSE-STATUS 1+ * 0 No other VJOURNAL properties are present VQUERY 0+ RESPONSE-STATUS 1+ * 0 No other VQUERY properties are present VTODO 0+ RESPONSE-STATUS 1+ * 0 No other VTODO properties are present Issues: freebusy - a cap server should dynamically calculate freebusy information we recommend that you cannot create, modify, or delete freebusy composers --------------8B55465FC5551EEDDCF7F710 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 tel;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------8B55465FC5551EEDDCF7F710-- From owner-ietf-calendar@mail.imc.org Thu Aug 17 17:33: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 RAA05062 for ; Thu, 17 Aug 2000 17:33:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA02198 for ietf-calendar-bks; Thu, 17 Aug 2000 14:16:23 -0700 (PDT) Received: from agony.busboom.org (IDENT:root@24-25-201-226.san.rr.com [24.25.201.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02194 for ; Thu, 17 Aug 2000 14:16:21 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id OAA04560 for ; Thu, 17 Aug 2000 14:16:11 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 17 Aug 2000 14:16:10 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: iRIP SWITCH command in CRISP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: iRIP had a SWITCH command so an iRIP client could initiate an outgoing connection though a firewall and then become a server, letting a remote client send components that it otherwise would not be able to. The CRISP draft mentions a relaying server that is placed outside of the firewall, presumably for the same purpose, but with a different model: in CRISP, there is a machine outside the firewall, but in iRIP all machines could be inside the firewall. Is the CRISP model sufficient to replace the SWITCH command? I don't know that it it not, but I'd like to be (reletively) certain that the SWITCH command is forever gone, since it has some design implications. eric. From owner-ietf-calendar@mail.imc.org Fri Aug 18 12:29: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 MAA01636 for ; Fri, 18 Aug 2000 12:29:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18943 for ietf-calendar-bks; Fri, 18 Aug 2000 09:16:49 -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 JAA18937 for ; Fri, 18 Aug 2000 09:16:48 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA21935 for ; Fri, 18 Aug 2000 12:18:17 -0400 Message-ID: <399D61C9.26763578@ecal.com> Date: Fri, 18 Aug 2000 12:18:17 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: Updates to iTIP/iMIP RFCs References: <39970DC4.205A2E1@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Is this really necessary? Since there are some deployed iMIP > > implementations (right?), it would require us to support both > > modes. > > > > We knew that RFC 2445 would not be a standard until there > were multiple interoperable implementations. We also knew > that interoperability testing would find bugs. This is one > that was found. Could you clarify, please? What sort of bugs came up, and how would changing REQUEST avoid them? While I appreciate that it may be necessary to make changes between Proposed and Draft, I'd rather see such changes minimized; there will be implementations that don't catch up, and supporting both old and new versions is a pain. -- /===============================================================\ |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 Fri Aug 18 12:29: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 MAA01647 for ; Fri, 18 Aug 2000 12:29:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18773 for ietf-calendar-bks; Fri, 18 Aug 2000 09:12:03 -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 JAA18769 for ; Fri, 18 Aug 2000 09:12:01 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA21908; Fri, 18 Aug 2000 12:13:07 -0400 Message-ID: <399D6092.A790BB9C@ecal.com> Date: Fri, 18 Aug 2000 12:13:06 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt 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 (Sorry; I was on vacation most of this week.) Bruce_Kahn@iris.com wrote: > 2 Quick questions come to mind after reading this preliminary > draft: > > 1: Is a CRISP server intended to be an iTIP->CAP bridge ONLY or > is it intended to be iTIP<->CAP (ie: a bidirectional > transcoder)?? > > 2: Is CRISP an attempt to try to make a realtime ONLY iTIP > bridge to CAP or is there any intenet/expectation to do iMIP > bridging? CRISP is a subset of CAP (hence the term "Profile"). It could be used to create a bridge (as in the proxy case in section 6); or you could build a CAP server that lives in a DMZ and is CRISP-only when it gets a connection from the outside world; or (if you don't have CAP at all) you could build a server that just does CRISP. The notion of a CRISP implementation being a sidecar slapped on to the side of CAP to provide iTIP services is interesting, but probably can't really hold up in practice, since it relies too much on CAP's non-iTIP services (e.g., authentication). I'll see about clarifying the text. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"Fate just isn't what it used to be." --Hobbes| |francis@ecal.com| | \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 18 12:37: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 MAA01846 for ; Fri, 18 Aug 2000 12:37:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18791 for ietf-calendar-bks; Fri, 18 Aug 2000 09:13:00 -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 JAA18786 for ; Fri, 18 Aug 2000 09:12:58 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA21916 for ; Fri, 18 Aug 2000 12:14:28 -0400 Message-ID: <399D60E4.6F0B3FF1@ecal.com> Date: Fri, 18 Aug 2000 12:14:28 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: Updates to iTIP/iMIP RFCs 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: > > > Proposal: Add a new method: CONFIRM. It would be used > > to (a) reply to a REFRESH and (b) notify participants > > of any changes to ATTENDEE or ORGANIZER. All other > > "reschedule" or "update" changes MUST use REQUEST > > method. > > > Is this really necessary? Since there are some deployed iMIP > implementations (right?), it would require us to support both > modes. > > John: > > We talked about this some time ago. Just didn't act on it. > > The rationale was that the iTIP REQUEST method was overloaded > as a verb for both invite, reschedule, as well as confirm and > attendee status confirmations. Yes, I understand that--it is in the text that I quoted. It's not clear to me, though, whether this is a problem serious enough to break compatibility. -- /===============================================================\ |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 Fri Aug 18 12:38: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 MAA01878 for ; Fri, 18 Aug 2000 12:38:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19096 for ietf-calendar-bks; Fri, 18 Aug 2000 09:18:30 -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 JAA19091 for ; Fri, 18 Aug 2000 09:18:28 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA21939 for ; Fri, 18 Aug 2000 12:19:58 -0400 Message-ID: <399D622E.85A5B2C0@ecal.com> Date: Fri, 18 Aug 2000 12:19:58 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iRIP SWITCH command in CRISP 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 Eric Busboom wrote: > Is the CRISP model sufficient to replace the SWITCH command? I don't know > that it it not, but I'd like to be (reletively) certain that the SWITCH > command is forever gone, since it has some design implications. CRISP is a subset of CAP. CAP doesn't have it, so CRISP won't. Moreover, I suspect that, even if CAP had SWITCH, then CRISP would not; it sounds like a truly terrifying prospect, from a security standpoint, and CRISP is meant to be less terrifying than CAP. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |There are many intelligent species in the | |francis@ecal.com|cosmos. All are owned by cats. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 18 12:47: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 MAA02086 for ; Fri, 18 Aug 2000 12:47:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20169 for ietf-calendar-bks; Fri, 18 Aug 2000 09:33:36 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20164 for ; Fri, 18 Aug 2000 09:33:35 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Fri, 18 Aug 2000 09:33:33 -0700 Message-ID: <399D655C.810388B5@home.royer.com> Date: Fri, 18 Aug 2000 09:33:32 -0700 From: Doug Royer X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org, ietf-calendar@imc.org Subject: CAP - UPN question 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 A question for Paul Hill. In the Definitions section is: "User Principal Name (UPN)" An identifier that denotes a unique CU. A UPN is an RFC 822 ... .... A CU's UPN MUST never be deliverable to a different person. ... What about if someone does a READ of a VCAR. Should the CS filter out all other UPN's from the reply? -Doug From owner-ietf-calendar@mail.imc.org Fri Aug 18 12:47:56 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 MAA02099 for ; Fri, 18 Aug 2000 12:47:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19978 for ietf-calendar-bks; Fri, 18 Aug 2000 09:30:36 -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 JAA19972 for ; Fri, 18 Aug 2000 09:30:34 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA21999 for ; Fri, 18 Aug 2000 12:32:03 -0400 Message-ID: <399D6502.CACDD09B@ecal.com> Date: Fri, 18 Aug 2000 12:32:03 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt References: <399D6092.A790BB9C@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: > > 2: Is CRISP an attempt to try to make a realtime ONLY iTIP > > bridge to CAP or is there any intenet/expectation to do iMIP > > bridging? Forgot to answer this part. My expectation is that iMIP is done via a separate system. First of all, in order to have iMIP feed automatically into the user's calendar, you need to be able to get at the user's incoming email. POP and IMAP are not adequate for this purpose, because the user might read and delete the message before you get to it. This means that the iMIP receiver has to be integrated into the email server by some nonstandard process, which in turn means that it might not be able to run anywhere near the CAP server. In addition, such an iMIP implementation has to be very careful about what it does with the iTIP messages it gets, since they aren't authenticated (unless you're using S/MIME or something). Personally, I believe that a more reasonable approach to iMIP is to give the user a way to take incoming iTIP attachments and submit them to the CS by hand (via CAP, probably [CRISP would suffice]). Then you don't have to worry about tapping their email, and the CS can ignore questions of authentication and just trust that the user has some reason to believe that the message is legitimate. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |We want forty million helicopters and a dollar!| |francis@ecal.com|--"Dinosaurs" | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Aug 18 14:44: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 OAA04652 for ; Fri, 18 Aug 2000 14:44:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26228 for ietf-calendar-bks; Fri, 18 Aug 2000 11:27:59 -0700 (PDT) Received: from agony.busboom.org (IDENT:root@24-25-201-226.san.rr.com [24.25.201.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26224 for ; Fri, 18 Aug 2000 11:27:58 -0700 (PDT) From: eric@softwarestudio.org Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id LAA01504; Fri, 18 Aug 2000 11:27:54 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Fri, 18 Aug 2000 11:27:53 -0700 (PDT) X-Sender: eric@agony.busboom.org To: Doug@Royer.com cc: ietf-calendar@imc.org Subject: CAP Questions and Comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug, Here are some more questions and comments regarding the latest CAP draft. 1) Are all the examples in the CAP draft in SQL-MIN format? 2) For SQL-MIN, there is apparently no way to seach for components based on parameter value. Is this intended? If so, I presume that you need to use the SQL-92 format, but there don't seem to be any examples of its use. 3) If you are allowing any SQL-92 statement that follows the schema, then it looks like you could return data that is not representable in RFC2445 format, such as: SELECT VALUE_KEY FROM TRANSP WHERE VALUE=OPAQUE I'd expect this to return a list of integers if it were issued to a database. Does CAP automatically translate these value keys into components? Or, are these disallowed? 4) What is capmin-coms, referenced in (5) of section 5.1.2, page 30? 5) What is the precedece for AND and OR in WHERE? For instance, how do you interpret: WHERE x AND y OR z 6) In the SQL grammar section, there is no description of colvalue, other than its use in capmin-cmp, and it looks like query-min and capselect-min conflict. 7) 7.1.10.1. UPNEXPAND Method UPNEXPAND is actually a command, right? eric. From owner-ietf-calendar@mail.imc.org Fri Aug 18 15:14:35 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 PAA05325 for ; Fri, 18 Aug 2000 15:14:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA28105 for ietf-calendar-bks; Fri, 18 Aug 2000 11:59:41 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28095 for ; Fri, 18 Aug 2000 11:59:39 -0700 (PDT) Received: from grand-central-station.MIT.EDU (GRAND-CENTRAL-STATION.MIT.EDU [18.69.0.34]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA21986; Fri, 18 Aug 2000 14:59:30 -0400 (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 OAA09347; Fri, 18 Aug 2000 14:59:29 -0400 (EDT) Received: from miles-davis (MILES-DAVIS.MIT.EDU [18.18.1.113]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id OAA27697; Fri, 18 Aug 2000 14:59:28 -0400 (EDT) Message-Id: <4.2.0.58.20000818140741.01ad1bb0@po12.mit.edu> X-Sender: pbh@po12.mit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 18 Aug 2000 14:59:19 -0400 To: Doug Royer , ietf-calendar@imc.org From: "Paul B. Hill" Subject: Re: CAP - UPN question In-Reply-To: <399D655C.810388B5@home.royer.com> 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: >In the Definitions section is: > >"User Principal Name (UPN)" >An identifier that denotes a unique CU. A UPN is an RFC 822 ... > .... A CU's UPN MUST never be deliverable to a different person. ... > >What about if someone does a READ of a VCAR. Should the >CS filter out all other UPN's from the reply? IMHO, no. If you are reading a VCAR it might be because you are trying to determine who is on the VCAR. The intent of the phrase, "A CU's UPN MUST never be deliverable to a different person.", is to cover the situation where a person's UPN is not the same as their email address. Let's take the following example. Suppose that we have a person that has an email address of BOB@EXAMPLE.COM. But the CS administrator has assigned BOB a UPN of 123@EXAMPLE.COM. This might cause some confusion for people that interact with Bob. They might know him as BOB@example.com and 123@example.com in two different contexts, they might not even realize that they map to the same person. But if someone sends mail to 123@example.com it shouldgo to either Bob, or bounce. Mail sent to 123@example.com must not be delivered to someone else. (Ignore the issue of bounces going to postmaster.) Another way of saying this is, if a domain has a disjoint namespace between the CS UPN's and the email identifiers used in the same DNS domain, then no collisions should occur; alternatively a domain may choose to implement a single namespace that unifies their CS UPN's and their email identifiers. Does this help, or did I just cause even more confusion? Paul From owner-ietf-calendar@mail.imc.org Fri Aug 18 15:33: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 PAA06114 for ; Fri, 18 Aug 2000 15:33:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA29035 for ietf-calendar-bks; Fri, 18 Aug 2000 12:20:29 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29030 for ; Fri, 18 Aug 2000 12:20:27 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Fri, 18 Aug 2000 12:20:27 -0700 Message-ID: <399D8C7B.6EA8362E@home.royer.com> Date: Fri, 18 Aug 2000 12:20:27 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP - UPN question References: <4.2.0.58.20000818140741.01ad1bb0@po12.mit.edu> 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 "Paul B. Hill" wrote: > > >In the Definitions section is: > > > >"User Principal Name (UPN)" > >An identifier that denotes a unique CU. A UPN is an RFC 822 ... > > .... A CU's UPN MUST never be deliverable to a different person. ... > > > >What about if someone does a READ of a VCAR. Should the > >CS filter out all other UPN's from the reply? > > IMHO, no. If you are reading a VCAR it might be because you are trying to > determine who is on the VCAR. > .... > Another way of saying this is, if a domain has a disjoint namespace > between the CS UPN's and the email identifiers used in the same DN > domain, then no collisions should occur; alternatively a domain may > choose to implement a single namespace that unifies their CS UPN's > and their email identifiers. > > Does this help, or did I just cause even more confusion? Helps - I'll add/tweak the text to reflect this. Thanks! -Doug From owner-ietf-calendar@mail.imc.org Fri Aug 18 17:03: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 RAA08352 for ; Fri, 18 Aug 2000 17:03:50 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA00942 for ietf-calendar-bks; Fri, 18 Aug 2000 13:47:04 -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 NAA00937 for ; Fri, 18 Aug 2000 13:47:03 -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 QAA27924 for ; Fri, 18 Aug 2000 16:46:35 -0400 Received: from cst.ca (cc-1106.int.cst.ca [192.168.1.105]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RAYK41JK; Fri, 18 Aug 2000 16:46:34 -0400 Message-ID: <399DA0AB.BF6DEEF8@cst.ca> Date: Fri, 18 Aug 2000 16:46:35 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Subject: Registration of text/calendar MIME property TRANSP 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 Note: This has been changed from the original definition in iCAL by adding the TRANSPARENT-NOCONFLICT and OPAQUE-NOCONFLICT values. Changes needed by CAP. ------------------------------------------------------------------- To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property TRANSP Property name: TRANSP Property purpose: This property defines whether an event is transparent or not to busy time searches. Propery value type: TEXT Property parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified once in a "VEVENT" calendar component. Description: Time Transparency is the characteristic of an event that determines whether it appears to consume time on a calendar. Events that consume actual time for the individual or resource associated with the calendar SHOULD be recorded as OPAQUE or OPAQUE-NOCONFLICT, allowing them to be detected by free-busy time searches. If no other event can overlap such an event, then it SHOULD be recorded as OPAQUE-NOCONFLICT, otherwise it SHOULD be recorded as OPAQUE. Other events, which do not take up the individual's (or resource's) time SHOULD be recorded as TRANSPARENT or TRANSPARENT-NOCONFLICT, making them invisible to free-busy time searches. TRANSPARENT-NOCONFLICT SHOULD be used when no other OPAQUE or OPAQUE-NOCONFLICT event can overlap it, otherwise TRANSPARENT SHOULD be used. Format Definition: The property is specified by the following notation: transp = "TRANSP" tranparam ":" transvalue CRLF tranparam = *(";" xparam) transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. / "TRANSPARENT" ;Transparent on busy time searches. / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time ; searches and no other OPAQUE ; or OPAQUE-NOCONFLICT event ; can overlap it. / "OPAQUE-NOCONFLICT" ; Opaque on busy time ; searches and no other OPAQUE ; or OPAQUE-NOCONFLICT event ; can overlap it. ; ;Default value is OPAQUE Example: The following is an example of this property for an event that is transparent or does not block on free/busy time searches: TRANSP:TRANSPARENT The following is an example of this property for an event that is opaque or blocks on free/busy time searches: TRANSP:OPAQUE The following is an example of this property for an event that is opaque or blocks on free/busy time searches plus no other event can overlap it: TRANSP:OPAQUE-NOCONFLICT From owner-ietf-calendar@mail.imc.org Fri Aug 18 17:13: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 RAA08555 for ; Fri, 18 Aug 2000 17:13:13 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA00936 for ietf-calendar-bks; Fri, 18 Aug 2000 13:47:02 -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 NAA00930 for ; Fri, 18 Aug 2000 13:47:01 -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 QAA27920 for ; Fri, 18 Aug 2000 16:46:33 -0400 Received: from cst.ca (cc-1106.int.cst.ca [192.168.1.105]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RAYK41J2; Fri, 18 Aug 2000 16:46:32 -0400 Message-ID: <399DA0A9.A00A7FD7@cst.ca> Date: Fri, 18 Aug 2000 16:46:33 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Subject: Registration of text/calendar MIME property REQUEST-STATUS 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 Note: The changes that were made to this iCAL property: 1) statdesc is now optional 2) more examples were added 3) can be specified in any calendar component Changes needed by CAP. ------------------------------------------------------------------- To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property REQUEST-STATUS Property name: REQUEST-STATUS Purpose: This property defines the status code returned for a scheduling request. Value type: TEXT Property parameters: Non-standard and language property parameters can be specified on this property. Conformance: the property can be specified in any calendar component. Description: This property is used to return status code information related to the processing of an associated iCalendar object. The data type for this property is TEXT. The value consists of a short return status component, a longer return status description component, and optionally a status-specific data component. The components of the value are separated by the SEMICOLON character (US-ASCII decimal 59). The short return status is a PERIOD character (US-ASCII decimal 46) separated 3-tuple of integers. For example, "3.1.1". The successive levels of integers provide for a successive level of status code granularity. The following are initial classes for the return status code. Individual iCalendar object methods will define specific return status codes for these classes. In addition, other classes for the return status code may be defined using the registration process defined later in this memo. |==============+===============================================| | Short Return | Longer Return Status Description | | Status Code | | |==============+===============================================| | 1.xx | Preliminary success. This class of status | | | of status code indicates that the request has | | | request has been initially processed but that | | | completion is pending. | |==============+===============================================| | 2.xx | Successful. This class of status code | | | indicates that the request was completed | | | successfuly. However, the exact status code | | | can indicate that a fallback has been taken. | |==============+===============================================| | 3.xx | Client Error. This class of status code | | | indicates that the request was not successful.| | | The error is the result of either a syntax or | | | a semantic error in the client formatted | | | request. Request should not be retried until | | | the condition in the request is corrected. | |==============+===============================================| | 4.xx | Scheduling Error. This class of status code | | | indicates that the request was not successful.| | | Some sort of error occurred within the | | | calendaring and scheduling service, not | | | directly related to the request itself. | |==============+===============================================| Format Definition: The property is defined by the following notation: rstatus = "REQUEST-STATUS" rstatparam ":" statcode [";" statdesc [";" extdata]] rstatparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparm) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) statcode = 1*DIGIT *("." 1*DIGIT) ;Hierarchical, numeric return status code statdesc = text ;An optional textual status description, content is ;decided by the implementor. May be empty. extdata = text ;Textual exception data. For example, the offending property ;name and value or complete property line. Examples: The following are some possible examples of this property. The COMMA and SEMICOLON separator characters in the property value are BACKSLASH character escaped because they appear in a text value. REQUEST-STATUS:2.0 REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success despite braindead LDAP implementation REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: MAILTO:jsmith@host.com REQUEST-STATUS:3.7;;ATTENDEE:MAILTO:jsmith@host.com REQUEST-STATUS:10.4;Help! That really shouldnt have happened. From owner-ietf-calendar@mail.imc.org Fri Aug 18 19:42: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 TAA10690 for ; Fri, 18 Aug 2000 19:42:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA03410 for ietf-calendar-bks; Fri, 18 Aug 2000 16:25:44 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03406 for ; Fri, 18 Aug 2000 16:25:43 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Fri, 18 Aug 2000 16:25:44 -0700 Message-ID: <399DC5F8.1581CC03@home.royer.com> Date: Fri, 18 Aug 2000 16:25:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Questions and Comments 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 eric@softwarestudio.org wrote: > > Doug, > > Here are some more questions and comments regarding the latest CAP draft. > > 1) Are all the examples in the CAP draft in SQL-MIN format? I'll check. If yes - did you find a bug? > 2) For SQL-MIN, there is apparently no way to seach for components based > on parameter value. Is this intended? If so, I presume that you need to > use the SQL-92 format, but there don't seem to be any examples of its use. Would this suffice if we added this to SQL-MIN: QUERY:SELECT * FROM VEVENT WHERE RECURRENCE-ID >= '20000801T000000Z' AND RECURRENCE-ID <= '20000831T235959Z' AND METHOD = 'CREATE' AND ORGANIZER.SENT-BY = cal-address And change 'colname' to something like: colname = ( "*" / cap-prop / cap-propDotParam ) cap-prop = ; Any valid iCal, iTIP, iMIP or CAP property. cap-propDocParam = cap-prop 1*( "." cap-param) cap-parm = ; Any iCal, iTIP, iMIP or CAP paramater ; valid for the cap-prop used. > 3) If you are allowing any SQL-92 statement that follows the schema, then > it looks like you could return data that is not representable in RFC2445 > format, such as: > > SELECT VALUE_KEY FROM TRANSP WHERE VALUE=OPAQUE > > I'd expect this to return a list of integers if it were issued to a > database. Does CAP automatically translate these value keys into > components? Or, are these disallowed? I'll add a statement something like The query is SQL, however all responses must be in VCALENDAR format. And as VALUE_KEY is not a VCALENDAR object, it would be an invalid query. I have also changed capmin-col to: capmin-col = ; Any property name found in any of the components. ; These are NOT schema names. > 4) What is capmin-coms, referenced in (5) of section 5.1.2, page 30? Typo - should have been capmin-comps. > 5) What is the precedece for AND and OR in WHERE? For instance, how do you > interpret: > > WHERE x AND y OR z The correct answer is what ever the precedience for SQL is. I'll look it up. > 6) In the SQL grammar section, there is no description of colvalue, other > than its use in capmin-cmp, ... Added: colvalue = ; Any value valid for the colname selected. and made: capmin-col = ( ; Any property name found in any of the components. ; These are NOT schema names. / "*" ) > ...and it looks like query-min and capselect-min conflict. Yep - I'll fix. > 7) 7.1.10.1. UPNEXPAND Method > > UPNEXPAND is actually a command, right? Yep - fixed. From owner-ietf-calendar@mail.imc.org Fri Aug 18 23:19: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 XAA14959 for ; Fri, 18 Aug 2000 23:19:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA17586 for ietf-calendar-bks; Fri, 18 Aug 2000 20:05:27 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17579 for ; Fri, 18 Aug 2000 20:05:26 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Fri, 18 Aug 2000 20:05:26 -0700 Message-ID: <399DF976.104B2F3F@home.royer.com> Date: Fri, 18 Aug 2000 20:05:26 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: AUTHENTICATE replies 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 What is the difference between: 6.0 - Failed authentication. 6.1 - Authorization identity refused. --- What is the difference between: 6.2 - Sender aborted authentication, authentication exchange canceled. 6.5 - Authentication exchange canceled. --- 6.7 - Encryption required. Could this be: "MUST use TLSSTART first" ? --- 6.9 - The user is valid but the server does not have an entry in the authentication database for the requested mechanism (e.g., DIGEST-MD5). If the user successfully authenticates using a plain text password, then the back end back end entry will be updated. Note that if the client chooses to fall back to plain text password authentication it should enable an encryption layer or get user-confirmation that a one-time transition is acceptable. What? So if authentication fails, then is this supposed to mean that only PLAIN-TEXT password is supported for this user? If so, then ONLY if TLSSTART has been issued? Then the CUA is supposed to retry using plain text? How is a CS supposed to know to update any kind of authentication information. The CS might not be the authentication authority. --- From owner-ietf-calendar@mail.imc.org Sat Aug 19 02:32:41 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 CAA28473 for ; Sat, 19 Aug 2000 02:32:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA28902 for ietf-calendar-bks; Fri, 18 Aug 2000 23:17:31 -0700 (PDT) Received: from agony.busboom.org (IDENT:root@24-25-201-226.san.rr.com [24.25.201.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA28893 for ; Fri, 18 Aug 2000 23:17:29 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id XAA03905 for ; Fri, 18 Aug 2000 23:17:32 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Fri, 18 Aug 2000 23:17:32 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Re: CAP Questions and Comments In-Reply-To: <399DC5F8.1581CC03@home.royer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 Aug 2000, Doug Royer wrote: > Would this suffice if we added this to SQL-MIN: > > QUERY:SELECT * > FROM VEVENT > WHERE RECURRENCE-ID >= '20000801T000000Z' > AND RECURRENCE-ID <= '20000831T235959Z' > AND METHOD = 'CREATE' > AND ORGANIZER.SENT-BY = cal-address In this case, an implementation has to distinguish between property.parameter (ORGANIZER.SENT-BY) and component.property (VALARM.TRIGGER). Ick. I like the simplicity of SQL-MIN, and would be happier if it did not allow for searching by parameter, instead requiring SQL-92 to search for parameters. ( Sorry if my question was leading ) Some SQL-92 examples would be really nice, and perhaps an explaination of why there are two variants. > I'll add a statement something like > > The query is SQL, however all responses must be in VCALENDAR > format. And as VALUE_KEY is not a VCALENDAR object, it would > be an invalid query. > And note what response code is generated when the query is not valid. eric. From owner-ietf-calendar@mail.imc.org Sun Aug 20 03:16: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 DAA01161 for ; Sun, 20 Aug 2000 03:16:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA24855 for ietf-calendar-bks; Sun, 20 Aug 2000 00:00:06 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24829 for ; Sun, 20 Aug 2000 00:00:03 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Sat, 19 Aug 2000 23:59:57 -0700 Message-ID: <399F81EC.23853F3D@home.royer.com> Date: Sat, 19 Aug 2000 23:59:57 -0700 From: Doug Royer Reply-To: Doug@Royer.com X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property GEO_BOUNDS 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 Property name: GEO_BOUNDS Property purpose: To define the geographic bounds of a area. Property value type: FLOAT Property parameter: Non-standard parameters can be specified on this property. Conformance: VTIMEZONE plus other components that can use GEO. Description: GEO_BOUNDS is a list of latitude and longitude points (geovalue) that describe a bounding polygon for a geographic area. It must consist if at least three points. The polygon is closed by a line between the last and first point. Each point is a geovalue. Format definition: geo_bounds = "GEO_BOUNDS" bounds-param ":" latlon-sets bounds-param = *( ";" xparam ) latlon-sets = geovalue *( "," latlon-sets ) geovalue = ; As defined in RFC2445 xparam = ; As defined in RFC2445 float = ; As defined in RFC2445 Examples: GEO_BOUNDS:21.17;157.51,21.18;157.50,21.18;157.11 From owner-ietf-calendar@mail.imc.org Sun Aug 20 03:19:38 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 DAA01324 for ; Sun, 20 Aug 2000 03:19:37 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA24861 for ietf-calendar-bks; Sun, 20 Aug 2000 00:00: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 AAA24856 for ; Sun, 20 Aug 2000 00:00:06 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA10175 for ietf-calendar@imc.org; Sun, 20 Aug 2000 00:00:04 -0700 (PDT) Date: Sun, 20 Aug 2000 00:00:04 -0700 (PDT) From: Doug Royer Message-Id: <200008200700.AAA10175@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 draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) 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! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ 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 Tuesday discussion: DONE Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. DONE Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). DONE Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) DONE Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. DONE Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text DONE Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 DONE Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. DONE Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Sun Aug 20 20:57: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 UAA11670 for ; Sun, 20 Aug 2000 20:57:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA07265 for ietf-calendar-bks; Sun, 20 Aug 2000 17:43:46 -0700 (PDT) Received: from agony.busboom.org (IDENT:root@24-25-201-226.san.rr.com [24.25.201.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07261 for ; Sun, 20 Aug 2000 17:43:44 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id RAA11876; Sun, 20 Aug 2000 17:42:52 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Sun, 20 Aug 2000 17:42:51 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Doug@Royer.com cc: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS In-Reply-To: <399F81EC.23853F3D@home.royer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 19 Aug 2000, Doug Royer wrote: > > Property name: GEO_BOUNDS > > Property purpose: To define the geographic bounds of a area. What is the motivation for this registration? Can you give a scenario where it is required? I can't think of any case where this information must be in machine readable form? From owner-ietf-calendar@mail.imc.org Sun Aug 20 22:05:41 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 WAA13087 for ; Sun, 20 Aug 2000 22:05:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA13367 for ietf-calendar-bks; Sun, 20 Aug 2000 18:51:09 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA13360 for ; Sun, 20 Aug 2000 18:51:07 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Sun, 20 Aug 2000 18:51:16 -0700 Message-ID: <39A08B13.C28DF15D@home.royer.com> Date: Sun, 20 Aug 2000 18:51:16 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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 Eric Busboom wrote: > > On Sat, 19 Aug 2000, Doug Royer wrote: > > > > > Property name: GEO_BOUNDS > > > > Property purpose: To define the geographic bounds of a area. > > What is the motivation for this registration? Can you give a scenario > where it is required? I can't think of any case where this information > must be in machine readable form? One of the other things I am working on is time zones. For a global registry, given you have your location, or some location. Now you can find your time zone or the time zone of a location. It is not a required property for any component. -Doug From owner-ietf-calendar@mail.imc.org Mon Aug 21 02:04: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 CAA27420 for ; Mon, 21 Aug 2000 02:04:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA26988 for ietf-calendar-bks; Sun, 20 Aug 2000 22:50:59 -0700 (PDT) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26983 for ; Sun, 20 Aug 2000 22:50:57 -0700 (PDT) Received: from [32.100.79.78] ([32.100.79.78]) by prserv.net (out1) with SMTP id <2000082105501525202i90mie>; Mon, 21 Aug 2000 05:50:15 +0000 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Thu, 03 Aug 2000 23:00:02 -0700 Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS From: Rives McDow To: Message-ID: In-Reply-To: <39A08B13.C28DF15D@home.royer.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA26984 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dear Doug, It has been a while since we corresponded, and when I saw this exchange, I thought it would be good for us to communicate again. Have you thought about the implementation you brought up in the email below? I am interested to know if you are planning on developing this yourself. I feel pretty certain that I can supply this at a cost below what you will be able to develop it for, and with several advantages. Last week the man who is responsible for Appendix F from IATA came to meet with me here. We looked over the requirements of the aviation industry, and have come up with a plan to implement the methodology used in GTS to track and publish the time changes for the industry, expanding the current list based system to a true GIS. I am in contact with the people at ICAO and the Reed Travel Group, and am planning a meeting with them later this year in London. Our aim is to get everyone on the same page, and with accurate information. You and I had discussed this earlier this year, before one of the IETF conferences, I believe in Australia. I didn't hear from you after the conference, and didn't know that you still have a geo-referenced method in mind until the email below. If you want to pursue this yourself so that you have your own solution, I don't see any difficulty with that, however, I think that it would make a lot of sense to coordinate our efforts. I am in the process of getting all the time zone data from the initiation of time zones in the 1800's until present in a geo-coordinated database. This is a pretty big undertaking, and I don't think that it will be that practical to implement in the embedded systems that are my primary interest. However, it may be something that would interest people using past historical data of the Olsen archive. I can't quite follow why the historical data is so important to anyone but astrologers and insurance adjusters, but I guess that there is a reason. Is your interest in historical or current time zones? Let me know if you are interested in working together to coordinate our efforts, and how that would best be done. Sincerely, Rives McDow > From: Doug Royer > Reply-To: ietf-calendar@imc.org > Date: Sun, 20 Aug 2000 18:51:16 -0700 > To: ietf-calendar@imc.org > Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS > > Eric Busboom wrote: >> >> On Sat, 19 Aug 2000, Doug Royer wrote: >> >>> >>> Property name: GEO_BOUNDS >>> >>> Property purpose: To define the geographic bounds of a area. >> >> What is the motivation for this registration? Can you give a scenario >> where it is required? I can't think of any case where this information >> must be in machine readable form? > > One of the other things I am working on is time zones. > For a global registry, given you have your location, or > some location. Now you can find your time zone or the > time zone of a location. It is not a required property > for any component. > > -Doug From owner-ietf-calendar@mail.imc.org Mon Aug 21 11:09: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 LAA02227 for ; Mon, 21 Aug 2000 11:09:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA09833 for ietf-calendar-bks; Mon, 21 Aug 2000 07:43:55 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09829 for ; Mon, 21 Aug 2000 07:43:54 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Mon, 21 Aug 2000 07:44:04 -0700 Message-ID: <39A14033.4255129B@home.royer.com> Date: Mon, 21 Aug 2000 07:44:03 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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 Rives McDow wrote: > > Dear Doug, > > It has been a while since we corresponded, and when I saw this exchange, > I thought it would be good for us to communicate again. > > Have you thought about the implementation you brought up in the email > below? I am interested to know if you are planning on developing this > yourself. I feel pretty certain that I can supply this at a cost > below what you will be able to develop it for, and with several > advantages. I have no plans to fill in the data. I am just proposing a standard way for applications to express the data. -Doug From owner-ietf-calendar@mail.imc.org Mon Aug 21 11:21: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 LAA02604 for ; Mon, 21 Aug 2000 11:21:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10069 for ietf-calendar-bks; Mon, 21 Aug 2000 07:56:39 -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 HAA10064 for ; Mon, 21 Aug 2000 07:56:38 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA01735 for ; Mon, 21 Aug 2000 10:58:22 -0400 Message-ID: <39A1438D.AE3F5FB6@ecal.com> Date: Mon, 21 Aug 2000 10:58:21 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS References: <39A08B13.C28DF15D@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > One of the other things I am working on is time zones. > For a global registry, given you have your location, or > some location. Now you can find your time zone or the > time zone of a location. Most of the time, yes. Are there any weird cases out there, with overlapping time zones? For example, a country where some religious minority doesn't observe DST; then which time zone you want will depend on the user's religion. Or suppose you're at sea, on a course that takes you in and out of international waters. In international waters, there won't be any authority issuing time zone rules; in national waters, there will be, but you won't really care; you'll want to keep a consistent clock (particularly if you're going more or less north-south). So what time zone you follow will probably be up to the captain of the ship. (Extra Bonus Complication: consider nations such as Libya, which claim sovereignty out to 100 miles, even though nobody listens. The borders reported by your timezone registry may have to be localized depending on what nation the user is in.) I suppose those can be handled by returning multiple values, though, and letting the user pick. We just need to make sure that nobody builds a VEVENT which contains a LOCATION but no TZID, and expects the recipient to look it up by location. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Te audire no possum. Musa sapientum fixa est in| |francis@ecal.com|aure. | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 21 11:23: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 LAA02654 for ; Mon, 21 Aug 2000 11:23:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10217 for ietf-calendar-bks; Mon, 21 Aug 2000 08:02:04 -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 IAA10213 for ; Mon, 21 Aug 2000 08:02:03 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA01753; Mon, 21 Aug 2000 11:03:47 -0400 Message-ID: <39A144D3.A4A18D9B@ecal.com> Date: Mon, 21 Aug 2000 11:03:47 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: AUTHENTICATE replies References: <399DF976.104B2F3F@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > 6.9 - The user is valid but the server does not have an > entry in the authentication database for the requested > mechanism (e.g., DIGEST-MD5). If the user successfully > authenticates using a plain text password, then the > back end back end entry will be updated. > Note that if the client chooses to fall back to plain text password > authentication it should enable an encryption layer > or get user-confirmation that a one-time transition > is acceptable. > > What? > So if authentication fails, then is this supposed > to mean that only PLAIN-TEXT password is supported for > this user? I think it just means that the specified mechanism is not configured. The CUA could try other mechanisms before falling back to PLAIN-TEXT. > If so, then ONLY if TLSSTART has been issued? Not necessarily. A good CUA would issue TLSSTART and fall back to PLAIN-TEXT; a lazy one would fall back to PLAIN-TEXT and issue TLSSTART only if it got a 6.7. > How is a CS supposed to know to update any kind > of authentication information. The CS might not > be the authentication authority. That is a good point. I would suggest the text should be changed to say that updating the backend is recommended where possible, but not required. (It can't *really* be required by the protocol anyway, since the CUA can't assume that the updated authentication information will still be there the next time it comes along.) Another reasonable CS behavior might be to send email to the admin saying that the user's DIGEST-MD5 (or whatever) authentication info needs to be entered. (Then again, that could be a security risk if someone else can read that email.) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"How quietly do you think we can nail these back| |francis@ecal.com|in?" --Calvin | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 21 11:48: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 LAA03390 for ; Mon, 21 Aug 2000 11:48:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10623 for ietf-calendar-bks; Mon, 21 Aug 2000 08:11:48 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10619 for ; Mon, 21 Aug 2000 08:11:46 -0700 (PDT) Received: from grand-central-station.MIT.EDU (GRAND-CENTRAL-STATION.MIT.EDU [18.69.0.34]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA17507 for ; Mon, 21 Aug 2000 11:12:02 -0400 (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 LAA29677 for ; Mon, 21 Aug 2000 11:11:58 -0400 (EDT) Received: from miles-davis (MILES-DAVIS.MIT.EDU [18.18.1.113]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id LAA09218 for ; Mon, 21 Aug 2000 11:11:56 -0400 (EDT) Message-Id: <4.2.0.58.20000821110243.03495330@po12.mit.edu> X-Sender: pbh@po12.mit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 21 Aug 2000 11:11:53 -0400 To: ietf-calendar@imc.org From: "Paul B. Hill" Subject: Re: CAP: AUTHENTICATE replies In-Reply-To: <399DF976.104B2F3F@home.royer.com> 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: At 08:05 PM 8/18/2000 -0700, Doug Royer wrote: >What is the difference between: > > 6.0 - Failed authentication. > 6.1 - Authorization identity refused. Authentication - who you are Authorization - what you can do I may be able to authenticate as Doug, but the server might not allow me to then assert an authorization identity of Frank. How the authorization identity is supported and enforced is implementation specific. >--- > >What is the difference between: > >6.2 - Sender aborted authentication, authentication exchange canceled. >6.5 - Authentication exchange canceled. I assume that 6.2 indicates the client initiation the cancellation and 6.5 indicates that the server initiated the cancellation. 6.5 would also indicate that the client and server cannot agree on mutually acceptable authentication mechanism. >--- > >6.7 - Encryption required. > >Could this be: "MUST use TLSSTART first" ? No. Suppose you are using the SASL GSSAPI binding and the underlying mechanism is Kerberos 5. That mechanism might use DES or DES3. You don't want the overhead of encrpting the stream twice with two different systems. Nor do you want to start the channel with TLS and then later negotiate TLS off. >--- > >6.9 - The user is valid but the server does not have an > entry in the authentication database for the requested > mechanism (e.g., DIGEST-MD5). If the user successfully > authenticates using a plain text password, then the > back end back end entry will be updated. > Note that if the client chooses to fall back to plain text password > authentication it should enable an encryption layer > or get user-confirmation that a one-time transition > is acceptable. > >What? >So if authentication fails, then is this supposed >to mean that only PLAIN-TEXT password is supported for >this user? If so, then ONLY if TLSSTART has been issued? >Then the CUA is supposed to retry using plain text? >How is a CS supposed to know to update any kind >of authentication information. The CS might not >be the authentication authority. Doesn't sound like anything I wrote. I'll try to find the time to back over this section :) Paul From owner-ietf-calendar@mail.imc.org Mon Aug 21 13:17: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 NAA04886 for ; Mon, 21 Aug 2000 13:17:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17382 for ietf-calendar-bks; Mon, 21 Aug 2000 09:15:00 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17376 for ; Mon, 21 Aug 2000 09:14:58 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id JAA00650 for ; Mon, 21 Aug 2000 09:15:12 -0700 (PDT) Message-ID: <39A1558F.DB7828D4@home.royer.com> Date: Mon, 21 Aug 2000 09:15:11 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS References: <39A08B13.C28DF15D@home.royer.com> <39A1438D.AE3F5FB6@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: > > Doug Royer wrote: > > > One of the other things I am working on is time zones. > > For a global registry, given you have your location, or > > some location. Now you can find your time zone or the > > time zone of a location. > > Most of the time, yes. Are there any weird cases out there, with > overlapping time zones? For example, a country where some > religious minority doesn't observe DST; then which time zone you > want will depend on the user's religion. Correct time zones can overlap. If you get > 1, choose. > Or suppose you're at sea, on a course that takes you in and out of > international waters. In international waters, there won't be any > authority issuing time zone rules; in national waters, there will > be, but you won't really care; you'll want to keep a consistent > clock (particularly if you're going more or less north-south). > So what time zone you follow will probably be up to the captain > of the ship. (Extra Bonus Complication: consider nations such as > Libya, which claim sovereignty out to 100 miles, even though nobody > listens. The borders reported by your timezone registry may have > to be localized depending on what nation the user is in.) I have not made an assertion that everyplace on earth has a time zone. I have no idea if it is true or false. > I suppose those can be handled by returning multiple values, > though, and letting the user pick. We just need to make sure > that nobody builds a VEVENT which contains a LOCATION but no TZID, > and expects the recipient to look it up by location. Correct - I have not proposed anything of the kind. I assume you meant GEO and not LOCATION, as LOCATION is TEXT. The rules for when to use TZID will not change. I do expect in the future that when someone builds a VEVENT they will be able to pick a TZID given the GEO before sending out the VEVENT. -Doug From owner-ietf-calendar@mail.imc.org Mon Aug 21 16:40: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 QAA09027 for ; Mon, 21 Aug 2000 16:40:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA22258 for ietf-calendar-bks; Mon, 21 Aug 2000 12:51:55 -0700 (PDT) Received: from arista.iris.com ([198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22252 for ; Mon, 21 Aug 2000 12:51:53 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: George Babics Cc: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS X-Mailer: Lotus Notes Build V60_08132000 August 13, 2000 Message-ID: Date: Mon, 21 Aug 2000 15:50:43 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/21/2000 03:52:12 PM, Serialize complete at 08/21/2000 03:52:12 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006D0F5985256942_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D0F5985256942_= Content-Type: text/plain; charset="us-ascii" George proposed: >Note: The changes that were made to this iCAL property: > 1) statdesc is now optional > 2) more examples were added > 3) can be specified in any calendar component I have a concern about #1. If the VERSION is still 2.0 then any product that parses the REQUEST-STATUS of RFC 2445 will not find what it expects and may treat it as a bad property. Since this change was "needed by CAP" then perhaps someone whose scribing can please explain WHY that particular change is necessary for CAP?? FWIW: The other 2 reasons are fine (albeit Im not sure why you would want REQUEST-STATUS in a VTIMEZONE...) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D0F5985256942_= Content-Type: text/html; charset="us-ascii"
George proposed:

>Note: The changes that were made to this iCAL property:
>      1) statdesc is now optional
>      2) more examples were added
>      3) can be specified in any calendar component

I have a concern about #1.  If the VERSION is still 2.0 then any product that parses the REQUEST-STATUS of RFC 2445 will not find what it expects and may treat it as a bad property.  Since this change was "needed by CAP" then perhaps someone whose scribing can please explain WHY that particular change is necessary for CAP??

FWIW: The other 2 reasons are fine (albeit Im not sure why you would want REQUEST-STATUS in a VTIMEZONE...)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006D0F5985256942_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 21 17:00: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 RAA09340 for ; Mon, 21 Aug 2000 17:00:11 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA22346 for ietf-calendar-bks; Mon, 21 Aug 2000 12:55:53 -0700 (PDT) Received: from arista.iris.com ([198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22340 for ; Mon, 21 Aug 2000 12:55:51 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: George Babics Cc: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Build V60_08132000 August 13, 2000 Message-ID: Date: Mon, 21 Aug 2000 15:55:26 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/21/2000 03:56:10 PM, Serialize complete at 08/21/2000 03:56:10 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006D7DD285256942_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D7DD285256942_= Content-Type: text/plain; charset="us-ascii" George proposed the following ABNF change: / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time ; searches and no other OPAQUE ; or OPAQUE-NOCONFLICT event ; can overlap it. / "OPAQUE-NOCONFLICT" ; Opaque on busy time ; searches and no other OPAQUE ; or OPAQUE-NOCONFLICT event ; can overlap it. Im curious why for TRANSPARENT-NOCONFLICT it does not also prohibit overlapping TRANSPARENT-NOCONFLICT events (entries really, vToDos count too yes??). Also, why does OPAQUE-NOCONFLICT not preclue TRANSPARENT-NOCONFLICT entries as well?? Im assuming that a *-NOCONFLICT should not allow any overlaps unless it is _just_ TRANSPARENT; just the text in the ABNF is not quite there... If the intent was NOT to do this then how come?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D7DD285256942_= Content-Type: text/html; charset="us-ascii"
George proposed the following ABNF change:

               / "TRANSPARENT-NOCONFLICT"  ; Transparent on busy time
                                           ; searches and no other OPAQUE
                                           ; or OPAQUE-NOCONFLICT event
                                           ; can overlap it.

               / "OPAQUE-NOCONFLICT"       ; Opaque on busy time
                                           ; searches and no other OPAQUE
                                           ; or OPAQUE-NOCONFLICT event
                                           ; can overlap it.

Im curious why for TRANSPARENT-NOCONFLICT it does not also prohibit overlapping TRANSPARENT-NOCONFLICT events (entries really, vToDos count too yes??).  Also, why does OPAQUE-NOCONFLICT not preclue TRANSPARENT-NOCONFLICT entries as well??

Im assuming that a *-NOCONFLICT should not allow any overlaps unless it is _just_ TRANSPARENT; just the text in the ABNF is not quite there...  If the intent was NOT to do this then how come??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006D7DD285256942_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 21 17:43: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 RAA10049 for ; Mon, 21 Aug 2000 17:43:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23504 for ietf-calendar-bks; Mon, 21 Aug 2000 14:02:52 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23500 for ; Mon, 21 Aug 2000 14:02:50 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id OAA01370 for ; Mon, 21 Aug 2000 14:03:06 -0700 (PDT) Message-ID: <39A19909.ECA8D038@home.royer.com> Date: Mon, 21 Aug 2000 14:03:05 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS 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: > > George proposed: > > >Note: The changes that were made to this iCAL property: > > 1) statdesc is now optional > > 2) more examples were added > > 3) can be specified in any calendar component > > I have a concern about #1. If the VERSION is still 2.0 then any product > that parses the REQUEST-STATUS of RFC 2445 will not find what it expects > and may treat it as a bad property. Since this change was "needed by > CAP" then perhaps someone whose scribing can please explain WHY that > particular change is necessary for CAP?? Remember the, what language should it be in, debate? Its one of the bugs in iCalendar what was discussed (a lot). How about one SPACE character for when it does not apply? > FWIW: The other 2 reasons are fine (albeit Im not sure why you would want > REQUEST-STATUS in a VTIMEZONE...) Any query to a CAP server needs to be able to return a status. You can query for a VTIMEZONE. -Doug From owner-ietf-calendar@mail.imc.org Mon Aug 21 17:52: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 RAA10110 for ; Mon, 21 Aug 2000 17:52:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23567 for ietf-calendar-bks; Mon, 21 Aug 2000 14:06:27 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23563 for ; Mon, 21 Aug 2000 14:06:26 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id OAA01377 for ; Mon, 21 Aug 2000 14:06:42 -0700 (PDT) Message-ID: <39A199E1.9BD3D69C@home.royer.com> Date: Mon, 21 Aug 2000 14:06:41 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP 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: > > George proposed the following ABNF change: > > / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time > ; searches and no other OPAQUE > ; or OPAQUE-NOCONFLICT event > ; can overlap it. > > / "OPAQUE-NOCONFLICT" ; Opaque on busy time > ; searches and no other OPAQUE > ; or OPAQUE-NOCONFLICT event > ; can overlap it. > > Im curious why for TRANSPARENT-NOCONFLICT it does not also prohibit > overlapping TRANSPARENT-NOCONFLICT events (entries really, vToDos count > too yes??). Also, why does OPAQUE-NOCONFLICT not preclue > TRANSPARENT-NOCONFLICT entries as well?? > > Im assuming that a *-NOCONFLICT should not allow any overlaps unless it > is _just_ TRANSPARENT; just the text in the ABNF is not quite there... Your correct *-NOCONFLICT should not allow any overlaps. TRANSPARENT just has todo with if it shows up in VFREBUSY searches. From owner-ietf-calendar@mail.imc.org Mon Aug 21 18:06: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 SAA10239 for ; Mon, 21 Aug 2000 18:06:55 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA23992 for ietf-calendar-bks; Mon, 21 Aug 2000 14:31:32 -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 OAA23988 for ; Mon, 21 Aug 2000 14:31:31 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Mon, 21 Aug 2000 17:31:42 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/21/2000 05:31:49 PM, Serialize complete at 08/21/2000 05:31:49 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00764E6985256942_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00764E6985256942_= Content-Type: text/plain; charset="us-ascii" Doug in part wrote: >> Most of the time, yes. Are there any weird cases out there, with >> overlapping time zones? For example, a country where some >> religious minority doesn't observe DST; then which time zone you >> want will depend on the user's religion. > >Correct time zones can overlap. If you get > 1, choose. I was with ya up until the "If you get > 1, choose" bit. This is a recipe for interop disaster/nightmare. If I use CUA 1 I get 1 set of date/times and if I use CUA 2 to view the same entry I get another because it guessed differently?!? Argh! Dont do it!! Propose a methodology to resolve this so we dont have another multipart/* scenario on our hands at the next CalConnect. Otherwise this just adds mud to the water instead of filtering the interop waters... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00764E6985256942_= Content-Type: text/html; charset="us-ascii"
Doug in part wrote:
>> Most of the time, yes.  Are there any weird cases out there, with
>> overlapping time zones? For example, a country where some
>> religious minority doesn't observe DST; then which time zone you
>> want will depend on the user's religion.
>
>Correct time zones can overlap. If you get > 1, choose.

I was with ya up until the "If you get > 1, choose" bit.  This is a recipe for interop disaster/nightmare.  If I use CUA 1 I get 1 set of date/times and if I use CUA 2 to view the same entry I get another because it guessed differently?!?  Argh!  Dont do it!!  

Propose a methodology to resolve this so we dont have another multipart/* scenario on our hands at the next CalConnect.  Otherwise this just adds mud to the water instead of filtering the interop waters...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00764E6985256942_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 21 18:27:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10323 for ; Mon, 21 Aug 2000 18:27:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA24284 for ietf-calendar-bks; Mon, 21 Aug 2000 14:49:50 -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 OAA24279 for ; Mon, 21 Aug 2000 14:49:44 -0700 (PDT) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: Request-Status on vtimezone X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: Date: Mon, 21 Aug 2000 17:49:52 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 08/21/2000 05:50:05 PM, Serialize complete at 08/21/2000 05:50:05 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0077F8D185256942_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077F8D185256942_= Content-Type: text/plain; charset="us-ascii" Bruce wrote: >> > FWIW: The other 2 reasons are fine (albeit Im not sure why you would want > REQUEST-STATUS in a VTIMEZONE...) Doug wrote: >> Any query to a CAP server needs to be able to return a status. You can query for a VTIMEZONE. Pat wrote: With all the confusion about timezones (or "where am I today") don't you really want to query for a timezone so you can have an accurate view of what the real time is? Then my client or implementation can take care of how it shows me the data? Correct? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0077F8D185256942_= Content-Type: text/html; charset="us-ascii"
Bruce wrote:
>> > FWIW: The other 2 reasons are fine (albeit Im not sure why you would want
> REQUEST-STATUS in a VTIMEZONE...)

Doug wrote:
>> Any query to a CAP server needs to be able to return a status.
You can query for a VTIMEZONE.

Pat wrote:

With all the confusion about timezones (or "where am I today") don't you really want to query for a timezone so you can have an accurate view of what the real time is? Then my client or implementation can take care of how it shows me the data? Correct?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0077F8D185256942_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 21 18:37:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10446 for ; Mon, 21 Aug 2000 18:37:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA24344 for ietf-calendar-bks; Mon, 21 Aug 2000 14:52:39 -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 OAA24340 for ; Mon, 21 Aug 2000 14:52:37 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id RAA03622 for ; Mon, 21 Aug 2000 17:54:23 -0400 Message-ID: <39A1A50F.35644C82@ecal.com> Date: Mon, 21 Aug 2000 17:54:23 -0400 From: John Stracke X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS References: <39A08B13.C28DF15D@home.royer.com> <39A1438D.AE3F5FB6@ecal.com> <39A1558F.DB7828D4@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Correct time zones can overlap. If you get > 1, choose. [...] > I have not made an assertion that everyplace on earth > has a time zone. I have no idea if it is true or false. Looking back, I think I read it into "Now you can find your time zone or the time zone of a location."--but that wasn't part of the actual registration. > I assume you meant GEO and not LOCATION, as LOCATION is TEXT. Yes, sorry. > The rules for when to use TZID will not change. Right; I didn't see any text that would change TZID--but it could be thought to be a logical next step; I just wanted to forestall it. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |Dave Barry for President! He'll Keep Dan Quayle.| |francis@ecal.com|(OK, it's old) | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 21 18:40:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10512 for ; Mon, 21 Aug 2000 18:40:07 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA24371 for ietf-calendar-bks; Mon, 21 Aug 2000 14:53:50 -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 OAA24366 for ; Mon, 21 Aug 2000 14:53:48 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Mon, 21 Aug 2000 17:54:01 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/21/2000 05:54:06 PM, Serialize complete at 08/21/2000 05:54:07 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/21/2000 05:54:07 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 007859A585256942_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007859A585256942_= Content-Type: text/plain; charset="us-ascii" Doug thoughtfully replied: >Its one >of the bugs in iCalendar what was discussed (a lot). We did cover it but I do not recall it being a bug; rather than an oversight (even w/UTF8 as the character set). In any case, _how_ does CAP need it?? If there is no CAP reason for it, Im dubious about making this change that is not backwards compatible. >How about one SPACE character for when it does not apply? The contents are not mandated; just the presence of contents. As such, there is no reason that a single ASCII SPACE character could not be used. For the 2.0 "Success" case this may be ok but for all the other the non-2.0 cases where the statdesc may be somewhat useful, a SPACE is not going to cut it. Are you saying that the 2.0 case justifys sending a SPACE only for this and as such it should be optional for all cases (and hence this proposed change)?? There are plenty of other statcodes besides 2.0 to justify having it still. This is NON BACKWARDS COMPATIBLE change for 1 particular case (or maybe handful of particular cases that have yet to be shown) that I would like justified before we just do it. Before we make such a change compelling reasons should be demonstrated! If you really want to fix things, lets talk about RRULEs... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007859A585256942_= Content-Type: text/html; charset="us-ascii"
Doug thoughtfully replied:
>Its one
>of the bugs in iCalendar what was discussed (a lot).
We did cover it but I do not recall it being a bug; rather than an oversight (even w/UTF8 as the character set).  In any case, _how_ does CAP need it??  If there is no CAP reason for it, Im dubious about making this change that is not backwards compatible.

>How about one SPACE character for when it does not apply?

The contents are not mandated; just the presence of contents. As such, there is no reason that a single ASCII SPACE character could not be used.  For the 2.0 "Success" case this may be ok but for all the other the non-2.0 cases where the statdesc may be somewhat useful, a SPACE is not going to cut it.  Are you saying that the 2.0 case justifys sending a SPACE only for this and as such it should be optional for all cases (and hence this proposed change)??

There are plenty of other statcodes besides 2.0 to justify having it still.  This is NON BACKWARDS COMPATIBLE change for 1 particular case (or maybe handful of particular cases that have yet to be shown) that I would like justified before we just do it.  Before we make such a change compelling reasons should be demonstrated!

If you really want to fix things, lets talk about RRULEs...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007859A585256942_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 21 19:14: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 TAA10891 for ; Mon, 21 Aug 2000 19:14:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA24953 for ietf-calendar-bks; Mon, 21 Aug 2000 15:23:46 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24949 for ; Mon, 21 Aug 2000 15:23:45 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id PAA01540 for ; Mon, 21 Aug 2000 15:24:01 -0700 (PDT) Message-ID: <39A1AC00.7AF6763C@home.royer.com> Date: Mon, 21 Aug 2000 15:24:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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 in part wrote: > >> Most of the time, yes. Are there any weird cases out there, with > >> overlapping time zones? For example, a country where some > >> religious minority doesn't observe DST; then which time zone you > >> want will depend on the user's religion. > > > >Correct time zones can overlap. If you get > 1, choose. > > I was with ya up until the "If you get > 1, choose" bit. This is a > recipe for interop disaster/nightmare. If I use CUA 1 I get 1 set of > date/times and if I use CUA 2 to view the same entry I get another > because it guessed differently?!? Argh! Dont do it!! As you recall from RFC2445-7, a VTIMEZONE MUST be included in a VCALENDAR when any component uses a TZID. Adding GEO_BOUNDRY simply specifies (if included) in addition to what alredy MUST be sent, the physical boundry of the TZID supplied. The only time a user must choose is when a CUA would query a CS to get a TZID or list of TZID's to use. If they get > 1, then the CU or CUA chooses which TZID MUST be sent with the object. One VTIMEZONE for each unique TZID. I have not proposed eliminating a VTIMEZONE as a MUST in a VCALENDAR. From owner-ietf-calendar@mail.imc.org Mon Aug 21 19:56: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 TAA11212 for ; Mon, 21 Aug 2000 19:56:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA26455 for ietf-calendar-bks; Mon, 21 Aug 2000 16:43:57 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26451 for ; Mon, 21 Aug 2000 16:43:56 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id QAA01847 for ; Mon, 21 Aug 2000 16:44:12 -0700 (PDT) Message-ID: <39A1BECB.98490223@home.royer.com> Date: Mon, 21 Aug 2000 16:44:11 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS 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: > >How about one SPACE character for when it does not apply? > > The contents are not mandated; just the presence of contents. As such, > there is no reason that a single ASCII SPACE character could not be used. > For the 2.0 "Success" case this may be ok but for all the other the > non-2.0 cases where the statdesc may be somewhat useful, a SPACE is not > going to cut it. No text was mandaded for non-2.0 cases, so why is SPACE invalid? > Are you saying that the 2.0 case justifys sending a > SPACE only for this and as such it should be optional for all cases (and > hence this proposed change)?? Noting in RFC2445 said what was to be sent. No format, no data, nothing. So a single SPACE is valid per RFC2445 now. When is it not valid? -Doug From owner-ietf-calendar@mail.imc.org Mon Aug 21 21:22: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 VAA11796 for ; Mon, 21 Aug 2000 21:22:54 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA27795 for ietf-calendar-bks; Mon, 21 Aug 2000 18:02: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 SAA27791; Mon, 21 Aug 2000 18:02:35 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA19863; Mon, 21 Aug 2000 21:04:16 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA06658; Mon, 21 Aug 2000 21:02:22 -0400 (EDT) To: George Babics Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 21 Aug 2000 21:01:59 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/21/2000 09:01:59 PM, Serialize complete at 08/21/2000 09:01:59 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0005B1C485256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0005B1C485256943_= Content-Type: text/plain; charset="us-ascii" George: An interesting suggested change to the TRANSP property in iCalendar. However, I have some concerns with the suggested proposal. TRANSP semantics in RFC 2445 are specific to whether a VEVENT calendar component creates a busy time interval or not. It has current no semantics that indicate whether overlapping or "conflicting" VEVENT intervals can be generated. That is, the semantics for TRANSP are singular and orthogonal to any other semantics. Your proposal would create a "side effect" by overloading the TRANSParency property with semantics for specifying whether overlapping events might also be allowed on an event. Creating side effects is not considered to be a good engineering practice. It certainly creates implementation complexity. In past CAP discussions about this idea, it was noted by some that testing for an overlap state is difficult to test for as the calendar data base grows in size and is also inefficient in such large databases, leading to performance considerations. There are other problems too. There is also the scenario where overlap already exists between two existing events (e.g., event "A" and "B"). Now if a proposed event "C" that specifies an event interval happens to overlap the event intervals for events "A" and "B", how is a request for "no overlap" to be enforced? Is the event creation to fail? Or is the event to be created but with a non-fatal exception that an overlap already exists? Or is it okay for an implementation to take an "implementation dependent" approach to "overlap enforcement"? These questions need to be answered prior to addressing this proposal. This raises the additional concern whether this extension would ever be widely implemented. If not, why are we proposing it for iCalendar? The proposed standard can't progress to draft standard until we see widespread implementation of the complete set of iCalendar features. Earlier, I had remembered CAP conversations about creating a new property (e.g., NOCONFLICTS) that would be specified on an event that wanted to prevent such overlapping events. What happened to this design approach. Whether an individual VEVENT creates busy time should remain an independent property from whether overlapping or "conflicting" VEVENT calendar components are allowed within a given time interval. Don't others see the problems with this proposal, as it current is written, too? -- Frank --=_alternative 0005B1C485256943_= Content-Type: text/html; charset="us-ascii"
George:

An interesting suggested change to the TRANSP property in iCalendar. However, I have some concerns with the suggested proposal.

TRANSP semantics in RFC 2445 are specific to whether a VEVENT calendar component creates a busy time interval or not. It has current no semantics that indicate whether overlapping or "conflicting" VEVENT intervals can be generated. That is, the semantics for TRANSP are singular and orthogonal to any other semantics.

Your proposal would create a "side effect" by overloading the TRANSParency property with semantics for specifying whether overlapping events might also be allowed on an event. Creating side effects is not considered to be a good engineering practice. It certainly creates implementation complexity.

In past CAP discussions about this idea, it was noted by some that testing for an overlap state is difficult to test for as the calendar data base grows in size and is also inefficient in such large databases, leading to performance considerations. There are other problems too.

There is also the scenario where overlap already exists between two existing events (e.g., event "A" and "B"). Now if a proposed event "C" that specifies an event interval happens to overlap the event intervals for events "A" and "B", how is a request for "no overlap" to be enforced? Is the event creation to fail? Or is the event to be created but with a non-fatal exception that an overlap already exists? Or is it okay for an implementation to take an "implementation dependent" approach to "overlap enforcement"? These questions need to be answered prior to addressing this proposal.

This raises the additional concern whether this extension would ever be widely implemented. If not, why are we proposing it for iCalendar? The proposed standard can't progress to draft standard until we see widespread implementation of the complete set of iCalendar features.

Earlier, I had remembered CAP conversations about creating a new property (e.g., NOCONFLICTS) that would be specified on an event that wanted to prevent such overlapping events. What happened to this design approach.

Whether an individual VEVENT creates busy time should remain an independent property from whether overlapping or "conflicting" VEVENT calendar components are allowed within a given time interval.

Don't others see the problems with this proposal, as it current is written, too?

-- Frank --=_alternative 0005B1C485256943_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 21 21:28: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 VAA11808 for ; Mon, 21 Aug 2000 21:28:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA28939 for ietf-calendar-bks; Mon, 21 Aug 2000 18:12:14 -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 SAA28925; Mon, 21 Aug 2000 18:12:06 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA20210; Mon, 21 Aug 2000 21:14:07 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA07111; Mon, 21 Aug 2000 21:12:13 -0400 (EDT) To: George Babics Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 21 Aug 2000 21:11:51 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/21/2000 09:11:51 PM, Serialize complete at 08/21/2000 09:11:51 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000698FE85256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000698FE85256943_= Content-Type: text/plain; charset="us-ascii" (I may have ruined the discussion thread by posting my previous concern with this proposal with a prefix of "Re:" in the subject line. My apologies!) George: Another thought... I can understand the requirement to allow a CUA to interact with a CS to negotiate the desire to avoid overlapping events. Maybe this should be a modally set calendar property? -- Frank --=_alternative 000698FE85256943_= Content-Type: text/html; charset="us-ascii"
(I may have ruined the discussion thread by posting my previous concern  with this proposal with a prefix of "Re:" in the subject line. My apologies!)

George:

Another thought...

I can understand the requirement to allow a CUA to interact with a CS to negotiate the desire to avoid overlapping events. Maybe this should be a modally set calendar property?

-- Frank

--=_alternative 000698FE85256943_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 21 21:45: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 VAA13109 for ; Mon, 21 Aug 2000 21:45:39 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA00896 for ietf-calendar-bks; Mon, 21 Aug 2000 18:28:35 -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 SAA00890; Mon, 21 Aug 2000 18:28:33 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA20881; Mon, 21 Aug 2000 21:30:08 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA08152; Mon, 21 Aug 2000 21:28:13 -0400 (EDT) To: John Stracke Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Updates to iTIP/iMIP RFCs X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 21 Aug 2000 21:27:41 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/21/2000 09:27:50 PM, Serialize complete at 08/21/2000 09:27:50 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00080C4785256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00080C4785256943_= Content-Type: text/plain; charset="us-ascii" John: As John has pointed out, there is no real market presence for iCalendar yet. This was certainly shown by the low attendance at CalConnect #1. Don't get me wrong, it is my every hope that the iCalendar market will manifest itself in the coming months. However, one of the problems we have with this current iTIP specification for REQUEST method is that it is very overloaded. It includes the semantics for: 1. An invitation, 2. A rescheduling invitation, 3. An update on attendee status, 4. A confirmation of the event status. Now, two of these are clearly REQUEST type of actions. The other two are of a confirmation nature. They require no reply, just monitoring and possible update of descriptive information in the event definition; by the recipient. This dycotomy was noted by a number of the early implementors with iCalendar. Early implementation is the time to fix these problems. I strongly disagree with your view of letting design problems linger in the early specifications. Let's fix this know bug in the iTIP design now, as we agreed to some time ago. -- Frank --=_alternative 00080C4785256943_= Content-Type: text/html; charset="us-ascii"
John:

As John has pointed out, there is no real market presence for iCalendar yet. This was certainly shown by the low attendance at CalConnect #1.

Don't get me wrong, it is my every hope that the iCalendar market will manifest itself in the coming months.

However, one of the problems we have with this current iTIP specification for REQUEST method is that it is very overloaded. It includes the semantics for:

1. An invitation,

2. A rescheduling invitation,

3. An update on attendee status,

4. A confirmation of the event status.

Now, two of these are clearly REQUEST type of actions. The other two are of a confirmation nature. They require no reply, just monitoring and possible update of descriptive information in the event definition; by the recipient.

This dycotomy was noted by a number of the early implementors with iCalendar. Early implementation is the time to fix these problems.

I strongly disagree with your view of letting design problems linger in the early specifications. Let's fix this know bug in the iTIP design now, as we agreed to some time ago.

-- Frank --=_alternative 00080C4785256943_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 21 22:56: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 WAA14531 for ; Mon, 21 Aug 2000 22:56:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA07120 for ietf-calendar-bks; Mon, 21 Aug 2000 19:30:15 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07115 for ; Mon, 21 Aug 2000 19:30:13 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id TAA00930 for ; Mon, 21 Aug 2000 19:30:26 -0700 (PDT) Message-ID: <39A1E5C1.D2FC45A2@home.royer.com> Date: Mon, 21 Aug 2000 19:30:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: [Fwd: Returned mail: Host unknown (Name server: imc.or: host not found)] Content-Type: multipart/mixed; boundary="------------4369E05AC02D4E07EF5B8D88" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4369E05AC02D4E07EF5B8D88 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Another thought... > > I can understand the requirement to allow a CUA to interact with a CS to > negotiate the desire to avoid overlapping events. Maybe this should be a > modally set calendar property? There was a large discussion on this WG list about NOCONFLICT. The original proposal was that both the Calendar and components needed a NOCONFLICT - I think it was Bruce's idea, and Frank you used to think it was a good idea :-) > Subject: Re: W-23 CAP Calendar property .. overlapped booking > From: Frank_Dawson@lotus.com > Date: Fri, 27 Aug 1999 19:05:35 GMT > >> If the calendar property is set CONFLICTS:FALSE, then new or >> updated events which conflict should generate an error. Previously >> entered events which conflict should not cause an error unless/until >> one of them is updated. Why would I have a conflict if I try to >> update an event with CONFLICT:TRUE that was created prior to the >> calendar property CONFLICTS:FALSE being set? > > BUT...I think that Bruce Kahn's comments about adding another enumeration > to TRANSP for OPAQUE-NO-CONFLICTS sounds good too. > > -- Frank --------------4369E05AC02D4E07EF5B8D88 Content-Type: message/delivery-status; name="nsmail39A1E5981AA0216" Content-Disposition: inline; filename="nsmail39A1E5981AA0216" Content-Transfer-Encoding: 7bit Reporting-MTA: dns; home.royer.com Received-From-MTA: DNS; home.royer.com Arrival-Date: Mon, 21 Aug 2000 19:28:34 -0700 (PDT) Final-Recipient: RFC822; ietf-calendar@imc.or Action: failed Status: 5.1.2 Remote-MTA: DNS; imc.or Last-Attempt-Date: Mon, 21 Aug 2000 19:28:35 -0700 (PDT) --------------4369E05AC02D4E07EF5B8D88 Content-Type: message/rfc822; name="nsmail39A1E5981AB0216" Content-Disposition: inline; filename="nsmail39A1E5981AB0216" Return-Path: Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id TAA00924 for ; Mon, 21 Aug 2000 19:28:34 -0700 (PDT) Sender: doug Message-ID: <39A1E550.2B67556F@home.royer.com> Date: Mon, 21 Aug 2000 19:28:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.or Subject: Re: Subject: Registration of text/calendar MIME property TRANSP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Another thought... > > I can understand the requirement to allow a CUA to interact with a CS to > negotiate the desire to avoid overlapping events. Maybe this should be a > modally set calendar property? There was a large discussion on this WG list about NOCONFLICT. The original proposal was that both the Calendar and components needed a NOCONFLICT - I think it was Bruce's idea, and Frank you used to think it was a good idea :-) > Subject: Re: W-23 CAP Calendar property .. overlapped booking > From: Frank_Dawson@lotus.com > Date: Fri, 27 Aug 1999 19:05:35 GMT > >> If the calendar property is set CONFLICTS:FALSE, then new or >> updated events which conflict should generate an error. Previously >> entered events which conflict should not cause an error unless/until >> one of them is updated. Why would I have a conflict if I try to >> update an event with CONFLICT:TRUE that was created prior to the >> calendar property CONFLICTS:FALSE being set? > > BUT...I think that Bruce Kahn's comments about adding another enumeration > to TRANSP for OPAQUE-NO-CONFLICTS sounds good too. > > -- Frank --------------4369E05AC02D4E07EF5B8D88-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 01:13: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 BAA16876 for ; Tue, 22 Aug 2000 01:13:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA16860 for ietf-calendar-bks; Mon, 21 Aug 2000 21:55:32 -0700 (PDT) Received: from equinox.law.columbia.edu (discussion.law.columbia.edu [128.59.176.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA16854 for ; Mon, 21 Aug 2000 21:55:30 -0700 (PDT) Subject: Heather Maitre is out of the office today From: "Heather Maitre" To: ietf-calendar@imc.org Message-ID: Date: Tue, 22 Aug 2000 01:00:46 -0400 X-MIMETrack: Serialize by Router on equinox/CLS(Release 5.0.4 |June 8, 2000) at 08/22/2000 01:00:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I will be out of the office starting 08/21/2000 and will not return until 08/23/2000. If your inquiry can wait until my return, I will be sure to get back to you then. If your inquiry requires immediate attention, alternate options are below: *for a computer problem contact the Administrative Technology Group directly at 854-1370 (or e-mail Helpdesk@law.columbia.edu); *if you have reported your computer problem and it needs escalation, or if you have something else that requires managerial attention, contact James Hua at 854-4861 *if your inquiry requires managerial attention, contact Frantz Merine, Associate Director of IT, at 854-4056. From owner-ietf-calendar@mail.imc.org Tue Aug 22 07:28: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 HAA01297 for ; Tue, 22 Aug 2000 07:28:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13461 for ietf-calendar-bks; Tue, 22 Aug 2000 04:07:19 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13457 for ; Tue, 22 Aug 2000 04:07:17 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00808; Tue, 22 Aug 2000 07:07:37 -0400 (EDT) Message-Id: <200008221107.HAA00808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stracke-calsch-crisp-01.txt Date: Tue, 22 Aug 2000 07:07:37 -0400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CAP Realtime iTIP-based Scheduling Profile (CRISP) Author(s) : J. Stracke Filename : draft-stracke-calsch-crisp-01.txt Pages : 4 Date : 21-Aug-00 This document sets forth a restricted profile of [CAP], one which supports no operations beyond the scheduling functionality of [iTIP]. The motivation is to permit use of CAP's real-time iTIP functionality without exposing the calendar access functionality (which may require stricter security controls than iTIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stracke-calsch-crisp-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stracke-calsch-crisp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stracke-calsch-crisp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000821135330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stracke-calsch-crisp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-stracke-calsch-crisp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000821135330.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 10:31: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 KAA07282 for ; Tue, 22 Aug 2000 10:31:33 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA23188 for ietf-calendar-bks; Tue, 22 Aug 2000 07:07: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 HAA23184 for ; Tue, 22 Aug 2000 07:07:41 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 22 Aug 2000 10:12:34 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/22/2000 10:12:46 AM, Serialize complete at 08/22/2000 10:12:46 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004DAEC285256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004DAEC285256943_= Content-Type: text/plain; charset="us-ascii" Doug asked: >> For the 2.0 "Success" case this may be ok but for all the other the >> non-2.0 cases where the statdesc may be somewhat useful, a SPACE is not >> going to cut it. > >No text was mandaded for non-2.0 cases, so why is SPACE invalid? I didnt say "invalid", I was referring to the _usefulness_ of statdesc when I said "cutting it". Let me be more precise then to avoid any further confusion: NO contents were EVERY mandated for statdesc. For cases other than 2.0, the _PURPOSE_ of statdesc is defeated by anything like SPACE or NULL for contents. For the 2.0 case, statdesc is not that important since its the "Success" case; for (nearly?) all other cases statdesc is of some use so a SPACE or NULL is NOT a good choice to send (even though you CAN do it by RFC defintions). >Noting in RFC2445 said what was to be sent. No format, no data, >nothing. So a single SPACE is valid per RFC2445 now. Read the ABNF for statdesc and you will see "Textual status description". So while the actual contents of that are not mandated (nor are they for LOCATION, CLASS, etc) the _kind_ of data is described. Its up to implementations to put in something useful. See thoughts above on the _intent_ of statdesc if still necessary... Also, if you really read the ABNF you will see that NULL is also valid! The ABNF for statdesc is: statdesc = text ;Textual status description and we defined text as: text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) Note the *() format so NULL is already an option. The only difference between this proposal and the one we already have in RFC 2445 is effectively to remove the mandated semicolon after the statcode. Thats it! If the collective CAP folks are worried about the difference between: REQUEST-STATUS:2.0; and REQUEST-STATUS:2.0 then CAP has other problems than those already raised. The ABNF change suggested really boils down to this 1 character difference! So answer will someone please answer WHY this is necessary to make a NON-BACKWARDS COMPATIBLE change for this in CAP?? If there is no compelling reason then Im vigorously opposed to this proposed change!! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 004DAEC285256943_= Content-Type: text/html; charset="us-ascii"
Doug asked:
>>  For the 2.0 "Success" case this may be ok but for all the other the
>> non-2.0 cases where the statdesc may be somewhat useful, a SPACE is not
>> going to cut it.
>
>No text was mandaded for non-2.0 cases, so why is SPACE invalid?
I didnt say "invalid", I was referring to the _usefulness_ of statdesc when I said "cutting it".

Let me be more precise then to avoid any further confusion:  NO contents were EVERY mandated for statdesc.  For cases other than 2.0, the _PURPOSE_ of statdesc is defeated by anything like SPACE or NULL for contents.  For the 2.0 case, statdesc is not that important since its the "Success" case; for (nearly?) all other cases statdesc is of some use so a SPACE or NULL is NOT a good choice to send (even though you CAN do it by RFC defintions).

>Noting in RFC2445 said what was to be sent. No format, no data,
>nothing. So a single SPACE is valid per RFC2445 now.
Read the ABNF for statdesc and you will see "Textual status description".  So while the actual contents of that are not mandated (nor are they for LOCATION, CLASS, etc) the _kind_ of data is described.  Its up to implementations to put in something useful.  See thoughts above on the _intent_ of statdesc if still necessary...

Also, if you really read the ABNF you will see that NULL is also valid!  The ABNF for statdesc is:

    statdesc   = text
    ;Textual status description

and we defined text as:

     text       = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)

Note the *() format so NULL is already an option.  The only difference between this proposal and the one we already have in RFC 2445 is effectively to remove the mandated semicolon after the statcode.  Thats it!  

If the collective CAP folks are worried about the difference between:

REQUEST-STATUS:2.0;

and

REQUEST-STATUS:2.0

then CAP has other problems than those already raised.  The ABNF change suggested really boils down to this 1 character difference!  

So answer will someone please answer WHY this is necessary to make a NON-BACKWARDS COMPATIBLE change for this in CAP??  If there is no compelling reason then Im vigorously opposed to this proposed change!!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 004DAEC285256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 10:55: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 KAA07677 for ; Tue, 22 Aug 2000 10:55:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26149 for ietf-calendar-bks; Tue, 22 Aug 2000 07:43:31 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26145 for ; Tue, 22 Aug 2000 07:43:30 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id HAA02023 for ; Tue, 22 Aug 2000 07:43:50 -0700 (PDT) Message-ID: <39A291A5.E64FC4C0@home.royer.com> Date: Tue, 22 Aug 2000 07:43:49 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS 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: > So answer will someone please answer WHY this is necessary to make a > NON-BACKWARDS COMPATIBLE change for this in CAP?? The idea was that when nothing is needed, why add something just to fill in the ABNF. The 'NULL' description would serve the same purpose. > If there is no > compelling reason then Im vigorously opposed to this proposed change!! I think that "REQUEST-STATUS:2.0;" would be acceptable. -Doug From owner-ietf-calendar@mail.imc.org Tue Aug 22 11:47: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 LAA09073 for ; Tue, 22 Aug 2000 11:47:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29283 for ietf-calendar-bks; Tue, 22 Aug 2000 08:32:27 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29279 for ; Tue, 22 Aug 2000 08:32:26 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA06036 for ; Tue, 22 Aug 2000 11:34:47 -0400 Message-ID: <39A29D96.DB9B130C@ecal.com> Date: Tue, 22 Aug 2000 11:34:47 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: Updates to iTIP/iMIP RFCs 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: > As John has pointed out, there is no real market presence for > iCalendar yet. This was certainly shown by the low attendance > at CalConnect #1. OK, good point. I withdraw the objection. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |When rats leave a sinking ship, where exactly do| |francis@ecal.com|they think they're going? | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 22 11:49: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 LAA09132 for ; Tue, 22 Aug 2000 11:49:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29104 for ietf-calendar-bks; Tue, 22 Aug 2000 08:30:43 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29100 for ; Tue, 22 Aug 2000 08:30:41 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA06032 for ; Tue, 22 Aug 2000 11:33:03 -0400 Message-ID: <39A29D2E.6DA75CDF@ecal.com> Date: Tue, 22 Aug 2000 11:33:02 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: I-D ACTION:draft-stracke-calsch-crisp-01.txt References: <200008221107.HAA00808@ietf.org> 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 Internet-Drafts@ietf.org wrote: > Title : CAP Realtime iTIP-based Scheduling Profile (CRISP) > Author(s) : J. Stracke > Filename : draft-stracke-calsch-crisp-01.txt This is an update attempting to clarify the questions that came up on the list. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |All your problems can be solved by not caring!| |francis@ecal.com| | \===============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 22 12:02: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 MAA09428 for ; Tue, 22 Aug 2000 12:02:04 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA00307 for ietf-calendar-bks; Tue, 22 Aug 2000 08:43: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 IAA00299 for ; Tue, 22 Aug 2000 08:43:18 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 22 Aug 2000 11:48:14 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/22/2000 11:48:20 AM, Serialize complete at 08/22/2000 11:48:20 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005670F985256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005670F985256943_= Content-Type: text/plain; charset="us-ascii" Doug noted: >There was a large discussion on this WG list about NOCONFLICT. Actually it was about CONFLICTS:TRUE/FALSE (All under the Subject "W-23 CAP Calendar property .. overlapped booking" starting 17-Aug-1999). >The original proposal was that both the >Calendar and components needed a NOCONFLICT - I think >it was Bruce's idea, Actually I wrote: >>Which brings up another point (I think you were saying). That if the >>property exists in a component, then it would only apply to >>TRANSP:OPAQUE components. > >This would argue in favor of not making 2 properties that need to be checked but rather changing TRANSP: >to be n-stated (ie: TRANS, OPAQUE, OPAQUE-NOCONFLICTS). Are you suggesting this or am I just >ahead of the thought process on this?? > >I think having 2 properties that control each other (ie: > > >IFF TRANSP:TRANS > ignore CONFLICTS: >ELSE IFF CONFLICTS:TRUE > RETURN("OK") > ELSE > RETURN("BUZZ OFF") > > >is just ugly. This was one motivation for collapsing required, optional, etc down and including into ROLE= >on ATTENDEEs. However if we do this, it couldn't be a property of the Calendar (ie: outside a vEvent) since >we do not have TRANSP: on calendars... > >Then again, if TRANSP and CONFLICTS were exclusive of each other I could use TRANSP: TRANS and > >CONFLICTS:FALSE to leave holes in my busytime and still block them from being booked by others. A >novel ideal some folks would enjoy playing with Im sure. > > Hmm, choices, choices... I didnt propose it actually, I was just thinking out loud to further progress the discussion. The talk of a separate CS policy that enforces CONFLICTS happened later in that same thread. Given that CAP is interested in having CONFLICTS:TRUE / FALSE as a policy, it makes more sense to NOT overload TRANSP and make a separate new property called CONFLICTS. That way it can be both on the entry (ie: inside the vEvent) or on the calendar as CS policy. It seems nonsensicial to have a CS policy of "TRANSP:OPAQUE-NOCONFLICT" since the policy is really "Do I allow CONFLICTs or not??"; it has _nothing_ to do with transparency or opaqueness of the calendar itself. In addition, a side effect of a new property could be that it is defined to be CONFLICT: TRUE if it is not there. This would allow a phasing in of CUAs that grok CONFLICT when parsing data they get over iTIP (NOT over CAP itself) while allowing CAP savy CUAs to do the right thing. Changing TRANSP to new non-RFC 2445 values would mean that existing CUAs would not properly grok the TRANSPARENT/OPAQUEness of the entry as well as the NOCONFLICT intent. Yes, there are some niggling 'what about...' cases that would need to be resolved by defining a new CONFLICTS property (ie: Dealing with preexisting CONFLICTS:FALSE entries that conflict) but they can be resolved by a clear, well thought thru proposal... This is not waffling on my part; just mulling over the needs vs implications arguments again. Someone nudge me back with a compelling argument why TRANSP must get toasted instead of making a new CONFLICTS property... Hmm, originally I also talked about letting the Organzier 'request' the priority of the entry via TRANSP instead of CONFLICT but that the recipient did not have to obey it. Does it make more sense for _that_ case to n-state TRANSP or can it be done via a combination of TRANSP/CONFLICT (ala the pseudo code above)?? Also looking back over the original thread, I do not see a clear concensus to some of the issues (esp. CS enforcment vs CUA enforcment in some cases). Perhaps there has been some new cycles spent on this out of bounds to fix this... Bruce PS: In researching this thread I found that Doug was actually on the other side then (Dated 08/25/99 10:57:08 AM MST, same Subject thread in response to Andre): > They both sound like the same amount of work to me, and having > CONFLICTS at the component level increases flexibility a _lot_, > so we need it. Me too. =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005670F985256943_= Content-Type: text/html; charset="us-ascii"
Doug noted:
>There was a large discussion on this WG list about
NOCONFLICT.

Actually it was about CONFLICTS:TRUE/FALSE (All under the Subject "W-23 CAP Calendar property .. overlapped booking" starting 17-Aug-1999).

>The original proposal was that both the
>Calendar and components needed a NOCONFLICT - I think
>it was Bruce's idea,

Actually I wrote:
>>Which brings up another point (I think you were saying).  That if the
>>property exists in a component, then it would only apply to
>>TRANSP:OPAQUE components.
>
>This would argue in favor of not making 2 properties that need to be checked but rather changing TRANSP:
>to be n-stated (ie: TRANS, OPAQUE, OPAQUE-NOCONFLICTS).  Are you suggesting this or am I just
>ahead of the thought process on this??
>
>I think having 2 properties that control each other (ie:
>
><PSEUDOCODE>
>IFF TRANSP:TRANS
>        ignore CONFLICTS:
>ELSE IFF CONFLICTS:TRUE
>                RETURN("OK")
>        ELSE
>                RETURN("BUZZ OFF")
></PSEUDOCODE>
>
>is just ugly.  This was one motivation for collapsing required, optional, etc down and including into ROLE=
>on ATTENDEEs.  However if we do this, it couldn't be a property of the Calendar (ie: outside a vEvent) since
>we do not have TRANSP: on calendars...
>
>Then again, if TRANSP and CONFLICTS were exclusive of each other I could use TRANSP: TRANS and >
>CONFLICTS:FALSE to leave holes in my busytime and still block them from being booked by others.  A
>novel ideal some folks would enjoy playing with Im sure.
>
> Hmm, choices, choices...

I didnt propose it actually, I was just thinking out loud to further progress the discussion.  The talk of a separate CS policy that enforces CONFLICTS happened later in that same thread.  Given that CAP is interested in having CONFLICTS:TRUE / FALSE as a policy, it makes more sense to NOT overload TRANSP and make a separate new property called CONFLICTS.  That way it can be both on the entry (ie: inside the vEvent) or on the calendar as CS policy.

It seems nonsensicial to have a CS policy of "TRANSP:OPAQUE-NOCONFLICT" since the policy is really "Do I allow CONFLICTs or not??"; it has _nothing_ to do with transparency or opaqueness of the calendar itself.

In addition, a side effect of a new property could be that it is defined to be CONFLICT: TRUE if it is not there.  This would allow a phasing in of CUAs that grok CONFLICT when parsing data they get over iTIP (NOT over CAP itself) while allowing CAP savy CUAs to do the right thing.  Changing TRANSP to new non-RFC 2445 values would mean that existing CUAs would not properly grok the TRANSPARENT/OPAQUEness of the entry as well as the NOCONFLICT intent.

Yes, there are some niggling 'what about...' cases that would need to be resolved by defining a new CONFLICTS property (ie: Dealing with preexisting CONFLICTS:FALSE entries that conflict) but they can be resolved by a clear, well thought thru proposal...

This is not waffling on my part; just mulling over the needs vs implications arguments again.  Someone nudge me back with a compelling argument why TRANSP must get toasted instead of making a new CONFLICTS property...

Hmm, originally I also talked about letting the Organzier 'request' the priority of the entry via TRANSP instead of CONFLICT but that the recipient did not have to obey it.  Does it make more sense for _that_ case to n-state TRANSP or can it be done via a combination of TRANSP/CONFLICT (ala the pseudo code above)??

Also looking back over the original thread, I do not see a clear concensus to some of the issues (esp. CS enforcment vs CUA enforcment in some cases).  Perhaps there has been some new cycles spent on this out of bounds to fix this...

Bruce
PS: In researching this thread I found that Doug was actually on the other side then (Dated 08/25/99 10:57:08 AM MST, same Subject thread in response to Andre):
> They both sound like the same amount of work to me, and having
> CONFLICTS at the component level increases flexibility a _lot_,
> so we need it.

Me too.
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005670F985256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 12:03: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 MAA09512 for ; Tue, 22 Aug 2000 12:03:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA01334 for ietf-calendar-bks; Tue, 22 Aug 2000 08:50:02 -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 IAA01330 for ; Tue, 22 Aug 2000 08:50:00 -0700 (PDT) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 22 Aug 2000 11:54:59 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/22/2000 11:55:02 AM, Serialize complete at 08/22/2000 11:55:02 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00570EE985256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00570EE985256943_= Content-Type: text/plain; charset="us-ascii" Doug noted: >The idea was that when nothing is needed, why add something >just to fill in the ABNF. The 'NULL' description would >serve the same purpose. That is already allowed via the ABNF. >I think that "REQUEST-STATUS:2.0;" would be acceptable. If that is the case, then it sounds like this proposal can be withdrawn. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00570EE985256943_= Content-Type: text/html; charset="us-ascii"
Doug noted:
>The idea was that when nothing is needed, why add something
>just to fill in the ABNF. The 'NULL' description would
>serve the same purpose.

That is already allowed via the ABNF.

>I think that "REQUEST-STATUS:2.0;" would be acceptable.

If that is the case, then it sounds like this proposal can be withdrawn.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00570EE985256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 12:17: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 MAA09914 for ; Tue, 22 Aug 2000 12:17:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA02454 for ietf-calendar-bks; Tue, 22 Aug 2000 08:59:10 -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 IAA02450 for ; Tue, 22 Aug 2000 08:59:09 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 22 Aug 2000 12:04:02 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/22/2000 12:04:11 PM, Serialize complete at 08/22/2000 12:04:11 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0057E32885256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057E32885256943_= Content-Type: text/plain; charset="us-ascii" Errp, spoke a bit too quickly that last time. Im for removing the portions of the proposal that do an ABNF change. I am FOR keeping the changes relating to more examples and allowing REQUEST-STATUS to be in other components. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0057E32885256943_= Content-Type: text/html; charset="us-ascii"
Errp, spoke a bit too quickly that last time.  Im for removing the portions of the proposal that do an ABNF change.  I am FOR keeping the changes relating to more examples and allowing REQUEST-STATUS to be in other components.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0057E32885256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 12:22:35 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 MAA10011 for ; Tue, 22 Aug 2000 12:22:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03364 for ietf-calendar-bks; Tue, 22 Aug 2000 09:10:26 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03360 for ; Tue, 22 Aug 2000 09:10:25 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id JAA02173 for ; Tue, 22 Aug 2000 09:10:45 -0700 (PDT) Message-ID: <39A2A603.5C7B6E02@home.royer.com> Date: Tue, 22 Aug 2000 09:10:43 -0700 From: Doug Royer X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP 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: >. > It seems nonsensicial to have a CS policy of "TRANSP:OPAQUE-NOCONFLICT" > since the policy is really "Do I allow CONFLICTs or not??"; it has > _nothing_ to do with transparency or opaqueness of the calendar itself. I have always agreed they needed to be separate. I just bowed to what I thought would make it work and keep both sides happy > Also looking back over the original thread, I do not see a clear > concensus to some of the issues (esp. CS enforcment vs CUA enforcment in > some cases). Perhaps there has been some new cycles spent on this out of > bounds to fix this... Group Do we do 2 separate properties? -Doug From owner-ietf-calendar@mail.imc.org Tue Aug 22 12:29: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 MAA10156 for ; Tue, 22 Aug 2000 12:29:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03832 for ietf-calendar-bks; Tue, 22 Aug 2000 09:15:57 -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 JAA03826 for ; Tue, 22 Aug 2000 09:15:56 -0700 (PDT) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: REQUEST-STATUS & CAP Querries X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 22 Aug 2000 12:20:51 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/22/2000 12:20:58 PM, Serialize complete at 08/22/2000 12:20:58 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00596D5185256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00596D5185256943_= Content-Type: text/plain; charset="us-ascii" I have a new question about REQUEST-STATUS and how it is used in CAP. If a CUA uses CAP to query what TZs are available for a particular criteria (GEO-BOUNDS, etc.) but does not indicate it wants REQUEST-STATUS values back; will the CAP server send them anyway? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00596D5185256943_= Content-Type: text/html; charset="us-ascii"
I have a new question about REQUEST-STATUS and how it is used in CAP.  If a CUA uses CAP to query what TZs are available for a particular criteria (GEO-BOUNDS, etc.) but does not indicate it wants REQUEST-STATUS values back; will the CAP server send them anyway?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00596D5185256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 13:06: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 NAA10969 for ; Tue, 22 Aug 2000 13:06:29 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA05842 for ietf-calendar-bks; Tue, 22 Aug 2000 09:51:13 -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 JAA05838 for ; Tue, 22 Aug 2000 09:51:10 -0700 (PDT) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 22 Aug 2000 12:56:07 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/22/2000 12:56:14 PM, Serialize complete at 08/22/2000 12:56:14 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005CA7C385256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CA7C385256943_= Content-Type: text/plain; charset="us-ascii" Doug replied: >The only time a user must choose is when a CUA would query a CS >to get a TZID or list of TZID's to use. If they get > 1, then >the CU or CUA chooses which TZID MUST be sent >with the object. One VTIMEZONE for each unique TZID. Ok, let me make my concern a bit sharper: I am 95% against having the CUA doing the choosing by itself (I can think of some cases where it MAY be ok but very very few). This is the interop nightmare. Do _not_ leave the option open ended or we have the multipart/* case all over but its worse as the entrys may actually be misrendered at incorrect times. Since you are "simply" adding some specifics "in addition to what alredy MUST be sent", why not take the opportunity to properly codify the behaviour WRT > 1 entry so that it is unambiguous. I took your original "If > 1, choose" to mean that the CUA would arbitrarily (or using some voodoo) decide which to use and that is just bad! The addition of GEO-BOUNDS (hyphenated to be consistant or underscored to be different??) makes the puzzle worse by allowing a CUA to query for "What TZs may be in effect at this GEO position?" If you are going to be in that part of the architecture to add stuff that makes interop potentially nastier, please, PLEASE clearly codify the proper behaviour for a CUA in these boundary scenarios!!! (Consider this an opportunity to clean up an oversight in our original text. :^) ) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005CA7C385256943_= Content-Type: text/html; charset="us-ascii"
Doug replied:
>The only time a user must choose is when a CUA would query a CS
>to get a TZID or list of TZID's to use. If they get > 1, then
>the CU or CUA chooses which TZID MUST be sent
>with the object. One VTIMEZONE for each unique TZID.

Ok, let me make my concern a bit sharper: I am 95% against having the CUA doing the choosing by itself (I can think of some cases where it MAY be ok but very very few).  This is the interop nightmare.  Do _not_ leave the option open ended or we have the multipart/* case all over but its worse as the entrys may actually be misrendered at incorrect times.  Since you are "simply" adding some specifics "in addition to what alredy MUST be sent", why not take the opportunity to properly codify the behaviour WRT > 1 entry so that it is unambiguous.

I took your original "If > 1, choose" to mean that the CUA would arbitrarily (or using some voodoo) decide which to use and that is just bad!  The addition of GEO-BOUNDS (hyphenated to be consistant or underscored to be different??) makes the puzzle worse by allowing a CUA to query for "What TZs may be in effect at this GEO position?"  If you are going to be in that part of the architecture to add stuff that makes interop potentially nastier, please, PLEASE clearly codify the proper behaviour for a CUA in these boundary scenarios!!!  (Consider this an opportunity to clean up an oversight in our original text. :^) )

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005CA7C385256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 13:33: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 NAA11534 for ; Tue, 22 Aug 2000 13:33:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06775 for ietf-calendar-bks; Tue, 22 Aug 2000 10:18:07 -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 KAA06771; Tue, 22 Aug 2000 10:18:06 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA03142; Tue, 22 Aug 2000 13:19:48 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA26603; Tue, 22 Aug 2000 13:17:53 -0400 (EDT) To: Doug Royer Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 22 Aug 2000 13:17:28 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/22/2000 01:17:30 PM, Serialize complete at 08/22/2000 01:17:30 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005F040885256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005F040885256943_= Content-Type: text/plain; charset="us-ascii" Doug: In either case, let's make sure that the change request has a clear definition of the exception cases and how they are handled. BTW, separating this out from TRANSP would be my preference. -- Frank --=_alternative 005F040885256943_= Content-Type: text/html; charset="us-ascii"
Doug:

In either case, let's make sure that the change request has a clear definition of the exception cases and how they are handled.

BTW, separating this out from TRANSP would be my preference.

-- Frank --=_alternative 005F040885256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 13:51: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 NAA11887 for ; Tue, 22 Aug 2000 13:51:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08016 for ietf-calendar-bks; Tue, 22 Aug 2000 10:38:33 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08009 for ; Tue, 22 Aug 2000 10:38:31 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id KAA02724 for ; Tue, 22 Aug 2000 10:38:51 -0700 (PDT) Message-ID: <39A2BAA9.FD1C80C8@home.royer.com> Date: Tue, 22 Aug 2000 10:38:49 -0700 From: Doug Royer Reply-To: IETF-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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 replied: > >The only time a user must choose is when a CUA would query a CS > >to get a TZID or list of TZID's to use. If they get > 1, then > >the CU or CUA chooses which TZID MUST be sent > >with the object. One VTIMEZONE for each unique TZID. > > Ok, let me make my concern a bit sharper: I am 95% against > having the CUA doing the choosing by itself. > (I can think > ff some cases where it MAY be ok but very very few). This is > the interop nightmare. Do _not_ leave the option open ended > or we have the multipart/* case all over but its worse as > the entrys may actually be misrendered at incorrect times. > Since you are "simply" adding some specifics "in addition > to what alredy MUST be sent", why not take the opportunity > to properly codify the behaviour WRT > 1 entry so that it > is unambiguous. If the CUA knows its timezone name, but does not have the VTIMEZONE definition. Why not let the CUA choose? Example: My mobile CUA thinks it's timezone is US/Pacific because my OS says so. But my mobile OS system does not know anything about VTIMEZONE. So my mobile CUA queries a CAP server and provides my GEO position. The CS could come back with VTIMEZONES with the following TZIDs + TZNAME BEGIN:VTIMEZONE ... TZID:TZID:America/Los_Angeles ... TZNAME;LANGUAGE=us-EN:PST8PDT TZNAME;LANGUAGE=us-EN:US/Pacific TZNAME;LANGUAGE=us-EN:US/Pacific-New ... END:VTIMEZONE BEGIN:VTMEZONE TZID:GMT-8 ... TZNAME:Us Pacific Coast Military time ... END:VTIMEZONE BEGIN:VTIMEZONE TZID:... ... END:VTIMEZONE I can write a tool that selects the correct VTIMEZONE America/Los_Angles from a list.There are times when the CUA will know which to use. If it can't find a match - then the user selects. -Doug From owner-ietf-calendar@mail.imc.org Tue Aug 22 13:52: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 NAA11938 for ; Tue, 22 Aug 2000 13:52:27 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA08044 for ietf-calendar-bks; Tue, 22 Aug 2000 10:38:47 -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 KAA08038; Tue, 22 Aug 2000 10:38:46 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA07061; Tue, 22 Aug 2000 13:40:28 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA00914; Tue, 22 Aug 2000 13:38:32 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 22 Aug 2000 13:38:00 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/22/2000 01:38:09 PM, Serialize complete at 08/22/2000 01:38:09 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0060E53C85256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0060E53C85256943_= Content-Type: text/plain; charset="us-ascii" Bruce: >Hmm, originally I also talked about letting the Organzier 'request' the priority of the entry via TRANSP instead of CONFLICT >but that the recipient did not have to obey it. Does it make more sense for _that_ case to n-state TRANSP or can it be done >via a combination of TRANSP/CONFLICT (ala the pseudo code above)?? Actually, having a n-state TRANSP is what we had in vCalendar. You may remember that we had an integer value on TRANSP. We had a value of zero mean that the entry will block time and be factored into a busy time search. A value of one meant that the event was truly transparent and would not block time. A value other than that was implementation dependent. The original design ideas were that other values would act similar to the "layering" in CAD drawings. Busy but reschedulable (a value of 2). Busy but schedulable with overlapping events(a value of 3), busy and no conflicts (a value of 4). But we got rid of integer values in iCalendar... In any case, the discussion seems to be going towards a disjoint property for CONFLICTS. Back to where we were back some time ago on the list. >Also looking back over the original thread, I do not see a clear concensus to some of the issues (esp. CS enforcment vs >CUA enforcment in some cases). Perhaps there has been some new cycles spent on this out of bounds to fix this... Yep. No consensus. Which is why I guess this gets brought up again ;-) --=_alternative 0060E53C85256943_= Content-Type: text/html; charset="us-ascii"
Bruce:

>Hmm, originally I also talked about letting the Organzier 'request' the priority of the entry via TRANSP instead of CONFLICT >but that the recipient did not have to obey it.  Does it make more sense for _that_ case to n-state TRANSP or can it be done >via a combination of TRANSP/CONFLICT (ala the pseudo code above)??

Actually, having a n-state TRANSP is what we had in vCalendar. You may remember that we had an integer value on TRANSP. We had a value of zero mean that the entry will block time and be factored into a busy time search. A value of one meant that the event was truly transparent and would not block time. A value other than that was implementation dependent. The original design ideas were that other values would act similar to the "layering" in CAD drawings. Busy but reschedulable (a value of 2). Busy but schedulable with overlapping events(a value of 3), busy and no conflicts (a value of 4). But we got rid of integer values in iCalendar...

In any case, the discussion seems to be going towards a disjoint property for CONFLICTS. Back to where we were back some time ago on the list.


>Also looking back over the original thread, I do not see a clear concensus to some of the issues (esp. CS enforcment vs >CUA enforcment in some cases).  Perhaps there has been some new cycles spent on this out of bounds to fix this...

Yep. No consensus. Which is why I guess this gets brought up again ;-)
 --=_alternative 0060E53C85256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 14:04: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 OAA12218 for ; Tue, 22 Aug 2000 14:04:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08842 for ietf-calendar-bks; Tue, 22 Aug 2000 10:49:21 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08835 for ; Tue, 22 Aug 2000 10:49:19 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id KAA02776 for ; Tue, 22 Aug 2000 10:49:38 -0700 (PDT) Message-ID: <39A2BD31.8AB2E5C1@home.royer.com> Date: Tue, 22 Aug 2000 10:49:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: REQUEST-STATUS & CAP Querries 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: > > I have a new question about REQUEST-STATUS and how it is used in CAP. If > a CUA uses CAP to query what TZs are available for a particular criteria > (GEO-BOUNDS, etc.) but does not indicate it wants REQUEST-STATUS values > back; will the CAP server send them anyway? (1) CAP places them every place iTIP needs them, and if a CAP error occurred, then, (2) All responces from a CAP server for non-iTIP METHOD's include at least one REQUEST-STATUS for all failures. This applies to VTIMEZONE and all other containers (if any others). -Doug From owner-ietf-calendar@mail.imc.org Tue Aug 22 14:49: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 OAA12909 for ; Tue, 22 Aug 2000 14:49:43 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA10470 for ietf-calendar-bks; Tue, 22 Aug 2000 11:36:40 -0700 (PDT) Received: from altaweb.altawave.com (w235.z208176003.sjc-ca.dsl.cnc.net [208.176.3.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10466 for ; Tue, 22 Aug 2000 11:36:39 -0700 (PDT) Received: from [209.220.160.127] ([209.220.160.127]) by altaweb.altawave.com (Lotus Domino Release 5.0.1) with SMTP id 2000082211371343:3918 ; Tue, 22 Aug 2000 11:37:13 -0700 Message-ID: <001f01c00c67$f52bff40$0301a8c0@JRMEDLEY> Reply-To: "JR" From: "JR" To: , References: <399F81EC.23853F3D@home.royer.com> Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS Date: Tue, 22 Aug 2000 11:36:59 -0700 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on altaweb/Altawave/US(Release 5.0.1|July 16, 1999) at 08/22/2000 11:37:14 AM, Serialize by Router on altaweb/Altawave/US(Release 5.0.1|July 16, 1999) at 08/22/2000 11:37:15 AM, Serialize complete at 08/22/2000 11:37:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't have a strong opinion about your idea of a GEO_BOUNDS format, but it's not clear whether all the factors have been carefully considered. I would suggest the following as necessary points of discussion: A. When you say "as defined in RFC2445", I presume you mean that the values are to be interpreted as decimal degrees, as described for the GEO property of iCalendar? I would strongly recommend making this more clear, perhaps by saying something more like "decimal degrees, as defined in RFC2445". B. I trust that everyone is aware that the LAT/LON coordinates of RFC2445 are NOT cartesian (i.e. not strictly rectangular), but refer to a points on a sphere. So a simple rectangular "point in polygon" algorithm would be inadequate for comparing a location to a timezone polygon. Not a huge problem, but it typically requires some GIS-type capabilities to calculate. C. There are also plenty of accuracy issues unless the provided polygon includes a huge number of LAT/LON coordinates. It typically takes at least several hundred coordinates to define a single geographic region with any reasonable accuracy. If you reduce the provided number, the overall accuracy of comparisons goes down accordingly. D. How do you define regions that are made up of multiple distinct polygons? Given the political fragmentation of our fine planet, there are likely time zones with holes in the middle, or broken into several distinct pieces. (GIS folks refer to these as lakes and islands.) It doesn't look to me like the current proposal has any way of addressing this issue. I don't have the bandwidth to track closely with all this discussion, but I would strongly recommend that you work with some experienced GIS folks to better understand all the issues. Just be sure you know what can of worms you are opening up... Hope this helps, - JR ----- Original Message ----- From: "Doug Royer" To: Sent: Saturday, August 19, 2000 11:59 PM Subject: Registration of text/calendar MIME property GEO_BOUNDS > > Property name: GEO_BOUNDS > > Property purpose: To define the geographic bounds of a area. > > Property value type: FLOAT > > Property parameter: Non-standard parameters can be > specified on this property. > > Conformance: VTIMEZONE plus other components that can use GEO. > > Description: GEO_BOUNDS is a list of latitude and longitude > points (geovalue) that describe a bounding polygon for a > geographic area. It must consist if at least three points. > The polygon is closed by a line between the last and first point. > > Each point is a geovalue. > > Format definition: > > geo_bounds = "GEO_BOUNDS" bounds-param ":" latlon-sets > > bounds-param = *( ";" xparam ) > > latlon-sets = geovalue *( "," latlon-sets ) > > geovalue = ; As defined in RFC2445 > > xparam = ; As defined in RFC2445 > > float = ; As defined in RFC2445 > > Examples: > > GEO_BOUNDS:21.17;157.51,21.18;157.50,21.18;157.11 From owner-ietf-calendar@mail.imc.org Tue Aug 22 15:12: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 PAA13676 for ; Tue, 22 Aug 2000 15:12:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11600 for ietf-calendar-bks; Tue, 22 Aug 2000 11:58:23 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11596 for ; Tue, 22 Aug 2000 11:58:20 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA03236 for ; Tue, 22 Aug 2000 11:58:40 -0700 (PDT) Message-ID: <39A2CD5F.60449AD6@home.royer.com> Date: Tue, 22 Aug 2000 11:58:39 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS References: <399F81EC.23853F3D@home.royer.com> <001f01c00c67$f52bff40$0301a8c0@JRMEDLEY> 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 JR wrote: > > I don't have a strong opinion about your idea of a GEO_BOUNDS > format, but it's not clear whether all the factors have been > carefully considered. Delighted to get input! > I would suggest the following as necessary > points of discussion: > > A. When you say "as defined in RFC2445", I presume you mean that the > values are to be interpreted as decimal degrees, as described for > the GEO property of iCalendar? I would strongly recommend making > this more clear, perhaps by saying something more like "decimal > degrees, as defined in RFC2445". Yep - I'll do that. > B. I trust that everyone is aware that the LAT/LON coordinates of > RFC2445 are NOT cartesian (i.e. not strictly rectangular), but refer > to a points on a sphere. So a simple rectangular "point in polygon" > algorithm would be inadequate for comparing a location to a timezone > polygon. Not a huge problem, but it typically requires some GIS-type > capabilities to calculate. Yea I knew that. I was not sure how to say that. I had not proposed (at this time) any solution to that problem. When this gets worked out, I plan on sending out a draft that describes how GEO_BOUNDRY should be used by a CS and a CUA to find a VTIMEZONE. > C. There are also plenty of accuracy issues unless the provided polygon > includes a huge number of LAT/LON coordinates. It typically takes > at least several hundred coordinates to define a single geographic > region with any reasonable accuracy. If you reduce the provided > number, the overall accuracy of comparisons goes down accordingly. Yes. A CUA does not need to download the GEO_BOUNDRY in order to QUERY for a valid VTIMEZONE. So not all CUAs will need to keep the data. > D. How do you define regions that are made up of multiple distinct > polygons? Multiple GEO_BOUNDRY entries in the VTIMEZONE. I'll add that. > Given the political fragmentation of our fine planet, there are likely > time zones with holes in the middle, or broken into several distinct > pieces. (GIS folks refer to these as lakes and islands.) It doesn't > look to me like the current proposal has any way of addressing this > issue. I had not thought of the hole in the middle problem. Would something like "GEO_BOUNDRY_EXCEPTION: " do? It would describe holes. > I don't have the bandwidth to track closely with all this discussion, > but I would strongly recommend that you work with some experienced GIS > folks to better understand all the issues. Just be sure you know > what can of worms you are opening up... As to working with the experienced GIS folks - any volunteers? -Doug From owner-ietf-calendar@mail.imc.org Tue Aug 22 16:18: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 QAA14899 for ; Tue, 22 Aug 2000 16:18:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12807 for ietf-calendar-bks; Tue, 22 Aug 2000 12:58: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 MAA12803; Tue, 22 Aug 2000 12:58:10 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA00831; Tue, 22 Aug 2000 15:59:55 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA26185; Tue, 22 Aug 2000 15:58:00 -0400 (EDT) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 22 Aug 2000 15:57:30 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/22/2000 03:57:37 PM, Serialize complete at 08/22/2000 03:57:37 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006DAADA85256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006DAADA85256943_= Content-Type: text/plain; charset="us-ascii" Doug Royer wrote, in part: >I had not proposed (at this time) any solution to that problem. When >this gets worked out, I plan on sending out a draft that describes >how GEO_BOUNDRY should be used by a CS and a CUA to find a VTIMEZONE. So, then your change request was not a complete RFC2445 change request? Shouldn't we be submitting complete change request packages, if we really intend these to seriously considered by the WG? Or were you just using the official change request format to introduce a new discussion? The title of the thread implied the registration of a new property with a complete proposal? I am confused now? -- Frank --=_alternative 006DAADA85256943_= Content-Type: text/html; charset="us-ascii"
Doug Royer wrote, in part:


>I had not proposed (at this time) any solution to that problem. When
>this gets worked out, I plan on sending out a draft that describes
>how GEO_BOUNDRY should be used by a CS and a CUA to find a VTIMEZONE.

So, then your change request was not a complete RFC2445 change request?

Shouldn't we be submitting complete change request packages, if we really intend these to seriously considered by the WG?

Or were you just using the official change request format to introduce a new discussion? The title of the thread implied the registration of a new property with a complete proposal? I am confused now?

-- Frank
 --=_alternative 006DAADA85256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 16:18: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 QAA14910 for ; Tue, 22 Aug 2000 16:18:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12950 for ietf-calendar-bks; Tue, 22 Aug 2000 13:04:30 -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 NAA12945; Tue, 22 Aug 2000 13:04:28 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA01758; Tue, 22 Aug 2000 16:06:09 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA27142; Tue, 22 Aug 2000 16:04:14 -0400 (EDT) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 22 Aug 2000 16:03:45 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/22/2000 04:03:52 PM, Serialize complete at 08/22/2000 04:03:52 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006E3D6F85256943_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E3D6F85256943_= Content-Type: text/plain; charset="us-ascii" >> Given the political fragmentation of our fine planet, there are likely >> time zones with holes in the middle, or broken into several distinct >> pieces. (GIS folks refer to these as lakes and islands.) It doesn't >> look to me like the current proposal has any way of addressing this >> issue. >I had not thought of the hole in the middle problem. > >Would something like "GEO_BOUNDRY_EXCEPTION: " do? >It would describe holes. I seem to remember that the CGI, GKS, PHIGS computer graphics standards had a POLYGON_SET primitive. So maybe you don't really need the exception property? If you include a set of polygons there is a well know algorithm to find out if a coordinate is in the inside or outside of the set. But then, this would only require the CUA to convey to the CS a single LAT/LON coordinate (and a date/time value?) for the CS to calculate which set of time zones correspond to the GEO? -- Frank --=_alternative 006E3D6F85256943_= Content-Type: text/html; charset="us-ascii"
>>  Given the political fragmentation of our fine planet, there are likely
>>  time zones with holes in the middle, or broken into several distinct
>> pieces.  (GIS folks refer to these as lakes and islands.)  It doesn't
>> look to me like the current  proposal has any way of addressing this
>> issue.

>I had not thought of the hole in the middle problem.
>
>Would something like "GEO_BOUNDRY_EXCEPTION: <sets-of-points>" do?
>It would describe holes.

I seem to remember that the CGI, GKS, PHIGS computer graphics standards had a POLYGON_SET primitive. So maybe you don't really need the exception property?

If you include a set of polygons there is a well know algorithm to find out if a coordinate is in the inside or outside of the set.

But then, this would only require the CUA to convey to the CS a single LAT/LON coordinate (and a date/time value?) for the CS to calculate which set of time zones correspond to the GEO?

-- Frank --=_alternative 006E3D6F85256943_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 16:44: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 QAA15562 for ; Tue, 22 Aug 2000 16:44:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13392 for ietf-calendar-bks; Tue, 22 Aug 2000 13:31:48 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13388 for ; Tue, 22 Aug 2000 13:31:46 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id NAA03738 for ; Tue, 22 Aug 2000 13:32:07 -0700 (PDT) Message-ID: <39A2E346.A7AB1076@home.royer.com> Date: Tue, 22 Aug 2000 13:32:06 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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 had not proposed (at this time) any solution to that problem. When > >this gets worked out, I plan on sending out a draft that describes > >how GEO_BOUNDRY should be used by a CS and a CUA to find a VTIMEZONE. > > So, then your change request was not a complete RFC2445 change request? It can stand on it own. What I plan on putting in a draft is HOW you make it work. I did not think that was appropriate for property addition IANA registration form. > Shouldn't we be submitting complete change request packages, if we really > intend these to seriously considered by the WG? In addition to the iCalendar/iTIP/iMIP/CAP work, if you will recall; I am working on registering time zone names. I am at this time also creating a IANA registration process for time zones (I have 404 currently identified from the Olson tz database). I got feedback that we needed to add lat/lon information to the VTIMEZONE. So the GEO BOUNDRY can exist on its own. So no matter what the motive, the property still needs to be registered. > Or were you just using the official change request format to introduce a > new discussion? 'just' -> No that was not the plan. Discussion welcome. > The title of the thread implied the registration of a new > property with a complete proposal? I am confused now? I had planned it that way (proposal) :-) Discussion welcome. -Doug From owner-ietf-calendar@mail.imc.org Tue Aug 22 17:06:38 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 RAA15903 for ; Tue, 22 Aug 2000 17:06:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13693 for ietf-calendar-bks; Tue, 22 Aug 2000 13:49:29 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13688 for ; Tue, 22 Aug 2000 13:49:27 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id NAA03863 for ; Tue, 22 Aug 2000 13:49:44 -0700 (PDT) Message-ID: <39A2E761.C00CE410@home.royer.com> Date: Tue, 22 Aug 2000 13:49:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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: > > >> Given the political fragmentation of our fine planet, there are > likely > >> time zones with holes in the middle, or broken into several distinct > >> pieces. (GIS folks refer to these as lakes and islands.) It doesn't > >> look to me like the current proposal has any way of addressing this > >> issue. > > >I had not thought of the hole in the middle problem. > > > >Would something like "GEO_BOUNDRY_EXCEPTION: " do? > >It would describe holes. > > I seem to remember that the CGI, GKS, PHIGS computer graphics > standards had a POLYGON_SET primitive. So maybe you don't really > need the exception property? Maybe - I have not seen one that allowed holes in the middle of the polygon. Can you point me at something specific? I'll start looking now. > If you include a set of polygons there is a well know algorithm to find > out if a coordinate is in the inside or outside of the set. As the original person said ("JR" ) most are for 2-D. And since Columbus, the world ain't flat :-) So independent of the algorithm needed. We need a way to store the ever changing GEO data, which resulted in my proposal. There is at least one supplier of this data on this WG list. > But then, this would only require the CUA to convey to the > CS a single LAT/LON coordinate (and a date/time value?) for the > CS to calculate which set of time zones correspond to the GEO? Yep, but as Burce and John have pointed out. Often the user will have to choose when there is more than one VTIMEZONE that matches. -Doug From owner-ietf-calendar@mail.imc.org Tue Aug 22 22:21:35 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 WAA19887 for ; Tue, 22 Aug 2000 22:21:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA25396 for ietf-calendar-bks; Tue, 22 Aug 2000 19:08: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 TAA25392; Tue, 22 Aug 2000 19:08:20 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id WAA01886; Tue, 22 Aug 2000 22:10:06 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id WAA27756; Tue, 22 Aug 2000 22:08:12 -0400 (EDT) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 22 Aug 2000 22:07:47 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/22/2000 10:07:49 PM, Serialize complete at 08/22/2000 10:07:49 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000BB9B085256944_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000BB9B085256944_= Content-Type: text/plain; charset="us-ascii" >It can stand on it own. What I plan on putting in a draft >is HOW you make it work. I did not think that was appropriate >for property addition IANA registration form. Doug: Based on the comments you were getting, I think that a number of folks wanted to see the whole proposal, not just the abridged version. The editors will also need to see the proposed new text to be added to iCalendar. Right? -- Frank --=_alternative 000BB9B085256944_= Content-Type: text/html; charset="us-ascii"
>It can stand on it own. What I plan on putting in a draft
>is HOW you make it work. I  did not think that was appropriate
>for property addition IANA registration form.

Doug:

Based on the comments you were getting, I think that a number of folks wanted to see the whole proposal, not just the abridged version.

The editors will also need to see the proposed new text to be added to iCalendar. Right?

-- Frank --=_alternative 000BB9B085256944_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 22:26: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 WAA19912 for ; Tue, 22 Aug 2000 22:26:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA25843 for ietf-calendar-bks; Tue, 22 Aug 2000 19:12:46 -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 TAA25838 for ; Tue, 22 Aug 2000 19:12:45 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id WAA02197 for ; Tue, 22 Aug 2000 22:14:31 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id WAA28038 for ; Tue, 22 Aug 2000 22:12:36 -0400 (EDT) To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 22 Aug 2000 22:12:11 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08172000 |August 17, 2000) at 08/22/2000 10:12:13 PM, Serialize complete at 08/22/2000 10:12:13 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000C209185256944_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000C209185256944_= Content-Type: text/plain; charset="us-ascii" I don't have a reference to these graphics standards anymore. They were left in a previous job(s). You should be able to find them in your neck-of-the-woods. UCSD was one of the great CG havens. --=_alternative 000C209185256944_= Content-Type: text/html; charset="us-ascii"
I don't have a reference to these graphics standards anymore. They were left in a previous job(s). You should be able to find them in your neck-of-the-woods. UCSD was one of the great CG havens. --=_alternative 000C209185256944_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 22 22:53: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 WAA21168 for ; Tue, 22 Aug 2000 22:53:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA00235 for ietf-calendar-bks; Tue, 22 Aug 2000 19:40:49 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA00225 for ; Tue, 22 Aug 2000 19:40:47 -0700 (PDT) Received: from home.royer.com (doug@home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id TAA04613 for ; Tue, 22 Aug 2000 19:41:09 -0700 (PDT) Message-ID: <39A339C3.78A1724A@home.royer.com> Date: Tue, 22 Aug 2000 19:41:07 -0700 From: Doug Royer X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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: > > >It can stand on it own. What I plan on putting in a draft > >is HOW you make it work. I did not think that was appropriate > >for property addition IANA registration form. > > Doug: > > Based on the comments you were getting, I think that a number of folks > wanted to see the whole proposal, not just the abridged version. I can add more comments, but if you look at the registration procedure - its abridged. I will be sending out REV-2 in a couple of days after more to give time for more feedback. > The editors will also need to see the proposed new text to be added to > iCalendar. Right? No. It was not planned for iCalendar. If anything it might go into CAP. The plan was that it was just a new registered property. -Doug From owner-ietf-calendar@mail.imc.org Tue Aug 22 23:53: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 XAA22265 for ; Tue, 22 Aug 2000 23:53:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA04514 for ietf-calendar-bks; Tue, 22 Aug 2000 20:34:13 -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 UAA04505 for ; Tue, 22 Aug 2000 20:34:12 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id UAA03157 for ietf-calendar@imc.org; Tue, 22 Aug 2000 20:34:35 -0700 (PDT) Date: Tue, 22 Aug 2000 20:34:35 -0700 (PDT) From: Doug Royer Message-Id: <200008230334.UAA03157@royer.com> To: ietf-calendar@imc.org Subject: CAP draft update Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAP draft files have been updated on: ftp://royer.com/pub/CALSCH Nroff and other source files including cap.txt: ftp://royer.com/pub/CALSCH/cap.sources.tar.gz From owner-ietf-calendar@mail.imc.org Wed Aug 23 12:32: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 MAA17908 for ; Wed, 23 Aug 2000 12:32:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01535 for ietf-calendar-bks; Wed, 23 Aug 2000 09:13:10 -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 JAA01529 for ; Wed, 23 Aug 2000 09:13:09 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA10832 for ; Wed, 23 Aug 2000 12:15:08 -0400 Message-ID: <39A3F88C.D57AF386@ecal.com> Date: Wed, 23 Aug 2000 12:15:08 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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: > Ok, let me make my concern a bit sharper: I am 95% against > having the CUA doing the choosing by itself (I can think of > some cases where it MAY be ok but very very few). This is the > interop nightmare. I don't think it is an interop problem, actually; the timezone choice occurs *before* the iCalendar is composed and sent over the wire. Once it's been chosen, the iCalendar is self-contained, with a complete VTIMEZONE, so there's no ambiguity. In any case, there is simply no way to eliminate all the cases where it has to be left up to the user. Someone gave me some examples in a private message (I had just been speculating), and, for one of them, what timezone you followed depended on your politics! Try feeding *that* into the CS. :-) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Illiterate? Write today for free help! | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 23 12:36: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 MAA17983 for ; Wed, 23 Aug 2000 12:36:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02548 for ietf-calendar-bks; Wed, 23 Aug 2000 09:21:00 -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 JAA02542 for ; Wed, 23 Aug 2000 09:20:59 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA10852 for ; Wed, 23 Aug 2000 12:22:58 -0400 Message-ID: <39A3FA62.34FA8A57@ecal.com> Date: Wed, 23 Aug 2000 12:22:58 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS References: <39A2E761.C00CE410@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Frank_Dawson@lotus.com wrote: > > > > I seem to remember that the CGI, GKS, PHIGS computer graphics > > standards had a POLYGON_SET primitive. So maybe you don't really > > need the exception property? > > Maybe - I have not seen one that allowed holes in the middle > of the polygon. A polygon with one hole in the middle can be expressed as the union of two polygons with no holes. (Side note to those who think I should be saying "polygonal region" rather than "polygon": you're probably right. :-) For example, say you've got a large square with a small square hole in the middle. If you slice the figure in two, with a vertical line down the middle, then you have two holeless polygons (one is a vertical rectangle with two small rectangles sticking out to the right; the other is its mirror image). You can also come up with other partitions, of course. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This space intentionally not left blank. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 24 05:19: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 FAA13332 for ; Thu, 24 Aug 2000 05:19:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA08467 for ietf-calendar-bks; Thu, 24 Aug 2000 02:06:45 -0700 (PDT) Received: from web2105.mail.yahoo.com (web2105.mail.yahoo.com [128.11.68.249]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA08462 for ; Thu, 24 Aug 2000 02:06:44 -0700 (PDT) Received: (qmail 13779 invoked by uid 60001); 24 Aug 2000 09:07:14 -0000 Message-ID: <20000824090714.13778.qmail@web2105.mail.yahoo.com> Received: from [212.161.95.33] by web2105.mail.yahoo.com; Thu, 24 Aug 2000 02:07:14 PDT Date: Thu, 24 Aug 2000 02:07:14 -0700 (PDT) From: =?iso-8859-1?q?Chris=20Harris?= Reply-To: christopher.harris@bigfoot.com Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS To: ietf-calendar@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > I have not made an assertion that everyplace on earth > has a time zone. I have no idea if it is true or false. A point of intellectual curiosity - what time zone is the North Pole in? Isn't it where they all meet? Does your time zone then depend on which way you're facing? c __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-ietf-calendar@mail.imc.org Fri Aug 25 08:37: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 IAA18811 for ; Fri, 25 Aug 2000 08:37:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA01928 for ietf-calendar-bks; Fri, 25 Aug 2000 05:12:37 -0700 (PDT) Received: from flemings.com.br ([200.255.85.3]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA01877; Fri, 25 Aug 2000 05:12:07 -0700 (PDT) From: HomeOwners@zkan.fsnet.co.uk Received: from x134 by flemings.com.br (Lotus SMTP MTA v1.1 (385.6 5-6-1997)) with SMTP id 03256946.00401BEDó; Tue, 25 Aug 1970 08:40:54 -0300 Message-ID: <0000075e701d$00004b58$00004e0f@150> To: Subject: Homeowners: Get The Money You Need! Date: Fri, 25 Aug 2000 05:07:52 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable

Fo= r Homeowners Only
Save Now!

Dear Homeown= er,

If you are in debt or need extra cash, we can help you get the money= you have been hoping for.
Our services are FREE and we have already helped thousands of hom= eowners, just like you.


Best Of All...

*Our lenders offer the Lowest Interest Rates available
*They can set you up with an incredibly low monthly payment!
*We can provide you with Lenders who will loan you ...

Up To 125% Of Your Home's Value!

Click Here To Request Your FRE= E Quote!

And even better, there are NO Advances= or Upfront Fees of any kind!
This means you won't pay a dime - so you have absolutely nothing to lose!


Here are just some of the ways you could put this cash to use:

-> Home Improvements
-> Credit Card Debt
-> College Tuition
-> Dream Vacation
-> A New Car
-> Start Your Own Business
...or whatever else you need - it's up to YOU.

So if you're serious about improving your current fin= ancial position, you owe it to yourself to request your FREE 
Loan Evaluation. It's FREE and you've got nothing to lose. Right n= ow, while it's fresh in your mind, visit our site.

 

Cl= ick Here To Request Your FREE Quote!

We take great pride in offering such prompt and quality service to you an= d your family.

Sincerely,
The Mortgage Guys

 

To unsubscribe from our mailing list, please click here!

From owner-ietf-calendar@mail.imc.org Sun Aug 27 03:20:16 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 DAA01842 for ; Sun, 27 Aug 2000 03:20:14 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA03983 for ietf-calendar-bks; Sat, 26 Aug 2000 23:59:31 -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 XAA03973 for ; Sat, 26 Aug 2000 23:59:29 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA18564 for ietf-calendar@imc.org; Sun, 27 Aug 2000 00:00:03 -0700 (PDT) Date: Sun, 27 Aug 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200008270700.AAA18564@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 draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) 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! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ 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 Tuesday discussion: DONE Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. DONE Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). DONE Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) DONE Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. DONE Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text DONE Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 DONE Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. DONE Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Mon Aug 28 01:15:46 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 BAA18730 for ; Mon, 28 Aug 2000 01:15:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02470 for ietf-calendar-bks; Sun, 27 Aug 2000 21:55:40 -0700 (PDT) Received: from agony.dyn.dhs.org (IDENT:root@dt010n4b.san.rr.com [204.210.12.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA02466 for ; Sun, 27 Aug 2000 21:55:39 -0700 (PDT) From: eric@softwarestudio.org Received: from localhost (eric@localhost) by agony.dyn.dhs.org (8.9.3/8.9.3) with ESMTP id VAA06140 for ; Sun, 27 Aug 2000 21:56:23 -0700 X-Authentication-Warning: agony.dyn.dhs.org: eric owned process doing -bs Date: Sun, 27 Aug 2000 21:56:22 -0700 (PDT) X-Sender: eric@agony.dyn.dhs.org To: ietf-calendar@imc.org Subject: iTIP: Who sent that message? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: How do you determine who sent a COUNTER message? A COUNTER message can have multiple ATTENDEE properties, and it will not have come from teh ORGANIZER, so there is apparently no unambiguous, in-band way to determine who sent the message. This makes it tough to send back a response to the COUNTER message if your architecture involves storing incomming messages in a file and processing them later. Of course, I could add an X- property to the component to indicate who sent the message, but I really think that the information should be part of the message. Am I missing something, or is this worthy of an additional parameter for ATTENDEE? eric. From owner-ietf-calendar@mail.imc.org Mon Aug 28 11:28: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 LAA12781 for ; Mon, 28 Aug 2000 11:28:27 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA16723 for ietf-calendar-bks; Mon, 28 Aug 2000 08:01: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 IAA16719 for ; Mon, 28 Aug 2000 08:01:15 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: eric@softwarestudio.org Cc: ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Mon, 28 Aug 2000 11:06:36 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/28/2000 11:07:02 AM, Serialize complete at 08/28/2000 11:07:03 AM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/28/2000 11:07:03 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00529F2685256949_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00529F2685256949_= Content-Type: text/plain; charset="us-ascii" Eric astutely asked: >How do you determine who sent a COUNTER message? Well it seems that some folks are actually reading the RFCs before they implement them. As the text of 3.2.7 COUNTER and 4.2.4 Countering an Event Proposal show, there is NO mechanism for determining this in iTIP. The best answers I could find are: "It's FM", a wild guess, or the use of external meta information (ie: the "Sender: ..." MIME header from the iMIP message, etc). This appears to be another sight that came from simplifying the original proposed iTIP message set down to the "minimal" set in the RFCs. Chalk it up on the list of errata that needs to be dealt with. A simpler solution that some appear to have taken is to NOT allow COUNTERing but I dont consider that viable in a real C&S system... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00529F2685256949_= Content-Type: text/html; charset="us-ascii"
Eric astutely asked:
>How do you determine who sent a COUNTER message?

Well it seems that some folks are actually reading the RFCs before they implement them.  As the text of 3.2.7 COUNTER and 4.2.4 Countering an Event Proposal show, there is NO mechanism for determining this in iTIP.  

The best answers I could find are: "It's FM", a wild guess, or the use of external meta information (ie: the "Sender: ..." MIME header from the iMIP message, etc).  

This appears to be another sight that came from simplifying the original proposed iTIP message set down to the "minimal" set in the RFCs.  Chalk it up on the list of errata that needs to be dealt with.

A simpler solution that some appear to have taken is to NOT allow COUNTERing but I dont consider that viable in a real C&S system...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00529F2685256949_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 12:21: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 MAA14588 for ; Mon, 28 Aug 2000 12:21:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA21640 for ietf-calendar-bks; Mon, 28 Aug 2000 08:56:13 -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 IAA21632; Mon, 28 Aug 2000 08:56:12 -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 LAA03057; Mon, 28 Aug 2000 11:58:34 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA10752; Mon, 28 Aug 2000 11:56:30 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: eric@softwarestudio.org, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 28 Aug 2000 11:55:53 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/28/2000 11:56:07 AM, Serialize complete at 08/28/2000 11:56:08 AM, Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/28/2000 11:56:08 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00578CBC85256949_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00578CBC85256949_= Content-Type: text/plain; charset="us-ascii" Bruce: I believe that the original idea was that the only ATTENDEE properties would be the originator and the chair who is receiving the COUNTER. But as written in RFC 2446, I agree that this is an issue needing clarification (mere fixing text) or a change request (change functionality if we consider what is written to be what the other authors intended). -- Frank --=_alternative 00578CBC85256949_= Content-Type: text/html; charset="us-ascii"
Bruce:

I believe that the original idea was that the only ATTENDEE properties would be the originator and the chair who is receiving the COUNTER.

But as written in RFC 2446, I agree that this is an issue needing clarification (mere fixing text) or a change request (change functionality if we consider what is written to be what the other authors intended).

-- Frank --=_alternative 00578CBC85256949_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 12:55: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 MAA15595 for ; Mon, 28 Aug 2000 12:55:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23711 for ietf-calendar-bks; Mon, 28 Aug 2000 09:34:05 -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 JAA23697 for ; Mon, 28 Aug 2000 09:33:32 -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 MAA26171; Mon, 28 Aug 2000 12:32:28 -0400 Received: from cst.ca (cc-1106.int.cst.ca [192.168.1.105]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RAYK448R; Mon, 28 Aug 2000 12:32:27 -0400 Message-ID: <39AA941B.776C7B38@cst.ca> Date: Mon, 28 Aug 2000 12:32:27 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Royer CC: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP References: <39A2A603.5C7B6E02@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: [snip] > Group Do we do 2 separate properties? > > -Doug At our last CAP editors meeting we agreed that we support two separate properties. However, should the property be at the attendee level? This would be to allow an attendee to specify whether someone can double book the attendee at the same time slot the event occurs. It can look something like: ATTENDEE:CONFLICT=FALSE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal The default can be true (allow conflicts). The user may be able to change his or her default, i.e., have a calendar wide CONFLICT property. Or perhaps it should go into VCARs, i.e., allow or disallow UPNs to double book a user. Comments? George From owner-ietf-calendar@mail.imc.org Mon Aug 28 13:09: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 MAA15631 for ; Mon, 28 Aug 2000 12:56:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23767 for ietf-calendar-bks; Mon, 28 Aug 2000 09:37:53 -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 JAA23762 for ; Mon, 28 Aug 2000 09:37:49 -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 MAA26213 for ; Mon, 28 Aug 2000 12:38:09 -0400 Received: from cst.ca (cc-1106.int.cst.ca [192.168.1.105]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RAYK4488; Mon, 28 Aug 2000 12:38:07 -0400 Message-ID: <39AA956F.BBD68EDB@cst.ca> Date: Mon, 28 Aug 2000 12:38:07 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS References: <39A291A5.E64FC4C0@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: [snip] > I think that "REQUEST-STATUS:2.0;" would be acceptable. > > -Doug Its fine by me also. If there are no more objections, I will repost the registration for the property with the above change. George From owner-ietf-calendar@mail.imc.org Mon Aug 28 13:10: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 MAA15617 for ; Mon, 28 Aug 2000 12:56:24 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23445 for ietf-calendar-bks; Mon, 28 Aug 2000 09:24:39 -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 JAA23441 for ; Mon, 28 Aug 2000 09:24:37 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: Frank_Dawson@lotus.com Cc: eric@softwarestudio.org, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Mon, 28 Aug 2000 12:29:59 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/28/2000 12:30:16 PM, Serialize complete at 08/28/2000 12:30:16 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005A416785256949_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A416785256949_= Content-Type: text/plain; charset="us-ascii" Frank suggested: >I believe that the original idea was that the only ATTENDEE >properties would be the originator and the chair who is >receiving the COUNTER. That may be if I you take 3.2.7 COUNTER strictly by what it claimed: The "COUNTER" method for a "VEVENT" calendar component is used by an "Attendee" of an existing event to submit to the "Organizer" a counter proposal to the event description. but the restriction table clearly states: ATTENDEE 0+ Can also be used to propose other "Attendees" and this is a good thing. This ability is clearly one that C&S needs to have ("Hey Frank, dont forget to invite the new RFC co-editor to the conference call!") w/o relying on OOB means. >I agree that this is an issue needing clarification (mere fixing >text) or a change request (change functionality if we consider >what is written to be what the other authors intended). Given that the iTIP messages are 'full snapshots' of the entry (including COUNTER, see the actual examples under 4.2.4 Countering an Event Proposal), I think some new text is in order. If the COUNTER were _not_ a full snapshot then how could B suggest adding new ATTENDEEs and removing others all in the same COUNTER? However mere text changes wont solve the problem (without removing funtionality), since neither 2445 or 2446 have any means to convey the senders identity in this case. First blush would seem to indicate that a new property is necessary but not inside the vEvent, etc. but rather at the outer 'container' level. A few more cycles yeilds the concept of a property parameter on the METHOD (ie: METHOD;SENT-BY="mailto:B@example.com":COUNTER) but Im only tossing out ideas; not doing the actual redesign now... Bruce PS: Just why is the restriction table 0+ instead of 1+?? =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005A416785256949_= Content-Type: text/html; charset="us-ascii"
Frank suggested:
>I believe that the original idea was that the only ATTENDEE
>properties would be the originator and the chair who is
>receiving the COUNTER.

That may be if I you take 3.2.7 COUNTER strictly by what it claimed:

   The "COUNTER" method for a "VEVENT" calendar component is used by an
  "Attendee" of an existing event to submit to the "Organizer" a
  counter proposal to the event description.

but the restriction table clearly states:

    ATTENDEE        0+      Can also  be used to propose other
                           "Attendees"

and this is a good thing.  This ability is clearly one that C&S needs to have ("Hey Frank, dont forget to invite the new RFC co-editor to the conference call!") w/o relying on OOB means.

>I agree that this is an issue needing clarification (mere fixing
>text) or a change request (change functionality if we consider
>what is written to be what the other authors intended).

Given that the iTIP messages are 'full snapshots' of the entry (including COUNTER, see the actual examples under 4.2.4 Countering an Event Proposal), I think some new text is in order.  If the COUNTER were _not_ a full snapshot then how could B suggest adding new ATTENDEEs and removing others all in the same COUNTER?  However mere text changes wont solve the problem (without removing funtionality), since neither 2445 or 2446 have any means to convey the senders identity in this case.  

First blush would seem to indicate that a new property is necessary but not inside the vEvent, etc. but rather at the outer 'container' level.  A few more cycles yeilds the concept of a property parameter on the METHOD (ie: METHOD;SENT-BY="mailto:B@example.com":COUNTER) but Im only tossing out ideas; not doing the actual redesign now...

Bruce
PS: Just why is the restriction table 0+ instead of 1+??
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005A416785256949_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 14:41: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 OAA18136 for ; Mon, 28 Aug 2000 14:41:19 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA25529 for ietf-calendar-bks; Mon, 28 Aug 2000 11:20:50 -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 LAA25523 for ; Mon, 28 Aug 2000 11:20:43 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7SIBAe15667 for ; Mon, 28 Aug 2000 11:11:10 -0700 (PDT) Received: from netscape.com ([192.18.125.171]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G00LN302.T1V; Mon, 28 Aug 2000 11:21:03 -0700 Message-ID: <39AAAD85.367ECC9C@netscape.com> Date: Mon, 28 Aug 2000 11:20:53 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: eric@softwarestudio.org, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? References: Content-Type: multipart/mixed; boundary="------------AB52435C5915915FD34CA711" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AB52435C5915915FD34CA711 Content-Type: multipart/alternative; boundary="------------533C712F18A7FCF0090D7284" --------------533C712F18A7FCF0090D7284 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > Eric astutely asked: > >How do you determine who sent a COUNTER message? > > Well it seems that some folks are actually reading the RFCs before > they implement them. As the text of 3.2.7 COUNTER and 4.2.4 > Countering an Event Proposal show, there is NO mechanism for > determining this in iTIP. > > The best answers I could find are: "It's FM", a wild guess, or the use > of external meta information (ie: the "Sender: ..." MIME header from > the iMIP message, etc). > > This appears to be another sight that came from simplifying the > original proposed iTIP message set down to the "minimal" set in the > RFCs. Chalk it up on the list of errata that needs to be dealt with. > > A simpler solution that some appear to have taken is to NOT allow > COUNTERing but I dont consider that viable in a real C&S system... This is a proposed update as pointed out in my message to the list on Aug 10, 2000. Here is an excerpt from that message 2. Identify sender of iTIP COUNTER: Problem: You can't identify which Attendee a COUNTER message came from because all of the Attendees will appear in the component. Proposal 1: Restrict the COUNTER message so that it can only specify the ORGANIZER and countering ATTENDEE. Note: You can still forward (party crashing, remember? :-) or delegate a REQUEST to change participants. However, only the ORGANIZER can remove a participant. The down side to this approach is that you can't change the Attendees. This removes functionality. The up side is that it requires no changes to iCalendar. Proposal 2: Add a new parameter to the ATTENDEE property: ATTCOUNTER. It can only be specified (a) when the component method is COUNTER and (b) for the one Attendee who issued the COUNTER. Note: The good news is that no functionality is lost -- you can suggest a different attendee list. The down side is that we have to update iCalendar with a new parameter. So far, there's been one reply to the list favoring proposal 2, plus I've received one private reply favoring proposal 2. This is the one I was planning to write up for the updated iTIP spec. -Steve --------------533C712F18A7FCF0090D7284 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

Eric astutely asked:
>How do you determine who sent a COUNTER message?

Well it seems that some folks are actually reading the RFCs before they implement them.  As the text of 3.2.7 COUNTER and 4.2.4 Countering an Event Proposal show, there is NO mechanism for determining this in iTIP.

The best answers I could find are: "It's FM", a wild guess, or the use of external meta information (ie: the "Sender: ..." MIME header from the iMIP message, etc).

This appears to be another sight that came from simplifying the original proposed iTIP message set down to the "minimal" set in the RFCs.  Chalk it up on the list of errata that needs to be dealt with.

A simpler solution that some appear to have taken is to NOT allow COUNTERing but I dont consider that viable in a real C&S system...

This is a proposed update as pointed out in my message to the list on Aug 10, 2000.  Here is an excerpt from that message
2. Identify sender of iTIP COUNTER:
Problem: You can't identify which Attendee a COUNTER message came from because all of the Attendees will appear in the component.

Proposal 1:  Restrict the COUNTER message so that it can only specify the ORGANIZER and countering ATTENDEE.

Note: You can still forward (party crashing, remember? :-) or delegate a REQUEST to change participants. However, only the ORGANIZER can remove a participant.  The down side to this approach is that you can't change the Attendees. This removes functionality.  The up side is that it requires no changes to iCalendar.

Proposal 2: Add a new parameter to the ATTENDEE property:  ATTCOUNTER.  It can only be specified (a) when the component method is COUNTER and (b) for the one Attendee who issued the COUNTER.

Note: The good news is that no functionality is lost -- you can suggest a different attendee list.  The down side is that we have to update iCalendar with a new parameter.

So far, there's been one reply to the list favoring proposal 2, plus I've received one private reply favoring proposal 2.  This is the one I was planning to write up for the updated iTIP spec.

-Steve --------------533C712F18A7FCF0090D7284-- --------------AB52435C5915915FD34CA711 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 tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------AB52435C5915915FD34CA711-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 14:43:35 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 OAA18206 for ; Mon, 28 Aug 2000 14:43:35 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA25635 for ietf-calendar-bks; Mon, 28 Aug 2000 11:24:51 -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 LAA25627 for ; Mon, 28 Aug 2000 11:24:44 -0700 (PDT) From: Bruce_Kahn@iris.com To: George Babics Cc: Doug Royer , ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Mon, 28 Aug 2000 14:28:58 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/28/2000 02:30:28 PM, Serialize complete at 08/28/2000 02:30:29 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/28/2000 02:30:29 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0065261A85256949_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065261A85256949_= Content-Type: text/plain; charset="us-ascii" George asked: > However, should the property be at the attendee level? >[Snip]It can look something like: > > ATTENDEE:CONFLICT=FALSE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal This is probably too fine a level to put it at; allowing the Organizer to say that I may not double book the time but Doug or Frank can. I would think that the value would be better suited as a property of the entry that applies equally to all: BEGIN:VEVENT CONLICTS:FALSE ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal ... I would also suggest that the property convey the Organizers desire but is not required to be observed. For example, I may decide that I would want CONFLICT:TRUE for this entry since I only tentatively accepted it. This is similar to the Organizer classifying the entry as TRANSP:OPAQUE but I change it to TRANSP:TRANSPARENT because Im tentatively going or because I do not want it to affect my busytime when others check. The Organzier can convey intent or desire but cannot rule the Attendees world; at least not in this respect. >The user may be able to >change his or her default, i.e., have a calendar wide CONFLICT property. CAP Editors: Please be sure that when CAP addresses this issue of both calendar level policy (ie: A room cannot be double booked but a user can be) and the entry level policy (ie: "You already have an entry for that time slot that precludes overbooking this time"). It should allow some flexibility in dealing with both as well as just resolving single cases. For example, if I have an event conflict but no calendar level policy then I would expect some reasonable behaviour (ie: "Do you want to A) Reschedule this entry, B) Reschedule that entry, C) Double book anyways or...") to be achievable w/o making the CUA jump thru tons of hoops (ie: First I must change the blocking entry to CONFLICT:TRUE then I have to resave the conflicting one and finally I change CONFLICT:FALSE on the blocker. Ugh!!!) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0065261A85256949_= Content-Type: text/html; charset="us-ascii"
George asked:
>   However, should the property be at the attendee level?
>[Snip]It can look something like:
>
>   ATTENDEE:CONFLICT=FALSE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal

This is probably too fine a level to put it at; allowing the Organizer to say that I may not double book the time but Doug or Frank can.  I would think that the value would be better suited as a property of the entry that applies equally to all:

BEGIN:VEVENT
CONLICTS:FALSE
ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal
...

  I would also suggest that the property convey the Organizers desire but is not required to be observed.  For example, I may decide that I would want CONFLICT:TRUE for this entry since I only tentatively accepted it.  This is similar to the Organizer classifying the entry as TRANSP:OPAQUE but I change it to TRANSP:TRANSPARENT because Im tentatively going or because I do not want it to affect my busytime when others check.  The Organzier can convey intent or desire but cannot rule the Attendees world; at least not in this respect.

>The user may be able to
>change his or her default, i.e., have a calendar wide CONFLICT property.

CAP Editors: Please be sure that when CAP addresses this issue of both calendar level policy (ie: A room cannot be double booked but a user can be) and the entry level policy (ie: "You already have an entry for that time slot that precludes overbooking this time").  It should allow some flexibility in dealing with both as well as just resolving single cases.  

For example, if I have an event conflict but no calendar level policy then I would expect some reasonable behaviour (ie: "Do you want to A) Reschedule this entry, B) Reschedule that entry, C) Double book anyways or...") to be achievable w/o making the CUA jump thru tons of hoops (ie: First I must change the blocking entry to CONFLICT:TRUE then I have to resave the conflicting one and finally I change CONFLICT:FALSE on the blocker.  Ugh!!!)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0065261A85256949_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 15:47: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 PAA19299 for ; Mon, 28 Aug 2000 15:47:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA26913 for ietf-calendar-bks; Mon, 28 Aug 2000 12:30:28 -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 MAA26909 for ; Mon, 28 Aug 2000 12:30:26 -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 PAA27947; Mon, 28 Aug 2000 15:30:09 -0400 Received: from cst.ca (cc-1106.int.cst.ca [192.168.1.105]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RAYK4VP8; Mon, 28 Aug 2000 15:30:08 -0400 Message-ID: <39AABDC1.3C1B880C@cst.ca> Date: Mon, 28 Aug 2000 15:30:09 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: Doug Royer , ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP 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: > > George asked: > > However, should the property be at the attendee level? > >[Snip]It can look something like: > > > > ATTENDEE:CONFLICT=FALSE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal > > This is probably too fine a level to put it at; allowing the Organizer to say that I may not double book the time but > Doug or Frank can. I would think that the value would be better suited as a property of the entry that applies > equally to all: > > BEGIN:VEVENT > CONLICTS:FALSE > ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal > ... > > I would also suggest that the property convey the Organizers desire but is not required to be observed. For > example, I may decide that I would want CONFLICT:TRUE for this entry since I only tentatively accepted it. This is > similar to the Organizer classifying the entry as TRANSP:OPAQUE but I change it to TRANSP:TRANSPARENT because Im > tentatively going or because I do not want it to affect my busytime when others check. The Organzier can convey > intent or desire but cannot rule the Attendees world; at least not in this respect. I meant that it is the attendee that sets the value of CONFLICT like it does for PARTSTAT. That is, the attendee, and not the Organizer, who decides whether one may double book that attendee at that time. The Organizer can still give a suggestion of whether double booking be allowed or not. > > >The user may be able to > >change his or her default, i.e., have a calendar wide CONFLICT property. > > CAP Editors: Please be sure that when CAP addresses this issue of both calendar level policy (ie: A room cannot be > double booked but a user can be) and the entry level policy (ie: "You already have an entry for that time slot that > precludes overbooking this time"). It should allow some flexibility in dealing with both as well as just resolving > single cases. > > For example, if I have an event conflict but no calendar level policy then I would expect some reasonable behaviour > (ie: "Do you want to A) Reschedule this entry, B) Reschedule that entry, C) Double book anyways or...") to be > achievable w/o making the CUA jump thru tons of hoops (ie: First I must change the blocking entry to CONFLICT:TRUE > then I have to resave the conflicting one and finally I change CONFLICT:FALSE on the blocker. Ugh!!!) > > 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 Mon Aug 28 16:42: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 QAA20244 for ; Mon, 28 Aug 2000 16:42:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA27825 for ietf-calendar-bks; Mon, 28 Aug 2000 13:22:00 -0700 (PDT) Received: from agony.dyn.dhs.org (IDENT:root@24-25-200-241.san.rr.com [24.25.200.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27821 for ; Mon, 28 Aug 2000 13:21:58 -0700 (PDT) Received: from localhost (eric@localhost) by agony.dyn.dhs.org (8.9.3/8.9.3) with ESMTP id NAA07184; Mon, 28 Aug 2000 13:22:22 -0700 X-Authentication-Warning: agony.dyn.dhs.org: eric owned process doing -bs Date: Mon, 28 Aug 2000 13:22:22 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.dyn.dhs.org To: Steve Mansour cc: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? In-Reply-To: <39AAAD85.367ECC9C@netscape.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 28 Aug 2000, Steve Mansour wrote: > This is a proposed update as pointed out in my message to the list on > Aug 10, 2000. Here is an excerpt from that message > > 2. Identify sender of iTIP COUNTER: Oh, sorry. It felt like a dumb question when I asked it, but I couldn't figure out why.... > Proposal 1: Restrict the COUNTER message so that it > can only specify the ORGANIZER and countering > ATTENDEE. > Proposal 2: Add a new parameter to the ATTENDEE > property: ATTCOUNTER. It can only be specified (a) > when the component method is COUNTER and (b) for the > one Attendee who issued the COUNTER. > I've received one private reply favoring proposal 2. This is the one I > was planning to write up for the updated iTIP spec. Proposal 2 sounds OK, but perhaps it could be generalized by just using the existing SENT-BY parameter? It would be awkward, since you'd have the calid in the property line twice ( once as a value and once in the SENT-BY parameter) but it does solve the problem with minimal changes, since SENT-BY is already spec'd for use in ATTENDEE. We'd just be overloading the semantics a bit. eric. From owner-ietf-calendar@mail.imc.org Mon Aug 28 17:02: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 RAA20548 for ; Mon, 28 Aug 2000 17:02:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA28169 for ietf-calendar-bks; Mon, 28 Aug 2000 13:44:49 -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 NAA28165 for ; Mon, 28 Aug 2000 13:44:48 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7SKdJY21073 for ; Mon, 28 Aug 2000 13:39:19 -0700 (PDT) Received: from netscape.com ([192.18.125.171]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G00SB901.G57; Mon, 28 Aug 2000 13:45:09 -0700 Message-ID: <39AACF46.5169ED0A@netscape.com> Date: Mon, 28 Aug 2000 13:44:55 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Eric Busboom CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? References: Content-Type: multipart/mixed; boundary="------------12AE47340262044106D2E5CB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------12AE47340262044106D2E5CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric Busboom wrote: > On Mon, 28 Aug 2000, Steve Mansour wrote: > > ... > > Proposal 2: Add a new parameter to the ATTENDEE > > property: ATTCOUNTER. It can only be specified (a) > > when the component method is COUNTER and (b) for the > > one Attendee who issued the COUNTER. > > > I've received one private reply favoring proposal 2. This is the one I > > was planning to write up for the updated iTIP spec. > > Proposal 2 sounds OK, but perhaps it could be generalized by just using > the existing SENT-BY parameter? It would be awkward, since you'd have the > calid in the property line twice ( once as a value and once in the SENT-BY > parameter) but it does solve the problem with minimal changes, since > SENT-BY is already spec'd for use in ATTENDEE. We'd just be overloading > the semantics a bit. Yea, overloading SENT-BY is sure to come back to haunt us. Remember that an Event may already have several ATTENDEEs with SENT-BY parameters. We still need to figure out which SENT-BY is sending the COUNTER. Will the person doing the COUNTER have to strip out all SENT-BY info? Probably not a good idea. Is the ATTCOUNTER param OK with you, Eric? Bruce? -Steve --------------12AE47340262044106D2E5CB 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 tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------12AE47340262044106D2E5CB-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 17:46: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 RAA21071 for ; Mon, 28 Aug 2000 17:46:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA28845 for ietf-calendar-bks; Mon, 28 Aug 2000 14:29:49 -0700 (PDT) Received: from agony.dyn.dhs.org (IDENT:root@24-25-200-241.san.rr.com [24.25.200.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28841 for ; Mon, 28 Aug 2000 14:29:48 -0700 (PDT) Received: from localhost (eric@localhost) by agony.dyn.dhs.org (8.9.3/8.9.3) with ESMTP id OAA07274; Mon, 28 Aug 2000 14:30:29 -0700 X-Authentication-Warning: agony.dyn.dhs.org: eric owned process doing -bs Date: Mon, 28 Aug 2000 14:30:29 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.dyn.dhs.org To: Steve Mansour cc: CalSched IETF Subject: Re: Updates to iTIP/iMIP RFCs In-Reply-To: <39932418.CE1A2657@netscape.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 10 Aug 2000, Steve Mansour wrote: > 1. Overloading iTIP REQUEST: > Proposal: Add a new method: CONFIRM. It would be used to (a) > reply to a REFRESH and (b) notify participants of any changes > to ATTENDEE or ORGANIZER. All other "reschedule" or "update" > changes MUST use REQUEST method. I understand using CONFIRM for the reply to a REFRESH, but it seems odd to use it to change ATTENDEEs or the ORGANIZER, while other types of changes still fall under REQUEST. As long as we are breaking up the REQUEST method, I'd like to see the reschedule and update tasks broken out with a new METHOD, say UPDATE. This would mirror the conceptual difference between a new request and a change to a scheduled meeting. Then, case (b) above would fall under UPDATE Also, new methods would make the components easier for a human to understand. Some of the utility of having a human readable component is lost because a human can't look at a request message and figure out what it is really for. An UPDATE method would make the purpose of the component more clear. ( Er, or does SEQUENCE != 0 always imply UPDATE? ) eric. From owner-ietf-calendar@mail.imc.org Mon Aug 28 22:25: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 WAA24541 for ; Mon, 28 Aug 2000 22:25:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12546 for ietf-calendar-bks; Mon, 28 Aug 2000 19:07:52 -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 TAA12537; Mon, 28 Aug 2000 19:07:51 -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 WAA22096; Mon, 28 Aug 2000 22:10:15 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id WAA10914; Mon, 28 Aug 2000 22:08:13 -0400 (EDT) To: Eric Busboom Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 28 Aug 2000 22:07:49 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/28/2000 10:07:49 PM, Serialize complete at 08/28/2000 10:07:50 PM, Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/28/2000 10:07:50 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000BBD168525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000BBD168525694A_= Content-Type: text/plain; charset="us-ascii" >Proposal 2 sounds OK, but perhaps it could be generalized by just using >the existing SENT-BY parameter? This changes the semantics of the SENT-BY parameter. Don't like this idea. -- Frank --=_alternative 000BBD168525694A_= Content-Type: text/html; charset="us-ascii"
>Proposal 2 sounds OK, but perhaps it could be generalized by just using
>the existing SENT-BY parameter?

This changes the semantics of the SENT-BY parameter. Don't like this idea.

-- Frank --=_alternative 000BBD168525694A_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 22:25: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 WAA24554 for ; Mon, 28 Aug 2000 22:25:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12362 for ietf-calendar-bks; Mon, 28 Aug 2000 19:06: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 TAA12350 for ; Mon, 28 Aug 2000 19:06: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 WAA22000; Mon, 28 Aug 2000 22:08:50 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id WAA10808; Mon, 28 Aug 2000 22:06:48 -0400 (EDT) To: sman@netscape.com (Steve Mansour) Cc: Bruce_Kahn@iris.com, eric@softwarestudio.org, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 28 Aug 2000 22:06:18 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/28/2000 10:06:24 PM, Serialize complete at 08/28/2000 10:06:24 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000B99628525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000B99628525694A_= Content-Type: text/plain; charset="us-ascii" Lesson learned for our next protocol... Separate out the routing information from the content information! -- Frank --=_alternative 000B99628525694A_= Content-Type: text/html; charset="us-ascii"
Lesson learned for our next protocol...

Separate out the routing information from the content information!

-- Frank --=_alternative 000B99628525694A_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 22:29: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 WAA24596 for ; Mon, 28 Aug 2000 22:29:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13453 for ietf-calendar-bks; Mon, 28 Aug 2000 19:14: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 TAA13446; Mon, 28 Aug 2000 19:14: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 WAA22341; Mon, 28 Aug 2000 22:17:07 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id WAA11303; Mon, 28 Aug 2000 22:15:05 -0400 (EDT) To: Eric Busboom Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: Updates to iTIP/iMIP RFCs X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 28 Aug 2000 22:14:37 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/28/2000 10:14:41 PM, Serialize complete at 08/28/2000 10:14:41 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000C5C6C8525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000C5C6C8525694A_= Content-Type: text/plain; charset="us-ascii" >I understand using CONFIRM for the reply to a REFRESH, but it seems odd to >use it to change ATTENDEEs or the ORGANIZER, while other types of changes >still fall under REQUEST. I missed something...I wasn't aware that the CONFIRM would be used to add or delete the ATTENDEE properties, only to update the ;PARTSTAT parameter. Others: RIGHT? -- Frank --=_alternative 000C5C6C8525694A_= Content-Type: text/html; charset="us-ascii"
>I understand using CONFIRM for the reply to a REFRESH, but it seems odd to
>use it to change ATTENDEEs or the ORGANIZER, while other types of changes
>still fall under REQUEST.

I missed something...I wasn't aware that the CONFIRM would be used to add or delete the ATTENDEE properties, only to update the ;PARTSTAT parameter.

Others: RIGHT?

-- Frank --=_alternative 000C5C6C8525694A_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 22:29: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 WAA24608 for ; Mon, 28 Aug 2000 22:29:32 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA13168 for ietf-calendar-bks; Mon, 28 Aug 2000 19:12: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 TAA13164; Mon, 28 Aug 2000 19:12:56 -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 WAA22264; Mon, 28 Aug 2000 22:15:20 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id WAA11178; Mon, 28 Aug 2000 22:13:17 -0400 (EDT) To: Eric Busboom Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: Updates to iTIP/iMIP RFCs X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 28 Aug 2000 22:12:52 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/28/2000 10:12:53 PM, Serialize complete at 08/28/2000 10:12:54 PM, Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/28/2000 10:12:54 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000C33948525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000C33948525694A_= Content-Type: text/plain; charset="us-ascii" >As long as we are breaking up the REQUEST method, I'd like to see the >reschedule and update tasks broken out with a new METHOD, say UPDATE. This >would mirror the conceptual difference between a new request and a change >to a scheduled meeting. Then, case (b) above would fall under UPDATE So, you get an UPDATE for an event that you don't have in your calendar? Is it to be ignored? I prefer the current semantics of REQUEST for invitations and rescheduling. A "rescheduling" of an event for a person that is just now being invited is just an "invitation" or REQUEST. Keeping rescheduling and invitations as REQUEST seems more appropriate. However, updates to the ;PARTSTAT parameter or the STATUS property seems quite different and is the semantics of a CONFIRMation in many a C&S system. This seems to also be aliased in the current reuse of the REQUEST. One is hardpressed today to figure out if a REQUEST is for an invitation/reschedule or for a confirmation/status update. This distinction clearly needs to be clarified with the proposed change request. -- Frank --=_alternative 000C33948525694A_= Content-Type: text/html; charset="us-ascii"
>As long as we are breaking up the REQUEST method, I'd like to see the
>reschedule and update tasks broken out with a new METHOD, say UPDATE. This
>would mirror the conceptual difference between a new request and a change
>to a scheduled meeting. Then, case (b) above would fall under UPDATE

So, you get an UPDATE for an event that you don't have in your calendar? Is it to be ignored?

I prefer the current semantics of REQUEST for invitations and rescheduling. A "rescheduling" of an event for a person that is just now being invited is just an "invitation" or REQUEST. Keeping rescheduling and invitations as REQUEST seems more appropriate.

However, updates to the ;PARTSTAT parameter or the STATUS property seems quite different and is the semantics of a CONFIRMation in many a C&S system. This seems to also be aliased in the current reuse of the REQUEST.

One is hardpressed today to figure out if a REQUEST is for an invitation/reschedule or for a confirmation/status update.

This distinction clearly needs to be clarified with the proposed change request.

-- Frank --=_alternative 000C33948525694A_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 28 23:20: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 XAA26103 for ; Mon, 28 Aug 2000 23:20:09 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA18018 for ietf-calendar-bks; Mon, 28 Aug 2000 20:03:36 -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 UAA18013 for ; Mon, 28 Aug 2000 20:03:34 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7T2roe28104 for ; Mon, 28 Aug 2000 19:53:50 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G019U300.7U2; Mon, 28 Aug 2000 20:03:39 -0700 Message-ID: <39AB28F0.1946F81E@netscape.com> Date: Mon, 28 Aug 2000 20:07:28 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Bruce_Kahn@iris.com, eric@softwarestudio.org, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? References: Content-Type: multipart/mixed; boundary="------------23029C228C74990923F471D2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------23029C228C74990923F471D2 Content-Type: multipart/alternative; boundary="------------A2EEFD46EA86FA7F903798FE" --------------A2EEFD46EA86FA7F903798FE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > > Lesson learned for our next protocol... > > Separate out the routing information from the content information! Agreed. What hurts even worse is that we discussed this exact point several times, and somehow it still slipped. -Steve --------------A2EEFD46EA86FA7F903798FE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Frank_Dawson@lotus.com wrote:

 
Lesson learned for our next protocol...

Separate out the routing information from the content information!

Agreed.   What hurts even worse is that we discussed this exact point several times, and somehow it still slipped.

-Steve --------------A2EEFD46EA86FA7F903798FE-- --------------23029C228C74990923F471D2 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 tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------23029C228C74990923F471D2-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 00:02: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 AAA26914 for ; Tue, 29 Aug 2000 00:02:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22449 for ietf-calendar-bks; Mon, 28 Aug 2000 20:47:08 -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 UAA22427 for ; Mon, 28 Aug 2000 20:47:02 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7T3fZY22441 for ; Mon, 28 Aug 2000 20:41:35 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G01BV000.MRT; Mon, 28 Aug 2000 20:47:24 -0700 Message-ID: <39AB3337.B3BC6EB5@netscape.com> Date: Mon, 28 Aug 2000 20:51:19 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Eric Busboom , CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: Updates to iTIP/iMIP RFCs References: Content-Type: multipart/mixed; boundary="------------ECD94F6D2D524D3ABFD1158B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ECD94F6D2D524D3ABFD1158B Content-Type: multipart/alternative; boundary="------------695BE3CF86D11DAEB4FD536A" --------------695BE3CF86D11DAEB4FD536A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > >I understand using CONFIRM for the reply to a REFRESH, but it seems > odd to > >use it to change ATTENDEEs or the ORGANIZER, while other types of > changes > >still fall under REQUEST. > > I missed something...I wasn't aware that the CONFIRM would be used to > add or delete the ATTENDEE properties, only to update the ;PARTSTAT > parameter. > > Others: RIGHT? Right ... at least from my point of view. The notes from the CALSCH Working Group meeting in Minn. actually did say that a CONFIRM would be used to notify people of any "changes to the Attendees". I took this to mean changes with respect to their PARTSTAT. Anybody take it to mean something else? -Steve --------------695BE3CF86D11DAEB4FD536A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote:

>I understand using CONFIRM for the reply to a REFRESH, but it seems odd to
>use it to change ATTENDEEs or the ORGANIZER, while other types of changes
>still fall under REQUEST.

I missed something...I wasn't aware that the CONFIRM would be used to add or delete the ATTENDEE properties, only to update the ;PARTSTAT parameter.

Others: RIGHT?

Right ... at least from my point of view.

The notes from the CALSCH Working Group meeting in Minn. actually did say that a CONFIRM would be used to notify people of any "changes to the Attendees". I took this to mean changes with respect to their PARTSTAT. Anybody take it to mean something else?

-Steve
  --------------695BE3CF86D11DAEB4FD536A-- --------------ECD94F6D2D524D3ABFD1158B 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 tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------ECD94F6D2D524D3ABFD1158B-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 00:07: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 AAA26981 for ; Tue, 29 Aug 2000 00:07:23 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA22672 for ietf-calendar-bks; Mon, 28 Aug 2000 20:51:23 -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 UAA22665 for ; Mon, 28 Aug 2000 20:51:21 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7T3foe01818 for ; Mon, 28 Aug 2000 20:41:50 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G01C2700.5TO; Mon, 28 Aug 2000 20:51:43 -0700 Message-ID: <39AB3432.D396EF1D@netscape.com> Date: Mon, 28 Aug 2000 20:55:30 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Eric Busboom , CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: Updates to iTIP/iMIP RFCs References: Content-Type: multipart/mixed; boundary="------------0059F5B0245C309D070E3269" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0059F5B0245C309D070E3269 Content-Type: multipart/alternative; boundary="------------BA2135D578C1CE6308606FE9" --------------BA2135D578C1CE6308606FE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > >As long as we are breaking up the REQUEST method, I'd like to see the > > >reschedule and update tasks broken out with a new METHOD, say UPDATE. > This > >would mirror the conceptual difference between a new request and a > change > >to a scheduled meeting. Then, case (b) above would fall under UPDATE > > So, you get an UPDATE for an event that you don't have in your > calendar? Is it to be ignored? > > I prefer the current semantics of REQUEST for invitations and > rescheduling. A "rescheduling" of an event for a person that is just > now being invited is just an "invitation" or REQUEST. Keeping > rescheduling and invitations as REQUEST seems more appropriate. > > However, updates to the ;PARTSTAT parameter or the STATUS property > seems quite different and is the semantics of a CONFIRMation in many a > C&S system. This seems to also be aliased in the current reuse of the > REQUEST. > > One is hardpressed today to figure out if a REQUEST is for an > invitation/reschedule or for a confirmation/status update. > > This distinction clearly needs to be clarified with the proposed > change request. Just to clarify... If the Organizer is resending an event to all the Attendees and the *only* change is to the PARTSTAT parameter of one or more ATTENDEEs we should make the METHOD be CONFIRM rather than REQUEST. Is that correct? -Steve --------------BA2135D578C1CE6308606FE9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote:

>As long as we are breaking up the REQUEST method, I'd like to see the
>reschedule and update tasks broken out with a new METHOD, say UPDATE. This
>would mirror the conceptual difference between a new request and a change
>to a scheduled meeting. Then, case (b) above would fall under UPDATE

So, you get an UPDATE for an event that you don't have in your calendar? Is it to be ignored?

I prefer the current semantics of REQUEST for invitations and rescheduling. A "rescheduling" of an event for a person that is just now being invited is just an "invitation" or REQUEST. Keeping rescheduling and invitations as REQUEST seems more appropriate.

However, updates to the ;PARTSTAT parameter or the STATUS property seems quite different and is the semantics of a CONFIRMation in many a C&S system. This seems to also be aliased in the current reuse of the REQUEST.

One is hardpressed today to figure out if a REQUEST is for an invitation/reschedule or for a confirmation/status update.

This distinction clearly needs to be clarified with the proposed change request.

Just to clarify...

If the Organizer is resending an event to all the Attendees and the *only* change is to the PARTSTAT parameter of one or more ATTENDEEs we should make the METHOD be CONFIRM rather than REQUEST.

Is that correct?

-Steve
  --------------BA2135D578C1CE6308606FE9-- --------------0059F5B0245C309D070E3269 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 tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------0059F5B0245C309D070E3269-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 10:23: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 KAA18972 for ; Tue, 29 Aug 2000 10:23:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA03824 for ietf-calendar-bks; Tue, 29 Aug 2000 07:03:31 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03818 for ; Tue, 29 Aug 2000 07:03:30 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA31485 for ; Tue, 29 Aug 2000 10:06:33 -0400 Message-ID: <39ABC369.5604B1D9@ecal.com> Date: Tue, 29 Aug 2000 10:06:33 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP References: <39A2A603.5C7B6E02@home.royer.com> <39AA941B.776C7B38@cst.ca> 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 George Babics wrote: > ATTENDEE:CONFLICT=FALSE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal I would prefer not to see TRANSP bound to CAP; I think it will be useful even for those who don't support CAP. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Don't anthropomorphize computers. We don't like| |francis@ecal.com|it. | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 29 10:25: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 KAA19039 for ; Tue, 29 Aug 2000 10:25:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA04145 for ietf-calendar-bks; Tue, 29 Aug 2000 07:08:43 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04141 for ; Tue, 29 Aug 2000 07:08:41 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA31495 for ; Tue, 29 Aug 2000 10:11:44 -0400 Message-ID: <39ABC4A0.B1F0B0EB@ecal.com> Date: Tue, 29 Aug 2000 10:11:44 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? 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 best answers I could find are: "It's FM", a wild guess, or > the use of external meta information (ie: the "Sender: ..." > MIME header from the iMIP message, etc). Clarification: that should be From:. The Sender: is likely to be an address for the CS admin or something. RFC-822 (section 4.4.4...I had occasion to look this up last night) says you never send a reply to Sender:. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Never do card tricks for your poker buddies. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 29 10:27: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 KAA19177 for ; Tue, 29 Aug 2000 10:27:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA04378 for ietf-calendar-bks; Tue, 29 Aug 2000 07:12:54 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04373 for ; Tue, 29 Aug 2000 07:12:52 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA31508 for ; Tue, 29 Aug 2000 10:15:55 -0400 Message-ID: <39ABC59B.DF758DCB@ecal.com> Date: Tue, 29 Aug 2000 10:15:55 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? 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 Eric Busboom wrote: > Proposal 2 sounds OK, but perhaps it could be generalized by just using > the existing SENT-BY parameter? SENT-BY means something completely different: the person who sent the message, as opposed to the one on whose behalf it was sent. In email terms, it's like Sender:, not like From:. Since the current system allows a SENT-BY on the ATTENDEE in a COUNTER message, there'd be no way to distinguish between the old usage ("Joe wants to submit a counterproposal, but Fred sent this message for him") and the new ("Fred wants to submit a counterproposal in which Joe is the only attendee"). And we can't scrap old usage; it's likely to be useful sometimes. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Never do card tricks for your poker buddies. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 29 12:00: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 MAA23523 for ; Tue, 29 Aug 2000 12:00:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14656 for ietf-calendar-bks; Tue, 29 Aug 2000 08:33: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 IAA14647; Tue, 29 Aug 2000 08:33: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 LAA04987; Tue, 29 Aug 2000 11:35:41 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA24941; Tue, 29 Aug 2000 11:33:37 -0400 (EDT) To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 29 Aug 2000 11:33:12 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/29/2000 11:33:14 AM, Serialize complete at 08/29/2000 11:33:14 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005579088525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005579088525694A_= Content-Type: text/plain; charset="us-ascii" Folks: I have thought about this some more. I think that the proposal to add an ATT-COUNTER parameter to the ATTENDEE property present backwards compatibility with iCalendar RFC2445 products. An alternative proposal would be to have an ATT-COUNTER property, instead. If we think about what this semantic means, it is similar to the ORGANIZER property. The attendee making the COUNTER proposal is effectively proposing a new event, similar to a tentative invitation proposal. As such, I believe that you all would agree that making this a property, instead of an ATTENDEE property parameter is a better design approach. For backwards compatibility, a RFC2445 compatible parser is supposed to skip any unrecognized properties, as these may have been IANA registered extensions anyway. Don't you all agree? -- Frank --=_alternative 005579088525694A_= Content-Type: text/html; charset="us-ascii"
Folks:

I have thought about this some more.

I think that the proposal to add an ATT-COUNTER parameter to the ATTENDEE property present backwards compatibility with iCalendar RFC2445 products.

An alternative proposal would be to have an ATT-COUNTER property, instead.

If we think about what this semantic means, it is similar to the ORGANIZER property. The attendee making the COUNTER proposal is effectively proposing a new event, similar to a tentative invitation proposal. As such, I believe that you all would agree that making this a property, instead of an ATTENDEE property parameter is a better design approach.

For backwards compatibility, a RFC2445 compatible parser is supposed to skip any unrecognized properties, as these may have been IANA registered extensions anyway.

Don't you all agree?

-- Frank

--=_alternative 005579088525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 12:28: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 MAA24639 for ; Tue, 29 Aug 2000 12:28:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16836 for ietf-calendar-bks; Tue, 29 Aug 2000 09:08:51 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16830 for ; Tue, 29 Aug 2000 09:08:49 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA31892 for ; Tue, 29 Aug 2000 12:11:52 -0400 Message-ID: <39ABE0C8.CD7E8E2E@ecal.com> Date: Tue, 29 Aug 2000 12:11:52 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? 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: > For backwards compatibility, a RFC2445 compatible parser is > supposed to skip any unrecognized properties, as these may have > been IANA registered extensions anyway. Shouldn't the same be said of unrecognized parameters? (I'm not opposing using a property, mind you; I like the argument that ATT-COUNTER is parallel to ORGANIZER.) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |No matter how tempting the prospect of unlimited| |francis@ecal.com|power, I will not consume any energy field | | |bigger than my head. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 29 12:51: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 MAA25666 for ; Tue, 29 Aug 2000 12:51:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17709 for ietf-calendar-bks; Tue, 29 Aug 2000 09:37: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 JAA17701 for ; Tue, 29 Aug 2000 09:37:08 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7TGRde27214 for ; Tue, 29 Aug 2000 09:27:39 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G02BIM00.17Z; Tue, 29 Aug 2000 09:37:34 -0700 Message-ID: <39ABE7BE.8E52D4FB@netscape.com> Date: Tue, 29 Aug 2000 09:41:34 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: John Stracke , ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP: Who sent that message? References: Content-Type: multipart/mixed; boundary="------------92DFAC491FC30AD6B7F3CBEC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------92DFAC491FC30AD6B7F3CBEC Content-Type: multipart/alternative; boundary="------------D0B74B554846477D47DAF8C2" --------------D0B74B554846477D47DAF8C2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > Folks: > > I have thought about this some more. > > I think that the proposal to add an ATT-COUNTER parameter to the > ATTENDEE property present backwards compatibility with iCalendar > RFC2445 products. > > An alternative proposal would be to have an ATT-COUNTER property, > instead. > ... I'm fine with this. -Steve --------------D0B74B554846477D47DAF8C2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote:

Folks:

I have thought about this some more.

I think that the proposal to add an ATT-COUNTER parameter to the ATTENDEE property present backwards compatibility with iCalendar RFC2445 products.

An alternative proposal would be to have an ATT-COUNTER property, instead.
...

I'm fine with this.

-Steve
  --------------D0B74B554846477D47DAF8C2-- --------------92DFAC491FC30AD6B7F3CBEC 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 tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------92DFAC491FC30AD6B7F3CBEC-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 12:53: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 MAA25764 for ; Tue, 29 Aug 2000 12:53:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17339 for ietf-calendar-bks; Tue, 29 Aug 2000 09:33:33 -0700 (PDT) Received: from agony.dyn.dhs.org (IDENT:root@24-25-200-241.san.rr.com [24.25.200.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17333 for ; Tue, 29 Aug 2000 09:33:32 -0700 (PDT) From: eric@softwarestudio.org Received: from localhost (eric@localhost) by agony.dyn.dhs.org (8.9.3/8.9.3) with ESMTP id JAA09388; Tue, 29 Aug 2000 09:33:46 -0700 X-Authentication-Warning: agony.dyn.dhs.org: eric owned process doing -bs Date: Tue, 29 Aug 2000 09:33:45 -0700 (PDT) X-Sender: eric@agony.dyn.dhs.org To: Steve Mansour cc: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? In-Reply-To: <39AACF46.5169ED0A@netscape.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 28 Aug 2000, Steve Mansour wrote: > Yea, overloading SENT-BY is sure to come back to haunt us. Remember that an > Event may already have several ATTENDEEs with SENT-BY parameters. We still > need to figure out which SENT-BY is sending the COUNTER. Will the person doing > the COUNTER have to strip out all SENT-BY info? Probably not a good idea. Ah. > Is the ATTCOUNTER param OK with you, Eric? Bruce? I can live with ATTCOUNTER. This would be a boolean type, or maybe a parameter with no value -- you just check for it's existence? It still makes me uneasy, since it is a parameter that has such a small purpose. eric. From owner-ietf-calendar@mail.imc.org Tue Aug 29 13:00: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 NAA25883 for ; Tue, 29 Aug 2000 13:00:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA18130 for ietf-calendar-bks; Tue, 29 Aug 2000 09:44:31 -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 JAA18124 for ; Tue, 29 Aug 2000 09:44:30 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7TGd4Y28177 for ; Tue, 29 Aug 2000 09:39:04 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G02BUV00.F6Z; Tue, 29 Aug 2000 09:44:55 -0700 Message-ID: <39ABE976.1A0106E8@netscape.com> Date: Tue, 29 Aug 2000 09:48:54 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: eric@softwarestudio.org CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? References: Content-Type: multipart/mixed; boundary="------------5C8056BED9DC264B2D99FE15" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5C8056BED9DC264B2D99FE15 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit eric@softwarestudio.org wrote: > On Mon, 28 Aug 2000, Steve Mansour wrote: > > > Yea, overloading SENT-BY is sure to come back to haunt us. Remember that an > > Event may already have several ATTENDEEs with SENT-BY parameters. We still > > need to figure out which SENT-BY is sending the COUNTER. Will the person doing > > the COUNTER have to strip out all SENT-BY info? Probably not a good idea. > > Ah. > > > Is the ATTCOUNTER param OK with you, Eric? Bruce? > > I can live with ATTCOUNTER. This would be a boolean type, or maybe a > parameter with no value -- you just check for it's existence? > > It still makes me uneasy, since it is a parameter that has such a small > purpose. right. Frank's proposal for making it a property deals with this problem. Still serves a small purpose, but it's clear. So, iTIP example 4.2.4 would become somthing like: BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:COUNTER VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTCOUNTER:mailto:B@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com DTSTART:19970701T160000Z DTEND:19970701T190000Z DTSTAMP:19970612T190000Z SUMMARY:Discuss the Merits of the election results LOCATION:Green Conference Room COMMENT:This time works much better and I think the big conference room is too big UID:calsrv.example.com-873970198738777a@example.com SEQUENCE:0 DTSTAMP:19970611T190000Z END:VEVENT END:VCALENDAR This indicates that the counter proposal was made by "B". -Steve --------------5C8056BED9DC264B2D99FE15 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 tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------5C8056BED9DC264B2D99FE15-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 13:06: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 NAA26058 for ; Tue, 29 Aug 2000 13:06:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18533 for ietf-calendar-bks; Tue, 29 Aug 2000 09:50: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 JAA18529; Tue, 29 Aug 2000 09:50:18 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet1.lotus.com (internet1 [9.95.4.235]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA17037; Tue, 29 Aug 2000 12:52:46 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet1.lotus.com (8.9.3/8.9.3) with ESMTP id MAA25059; Tue, 29 Aug 2000 12:50:39 -0400 (EDT) To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 29 Aug 2000 12:50:06 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/29/2000 12:50:17 PM, Serialize complete at 08/29/2000 12:50:17 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005C83868525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C83868525694A_= Content-Type: text/plain; charset="us-ascii" >Shouldn't the same be said of unrecognized parameters? Did you mean "parameter" or "property". I am confused. I argued against a parameter and pro a property. >(I'm not opposing using a property, mind you; I like the argument >that ATT-COUNTER is parallel to ORGANIZER.) Great! Makes two of us. --=_alternative 005C83868525694A_= Content-Type: text/html; charset="us-ascii"
>Shouldn't the same be said of unrecognized parameters?

Did you mean "parameter" or "property". I am confused. I argued against a parameter and pro a property.

>(I'm not opposing using a property, mind you; I like the argument
>that ATT-COUNTER is parallel to ORGANIZER.)

Great! Makes two of us. --=_alternative 005C83868525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 13:34: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 NAA26808 for ; Tue, 29 Aug 2000 13:34:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20157 for ietf-calendar-bks; Tue, 29 Aug 2000 10:16:57 -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 KAA20149 for ; Tue, 29 Aug 2000 10:16:54 -0700 (PDT) From: Bruce_Kahn@iris.com To: eric@softwarestudio.org Cc: ietf-calendar@imc.org, Steve Mansour Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 29 Aug 2000 13:17:45 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/29/2000 01:17:54 PM, Serialize complete at 08/29/2000 01:17:55 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/29/2000 01:17:55 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005F13468525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005F13468525694A_= Content-Type: text/plain; charset="us-ascii" Eric said: >It still makes me uneasy, since it is a parameter that has such a small >purpose. Im in the same boat as Eric (see previous posting)... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005F13468525694A_= Content-Type: text/html; charset="us-ascii"
Eric said:
>It still makes me uneasy, since it is a parameter that has such a small
>purpose.

Im in the same boat as Eric (see previous posting)...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005F13468525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 13:37: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 NAA26905 for ; Tue, 29 Aug 2000 13:37:30 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20122 for ietf-calendar-bks; Tue, 29 Aug 2000 10:15:53 -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 KAA20114 for ; Tue, 29 Aug 2000 10:15:48 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: sman@netscape.com (Steve Mansour) Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 29 Aug 2000 13:16:28 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/29/2000 01:16:49 PM, Serialize complete at 08/29/2000 01:16:49 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005EF5608525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005EF5608525694A_= Content-Type: text/plain; charset="us-ascii" Steve wrote: >Remember that an >Event may already have several ATTENDEEs with SENT-BY parameters. We still >need to figure out which SENT-BY is sending the COUNTER. First off, I think that you are assuming that SENT-BY will be preserved or propigated by the Organizer when sending out updates. Thats new behaviour thats not univerally agree'd on. (I would sure hate to have to be the CUA coordinating this 'updating of sent-bys' when the value changes on a later REPLY!! I have some mgrs here w/2+ AAs so that value can easily be different between responses!!) The SENT-BY is typically found on 1 Attendee; the one that is sending the REPLY or COUNTER (or whatever) _back_ to the Organizer. So, unless the Organizer is saving and resending them out to all other Attendees, I do NOT see this as being something thats going to haunt us! >Will the person doing >the COUNTER have to strip out all SENT-BY info? I guess that depends on if you subscribe to the belief that the Organizer propagates the SENT-BY property out or not. Since this is not feasible for the delgation case (w/ or w/o an AA) I would stipulate that SENT-BY values are NOT propagated to other Attendees and as such are actually useful in this case. I will agree that we are overloading the current 2445 definition of SENT-BY: "To specify the calendar user that is acting on behalf of the calendar user specified by the property." but Im not convinced its as bad as the other overloadings we have. >Is the ATTCOUNTER param OK with you, Eric? Bruce? Hmm, Im mulling it over but I can see the use of SENT-BY on METHOD being another means to convey the same thing. At this rate, we are going to have tons of specialized property parameters for ATTENDEE when we can just slightly overload SENT-BY (to allow on METHOD) and achieve the same thing... Having tons of property parameters begs the case we may need to revisit the property design/usage and Im not in favor of 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... --=_alternative 005EF5608525694A_= Content-Type: text/html; charset="us-ascii"
Steve wrote:
>Remember that an
>Event may already have several ATTENDEEs with SENT-BY parameters. We still
>need to figure out which SENT-BY is sending the COUNTER.

First off, I think that you are assuming that SENT-BY will be preserved or propigated by the Organizer when sending out updates.  Thats new behaviour thats not univerally agree'd on.  (I would sure hate to have to be the CUA coordinating this 'updating of sent-bys' when the value changes on a later REPLY!!  I have some mgrs here w/2+ AAs so that value can easily be different between responses!!)

The SENT-BY is typically found on 1 Attendee; the one that is sending the REPLY or COUNTER (or whatever) _back_ to the Organizer.  So, unless the Organizer is saving and resending them out to all other Attendees, I do NOT see this as being something thats going to haunt us!

>Will the person doing
>the COUNTER have to strip out all SENT-BY info?

I guess that depends on if you subscribe to the belief that the Organizer propagates the SENT-BY property out or not.  Since this is not feasible for the delgation case (w/ or w/o an AA) I would stipulate that SENT-BY values are NOT propagated to other Attendees and as such are actually useful in this case.

I will agree that we are overloading the current 2445 definition of SENT-BY: "To specify the calendar user that is acting on behalf of the calendar user specified by the property." but Im not convinced its as bad as the other overloadings we have.

>Is the ATTCOUNTER param OK with you, Eric?  Bruce?

Hmm, Im mulling it over but I can see the use of SENT-BY on METHOD being another means to convey the same thing.  At this rate, we are going to have tons of specialized property parameters for ATTENDEE when we can just slightly overload SENT-BY (to allow on METHOD) and achieve the same thing...  Having tons of property parameters begs the case we may need to revisit the property design/usage and Im not in favor of 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... --=_alternative 005EF5608525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 13:41: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 NAA26972 for ; Tue, 29 Aug 2000 13:41:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20301 for ietf-calendar-bks; Tue, 29 Aug 2000 10:24:12 -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 KAA20297 for ; Tue, 29 Aug 2000 10:24:10 -0700 (PDT) From: Bruce_Kahn@iris.com To: Frank_Dawson@lotus.com Cc: eric@softwarestudio.org, ietf-calendar@imc.org, sman@netscape.com (Steve Mansour) Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 29 Aug 2000 13:25:03 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/29/2000 01:25:09 PM, Serialize complete at 08/29/2000 01:25:09 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005FBE678525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005FBE678525694A_= Content-Type: text/plain; charset="us-ascii" Frank and Steve pondered: >>Separate out the routing information from the content information! >Agreed. This is not the case of mixed information per-se but rather a case of just not diving deep enough on the less frequently traveled C&S workflow paths (as we saw recently with the RRULEs issues). Our "fully encapsulated" goal was and still is worthwhile for many cases but as we discovered in DC in December a separation model is also necessary at times... Lets learn the right lessons from this as we fix it; not just "We should'a done something different". Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005FBE678525694A_= Content-Type: text/html; charset="us-ascii"
Frank and Steve pondered:
>>Separate out the routing information from the content information!
>Agreed.

This is not the case of mixed information per-se but rather a case of just not diving deep enough on the less frequently traveled C&S workflow paths (as we saw recently with the RRULEs issues).

Our "fully encapsulated" goal was and still is worthwhile for many cases but as we discovered in DC in December a separation model is also necessary at times...  Lets learn the right lessons from this as we fix it; not just "We should'a done something different".

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005FBE678525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 14:01: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 OAA27454 for ; Tue, 29 Aug 2000 14:01:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20587 for ietf-calendar-bks; Tue, 29 Aug 2000 10:43:15 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20583 for ; Tue, 29 Aug 2000 10:43:14 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id NAA32268 for ; Tue, 29 Aug 2000 13:46:17 -0400 Message-ID: <39ABF6E9.93692B63@ecal.com> Date: Tue, 29 Aug 2000 13:46:17 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? 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: > >Shouldn't the same be said of unrecognized parameters? > > Did you mean "parameter" or "property". I meant "parameter". You said that an iCalendar implementation that didn't recognize a property should remain silent. I'm asking whether an iCalendar implementation that doesn't recognize a parameter should remain silent. I'm concerned because, if not, then it becomes difficult to extend a property definition over time. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |NT's lack of reliability is only surpassed by| |francis@ecal.com|its lack of scalability. --John Kirch | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 29 14:58: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 OAA28632 for ; Tue, 29 Aug 2000 14:58:18 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA22962 for ietf-calendar-bks; Tue, 29 Aug 2000 11:40:32 -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 LAA22958 for ; Tue, 29 Aug 2000 11:40:30 -0700 (PDT) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: eric@softwarestudio.org, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Tue, 29 Aug 2000 14:41:21 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/29/2000 02:41:29 PM, Serialize complete at 08/29/2000 02:41:29 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0066BA928525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066BA928525694A_= Content-Type: text/plain; charset="us-ascii" Steve wrote: >However, only the ORGANIZER can remove a participant. The down side to this approach is that you can't change the Attendees. Actually, if you read iTIP the text in the restriction table talkes about the person countering being able to add Attendees. Since the COUNTER is a full snapshot, I dont see any reason that a COUNTER could not be used to indicate to the Organzier that an Attendee should be removed. In fact, if the delta between the Organizers copy and the COUNTER (assuming no SEQUENCE changes and that property parameters are ignored) should indicate this just fine. Yes, only the Organzier has the authority to remove Attendees but theres nothing precluding someone _suggesting_ it in a COUNTER... In RFC 2446, Section 3.2.7 you see the text: The "COUNTER" method for a "VEVENT" calendar component is used by an "Attendee" of an existing event to submit to the "Organizer" a counter proposal to the event description. The "Attendee" sends this message to the "Organizer" of the event. The counter proposal is an iCalendar object consisting of a VEVENT calendar component describing the complete description of the alternate event. I claim that "complete description" includes those attending it and as such, a COUNTER conveys the removal intent (as well as rescheduling, etc) to the Organzier. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0066BA928525694A_= Content-Type: text/html; charset="us-ascii"
Steve wrote:
>However, only the ORGANIZER can remove a participant.  The down side to this approach is that you can't change the Attendees.

Actually, if you read iTIP the text in the restriction table talkes about the person countering being able to add Attendees.  Since the COUNTER is a full snapshot, I dont see any reason that a COUNTER could not be used to indicate to the Organzier that an Attendee should be removed.  In fact, if the delta between the Organizers copy and the COUNTER (assuming no SEQUENCE changes and that property parameters are ignored) should indicate this just fine.  

Yes, only the Organzier has the authority to remove Attendees but theres nothing precluding someone _suggesting_ it in a COUNTER...

In RFC 2446, Section 3.2.7 you see the text:

   The "COUNTER" method for a "VEVENT" calendar component is used by an
  "Attendee" of an existing event to submit to the "Organizer" a
  counter proposal to the event description. The "Attendee" sends this
  message to the "Organizer" of the event.

  The counter proposal is an iCalendar object consisting of a VEVENT
  calendar component describing the complete description of the
   alternate event.

I claim that "complete description" includes those attending it and as such, a COUNTER conveys the removal intent (as well as rescheduling, etc) to the Organzier.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0066BA928525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 15:12: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 PAA28981 for ; Tue, 29 Aug 2000 15:12:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA23203 for ietf-calendar-bks; Tue, 29 Aug 2000 11:54: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 LAA23199; Tue, 29 Aug 2000 11:54:14 -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 OAA00506; Tue, 29 Aug 2000 14:56:41 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA03667; Tue, 29 Aug 2000 14:54:38 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 29 Aug 2000 14:54:13 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/29/2000 02:54:14 PM, Serialize complete at 08/29/2000 02:54:14 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0067E0818525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067E0818525694A_= Content-Type: text/plain; charset="us-ascii" >Remember that an >Event may already have several ATTENDEEs with SENT-BY parameters. We still >need to figure out which SENT-BY is sending the COUNTER. Bruce: I agree with you on this one. The SENT-BY parameter was there to be used in a REPLY method. We never had any intentions that I can recall to persist this information. The SENT-BY is used by a person acting on behalf of the attendee. What I would expect the ORGANIZER to send out on a CONFIRM would merely be the updated ATTENDEE;PARTSTAT= value. This is born out by the examples in the iTIP spec. Not sure there is an example of a reschedule, forwarding of an invitation, or any other example with SENT-BY being persisted beyond the initial use in a REPLY. I agree with BRUCE... -- Frank --=_alternative 0067E0818525694A_= Content-Type: text/html; charset="us-ascii"
>Remember that an
>Event may already have several ATTENDEEs with SENT-BY parameters. We still
>need to figure out which SENT-BY is sending the COUNTER.

Bruce:

I agree with you on this one. The SENT-BY parameter was there to be used in a REPLY method. We never had any intentions that I can recall to persist this information.

The SENT-BY is used by a person acting on behalf of the attendee. What I would expect the ORGANIZER to send out on a CONFIRM would merely be the updated ATTENDEE;PARTSTAT= value. This is born out by the examples in the iTIP spec. Not sure there is an example of a reschedule, forwarding of an invitation, or any other example with SENT-BY being persisted beyond the initial use in a REPLY.

I agree with BRUCE...

-- Frank --=_alternative 0067E0818525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 16:36: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 QAA00589 for ; Tue, 29 Aug 2000 16:36:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24587 for ietf-calendar-bks; Tue, 29 Aug 2000 13:19:51 -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 NAA24583; Tue, 29 Aug 2000 13:19:50 -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 QAA11097; Tue, 29 Aug 2000 16:22:17 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA17894; Tue, 29 Aug 2000 16:20:14 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: eric@softwarestudio.org, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, sman@netscape.com (Steve Mansour) Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 29 Aug 2000 16:19:49 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/29/2000 04:19:51 PM, Serialize complete at 08/29/2000 04:19:51 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006FB6F08525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006FB6F08525694A_= Content-Type: text/plain; charset="us-ascii" Bruce is correct. The intent was that a "counterer" could suggest a different list of attendees. But without the ATT-COUNTER property this is kind of broke :-( -- Frank --=_alternative 006FB6F08525694A_= Content-Type: text/html; charset="us-ascii"
Bruce is correct. The intent was that a "counterer" could suggest a different list of attendees.

But without the ATT-COUNTER property this is kind of broke :-(

-- Frank --=_alternative 006FB6F08525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 16:41: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 QAA00651 for ; Tue, 29 Aug 2000 16:41:26 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA24464 for ietf-calendar-bks; Tue, 29 Aug 2000 13:13:02 -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 NAA24460 for ; Tue, 29 Aug 2000 13:13:00 -0700 (PDT) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7TK7XY15902; Tue, 29 Aug 2000 13:07:34 -0700 (PDT) Received: from netscape.com (h-192-18-125-198.red.iplanet.com [192.18.125.198]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id NAA116351; Tue, 29 Aug 2000 13:20:28 -0700 (PDT) Message-ID: <39AC1979.250F837D@netscape.com> Date: Tue, 29 Aug 2000 13:13:45 -0700 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: Eric Busboom , ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? References: Content-Type: multipart/mixed; boundary="------------94E46AA66F6D8EA63011A5BB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------94E46AA66F6D8EA63011A5BB Content-Type: multipart/alternative; boundary="------------BDCD7570A7730570EEA2158F" --------------BDCD7570A7730570EEA2158F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > Steve wrote: > >Remember that an > >Event may already have several ATTENDEEs with SENT-BY parameters. We > still > >need to figure out which SENT-BY is sending the COUNTER. > > First off, I think that you are assuming that SENT-BY will be > preserved or propigated by the Organizer when sending out updates. > Thats new behaviour thats not univerally agree'd on. (I would sure > hate to have to be the CUA coordinating this 'updating of sent-bys' > when the value changes on a later REPLY!! I have some mgrs here w/2+ > AAs so that value can easily be different between responses!!) I was just assuming that whatever was sent to the Organizer would be maintained. > The SENT-BY is typically found on 1 Attendee; the one that is sending > the REPLY or COUNTER (or whatever) _back_ to the Organizer. So, > unless the Organizer is saving and resending them out to all other > Attendees, I do NOT see this as being something thats going to haunt > us! Seems like useful information to me. In our implementation, we were not going to change the SENT-BY info. Don't you think it's important to save it? If it's not, how were you envisioning that it would be used? -Steve --------------BDCD7570A7730570EEA2158F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

Steve wrote:
>Remember that an
>Event may already have several ATTENDEEs with SENT-BY parameters. We still
>need to figure out which SENT-BY is sending the COUNTER.

First off, I think that you are assuming that SENT-BY will be preserved or propigated by the Organizer when sending out updates.  Thats new behaviour thats not univerally agree'd on.  (I would sure hate to have to be the CUA coordinating this 'updating of sent-bys' when the value changes on a later REPLY!!  I have some mgrs here w/2+ AAs so that value can easily be different between responses!!)

I was just assuming that whatever was sent to the Organizer would be maintained.
The SENT-BY is typically found on 1 Attendee; the one that is sending the REPLY or COUNTER (or whatever) _back_ to the Organizer.  So, unless the Organizer is saving and resending them out to all other Attendees, I do NOT see this as being something thats going to haunt us!
Seems like useful information to me.  In our implementation, we were not going to change the SENT-BY info.

Don't you think it's important to save it?  If it's not, how were you envisioning that it would be used?

-Steve --------------BDCD7570A7730570EEA2158F-- --------------94E46AA66F6D8EA63011A5BB 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 tel;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------94E46AA66F6D8EA63011A5BB-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 16:55: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 QAA00836 for ; Tue, 29 Aug 2000 16:55:43 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24666 for ietf-calendar-bks; Tue, 29 Aug 2000 13:24:29 -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 NAA24662; Tue, 29 Aug 2000 13:24:28 -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 QAA11520; Tue, 29 Aug 2000 16:26:57 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA18592; Tue, 29 Aug 2000 16:24:55 -0400 (EDT) To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 29 Aug 2000 16:24:30 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/29/2000 04:24:31 PM, Serialize complete at 08/29/2000 04:24:31 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 007024748525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007024748525694A_= Content-Type: text/plain; charset="us-ascii" John and all others: >I'm concerned because, if not, then it becomes difficult to >extend a property definition over time. Bruce Kahn and I talked about this in a call today. We reviewed for the 100th time the iCalendar specification. We got a shock. It appears that the editors (moi for one) did not include "iana-param" or "iana-prop" in any of the definitions for the standard properties. This was certainly an oversight on the editors' part. There is the "iana-comp" in the definition of a component, but not the counterpart for new standardized properties or parameters in the various standard property definitions. My humble apologies! This is certain a numero uno Change Request candidate. Without this, the ABNF doesn't currently allow registered extensions. Only "x-prop" and "x-param" experimental extensions. Not what we had intended folks. Eric: After the dust settles on this one, can you please add this to our list of defects that need change requests? Thanks. -- Frank --=_alternative 007024748525694A_= Content-Type: text/html; charset="us-ascii"
John and all others:

>I'm concerned because, if not, then it becomes difficult to
>extend a property definition over time.

Bruce Kahn and I talked about this in a call today. We reviewed for the 100th time the iCalendar specification. We got a shock. It appears that the editors (moi for one) did not include "iana-param" or "iana-prop" in any of the definitions for the standard properties.

This was certainly an oversight on the editors' part. There is the "iana-comp" in the definition of a component, but not the counterpart for new standardized properties or parameters in the various standard property definitions.

My humble apologies! This is certain a numero uno Change Request candidate. Without this, the ABNF doesn't currently allow registered extensions. Only "x-prop" and "x-param" experimental extensions. Not what we had intended folks.

Eric:

After the dust settles on this one, can you please add this to our list of defects that need change requests? Thanks.

-- Frank
 --=_alternative 007024748525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 17:04: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 RAA00963 for ; Tue, 29 Aug 2000 17:04:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25000 for ietf-calendar-bks; Tue, 29 Aug 2000 13:43: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 NAA24996; Tue, 29 Aug 2000 13:43: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 QAA13377; Tue, 29 Aug 2000 16:46:02 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA20967; Tue, 29 Aug 2000 16:43:59 -0400 (EDT) To: George Babics Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Tue, 29 Aug 2000 16:43:34 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/29/2000 04:43:36 PM, Serialize complete at 08/29/2000 04:43:36 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0071E3788525694A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071E3788525694A_= Content-Type: text/plain; charset="us-ascii" George: Not sure what the benefit is of allowing a conflict flag parameter on the ATTENDEE property. This seems to introduce a level of complexity that may be difficult to show interoperability for. I think you would agree that we need to nip-in-the-bud any extensions that will negatively impact IOP. I can see the scenarios for having a modal, CAP specific, calendar level property that says "check and notify me of any conflicts" on events that I create during this session. But I see only problems with a modal, calendar component level property that is suppose to restrict creation of conflicting components. If the property is set of TRUE and you create some properties that are overlapping and then you reset the property to FALSE, is the calendar system suppose to do anything about the existing overlapping events that would otherwise not be allowed with the FALSE value? If not, then I think that this property has limited utility. Better to have a CAP property that merely is active for the session and will notify a CUA if they try to create an event that overlaps an existing event. -- Frank --=_alternative 0071E3788525694A_= Content-Type: text/html; charset="us-ascii"
George:

Not sure what the benefit is of allowing a conflict flag parameter on the ATTENDEE property. This seems to introduce a level of complexity that may be difficult to show interoperability for. I think you would agree that we need to nip-in-the-bud any extensions that will negatively impact IOP.

I can see the scenarios for having a modal, CAP specific, calendar level property that says "check and notify me of any conflicts" on events that I create during this session. But I see only problems with a modal, calendar component level property that is suppose to restrict creation of conflicting components. If the property is set of TRUE and you create some properties that are overlapping and then you reset the property to FALSE, is the calendar system suppose to do anything about the existing overlapping events that would otherwise not be allowed with the FALSE value? If not, then I think that this property has limited utility.

Better to have a CAP property that merely is active for the session and will notify a CUA if they try to create an event that overlaps an existing event.

-- Frank --=_alternative 0071E3788525694A_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 17:16: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 RAA01103 for ; Tue, 29 Aug 2000 17:16:04 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA25182 for ietf-calendar-bks; Tue, 29 Aug 2000 13: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 NAA25178 for ; Tue, 29 Aug 2000 13:57:44 -0700 (PDT) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7TKqIY25880; Tue, 29 Aug 2000 13:52:18 -0700 (PDT) Received: from netscape.com (h-192-18-125-198.red.iplanet.com [192.18.125.198]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id OAA123777; Tue, 29 Aug 2000 14:05:14 -0700 (PDT) Message-ID: <39AC23F6.42B3F9B@netscape.com> Date: Tue, 29 Aug 2000 13:58:30 -0700 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: eric@softwarestudio.org, ietf-calendar@imc.org Subject: Re: iTIP: Who sent that message? References: Content-Type: multipart/mixed; boundary="------------AD063921E2D21ABD94119907" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AD063921E2D21ABD94119907 Content-Type: multipart/alternative; boundary="------------8A8B7D820DA4B9B49D0B8962" --------------8A8B7D820DA4B9B49D0B8962 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > Steve wrote: > >However, only the ORGANIZER can remove a participant. The down side > to this approach is that you can't change the Attendees. > > Actually, if you read iTIP the text in the restriction table talkes > about the person countering being able to add Attendees. Since the > COUNTER is a full snapshot, I dont see any reason that a COUNTER could > not be used to indicate to the Organzier that an Attendee should be > removed. In fact, if the delta between the Organizers copy and the > COUNTER (assuming no SEQUENCE changes and that property parameters are > ignored) should indicate this just fine. > > Yes, only the Organzier has the authority to remove Attendees but > theres nothing precluding someone _suggesting_ it in a COUNTER... agreed. > In RFC 2446, Section 3.2.7 you see the text: > > The "COUNTER" method for a "VEVENT" calendar component is used by > an > "Attendee" of an existing event to submit to the "Organizer" a > counter proposal to the event description. The "Attendee" sends this > > message to the "Organizer" of the event. > > The counter proposal is an iCalendar object consisting of a VEVENT > calendar component describing the complete description of the > alternate event. > > I claim that "complete description" includes those attending it and as > such, a COUNTER conveys the removal intent (as well as rescheduling, > etc) to the Organzier. I agree. I'll suggest an update here when making the fixes to iTIP. -Steve --------------8A8B7D820DA4B9B49D0B8962 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

 
Steve wrote:
>However, only the ORGANIZER can remove a participant.  The down side to this approach is that you can't change the Attendees.

Actually, if you read iTIP the text in the restriction table talkes about the person countering being able to add Attendees.  Since the COUNTER is a full snapshot, I dont see any reason that a COUNTER could not be used to indicate to the Organzier that an Attendee should be removed.  In fact, if the delta between the Organizers copy and the COUNTER (assuming no SEQUENCE changes and that property parameters are ignored) should indicate this just fine.

Yes, only the Organzier has the authority to remove Attendees but theres nothing precluding someone _suggesting_ it in a COUNTER...

agreed.
In RFC 2446, Section 3.2.7 you see the text:

   The "COUNTER" method for a "VEVENT" calendar component is used by an
  "Attendee" of an existing event to submit to the "Organizer" a
  counter proposal to the event description. The "Attendee" sends this
  message to the "Organizer" of the event.

  The counter proposal is an iCalendar object consisting of a VEVENT
  calendar component describing the complete description of the
   alternate event.

I claim that "complete description" includes those attending it and as such, a COUNTER conveys the removal intent (as well as rescheduling, etc) to the Organzier.

I agree.  I'll suggest an update here when making the fixes to iTIP.

-Steve --------------8A8B7D820DA4B9B49D0B8962-- --------------AD063921E2D21ABD94119907 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 tel;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------AD063921E2D21ABD94119907-- From owner-ietf-calendar@mail.imc.org Tue Aug 29 17:22:56 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 RAA01181 for ; Tue, 29 Aug 2000 17:22:56 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA25276 for ietf-calendar-bks; Tue, 29 Aug 2000 14:00:53 -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 OAA25272; Tue, 29 Aug 2000 14:00:52 -0700 (PDT) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7TKtQY26732; Tue, 29 Aug 2000 13:55:26 -0700 (PDT) Received: from netscape.com (h-192-18-125-198.red.iplanet.com [192.18.125.198]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id OAA07660; Tue, 29 Aug 2000 14:08:18 -0700 (PDT) Message-ID: <39AC24AF.8E406FD5@netscape.com> Date: Tue, 29 Aug 2000 14:01:35 -0700 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP: Who sent that message? References: Content-Type: multipart/mixed; boundary="------------83FA42618A2C4958EE659B68" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------83FA42618A2C4958EE659B68 Content-Type: multipart/alternative; boundary="------------B78DFF0FB582406258F0482B" --------------B78DFF0FB582406258F0482B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > Remember that an > >Event may already have several ATTENDEEs with SENT-BY parameters. We > still > >need to figure out which SENT-BY is sending the COUNTER. > > Bruce: > > I agree with you on this one. The SENT-BY parameter was there to be > used in a REPLY method. We never had any intentions that I can recall > to persist this information. You're suggesting we remove this before storing it ???? Really???? I don't know. It seems like pretty valuable information to remove. > The SENT-BY is used by a person acting on behalf of the attendee. What > I would expect the ORGANIZER to send out on a CONFIRM would merely be > the updated ATTENDEE;PARTSTAT= value. This is born out by the examples > in the iTIP spec. Not sure there is an example of a reschedule, > forwarding of an invitation, or any other example with SENT-BY being > persisted beyond the initial use in a REPLY. > > I agree with BRUCE... So, are you saying that whenever an Organizer sends out an event or todo to the attendees, all SENT-BY information should be removed? -Steve --------------B78DFF0FB582406258F0482B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote:

Remember that an
>Event may already have several ATTENDEEs with SENT-BY parameters. We still
>need to figure out which SENT-BY is sending the COUNTER.

Bruce:

I agree with you on this one. The SENT-BY parameter was there to be used in a REPLY method. We never had any intentions that I can recall to persist this information.

You're suggesting we remove this before storing it ????   Really????

I don't know. It seems like pretty valuable information to remove.

The SENT-BY is used by a person acting on behalf of the attendee. What I would expect the ORGANIZER to send out on a CONFIRM would merely be the updated ATTENDEE;PARTSTAT= value. This is born out by the examples in the iTIP spec. Not sure there is an example of a reschedule, forwarding of an invitation, or any other example with SENT-BY being persisted beyond the initial use in a REPLY.

I agree with BRUCE...

So, are you saying that whenever an Organizer sends out an event or todo to the attendees, all SENT-BY information should be removed?

-Steve --------------B78DFF0FB582406258F0482B-- --------------83FA42618A2C4958EE659B68 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 tel;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------83FA42618A2C4958EE659B68-- From owner-ietf-calendar@mail.imc.org Wed Aug 30 04:23:35 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 EAA22187 for ; Wed, 30 Aug 2000 04:23:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02139 for ietf-calendar-bks; Wed, 30 Aug 2000 01:04:24 -0700 (PDT) Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01618; Wed, 30 Aug 2000 01:00:01 -0700 (PDT) From: sfaquestions@sendflowersamerica.com Subject: FlowerFunds - Fund Raising Program Date: Wed, 30 Aug 2000 01:32:17 Message-Id: <620.108063.29555@sendflowersamerica.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SendFlowersAmerica is proud to introduce FlowerFunds-- This unique new concept will provide an income flow for your organization for years to come. Your organization is invited to explore the possibilities of participating in FlowerFunds. $FlowerFunds is an individualized fund raising program for non-profit organizations and schools. $FlowerFunds are cash rebates that are paid to your organization each and every time an order is placed by your members and supporters. $The best part is that it costs your organization nothing to participate!! How it works: 1. When your members and supporters order flowers or gifts through sendflowersamerica they determine the price they want to pay; be it $30, $40, $50 or $1000. Since your members and supporters determine the price, they all can participate in this program. 2. Your organization receives 20% of the purchase price of the order. Say a husband buys his wife a $50 bouquet. Your organization will receive a $10 cash rebate. Nice. This program never ends. Each and every time there is an order placed by your memebers and supporters, your organization will receive the 20% cash rebate. That's a lot of FlowerFunds, and your organization stands to benefit from a findraiser unlike any other fundraiser. For more information call 1 800 SEND 123 or http://www.sendflowersamerica.com Imagine earning money for your organization by making someone smile :-) From owner-ietf-calendar@mail.imc.org Wed Aug 30 14:12:46 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 OAA06231 for ; Wed, 30 Aug 2000 14:12:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA16312 for ietf-calendar-bks; Wed, 30 Aug 2000 10:48:16 -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 KAA16301 for ; Wed, 30 Aug 2000 10:48:05 -0700 (PDT) From: pregen@egenconsulting.com To: Frank_Dawson@lotus.com Cc: Bruce_Kahn@iris.com, eric@softwarestudio.org, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, sman@netscape.com (Steve Mansour) Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: Date: Wed, 30 Aug 2000 13:49:02 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 08/30/2000 01:49:17 PM, Serialize complete at 08/30/2000 01:49:17 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0061F3FF8525694B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0061F3FF8525694B_= Content-Type: text/plain; charset="us-ascii" I see some noise on the list that support the ATT-Counter property. I don't see much saying anyone does not like the idea. Frank, since it's your idea, do you have some text to put on the list and we'll get it approved and added. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0061F3FF8525694B_= Content-Type: text/html; charset="us-ascii"
I see some noise on the list that support the ATT-Counter property.  I don't see much saying anyone does not like the idea.  Frank, since it's your idea, do you have some text to put on the list and we'll get it approved and added.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0061F3FF8525694B_=-- From owner-ietf-calendar@mail.imc.org Wed Aug 30 14:12: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 OAA06242 for ; Wed, 30 Aug 2000 14:12:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA16700 for ietf-calendar-bks; Wed, 30 Aug 2000 10:53:49 -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 KAA16692; Wed, 30 Aug 2000 10:53:48 -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 NAA12528; Wed, 30 Aug 2000 13:54:19 -0400 Received: from cst.ca (cc-1106.int.cst.ca [192.168.1.105]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RAYK45M9; Wed, 30 Aug 2000 13:54:18 -0400 Message-ID: <39AD4A4A.C96F4EDE@cst.ca> Date: Wed, 30 Aug 2000 13:54:18 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP 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: > > George: > > Not sure what the benefit is of allowing a conflict flag parameter on the ATTENDEE property. This seems to introduce a level of complexity that may be difficult to show interoperability for. I think you would agree that we need to nip-in-the-bud any extensions that will negatively impact IOP. I am not sure if it will introduce such a level of complexity. If it does, we will have to examine gain VS interoperability cost. > > I can see the scenarios for having a modal, CAP specific, calendar level property that says "check and notify me of any conflicts" on events that I create during this session. But I see only problems with a modal, calendar component level property that is suppose to restrict creation of conflicting components. If the property is set of TRUE and you create some properties that are overlapping and then you reset the property to FALSE, is the calendar system suppose to do anything about the existing overlapping events that would otherwise not be allowed with the FALSE value? If not, then I think that this property has limited utility. The calendar system can ignore any other component that conflicts with the component that now has CONFLICT set to FALSE. It will still have the utility to prevent anyone from inviting the user to any new events during that time slot. It could be useful for a user who may often obtain many conflicts, and who, for certain events, does not want any conflicts, and for other less important events may allow conflicts (allowing the user to chose from the conflicting meetings). > > Better to have a CAP property that merely is active for the session and will notify a CUA if they try to create an event that overlaps an existing event. A user may want to prevent others from double booking him or her, or it can be used by a resource, such as a room, to prevent double booking. However, if it does cause interoperability or implementation problems, and we see a need for such functionality, we may need to restrict ourselves to a property that simply checks and notifies the user of any conflicts that he or she created. > > -- Frank George From owner-ietf-calendar@mail.imc.org Wed Aug 30 14:32: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 OAA06474 for ; Wed, 30 Aug 2000 14:32:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA17228 for ietf-calendar-bks; Wed, 30 Aug 2000 11:17: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 LAA17222; Wed, 30 Aug 2000 11:17: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 OAA12964; Wed, 30 Aug 2000 14:19:35 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA10111; Wed, 30 Aug 2000 14:17:29 -0400 (EDT) To: pregen@egenconsulting.com Cc: Bruce_Kahn@iris.com, eric@softwarestudio.org, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, sman@netscape.com (Steve Mansour) Subject: Re: iTIP: Who sent that message? X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Wed, 30 Aug 2000 14:17:04 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08232000 |August 23, 2000) at 08/30/2000 02:17:08 PM, Serialize complete at 08/30/2000 02:17:08 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00647A088525694B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00647A088525694B_= Content-Type: text/plain; charset="us-ascii" Yes, ma'am. --=_alternative 00647A088525694B_= Content-Type: text/html; charset="us-ascii"
Yes, ma'am. --=_alternative 00647A088525694B_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 11:56: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 LAA08562 for ; Thu, 31 Aug 2000 11:56:59 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA01651 for ietf-calendar-bks; Thu, 31 Aug 2000 08:28:19 -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 IAA01208 for ; Thu, 31 Aug 2000 08:26:55 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: George Babics Cc: Doug Royer , ietf-calendar@imc.org Subject: Re: Subject: Registration of text/calendar MIME property TRANSP X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 11:31:16 -0400 X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_08202000|August 20, 2000) at 08/31/2000 11:28:17 AM, Serialize by Notes Client on Bruce Kahn/Iris(Build V60_08202000|August 20, 2000) at 08/31/2000 11:28:17 AM, Serialize complete at 08/31/2000 11:28:17 AM, Itemize by Notes Client on Bruce Kahn/Iris(Build V60_08202000|August 20, 2000) at 08/31/2000 11:28:18 AM, S/MIME Sign complete at 08/31/2000 11:28:18 AM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 11:31:50 AM, Serialize complete at 08/31/2000 11:31:50 AM MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z8772_boundary_sign Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an S/MIME signed message. ---------z8772_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0054FCA68525694C_=" This is a multipart message in MIME format. --=_alternative 0054FCA68525694C_= Content-Type: text/plain; charset="us-ascii" George wrote: >That is, the attendee, and not the Organizer, who decides >whether one may double book that attendee at that time. The Organizer can still >give a suggestion of whether double booking be allowed or not. This would argue more for a separate property rather than a parameter on an ATTENDEE since it applies to the entry in the Attendees calendar rather than being a property of the person itself. Kind of like TRANSP... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0054FCA68525694C_= Content-Type: text/html; charset="us-ascii"
George wrote:
>That is, the attendee, and not the Organizer, who decides
>whether one may double book that attendee at that time. The Organizer can still
>give a suggestion of whether double booking be allowed or not.

This would argue more for a separate property rather than a parameter on an ATTENDEE since it applies to the entry in the Attendees calendar rather than being a property of the person itself.  Kind of like TRANSP...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0054FCA68525694C_=-- ---------z8772_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIawYJKoZIhvcNAQcCoIIIXDCCCFgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5 yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34 GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5 jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p 8qxJFReEDuso4koWno/wMYIBdTCCAXECAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34 GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKCBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA4MzExNTI4MTdaMCMGCSqGSIb3DQEJBDEWBBQI7cT6hxM2 QOQw82Q54zEYv18m3zBEBgkqhkiG9w0BCQ8xNzA1MAcGBSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICACgwDQYJKoZIhvcNAQEBBQAEQAwvT+9J1GN71aOC2HMx nW3O4AdDQGE+Bg2oHcuLthl3l83VKr2Fhy3M/oH3K3b0BEwb0dFmcv9QzJyqEpJEeYk= ---------z8772_boundary_sign-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 12:03: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 MAA08709 for ; Thu, 31 Aug 2000 12:03:25 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05825 for ietf-calendar-bks; Thu, 31 Aug 2000 08:48:59 -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 IAA05820 for ; Thu, 31 Aug 2000 08:48:54 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: IETF-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 11:52:35 -0400 X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_08202000|August 20, 2000) at 08/31/2000 11:49:36 AM, Serialize by Notes Client on Bruce Kahn/Iris(Build V60_08202000|August 20, 2000) at 08/31/2000 11:49:36 AM, Serialize complete at 08/31/2000 11:49:36 AM, Itemize by Notes Client on Bruce Kahn/Iris(Build V60_08202000|August 20, 2000) at 08/31/2000 11:49:36 AM, S/MIME Sign complete at 08/31/2000 11:49:36 AM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 11:53:49 AM, Serialize complete at 08/31/2000 11:53:49 AM MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z54697_boundary_sign Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an S/MIME signed message. ---------z54697_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0056F02F8525694C_=" This is a multipart message in MIME format. --=_alternative 0056F02F8525694C_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doug replied with: >If the CUA knows its timezone name, but does not have >the VTIMEZONE definition. Why not let the CUA choose? >Example: > > My mobile CUA thinks it's timezone is US/Pacific > because my OS says so. When I stated "I am 95% against having the CUA doing the choosing by=20 itself" I was considering the case where the CUA could be coded to use=20 some OS knowledge but not every OS has it (MacOS lacks it; not sure about=20 all Un*x's). If you only plan on supporting Windows OS CUAs (or on OS's=20 that do have some TZ knowledge) then the design is fine. Otherwise, the=20 CU and CUA should be working together instead of the CUA doing it possibly = right, possibly wrong. Lets pick a TZ that has exceptions, say Phoenix Arizona. If your OS only=20 has "US/Mountain" then your CUA will not properly be able to adjust for AZ = that does not support DST. For 6 months, your times will be wrong. If=20 you expect an OS that was coded 2 years ago to be fully updated w/all TZ=20 changes that can occur after its writing then you are in for a support=20 nightmare (ie: France changes the dates annually but I dont necessarily=20 run the French version of the OS if Im a mobile user from the UK or=20 Germany). >So my mobile CUA > queries a CAP server and provides my GEO position. >[Snip, snip] >I can write a tool that selects the correct VTIMEZONE America/Los=5FAngles >from a list.=1BThere are times when the CUA will know which to use. > >If it can't find a match - then the user selects. Ugh, just how will your tool know that Phoenix is in US/Mountain or=20 US/Mountain-NoDST (or as in your example that it wants=20 America/Los=5FAngeles)?? Is it psychic? I have yet to see a tool that can= =20 do this unless its coded with prior knowledge. Still, once coded the=20 knowledge can become stale or incorrect (ie: say AZ relents and decides to = go along w/the US/Mountain settings). At this point in time, our=20 knowledge based technology still cannot match the CU's ability to say=20 which one to use (or which they =5Fwant=5F used!). My point is simply this, a CUA should not always select the TZ settings by = itself and we have not yet codified the way that all 'interoperating'=20 implementations should work. I dont have the magic bullet for fixing this = apart from codifying the proper behavour for CUAs do follow when dealing=20 with TZ/DST selections. Leaving the methodology open will be just like=20 the multipart/* interop test mishaps we saw at CalConnect 1. Since the CAP folks are so gung ho on adding this ability, why not take=20 the time to learn from iCals multipart/* example and clearly specify how=20 =5Fall=5F CAP CUAs should function when doing this pretty key bit of=20 setup!?!?! (Just saying "the CUA will select the correct VTIMEZONE" is=20 smoke and mirrors, not a real solution!) Bruce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Kahn INet: Bruce=5FKahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0056F02F8525694C_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Doug replied with:
>If the CUA knows its timezone n= ame, but does not have
>the VTIMEZONE definition. Why not let the CUA choose?
>Example:
>
>                 My mobile CUA = thinks it's timezone is US/Pacific
>                 because my OS = says so.

When I stated "I am 95% against= having the CUA doing the choosing by itself" I was considering the ca= se where the CUA could be coded to use some OS knowledge but not every OS h= as it (MacOS lacks it; not sure about all Un*x's).  If you only plan o= n supporting Windows OS CUAs (or on OS's that do have some TZ knowledge) th= en the design is fine.  Otherwise, the CU and CUA should be working to= gether instead of the CUA doing it possibly right, possibly wrong.

Lets pick a TZ that has exceptions, = say Phoenix Arizona.  If your OS only has "US/Mountain" then= your CUA will not properly be able to adjust for AZ that does not support = DST.  For 6 months, your times will be wrong.  If you expect an O= S that was coded 2 years ago to be fully updated w/all TZ changes that can = occur after its writing then you are in for a support nightmare (ie: France= changes the dates annually but I dont necessarily run the French version o= f the OS if Im a mobile user from the UK or Germany).

>So my mobile CUA
>                 queries a CAP = server and provides my GEO position.
>[Snip, snip]
>I can write a tool that selects= the correct VTIMEZONE America/Los=5FAngles
>from a list.=1BThere are times when the CUA will know which to use.
>
>If it can't find a match - then the user selects.

Ugh, just how will your tool know th= at Phoenix is in US/Mountain or US/Mountain-NoDST (or as in your example th= at it wants America/Los=5FAngeles)??  Is it psychic?  I have yet = to see a tool that can do this unless its coded with prior knowledge.  = ;Still, once coded the knowledge can become stale or incorrect (ie: say AZ = relents and decides to go along w/the US/Mountain settings).  At this = point in time, our knowledge based technology still cannot match the CU's a= bility to say which one to use (or which they =5Fwant=5F used!).

My point is simply this, a CUA shoul= d not always select the TZ settings by itself and we have not yet codified = the way that all 'interoperating' implementations should work.  I dont= have the magic bullet for fixing this apart from codifying the proper beha= vour for CUAs do follow when dealing with TZ/DST selections.  Leaving = the methodology open will be just like the multipart/* interop test mishaps= we saw at CalConnect 1.

Since the CAP folks are so gung ho o= n adding this ability, why not take the time to learn from iCals multipart/= * example and clearly specify how =5Fall=5F CAP CUAs should function when d= oing this pretty key bit of setup!?!?!  (Just saying "the CUA wil= l select the correct VTIMEZONE" is smoke and mirrors, not a real solut= ion!)

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                   &= nbsp;            INet: Bruce=5FKahn@iris.com<= br> Iris Associates                 &nb= sp;        Phone: 978.392.5335
Westford, MA, USA 01886               &n= bsp;    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0056F02F8525694C_=-- ---------z54697_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIawYJKoZIhvcNAQcCoIIIXDCCCFgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5 yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34 GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5 jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p 8qxJFReEDuso4koWno/wMYIBdTCCAXECAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34 GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKCBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA4MzExNTQ5MzZaMCMGCSqGSIb3DQEJBDEWBBSzhZG4sHkO 3uJshEGSkhjX3wfNQjBEBgkqhkiG9w0BCQ8xNzA1MAcGBSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICACgwDQYJKoZIhvcNAQEBBQAEQMD8mcApk08I08NxdEGs XMMRK+y6FBDutE3ZxRIUhliiExhdEpVyGbH5MI9RnTbN8KQM7qx2c76tFHJSS1CqQ9o= ---------z54697_boundary_sign-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 12:16: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 MAA08862 for ; Thu, 31 Aug 2000 12:16:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA06746 for ietf-calendar-bks; Thu, 31 Aug 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 JAA06742 for ; Thu, 31 Aug 2000 09:02:01 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA05234 for ; Thu, 31 Aug 2000 12:05:17 -0400 Message-ID: <39AE823C.64D9C31E@ecal.com> Date: Thu, 31 Aug 2000 12:05:17 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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: > >I don't think it is an interop problem, actually; the timezone > > >choice occurs *before* the iCalendar is composed and sent over > > >the wire. > > Yes, once selected the CUA can store the selection but that > does not help in _picking_ the selection... > > So, please explain to me _exactly_ how 2 (or more) separate > CUAs will accuratly pick the proper VTimeZone to use for > Phoenix AZ or Paris, France w/o intervention or interaction > w/the CU. If the CAP server indicates that there are > 1 > VTimeZone in effect for that location (based on GEO_BOUNDS or > OS setting or some other inputs) then just how will _all_ CAP > complaint CUAs accurately select not only the proper VTimeZone > but also the _same_ one? They don't *need* to. As I said above, the timezone is selected once per event, by the creator of the event. After that, it's determined, and the picking doesn't happen again. It doesn't *matter* if two separate users make two separate choices for two separate events in the same place. Each event is self-describing and self-contained; there is no ambiguity. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I will not buy this .signature, it is scratched.| |francis@ecal.com| | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 31 12:16: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 MAA08874 for ; Thu, 31 Aug 2000 12:16:50 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA06065 for ietf-calendar-bks; Thu, 31 Aug 2000 08:54: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 IAA06055 for ; Thu, 31 Aug 2000 08:54:04 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 11:58:48 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 11:58:58 AM, Serialize complete at 08/31/2000 11:58:58 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005781FB8525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005781FB8525694C_= Content-Type: text/plain; charset="us-ascii" When John replied with: >> Ok, let me make my concern a bit sharper: I am 95% against >> having the CUA doing the choosing by itself (I can think of >> some cases where it MAY be ok but very very few). This is the >> interop nightmare. > >I don't think it is an interop problem, actually; the timezone >choice occurs *before* the iCalendar is composed and sent over >the wire. Yes, once selected the CUA can store the selection but that does not help in _picking_ the selection... So, please explain to me _exactly_ how 2 (or more) separate CUAs will accuratly pick the proper VTimeZone to use for Phoenix AZ or Paris, France w/o intervention or interaction w/the CU. If the CAP server indicates that there are > 1 VTimeZone in effect for that location (based on GEO_BOUNDS or OS setting or some other inputs) then just how will _all_ CAP complaint CUAs accurately select not only the proper VTimeZone but also the _same_ one? My answer: They cannot w/o CU intervention! As such, the current "Just pick one" solution will be a nightmare to interop test and for mobile CUs! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005781FB8525694C_= Content-Type: text/html; charset="us-ascii"
When John replied with:
>> Ok, let me make my concern a bit sharper: I am 95% against
>> having the CUA doing the choosing by itself (I can think of
>> some cases where it MAY be ok but very very few).  This is the
>> interop nightmare.
>
>I don't think it is an interop problem, actually; the timezone
>choice occurs *before* the iCalendar is composed and sent over
>the wire.

Yes, once selected the CUA can store the selection but that does not help in _picking_ the selection...

So, please explain to me _exactly_ how 2 (or more) separate CUAs will accuratly pick the proper VTimeZone to use for Phoenix AZ or Paris, France w/o intervention or interaction w/the CU.  If the CAP server indicates that there are > 1 VTimeZone in effect for that location (based on GEO_BOUNDS or OS setting or some other inputs) then just how will _all_ CAP complaint CUAs accurately select not only the proper VTimeZone but also the _same_ one?

My answer: They cannot w/o CU intervention!  As such, the current "Just pick one" solution will be a nightmare to interop test and for mobile CUs!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005781FB8525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 12:49: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 MAA09389 for ; Thu, 31 Aug 2000 12:49:29 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA08484 for ietf-calendar-bks; Thu, 31 Aug 2000 09:34:06 -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 JAA08477 for ; Thu, 31 Aug 2000 09:34:04 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 12:38:43 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 12:38:57 PM, Serialize complete at 08/31/2000 12:38:57 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005B29908525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B29908525694C_= Content-Type: text/plain; charset="us-ascii" John replied: >As I said above, the timezone is selected >once per event, by the creator of the event. After that, it's >determined, and the picking doesn't happen again. Not quite. Ever COUNTER or reschedule an entry on your calendar?? Changes do happen (at least on my calendar)... >It doesn't >*matter* if two separate users make two separate choices for two >separate events in the same place. Ahh, thats just fine if entries do not move when reschedule (or COUNTERed) but they can and will so the case cannot just be ignored or wished away... Especially for the mobile user who are more likely to use GEO_BOUNDS. There is also the case of a CU using > 1 CUAs (ie: 2 browsers on the same system) to do C&S. They may use CUA1 when on their 'beefy' work system and CUA2 for their mobile needs (ie: their PDA, their laptop). These CU are going to expect that creating an entry for the same TZ should result in the proper TZ settings being selected and used. If both CUAs do not follow the same methodology for selecting the TZ initially, this wont happen and nirvana wont be achievable. Also, it _does_ matter if we are both trying to schedule an entry for the same room and my CUA incorrectly says DST is in use for 6 months and I get misbooked for that time frame but your CUA (in the same company/organization/team) "behaves correctly" and get the correct TZ definition. I wind up being misbooked or not being able to get the room when it truely is available.... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005B29908525694C_= Content-Type: text/html; charset="us-ascii"
John replied:
>As I said above, the timezone is selected
>once per event, by the creator of the event.  After that, it's
>determined, and the picking doesn't happen again.

Not quite.  Ever COUNTER or reschedule an entry on your calendar??  Changes do happen (at least on my calendar)...

>It doesn't
>*matter* if two separate users make two separate choices for two
>separate events in the same place.

Ahh, thats just fine if entries do not move when reschedule (or COUNTERed) but they can and will so the case cannot just be ignored or wished away...  Especially for the mobile user who are more likely to use GEO_BOUNDS.

There is also the case of a CU using > 1 CUAs (ie: 2 browsers on the same system) to do C&S.  They may use CUA1 when on their 'beefy' work system and CUA2 for their mobile needs (ie: their PDA, their laptop).  These CU are going to expect that creating an entry for the same TZ should result in the proper TZ settings being selected and used.  If both CUAs do not follow the same methodology for selecting the TZ initially, this wont happen and nirvana wont be achievable.

Also, it _does_ matter if we are both trying to schedule an entry for the same room and my CUA incorrectly says DST is in use for 6 months and I get misbooked for that time frame but your CUA (in the same company/organization/team) "behaves correctly" and get the correct TZ definition.  I wind up being misbooked or not being able to get the room when it truely is available....

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005B29908525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 13:02: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 NAA09708 for ; Thu, 31 Aug 2000 13:02:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA08957 for ietf-calendar-bks; Thu, 31 Aug 2000 09:41:59 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08953 for ; Thu, 31 Aug 2000 09:41:58 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA05361 for ; Thu, 31 Aug 2000 12:45:14 -0400 Message-ID: <39AE8B98.D919E3F8@ecal.com> Date: Thu, 31 Aug 2000 12:45:13 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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: > John replied: > >As I said above, the timezone is selected > >once per event, by the creator of the event. After that, it's > > >determined, and the picking doesn't happen again. > > Not quite. Ever COUNTER or reschedule an entry on your > calendar?? Changes do happen (at least on my calendar)... Why does this make a difference? You reschedule, you send out a new iCalendar with, maybe, a new timezone. It's still unambiguous. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |There are many intelligent species in the | |francis@ecal.com|cosmos. All are owned by cats. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 31 13:45: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 NAA10409 for ; Thu, 31 Aug 2000 13:45:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09997 for ietf-calendar-bks; Thu, 31 Aug 2000 10:15:30 -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 KAA09986 for ; Thu, 31 Aug 2000 10:15:22 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 13:19:43 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 01:20:18 PM, Serialize complete at 08/31/2000 01:20:18 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005EEA4D8525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005EEA4D8525694C_= Content-Type: text/plain; charset="us-ascii" John replied: >> Not quite. Ever COUNTER or reschedule an entry on your >> calendar?? Changes do happen (at least on my calendar)... > >Why does this make a difference? You reschedule, you send out a >new iCalendar with, maybe, a new timezone. It's still >unambiguous. You're not getting my point. Yes, once specified its unambiguious. Its making sure that the CUA picks the right one in the first place... If each CUA picks differently for the same location, you dont interop well... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005EEA4D8525694C_= Content-Type: text/html; charset="us-ascii"
John replied:
>> Not quite.  Ever COUNTER or reschedule an entry on your
>> calendar??  Changes do happen (at least on my calendar)...
>
>Why does this make a difference? You reschedule, you send out a
>new iCalendar with, maybe, a new timezone.  It's still
>unambiguous.

You're not getting my point.  Yes, once specified its unambiguious.  Its making sure that the CUA picks the right one in the first place...  If each CUA picks differently for the same location, you dont interop well...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005EEA4D8525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 14:23: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 OAA11138 for ; Thu, 31 Aug 2000 14:23:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA12383 for ietf-calendar-bks; Thu, 31 Aug 2000 11:06:05 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12379 for ; Thu, 31 Aug 2000 11:06:03 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id OAA05742 for ; Thu, 31 Aug 2000 14:09:19 -0400 Message-ID: <39AE9F4E.515DD738@ecal.com> Date: Thu, 31 Aug 2000 14:09:19 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: calsch WG Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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: > You're not getting my point. Yes, once specified its > unambiguious. Its making sure that the CUA picks the right one > in the first place... "The right one" is the one the user picks. It has to be that way. When there are multiple timezones for a location, there is absolutely no way for any automated system to know which one the user wants; it's an AI-complete problem. Are you going to build a CUA that understands the user's politics? > If each CUA picks differently for the same location, you dont > interop well... Not at all. Different timezones for the same location have no impact on interop, because exactly one goes over the wire. The recipient doesn't pick a timezone based on LOCATION; they read it out of the TZID and VTIMEZONE. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |All I ask is a chance to prove that money can't| |francis@ecal.com|make me happy. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 31 15:06: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 PAA11762 for ; Thu, 31 Aug 2000 15:05:59 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA14677 for ietf-calendar-bks; Thu, 31 Aug 2000 11:45:52 -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 LAA14673 for ; Thu, 31 Aug 2000 11:45:51 -0700 (PDT) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id e7VIeTY08212 for ; Thu, 31 Aug 2000 11:40:29 -0700 (PDT) Received: from netscape.com (h-192-18-125-198.red.iplanet.com [192.18.125.198]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id LAA133862 for ; Thu, 31 Aug 2000 11:53:30 -0700 (PDT) Message-ID: <39AEA814.F6159DE0@netscape.com> Date: Thu, 31 Aug 2000 11:46:44 -0700 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP Restriction Table: CREATE Content-Type: multipart/mixed; boundary="------------F65282FFDA50B6398F6A6E2A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F65282FFDA50B6398F6A6E2A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's the latest. Comments would be appreciated. -Steve --------------F65282FFDA50B6398F6A6E2A Content-Type: text/plain; charset=us-ascii; name="restriction.txt" Content-Disposition: inline; filename="restriction.txt" Content-Transfer-Encoding: 7bit Restriction Tables Commands are sent to CAP servers encapsulated in iCalendar objects. The reply to these commands are also encapsulated in iCalendar objects. The restriction tables listed in the commands below describe the composition of these commands and replies. The Presence column uses the following values to assert whether a property is required, is optional and the number of times it may appear in the iCalendar object. A Comment may be provided to further clarify the presence criteria. The table below defines the values for the Presence column. Presence Value Description ------------------------------------------------------------------- 1 One instance MUST be present 1+ At least one instance MUST be present 0 Instances of this property Must NOT be present 0+ Multiple instances MAY be present 0 or 1 Up to 1 instance of this property MAY be present ------------------------------------------------------------------- While the tables list every component and property, their purpose is not to define the meaning of the component or property. There will be a RESPONSE-STATUS for each VCALENDAR and component created, modified, deleted, or requested. The number of RESPONSE-STATUS values returned MUST be equal to the number of TARGETS times the number of objects in the command. The responses MUST be ordered first by TARGET then by the order of the objects as supplied in the command. Client Restriction Table for the Create command Component/Property Presence Comment ------------------- -------- -------------------------------------- VCALENDAR 1+ The CUA can send up PIPELINE commands without processing a response CMDID 0 or 1 If CMDID is not supplied, then there must not be pending replies to previous command. VERSION 1 MUST be 2.0 VCOMMAND 1 MUST at least one container (VCALENDAR, VCAR, VQUERY, VEVENT, VTODO, VJOURNAL, V METHOD 1 MUST be CREATE. TARGET 1+ MUST be a the CSID or CALID VCALENDAR 0+ CALMASTER 0 or 1 NAME 0 or 1 The user friendly name, localizable. OWNER 1+ RELCALID 1 TZID 0 or 1 VCAR 0+ CARID 0 or 1 A reference name DENY 0+ permissions denied. Note, there must be at least one GRANT or DENY within the VCAR. GRANT 0+ permissions granted. Note, there must be at least one GRANT or DENY within the VCAR. VQUERY 0+ EXPAND 0 or 1 Expand recurrences or not MAXRESULTS 0 or 1 Limit the solution set to no more than this many enries. MAXSIZE 0 or 1 Maximum number of octets to transfer QUERYNAME 1 Name by which this query is referenced QUERY 1 The query VEVENT 0+ ATTENDEE 0+ SEQUENCE 0 or 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTEND 0 or 1 if present DURATION MUST NOT be present DTSTAMP 1 DTSTART 1 DURATION 0 or 1 if present DTEND MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 METHOD 1 <> ORGANIZER 1 PRIORITY 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUS 0+ RESOURCES 0 or 1 This property MAY contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED TRANSP 0 or 1 URL 0 or 1 X-PROPERTY 0+ [IANA-PROP] 0+ any IANA registered property VALARM 0+ ACTION 1 ALARMID 0 or 1 MUST be 1 if multiple VALARMs are present in same component. ATTACH 0+ DESCRIPTION 0 or 1 DURATION 0 or 1 if present REPEAT MUST be present REPEAT 0 or 1 if present DURATION MUST be present SUMMARY 0 or 1 TRIGGER 1 X-PROPERTY 0+ VTODO 0+ ATTENDEE 0+ SEQUENCE 0 or 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null. UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTSTAMP 1 DTSTART 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 METHOD 1 <> ORGANIZER 1 PRIORITY 1 PERCENT-COMPLETE 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUS 0 RESOURCES 0 or 1 This property may contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- PROCESS/CANCELLED URL 0 or 1 X-PROPERTY 0+ [IANA-PROP] 0+ any IANA registered property VALARM 0+ ACTION 1 ALARMID 0 or 1 MUST be 1 if multiple VALARMs are present in same component. ATTACH 0+ DESCRIPTION 0 or 1 DURATION 0 or 1 if present REPEAT MUST be present REPEAT 0 or 1 if present DURATION MUST be present SUMMARY 0 or 1 TRIGGER 1 X-PROPERTY 0+ VJOURNAL 0+ ATTENDEE 0 DESCRIPTION 1 Can be null. DTSTAMP 1 DTSTART 1 ORGANIZER 1 UID 1 ATTACH 0+ CATEGORIES 0 or 1 This property MAY contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 EXDATE 0+ EXRULE 0+ LAST-MODIFIED 0 or 1 METHOD 1 <> RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ RRULE 0+ SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. MUST be present if non-zero. MAY be present if zero. STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED SUMMARY 0 or 1 Can be null URL 0 or 1 X-PROPERTY 0+ VFREEBUSY 0 VTIMEZONE 0+ MUST be present if any date/time refers to timezone DAYLIGHT 0+ MUST be one or more of either STANDARD or DAYLIGHT COMMENT 0 or 1 DTSTART 1 MUST be local time format RDATE 0+ if present RRULE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present TZNAME 0 or 1 TZOFFSET 1 TZOFFSETFROM 1 TZOFFSETTO 1 X-PROPERTY 0+ LAST-MODIFIED 0 or 1 STANDARD 0+ MUST be one or more of either STANDARD or DAYLIGHT COMMENT 0 or 1 DTSTART 1 MUST be local time format RDATE 0+ if present RRULE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present TZNAME 0 or 1 TZOFFSETFROM 1 TZOFFSETTO 1 X-PROPERTY 0+ TZID 1 TZURL 0 or 1 X-PROPERTY 0+ Server Restriction Table for the CREATE command Component/Property Presence Comment ------------------- -------- -------------------------------------- VCALENDAR 1+ TARGET 1 VERSION 1 MUST be 2.0 CMDID 0 or 1 MUST be returned if the request contained a CMDID VALARM 0 RESPONSE-STATUS 0 if not creating a calendar 1+ if creating a calendar VCAR 0+ RESPONSE-STATUS 1+ * 0 No other VCAR properties are present VCOMMAND 0 VEVENT 0+ RESPONSE-STATUS 1+ * 0 No other VEVENT properties are present VFREEBUSY 0+ RESPONSE-STATUS 1+ * 0 No other VFREEBUSY properties are present VJOURNAL 0+ RESPONSE-STATUS 1+ * 0 No other VJOURNAL properties are present VQUERY 0+ RESPONSE-STATUS 1+ * 0 No other VQUERY properties are present VTODO 0+ RESPONSE-STATUS 1+ * 0 No other VTODO properties are present Issues: freebusy - a cap server should dynamically calculate freebusy information we recommend that you cannot create, modify, or delete freebusy composers --------------F65282FFDA50B6398F6A6E2A 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 tel;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------F65282FFDA50B6398F6A6E2A-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 15:24: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 PAA12033 for ; Thu, 31 Aug 2000 15:24:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15067 for ietf-calendar-bks; Thu, 31 Aug 2000 12:06:21 -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 MAA15058 for ; Thu, 31 Aug 2000 12:06:14 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: iTIP: Delegation chains X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 15:08:01 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:11:14 PM, Serialize complete at 08/31/2000 03:11:14 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0068D4AD8525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068D4AD8525694C_= Content-Type: text/plain; charset="us-ascii" All: In reviewing some iTIP topics that have yet to be resolved I had one Id like to add to the mix; delegation chains. More to the point, just how much of a delegation chain should be sent back to the Organzier when a 2nd (or later) generation Delegatee/Delegator sends a REPLY (or further delegates)? Should just 2 ATTENDEES be sent (the Delegator and the Delegatee) or should the entire chain be preserved (to avoid 'breakages' that may occur if iTIP/iMIP messages get lost in transit or by data corruptions)? Most Attendees may not care but the Organizer would for sure... Thoughts? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0068D4AD8525694C_= Content-Type: text/html; charset="us-ascii"
All:

  In reviewing some iTIP topics that have yet to be resolved I had one Id like to add to the mix; delegation chains.  More to the point, just how much of a delegation chain should be sent back to the Organzier when a 2nd (or later) generation Delegatee/Delegator sends a REPLY (or further delegates)?  Should just 2 ATTENDEES be sent (the Delegator and the Delegatee) or should the entire chain be preserved (to avoid 'breakages' that may occur if iTIP/iMIP messages get lost in transit or by data corruptions)?

  Most Attendees may not care but the Organizer would for sure...

  Thoughts?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0068D4AD8525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 15:34: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 PAA12159 for ; Thu, 31 Aug 2000 15:34:51 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA15057 for ietf-calendar-bks; Thu, 31 Aug 2000 12:06:06 -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 MAA15051 for ; Thu, 31 Aug 2000 12:05:47 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Re: RFC 2446 conflict: Delegation and REPLY X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 15:04:15 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:10:58 PM, Serialize complete at 08/31/2000 03:10:58 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00687C4F8525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00687C4F8525694C_= Content-Type: text/plain; charset="us-ascii" A while back I raised the case of a conflict in iTIP with regards to what goes into a delegation message in iTIP. There was no coverage of is so Im raising it again. Here is the original posting for thost that missed it the first time: Ok, while taking a breather to reread the RFCs yet again Ive found a discrepancy in RFC 2446 with respect to delegation and ATTENDEE properties. In particular 4.2.5 Delegating an Event When delegating an event request to another "Calendar User", the "Delegator" must both update the "Organizer" with a "REPLY" and send a request to the "Delegate". [Snip, snip] The "Delegator" MUST: . Send a "REPLY" to the "Organizer" with the following updates: . The "Delegator's" "ATTENDEE" property "partstat" parameter set to "delegated" and the "delegated-to" parameter is set to the address of the "Delegate" . Add an additional "ATTENDEE" property for the "Delegate" with the "delegated-from" property parameter set to the "Delegator" says that on my REPLY to the Organizer I can have 2 (or possibly more if I do delegation to > 1 CU!) ATTENDEE properties in it. A supporting example can be found in 4.2.6 Delegate Accepts the Meeting. However these are in direct conflict with: 3.2.2.3 Delegating an Event to another CU ... In response to the request, the "Delegate" MUST send a "REPLY" method to the "Organizer" and optionally, to the "Delegator". The "REPLY" method " SHOULD include the "ATTENDEE" property with the "delegated- from" parameter value of the "Delegator's" calendar address. and 3.2.3 REPLY ... Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "REPLY" VEVENT 1+ All components MUST have the same UID ATTENDEE 1 MUST be the address of the Attendee replying. This last line precludes doing what 4.2.5 advocates. Since we have not precluded that a Delegator can delegate to > 1 Delegatee, I think the table entry for ATTENDEE under 3.2.3 should be amended to: ATTENDEE 1+ MUST be the address of the Attendee replying and MAY include addresses of any delegates. We (or the current maintainers of the corrections list) need to resolve this potentially nasty interop issue in the next update to the RFCs... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00687C4F8525694C_= Content-Type: text/html; charset="us-ascii"
A while back I raised the case of a conflict in iTIP with regards to what goes into a delegation message in iTIP.  There was no coverage of is so Im raising it again.  Here is the original posting for thost that missed it the first time:

Ok, while taking a breather to reread the RFCs yet again Ive found a discrepancy in RFC 2446 with respect to delegation and ATTENDEE properties.  In particular

4.2.5 Delegating an Event

 When delegating an event request to another "Calendar User", the
 "Delegator" must both update the "Organizer" with a "REPLY" and send
 a request to the "Delegate". [Snip, snip]      The "Delegator" MUST:

   .  Send a "REPLY" to the "Organizer" with the following updates:
   .  The "Delegator's" "ATTENDEE" property "partstat" parameter set
      to "delegated" and the "delegated-to" parameter is set to the
      address of the "Delegate"
   .  Add an additional "ATTENDEE" property for the "Delegate" with
      the "delegated-from" property parameter set to the "Delegator"

says that on my REPLY to the Organizer I can have 2 (or possibly more if I do delegation to > 1 CU!) ATTENDEE properties in it.  A supporting example can be found in 4.2.6 Delegate Accepts the Meeting.  However these are in direct conflict with:

3.2.2.3 Delegating an Event to another CU
...
  In response to the request, the "Delegate" MUST send a "REPLY" method
 to the "Organizer" and optionally, to the "Delegator". The "REPLY"
 method " SHOULD include the "ATTENDEE" property with the "delegated-
 from" parameter value of the "Delegator's" calendar address.

and

3.2.3 REPLY
...
Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST be "REPLY"
VEVENT              1+      All components MUST have the same UID
  ATTENDEE        1       MUST be the address of the Attendee
                          replying.

This last line precludes doing what 4.2.5 advocates.  Since we have not precluded that a Delegator can delegate to > 1 Delegatee, I think the table entry for ATTENDEE under 3.2.3 should be amended to:

   ATTENDEE        1+      MUST be the address of the Attendee
                          replying and MAY include addresses of
                           any delegates.

We (or the current maintainers of the corrections list) need to resolve this potentially nasty interop issue in the next update to the RFCs...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00687C4F8525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 15: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 PAA12180 for ; Thu, 31 Aug 2000 15:36:10 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA15259 for ietf-calendar-bks; Thu, 31 Aug 2000 12:16:18 -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 MAA15255 for ; Thu, 31 Aug 2000 12:16:12 -0700 (PDT) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Delegation model: Breaking chains X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 15:21:00 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:21:06 PM, Serialize complete at 08/31/2000 03:21:08 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:21:08 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006A04C08525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A04C08525694C_= Content-Type: text/plain; charset="us-ascii" Ok, I had a tough time w/the subject but read on anyway... In the current iCalendar/iTIP model it is possible to have a delegation 'chain' several layers deep. Im curious what others think the proper behaviour should be in iCalendar/iTIP for dealing with delegatees that have been 'undelegated'. That is, I delegate to Frank Dawson who now becomes active in the workflow process; he may further delegate or stay active. At some point later on I decide I want to either designate a new Delegatee or to take back that entry (ie: I will attend the conf. call after all). So, here are some of my questions: Just what becomes of Frank (and other 'sub-Delegatees' he may have created by that time)? Is Frank punted from the process?? If so, how? If not, what exactly is his standing then (and should he still be my "Delegatee")?? Does Frank continue to be my Delegatee even though I change it to someone else? Just how does the Delegator tell the Delegatee that they are no longer the Delegatee? (Or does the Organzier have to do this??) Thats enough for now. Thoughts?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006A04C08525694C_= Content-Type: text/html; charset="us-ascii"
Ok, I had a tough time w/the subject but read on anyway...

In the current iCalendar/iTIP model it is possible to have a delegation 'chain' several layers deep.  Im curious what others think the proper behaviour should be in iCalendar/iTIP for dealing with delegatees that have been 'undelegated'.  That is, I delegate to Frank Dawson who now becomes active in the workflow process; he may further delegate or stay active.  At some point later on I decide I want to either designate a new Delegatee or to take back that entry (ie: I will attend the conf. call after all).  So, here are some of my questions:

Just what becomes of Frank (and other 'sub-Delegatees' he may have created by that time)?  
Is Frank punted from the process??  If so, how?  If not, what exactly is his standing then (and should he still be my "Delegatee")??
Does Frank continue to be my Delegatee even though I change it to someone else?  
Just how does the Delegator tell the Delegatee that they are no longer the Delegatee?  (Or does the Organzier have to do this??)

Thats enough for now.  Thoughts??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006A04C08525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 15:39:41 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 PAA12194 for ; Thu, 31 Aug 2000 15:39:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15363 for ietf-calendar-bks; Thu, 31 Aug 2000 12:23:36 -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 MAA15359; Thu, 31 Aug 2000 12:23:34 -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 PAA13631; Thu, 31 Aug 2000 15:26:13 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA29242; Thu, 31 Aug 2000 15:24:06 -0400 (EDT) To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Thu, 31 Aug 2000 15:23:41 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08292000 |August 29, 2000) at 08/31/2000 03:23:43 PM, Serialize complete at 08/31/2000 03:23:43 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006A93648525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A93648525694C_= Content-Type: text/plain; charset="us-ascii" John: I think your scenario is different than the one that Doug Royer was quoting. -- Frank --=_alternative 006A93648525694C_= Content-Type: text/html; charset="us-ascii"
John:

I think your scenario is different than the one that Doug Royer was quoting.

-- Frank --=_alternative 006A93648525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 15:47: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 PAA12291 for ; Thu, 31 Aug 2000 15:47:08 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA15476 for ietf-calendar-bks; Thu, 31 Aug 2000 12:30:47 -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 MAA15472; Thu, 31 Aug 2000 12:30:46 -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 PAA15133; Thu, 31 Aug 2000 15:33:23 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA00716; Thu, 31 Aug 2000 15:31:17 -0400 (EDT) To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Thu, 31 Aug 2000 15:30:20 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08292000 |August 29, 2000) at 08/31/2000 03:30:54 PM, Serialize complete at 08/31/2000 03:30:54 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006B2EFD8525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B2EFD8525694C_= Content-Type: text/plain; charset="us-ascii" >Why does this make a difference? You reschedule, you send out a >new iCalendar with, maybe, a new timezone. It's still >unambiguous. John: I repeat...I don't think that you and Doug Royer had the same scenarios for "picking time zones". As I remember Doug was focused on using a CAP server to help a CUA determine what the property time zone was, based on geopositioning information. Hence, in this scenario each time you go and schedule you will be checking a CAP service somewhere to find out "now what time zone am I in now". As Bruce pointed out, you may be using different CUAs for the initial invite and the reschedule and I would like to point out that these two iTIP/iMIP operations might be in different time zones. So, it's not a question of getting a new time zone information prior to the rescheduling operation, but getting numerous time zone information choices and having to pick one to use for the reschedule. We need to be clear and unambiguous about how a CUA is to choose which of a number of possible choice it should use. Bruce is pointing out that the choice necessitates both the CUA and the possible intervention of a CU. Given this, I don't see how we can codify this. Our task isn't to involve UI standardization. Not really sure it should involve MCI design either. -- Frank -- Frank --=_alternative 006B2EFD8525694C_= Content-Type: text/html; charset="us-ascii"
>Why does this make a difference? You reschedule, you send out a
>new iCalendar with, maybe, a new timezone.  It's still
>unambiguous.

John:

I repeat...I don't think that you and Doug Royer had the same scenarios for "picking time zones".

As I remember Doug was focused on using a CAP server to help a CUA determine what the property time zone was, based on geopositioning information.

Hence, in this scenario each time you go and schedule you will be checking a CAP service somewhere to find out "now what time zone am I in now".

As Bruce pointed out, you may be using different CUAs for the initial invite and the reschedule and I would like to point out that these two iTIP/iMIP operations might be in different time zones.

So, it's not a question of getting a new time zone information prior to the rescheduling operation, but getting numerous time zone information choices and having to pick one to use for the reschedule.

We need to be clear and unambiguous about how a CUA is to choose which of a number of possible choice it should use. Bruce is pointing out that the choice necessitates both the CUA and the possible intervention of a CU.

Given this, I don't see how we can codify this. Our task isn't to involve UI standardization. Not really sure it should involve MCI design either.

-- Frank

-- Frank --=_alternative 006B2EFD8525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 15:49: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 PAA12320 for ; Thu, 31 Aug 2000 15:49:28 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA15486 for ietf-calendar-bks; Thu, 31 Aug 2000 12:31:37 -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 MAA15481 for ; Thu, 31 Aug 2000 12:31:18 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: calsch WG Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 15:36:00 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:36:28 PM, Serialize complete at 08/31/2000 03:36:30 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:36:30 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006B64B38525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B64B38525694C_= Content-Type: text/plain; charset="us-ascii" John replied: >"The right one" is the one the user picks. It has to be that >way.[Snip]Are you going to build >a CUA that understands the user's politics? Now you are on my side of this chat w/Doug. He claims he can "write a tool" to pick it. I claim its not going to work and that the CU MUST be involved in the process; the CUA CANNOT do it properly 100% of the time (not that CUs are perfect but thats different...) The current text (and the arguments from Doug) just handwave on _how_ the proper TZ is picked when there are multiple GEO_BOUNDS that match. I objected and this thread began. I want to have some text that unambiguously states the process ALL conformant CUAs follow to select the proper TZ, thats all! I do not want it left up to each CUA author to make assumptions!! (You missed the CalConnect 1 and multipart/* messages I take it...) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B64B38525694C_= Content-Type: text/html; charset="us-ascii"
John replied:
>"The right one" is the one the user picks.  It has to be that
>way.[Snip]Are you going to build
>a CUA that understands the user's politics?

Now you are on my side of this chat w/Doug.  He claims he can "write a tool" to pick it.  I claim its not going to work and that the CU MUST be involved in the process; the CUA CANNOT do it properly 100% of the time (not that CUs are perfect but thats different...)

The current text (and the arguments from Doug) just handwave on _how_  the proper TZ is picked when there are multiple GEO_BOUNDS that match.  I objected and this thread began.  I want to have some text that unambiguously states the process ALL conformant CUAs follow to select the proper TZ, thats all!  I do not want it left up to each CUA author to make assumptions!!  (You missed the CalConnect 1 and multipart/* messages I take it...)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006B64B38525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 16:03: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 QAA12479 for ; Thu, 31 Aug 2000 16:03:09 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA15750 for ietf-calendar-bks; Thu, 31 Aug 2000 12:45:14 -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 MAA15739 for ; Thu, 31 Aug 2000 12:44:53 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: Steve Mansour Cc: CalSched IETF Subject: Re: CAP Restriction Table: CREATE X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 15:47:15 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:50:07 PM, Serialize complete at 08/31/2000 03:50:07 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006C6C4B8525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C6C4B8525694C_= Content-Type: text/plain; charset="us-ascii" Second quick observation: VALARM 0 RESPONSE-STATUS 0 if not creating a calendar 1+ if creating a calendar Why is 1+ creating a calendar if it is in a VALARM? I think this is a typo (or Im just not groking vAlarms anymore). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006C6C4B8525694C_= Content-Type: text/html; charset="us-ascii"
Second quick observation:

VALARM               0

   RESPONSE-STATUS  0       if not creating a calendar
                    1+      if creating a calendar

Why is 1+ creating a calendar if it is in a VALARM?  I think this is a typo (or Im just not groking vAlarms anymore).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006C6C4B8525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 16:03: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 QAA12490 for ; Thu, 31 Aug 2000 16:03:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15738 for ietf-calendar-bks; Thu, 31 Aug 2000 12:44:50 -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 MAA15733 for ; Thu, 31 Aug 2000 12:44:45 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: Steve Mansour Cc: CalSched IETF Subject: Re: CAP Restriction Table: CREATE X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 15:44:42 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:49:41 PM, Serialize complete at 08/31/2000 03:49:42 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 03:49:42 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006C30868525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C30868525694C_= Content-Type: text/plain; charset="us-ascii" One quick observation based on recent events: [IANA-PROP] 0+ any IANA registered property should be in ALL continers. Its missing from your vAlarm, vCAR, vQuery and possibly others... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006C30868525694C_= Content-Type: text/html; charset="us-ascii"
One quick observation based on recent events:

      [IANA-PROP]          0+      any IANA registered property

should be in ALL continers.  Its missing from your vAlarm, vCAR, vQuery and possibly others...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006C30868525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 16:05:25 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 QAA12514 for ; Thu, 31 Aug 2000 16:05:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15610 for ietf-calendar-bks; Thu, 31 Aug 2000 12:38:29 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15606 for ; Thu, 31 Aug 2000 12:38:27 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id PAA06189 for ; Thu, 31 Aug 2000 15:41:44 -0400 Message-ID: <39AEB4F8.49BAF5B8@ecal.com> Date: Thu, 31 Aug 2000 15:41:44 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS 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: > I repeat...I don't think that you and Doug Royer had the same > scenarios for "picking time zones". > > As I remember Doug was focused on using a CAP server to help a > CUA determine what the property time zone was, based on > geopositioning information. Yeah, that's what I have in mind, too. > Hence, in this scenario each time you go and schedule you will > be checking a CAP service somewhere to find out "now what time > zone am I in now". (Not necessarily *each* time, but yeah.) > As Bruce pointed out, you may be using different CUAs for the > initial invite and the reschedule and I would like to point out > that these two iTIP/iMIP operations might be in different time > zones. (a) I don't think two CUAs should ever behave differently, because the only correct behavior is "ask the user". (b) Even if this does come up, I still don't think it's an interop problem. Even if the initial invitation and the reschedule come out with different time zones, what is it going to affect? The recipient's CUA will to translate the event's time into their local time, and everybody will agree on when to show up. > Given this, I don't see how we can codify this. I think we just have to say, "CUA, if you find more than one timezone for a location, ask the user. Don't guess." This can't be normative, because it doesn't affect interop; but it can be strong advice. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |The cheapest, fastest, most reliable components| |francis@ecal.com|of a computer system are those that aren't | | |there.--Gordon Bell | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 31 18:03: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 SAA13606 for ; Thu, 31 Aug 2000 18:03:06 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA18365 for ietf-calendar-bks; Thu, 31 Aug 2000 14:41:54 -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 OAA18360 for ; Thu, 31 Aug 2000 14:41:51 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: RFC 2445 & RECURRNECE-ID X-Mailer: Lotus Notes Build V60_08202000 August 20, 2000 Message-ID: Date: Thu, 31 Aug 2000 16:55:08 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 08/31/2000 05:46:47 PM, Serialize complete at 08/31/2000 05:46:47 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0072F9A38525694C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072F9A38525694C_= Content-Type: text/plain; charset="us-ascii" Time for a change of focus, back to RFC 2445. In trying to work on recurrences better I noticed a slight oversight in the current RFC 2445 text WRT RECURRENCE-ID and multiple recurrences on the same day. The ABNF for RECURRENCE-ID is: recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF ridparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE)) / (";" tzidparam) / (";" rangeparam) / [Snip] ) ridval = date-time / date ;Value MUST match value type There is also text in the description that says: If the value of the "DTSTART" property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. However we did overlook a possibility, that the entry repeats more than once on the same day (ie: BYHOUR=9,10) and the CUA sends: DTSTART:20000901T090000 RECURRENCE-ID;VALUE=DATE:20000904 Just which instance is this RECURRENCE-ID for (there is no RANGE parameter)?? I think we should tighten up RFC 2445 to to address the multiple instance on a single day case when VALUE=DATE is specified. In particular I suggest we expressly preclude VALUE=DATE (and date only values) when are > 1 instances on that date. Comments?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072F9A38525694C_= Content-Type: text/html; charset="us-ascii"
Time for a change of focus, back to RFC 2445.  In trying to work on recurrences better I noticed a slight oversight in the current RFC 2445 text WRT RECURRENCE-ID and multiple recurrences on the same day.  The ABNF for RECURRENCE-ID is:

     recurid    = "RECURRENCE-ID" ridparam ":" ridval CRLF

    ridparam   = *(

               ; the following are optional,
               ; but MUST NOT occur more than once

               (";" "VALUE" "=" ("DATE-TIME" / "DATE)) /
               (";" tzidparam) / (";" rangeparam) /
[Snip]
                )

    ridval     = date-time / date
    ;Value MUST match value type

There is also text in the description that says:

   If the value of the "DTSTART" property is a DATE type value, then the
  value MUST be the calendar date for the recurrence instance.
However we did overlook a possibility, that the entry repeats more than once on the same day (ie: BYHOUR=9,10) and the CUA sends:

        DTSTART:20000901T090000
        RECURRENCE-ID;VALUE=DATE:20000904

Just which instance is this RECURRENCE-ID for (there is no RANGE parameter)??  I think we should tighten up RFC 2445 to to address the multiple instance on a single day case when VALUE=DATE is specified.  In particular I suggest we expressly preclude VALUE=DATE (and date only values) when are > 1 instances on that date.  Comments??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0072F9A38525694C_=-- From owner-ietf-calendar@mail.imc.org Thu Aug 31 23:49: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 XAA20334 for ; Thu, 31 Aug 2000 23:49:09 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA18122 for ietf-calendar-bks; Thu, 31 Aug 2000 20:32:14 -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 UAA18118 for ; Thu, 31 Aug 2000 20:32:13 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e813Qvu02887 for ; Thu, 31 Aug 2000 20:26:58 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G06V6R02.E34; Thu, 31 Aug 2000 20:32:51 -0700 Message-ID: <39AF234E.BD8AADE4@netscape.com> Date: Thu, 31 Aug 2000 20:32:30 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: CalSched IETF Subject: Re: CAP Restriction Table: CREATE References: Content-Type: multipart/mixed; boundary="------------79EB9B8050544A310FA6E825" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------79EB9B8050544A310FA6E825 Content-Type: multipart/alternative; boundary="------------78F330224A242800555801D3" --------------78F330224A242800555801D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit fixed. Thanks. -Steve Bruce_Kahn@iris.com wrote: > > One quick observation based on recent events: > > [IANA-PROP] 0+ any IANA registered property > > should be in ALL continers. Its missing from your vAlarm, vCAR, > vQuery and possibly others... > > 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... --------------78F330224A242800555801D3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit fixed. Thanks.
-Steve

Bruce_Kahn@iris.com wrote:

 
One quick observation based on recent events:

      [IANA-PROP]          0+      any IANA registered property

should be in ALL continers.  Its missing from your vAlarm, vCAR, vQuery and possibly others...

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

--------------78F330224A242800555801D3-- --------------79EB9B8050544A310FA6E825 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 tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------79EB9B8050544A310FA6E825--