From owner-ietf-calendar@mail.imc.org Thu Nov 1 11:31:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23090 for ; Thu, 1 Nov 2001 11:31:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA1FxgX25191 for ietf-calendar-bks; Thu, 1 Nov 2001 07:59:42 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1Fxd825173 for ; Thu, 1 Nov 2001 07:59:39 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA12788 for ; Thu, 1 Nov 2001 10:59:34 -0500 Received: from steltor.com ([192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA1FxWH12412 for ; Thu, 1 Nov 2001 10:59:32 -0500 (EST) Message-ID: <3BE1715B.26F6D9BC@steltor.com> Date: Thu, 01 Nov 2001 10:59:23 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: Filing of components References: <3BBDAA10.A5C864D6@steltor.com> <3BC2155C.A3CF8C9D@Royer.com> <3BC4BFFE.9ABF0100@steltor.com> <3BCB7F39.1948F17E@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 Bernard Desruisseaux wrote: > > CAP doesn't allow calendar users to move components between > calendars. Currently, the MOVE command can only be "used to > move a calendar within the CS's hierarchy of calendars". Can we close this issue by simply modifying the MOVE command to allow calendar users to move components between calendars? To modify the MOVE command as such, I propose the addition of a DESTINATION property to specify the address of the calendar into which components should be moved. Furthermore, I propose to use a VQUERY component to select the components to be moved. To stay consistent with the READ command, the VQUERY would perform its selection on all the TARGET(s) specified in the VCOMMAND. Here's two examples: # # Move the event with the UID "123456789@host1.com" # currently stored in the calendar "relcalid-source" # into the calendar "relcalid-destination". # BEGIN:VCALENDAR VERSION:2.1 BEGIN:VCOMMAND METHOD:MOVE DESTINATION:relcalid-destination TARGET:relcalid-source BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = '123456789@host1.com' END:VQUERY END:VCOMMAND END:VCALENDAR # # Move the agenda with the RELCALID "relcalid-agenda" # currently stored in the calendar "relcalid-source" # into the calendar "relcalid-destination". # BEGIN:VCALENDAR VERSION:2.1 BEGIN:VCOMMAND METHOD:MOVE DESTINATION:relcalid-destination TARGET:relcalid-source BEGIN:VQUERY QUERY:SELECT * FROM VAGENDA WHERE RELCALID = 'relcalid-agenda' END:VQUERY END:VCOMMAND END:VCALENDAR Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Nov 1 12:46:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25252 for ; Thu, 1 Nov 2001 12:46:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA1HGZ302573 for ietf-calendar-bks; Thu, 1 Nov 2001 09:16:35 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1HGX802568 for ; Thu, 1 Nov 2001 09:16:33 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA17631; Thu, 1 Nov 2001 11:15:34 -0600 From: "Shannon J. Clark" To: "Bernard Desruisseaux" , Subject: RE: CAP: Filing of components Date: Thu, 1 Nov 2001 11:15:46 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3BE1715B.26F6D9BC@steltor.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In looking at this a few questions come to my mind as a vendor considering implementing CAP. 1 - does this add another layer of security complexity that I must negotiate and handle? 2 - What defines a valid "DESTINATION" - at the very least this would need to be clearly spelled out 3 - Within a specific CS I am comfortable that UID's assigned will be unique, that I can validate users, that I can manage access rights to each calendar etc. - when it comes to a separate CS - I become somewhat less confident - what needs to be negotiated between the two CS to handle a MOVE command as proposed cleanly? - CS & CSofDestination must agree on access rights (to the old Calendar and the Destination Calendar) - CS & CSofDestination must agree on uniqueness of component being moved - i.e. there must be some means to handle a message from CSofDestination "already here" - Should this be a "Transaction" - i.e. what happens on error conditions - when is the "moved" object REMOVED from the original Calendar? Within one CS I as a vendor can take steps to ensure transactional integrity within actions on that server - but as soon as I am negotiating a transaction with another server it is a more complex action. - Can a MOVE command happen via another means? i.e. can (should?) it be possible via email (iMIP) - my initial reaction would be NO - but it does raise questions 4 - logically what is happening if a component is moved from one calendar to another? Does this trigger another round of messages if the component in question is a meeting? i.e. what is the difference between DELEGATING the meeting to another ATTENDEE and MOVEing the meeting component to another calendar? 5 - Are vendors in fact implementing and using Parent/child relationships between Calendars? My rough reading of CAP was that MOVE was intended to move whole Calendars within hierarchies of calendars - i.e. a command to modify the PARENT and CHILD fields. However I have not seen well detailed and documented examples of how these are intended to be used. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Bernard Desruisseaux Sent: Thursday, November 01, 2001 9:59 AM To: ietf-calendar@imc.org Subject: Re: CAP: Filing of components Bernard Desruisseaux wrote: > > CAP doesn't allow calendar users to move components between > calendars. Currently, the MOVE command can only be "used to > move a calendar within the CS's hierarchy of calendars". Can we close this issue by simply modifying the MOVE command to allow calendar users to move components between calendars? To modify the MOVE command as such, I propose the addition of a DESTINATION property to specify the address of the calendar into which components should be moved. Furthermore, I propose to use a VQUERY component to select the components to be moved. To stay consistent with the READ command, the VQUERY would perform its selection on all the TARGET(s) specified in the VCOMMAND. Here's two examples: # # Move the event with the UID "123456789@host1.com" # currently stored in the calendar "relcalid-source" # into the calendar "relcalid-destination". # BEGIN:VCALENDAR VERSION:2.1 BEGIN:VCOMMAND METHOD:MOVE DESTINATION:relcalid-destination TARGET:relcalid-source BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = '123456789@host1.com' END:VQUERY END:VCOMMAND END:VCALENDAR # # Move the agenda with the RELCALID "relcalid-agenda" # currently stored in the calendar "relcalid-source" # into the calendar "relcalid-destination". # BEGIN:VCALENDAR VERSION:2.1 BEGIN:VCOMMAND METHOD:MOVE DESTINATION:relcalid-destination TARGET:relcalid-source BEGIN:VQUERY QUERY:SELECT * FROM VAGENDA WHERE RELCALID = 'relcalid-agenda' END:VQUERY END:VCOMMAND END:VCALENDAR Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Nov 1 14:52:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28741 for ; Thu, 1 Nov 2001 14:52:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA1JQdv07666 for ietf-calendar-bks; Thu, 1 Nov 2001 11:26:39 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1JQc807659 for ; Thu, 1 Nov 2001 11:26:38 -0800 (PST) From: Robert_Ransdell@iris.com To: "ietf-calendar@imc.org" Subject: Fw: DATE values question MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10302001 Beta 4 October 30, 2001 Message-ID: Date: Thu, 1 Nov 2001 14:26:35 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_10252001|October 25, 2001) at 11/01/2001 02:22:38 PM, Serialize complete at 11/01/2001 02:22:38 PM Content-Type: multipart/alternative; boundary="=_alternative 006A5FB685256AF7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A5FB685256AF7_= Content-Type: text/plain; charset="US-ASCII" DTSTART;VALUE=DATE:20011009 DTEND;VALUE=DATE:20011013 In my opinion would run from 20011009T000000 to 20011013T235959 ie 4 days In my opinion is ----- Forwarded by Robert Ransdell/Iris on 11/01/2001 02:17 PM ----- Bruce Kahn 11/01/2001 02:20 PM To: Robert Ransdell/Iris@Iris cc: Subject: Fw: DATE values question =========================================================================== 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... ----- Forwarded by Bruce Kahn/Westford/IBM on 11/01/2001 02:16 PM ----- Damon Chaplin cc: Subject: DATE values question If I have a VEVENT like this: DTSTART;VALUE=DATE:20010910 DTEND;VALUE=DATE:20011310 (i.e. from 9th Oct to 13th Oct) Does it: a) include the 13th October entirely, up to midnight. or b) stop at 12am on 13th. Damon --=_alternative 006A5FB685256AF7_= Content-Type: text/html; charset="US-ASCII"
DTSTART;VALUE=DATE:20011009
DTEND;VALUE=DATE:20011013

In my opinion would run from 20011009T000000
to                                                  20011013T235959

ie 4 days

In my opinion is
----- Forwarded by Robert Ransdell/Iris on 11/01/2001 02:17 PM -----
Bruce Kahn

11/01/2001 02:20 PM

       
        To:        Robert Ransdell/Iris@Iris
        cc:        
        Subject:        Fw: DATE values question


===========================================================================
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...
----- Forwarded by Bruce Kahn/Westford/IBM on 11/01/2001 02:16 PM -----
Damon Chaplin <damon
Sent by: owner-ietf-calendar@mail.imc.org

10/28/2001 08:58 PM

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        DATE values question





If I have a VEVENT like this:

DTSTART;VALUE=DATE:20010910
DTEND;VALUE=DATE:20011310

(i.e. from 9th Oct to 13th Oct)

Does it:

    a) include the 13th October entirely, up to midnight.
 or b) stop at 12am on 13th.


Damon

--=_alternative 006A5FB685256AF7_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 1 14:56:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28810 for ; Thu, 1 Nov 2001 14:56:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA1JSGR07808 for ietf-calendar-bks; Thu, 1 Nov 2001 11:28:16 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1JSF807804 for ; Thu, 1 Nov 2001 11:28:15 -0800 (PST) From: Robert_Ransdell@iris.com MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Fw: DATE values question --- OOPS 5 DAYS X-Mailer: Lotus Notes Build M11_10302001 Beta 4 October 30, 2001 Message-ID: Date: Thu, 1 Nov 2001 14:28:14 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_10252001|October 25, 2001) at 11/01/2001 02:24:15 PM, Serialize complete at 11/01/2001 02:24:15 PM Content-Type: multipart/alternative; boundary="=_alternative 006A863D85256AF7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A863D85256AF7_= Content-Type: text/plain; charset="US-ASCII" DTSTART;VALUE=DATE:20011009 DTEND;VALUE=DATE:20011013 In my opinion would run from 20011009T000000 to 20011013T235959 ie 5 days In my opinion is ----- Forwarded by Robert Ransdell/Iris on 11/01/2001 02:17 PM ----- Bruce Kahn 11/01/2001 02:20 PM To: Robert Ransdell/Iris@Iris cc: Subject: Fw: DATE values question =========================================================================== 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... ----- Forwarded by Bruce Kahn/Westford/IBM on 11/01/2001 02:16 PM ----- Damon Chaplin cc: Subject: DATE values question If I have a VEVENT like this: DTSTART;VALUE=DATE:20010910 DTEND;VALUE=DATE:20011310 (i.e. from 9th Oct to 13th Oct) Does it: a) include the 13th October entirely, up to midnight. or b) stop at 12am on 13th. Damon --=_alternative 006A863D85256AF7_= Content-Type: text/html; charset="US-ASCII"
DTSTART;VALUE=DATE:20011009
DTEND;VALUE=DATE:20011013

In my opinion would run from 20011009T000000
to                                                  20011013T235959

ie 5 days

In my opinion is
----- Forwarded by Robert Ransdell/Iris on 11/01/2001 02:17 PM -----
Bruce Kahn

11/01/2001 02:20 PM

       
        To:        Robert Ransdell/Iris@Iris
        cc:        
        Subject:        Fw: DATE values question


===========================================================================
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...
----- Forwarded by Bruce Kahn/Westford/IBM on 11/01/2001 02:16 PM -----
Damon Chaplin <damon
Sent by: owner-ietf-calendar@mail.imc.org

10/28/2001 08:58 PM

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        DATE values question





If I have a VEVENT like this:

DTSTART;VALUE=DATE:20010910
DTEND;VALUE=DATE:20011310

(i.e. from 9th Oct to 13th Oct)

Does it:

    a) include the 13th October entirely, up to midnight.
 or b) stop at 12am on 13th.


Damon

--=_alternative 006A863D85256AF7_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 1 15:15:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29250 for ; Thu, 1 Nov 2001 15:15:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA1Jrgp09149 for ietf-calendar-bks; Thu, 1 Nov 2001 11:53:42 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1Jrd809145 for ; Thu, 1 Nov 2001 11:53:40 -0800 (PST) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: ietf-calendar@imc.org Subject: Re: DATE values question MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: Date: Thu, 1 Nov 2001 14:50:39 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_10252001|October 25, 2001) at 11/01/2001 02:49:40 PM, Serialize complete at 11/01/2001 02:49:40 PM Content-Type: multipart/alternative; boundary="=_alternative 006CAF2485256AF7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CAF2485256AF7_= Content-Type: text/plain; charset="US-ASCII" Damon wrote on 10/28/2001 08:58:21 PM: > If I have a VEVENT like this: > > DTSTART;VALUE=DATE:20010910 > DTEND;VALUE=DATE:20011310 > > (i.e. from 9th Oct to 13th Oct) Umm, I think you meant to say 20011009 and 20011013, respectively... :^) > Does it: > > a) include the 13th October entirely, up to midnight. > or b) stop at 12am on 13th. We never resolved this thread I dont think when we covered it back in 1999 (yep, that far back). Look for the thread titled "Recurring Anniversary Instances?" and then perhaps we can come to a final resolution of this issue. However in the interest of time Ill forge ahead and rehash a bit and put my stick in the ground as to what I think the answer is. Some relevant RFC citations for those who want a jumpstart, RFC 2445, p 53: The "VEVENT" is also the calendar component used to specify an anniversary or daily reminder within a calendar. These events have a DATE value type for the "DTSTART" property instead of the default data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be specified as a DATE value also. The anniversary type of "VEVENT" can span more than one date (i.e, "DTEND" property value is set to a calendar date after the "DTSTART" property value). The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE data type but no "DTEND" property, the events non-inclusive end is the end of the calendar date specified by the "DTSTART" property. Part of the original discussion was about DATE & DATE-TIME equivalents but I think the last line of the 1st paragraph will help us make a decision thats consistant one way or another. One would logically infer from the text above that since: DTSTART;VALUE=DATE:20011009 alone is an "all day" (09-Oct-2001) event and that: DTSTART;VALUE=DATE:20011009 DTEND;VALUE=DATE:20011010 would be a "two day" (09-Oct-2001 & 10-Oct-2001) event. However some have argued that the 2 day example is wrong and should be: DTSTART;VALUE=DATE:20011009 DTEND;VALUE=DATE:20011011 since the time defaulted should be 00:00:00. Also, we never did resolve the case of what does/should: DTSTART;VALUE=DATE:20011009 DTEND;VALUE=DATE:20011009 mean. Technially DTEND is not "after" DTSTART so some think this is 'illegal'. Others claim that DTEND is after DTSTART since they view the time for DTSTART as being 00:00:00 (Local) and the time of DTEND as being 23:59:59 (Local). The citation appears to bear out this argument but it should be noted that A) the text never says the DTEND is "1 day after" the DTSTART, it simply says "is set to a calendar date after the "DTSTART"" and B) while this "ends are relative to the end of the day" argument sounds normal it is by no means consistant with regard to defaulting times. Unfortunately we have no good iTIP/iMIP examples to use to resolve this but my take on this issues remains that the time always defaults to 00:00:00 (so the DATE value must be selected accordingly). To directly answer your (corrected) question, I would claim that 13-Oct-2001 is not included as part of the event; the event ends (non-inclusively) at 20011013T000000. Now where did I put those asbestos gloves??? 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 006CAF2485256AF7_= Content-Type: text/html; charset="US-ASCII"
Damon wrote on 10/28/2001 08:58:21 PM:
> If I have a VEVENT like this:
>
> DTSTART;VALUE=DATE:20010910
> DTEND;VALUE=DATE:20011310
>
> (i.e. from 9th Oct to 13th Oct)
Umm, I think you meant to say 20011009 and 20011013, respectively... :^)

> Does it:
>
>      a) include the 13th October entirely, up to midnight.
>   or b) stop at 12am on 13th.
We never resolved this thread I dont think when we covered it back in 1999 (yep, that far back).  Look for the thread titled "Recurring Anniversary Instances?" and then perhaps we can come to a final resolution of this issue.  However in the interest of time Ill forge ahead and rehash a bit and put my stick in the ground as to what I think the answer is.

Some relevant RFC citations for those who want a jumpstart, RFC 2445, p 53:

   The "VEVENT" is also the calendar component used to specify an
  anniversary or daily reminder within a calendar. These events have a
  DATE value type for the "DTSTART" property instead of the default
  data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
  MUST be specified as a DATE value also. The anniversary type of
  "VEVENT" can span more than one date (i.e, "DTEND" property value is
  set to a calendar date after the "DTSTART" property value).
   The "DTSTART" property for a "VEVENT" specifies the inclusive start
  of the event. For recurring events, it also specifies the very first
  instance in the recurrence set. The "DTEND" property for a "VEVENT"
  calendar component specifies the non-inclusive end of the event. For
  cases where a "VEVENT" calendar component specifies a "DTSTART"
  property with a DATE data type but no "DTEND" property, the events
  non-inclusive end is the end of the calendar date specified by the
  "DTSTART" property.

Part of the original discussion was about DATE & DATE-TIME equivalents but I think the last line of the 1st paragraph will help us make a decision thats consistant one way or another.  One would logically infer from the text above that since:

        DTSTART;VALUE=DATE:20011009

alone is an "all day" (09-Oct-2001) event and that:

        DTSTART;VALUE=DATE:20011009
        DTEND;VALUE=DATE:20011010

would be a "two day" (09-Oct-2001 & 10-Oct-2001) event.  However some have argued that the 2 day example is wrong and should be:

        DTSTART;VALUE=DATE:20011009
        DTEND;VALUE=DATE:20011011

since the time defaulted should be 00:00:00.  Also, we never did resolve the case of what does/should:

        DTSTART;VALUE=DATE:20011009
        DTEND;VALUE=DATE:20011009

mean.  Technially DTEND is not "after" DTSTART so some think this is 'illegal'.  Others claim that DTEND is after DTSTART since they view the time for DTSTART as being 00:00:00 (Local) and the time of DTEND as being 23:59:59 (Local).  

The citation appears to bear out this argument but it should be noted that A) the text never says the DTEND is "1 day after" the DTSTART, it simply says "is set to a calendar date after the "DTSTART"" and B) while this "ends are relative to the end of the day" argument sounds normal it is by no means consistant with regard to defaulting times.

Unfortunately we have no good iTIP/iMIP examples to use to resolve this but my take on this issues remains that the time always defaults to 00:00:00 (so the DATE value must be selected accordingly).  To directly answer your (corrected) question, I would claim that 13-Oct-2001 is not included as part of the event; the event ends (non-inclusively) at 20011013T000000.

Now where did I put those asbestos gloves???

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 006CAF2485256AF7_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 1 15:57:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00292 for ; Thu, 1 Nov 2001 15:57:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA1KQc011515 for ietf-calendar-bks; Thu, 1 Nov 2001 12:26:38 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1KQa811511 for ; Thu, 1 Nov 2001 12:26:36 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA18013; Thu, 1 Nov 2001 14:25:32 -0600 From: "Shannon J. Clark" To: , "Damon Chaplin" Cc: Subject: RE: DATE values question Date: Thu, 1 Nov 2001 14:25:57 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C162E1.1F659840" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C162E1.1F659840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I will add this to the next version of the Issues lists for iCalendar, iTIP, and iMIP 1 - examples of correct usage of DATE value type in VEVENT objects 2 - examples and explanation of "valid" and "invalid/illegal" DTEND forms for DATA value types 3 - examples of above situations if applicable to iMIP and iTIP 4 - Perhaps a general case of "What is done with inconsistent/invalid/illegal properties?" is also in order? Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Bruce_Kahn@iris.com Sent: Thursday, November 01, 2001 1:51 PM To: Damon Chaplin Cc: ietf-calendar@imc.org Subject: Re: DATE values question Damon wrote on 10/28/2001 08:58:21 PM: > If I have a VEVENT like this: > > DTSTART;VALUE=DATE:20010910 > DTEND;VALUE=DATE:20011310 > > (i.e. from 9th Oct to 13th Oct) Umm, I think you meant to say 20011009 and 20011013, respectively... :^) > Does it: > > a) include the 13th October entirely, up to midnight. > or b) stop at 12am on 13th. We never resolved this thread I dont think when we covered it back in 1999 (yep, that far back). Look for the thread titled "Recurring Anniversary Instances?" and then perhaps we can come to a final resolution of this issue. However in the interest of time Ill forge ahead and rehash a bit and put my stick in the ground as to what I think the answer is. Some relevant RFC citations for those who want a jumpstart, RFC 2445, p 53: The "VEVENT" is also the calendar component used to specify an anniversary or daily reminder within a calendar. These events have a DATE value type for the "DTSTART" property instead of the default data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be specified as a DATE value also. The anniversary type of "VEVENT" can span more than one date (i.e, "DTEND" property value is set to a calendar date after the "DTSTART" property value). The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE data type but no "DTEND" property, the events non-inclusive end is the end of the calendar date specified by the "DTSTART" property. Part of the original discussion was about DATE & DATE-TIME equivalents but I think the last line of the 1st paragraph will help us make a decision thats consistant one way or another. One would logically infer from the text above that since: DTSTART;VALUE=DATE:20011009 alone is an "all day" (09-Oct-2001) event and that: DTSTART;VALUE=DATE:20011009 DTEND;VALUE=DATE:20011010 would be a "two day" (09-Oct-2001 & 10-Oct-2001) event. However some have argued that the 2 day example is wrong and should be: DTSTART;VALUE=DATE:20011009 DTEND;VALUE=DATE:20011011 since the time defaulted should be 00:00:00. Also, we never did resolve the case of what does/should: DTSTART;VALUE=DATE:20011009 DTEND;VALUE=DATE:20011009 mean. Technially DTEND is not "after" DTSTART so some think this is 'illegal'. Others claim that DTEND is after DTSTART since they view the time for DTSTART as being 00:00:00 (Local) and the time of DTEND as being 23:59:59 (Local). The citation appears to bear out this argument but it should be noted that A) the text never says the DTEND is "1 day after" the DTSTART, it simply says "is set to a calendar date after the "DTSTART"" and B) while this "ends are relative to the end of the day" argument sounds normal it is by no means consistant with regard to defaulting times. Unfortunately we have no good iTIP/iMIP examples to use to resolve this but my take on this issues remains that the time always defaults to 00:00:00 (so the DATE value must be selected accordingly). To directly answer your (corrected) question, I would claim that 13-Oct-2001 is not included as part of the event; the event ends (non-inclusively) at 20011013T000000. Now where did I put those asbestos gloves??? 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... ------=_NextPart_000_0006_01C162E1.1F659840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I will = add this to=20 the next version of the Issues lists for iCalendar, iTIP, and=20 iMIP
 
1 - = examples of=20 correct usage of DATE value type in VEVENT = objects
 
2 - = examples and=20 explanation of "valid" and "invalid/illegal" DTEND forms for DATA value=20 types
 
3 - = examples of=20 above situations if applicable to iMIP and iTIP
 
4 - = Perhaps a=20 general case of "What is done with inconsistent/invalid/illegal=20 properties?" is also in order?
 
Shannon 
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of=20 Bruce_Kahn@iris.com
Sent: Thursday, November 01, 2001 = 1:51=20 PM
To: Damon Chaplin
Cc:=20 ietf-calendar@imc.org
Subject: Re: DATE values=20 question


Damon wrote=20 on 10/28/2001 08:58:21 PM:
> If I have a VEVENT like = this:
>=20
> DTSTART;VALUE=3DDATE:20010910
> = DTEND;VALUE=3DDATE:20011310
>=20
> (i.e. from 9th Oct to 13th Oct)

Umm, I think you meant to say 20011009 and 20011013, = respectively...=20 :^)

> Does = it:
>=20
>      a) include the 13th October entirely, up = to=20 midnight.
>   or b) stop at 12am on = 13th.

We never resolved this thread I dont think = when we=20 covered it back in 1999 (yep, that far back).  Look for the = thread titled=20 "Recurring Anniversary Instances?" and then perhaps we can come to a = final=20 resolution of this issue.  However in the interest of time Ill = forge=20 ahead and rehash a bit and put my stick in the ground as to what I = think the=20 answer is.

Some = relevant RFC=20 citations for those who want a jumpstart, RFC 2445, p 53: =

   The "VEVENT" is also the calendar component = used to=20 specify an
  anniversary or daily reminder within a calendar. = These=20 events have a
  DATE value type for the "DTSTART" property = instead of=20 the default
  data type of DATE-TIME. If such a "VEVENT" has a = "DTEND"=20 property, it
  MUST be specified as a DATE value also. The = anniversary=20 type of
  "VEVENT" can span more than one date (i.e, "DTEND" = property=20 value is
  set to a calendar date after the "DTSTART" property = value).

   The = "DTSTART"=20 property for a "VEVENT" specifies the inclusive start
  of the = event.=20 For recurring events, it also specifies the very first
  = instance in=20 the recurrence set. The "DTEND" property for a "VEVENT"
  = calendar=20 component specifies the non-inclusive end of the event. For
  = cases=20 where a "VEVENT" calendar component specifies a "DTSTART"
  = property=20 with a DATE data type but no "DTEND" property, the events
 =20 non-inclusive end is the end of the calendar date specified by = the
 =20 "DTSTART" property.

Part of=20 the original discussion was about DATE & DATE-TIME equivalents but = I think=20 the last line of the 1st paragraph will help us make a decision thats=20 consistant one way or another.  One would logically infer from = the text=20 above that since:

   =20     DTSTART;VALUE=3DDATE:20011009

alone is an "all day" (09-Oct-2001) event and that:=20

       =20 DTSTART;VALUE=3DDATE:20011009
 =20       DTEND;VALUE=3DDATE:20011010

would be a "two day" (09-Oct-2001 & = 10-Oct-2001)=20 event.  However some have argued that the 2 day example is wrong = and=20 should be:

  =    =20   DTSTART;VALUE=3DDATE:20011009
        = DTEND;VALUE=3DDATE:20011011=20

since the time defaulted = should be=20 00:00:00.  Also, we never did resolve the case of what=20 does/should:

  =    =20   DTSTART;VALUE=3DDATE:20011009
        = DTEND;VALUE=3DDATE:20011009=20

mean.  Technially DTEND = is not=20 "after" DTSTART so some think this is 'illegal'.  Others claim = that DTEND=20 is after DTSTART since they view the time for DTSTART as being = 00:00:00=20 (Local) and the time of DTEND as being 23:59:59 (Local).   =

The citation appears to bear = out this=20 argument but it should be noted that A) the text never says the DTEND = is "1=20 day after" the DTSTART, it simply says "is set to a calendar date = after=20 the "DTSTART"" and B) while this "ends are relative to the end of the = day"=20 argument sounds normal it is by no means consistant with regard to = defaulting=20 times.

Unfortunately = we have no=20 good iTIP/iMIP examples to use to resolve this but my take on = this=20 issues remains that the time always defaults to 00:00:00 (so = the DATE=20 value must be selected accordingly).  To directly answer your = (corrected)=20 question, I would claim that 13-Oct-2001 is not included as = part of the=20 event; the event ends (non-inclusively) at 20011013T000000.=20

Now where did I put those = asbestos=20 gloves???

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=20 Kahn                   =  =20            INet: = Bruce_Kahn@iris.com
Iris=20 Associates                 =  =20        Phone: 978.392.5335
Westford, MA, USA = 01886=20                   =  FAX: and=20 nothing but the FAX...
Standard disclaimers apply, even where = prohibited by=20 law...
------=_NextPart_000_0006_01C162E1.1F659840-- From owner-ietf-calendar@mail.imc.org Thu Nov 1 16:10:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00563 for ; Thu, 1 Nov 2001 16:10:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA1KnHF12073 for ietf-calendar-bks; Thu, 1 Nov 2001 12:49:17 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1KnG812069 for ; Thu, 1 Nov 2001 12:49:16 -0800 (PST) From: Bruce_Kahn@iris.com To: jstracke@incentivesystems.com Cc: ietf-calendar@imc.org Subject: Re: CAP: why do we need GENERATEUID? MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: Date: Thu, 1 Nov 2001 15:49:13 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_10252001|October 25, 2001) at 11/01/2001 03:45:16 PM, Serialize complete at 11/01/2001 03:45:16 PM Content-Type: multipart/alternative; boundary="=_alternative 00720BB685256AF7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00720BB685256AF7_= Content-Type: text/plain; charset="US-ASCII" Appologies for the tardiness. Real Work (TM) and email problems w/IMC have been conspiring against me recently. John Stracke wrote: >>Using GENERATEUID doeesn't mean an additional round-trip for each >>create, a client can request many UIDs at once and store them >>locally for that session, or forever. >> >Oh, that's a good point. Well then you will never be able to use it with signed or encrypted data in the store unless you gave the store the your private keys so it can decrypt/reencrypt or resign the data as you. Some may not mind that the data could become "Signed by Some CS Server/Acme" instead of "Signed by Joe User/Acme" but some of do find it to be an issue. I certainly will never give my server my private keys so that it can do this stuff. When I get signed meeting requests they are signed by the requestor, not by their server. Im used to seeing this in both email and C&S and Im not the only one. I can see the bandwidth concern for some current low bandwidth clients but I strongly resist the idea of designing a protocol for a very narrow pipe that exists now when A) the pipes are constantly growing and B) the protocol will take a while to get fully fleshed out and implemented. I fully expect that bandwidth will have increased a good dea by the time CAP is being tested at CalConnects; at least enough so that requesting a GUID and getting it back is an inexpensive option. 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 00720BB685256AF7_= Content-Type: text/html; charset="US-ASCII"
Appologies for the tardiness.  Real Work (TM) and email problems w/IMC have been conspiring against me recently.

John Stracke wrote:
>>Using GENERATEUID doeesn't mean an additional round-trip for each
>>create, a client can request many UIDs at once and store them
>>locally for that session, or forever.
>>
>Oh, that's a good point.
Well then you will never be able to use it with signed or encrypted data in the store unless you gave the store the your private keys so it can decrypt/reencrypt or resign the data as you.  Some may not mind that the data could become "Signed by Some CS Server/Acme" instead of "Signed by Joe User/Acme" but some of do find it to be an issue.  I certainly will never give my server my private keys so that it can do this stuff.  

When I get signed meeting requests they are signed by the requestor, not by their server.  Im used to seeing this in both email and C&S and Im not the only one.

I can see the bandwidth concern for some current low bandwidth clients but I strongly resist the idea of designing a protocol for a very narrow pipe that exists now when A) the pipes are constantly growing and B) the protocol will take a while to get fully fleshed out and implemented.  I fully expect that bandwidth will have increased a good dea by the time CAP is being tested at CalConnects; at least enough so that requesting a GUID and getting it back is an inexpensive option.

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 00720BB685256AF7_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 1 16:56:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01558 for ; Thu, 1 Nov 2001 16:56:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA1LTnH13047 for ietf-calendar-bks; Thu, 1 Nov 2001 13:29:49 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1LTm813042 for ; Thu, 1 Nov 2001 13:29:48 -0800 (PST) MIME-Version: 1.0 From: Bruce_Kahn@iris.com To: jstracke@incentivesystems.com Cc: CalSched IETF Subject: Re: 2445:4.1 (x-name) is misleading. X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: Date: Thu, 1 Nov 2001 16:34:20 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_10252001|October 25, 2001) at 11/01/2001 04:25:47 PM, Serialize complete at 11/01/2001 04:25:47 PM Content-Type: multipart/alternative; boundary="=_alternative 0075C0AD85256AF7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075C0AD85256AF7_= Content-Type: text/plain; charset="US-ASCII" John wrote: >>2445:4.1 (x-name) is misleading. At least it mislead me. >> >Actually, I think you're right in your reading of it; it's just that, >since 2445 was written, everybody's understanding of X- has drifted. > I, for one, had forgotten that it was forbidden in released software, >and had come to think of it as meaning the same thing it does in >RFC-[2]822 headers: "use at your own risk". The reason that we put 'vendor' ids in there was so that any vendor could send C&S related info tag'd as belonging to themselves and not worry about it accidentally matching the recieving CUAs expectations. That is, if Notes wants to send along some extra info that other Notes client (or those that grok the Notes 'schema' [shudder]) need/want then it can do so w/o fear of someone using, say, Outlook from mistakenly misusing the data for something else entirely (or incorrectly). In effect, its a kind of namespace definition w/in 'eXtension' or 'eXperimental' properties. 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 0075C0AD85256AF7_= Content-Type: text/html; charset="US-ASCII"
John wrote:
>>2445:4.1 (x-name) is misleading.  At least it mislead me.
>>
>Actually, I think you're right in your reading of it; it's just that,
>since 2445 was written, everybody's understanding of X- has drifted.  
> I, for one, had forgotten that it was forbidden in released software,
>and had come to think of it as meaning the same thing it does in
>RFC-[2]822 headers: "use at your own risk".
The reason that we put 'vendor' ids in there was so that any vendor could send C&S related info tag'd as belonging to themselves and not worry about it accidentally matching the recieving CUAs expectations.  That is, if Notes wants to send along some extra info that other Notes client (or those that grok the Notes 'schema' [shudder]) need/want then it can do so w/o fear of someone using, say, Outlook from mistakenly misusing the data for something else entirely (or incorrectly).  In effect, its a kind of namespace definition w/in 'eXtension' or 'eXperimental' properties.

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 0075C0AD85256AF7_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 1 17:15:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01893 for ; Thu, 1 Nov 2001 17:15:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA1Lpkp13604 for ietf-calendar-bks; Thu, 1 Nov 2001 13:51:46 -0800 (PST) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1Lpi813600 for ; Thu, 1 Nov 2001 13:51:45 -0800 (PST) Received: from 192.168.10-104.masq (192.168.10-104.masq [192.168.10.104]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id QAA18067; Thu, 1 Nov 2001 16:51:40 -0500 Subject: Re: DATE values question From: Damon Chaplin To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99 (Preview Release) Date: 01 Nov 2001 16:49:05 -0500 Message-Id: <1004651345.1156.5.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thu, 2001-11-01 at 14:50, Bruce_Kahn@iris.com wrote: > Damon wrote on 10/28/2001 08:58:21 PM: > > If I have a VEVENT like this: > > > > DTSTART;VALUE=DATE:20010910 > > DTEND;VALUE=DATE:20011310 > > > > (i.e. from 9th Oct to 13th Oct) > > Umm, I think you meant to say 20011009 and 20011013, respectively... :^) Oops. Yes. > > Does it: > > > > a) include the 13th October entirely, up to midnight. > > or b) stop at 12am on 13th. > Unfortunately we have no good iTIP/iMIP examples to use to resolve this > but my take on this issues remains that the time always defaults to 00:00:00 (so the DATE value must be selected accordingly). To > directly answer your (corrected) question, I would claim that 13-Oct-2001 > is not included as part of the event; the event ends (non-inclusively) at > 20011013T000000. Yes, that is what we do now. The deciding factor for us was that that is what Outlook does. (which reminds me - I think the group should keep info on interop problems somewhere.) Damon From owner-ietf-calendar@mail.imc.org Thu Nov 1 18:02:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02497 for ; Thu, 1 Nov 2001 18:02:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA1MaWE14715 for ietf-calendar-bks; Thu, 1 Nov 2001 14:36:32 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1MaU814711 for ; Thu, 1 Nov 2001 14:36:30 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA13699; Thu Nov 1 17:33:06 2001 Subject: Re: CAP: why do we need GENERATEUID? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 1 Nov 2001 17:36:53 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/01/2001 05:36:54 PM, Serialize complete at 11/01/2001 05:36:54 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Well then you will never be able to use it with signed or encrypted data in the store unless you gave the store the > your private keys so it can decrypt/reencrypt or resign the data as you. I believe we've been over this before (for example, in San Diego): you are the only one who believes that the server will store the iCalendar objects as opaque MIME blobs, which could be signed by the sender. The rest of us expect the data to be stored in a relational database. The disconnect reflects our respective implementation experience: Notes is a MIME store, for flexibility; most other apps are built on databases, for performance. In any case, signing seems to have nothing to do with GENERATEUID; as far as I can see, where the UIDs come from does not impact signing the iCalendar objects. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Fri Nov 2 07:31:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00654 for ; Fri, 2 Nov 2001 07:31:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA2Bxot04183 for ietf-calendar-bks; Fri, 2 Nov 2001 03:59:50 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2Bxm804178 for ; Fri, 2 Nov 2001 03:59:48 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29527; Fri, 2 Nov 2001 06:59:45 -0500 (EST) Message-Id: <200111021159.GAA29527@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-inetcal-guide-02.txt Date: Fri, 02 Nov 2001 06:59:45 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Guide to Internet Calendaring Author(s) : B. Mahoney, G. Babics, A. Taler Filename : draft-ietf-calsch-inetcal-guide-02.txt Pages : 19 Date : 01-Nov-01 This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially help in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-inetcal-guide-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-inetcal-guide-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-inetcal-guide-02.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: <20011101123930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-inetcal-guide-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-inetcal-guide-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011101123930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Fri Nov 2 11:56:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11440 for ; Fri, 2 Nov 2001 11:56:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2GV4s23533 for ietf-calendar-bks; Fri, 2 Nov 2001 08:31:04 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2GV2823525 for ; Fri, 2 Nov 2001 08:31:02 -0800 (PST) To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: CAP: why do we need GENERATEUID? MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Fri, 2 Nov 2001 11:38:07 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/02/2001 11:31:05 AM, Serialize complete at 11/02/2001 11:31:05 AM Content-Type: multipart/alternative; boundary="=_alternative 0059D7AD85256AF8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059D7AD85256AF8_= Content-Type: text/plain; charset="US-ASCII" John replied on 11/01/2001 05:36:53 PM: > I believe we've been over this before (for example, in San Diego): you are > the only one who believes that the server will store the iCalendar objects > as opaque MIME blobs, which could be signed by the sender. For the benefit of those that were not in the halls then (and for some who seem to misrecall details) I think I need to restate somethings for clarity sake: CAP is NOT defining the internal architecture of the Calendar Store. It defines how a CUA accesses the CS and saves/retrieves/modifys data in the CS. The data format is MIME (from the CUAs POV, NOT necessiarily the CS's POV!!). The CAP messages/commands/data/responses are in MIME streams. As such, you need to consider MIME streams that are encrypted/signed. (Unless you intend to prohibit signed/encrypted ATTACHments or richer DESCRIPTIONs, etc). Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out the 'mail file'/'message store', we are doing the same in CAP. > The rest of us > expect the data to be stored in a relational database. The disconnect > reflects our respective implementation experience: Notes is a MIME store, > for flexibility; most other apps are built on databases, for performance. Another correction: Notes is not a MIME store. Notes is its own store that can also contain MIME data (preserving fidelity even). The Notes dB architecture was designed and built back in 1984, predating the MIME RFCs by about 6 years. Back to the discussion: You can pick your own back end store but not all implementors (Lotus / IBM, Open Source projects, etc) will be using someone elses backend store for the data for assorted reasons (ie: $$$, flexibility, ROI, etc). Just because the query language is SQL-like does not mean that the CS MUST be built on SQL... (or are you claiming that indirectly?) Much like IMAP/POP3 can be implemented w/ANY backend (flatfile, Notes dB, Oracle, DB2, SQL, proprietary, etc), ALL implementations need to deal with data integrity (esp. in IMAP). Perhaps Im just off base here but Ive yet to hear _why_?? It doesnt matter what backend choice you pick (Ill keep saying it untill I can grok otherwise). What matters is that the CUA can reasonably expect to get back the equivalent data to what it put in. If not, it will be impossible to have 'local CS' inside the CUA and keep it in sync w/the server CS data; the sync engine would just be thrashing. > In any case, signing seems to have nothing to do with GENERATEUID; as far > as I can see, where the UIDs come from does not impact signing the > iCalendar objects. Ok, Ill try to be as concise as I can w/o caffine yet. If the CS automagically updates the entry that the CUA just put into the store (ie: to put a UID on the entry for the CUA) then it will blow any signatures on the entry. Also, if the data is encrypted then the CS may not be able to decrypt and modify the data (signed or unsigned!). I firmly do expect users to encrypt their data and anyone who thinks otherwise is being an Ostrich about it. The way that mail gets around this is that the only modifyable headers are the outer most ones and they are never encrypted/signed. At one point (San Diego or Washington DC hall talk??) I think I finally convinced some folks that we needed to split out some modifyable info from the base iCalendar data and this is another good justification for that. (Steve, you recall that talk?? You were going to revise CAP to reflect that last I read it...) Taking a "Leave it for later" attitude towards signed/encrypted data is not an acceptable answer in this technical era. Otherwise at CalConnect 7 we will find 10 implementors doing 10 different things w/the data that prevent a heterogenous mixing of CUAs & CSs. Then we will spend even more time trying to retro a fix on that wont be painless to those implementors that far along the development path. Sigh, I dont like sounding like a broken record but I strongly think that some fundamental issues need to be addressed before the rest of the CAP house is built. This GENERATEUID posting I found in the archives just triggered that impulse again. Bruce Sidenote: I finally got my personal archive in sync w/the official archive and have copied in the missing postings from this past summer (about 16-17 in all). The updates should be available now for those that use it 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 0059D7AD85256AF8_= Content-Type: text/html; charset="US-ASCII"
John replied on 11/01/2001 05:36:53 PM:
> I believe we've been over this before (for example, in San Diego): you are
> the only one who believes that the server will store the iCalendar objects
> as opaque MIME blobs, which could be signed by the sender.

For the benefit of those that were not in the halls then (and for some who seem to misrecall details) I think I need to restate somethings for clarity sake:

CAP is NOT defining the internal architecture of the Calendar Store.  It defines how a CUA accesses the CS and saves/retrieves/modifys data in the CS.  
The data format is MIME (from the CUAs POV, NOT necessiarily the CS's POV!!).  
The CAP messages/commands/data/responses are in MIME streams.  As such, you need to consider MIME streams that are encrypted/signed.  (Unless you intend to prohibit signed/encrypted ATTACHments or richer DESCRIPTIONs, etc).

Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out the 'mail file'/'message store', we are doing the same in CAP.

>                                                            The rest of us
> expect the data to be stored in a relational database.  The disconnect
> reflects our respective implementation experience: Notes is a MIME store,
> for flexibility; most other apps are built on databases, for performance.
Another correction: Notes is not a MIME store.  Notes is its own store that can also contain MIME data (preserving fidelity even).  The Notes dB architecture was designed and built back in 1984, predating the MIME RFCs by about 6 years.  

Back to the discussion: You can pick your own back end store but not all implementors (Lotus / IBM, Open Source projects, etc) will be using someone elses backend store for the data for assorted reasons (ie: $$$, flexibility, ROI, etc).  Just because the query language is SQL-like does not mean that the CS MUST be built on SQL... (or are you claiming that indirectly?)

Much like IMAP/POP3 can be implemented w/ANY backend (flatfile, Notes dB, Oracle, DB2, SQL, proprietary, etc), ALL implementations need to deal with data integrity (esp. in IMAP).  Perhaps Im just off base here but Ive yet to hear _why_??  It doesnt matter what backend choice you pick (Ill keep saying it untill I can grok otherwise).  What matters is that the CUA can reasonably expect to get back the equivalent data to what it put in.  If not, it will be impossible to have 'local CS' inside the CUA and keep it in sync w/the server CS data; the sync engine would just be thrashing.

> In any case, signing seems to have nothing to do with GENERATEUID; as far
> as I can see, where the UIDs come from does not impact signing the
> iCalendar objects.
Ok, Ill try to be as concise as I can w/o caffine yet.  If the CS automagically updates the entry that the CUA just put into the store (ie: to put a UID on the entry for the CUA) then it will blow any signatures on the entry.  Also, if the data is encrypted then the CS may not be able to decrypt and modify the data (signed or unsigned!).  

I firmly do expect users to encrypt their data and anyone who thinks otherwise is being an Ostrich about it.  The way that mail gets around this is that the only modifyable headers are the outer most ones and they are never encrypted/signed.  At one point (San Diego or Washington DC hall talk??) I think I finally convinced some folks that we needed to split out some modifyable info from the base iCalendar data and this is another good justification for that.  (Steve, you recall that talk??  You were going to revise CAP to reflect that last I read it...)

Taking a "Leave it for later" attitude towards signed/encrypted data is not an acceptable answer in this technical era.  Otherwise at CalConnect 7 we will find 10 implementors doing 10 different things w/the data that prevent a heterogenous mixing of CUAs & CSs.  Then we will spend even more time trying to retro a fix on that wont be painless to those implementors that far along the development path.

Sigh, I dont like sounding like a broken record but I strongly think that some fundamental issues need to be addressed before the rest of the CAP house is built.  This GENERATEUID posting I found in the archives just triggered that impulse again.  

Bruce
Sidenote: I finally got my personal archive in sync w/the official archive and have copied in the missing postings from this past summer (about 16-17 in all).  The updates should be available now for those that use it 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 0059D7AD85256AF8_=-- From owner-ietf-calendar@mail.imc.org Fri Nov 2 12:35:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12607 for ; Fri, 2 Nov 2001 12:35:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2H5j802813 for ietf-calendar-bks; Fri, 2 Nov 2001 09:05:45 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2H5h802801 for ; Fri, 2 Nov 2001 09:05:43 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA03351 for ; Fri, 2 Nov 2001 12:05:39 -0500 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id fA2H5ZH11742 for ; Fri, 2 Nov 2001 12:05:35 -0500 (EST) Message-ID: <043701c163c0$7b64aa70$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: Subject: Re: CAP: encrypted MIME Date: Fri, 2 Nov 2001 12:04:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: "John Stracke" Cc: Sent: 02 November, 2001 11:38 Subject: Re: CAP: why do we need GENERATEUID? > The data format is MIME (from the CUAs POV, NOT necessiarily the CS's POV!!). > The CAP messages/commands/data/responses are in MIME streams. As such, > you need to consider MIME streams that are encrypted/signed. (Unless you > intend to prohibit signed/encrypted ATTACHments or richer DESCRIPTIONs, > etc). If a CS must accept a signed/encrypted iCalendar that it can't read, how can it reliably perform any CAP operations at all? "I'd love to retrieve that event for you, but you've encrypted all your data and I can't find it. Sorry." > Much like IMAP/POP3 can be implemented w/ANY backend (flatfile, Notes dB, > Oracle, DB2, SQL, proprietary, etc), ALL implementations need to deal with > data integrity (esp. in IMAP). Perhaps Im just off base here but Ive yet > to hear _why_?? It doesnt matter what backend choice you pick (Ill keep saying it > untill I can grok otherwise). What matters is that the CUA can reasonably > expect to get back the equivalent data to what it put in. If not, it will > be impossible to have 'local CS' inside the CUA and keep it in sync w/the > server CS data; the sync engine would just be thrashing. Mail services don't care about the content of messages; Calendaring & Scheduling services most definitely DO. How, otherwise, can a server provide such features to users like searching a user's calendar for free time, text-based searches, or even informing a user that they've been invited by someone? [the following quoted paragraphs have been re-ordered, for clarity of argument] > I firmly do expect users to encrypt their data and anyone who thinks otherwise is > being an Ostrich about it. The way that mail gets around this is that the > only modifyable headers are the outer most ones and they are never > encrypted/signed. At one point (San Diego or Washington DC hall talk??) I > think I finally convinced some folks that we needed to split out some > modifyable info from the base iCalendar data and this is another good > justification for that. (Steve, you recall that talk?? You were going to > revise CAP to reflect that last I read it...) So you are saying you would want to move some data out of the "content" portion into some kind of "header" that isn't encrypted? What kinds of data? Where does one draw the line between meta-data and actual content that should be protected? > Ok, Ill try to be as concise as I can w/o caffine yet. If the CS > automagically updates the entry that the CUA just put into the store (ie: > to put a UID on the entry for the CUA) then it will blow any signatures on > the entry. Also, if the data is encrypted then the CS may not be able to > decrypt and modify the data (signed or unsigned!). I don't think the UID is particularly important or valuable; why would you want to encrypt the UID as part of the content of your message (assuming some data was moved out into some kind of header)? Graham From owner-ietf-calendar@mail.imc.org Fri Nov 2 13:31:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14392 for ; Fri, 2 Nov 2001 13:31:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2I2cJ06014 for ietf-calendar-bks; Fri, 2 Nov 2001 10:02:38 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2I2a806010 for ; Fri, 2 Nov 2001 10:02:36 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id MAA13953; Fri Nov 2 12:58:48 2001 Subject: Re: CAP: why do we need GENERATEUID? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 2 Nov 2001 13:02:34 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/02/2001 01:02:40 PM, Serialize complete at 11/02/2001 01:02:40 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out the 'mail file'/'message store', we are doing the same in CAP. The difference is that it's feasible for a server to treat email messages as opaque blobs with a bit of machine-readable data. An iCalendar object consists almost entirely of machine-readable data; the server needs to understand the semantics of that data, and store it in a way it can search quickly. > You can pick your own back end store but not all implementors (Lotus / IBM, Open Source projects, etc) will be using someone elses backend store > for the data for assorted reasons (ie: $$$, flexibility, ROI, etc). Sure. It's all tradeoffs. Personally, I think the database approach is best, because it's cheaper (use postgresql if you think you can't afford a commercial DB); you lose some flexibility, but you can work around that. I don't think there's anyway to work around the performance problems of an opaque-blob store, though. eCal built a server, based on an Oracle backend, that could handle one million users at less than $1 apiece in hardware costs; I don't believe a non-relational approach can come close to that. (Granted, eCal subsequently went bankrupt; but the *technology* was sound. :-) > > In any case, signing seems to have nothing to do with GENERATEUID; as far > > as I can see, where the UIDs come from does not impact signing the > > iCalendar objects. > > Ok, Ill try to be as concise as I can w/o caffine yet. If the CS automagically updates the entry that the CUA just put into the store (ie: to put a UID on the entry for > the CUA) then it will blow any signatures on the entry. True--which argues for the GENERATEUID approach, which I had conceded in the message you were replying to. > Also, if the data is encrypted then the CS ...will not be able to search it. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Fri Nov 2 13:41:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14663 for ; Fri, 2 Nov 2001 13:41:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA2I43O06045 for ietf-calendar-bks; Fri, 2 Nov 2001 10:04:03 -0800 (PST) Received: from eeyore.jsoft.com (mail.jsoft.com [24.240.234.245] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2I42806041 for ; Fri, 2 Nov 2001 10:04:02 -0800 (PST) Received: from jsoft.com (IDENT:ggf@eeyore.jsoft.com [192.168.1.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id fA2I3FC10171; Fri, 2 Nov 2001 12:03:16 -0600 Message-ID: <3BE2DFE3.1070106@jsoft.com> Date: Fri, 02 Nov 2001 12:03:15 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: "NITSCH,FRANK (HP-Germany,ex1)" CC: "'John Stracke'" , ietf-calendar@imc.org Subject: Re: What should the xCal tag names case be? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit argh--- so many interesting projects - 24 hours in a day... I also 'vote' for lower case. It looks better. I have done a lot of hand coding of xcal (my version) and it is a real handy thing to have. However, I like the idea of all lower case because it is 'easy' to do in a program. If we have mixed case, we have to have a bit of code for each tag's case. My original post was trying (and failing due to my inability to 'type' English) to say that an original in iCalendar can have whatever case the XML will have for example lower-case. We will not be able to recreate the original iCalendar from xcal without saving info about the original's case. I see NO note the upper case reason to save info on the case of the original. >For whose "ease of use" do we make this decision? If it's easy to read, it's a bit easier to work with when doing XSLT stylesheets. A BIG did it again... plus. My wife uses my version of xcal to enter events. She enters them by hand. We can generate iCalendar and xcal once we have something in xcal. She finds it easy to work with xcal. I think there will be a small but measureable number of people editing xcal by hand. Gary NITSCH,FRANK (HP-Germany,ex1) wrote: >>>I believe >>>research has shown that mixed case is easier to read. >>> > > Well, reading a book is of course easier than reading > C code... ;-) > > >>That certainly accords with my own experience. People who >>SHOUT, or who >>type everything in lower case, are harder to read. Mixed >>case gives your >>eyes clues as they parse along. >> > > You should take into account that coding XML by hand will > be much less error-prone if everything is either lower or > upper case. However I agree that upper case is not really > a desired option... It looks just annoying and using Shift > or Caps Lock all the time is also a hassle for those who type > xCal by hand. > > If you now think that coding xCal by hand is not an important > use-case I'd like to ask you: who do you think should read > raw XML? What's the most important issue the decision > should be based on? Is it a developer who want's to verify > the output of his GUI by inspecting the XML source or a > developer who constructs a test xCal event in XML in his > ASCII editor? For whose "ease of use" do we make this decision? > > BTW: I'd vote for all lower case! ;-) > > Regards > > Frank > From owner-ietf-calendar@mail.imc.org Fri Nov 2 13:47:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14834 for ; Fri, 2 Nov 2001 13:47:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2IK7n06598 for ietf-calendar-bks; Fri, 2 Nov 2001 10:20:07 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2IK5806592 for ; Fri, 2 Nov 2001 10:20:05 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id NAA16117; Fri Nov 2 13:16:48 2001 Subject: Re: What should the xCal tag names case be? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 2 Nov 2001 13:20:34 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/02/2001 01:20:40 PM, Serialize complete at 11/02/2001 01:20:40 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If we have mixed case, we have to have > a bit of code for each tag's case. True--it would mean the script to convert text/calendar to application/icalendar+xml would need to know properties and parameters, and would have to be updated for extensions, just as if the names didn't match at all. So, yes, I think we should go for all lowercase (or all uppercase, if anybody really wants to argue that), and identical names. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Fri Nov 2 16:27:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18883 for ; Fri, 2 Nov 2001 16:27:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA2KtS113937 for ietf-calendar-bks; Fri, 2 Nov 2001 12:55:28 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2KtR813933 for ; Fri, 2 Nov 2001 12:55:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA20054; Fri, 2 Nov 2001 12:55:17 -0800 (PST) Message-ID: <3BE302DF.EC23BD95@Royer.com> Date: Fri, 02 Nov 2001 13:32:31 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DATE values question References: Content-Type: multipart/mixed; boundary="------------7AFED50264FF981FFDB84D67" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7AFED50264FF981FFDB84D67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > Does it: > > > > a) include the 13th October entirely, up to midnight. > > or b) stop at 12am on 13th. > > We never resolved this thread I dont think when we covered it back in 1999 > (yep, that far back). Look for the thread titled "Recurring Anniversary > Instances?" and then perhaps we can come to a final resolution of this > issue. However in the interest of time Ill forge ahead and rehash a bit and > put my stick in the ground as to what I think the answer is. > ... I agree, the DTEND is in effect an 'UNTIL' in that way. It starts at DTSTART, and goes UNTIL the end DTEND, and stops when DTEND matches the current DATE (As no time was specified). -Doug --------------7AFED50264FF981FFDB84D67 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------7AFED50264FF981FFDB84D67-- From owner-ietf-calendar@mail.imc.org Fri Nov 2 16:29:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19013 for ; Fri, 2 Nov 2001 16:29:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA2LC7514266 for ietf-calendar-bks; Fri, 2 Nov 2001 13:12:07 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2LC6814262 for ; Fri, 2 Nov 2001 13:12:06 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA20290; Fri, 2 Nov 2001 13:12:06 -0800 (PST) Message-ID: <3BE306CC.F5EFC7CA@Royer.com> Date: Fri, 02 Nov 2001 13:49:16 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: why do we need GENERATEUID? 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 1) We need GENERATEUID so the servers can generate unique id's. Think of the multitude of email programs that started with message id '1' for email message-id which was supposed to be unique, for each client? What a mess that is/was. NNTP has the same mess - each client starts with '1'. Server implementations have a need to make sure the UID's are unique - as they will have to deal with the problem if it is not done. Clients that act as a single CU do not care. Servers that have to deal with multiple CU's that could have everyone start with UID '1' will care a lot! 2) The ORGANIZERS CS stores the components, a logical place to generate the components UID. > Well then you will never be able to use it with signed or encrypted data in > the store unless you gave the store the your private keys so it can > decrypt/reencrypt or resign the data as you. Why? I give your CUA 'pwejfdsj;fjdslkfjsdlkfjdlfdslfdljds' as a unique ID. Why can't you encrypt it? 3) Encrypted data 'in the store' is out of scope for CAP. We have never said that the CS must be able to CRYPT/DECRYPT personal MIME messages. 'Your' CUA under your control can ask you for your private key. Then using TLS, talk in a secure way to your CS. At no point in time have we proposed that the CS store encrypted VCALENDAR components. If you wish to do that, great. But it is out of scope for CAP. -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 2 17:22:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20294 for ; Fri, 2 Nov 2001 17:22:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2M6FX15737 for ietf-calendar-bks; Fri, 2 Nov 2001 14:06:15 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2M6D815733 for ; Fri, 2 Nov 2001 14:06:13 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21111 for ; Fri, 2 Nov 2001 14:06:13 -0800 (PST) Message-ID: <3BE31370.7721A190@Royer.com> Date: Fri, 02 Nov 2001 14:43:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: why do we need GENERATEUID? 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 on 11/01/2001 05:36:53 PM: > > I believe we've been over this before (for example, in San Diego): you are > > > the only one who believes that the server will store the iCalendar > > objects as opaque MIME blobs, which could be signed by the sender. > > For the benefit of those that were not in the halls then (and for some who > seem to misrecall details) I think I need to restate somethings for clarity > sake: > > CAP is NOT defining the internal architecture of the Calendar Store. It > defines how a CUA accesses the CS and saves/retrieves/modifys data in the > CS. Which does NOT include MIME blobs and the storage of encrypted blobs. I agree with John - this is out of scope for CAP and it has been for years. You brought this up in San Diego, LA, Oslo, Chicago, Dallas, and perhaps in Montreal. If not in person - by email. I also agree with john that the rest of the WS does not agree that CAP should address that method of storage. How would your CS implementation meet the minimum requirements for VQUERY if the data is only stored encrypted? I submit that only the implementation that you have proposed would have this limitation. If you want to do this, if you can figure out how to read the inside of an encrypted blob by a CS in order to meet the minimum VQUERY CAP requirements - great - but it is not a CAP requirement. > The data format is MIME (from the CUAs POV, NOT necessiarily the CS's > POV!!). > The CAP messages/commands/data/responses are in MIME streams. > As such, you need to consider MIME streams that are encrypted/signed. >(Unless you intend to prohibit signed/encrypted ATTACHments or richer > DESCRIPTIONs, etc). Your CUA needs to worry about these, not the CS. Your CUA would get an encrypted MIME blob, ask you for your password, and store the iCalendar object via CAP into your CS. You CS does not want and should never have your private key. Thus it MUST NOT store encrypted blobs or it can not meet minimum the VQUERY requirements. From my point of view you are arguing both sides of the argument. On one hand you want encrypted MIME blobs in the CS, on the other you will never place your private key on the CS (you and I agree on this point - never give out your private key). A CS could NEVER function as anything except a file system if it had to handle MIME blobs - if that is all you want - use secure NFS. > Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out the > 'mail file'/'message store', we are doing the same in CAP. Not true - not the same issue. At no point 'MUST' a IMAP or POP server crack open an encrypted email to determine if you are busy. > Back to the discussion: You can pick your own back end store but not all > implementors (Lotus / IBM, Open Source projects, etc) will be using someone > elses backend store for the data for assorted reasons (ie: $$$, flexibility, > ROI, etc). Just because the query language is SQL-like does not mean that > the CS MUST be built on SQL... (or are you claiming that indirectly?) That is true. However in order to meet SQL-MIN, the CS MUST BE able to crack open the iCalendar object on the store. That was agreed to by all parties (you included at the time). > Much like IMAP/POP3 can be implemented w/ANY backend (flatfile, Notes dB, > Oracle, DB2, SQL, proprietary, etc), ALL implementations need to deal with > data integrity (esp. in IMAP). Perhaps Im just off base here but Ive yet > to hear _why_?? It doesnt matter what backend choice you pick (Ill keep > saying it untill I can grok otherwise). What matters is that the CUA can > reasonably expect to get back the equivalent data to what it put in. If > not, it will be impossible to have 'local CS' inside the CUA and keep it in > sync w/the server CS data; the sync engine would just be thrashing. We agree, and as storing of encrypted data on the CS is not a CAP requirement, you can't expect to operate with other CS's if your CUA expects to be able to do that. > > In any case, signing seems to have nothing to do with GENERATEUID; as far > > as I can see, where the UIDs come from does not impact signing the > > iCalendar objects. > > Ok, Ill try to be as concise as I can w/o caffine yet. If the CS > automagically updates the entry that the CUA just put into the store >(ie: to > put a UID on the entry for the CUA) then it will blow any signatures on the > entry. Also, if the data is encrypted then the CS may not be able to > decrypt and modify the data (signed or unsigned!). First, WRONG - the the UID must be in place PRIOR to the CUA depositing the entry into the CAP server, otherwise it is an invalid object. Second, if that entry represents a VEVENT, and the UPDATE is an RSVP reply, and you want your CS to interoperate with anyone else's, CUA then the CS MUST BE able to allow ANY conforming CUA TO modify the ATTENDEE entry in the CS to show their status- so much for your stored sig. Which is why the rest of us are saying that's not CAP. > I firmly do expect users to encrypt their data and anyone who thinks > otherwise is being an Ostrich about it. Yes - a CUA issue, not a CUA<->CS (CAP) issue. Feel free to decrypt, verify, validate, authenticate, authorize any MIME object blob. But as soon as you want to be able to issue CAP commands on that blob, you have to: (1) store it de-crypted. or (2) store you private key on the CS. (never!). So, copy, drag-n-drop, whatever the MIME blob to your CUA, it can crack it open - then store the results in the CS. > The way that mail gets around this > is that the only modifyable headers are the outer most ones and they are > never encrypted/signed. Yes, but in vCalendar - almost everything is up for change, that's what the (at least) year long debate that resulted in iTIP REQUEST/REPLY was all about. --> vCalendar objects change. Are you proposing that we eliminate all changes to an entry once the ORGANIZER submits the initial request? EVERYTHING could be changed, including the ORGANIZER, SUBJECT, DTSTART, DTEND, ... . > At one point (San Diego or Washington DC hall > talk??) I think I finally convinced some folks that we needed to split out > some modifyable info from the base iCalendar data and this is another good > justification for that. (Steve, you recall that talk?? You were going to > revise CAP to reflect that last I read it...) In DC we agreed that the transport method that we chose at that time needed to be updated as it disallowed encrypted MIME objects completely. We did not agree that CAP must allow for the storage of encrypted objects. I recall this was a meeting in the hall with You, me, and Paul, with Pat and Frank coming and going. It was never agreed on the WG list. We mentioned in session that we had to re-do the transport and separate the transport from the objects. > Taking a "Leave it for later" attitude towards signed/encrypted data is not > an acceptable answer in this technical era. Otherwise at CalConnect 7 we > will find 10 implementors doing 10 different things w/the data that prevent > a heterogenous mixing of CUAs & CSs. Then we will spend even more time > trying to retro a fix on that wont be painless to those implementors that > far along the development path. iMIP supports encrypted MIME objects. CAP uses a secure TLS connection to transport the information. It is a CUA implementation detail, not a CAP issue. You can have a functional CS unless the CS can crack open the object. -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 2 17:23:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20328 for ; Fri, 2 Nov 2001 17:23:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA2M5Ni15706 for ietf-calendar-bks; Fri, 2 Nov 2001 14:05:23 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2M5M815701 for ; Fri, 2 Nov 2001 14:05:22 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA09650; Fri, 2 Nov 2001 17:05:19 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA2M5IH03012; Fri, 2 Nov 2001 17:05:18 -0500 (EST) Message-ID: <3BE3189B.6DA2B767@steltor.com> Date: Fri, 02 Nov 2001 17:05:15 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "Shannon J. Clark" CC: ietf-calendar@imc.org Subject: Re: CAP: Filing of components References: 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 "Shannon J. Clark" wrote: > > In looking at this a few questions come to my mind as a vendor considering > implementing CAP. > > 1 - does this add another layer of security complexity that I must negotiate > and handle? > > 2 - What defines a valid "DESTINATION" - at the very least this would need > to be clearly spelled out DESTINATION would have the same value type as TARGET. > 3 - Within a specific CS I am comfortable that UID's assigned will be > unique, that I can validate users, that I can manage access rights to each > calendar etc. - when it comes to a separate CS - I become somewhat less > confident - what needs to be negotiated between the two CS to handle a MOVE > command as proposed cleanly? > > - CS & CSofDestination must agree on access rights (to the old Calendar and > the Destination Calendar) > > - CS & CSofDestination must agree on uniqueness of component being moved - > i.e. there must be some means to handle a message from CSofDestination > "already here" > > - Should this be a "Transaction" - i.e. what happens on error conditions - > when is the "moved" object REMOVED from the original Calendar? Within one CS > I as a vendor can take steps to ensure transactional integrity within > actions on that server - but as soon as I am negotiating a transaction with > another server it is a more complex action. > > - Can a MOVE command happen via another means? i.e. can (should?) it be > possible via email (iMIP) - my initial reaction would be NO - but it does > raise questions The first version of CAP will not address issues related to fanout. Thus, TARGET and DESTINATION will have to be local calendar addresses. > 4 - logically what is happening if a component is moved from one calendar to > another? Does this trigger another round of messages if the component in > question is a meeting? i.e. what is the difference between DELEGATING the > meeting to another ATTENDEE and MOVEing the meeting component to another > calendar? See Doug's previous posts on this thread. > 5 - Are vendors in fact implementing and using Parent/child relationships > between Calendars? My rough reading of CAP was that MOVE was intended to > move whole Calendars within hierarchies of calendars - i.e. a command to > modify the PARENT and CHILD fields. However I have not seen well detailed > and documented examples of how these are intended to be used. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Recherche et développement Tél. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri Nov 2 18:23:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21604 for ; Fri, 2 Nov 2001 18:23:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2N9ak17101 for ietf-calendar-bks; Fri, 2 Nov 2001 15:09:36 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2N9Z817097 for ; Fri, 2 Nov 2001 15:09:35 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA21996 for ; Fri, 2 Nov 2001 15:09:36 -0800 (PST) Message-ID: <3BE32227.2675C6C8@Royer.com> Date: Fri, 02 Nov 2001 15:45:59 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Filing of components References: <3BE3189B.6DA2B767@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > 4 - logically what is happening if a component is moved from one calendar to > > another? Does this trigger another round of messages if the component in > > question is a meeting? i.e. what is the difference between DELEGATING the > > meeting to another ATTENDEE and MOVEing the meeting component to another > > calendar? > > See Doug's previous posts on this thread. ! Lay it on me :-) The discussion was the lack of the ability for a CU to move an entry. As you can not be logged in twice in the same session, this would mean that you have exactly the same access as you would have before this existed. No permission gained, none lost. I don't think there are any security issues. This (As I understand it) allows you to move an entry from one of YOUR calendars to another of YOUR calendars (in the same CS). I guess the DESTINATION could be any calendar for which the CU has access already (on the same CS). Issues (which MUST BE added to CAP if this is agreed to): 1) The CS implementation MUST do (a) or (b) .IF. the ORGANIZER's is moving the reply-to (cal-address) entry: (a) Transparently allow users to continue to have access to the same entry as if it had never changed via the UID for the entry. The CS could do this without the CUA ever knowing the OWNER move the entry to there preferred calendar. Note: A CS ~could~ have already implemented this - it is not dependent on the DESTINATION addition. (b) Notify the users of an update to the cal-address for the event using the iTIP update method. The UID MUST remain the same. NOTE: This is nothing new, if you caged your ORIGANIZER:cal-address, you had to notify them already. Via UPDATE. One of these two MUST BE done or the iTIP portion of CAP breaks. 2) If the ATTENDEE's entry is changing in the ATTENDEE's calendar, any updates to the entry MUST ether: (a) Be transparently handled. or (b) The ATTENDEE MUST notify the ORGANIZER of new ATTENDEE:cal-address, followed by a REFRESH. NOTE: (a) Could have already been done in an implementation. (b) Would have to be done anyway for iTIP to work. > > 5 - Are vendors in fact implementing and using Parent/child relationships > > between Calendars? My rough reading of CAP was that MOVE was intended to > > move whole Calendars within hierarchies of calendars - i.e. a command to > > modify the PARENT and CHILD fields. However I have not seen well detailed > > and documented examples of how these are intended to be used. I don't think it adds any requirements to a CAP server, other than allowing a CU to move the CU's entries to any calendar on the same CS where the authenticated user already has access. I think this is a recognition that we missed this as an issue. If someone deposits a entry in one of YOUR calendars, and you want it in another of YOUR calendars on the same CS - there was no way to do this. With this there is. You could have parent/child calendars, you could have peer calendars. Ether way, the OWNER of the calendar should be able to re-organize their own calendars. -Doug From owner-ietf-calendar@mail.imc.org Mon Nov 5 11:48:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27852 for ; Mon, 5 Nov 2001 11:48:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA5GABs02523 for ietf-calendar-bks; Mon, 5 Nov 2001 08:10:11 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5GA9802511 for ; Mon, 5 Nov 2001 08:10:09 -0800 (PST) From: Bruce_Kahn@iris.com To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: CAP: why do we need GENERATEUID? MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: Date: Mon, 5 Nov 2001 11:10:07 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_10252001|October 25, 2001) at 11/05/2001 11:06:40 AM, Serialize complete at 11/05/2001 11:06:40 AM Content-Type: multipart/alternative; boundary="=_alternative 0058869785256AFB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058869785256AFB_= Content-Type: text/plain; charset="US-ASCII" John Stracke wrote on 11/02/2001 01:02:34 PM: > > Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out > the 'mail file'/'message store', we are doing the same in CAP. > > The difference is that it's feasible for a server to treat email messages > as opaque blobs with a bit of machine-readable data. Not true of IMAP. The IMAP server must be able to understand the structure of the entire MIME stream so that it can deal with IMAP clients that want to query the messages structure, etc. They can also care about the contents in some cases such as statistics generation, attachment scanning (for virsues, confidentail info, etc) and other assorted 'administrative' tasks. > An iCalendar object > consists almost entirely of machine-readable data; the server needs to > understand the semantics of that data, and store it in a way it can search > quickly. Ok, given that Notes preceded MIME by ~5 years; how do you think that Notes can store its own data AND MIME data w/FULL fidelity? Its all in how you design your storage system. In my mail file alone I have "Notes Mail" and any number of MIME messages with full fidelity. My calendar has > 3000 entries in it going back as far as 1996 and I can access any entry w/o any performance problems. (Im NOT going to to turn this into Notes Architecture 101 so dont worry about that. Im still unrepentant in my belief that NOT EVERYONE will build their CS using a relational dB as most seem to claim. If other vendors want to, go for it. Just dont make the implicit assumption that EVERYONE will and therefore stuff like the issues I keep raising will just go away.) Since you brought up the issue of CS storage Ill persist a bit to demonstrate my point. There is NOTHING precluding a Calendar Store from storing meta data in addition to the original, untainted data. In fact thats what EVERYONE will have to do if they EVER want to support preservation of signatures on MIME data let alone. No way around it. Even if you use the most high end, fanciest dB engine in the world you are going to need to build indexes on the data in addition to the actual data itself. Whether you break it down into parts and store it in different tables in a relational dB or if you use a different model, you are going to have to have indexes/meta data. > > You can pick your own back end store but not all implementors (Lotus / > IBM, Open Source projects, etc) will be using someone elses backend store > > for the data for assorted reasons (ie: $$$, flexibility, ROI, etc). > > Sure. It's all tradeoffs. Personally, I think the database approach is > best, By implicit definition the CS _is_ a database. However I suspect you are referring to relational dBs over any kind of other database format... > True--which argues for the GENERATEUID approach, which I had conceded in > the message you were replying to. Mea culpa. Thats now how I understood your response to Alex. In rereading it w/some caffine I think we are on the same page WRT this. > > Also, if the data is encrypted then the CS > > ...will not be able to search it. Unless you provide some of the data in unencrypted form for the CS's benefit. I can easily argue that the CS does NOT need to know the DESCRIPTION of a very top secret meeting between Bill Gates and Lou Gerstner to discuss IBM buying out Microsoft product lines (FICTIONAL EVENT here to make a point). It may need to know the DTSTART/DTEND so that their CUAs can query for events based on the time frame ("What entries are on my calendar for today?"). As such, the proposed CAP change (from Washington DC hall talks) to provide some information 'external' to the 'original' iCalendar data can be a solution. It does mean that there is some data redundency involved but it beats mandating that I have to give the decription keys to the CS OR precluding data encryption entirely. Nothing so far says that a CS cannot have a policy of rejecting signed/encrypted iCalendar w/a message like "Encrypted calendar entries are not allowed if they cannot be decrypted by the CS" or some appropriate response code/message... Time to get my AM caffine dosage to wake up properly... 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 0058869785256AFB_= Content-Type: text/html; charset="US-ASCII"
John Stracke wrote on 11/02/2001 01:02:34 PM:
> > Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out
> the 'mail file'/'message store', we are doing the same in CAP.
>
> The difference is that it's feasible for a server to treat email messages
> as opaque blobs with a bit of machine-readable data.

Not true of IMAP.  The IMAP server must be able to understand the structure of the entire MIME stream so that it can deal with IMAP clients that want to query the messages structure, etc.  They can also care about the contents in some cases such as statistics generation, attachment scanning (for virsues, confidentail info, etc) and other assorted 'administrative' tasks.

>                                               An iCalendar object
> consists almost entirely of machine-readable data; the server needs to
> understand the semantics of that data, and store it in a way it can search
> quickly.

Ok, given that Notes preceded MIME by ~5 years; how do you think that Notes can store its own data AND MIME data w/FULL fidelity?  Its all in how you design your storage system.  In my mail file alone I have "Notes Mail" and any number of MIME messages with full fidelity.  My calendar has > 3000 entries in it going back as far as 1996 and I can access any entry w/o any performance problems.  (Im NOT going to to turn this into Notes Architecture 101 so dont worry about that.  Im still unrepentant in my belief that NOT EVERYONE will build their CS using a relational dB as most seem to claim.  If other vendors want to, go for it.  Just dont make the implicit assumption that EVERYONE will and therefore stuff like the issues I keep raising will just go away.)

Since you brought up the issue of CS storage Ill persist a bit to demonstrate my point.  There is NOTHING precluding a Calendar Store from storing meta data in addition to the original, untainted data.  In fact thats what EVERYONE will have to do if they EVER want to support preservation of signatures on MIME data let alone.   No way around it.  Even if you use the most high end, fanciest dB engine in the world you are going to need to build indexes on the data in addition to the actual data itself.  Whether you break it down into parts and store it in different tables in a relational dB or if you use a different model, you are going to have to have indexes/meta data.  

> > You can pick your own back end store but not all implementors (Lotus /
> IBM, Open Source projects, etc) will be using someone elses backend store
> > for the data for assorted reasons (ie: $$$, flexibility, ROI, etc).
>
> Sure.  It's all tradeoffs.  Personally, I think the database approach is
> best,

By implicit definition the CS _is_ a database.  However I suspect you are referring to relational dBs over any kind of other database format...

> True--which argues for the GENERATEUID approach, which I had conceded in
> the message you were replying to.

Mea culpa.  Thats now how I understood your response to Alex.  In rereading it w/some caffine I think we are on the same page WRT this.

> > Also, if the data is encrypted then the CS
>
> ...will not be able to search it.

Unless you provide some of the data in unencrypted form for the CS's benefit.  I can easily argue that the CS does NOT need to know the DESCRIPTION of a very top secret meeting between Bill Gates and Lou Gerstner to discuss IBM buying out Microsoft product lines (FICTIONAL EVENT here to make a point).  It may need to know the DTSTART/DTEND so that their CUAs can query for events based on the time frame ("What entries are on my calendar for today?").  As such, the proposed CAP change (from Washington DC hall talks) to provide some information 'external' to the 'original' iCalendar data can be a solution.  It does mean that there is some data redundency involved but it beats mandating that I have to give the decription keys to the CS OR precluding data encryption entirely.  Nothing so far says that a CS cannot have a policy of rejecting signed/encrypted iCalendar w/a message like "Encrypted calen! dar entries are not allowed if they cannot be decrypted by the CS" or some appropriate response code/message...

Time to get my AM caffine dosage to wake up properly...

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 0058869785256AFB_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 5 12:03:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28337 for ; Mon, 5 Nov 2001 12:03:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA5GWnO03458 for ietf-calendar-bks; Mon, 5 Nov 2001 08:32:49 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5GWl803454 for ; Mon, 5 Nov 2001 08:32:47 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id LAA07456; Mon Nov 5 11:30:37 2001 Subject: Re: CAP: why do we need GENERATEUID? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 5 Nov 2001 11:34:43 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/05/2001 11:34:45 AM, Serialize complete at 11/05/2001 11:34:45 AM Content-Type: text/plain; charset="us-ascii" To: Bruce_Kahn@iris.com From: "John Stracke" Cc: ietf-calendar@imc.org Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bruce Kahn wrote: > John Stracke wrote on 11/02/2001 01:02:34 PM: > > > Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out > > the 'mail file'/'message store', we are doing the same in CAP. > > > > The difference is that it's feasible for a server to treat email messages > > as opaque blobs with a bit of machine-readable data. > > Not true of IMAP. The IMAP server must be able to understand the structure of the entire MIME stream so that it can deal with IMAP clients that > want to query the messages structure, etc. They can also care about the contents in some cases such as statistics generation, attachment > scanning (for virsues, confidentail info, etc) and other assorted 'administrative' tasks. ...none of which are possible on encrypted messages. If you have an encrypted message, your IMAP server can tell you so, but it can't do any analysis for you. Same for a CS--the difference being that analysis is the CS's *primary* function. > > > Also, if the data is encrypted then the CS > > > > ...will not be able to search it. > > Unless you provide some of the data in unencrypted form for the CS's benefit. Mrphl. I suppose you could do that...perhaps with a multipart/alternative, where the first alternative is the unencrypted text/calendar, with sensitive fields masked out, and the second is the encrypted version, which is complete. Makes me kind of nervous, though; I don't like the idea that my calendar may wind up showing me inconsistent views. If I've got a meeting where the SUMMARY is encrypted and the DTSTART/DTEND is not, then it'll show up on my monthly view; but, if I do a search by summary, I won't find it. Bad usability. No biscuit. And interop remains the sticking point, since it's likely only Notes would be able to handle it. John Stracke Principal Engineer Incentive Systems, Inc. jstracke@incentivesystems.com From owner-ietf-calendar@mail.imc.org Mon Nov 5 16:39:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08675 for ; Mon, 5 Nov 2001 16:39:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA5LCIO16052 for ietf-calendar-bks; Mon, 5 Nov 2001 13:12:18 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5LCH816047 for ; Mon, 5 Nov 2001 13:12:17 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA20085 for ; Mon, 5 Nov 2001 13:12:18 -0800 (PST) Message-ID: <3BE6FB61.24D8FED3@Royer.com> Date: Mon, 05 Nov 2001 13:49:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: why do we need GENERATEUID? References: Content-Type: multipart/mixed; boundary="------------73F2F1B6429FA8C56B19C14B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------73F2F1B6429FA8C56B19C14B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > John Stracke wrote on 11/02/2001 01:02:34 PM: > > > Just as IMAP and POP3 deal with MIME on-the-wire and they abstract out > > the 'mail file'/'message store', we are doing the same in CAP. > > > > The difference is that it's feasible for a server to treat email messages > > as opaque blobs with a bit of machine-readable data. > > Not true of IMAP. The IMAP server must be able to understand the structure > of the entire MIME stream so that it can deal with IMAP clients that want to > query the messages structure, etc. They can also care about the contents in > some cases such as statistics generation, attachment scanning (for virsues, > confidentail info, etc) and other assorted 'administrative' tasks. Not for encrypted MIME body parts. That's the point of encrypting them. > Unless you provide some of the data in unencrypted form for the CS's > benefit. I can easily argue that the CS does NOT need to know the > DESCRIPTION of a very top secret meeting between Bill Gates and Lou Gerstner > to discuss IBM buying out Microsoft product lines (FICTIONAL EVENT here to > make a point). Sure, you can hide parts of the object, as long as it is still a valid object (per the restriction tables). >It may need to know the DTSTART/DTEND so that their CUAs can > query for events based on the time frame ("What entries are on my calendar > for today?"). As such, the proposed CAP change (from Washington DC hall > talks) to provide some information 'external' to the 'original' iCalendar > data can be a solution. It does mean that there is some data redundency > involved but it beats mandating that I have to give the decription keys to > the CS OR precluding data encryption entirely. Nothing so far says that a > CS cannot have a policy of rejecting signed/encrypted iCalendar w/a message > like "Encrypted calen! dar entries are not allowed if they cannot be > decrypted by the CS" or some appropriate response code/message... Yes there is such a restriction. If the CS can not parse the object, it is not a valid object. Look at the restriction tables. If the CS does not know if there is a UID, SUMMARY, DTSTART, ..., then it is not a valid object. Are you proposing that some of the TEXT fields be encrypted and not the entire object? If so that might make a great additional draft. Perhaps with a 'encrypted=true' (or whatever) parameter to properties that ~could~ have their values encrypted? Again - out of scope for CAP. That may be an add on to iCal as long as none of the iTIP/CAP needed fields are encrypted. -Doug --------------73F2F1B6429FA8C56B19C14B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------73F2F1B6429FA8C56B19C14B-- From owner-ietf-calendar@mail.imc.org Tue Nov 6 10:07:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16503 for ; Tue, 6 Nov 2001 10:07:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6EmV914025 for ietf-calendar-bks; Tue, 6 Nov 2001 06:48:31 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6EmT814021 for ; Tue, 6 Nov 2001 06:48:30 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA11296; Tue, 6 Nov 2001 09:48:23 -0500 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA6EmMH14562; Tue, 6 Nov 2001 09:48:23 -0500 (EST) Message-ID: <3BE7F7CF.D06735FF@steltor.com> Date: Tue, 06 Nov 2001 09:46:39 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: New Interim Version Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, There is a new interim version of CAP. It can be found at: http://calsch.org/ietf/drafts.html Changes - removed UPNEXPAND - removed CALIDEXPAND - changed VCALENDAR to VAGENDA to describe calendars - many small corrections George From owner-ietf-calendar@mail.imc.org Tue Nov 6 14:19:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28208 for ; Tue, 6 Nov 2001 14:19:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6IaNc03177 for ietf-calendar-bks; Tue, 6 Nov 2001 10:36:23 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6IaM803172 for ; Tue, 6 Nov 2001 10:36:22 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: why do we need GENERATEUID? MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Tue, 6 Nov 2001 13:34:59 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/06/2001 01:50:20 PM, Serialize complete at 11/06/2001 01:50:20 PM Content-Type: multipart/alternative; boundary="=_alternative 0065E10985256AFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065E10985256AFC_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/05/2001 03:49:37 PM: > > Not true of IMAP. The IMAP server must be able to understand the structure > > of the entire MIME stream so that it can deal with IMAP clients that want to > > query the messages structure, etc. They can also care about the contents in > > some cases such as statistics generation, attachment scanning (for virsues, > > confidentail info, etc) and other assorted 'administrative' tasks. > > Not for encrypted MIME body parts. That's the point of encrypting them. Thats the problem w/using both signing and encryption in the same thread; its hard to always distinguish between a signed only case and an encryption only case (or the signed AND encrypted case). The IMAP server needs to understand the MIME hierarchy of an encrypted only msg in that it must be able to at least parse out the encrypted block(s) from the rest so that it can build the MIME hierarchy properly so that it can be properly represented to the IMAP client. It does NOT have to parse into and grok the encrypted data (I never claimed that). It must be able to at least grok what body parts are encrypted and 'do the best it can' w/them but deal properly w/the other non-encrypted body parts that occur before/after the encrypted stuff (in the worse case scenario of only encrypted some body parts, NOT all of them). In any case, the citation of IMAP/POP3 has been streteched beyond the intended discussion use. Time to get back to the original topic. I think we are in agreement about keeping GENERATEUID so persuing this under the current title is a digression. (We can persue it under its own heading later...) > Yes there is such a restriction. If the CS can not parse the object, > it is not a valid object. Look at the restriction tables. If the CS > does not know if there is a UID, SUMMARY, DTSTART, ..., then it > is not a valid object. This gets back to the unresolved issue about the requirements of CAP and not relevant to GENERATEUID. We can take this up (again) under its own thread. 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 0065E10985256AFC_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/05/2001 03:49:37 PM:
> > Not true of IMAP.  The IMAP server must be able to understand the structure
> > of the entire MIME stream so that it can deal with IMAP clients that want to
> > query the messages structure, etc.  They can also care about the contents in
> > some cases such as statistics generation, attachment scanning (for virsues,
> > confidentail info, etc) and other assorted 'administrative' tasks.
>
> Not for encrypted MIME body parts. That's the point of encrypting them.
Thats the problem w/using both signing and encryption in the same thread; its hard to always distinguish between a signed only case and an encryption only case (or the signed AND encrypted case).  

The IMAP server needs to understand the MIME hierarchy of an encrypted only msg in that it must be able to at least parse out the encrypted block(s) from the rest so that it can build the MIME hierarchy properly so that it can be properly represented to the IMAP client.  It does NOT have to parse into and grok the encrypted data (I never claimed that).  It must be able to at least grok what body parts are encrypted and 'do the best it can' w/them but deal properly w/the other non-encrypted body parts that occur before/after the encrypted stuff (in the worse case scenario of only encrypted some body parts, NOT all of them).

In any case, the citation of IMAP/POP3 has been streteched beyond the intended discussion use.  Time to get back to the original topic.  I think we are in agreement about keeping GENERATEUID so persuing this under the current title is a digression.  (We can persue it under its own heading later...)

> Yes there is such a restriction. If the CS can not parse the object,
> it is not a valid object. Look at the restriction tables. If the CS
> does not know if there is a UID, SUMMARY, DTSTART, ..., then it
> is not a valid object.

This gets back to the unresolved issue about the requirements of CAP and not relevant to GENERATEUID.  We can take this up (again) under its own thread.

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 0065E10985256AFC_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 7 17:24:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24989 for ; Wed, 7 Nov 2001 17:24:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA7Lrl514920 for ietf-calendar-bks; Wed, 7 Nov 2001 13:53:47 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA7Lrj814916 for ; Wed, 7 Nov 2001 13:53:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA01699; Wed, 7 Nov 2001 13:53:36 -0800 (PST) Message-ID: <3BE9A80C.431BA720@Royer.com> Date: Wed, 07 Nov 2001 14:30:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) References: Content-Type: multipart/mixed; boundary="------------BF468E03CAEB6F0548E8382B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BF468E03CAEB6F0548E8382B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Thats the problem w/using both signing and encryption in the same thread; > its hard to always distinguish between a signed only case and an encryption > only case (or the signed AND encrypted case). Okay, now I understand (I think). Are you saying that you want a CAP server to be able to get a MIME object, some of which could be encrypted (some BODY PARTS), and you want the CAP server to be able to pull out the non-encrypted body-parts that are CAP/iCal object (not encrypted)? Or in other words ar you saying(?): A CAP server MUST BE able to process a MIME object of type MULTIPART/ and correctly extract out the iCalendar object and ignore the non-iCalendar body-parts? If so, I agree. And I think that is one of the things that Frank kept promising to get into iCalendar-next. I Think that CAP used to say that, however it is not in the current draft - a TODO? I think the problem came up when everyone (except Microsoft), could handle multipart/ with text/calendar MIME objects. The current wording in CAP does not say this. I am sure it was added at some point, but it is not in cap now. Did someone remove it? If so why? -Doug --------------BF468E03CAEB6F0548E8382B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------BF468E03CAEB6F0548E8382B-- From owner-ietf-calendar@mail.imc.org Thu Nov 8 09:37:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27213 for ; Thu, 8 Nov 2001 09:37:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA8EJHT19886 for ietf-calendar-bks; Thu, 8 Nov 2001 06:19:17 -0800 (PST) Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8EJF819881 for ; Thu, 8 Nov 2001 06:19:15 -0800 (PST) Received: from james ([212.151.240.3]) by fep01-svc.swip.net with SMTP id <20011108141910.SWZ26807.fep01-svc.swip.net@james> for ; Thu, 8 Nov 2001 15:19:10 +0100 From: "Greg FitzPatrick" To: Subject: logical model of reoccurrence Date: Thu, 8 Nov 2001 15:09:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3BE9A80C.431BA720@Royer.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here is the URL to the paper I am giving in a session together with Libby Miller at XML2001 in Orlando. The aim of the paper is to formalize a logical and mnemonic model for the representation of Temporal information. The model, which we are calling Orlando, is evolved from the iCal RFC2445 datetime and datetime reoccurrence rules. In our migration from mime-directory to XML and RDF, it is important that we identify the incongruities discovered in the RFC2445 reoccurrence rules and make sure that we just don't pass these problems on unsolved. Other problems addressed are: Unambiguous identification of end-inclusive/end-exclusive interval representation. Unambiguous identification of periods. Are they duration specific ( the exact amount of days of seconds) or are they calendar specific (landing on some exact point on a wall clock or calendar? Any comments are appreciated and serious goofs unearthed will earn you a beer at the next IETF. the link is: http://skical.org/orlando/ Greg From owner-ietf-calendar@mail.imc.org Thu Nov 8 12:25:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01753 for ; Thu, 8 Nov 2001 12:25:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8H35J02447 for ietf-calendar-bks; Thu, 8 Nov 2001 09:03:05 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8H33802434 for ; Thu, 8 Nov 2001 09:03:03 -0800 (PST) To: "Greg FitzPatrick" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: logical model of reoccurrence MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 8 Nov 2001 12:02:33 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/08/2001 12:02:41 PM, Serialize complete at 11/08/2001 12:02:41 PM Content-Type: multipart/alternative; boundary="=_alternative 005DAD3F85256AFE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DAD3F85256AFE_= Content-Type: text/plain; charset="us-ascii" Greg, what do you mean by migration from mime-directory to RDF and XML. Are you talking about SkiCal? Or RFC2445? Right now we are not working on a migration. We have a document that shows an XML schema that rests on "top of" RFC2445. But it's not a replacement or migration. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Greg FitzPatrick" Sent by: owner-ietf-calendar@mail.imc.org 11/08/01 09:09 To: cc: Subject: logical model of reoccurrence Here is the URL to the paper I am giving in a session together with Libby Miller at XML2001 in Orlando. The aim of the paper is to formalize a logical and mnemonic model for the representation of Temporal information. The model, which we are calling Orlando, is evolved from the iCal RFC2445 datetime and datetime reoccurrence rules. In our migration from mime-directory to XML and RDF, it is important that we identify the incongruities discovered in the RFC2445 reoccurrence rules and make sure that we just don't pass these problems on unsolved. Other problems addressed are: Unambiguous identification of end-inclusive/end-exclusive interval representation. Unambiguous identification of periods. Are they duration specific ( the exact amount of days of seconds) or are they calendar specific (landing on some exact point on a wall clock or calendar? Any comments are appreciated and serious goofs unearthed will earn you a beer at the next IETF. the link is: http://skical.org/orlando/ Greg --=_alternative 005DAD3F85256AFE_= Content-Type: text/html; charset="us-ascii"
Greg, what do you mean by migration from mime-directory to RDF and XML.  Are you talking about SkiCal?  Or RFC2445?  Right now we are not working on a migration.  We have a document that shows an XML schema that rests on "top of" RFC2445.  But it's not a replacement or migration.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


"Greg FitzPatrick" <greg@metamatrix.se>
Sent by: owner-ietf-calendar@mail.imc.org

11/08/01 09:09

       
        To:        <ietf-calendar@imc.org>
        cc:        
        Subject:        logical model of reoccurrence





Here is the URL to the paper I am giving in a session together with Libby
Miller at XML2001 in Orlando.

The aim of the paper is to formalize a logical and mnemonic model for the
representation of Temporal information.

The model, which we are calling Orlando, is evolved from the iCal RFC2445
datetime and datetime reoccurrence rules.

In our migration from mime-directory to XML and RDF, it is important that we
identify the incongruities discovered in the RFC2445 reoccurrence rules and
make sure that we just don't pass these problems on unsolved.

Other problems addressed are:

Unambiguous identification of end-inclusive/end-exclusive interval
representation.

Unambiguous identification of periods.  Are they duration specific ( the
exact amount of days of seconds) or are they calendar specific (landing on
some exact point on a wall clock or calendar?

Any comments are appreciated and serious goofs unearthed will earn you a
beer at the next IETF.

the link is:

http://skical.org/orlando/

Greg

--=_alternative 005DAD3F85256AFE_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 8 14:25:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04604 for ; Thu, 8 Nov 2001 14:25:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8JA3Z10081 for ietf-calendar-bks; Thu, 8 Nov 2001 11:10:03 -0800 (PST) Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8JA1810071 for ; Thu, 8 Nov 2001 11:10:01 -0800 (PST) Received: from james ([212.151.236.234]) by fep01-svc.swip.net with SMTP id <20011108190956.BYMV26807.fep01-svc.swip.net@james>; Thu, 8 Nov 2001 20:09:56 +0100 From: "Greg FitzPatrick" To: Cc: , Subject: SV: logical model of reoccurrence Date: Thu, 8 Nov 2001 20:00:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C16890.0D051220" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C16890.0D051220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sorry - I was not very clear. The RDF calendaring group is using iCal as a base for their work. Migrating is perhaps a poor choice of words - but when they are done the results will not be pure RFC2445. From my mail one could get the impression that the CALSCH WG was "migrating" which if course is not the case. My apologies On the other hand I believe that the Orlando model is significant for even those who are not migrating. So I hope several of us will get a chance to read it. The first beer goes to Graham Klyne who discovered the first typo " >You say: Greg(2020) OR OFFSET(P1Y) = Greg(2021//2022) > and I don't see any reasonable definition that gives you that result. The correct example should read Greg(2020) OR OFFSET(P1Y) = Greg(2020//2022), -----Ursprungligt meddelande----- Från: pregen@egenconsulting.com [mailto:pregen@egenconsulting.com] Skickat: Thursday, November 08, 2001 6:03 PM Till: Greg FitzPatrick Kopia: ietf-calendar@imc.org; owner-ietf-calendar@mail.imc.org Ämne: Re: logical model of reoccurrence Greg, what do you mean by migration from mime-directory to RDF and XML. Are you talking about SkiCal? Or RFC2445? Right now we are not working on a migration. We have a document that shows an XML schema that rests on "top of" RFC2445. But it's not a replacement or migration. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Greg FitzPatrick" Sent by: owner-ietf-calendar@mail.imc.org 11/08/01 09:09 To: cc: Subject: logical model of reoccurrence Here is the URL to the paper I am giving in a session together with Libby Miller at XML2001 in Orlando. The aim of the paper is to formalize a logical and mnemonic model for the representation of Temporal information. The model, which we are calling Orlando, is evolved from the iCal RFC2445 datetime and datetime reoccurrence rules. In our migration from mime-directory to XML and RDF, it is important that we identify the incongruities discovered in the RFC2445 reoccurrence rules and make sure that we just don't pass these problems on unsolved. Other problems addressed are: Unambiguous identification of end-inclusive/end-exclusive interval representation. Unambiguous identification of periods. Are they duration specific ( the exact amount of days of seconds) or are they calendar specific (landing on some exact point on a wall clock or calendar? Any comments are appreciated and serious goofs unearthed will earn you a beer at the next IETF. the link is: http://skical.org/orlando/ Greg ------=_NextPart_000_0007_01C16890.0D051220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sorry=20 - I was not very clear.  The RDF calendaring group is using  = iCal as a=20 base for their work.  Migrating is perhaps a poor choice of words - = but=20 when they are done the results will not be pure RFC2445.  From my = mail one=20 could get the impression that the CALSCH WG was "migrating" which if = course is=20 not the case. My apologies
 
On the=20 other hand I believe that the Orlando model is significant for even = those=20 who are not migrating. So I hope several of us will get a chance to read = it.  
 
The first beer goes to Graham Klyne who discovered the = first typo=20 "

>You say: Greg(2020) OR OFFSET(P1Y) = =3D=20 Greg(2021//2022)

> and I don't see any=20 reasonable = definition that=20 gives you that result.

The correct = example should=20 read 
 
Greg(2020) OR = OFFSET(P1Y) =3D=20 Greg(2020//2022), =
-----Ursprungligt meddelande-----
Fr=E5n:=20 pregen@egenconsulting.com=20 [mailto:pregen@egenconsulting.com]
Skickat: Thursday, = November 08,=20 2001 6:03 PM
Till: Greg FitzPatrick
Kopia:=20 ietf-calendar@imc.org; = owner-ietf-calendar@mail.imc.org
=C4mne: Re:=20 logical model of reoccurrence


Greg, what do you mean by migration from mime-directory to = RDF and XML.=20  Are you talking about SkiCal?  Or RFC2445?  Right now = we are=20 not working on a migration.  We have a document that shows an XML = schema=20 that rests on "top of" RFC2445.  But it's not a replacement or=20 migration.
___________________
Patricia Egen=20 Consulting
www.egenconsulting.com
423-875-2652 =


"Greg FitzPatrick"=20 <greg@metamatrix.se>
Sent by: owner-ietf-calendar@mail.imc.org=20

11/08/01 09:09 =

        =
        To: =    =20    <ietf-calendar@imc.org>
        cc: =    =20    
  =  =20     Subject:        logical model = of=20 reoccurrence





Here is the URL to the paper I am giving in a = session=20 together with Libby
Miller at XML2001 in Orlando.

The aim of = the=20 paper is to formalize a logical and mnemonic model for = the
representation=20 of Temporal information.

The model, which we are calling = Orlando, is=20 evolved from the iCal RFC2445
datetime and datetime reoccurrence=20 rules.

In our migration from mime-directory to XML and RDF, it = is=20 important that we
identify the incongruities discovered in the = RFC2445=20 reoccurrence rules and
make sure that we just don't pass these = problems on=20 unsolved.

Other problems addressed are:

Unambiguous=20 identification of end-inclusive/end-exclusive=20 interval
representation.

Unambiguous identification of = periods.=20  Are they duration specific ( the
exact amount of days of = seconds) or=20 are they calendar specific (landing on
some exact point on a wall = clock or=20 calendar?

Any comments are appreciated and serious goofs = unearthed will=20 earn you a
beer at the next IETF.

the link=20 = is:

http://skical.org/orlando/

Greg


=

------=_NextPart_000_0007_01C16890.0D051220-- From owner-ietf-calendar@mail.imc.org Thu Nov 8 15:13:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05740 for ; Thu, 8 Nov 2001 15:13:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA8JpKT13131 for ietf-calendar-bks; Thu, 8 Nov 2001 11:51:20 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8JpI813126 for ; Thu, 8 Nov 2001 11:51:18 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id NAA04781 for ; Thu, 8 Nov 2001 13:49:59 -0600 From: "Shannon J. Clark" To: Subject: RE: MIME Multiple body parts (Was Re: uid...) Date: Thu, 8 Nov 2001 13:51:18 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <3BE9A80C.431BA720@Royer.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, Just a thought along these lines: 1 - are we discussing a MULTIPART composed of iCalendar related objects? (some encrypted, some not perhaps?) or 2 - are we discussing a MULTIPART composed of a text or text/html object + an iCalendar object? Also - if the iCalendar object has say an Attachment - are we considering allowing that ATTACHMENT to be bundled as part of the MULTIPART message, and/or for that ATTACHMENT to be encrypted in some manner? Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Wednesday, November 07, 2001 3:31 PM To: ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) > Thats the problem w/using both signing and encryption in the same thread; > its hard to always distinguish between a signed only case and an encryption > only case (or the signed AND encrypted case). Okay, now I understand (I think). Are you saying that you want a CAP server to be able to get a MIME object, some of which could be encrypted (some BODY PARTS), and you want the CAP server to be able to pull out the non-encrypted body-parts that are CAP/iCal object (not encrypted)? Or in other words ar you saying(?): A CAP server MUST BE able to process a MIME object of type MULTIPART/ and correctly extract out the iCalendar object and ignore the non-iCalendar body-parts? If so, I agree. And I think that is one of the things that Frank kept promising to get into iCalendar-next. I Think that CAP used to say that, however it is not in the current draft - a TODO? I think the problem came up when everyone (except Microsoft), could handle multipart/ with text/calendar MIME objects. The current wording in CAP does not say this. I am sure it was added at some point, but it is not in cap now. Did someone remove it? If so why? -Doug From owner-ietf-calendar@mail.imc.org Thu Nov 8 16:19:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08159 for ; Thu, 8 Nov 2001 16:19:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8L0dp16095 for ietf-calendar-bks; Thu, 8 Nov 2001 13:00:39 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8L0b816091 for ; Thu, 8 Nov 2001 13:00:37 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id PAA15033; Thu Nov 8 15:58:29 2001 Subject: RE: MIME Multiple body parts (Was Re: uid...) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 8 Nov 2001 16:02:57 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/08/2001 04:02:58 PM, Serialize complete at 11/08/2001 04:02:58 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >1 - are we discussing a MULTIPART composed of iCalendar related objects? >(some encrypted, some not perhaps?) Only if we adopt Bruce's suggestion of having some fields encrypted and others not (this could be done by the multipart/alternative approach I mentioned). >2 - are we discussing a MULTIPART composed of a text or text/html object + >an iCalendar object? I think so. For example, it will probably be common to send a multipart/mixed containing a text/plain and an text/calendar. (Less common, because it's broken, is the approach taken by Microsoft Entourage: a multipart/alternative containing first the text/calendar and then the text/html. A recipient that understands text/html will never see the text/calendar.) >Also - if the iCalendar object has say an Attachment - are we considering >allowing that ATTACHMENT to be bundled as part of the MULTIPART message, >and/or for that ATTACHMENT to be encrypted in some manner? Strictly speaking, it's permitted by RFC-2445; the ATTACH is specified by a URL, so you can use a cid: to reference bodyparts. Whether a CAP server would deal with it is another question. As a practical matter, sending an iMIP message with a cid: attachment is probably risky. It's easy for a recipient's MUA to take the text/calendar and pass it off to the CUA for processing; but permitting the CUA to go back to the MUA to resolve the cid: URL requires more integration. It'd be trivial for an app that combines the CUA and the MUA (e.g., Evolution, Outlook, Notes), but not for independent apps. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |"The struggle is always worthwhile, if the end be worthwhile and| |the means honorable; foreknowledge of defeat is not sufficient | |reason to withdraw from the contest." -- Adron e'Kieron, by | |Steven Brust | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 8 17:42:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10556 for ; Thu, 8 Nov 2001 17:42:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8MK8D19535 for ietf-calendar-bks; Thu, 8 Nov 2001 14:20:08 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8MK7819531 for ; Thu, 8 Nov 2001 14:20:07 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id QAA04933; Thu, 8 Nov 2001 16:18:45 -0600 From: "Shannon J. Clark" To: "John Stracke" , Subject: RE: MIME Multiple body parts (Was Re: uid...) Date: Thu, 8 Nov 2001 16:20:05 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, Thanks - helps clarify matters. Something else I realized - There is a common trend to associate ONE MIME object holding an iCalendar object with ONE vEVENT (and perhaps a vTimezone object). In fact I think some vendors may ONLY deal with iCalendar objects that contain only one vEVENT. However it is clearly valid to have a vCalendar with multiple vEVENT objects (or else what are we doing here???) How would you encode a iCalendar object holding multiple vEVENTS that were in DIFFERENT languages (and required DIFFERENT character encodings - say a calendar with meetings in Tokyo and Singapore - requiring Japanese and Chinese character encodings...)? In general how are "full calendar" objects intended to be handled - much of the standards we are writing seem to treat individual events as the primary unit for work - associating with them perhaps a vTimezone object, but other objects such as vTODO or even multiple vEVENT objects seem to be perhaps more complex to deal with? For that matter should it be possible to send multiple vCalendar objects? thanks, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Thursday, November 08, 2001 3:03 PM To: ietf-calendar@imc.org Subject: RE: MIME Multiple body parts (Was Re: uid...) >1 - are we discussing a MULTIPART composed of iCalendar related objects? >(some encrypted, some not perhaps?) Only if we adopt Bruce's suggestion of having some fields encrypted and others not (this could be done by the multipart/alternative approach I mentioned). >2 - are we discussing a MULTIPART composed of a text or text/html object + >an iCalendar object? I think so. For example, it will probably be common to send a multipart/mixed containing a text/plain and an text/calendar. (Less common, because it's broken, is the approach taken by Microsoft Entourage: a multipart/alternative containing first the text/calendar and then the text/html. A recipient that understands text/html will never see the text/calendar.) >Also - if the iCalendar object has say an Attachment - are we considering >allowing that ATTACHMENT to be bundled as part of the MULTIPART message, >and/or for that ATTACHMENT to be encrypted in some manner? Strictly speaking, it's permitted by RFC-2445; the ATTACH is specified by a URL, so you can use a cid: to reference bodyparts. Whether a CAP server would deal with it is another question. As a practical matter, sending an iMIP message with a cid: attachment is probably risky. It's easy for a recipient's MUA to take the text/calendar and pass it off to the CUA for processing; but permitting the CUA to go back to the MUA to resolve the cid: URL requires more integration. It'd be trivial for an app that combines the CUA and the MUA (e.g., Evolution, Outlook, Notes), but not for independent apps. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |"The struggle is always worthwhile, if the end be worthwhile and| |the means honorable; foreknowledge of defeat is not sufficient | |reason to withdraw from the contest." -- Adron e'Kieron, by | |Steven Brust | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 8 18:54:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11587 for ; Thu, 8 Nov 2001 18:54:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8NbJv21184 for ietf-calendar-bks; Thu, 8 Nov 2001 15:37:19 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8NbH821179 for ; Thu, 8 Nov 2001 15:37:17 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id RAA05056; Thu, 8 Nov 2001 17:35:53 -0600 From: "Shannon J. Clark" To: Cc: Subject: RE: MIME Multiple body parts (Was Re: uid...) + iCalendar as data standard Date: Thu, 8 Nov 2001 17:37:14 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C1687C.0116F640" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C1687C.0116F640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Robert, I agree that Outlook's implementation is not complete - however that said if iCalendar, iTIP, iMIP, CAP and other future standards are to become standards then ideally they should be easily implemented by all calendar user agents and calendar servers - that is after all the goal of interoperable systems. I think that the point that using iCalendar to store a calendar store for a specific user raises some very serious questions. IF iCalendar is a DATA standard - then why is it "very complicated" and "needs careful thought" to use it to store an entire calendar for a given user? It seems to me, both as a vendor and as a user, that something called "iCalendar" - implies an ability to deal with CALENDARS - i.e. that it is something that can be used to encapsulate and deal with a calendar as a data unit. I suspect that I am not alone with this reading of the intention of the standard. It has always struck me as curious that within the iCalendar standard it is not at all clear how to talk about a "USER" - i.e. how to talk about in a logical manner "a user's calendar" I think the differentiation between thinking of iCalendar as a means to store data for ONE transaction - i.e. for one meeting, for one task vs. the thinking of "Calendaring" in general and dealing with a user's calendar is a major one - and one that we may need to address head on. thanks, Shannon -----Original Message----- From: Robert_Ransdell@iris.com [mailto:Robert_Ransdell@iris.com]On Behalf Of tom_ransdell@iris.com Sent: Thursday, November 08, 2001 5:30 PM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: RE: MIME Multiple body parts (Was Re: uid...) Outlook did not do a complete implementation so should not be used as a standard. Your second case if very complicated and needs careful thought so that the export/import completely captures and restores the calendar store. I have deferred using iCalendar to implement export/import into my product at this time. "Shannon J. Clark" cc: Subject: RE: MIME Multiple body parts (Was Re: uid...) Robert, I agree - what I am looking at is whether it is clearly spelled out in the various standards documents that supporting these cases (and others) is a MUST requirement for interoperability. At present I believe that Outlook, at least in some versions will not accept or deal with importing or receiving an iCalendar attachment or file that has multiple vEvents - it claims "invalid file format" in that situation. I am also VERY interested in the use case of using iCalendar to dump to an interchange format an entire calendar for a given user - in this case the resulting vCalendar will contain MANY vEVENT, vTODO, vTIMEZONE objects. Shannon (can I share our conversation with the rest of the working group?) -----Original Message----- From: Robert_Ransdell/Westford/IBM%IRIS%LOTUS [mailto:Robert_Ransdell/Westford/IBM%IRIS%LOTUS@lotus.com]On Behalf Of Robert Ransdell/Iris Sent: Thursday, November 08, 2001 5:11 PM To: shannon@jigzaw.com Subject: RE: MIME Multiple body parts (Was Re: uid...) There are at least two cases for multiple vEvents. 1. Simple case of a show. The multiple VEVENTS show all the possible events at the show. 2. Now for the more complicated case. When you invite a new person to an already scheduled repeating meeting. If any of the individual dates have been modified, the easiest way to show this is to send the original meeting request with additional events to show changed items such as attendee, description, etc. "Shannon J. Clark" , cc: (bcc: Robert Ransdell/Westford/IBM) Subject: RE: MIME Multiple body parts (Was Re: uid...) John, Thanks - helps clarify matters. Something else I realized - There is a common trend to associate ONE MIME object holding an iCalendar object with ONE vEVENT (and perhaps a vTimezone object). In fact I think some vendors may ONLY deal with iCalendar objects that contain only one vEVENT. However it is clearly valid to have a vCalendar with multiple vEVENT objects (or else what are we doing here???) How would you encode a iCalendar object holding multiple vEVENTS that were in DIFFERENT languages (and required DIFFERENT character encodings - say a calendar with meetings in Tokyo and Singapore - requiring Japanese and Chinese character encodings...)? In general how are "full calendar" objects intended to be handled - much of the standards we are writing seem to treat individual events as the primary unit for work - associating with them perhaps a vTimezone object, but other objects such as vTODO or even multiple vEVENT objects seem to be perhaps more complex to deal with? For that matter should it be possible to send multiple vCalendar objects? thanks, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Thursday, November 08, 2001 3:03 PM To: ietf-calendar@imc.org Subject: RE: MIME Multiple body parts (Was Re: uid...) >1 - are we discussing a MULTIPART composed of iCalendar related objects? >(some encrypted, some not perhaps?) Only if we adopt Bruce's suggestion of having some fields encrypted and others not (this could be done by the multipart/alternative approach I mentioned). >2 - are we discussing a MULTIPART composed of a text or text/html object + >an iCalendar object? I think so. For example, it will probably be common to send a multipart/mixed containing a text/plain and an text/calendar. (Less common, because it's broken, is the approach taken by Microsoft Entourage: a multipart/alternative containing first the text/calendar and then the text/html. A recipient that understands text/html will never see the text/calendar.) >Also - if the iCalendar object has say an Attachment - are we considering >allowing that ATTACHMENT to be bundled as part of the MULTIPART message, >and/or for that ATTACHMENT to be encrypted in some manner? Strictly speaking, it's permitted by RFC-2445; the ATTACH is specified by a URL, so you can use a cid: to reference bodyparts. Whether a CAP server would deal with it is another question. As a practical matter, sending an iMIP message with a cid: attachment is probably risky. It's easy for a recipient's MUA to take the text/calendar and pass it off to the CUA for processing; but permitting the CUA to go back to the MUA to resolve the cid: URL requires more integration. It'd be trivial for an app that combines the CUA and the MUA (e.g., Evolution, Outlook, Notes), but not for independent apps. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |"The struggle is always worthwhile, if the end be worthwhile and| |the means honorable; foreknowledge of defeat is not sufficient | |reason to withdraw from the contest." -- Adron e'Kieron, by | |Steven Brust | \================================================================/ ------=_NextPart_000_000E_01C1687C.0116F640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Robert,
 
I = agree that=20 Outlook's implementation is not complete - however that said if = iCalendar, iTIP,=20 iMIP, CAP and other future standards are to become standards then = ideally they=20 should be easily implemented by all calendar user agents and calendar = servers -=20 that is after all the goal of interoperable systems.
 
I = think that the=20 point that using iCalendar to store a calendar store for a specific user = raises=20 some very serious questions.
 
IF = iCalendar is a=20 DATA standard - then why is it "very complicated" and "needs careful = thought" to=20 use it to store an entire calendar for a given user?
 
It = seems to me, both=20 as a vendor and as a user, that something called "iCalendar" - implies = an=20 ability to deal with CALENDARS - i.e. that it is something that can be = used to=20 encapsulate and deal with a calendar as a data unit. I suspect that I am = not=20 alone with this reading of the intention of the = standard.
 
It has = always struck=20 me as curious that within the iCalendar standard it is not at all clear = how to=20 talk about a "USER" - i.e. how to talk about in a logical manner "a = user's=20 calendar"
 
I = think the=20 differentiation between thinking of iCalendar as a means to store data = for ONE=20 transaction - i.e. for one meeting, for one task vs. the thinking of=20 "Calendaring" in general and dealing with a user's calendar is a major = one - and=20 one that we may need to address head on.
 
thanks,
 
Shannon
-----Original Message-----
From: = Robert_Ransdell@iris.com=20 [mailto:Robert_Ransdell@iris.com]On Behalf Of=20 tom_ransdell@iris.com
Sent: Thursday, November 08, 2001 = 5:30=20 PM
To: Shannon J. Clark
Cc:=20 ietf-calendar@imc.org
Subject: RE: MIME Multiple body parts = (Was Re:=20 uid...)


Outlook did not=20 do a complete implementation so should not be used as a = standard.=20

Your  second case if = very=20 complicated and needs careful thought so that the export/import = completely=20 captures and restores the calendar store.  I have deferred using=20 iCalendar to implement export/import into my product at this = time.=20



"Shannon = J. Clark"=20 <shannon=20

11/08/2001 06:06 PM =

    =    =20
      =   To:=20        "Robert Ransdell/Iris"=20 <tom_ransdell@iris.com>
        cc:      =20  
    =  =20   Subject:        RE: MIME Multiple = body parts=20 (Was Re: uid...)=20



Robert,
 
I agree - what I am looking at is whether it is clearly = spelled out in=20 the various standards documents that supporting these cases (and = others) is a=20 MUST requirement for interoperability.
 =20
At present I believe that Outlook, at = least in=20 some versions will not accept or deal with importing or receiving an = iCalendar=20 attachment or file that has multiple vEvents - it claims "invalid file = format"=20 in that situation.
 
I am also VERY interested in the use case of using iCalendar = to dump to=20 an interchange format an entire calendar for a given user - in this = case the=20 resulting vCalendar will contain MANY vEVENT, vTODO, vTIMEZONE = objects.=20
 
Shannon
 
(can I share our conversation with the rest of the working=20 group?)
 
 
-----Original=20 Message-----
From: Robert_Ransdell/Westford/IBM%IRIS%LOTUS=20 [mailto:Robert_Ransdell/Westford/IBM%IRIS%LOTUS@lotus.com]On Behalf = Of=20 Robert Ransdell/Iris
Sent: Thursday, November 08, 2001 = 5:11=20 PM
To: shannon@jigzaw.com
Subject: RE: MIME = Multiple body=20 parts (Was Re: uid...)


There=20 are at least two cases for multiple vEvents. =
1. Simple case of a show.  The = multiple=20 VEVENTS show all the possible events at the show.=20
2. Now for the more = complicated case.=20  When you invite a new person to an already scheduled repeating = meeting.=20  If any of the individual dates have been modified, the easiest = way to=20 show this is to send the original meeting request with additional = events to=20 show changed items such as attendee, description, etc.=20

"Shannon=20 J. Clark" <shannon
Sent by:=20 owner-ietf-calendar@mail.imc.org

11/08/2001 05:20 = PM=20

   =20    
  =  =20    To:        "John Stracke"=20 <jstracke@incentivesystems.com>,=20 <ietf-calendar@imc.org>
       cc: =    =20    (bcc: Robert Ransdell/Westford/IBM)=20
      =  Subject:        RE: MIME Multiple body = parts=20 (Was Re: uid...)





John,

Thanks - helps clarify = matters.

Something=20 else I realized -

There is a common trend to associate ONE MIME = object=20 holding an iCalendar
object with ONE vEVENT (and perhaps a = vTimezone=20 object). In fact I think
some vendors may ONLY deal with iCalendar = objects=20 that contain only one
vEVENT.

However it is clearly valid to = have a=20 vCalendar with multiple vEVENT objects
(or else what are we doing=20 here???)

How would you encode a iCalendar object holding = multiple=20 vEVENTS that were
in DIFFERENT languages (and required DIFFERENT = character=20 encodings - say a
calendar with meetings in Tokyo and Singapore - = requiring=20 Japanese and
Chinese character encodings...)?

In general how = are=20 "full calendar" objects intended to be handled - much of
the = standards we=20 are writing seem to treat individual events as the primary
unit for = work -=20 associating with them perhaps a vTimezone object, but other
objects = such as=20 vTODO or even multiple vEVENT objects seem to be perhaps
more = complex to=20 deal with?

For that matter should it be possible to send = multiple=20 vCalendar objects?

thanks,

Shannon

-----Original=20 Message-----
From:=20 = owner-ietf-calendar@mail.imc.org
[mailto:owner-ietf-calendar@mail.imc.= org]On=20 Behalf Of John Stracke
Sent: Thursday, November 08, 2001 3:03 = PM
To:=20 ietf-calendar@imc.org
Subject: RE: MIME Multiple body parts (Was = Re:=20 uid...)



>1 - are we discussing a MULTIPART composed = of=20 iCalendar related objects?
>(some encrypted, some not=20 perhaps?)

Only if we adopt Bruce's suggestion of having some = fields=20 encrypted and
others not (this could be done by the = multipart/alternative=20 approach I
mentioned).

>2 - are we discussing a MULTIPART = composed of a text or text/html object
+
>an iCalendar=20 object?

I think so.  For example, it will probably be = common to=20 send a
multipart/mixed containing a text/plain and an = text/calendar.=20  (Less
common, because it's broken, is the approach taken by = Microsoft=20 Entourage:
a multipart/alternative containing first the = text/calendar and=20 then the
text/html.  A recipient that understands text/html = will never=20 see the
text/calendar.)

>Also - if the iCalendar object = has say=20 an Attachment - are we considering
>allowing that ATTACHMENT to = be=20 bundled as part of the MULTIPART message,
>and/or for that = ATTACHMENT to=20 be encrypted in some manner?

Strictly speaking, it's permitted = by=20 RFC-2445; the ATTACH is specified by
a URL, so you can use a cid: = to=20 reference bodyparts.  Whether a CAP server
would deal with it = is=20 another question.

As a practical matter, sending an iMIP = message with a=20 cid: attachment is
probably risky.  It's easy for a = recipient's MUA to=20 take the text/calendar
and pass it off to the CUA for processing; = but=20 permitting the CUA to go
back to the MUA to resolve the cid: URL = requires=20 more integration.  It'd
be trivial for an app that combines = the CUA=20 and the MUA (e.g., Evolution,
Outlook, Notes), but not for = independent=20 = apps.

/=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\
|John=20 Stracke                   =  |Principal Engineer            =20 |
|jstracke@incentivesystems.com   |Incentive Systems, Inc. =  =20      |
|http://www.incentivesystems.com |My opinions = are my=20 own.      =20 =  |
|=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|
|"The=20 struggle is always worthwhile, if the end be worthwhile and|
|the = means=20 honorable; foreknowledge of defeat is not sufficient =  |
|reason to=20 withdraw from the contest." -- Adron e'Kieron, by     = |
|Steven=20 Brust                   =  =20                     =  =20        =20 =  |
\=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/




------=_NextPart_000_000E_01C1687C.0116F640-- From owner-ietf-calendar@mail.imc.org Thu Nov 8 19:03:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11715 for ; Thu, 8 Nov 2001 19:03:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8Nj5Y21401 for ietf-calendar-bks; Thu, 8 Nov 2001 15:45:05 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8Nj3821396 for ; Thu, 8 Nov 2001 15:45:03 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fA8NiVx05324 for ; Thu, 8 Nov 2001 15:44:33 -0800 (PST) Received: from netscape.com ([206.222.229.36]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMI9Y600.5XD; Thu, 8 Nov 2001 15:44:30 -0800 Message-ID: <3BEB18DE.9F679F89@netscape.com> Date: Thu, 08 Nov 2001 15:44:30 -0800 From: Steve Mansour Organization: Netscape X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" CC: John Stracke , ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) References: Content-Type: multipart/mixed; boundary="------------ACE1B05063A09D6EFFA2419C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ACE1B05063A09D6EFFA2419C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > There is a common trend to associate ONE MIME object holding an iCalendar > object with ONE vEVENT (and perhaps a vTimezone object). In fact I think > some vendors may ONLY deal with iCalendar objects that contain only one > vEVENT. > > However it is clearly valid to have a vCalendar with multiple vEVENT objects > (or else what are we doing here???) you'd think it would be clearly valid wouldnt you? Actually, there was a very persuasive group of folks that wanted text/calendar mime parts to only contain components with a single UID. And they won :-) Have a look at the restriction tables in iTIP. For VEVENTs, where the presence value is 1+, the text specifies that all components must have the same UID. > How would you encode a iCalendar object holding multiple vEVENTS that were > in DIFFERENT languages (and required DIFFERENT character encodings - say a > calendar with meetings in Tokyo and Singapore - requiring Japanese and > Chinese character encodings...)? While I am not a fan of limiting the iCalendar objects in iTIP to a specific UID, it does seem to mitigate this problem. I think it would be very unlikely to have a recurring event where different instances of the same event have different character encodings. > In general how are "full calendar" objects intended to be handled - much of > the standards we are writing seem to treat individual events as the primary > unit for work - associating with them perhaps a vTimezone object, but other > objects such as vTODO or even multiple vEVENT objects seem to be perhaps > more complex to deal with? iTIP doesn't handle this. CAP probably should. Any suggestions? Worst case, we require multiple sends. -Steve --------------ACE1B05063A09D6EFFA2419C Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:FALSE adr;dom;quoted-printable:;;501 East Middlefield Road=0D=0A;Mountain View;CA;94043; org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner tel;fax:(415) 428-4059 tel;work:(415) 937-2378 x-mozilla-cpt:;0 fn:Steve Mansour end:vcard --------------ACE1B05063A09D6EFFA2419C-- From owner-ietf-calendar@mail.imc.org Thu Nov 8 19:25:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11952 for ; Thu, 8 Nov 2001 19:25:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA906Fq21798 for ietf-calendar-bks; Thu, 8 Nov 2001 16:06:15 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA906D821794 for ; Thu, 8 Nov 2001 16:06:13 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA05114; Thu, 8 Nov 2001 18:04:43 -0600 From: "Shannon J. Clark" To: "Steve Mansour" Cc: "John Stracke" , Subject: RE: MIME Multiple body parts (Was Re: uid...) Date: Thu, 8 Nov 2001 18:06:05 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3BEB18DE.9F679F89@netscape.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve, This does explain something - I have spent the least time looking over iTIP so I had missed that section - but it is a clear indication of the different viewpoints on what use is intended for iCalendar objects. Simple and VERY common use case I have a question about: Calendar User Agent connects to Calendar Store for the FIRST TIME. Use case is - How does the CUA obtain the full calendar for that USER from the Calendar store? "multiple sends" - seems like a very ugly solution. I believe this is an EXACT use case from our documents - it is implied that Calendar User Agents will maintain a LOCAL Calendar Store - to me at least this implies a means to obtain the FULL calendar for that user from the remote store to a local store. thanks, Shannon -----Original Message----- From: Steve Mansour [mailto:sman@netscape.com] Sent: Thursday, November 08, 2001 5:45 PM To: Shannon J. Clark Cc: John Stracke; ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) "Shannon J. Clark" wrote: > > There is a common trend to associate ONE MIME object holding an iCalendar > object with ONE vEVENT (and perhaps a vTimezone object). In fact I think > some vendors may ONLY deal with iCalendar objects that contain only one > vEVENT. > > However it is clearly valid to have a vCalendar with multiple vEVENT objects > (or else what are we doing here???) you'd think it would be clearly valid wouldnt you? Actually, there was a very persuasive group of folks that wanted text/calendar mime parts to only contain components with a single UID. And they won :-) Have a look at the restriction tables in iTIP. For VEVENTs, where the presence value is 1+, the text specifies that all components must have the same UID. > How would you encode a iCalendar object holding multiple vEVENTS that were > in DIFFERENT languages (and required DIFFERENT character encodings - say a > calendar with meetings in Tokyo and Singapore - requiring Japanese and > Chinese character encodings...)? While I am not a fan of limiting the iCalendar objects in iTIP to a specific UID, it does seem to mitigate this problem. I think it would be very unlikely to have a recurring event where different instances of the same event have different character encodings. > In general how are "full calendar" objects intended to be handled - much of > the standards we are writing seem to treat individual events as the primary > unit for work - associating with them perhaps a vTimezone object, but other > objects such as vTODO or even multiple vEVENT objects seem to be perhaps > more complex to deal with? iTIP doesn't handle this. CAP probably should. Any suggestions? Worst case, we require multiple sends. -Steve From owner-ietf-calendar@mail.imc.org Fri Nov 9 09:32:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12091 for ; Fri, 9 Nov 2001 09:32:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9EE5M17319 for ietf-calendar-bks; Fri, 9 Nov 2001 06:14:05 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9EE4817315 for ; Fri, 9 Nov 2001 06:14:04 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA00908; Fri Nov 9 09:11:54 2001 Subject: RE: MIME Multiple body parts (Was Re: uid...) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 09:16:26 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 09:16:27 AM, Serialize complete at 11/09/2001 09:16:27 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >How would you encode a iCalendar object holding multiple vEVENTS that were >in DIFFERENT languages You have that problem even without multiple VEVENTs. For example, if one attendee's name is, say, Portugese, and another is Japanese. If they're going to have a meeting, they may well be able to speak each other's languages, so the organizer may want to express both names correctly, rather than giving the Romanization of the Japanese name. This can even come up within a single person's name. Consider a person living in Mexico (where both parents' surnames are used), whose father is Mexican and whose mother is Japanese. Spelling their name *correctly* may require characters from two different national character sets. The solution, of course, is Unicode. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |"The Elliot 903 was the first portable I ever used, though it| |needed a furniture van to *make* it portable." --Will Rose | \=============================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 12:04:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18598 for ; Fri, 9 Nov 2001 12:04:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9Gjh329440 for ietf-calendar-bks; Fri, 9 Nov 2001 08:45:43 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9Gjf829436 for ; Fri, 9 Nov 2001 08:45:41 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id KAA05853; Fri, 9 Nov 2001 10:43:57 -0600 From: "Shannon J. Clark" To: "John Stracke" , Subject: RE: MIME Multiple body parts (Was Re: uid...) Date: Fri, 9 Nov 2001 10:45:36 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, Unicode is a solution - but may have difficulties for certain Asian languages, specifically there appear to be commonly used Japanese character sets that are not in UTF8. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Friday, November 09, 2001 8:16 AM To: ietf-calendar@imc.org Subject: RE: MIME Multiple body parts (Was Re: uid...) >How would you encode a iCalendar object holding multiple vEVENTS that were >in DIFFERENT languages You have that problem even without multiple VEVENTs. For example, if one attendee's name is, say, Portugese, and another is Japanese. If they're going to have a meeting, they may well be able to speak each other's languages, so the organizer may want to express both names correctly, rather than giving the Romanization of the Japanese name. This can even come up within a single person's name. Consider a person living in Mexico (where both parents' surnames are used), whose father is Mexican and whose mother is Japanese. Spelling their name *correctly* may require characters from two different national character sets. The solution, of course, is Unicode. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |"The Elliot 903 was the first portable I ever used, though it| |needed a furniture van to *make* it portable." --Will Rose | \=============================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 12:16:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19290 for ; Fri, 9 Nov 2001 12:16:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9GrCc29655 for ietf-calendar-bks; Fri, 9 Nov 2001 08:53:12 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9GrB829651 for ; Fri, 9 Nov 2001 08:53:11 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id LAA21386; Fri Nov 9 11:51:00 2001 Subject: RE: MIME Multiple body parts (Was Re: uid...) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 11:55:31 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 11:55:33 AM, Serialize complete at 11/09/2001 11:55:33 AM Content-Type: text/plain; charset="us-ascii" To: "Shannon J. Clark" From: "John Stracke" Cc: ietf-calendar@imc.org Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Unicode is a solution - but may have difficulties for certain Asian >languages, specifically there appear to be commonly used Japanese character >sets that are not in UTF8. There is nothing in Unicode that is not in UTF-8. That's what "transformation format" means. See RFC-2279. Unicode has had difficulties with some Asian languages in the past (the whole "Han unification" mess), but I believe that was fixed this year. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |This is the .sig that says... Ni! | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 14:15:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24191 for ; Fri, 9 Nov 2001 14:15:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9IlVE06559 for ietf-calendar-bks; Fri, 9 Nov 2001 10:47:31 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9IlQ806553 for ; Fri, 9 Nov 2001 10:47:27 -0800 (PST) To: ietf-calendar@imc.org Subject: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 9 Nov 2001 13:46:47 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/09/2001 01:47:05 PM, Serialize complete at 11/09/2001 01:47:05 PM Content-Type: multipart/alternative; boundary="=_alternative 00673B9885256AFF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00673B9885256AFF_= Content-Type: text/plain; charset="us-ascii" I would suggest that members of this list review this draft to see if it helps/conflicts with any of our work. ----- Forwarded by Pat R Egen/Egen Consulting/01 on 11/09/01 13:44 ----- The IESG Sent by: scoya@cnri.reston.va.us 11/09/01 11:57 Please respond to iesg To: IETF-Announce: ; cc: impp@iastate.edu Subject: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard The IESG has received a request from the Instant Messaging and Presence Protocol Working Group to consider Date and Time on the Internet: Timestamps as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 23, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-05.txt --=_alternative 00673B9885256AFF_= Content-Type: text/html; charset="us-ascii"
I would suggest that members of this list review this draft to see if it helps/conflicts with any of our work.

----- Forwarded by Pat R Egen/Egen Consulting/01 on 11/09/01 13:44 -----
The IESG <iesg-secretary@ietf.org>
Sent by: scoya@cnri.reston.va.us

11/09/01 11:57
Please respond to iesg

       
        To:        IETF-Announce: ;
        cc:        impp@iastate.edu
        Subject:        Last Call: Date and Time on the Internet: Timestamps to Proposed Standard




The IESG has received a request from the Instant Messaging and Presence
Protocol Working Group to consider Date and Time on the Internet:
Timestamps <draft-ietf-impp-datetime-05.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by November 23, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-05.txt
--=_alternative 00673B9885256AFF_=-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:17:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28620 for ; Fri, 9 Nov 2001 17:17:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1Rx14840 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:27 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1Q814836 for ; Fri, 9 Nov 2001 14:01:26 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13146 for ; Fri, 9 Nov 2001 14:01:27 -0800 (PST) Message-ID: <3BEC3116.73BB5FCA@Royer.com> Date: Fri, 09 Nov 2001 12:40:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: autologout disconnect notification Content-Type: multipart/mixed; boundary="------------AF76B03CF31A99943ECA9462" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AF76B03CF31A99943ECA9462 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - Have a notification for the timeout of an idle connection > see post "CAP: autologout" Why? Any OS that I have seen the CUA can register for 'tell me when the other end went away'. Lets keep the hang up wait burden on the CUA and not the CS. If the connection drops, what would the CS do - wait until the connection came back to say - 'I am hanging up on you"? When the CUA noticed the connection went away, the CUA can attempt to re-establish the connection. I say if the client is not sending data (for what ever reason), then the CS MAY disconnect when the idle time is reached. Or if it is notified by the CS's OS that the CUA has hung up. Only the CUA knows if it cares to keep the connection alive. And if the connection is not working for whatever reason - let the CS close its session with that CUA. -Doug --------------AF76B03CF31A99943ECA9462 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------AF76B03CF31A99943ECA9462-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:17:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28633 for ; Fri, 9 Nov 2001 17:17:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9M1Gc14823 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:16 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1F814818 for ; Fri, 9 Nov 2001 14:01:15 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13137 for ; Fri, 9 Nov 2001 14:01:16 -0800 (PST) Message-ID: <3BEC30E7.9CF7BF99@Royer.com> Date: Fri, 09 Nov 2001 12:39:19 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: UID Content-Type: multipart/mixed; boundary="------------8BBC22598547555AB2E32928" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8BBC22598547555AB2E32928 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - Do we want/need the CAP server to auto-mangle (aka autoinsert) an > incoming stream of data with a generated UID? Especially if > 1 > operation is going to be needed (ie: "Put this on my calendar and > send invitations to the ATTENDEEs" = 1 CREATE and 1 or more > other operations). Wouldn't it be simpler and more efficient to have the > client request a UID and have the CAP server generate and return it ala > NNTP does with Message-IDs)?? > > Besides, the client will _probably_ need to have the UID for other > operations (like saving in its local store if is does sync work!). > (from Bruce) I assume this is one is dead - as in client does use GENERATEUID and that's the way it is. -Doug --------------8BBC22598547555AB2E32928 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------8BBC22598547555AB2E32928-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:20:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28710 for ; Fri, 9 Nov 2001 17:20:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1pR14904 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:51 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1o814900 for ; Fri, 9 Nov 2001 14:01:50 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13178 for ; Fri, 9 Nov 2001 14:01:51 -0800 (PST) Message-ID: <3BEC36D9.5E681544@Royer.com> Date: Fri, 09 Nov 2001 13:04:41 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: mimium componet properties Content-Type: multipart/mixed; boundary="------------7AC1181B4F982425858252AC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7AC1181B4F982425858252AC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - What are the minimum component properties set required to > create a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, > SUMMARY and UID. I think this is already done in CAP? -Doug --------------7AC1181B4F982425858252AC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------7AC1181B4F982425858252AC-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:20:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28735 for ; Fri, 9 Nov 2001 17:20:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9M1eP14870 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:40 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1c814866 for ; Fri, 9 Nov 2001 14:01:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13162 for ; Fri, 9 Nov 2001 14:01:40 -0800 (PST) Message-ID: <3BEC324A.DBAB9FD0@Royer.com> Date: Fri, 09 Nov 2001 12:45:14 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: Stored queries. Content-Type: multipart/mixed; boundary="------------89F29D8B540FCDBF9EAA5546" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------89F29D8B540FCDBF9EAA5546 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - make stored VQUERYs optional? > see thread: "CAP: stored queries" First I assume you mean 'MAY' and not 'optional'. SQL-MIN are stored queries as they are called by name. So they MUST be implemented. This was a BIG BIG BIG issue in the WG. All others are a MAY. -Doug --------------89F29D8B540FCDBF9EAA5546 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------89F29D8B540FCDBF9EAA5546-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:22:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28813 for ; Fri, 9 Nov 2001 17:22:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1XA14852 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:33 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1W814848 for ; Fri, 9 Nov 2001 14:01:32 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13154 for ; Fri, 9 Nov 2001 14:01:33 -0800 (PST) Message-ID: <3BEC314A.34086AC0@Royer.com> Date: Fri, 09 Nov 2001 12:40:58 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: MITM Content-Type: multipart/mixed; boundary="------------1C3F2CAE1A848C9171C30C7E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1C3F2CAE1A848C9171C30C7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - Danger of MITM attacks with weak authentication? > see post: "CAP: SASL mechanisms and MITM attacks" We mandate that DIGEST be implemented. Is that subject to MITM attacks - I don't think so. If a CUA/CS decide on a weak authentication - that is out of scope for CAP. We might want to in the security section point out why doing weak authentication is stupid and don't do that. CAP is not designing security. We are using already designed security - I don't think we picked a bad one. -Doug --------------1C3F2CAE1A848C9171C30C7E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------1C3F2CAE1A848C9171C30C7E-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:22:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28844 for ; Fri, 9 Nov 2001 17:22:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9M1DK14816 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:13 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1C814812 for ; Fri, 9 Nov 2001 14:01:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13133 for ; Fri, 9 Nov 2001 14:01:12 -0800 (PST) Message-ID: <3BEC30AD.E7F5437E@Royer.com> Date: Fri, 09 Nov 2001 12:38:21 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO - CRISP Content-Type: multipart/mixed; boundary="------------4BE4158121EC0DE458DC6AFD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4BE4158121EC0DE458DC6AFD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - Look at changes required by CAP to make it compatible with CRISP > (If we want to support CRISP, then some changes are needed in CAP. In > section 7.1.5, CAPVERSION, CAR, and QUERYLEVEL all need to be able to > have values of NONE.) Why MUST these be NONE? Why can't a CRISP server send out a CAPABILITY of CRISP, and if a client wishes to only use CRISP services, then that's all it uses. If a server is a CAP server, then it MUST be able to have a CAPVERSION, VCAR, and SQL-MIN. Otherwise, there is no minimum implementation for a CAP server (it would be a CRISP server). -Doug --------------4BE4158121EC0DE458DC6AFD Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------4BE4158121EC0DE458DC6AFD-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:23:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28858 for ; Fri, 9 Nov 2001 17:23:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1mn14897 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:48 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1l814893 for ; Fri, 9 Nov 2001 14:01:47 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13174 for ; Fri, 9 Nov 2001 14:01:49 -0800 (PST) Message-ID: <3BEC3678.F9E424E7@Royer.com> Date: Fri, 09 Nov 2001 13:03:04 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP DODO: VQUERY - partial access Content-Type: multipart/mixed; boundary="------------DB73991EBDBF34DC2BAA8B50" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DB73991EBDBF34DC2BAA8B50 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - VQUERY: if the user does not have access to some, but not > all of properties that were specified > should the acessible properties be returned along with an error code This is already described in CAP. They do not return the properties that the UPN does not have access to. If you ask for ATTENDEEs and you don't have permission, the results are returned without the ATTENDEE property: If you send: BEGIN:VQUERY QUERY:SELECT DTSTART,DTEND,ATTENDEE FROM VEVENT WHERE UID="123" END:VQUERY and get back: BEGIN:VCALENDAR DTSTART: DTEND: END:VCALENDAR Is a valid reply that means you have access to the calendar, but not all the properties you requested. (It could return and empty set with nothing between the BEGIN/END. -Doug --------------DB73991EBDBF34DC2BAA8B50 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------DB73991EBDBF34DC2BAA8B50-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:23:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28860 for ; Fri, 9 Nov 2001 17:23:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1sq14916 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:54 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1r814912 for ; Fri, 9 Nov 2001 14:01:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13182 for ; Fri, 9 Nov 2001 14:01:54 -0800 (PST) Message-ID: <3BEC373B.7B2F3D90@Royer.com> Date: Fri, 09 Nov 2001 13:06:19 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: undefined properties Content-Type: multipart/mixed; boundary="------------AB37B4B88A25A871135FEAA5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AB37B4B88A25A871135FEAA5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >- What is the state of all undefined properties? PROPOSAL: > Not defined. So a query will not return them, if they are > selected. Do you mean experimental (x-) properties? If you ask for them you get them. If you ask for all you get them If you don't ask for them, you don't get them. -Doug --------------AB37B4B88A25A871135FEAA5 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------AB37B4B88A25A871135FEAA5-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:23:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28880 for ; Fri, 9 Nov 2001 17:23:42 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1jV14884 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:45 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1i814880 for ; Fri, 9 Nov 2001 14:01:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13170 for ; Fri, 9 Nov 2001 14:01:46 -0800 (PST) Message-ID: <3BEC3325.BA29B826@Royer.com> Date: Fri, 09 Nov 2001 12:48:53 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: NOOP - from authenticated. Content-Type: multipart/mixed; boundary="------------7E08D53C4AB3C7DCFCB53EA0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7E08D53C4AB3C7DCFCB53EA0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - NOOP: should an unauthenticated and unidentified client > be able to issue this command? I say - NO. Else they can defeat various security login idle timeouts. If you don't know your account and password when the command is sent - hang up on them. -Doug --------------7E08D53C4AB3C7DCFCB53EA0 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------7E08D53C4AB3C7DCFCB53EA0-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:24:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28910 for ; Fri, 9 Nov 2001 17:24:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1JK14828 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:19 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1H814824 for ; Fri, 9 Nov 2001 14:01:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13129 for ; Fri, 9 Nov 2001 14:01:08 -0800 (PST) Message-ID: <3BEC3090.7B2AA267@Royer.com> Date: Fri, 09 Nov 2001 12:37:52 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: disconnect Content-Type: multipart/mixed; boundary="------------91EFB78CEB5667D79820C304" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------91EFB78CEB5667D79820C304 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - DISCONNECT: should the client now wait for a response > from the server before disconnecting? YES!! For two reasons: 1) To make sure the CS got the request. 2) To keep the CS from hanging open that connection for a while in TCP-WAIT state when: CUA: sends - goodbye CS: sends - goodbye reply CUA: physical hang-up before it gets the CS reply. CS: TCP waiting for the ill-mannered CUA's TCP stack to say 'got message' This was discussed in a SMTP IETF meeting. It can cause the server side to hang for a while in TCP-WAIT state while the TCP stack determines if the connection died or is just slow. SPANNERS loved the fact you could fire off junk to an smtp-server and disconnect without waiting for the spam target system to reply, sometimes resulting in possibly a HUGE NUMBER of sessions hung for a couple of minutes while the TCP-stack determining if they hung up or are slow. I think that on most Unix systems the default is a 2 minute wait per connection. -Doug --------------91EFB78CEB5667D79820C304 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------91EFB78CEB5667D79820C304-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:25:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28943 for ; Fri, 9 Nov 2001 17:25:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1LN14834 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:21 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1K814830 for ; Fri, 9 Nov 2001 14:01:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13141 for ; Fri, 9 Nov 2001 14:01:20 -0800 (PST) Message-ID: <3BEC3104.AF69F206@Royer.com> Date: Fri, 09 Nov 2001 12:39:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: Digest Content-Type: multipart/mixed; boundary="------------69D43E7235853990EA64E792" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------69D43E7235853990EA64E792 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - 2.4.2.3 Required Security Mechanisms > The following implementation conformance requirements are in place: > > [deletia...] > > (2) Implementations providing password-based authenticated > access MUST support authentication using Digest, as described > in section > > What section discusses authentication using Digest? I did a > quick search on "Digest" and didn't see anything that looked > like what was being referred to. Can you confirm > whether or not the section it's referring to is either in or > not in the latest draft? Is this issue going away - BXXP? If not, we need our security expert (Paul?) to add this text. -Doug --------------69D43E7235853990EA64E792 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------69D43E7235853990EA64E792-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:25:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28960 for ; Fri, 9 Nov 2001 17:25:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9M1hq14878 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:43 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1f814874 for ; Fri, 9 Nov 2001 14:01:41 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13166 for ; Fri, 9 Nov 2001 14:01:43 -0800 (PST) Message-ID: <3BEC328B.8BE8F472@Royer.com> Date: Fri, 09 Nov 2001 12:46:19 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: decreed VCARS Content-Type: multipart/mixed; boundary="------------AF7C4EBBA648A9999F4C7D93" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AF7C4EBBA648A9999F4C7D93 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - have decreed VCARS? If yes, need to make some changes to VCARS > in order to allow Decreed VCARS to be indentifiable Yes. The reasoning is that certain implementation have inherent access issues. For example, you can never deny the owner of a calendar - from access. This could be a named VCAR, or just a hard coded (decreed) VCAR. Other implementations may have other mandated requirements. Ex: Only people in my implementation specific 'manager list' have access to 'managers calendar'. And ALL VCARs are nameable - via CARID. But as all decreed VCARs are 'persistent immutable' (see 2.4.4), they would not need to be named in advance. And also because various implementations may have various hard coded immutable VCARs. So - they are needed. No - not necessarily named, could be hard coded in the code. We could recommend some - in examples. Else they would be a MAY - and that means that at least 2 implementations MUST support that feature - or no-no to standard. And they are in examples :-) -Doug --------------AF7C4EBBA648A9999F4C7D93 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------AF7C4EBBA648A9999F4C7D93-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:27:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29000 for ; Fri, 9 Nov 2001 17:27:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9M1U214846 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:30 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1T814842 for ; Fri, 9 Nov 2001 14:01:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13150 for ; Fri, 9 Nov 2001 14:01:30 -0800 (PST) Message-ID: <3BEC3127.2560401D@Royer.com> Date: Fri, 09 Nov 2001 12:40:23 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: single threaded Content-Type: multipart/mixed; boundary="------------B1BA894CFC942E851E17C75B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B1BA894CFC942E851E17C75B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - Problems with a single threaded server? > If yes, then will need to change some things. > See post "CAP: Bounded latency" (1) What do you mean by 'single threaded'? Do you mean OS threads? If so - I don't know of any issues. (2) If you mean overlapped requests - as in ask for one item, then before it replies, ask for another? And the replies can come out of order? This was a debate with another name a couple of years ago. (a) Given the connection is TCP. (b) If the CUA DOES support overlapped requests, and the CS DOES NOT support overlapped requests: The CS that does not support multiple overlapped requests simply does not have to read the pipe until it has sent the reply to the pending request. Any CUA that had hopped for (and sent) overlapped requests will simply see the replies in the same order as requested. (b.1) If the CS does read multiple requests, but does not support out of order replies - then it sends the replies in order. And the CUA sees them in order. (c) If a CUA DOES NOT support overlapped requests - it will not send them and the CS will process any requests in order. If the CUA DOES NOT support overlapped requests it MUST NOT send more than one without waiting for the CS to reply and it will never get out of order replies. If the CUA did send multiple - then it is telling the CS it supports multiple. (d) If both the CUA and the CS support overlapped requests: The request and replies are tagged with the TARGET and CMDID. So: If the multiple requests are to the SAME TARGET, the CS MUST process those to the same TARGET in order. For all requests that have unique TARGETS, process them in any order and reply to them in any order. If the CUA can not handle that, it would not have sent that. As far as the bounded latency time issues: (e) Bound latency is independent of overlapped requests. (f) If you ask for bounded requests - you better be able to handle them. (g) If you ask for overlapped requests with bound latency, then you better be able to handle them. Each command has a CMDID to identify the replies for overlapped requests. Each bound latency request was initiated by the CUA. The CUA MUST NOT send a request where it can not support the reply for any such request. I don't think that any of this is unique to CAP, it would be true if any wire protocol. But perhaps if it is confusing we should add these instructions to implementors? -Doug --------------B1BA894CFC942E851E17C75B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------B1BA894CFC942E851E17C75B-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 17:27:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29016 for ; Fri, 9 Nov 2001 17:27:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9M1b614863 for ietf-calendar-bks; Fri, 9 Nov 2001 14:01:37 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9M1Z814856 for ; Fri, 9 Nov 2001 14:01:35 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13158 for ; Fri, 9 Nov 2001 14:01:37 -0800 (PST) Message-ID: <3BEC322E.2993C455@Royer.com> Date: Fri, 09 Nov 2001 12:44:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP TODO: anonymous MUST Content-Type: multipart/mixed; boundary="------------30F6AD4280B9F97F5701A85A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------30F6AD4280B9F97F5701A85A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > - Is anonymous authentication a MUST? > see post: "CAP: MUST anonymous auth?" It is a MUST - however a CS administrator MAY elect not to allow any such authentications. However I would think that is an administrative policy. The reason it is a MUST for all implementations is so the name 'anonymous' and the mechanism described for anonymous is reserved to ONLY mean what CAP says it means. It is needed only by sites that allows public or named-domain-public anonymous self-invitations. Samples: Base ball games - where you invite yourself by buying a ticket and select (schedule) a seat. They really don't care who you are as long as your credit card worked. Notification of events on a public (or at at least accessible to you) calendar - by anyone that can connect and wants an iCal object for: Season game times Favorite event times Sunset / sunrise times ... When you really don't care who -Doug --------------30F6AD4280B9F97F5701A85A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------30F6AD4280B9F97F5701A85A-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:04:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29631 for ; Fri, 9 Nov 2001 18:04:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9MiEm16546 for ietf-calendar-bks; Fri, 9 Nov 2001 14:44:14 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9MiC816542 for ; Fri, 9 Nov 2001 14:44:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13889 for ; Fri, 9 Nov 2001 14:44:14 -0800 (PST) Message-ID: <3BEC56EF.1F472F44@Royer.com> Date: Fri, 09 Nov 2001 15:21:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Doug, > > Just a thought along these lines: > > 1 - are we discussing a MULTIPART composed of iCalendar related objects? > (some encrypted, some not perhaps?) YES > or > > 2 - are we discussing a MULTIPART composed of a text or text/html object + > an iCalendar object? AND YES > Also - if the iCalendar object has say an Attachment - are we considering > allowing that ATTACHMENT to be bundled as part of the MULTIPART message, > and/or for that ATTACHMENT to be encrypted in some manner? > > Shannon We allow attachments (AKA body parts) because we allow CID's and MID's as URL's in the vCalendar object. That means that one MIME message as MULTIPART/RELATED can have N-number of body parts, one of which is the vCalendar object (text/calendar). A CID is a CONTENT-ID, and means that one URL in the text/calendar body part refers to the contents of another body part in the same MIME message. Example: URL:cid:body-part-2 (note: I may not have correctly shown a CID or MID url, but you'll get the idea). A MID is a MESSAGE-ID to a MIME body part. That means that a text/calendar body part can refer to any body part in any other MIME message. Example: URL:mid:royer.com/~doug/message-3/body-part-3 Also, the WG agreed that MULTIPART/ALTERNATE was expected to be allowed. (one part text/calendar, others any other representation of the object text/plain, text/html, ...). Example: MIME-header ... MULTIPART/ALTERNATE BEGIN:VCALENDAR ... END:VCALENDAR You have been invited to a party Starts at: .... Ends at: ... ... This DOES NOT mean that a CUA or a CS MUST implement the code to process these. It mean that we agreed not to limit ourselves and allow CID/MID's. NOTE: MULTIPART/ may be combined/mixed and contain other MULTIPART/ Again we are not mandating that a CUA or CS MUST do this, we are simply not restricting them from using all of MIME. -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:05:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29645 for ; Fri, 9 Nov 2001 18:05:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9MiO616560 for ietf-calendar-bks; Fri, 9 Nov 2001 14:44:24 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9MiM816556 for ; Fri, 9 Nov 2001 14:44:22 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA16525; Fri Nov 9 17:42:14 2001 Subject: Re: CAP TODO: autologout disconnect notification MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 17:46:46 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 05:46:48 PM, Serialize complete at 11/09/2001 05:46:48 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I say if the client is not sending data (for what ever reason), >then the CS MAY disconnect when the idle time is reached. I agree. Note that this does not put any extra burden on the CUA, since the CUA must *always* be able to cope with the CS dropping the connection unexpectedly. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Amazing Fact: If there are three cats in a room, they will form a| |triangle! | \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:08:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29709 for ; Fri, 9 Nov 2001 18:08:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9MnL216854 for ietf-calendar-bks; Fri, 9 Nov 2001 14:49:21 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9MnK816850 for ; Fri, 9 Nov 2001 14:49:20 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA17036; Fri Nov 9 17:47:11 2001 Subject: Re: CAP TODO: disconnect MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 17:51:43 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 05:51:46 PM, Serialize complete at 11/09/2001 05:51:46 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I think that on most Unix systems the default is a 2 minute >wait per connection. Yes. This is a big problem with HTTP/1.0: normally, the server is the one to close the connection, so a busy server gets stuck with lots and lots of TIME_WAIT sockets, each taking up a slot in the socket table. As of about 1996, most kernels defaulted to something like 2000 sockets; they could be configured for more, but some did linear searches, which meant serious pain. That's part of why, in HTTP/1.1, persistent connections are the default. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Amazing Fact: If there are three cats in a room, they will form a| |triangle! | \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:14:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29919 for ; Fri, 9 Nov 2001 18:14:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9Mp5W16970 for ietf-calendar-bks; Fri, 9 Nov 2001 14:51:05 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9Mp4816966 for ; Fri, 9 Nov 2001 14:51:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13978 for ; Fri, 9 Nov 2001 14:51:05 -0800 (PST) Message-ID: <3BEC588A.6F51B4F7@Royer.com> Date: Fri, 09 Nov 2001 15:28:26 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) References: Content-Type: multipart/mixed; boundary="------------0EC17D9FB21B9D5F95C32C7C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0EC17D9FB21B9D5F95C32C7C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >1 - are we discussing a MULTIPART composed of iCalendar related objects? > >(some encrypted, some not perhaps?) > > Only if we adopt Bruce's suggestion of having some fields encrypted and > others not (this could be done by the multipart/alternative approach I > mentioned). Currently multipart/related objects could be encrypted, but they would not be text/calendar. > >Also - if the iCalendar object has say an Attachment - are we considering > >allowing that ATTACHMENT to be bundled as part of the MULTIPART message, > >and/or for that ATTACHMENT to be encrypted in some manner? > > Strictly speaking, it's permitted by RFC-2445; the ATTACH is specified by > a URL, so you can use a cid: to reference bodyparts. Whether a CAP server > would deal with it is another question. > > As a practical matter, sending an iMIP message with a cid: attachment is > probably risky. Yes - now. But we should encourage implementors to understand all of MIME and not limit themselves. > It's easy for a recipient's MUA to take the text/calendar > and pass it off to the CUA for processing; but permitting the CUA to go > back to the MUA to resolve the cid: URL requires more integration. It'd > be trivial for an app that combines the CUA and the MUA (e.g., Evolution, > Outlook, Notes), but not for independent apps. They just need to forward the entire MIME message if they don't look inside. We also did not limit them to CID/MID. Any including (but not limited to) ftp, imap, file, ... URL schemes could be used. -Doug --------------0EC17D9FB21B9D5F95C32C7C Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------0EC17D9FB21B9D5F95C32C7C-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:15:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29956 for ; Fri, 9 Nov 2001 18:15:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9MsNP17065 for ietf-calendar-bks; Fri, 9 Nov 2001 14:54:23 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9MsM817060 for ; Fri, 9 Nov 2001 14:54:22 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA14055 for ; Fri, 9 Nov 2001 14:54:23 -0800 (PST) Message-ID: <3BEC5950.4F77CE50@Royer.com> Date: Fri, 09 Nov 2001 15:31:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) References: Content-Type: multipart/mixed; boundary="------------883B98FC30F98B88A09B3AAC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------883B98FC30F98B88A09B3AAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > How would you encode a iCalendar object holding multiple vEVENTS that were > in DIFFERENT languages (and required DIFFERENT character encodings - say a > calendar with meetings in Tokyo and Singapore - requiring Japanese and > Chinese character encodings...)? Each in their own body part. Each with the "lang" and "charset" values set for their body part. > In general how are "full calendar" objects intended to be handled - much of > the standards we are writing seem to treat individual events as the primary > unit for work - associating with them perhaps a vTimezone object, but other > objects such as vTODO or even multiple vEVENT objects seem to be perhaps > more complex to deal with? YES! > For that matter should it be possible to send multiple vCalendar objects? Yes, you can do it in one body part: BEGIN:VCALENDER ... END:VCALENDAR BEGIN:VCALENDER ... END:VCALENDAR Or each in a separate body part. -Doug --------------883B98FC30F98B88A09B3AAC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------883B98FC30F98B88A09B3AAC-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:20:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00053 for ; Fri, 9 Nov 2001 18:20:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9MsoZ17087 for ietf-calendar-bks; Fri, 9 Nov 2001 14:54:50 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9Msn817083 for ; Fri, 9 Nov 2001 14:54:49 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA17362; Fri Nov 9 17:52:41 2001 Subject: Re: CAP TODO - CRISP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 17:57:14 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 05:57:16 PM, Serialize complete at 11/09/2001 05:57:16 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> section 7.1.5, CAPVERSION, CAR, and QUERYLEVEL all need to be able to >> have values of NONE.) > >Why MUST these be NONE? > >Why can't a CRISP server send out a CAPABILITY of CRISP, Mmm, that's an option. However, I think I'd rather make it explicit to clients that they're not going to get CAR or QUERYLEVEL features. That way, if a CAP client accidentally gets configured to use a CRISP server, it will be told so clearly, even if it doesn't check the CRISP capability. Perhaps CAPVERSION could be "CRISP" and the other two could be "NONE", and we can specify that NONE is a legal value if, and only if, CAPVERSION is CRISP. How's that? /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Earth: love it or leave it. | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:20:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00069 for ; Fri, 9 Nov 2001 18:20:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9MtIZ17110 for ietf-calendar-bks; Fri, 9 Nov 2001 14:55:18 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9MtG817106 for ; Fri, 9 Nov 2001 14:55:16 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA17382; Fri Nov 9 17:53:08 2001 Subject: Re: CAP TODO: NOOP - from authenticated. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 17:57:41 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 05:57:43 PM, Serialize complete at 11/09/2001 05:57:43 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> - NOOP: should an unauthenticated and unidentified client >> be able to issue this command? > >I say - NO. > >Else they can defeat various security login idle timeouts. I agree. /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===========================================================| |A computer without Windows is like a chocolate cake without| |mustard. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:22:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00089 for ; Fri, 9 Nov 2001 18:22:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9MxHD17244 for ietf-calendar-bks; Fri, 9 Nov 2001 14:59:17 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9MxG817240 for ; Fri, 9 Nov 2001 14:59:16 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA17530; Fri Nov 9 17:56:53 2001 Subject: Re: CAP TODO: single threaded MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 18:01:26 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 06:01:27 PM, Serialize complete at 11/09/2001 06:01:27 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> - Problems with a single threaded server? >> If yes, then will need to change some things. >> See post "CAP: Bounded latency" > >(1) What do you mean by 'single threaded'? Do you mean OS threads? > If so - I don't know of any issues. The post referred to explains. Basically, bounded latency is usually not implementable in a single-threaded process (unless you start messing with alarm signals, and signals are the spawn of Satan), because the APIs used to access the backend database are typically blocking calls. If CAP requires the bounded-latency features, then it is mandating that servers be designed with multiple threads. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |"Time is money, and price is information." --Russ Nelson| \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:29:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00255 for ; Fri, 9 Nov 2001 18:29:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9N1fL17358 for ietf-calendar-bks; Fri, 9 Nov 2001 15:01:41 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9N1d817354 for ; Fri, 9 Nov 2001 15:01:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA14137 for ; Fri, 9 Nov 2001 15:01:41 -0800 (PST) Message-ID: <3BEC5B04.784110C7@Royer.com> Date: Fri, 09 Nov 2001 15:39:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) + iCalendar as data standard References: Content-Type: multipart/mixed; boundary="------------7E39DB69B787E8C395E64413" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7E39DB69B787E8C395E64413 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > "Shannon J. Clark" wrote: > I think that the point that using iCalendar to store a calendar store for a > specific user raises some very serious questions. > > IF iCalendar is a DATA standard - then why is it "very complicated" and > "needs careful thought" to use it to store an entire calendar for a given > user? iCalendar is complicated because that the nature of calendering and scheduling. Calendaring only is easy. CAP is storage and iCalendar can (and is) used with out iTIP and CAP. > It has always struck me as curious that within the iCalendar standard it is > not at all clear how to talk about a "USER" - i.e. how to talk about in a > logical manner "a user's calendar" That is because a user may be a program. So rather than say a person, we say a CU (calendar user). That is spelled out in iCalendar and CAP. > I think the differentiation between thinking of iCalendar as a means to > store data for ONE transaction - iCalendar CAN NOT STORE DATA - that's what CAP is for. iTIP can not store data. iMIP can not store data. > i.e. for one meeting, for one task vs. the > thinking of "Calendaring" in general and dealing with a user's > calendar is a major one - and one that we may need to address head on. iTIP is for scheduling - for which much was added to iCalendar to represent the scheduling. (and MUCH debate). > From: Robert_Ransdell@iris.com [mailto:Robert_Ransdell@iris.com]On > > I am also VERY interested in the use case of using iCalendar to > dump to an interchange format an entire calendar for a given user > - in this case the resulting vCalendar will contain MANY vEVENT, > vTODO, vTIMEZONE objects. It CAN do that now. -Doug --------------7E39DB69B787E8C395E64413 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------7E39DB69B787E8C395E64413-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:30:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00317 for ; Fri, 9 Nov 2001 18:30:40 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9N8WM17625 for ietf-calendar-bks; Fri, 9 Nov 2001 15:08:32 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9N8U817620 for ; Fri, 9 Nov 2001 15:08:30 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id SAA17787; Fri Nov 9 18:06:17 2001 Subject: Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 18:10:50 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 06:10:52 PM, Serialize complete at 11/09/2001 06:10:52 PM Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org From: "John Stracke" Cc: iesg@ietf.org, impp@iastate.edu, ietf-calendar@imc.org Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: >However, many events are actually specified relative to a particular >timezone, and timezone offsets occasionally change with little advance >warning. As such, this representation may not be sufficient for >specifying dates and times of some kinds of events, particularly >future events. This is correct. The IMPP group covered this in Minneapolis, I think. The draft alludes to the problem, but may not be explicit enough (probably isn't, if Keith felt it necessary to comment): o All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC). (This is distinct from some usage in scheduling applications where a local time and location may be known, but the actual relationship to UTC may be dependent on the unknown or unknowable actions of politicians or administrators. The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time. This specification steers well clear of such considerations.) I believe that Keith is right, that this paragraph should include a reference to iCalendar (RFC-2445) and point readers to that for use when a simple timestamp won't do. It's a small point, but it could prevent some confusion. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |"Time is money, and price is information." --Russ Nelson| \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:33:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00396 for ; Fri, 9 Nov 2001 18:33:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9NILB17982 for ietf-calendar-bks; Fri, 9 Nov 2001 15:18:21 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9NIJ817975 for ; Fri, 9 Nov 2001 15:18:19 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA14360 for ; Fri, 9 Nov 2001 15:18:21 -0800 (PST) Message-ID: <3BEC5EE8.BBB97DAB@Royer.com> Date: Fri, 09 Nov 2001 15:55:36 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) References: <3BEB18DE.9F679F89@netscape.com> Content-Type: multipart/mixed; boundary="------------E8D875244706630EE341D156" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E8D875244706630EE341D156 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (I think Steve was sleeping when he sent his reply :-) Steve Mansour wrote: > > "Shannon J. Clark" wrote: > > > > There is a common trend to associate ONE MIME object holding an iCalendar > > object with ONE vEVENT (and perhaps a vTimezone object). In fact I think > > some vendors may ONLY deal with iCalendar objects that contain only one > > vEVENT. > > > > However it is clearly valid to have a vCalendar with multiple vEVENT objects > > (or else what are we doing here???) > > you'd think it would be clearly valid wouldnt you? Actually, there was > a very persuasive group of folks that wanted text/calendar mime parts to > only contain components with a single UID. And they won :-) Have a > look at the restriction tables in iTIP. For VEVENTs, where the presence > value is 1+, the text specifies that all components must have the same > UID. No: You can have multiple VEVENTS in one VCALENDAR each with its own UID. BEGIN:VCALENDAR ... BEGIN:VEVENT UID:1 ... END:VEVENT BEGIN:EVENT UID:2 ... END:VEVENT END:VCALENDAR The restriction is per VEVENT, not PER VCALENDAR. > While I am not a fan of limiting the iCalendar objects in iTIP to a > specific UID, it does seem to mitigate this problem. I think it would > be very unlikely to have a recurring event where different instances of > the same event have different character encodings. I agree, but you could send it. > > In general how are "full calendar" objects intended to be handled - much of > > the standards we are writing seem to treat individual events as the primary > > unit for work - associating with them perhaps a vTimezone object, but other > > objects such as vTODO or even multiple vEVENT objects seem to be perhaps > > more complex to deal with? > > iTIP doesn't handle this. CAP probably should. Any suggestions? Worst > case, we require multiple sends. Steve - you are sleeping - yes it can. We allow multiple VEVENT (or any component) per VCALENDAR now. There is no such restriction in iTIP. I think you are thinking of the VEVENT restriction table, there is no VCALENDAR restriction table in iTIP. BEGIN:VCALENDAR VERSION:... ... BEGIN:VEVENT ... END:VEVENT BEGIN:VEVENT ... END:VEVENT BEGIN:VJOURNAL ... END:VJOURNAL ... BEGIN:VTIMEZONE ... END:VTIMEZONE BEGIN:VTODO ... END:VTODO ... END:VCALENDAR -Doug --------------E8D875244706630EE341D156 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------E8D875244706630EE341D156-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:40:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00518 for ; Fri, 9 Nov 2001 18:40:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9NNvE18208 for ietf-calendar-bks; Fri, 9 Nov 2001 15:23:57 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9NNu818203 for ; Fri, 9 Nov 2001 15:23:56 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA14456 for ; Fri, 9 Nov 2001 15:23:57 -0800 (PST) Message-ID: <3BEC6037.52E9925D@Royer.com> Date: Fri, 09 Nov 2001 16:01:11 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) References: Content-Type: multipart/mixed; boundary="------------EF70B2DCDFCA920DC81D2710" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EF70B2DCDFCA920DC81D2710 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Steve, > > This does explain something - I have spent the least time looking over iTIP > so I had missed that section - but it is a clear indication of the > different viewpoints on what use is intended for iCalendar objects. > > Simple and VERY common use case I have a question about: > > Calendar User Agent connects to Calendar Store for the FIRST TIME. > > Use case is - How does the CUA obtain the full calendar for that USER from > the Calendar store? (syntax may be a little off...) VQUERY:SELECT * FROM VEVENT,VTODO,VJOURNAL WHERE OWNER=self The results come back as ONE VCALENAR object per TARGET calendar. > "multiple sends" - seems like a very ugly solution. No you do not have to. > I believe this is an EXACT use case from our documents - it is implied that > Calendar User Agents will maintain a LOCAL Calendar Store Or just the results, or current month, or current day, or ... >- to me at least > this implies a means to obtain the FULL calendar for that user from the > remote store to a local store. --------------EF70B2DCDFCA920DC81D2710 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------EF70B2DCDFCA920DC81D2710-- From owner-ietf-calendar@mail.imc.org Fri Nov 9 18:44:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00584 for ; Fri, 9 Nov 2001 18:43:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9NTj918332 for ietf-calendar-bks; Fri, 9 Nov 2001 15:29:45 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9NTi818328 for ; Fri, 9 Nov 2001 15:29:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA14578; Fri, 9 Nov 2001 15:29:45 -0800 (PST) Message-ID: <3BEC6191.A347E03E@Royer.com> Date: Fri, 09 Nov 2001 16:06:57 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > John, > > Unicode is a solution - but may have difficulties for certain Asian > languages, specifically there appear to be commonly used Japanese character > sets that are not in UTF8. I think that all of the Japanese characters can be displaid in UTF8, however it is in-efficient. But many experts tell me that it is just a preference. Any MIME compliant reader can do charset conversions so you can see the text in your preferred charset. I am waiting for someone to do lang conversion :-) An iCalendar object is UTF8 unless the MIME header says otherwise. I know the WG decided this for CAP, and I think for iCalendar. -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 9 19:05:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00893 for ; Fri, 9 Nov 2001 19:05:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9Nms318941 for ietf-calendar-bks; Fri, 9 Nov 2001 15:48:54 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9Nmr818936 for ; Fri, 9 Nov 2001 15:48:53 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id SAA19285; Fri Nov 9 18:46:44 2001 Subject: Re: MIME Multiple body parts (Was Re: uid...) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 9 Nov 2001 18:51:14 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/09/2001 06:51:19 PM, Serialize complete at 11/09/2001 06:51:19 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> It's easy for a recipient's MUA to take the text/calendar >> and pass it off to the CUA for processing; but permitting the CUA to go >> back to the MUA to resolve the cid: URL requires more integration. > >They just need to forward the entire MIME message if they >don't look inside. That still requires more integration, because it requires the MUA to know that the CUA is supposed to get the entire message, instead of just registering the CUA as a helper app. (Personally, I'd be uncomfortable with a helper app system where the app gets the entire message; too little modularity, too many opportunities for security bugs.) /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Know your limits, then destroy 'em. | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 9 19:13:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01009 for ; Fri, 9 Nov 2001 19:13:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA9NsIk19092 for ietf-calendar-bks; Fri, 9 Nov 2001 15:54:18 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9NsG819088 for ; Fri, 9 Nov 2001 15:54:16 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id RAA06556 for ; Fri, 9 Nov 2001 17:52:27 -0600 From: "Shannon J. Clark" To: Subject: RE: MIME Multiple body parts (Was Re: uid...) + iCalendar as data standard Date: Fri, 9 Nov 2001 17:54:10 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BEC5B04.784110C7@Royer.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, I am puzzled by what you mean when you say "iCalendar CAN NOT STORE DATE - that's what CAP is for" What puzzles me is that people talk about iCalendar as a "Data format" - and pardon my simple interpretation of the words - but I would tend to think of a "data format" as being capable of storing data.... On the other hand, CAP was as I understood it "Calendar Access Protocol" - i.e. it describes how to communicate with a piece of software termed a "Calendar Server" - i.e. how to access a calendar on a calendar server. iCalendar is described as being the data format for the communications with the Calendar Server, the format for the data ON the calendar server - how is this not a "data storage" standard??? I think that something very important, more than mere semantics is involved here - quite possibly we are confusing many people as to what is covered in which standard; how they work together; and what they do/do not apply towards. For example - what I really want from iCalendar is a coherent and interoperable means of encapsulating Calendar information - either one event at a time, or more usefully for me a "Calendar" at a time - where a "Calendar" is a collection of entities - which I will deem either as being for one human user or for a group of human users. I then want a means of exchanging this information with many other software applications - for the purposes I am currently using the calendaring systems SCHEDULING between individuals is not in the domain of my systems - BUT my systems MUST work with other calendaring servers for whom scheduling IS in the domain - i.e. I want to be able to store and/or forward scheduling related requirements - but my systems at present won't be generating scheduling workflow requests. So - do I look for this in iCalendar? in CAP? or in neither place at all? thanks - these conversations are very helpful in illuminating both what the documents SAY and what was intended by them... which are frequently different. thanks! Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Friday, November 09, 2001 4:39 PM To: ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) + iCalendar as data standard > "Shannon J. Clark" wrote: > I think that the point that using iCalendar to store a calendar store for a > specific user raises some very serious questions. > > IF iCalendar is a DATA standard - then why is it "very complicated" and > "needs careful thought" to use it to store an entire calendar for a given > user? iCalendar is complicated because that the nature of calendering and scheduling. Calendaring only is easy. CAP is storage and iCalendar can (and is) used with out iTIP and CAP. > It has always struck me as curious that within the iCalendar standard it is > not at all clear how to talk about a "USER" - i.e. how to talk about in a > logical manner "a user's calendar" That is because a user may be a program. So rather than say a person, we say a CU (calendar user). That is spelled out in iCalendar and CAP. > I think the differentiation between thinking of iCalendar as a means to > store data for ONE transaction - iCalendar CAN NOT STORE DATA - that's what CAP is for. iTIP can not store data. iMIP can not store data. > i.e. for one meeting, for one task vs. the > thinking of "Calendaring" in general and dealing with a user's > calendar is a major one - and one that we may need to address head on. iTIP is for scheduling - for which much was added to iCalendar to represent the scheduling. (and MUCH debate). > From: Robert_Ransdell@iris.com [mailto:Robert_Ransdell@iris.com]On > > I am also VERY interested in the use case of using iCalendar to > dump to an interchange format an entire calendar for a given user > - in this case the resulting vCalendar will contain MANY vEVENT, > vTODO, vTIMEZONE objects. It CAN do that now. -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 9 19:16:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01083 for ; Fri, 9 Nov 2001 19:16:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA9NxBN19192 for ietf-calendar-bks; Fri, 9 Nov 2001 15:59:11 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9NxA819188 for ; Fri, 9 Nov 2001 15:59:10 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA14983; Fri, 9 Nov 2001 15:59:05 -0800 (PST) Message-ID: <3BEC685F.1A87843D@Royer.com> Date: Fri, 09 Nov 2001 16:35:59 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ietf@ietf.org, "ietf-calendar@imc.org" Subject: Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard References: <200111092216.fA9MG9T16571@astro.cs.utk.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 Why not just specify that dates/times are RFC2445 compliant? The calsch WG spent a long time debating these issues. In addition the date-time format used in RFC2445 is also ISO-8601 based. In addition the calsch WG has a plan (don't laugh too hard) for the usage of time zones. This draft only mentions they exist. Why does there need to be another date-time standard? Why did this not go through the calsch working group (at least cc the working group before final proposal?). This draft acknowledges the calsch WG, but the chairs (I called Pat) never saw this - nor did I. Was it sent and debated as assumed by reading the acknowledgements? 6. Acknowledgements ... Thanks are also due to participants of the IETF Calendaring/Scheduling working group mailing list, and participants of the time zone mailing list. The iCalendar date-time format is restricted to exactly one representation of date-time (not optional spaces, dashes, ...). There was a large debate on this before rfc2445 came out. We decided on ONE format for date time based on ISO-8601 YYYYMMDDTHHMMSS [+/- ...] If the intent is to be human readable - both loose. If the intent is to be machine readable - why another similar format? -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 9 19:22:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01189 for ; Fri, 9 Nov 2001 19:22:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAA029519309 for ietf-calendar-bks; Fri, 9 Nov 2001 16:02:09 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAA028819304 for ; Fri, 9 Nov 2001 16:02:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA15066; Fri, 9 Nov 2001 16:02:08 -0800 (PST) Message-ID: <3BEC6913.24AB46B5@Royer.com> Date: Fri, 09 Nov 2001 16:38:59 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: ietf@ietf.org, "ietf-calendar@imc.org" Subject: Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard References: <200111091657.LAA18166@ietf.org> <200111092216.fA9MG9T16571@astro.cs.utk.edu> <20011109175906.C20667@buffoon.automagic.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 Joe Abley wrote: > > On Fri, Nov 09, 2001 at 05:16:09PM -0500, Keith Moore wrote: > > However, many events are actually specified relative to a particular > > timezone, and timezone offsets occasionally change with little advance > > warning. As such, this representation may not be sufficient for > > specifying dates and times of some kinds of events, particularly > > future events. > > > > In such cases it is necessary to include a representation of the timezone > > (not merely the GMT offset) along with the date of the event. This > > specification does not provide such a facility, and is therefore > > inappropriate for representation of (for example) events on a calendar. > > Is this not covered in section 1? > > o All times expressed have a stated relationship (offset) to > .... No - not at all. This is a BIG issue - if you want to understand it, go to the calsch archives. Or send email to the ietf-calendar@imc.org mailing list. -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 9 19:35:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01329 for ; Fri, 9 Nov 2001 19:35:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAA0Ilq19976 for ietf-calendar-bks; Fri, 9 Nov 2001 16:18:47 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAA0Ik819972 for ; Fri, 9 Nov 2001 16:18:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA15293 for ; Fri, 9 Nov 2001 16:18:47 -0800 (PST) Message-ID: <3BEC6CF4.2B8E5E11@Royer.com> Date: Fri, 09 Nov 2001 16:55:32 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: CAP TODO - 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 John Stracke wrote: > > >> section 7.1.5, CAPVERSION, CAR, and QUERYLEVEL all need to be able to > >> have values of NONE.) > > > >Why MUST these be NONE? > > > >Why can't a CRISP server send out a CAPABILITY of CRISP, > > Mmm, that's an option. However, I think I'd rather make it explicit to > clients that they're not going to get CAR or QUERYLEVEL features. That > way, if a CAP client accidentally gets configured to use a CRISP server, > it will be told so clearly, even if it doesn't check the CRISP capability. How about if a server sends out CRISP and not CAPVERSION, then it is a CRISP server and not a CAP server. If a server were NOT to send CAPVERSION, then it is NOT a CAP server. So it would be out of scope for CAP. However a LONG debate resolved to SQL-MIN, that is not optional for a CAP server. > Perhaps CAPVERSION could be "CRISP" and the other two could be "NONE", and > we can specify that NONE is a legal value if, and only if, CAPVERSION is > CRISP. How's that? I don't see what the conflict is. If you don't want to use SQL-MIN, don't use it. The CS will not cram one up the pipe to a CUA. If CAPVERSION is not present or its value is not "1.0" (as specified in the current draft) --> then it is not a CAP server. So out of scope for CAP. Sending NONE to CAPVERSION and NONE to SQL-MIN takes away a lot of CAP. It's not a CAP server. Why can't you say a CRISP server is a CAP server,except: no CAPVERSION and no SQL-MIN, ... ? -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 9 19:49:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01485 for ; Fri, 9 Nov 2001 19:48:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAA0UoN20246 for ietf-calendar-bks; Fri, 9 Nov 2001 16:30:50 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAA0Un820242 for ; Fri, 9 Nov 2001 16:30:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA15519 for ; Fri, 9 Nov 2001 16:30:50 -0800 (PST) Message-ID: <3BEC6FC2.8F514A1D@Royer.com> Date: Fri, 09 Nov 2001 17:07:30 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: single threaded References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > >> - Problems with a single threaded server? > >> If yes, then will need to change some things. > >> See post "CAP: Bounded latency" > > > >(1) What do you mean by 'single threaded'? Do you mean OS threads? > > If so - I don't know of any issues. > > The post referred to explains. Basically, bounded latency is usually not > implementable in a single-threaded process (unless you start messing with > alarm signals, and signals are the spawn of Satan), because the APIs used > to access the backend database are typically blocking calls. If CAP > requires the bounded-latency features, then it is mandating that servers > be designed with multiple threads. Multi-threaded - no not required. I can do that on a Palm Pilot, Unix, any of the MS-dos's, and using many single threaded OS's and languages. I was never a fan of bound latency. I always said if the CUA does not want to wait, it can cancel the request. However the WG overrode me by a huge majority. Any system that can handle iCalendar/CAP can handle this. Yes - you have to use alarms. But even the Palm Pilot and MS-Dos's can do that. And I don't know of any Unix that can not do alarms well. I really don't see this as an issue. The API's to backend databases - from mSQL, MySQL, the GNU-SQL, Oracle, and MANY others have nothing to-do with alarms. Many (all these?) allow for submitting the query and going back later for the answer. If your OS can't do OS alarms - then how will it ever handle iCal alarms? Is it going to block all request until all iCal-alarms are sent? Pain - yes - that's why I did not want it. The WG said yes. Closed issue - lets get CAP out. :-) -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 9 19:58:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01574 for ; Fri, 9 Nov 2001 19:58:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAA0bKi20393 for ietf-calendar-bks; Fri, 9 Nov 2001 16:37:20 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAA0bJ820389 for ; Fri, 9 Nov 2001 16:37:19 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA15593 for ; Fri, 9 Nov 2001 16:37:21 -0800 (PST) Message-ID: <3BEC7147.517AE10A@Royer.com> Date: Fri, 09 Nov 2001 17:13:59 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > >> It's easy for a recipient's MUA to take the text/calendar > >> and pass it off to the CUA for processing; but permitting the CUA to go > >> back to the MUA to resolve the cid: URL requires more integration. > > > >They just need to forward the entire MIME message if they > >don't look inside. > > That still requires more integration, because it requires the MUA to know > that the CUA is supposed to get the entire message, instead of just > registering the CUA as a helper app. I agree. I am NOT saying it is a must for MUA's. I am saying lets not limit ourselves to what MUA's can do today. Lets just support MIME (all of MIME). And not limit iCalendar to what some MUA's can or can not do today. If they send any valid MIME object to a CAP server - we should be able to handle it - if not 'we' are busted not the MUA. -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 9 21:08:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02220 for ; Fri, 9 Nov 2001 21:08:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAA1mPS22040 for ietf-calendar-bks; Fri, 9 Nov 2001 17:48:25 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAA1mN822036 for ; Fri, 9 Nov 2001 17:48:23 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA16624 for ; Fri, 9 Nov 2001 17:48:24 -0800 (PST) Message-ID: <3BEC81C2.BF9593CC@Royer.com> Date: Fri, 09 Nov 2001 18:24:18 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) + iCalendar as data standard References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Doug, > > I am puzzled by what you mean when you say "iCalendar CAN NOT STORE DATE - > that's what CAP is for" > > What puzzles me is that people talk about iCalendar as > a "Data format" - and pardon my simple interpretation of the > words - but I would tend to think of > a "data format" as being capable of storing data.... I can store a TV, but that not what it is for :-) It is simply the common nomenclature used to describe these things. The 'wire format' (or data format) is iCalendar. However there is no requirement that I store the object in iCalendar format. The only requirement is that when I transport the data on the wire, that I use iCalendar format. > On the other hand, CAP was as I understood it "Calendar Access Protocol" - > i.e. it describes how to communicate with a piece of software termed a > "Calendar Server" - i.e. how to access a calendar on a calendar server. Yes. How a server serves up iCalendar objects on the wire. > iCalendar is described as being the data format for the communications with > the Calendar Server, the format for the data ON the calendar server - how is > this not a "data storage" standard??? In my (toy) implementation - I store the data using MySQL. The data storage standard I use is SQL. However when I pull up the data and send it over the wire, I transform it to/from iCalendar. > I think that something very important, more than mere semantics is involved > here - quite possibly we are confusing many people as to what is covered in > which standard; how they work together; and what they do/do not apply > towards. > > For example - what I really want from iCalendar is a coherent and > interoperable means of encapsulating Calendar information - either one event > at a time, or more usefully for me a "Calendar" at a time - where a > "Calendar" is a collection of entities - which I will deem either as being > for one human user or for a group of human users. Yes - that is what iCalendar is for: how to represent any single item to an entire calendar - on the wire. > I then want a means of exchanging this information with many other software > applications - for the purposes I am currently using the calendaring systems > SCHEDULING between individuals is not in the domain of my systems - BUT my > systems MUST work with other calendaring servers for whom scheduling IS in > the domain - i.e. I want to be able to store and/or forward scheduling > related requirements - but my systems at present won't be generating > scheduling workflow requests. That is why iTIP exists. It explains how to use the iCalendar object to schedule with one or more CUs. > So - do I look for this in iCalendar? in CAP? or in neither place at all? If you want to know what an iCalendar entry looks like: Read iCalendar. If you want to know how to schedule with people using iCalendar object Read iTIP. If you want to know how to email both calendar entries and scheduling requests/replies: read iMIP. If you want your CUA to be able to manipulate iCalendar objects and talk to some one else's calendar store: Read CAP. The pain in the butt part is that as we evolve the work that was started years ago. We discover new properties, parameters, and restrictions. That is where most of the confusion comes from. -Doug From owner-ietf-calendar@mail.imc.org Sat Nov 10 00:57:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09183 for ; Sat, 10 Nov 2001 00:57:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAA5cSN00414 for ietf-calendar-bks; Fri, 9 Nov 2001 21:38:28 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAA5cR800408 for ; Fri, 9 Nov 2001 21:38:27 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fAA5cMY05152 for ; Fri, 9 Nov 2001 21:38:22 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMKL0100.TFJ for ; Fri, 9 Nov 2001 21:38:25 -0800 Message-ID: <3BECBC8D.F55294E6@netscape.com> Date: Fri, 09 Nov 2001 21:35:09 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) References: <3BEB18DE.9F679F89@netscape.com> <3BEC5EE8.BBB97DAB@Royer.com> Content-Type: multipart/mixed; boundary="------------A6156BF81C803D2444DE9EDC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A6156BF81C803D2444DE9EDC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > (I think Steve was sleeping when he sent his reply :-) that could be true, but see below... > Steve Mansour wrote: > > > > "Shannon J. Clark" wrote: > > > > > > There is a common trend to associate ONE MIME object holding an iCalendar > > > object with ONE vEVENT (and perhaps a vTimezone object). In fact I think > > > some vendors may ONLY deal with iCalendar objects that contain only one > > > vEVENT. > > > > > > However it is clearly valid to have a vCalendar with multiple vEVENT objects > > > (or else what are we doing here???) > > > > you'd think it would be clearly valid wouldnt you? Actually, there was > > a very persuasive group of folks that wanted text/calendar mime parts to > > only contain components with a single UID. And they won :-) Have a > > look at the restriction tables in iTIP. For VEVENTs, where the presence > > value is 1+, the text specifies that all components must have the same > > UID. > > No: You can have multiple VEVENTS in one VCALENDAR each with > its own UID. > > BEGIN:VCALENDAR > ... > BEGIN:VEVENT > UID:1 > ... > END:VEVENT > BEGIN:EVENT > UID:2 > ... > END:VEVENT > END:VCALENDAR > > The restriction is per VEVENT, not PER VCALENDAR. Hmm... that's not the way I read RFC2446. Have a look at 3.2.2 REQUEST. The restriction table says VEVENT 1+ All components MUST have the same UID I take this to mean that in a REQUEST you can have 1 or more VEVENTs but they all must have the same UID. How do others read this? -Steve --------------A6156BF81C803D2444DE9EDC 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:408-276-4930 tel;work:408-276-4268 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 --------------A6156BF81C803D2444DE9EDC-- From owner-ietf-calendar@mail.imc.org Sat Nov 10 08:52:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27230 for ; Sat, 10 Nov 2001 08:52:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAADWAx17480 for ietf-calendar-bks; Sat, 10 Nov 2001 05:32:10 -0800 (PST) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAADW8817476 for ; Sat, 10 Nov 2001 05:32:09 -0800 (PST) Received: (qmail 75244 invoked from network); 10 Nov 2001 13:31:59 -0000 Received: from unknown (HELO pslaptop) ([64.81.102.173]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Nov 2001 13:31:59 -0000 Reply-To: From: "Steve Miller" To: Subject: Synchronization issues Date: Sat, 10 Nov 2001 06:29:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C169B1.0701A240" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C169B1.0701A240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit We are using vCalendar to store our web appointments locally in our MS Outlook appointment books. This works well, but our clients now want to be able to synchronize all our web appointments with their MS Outlook appointment book. My first thought was to allow them to click a hyperlink on our web site, it would read all their appoinments, put all of them into one vCalendar file and send that to them in email. Then they would simply double click the vCalendar file and it would add the appointments. I found 2 problems with this: 1.. When they click the vCalendar file that contains more than one vCalendar event, it only adds the first one. I could not find a way to process them all. 2.. If a duplicate vCalendar entry is in the file, we want to ignore it. It creates a duplicate record in MS Outlook. Any ideas about our approach? My thought at this point is to have the client do an EXPORT of their calendar information in CSV format and allow us to import it into our web application, replacing duplicates and finding items that are on the web site but not locally. Then we could send the missing ones back to the client in via email with a vCalendar attachment. Then they could import that vCalendar file. Is there a better way? Steve Miller, Pragmatic Software Co., Inc., 303.471.8355 www.pragmaticsw.com www.defecttracker.com www.pragmaticoffice.com ------=_NextPart_000_001C_01C169B1.0701A240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We are using=20 vCalendar to store our web appointments locally in our MS = Outlook=20 appointment books.  This works well, but our clients now = want to be=20 able to synchronize all our web appointments with their MS Outlook=20 appointment book. 
 
My = first thought was=20 to allow them to click a hyperlink on our web site, it would read all = their=20 appoinments, put all of them into one vCalendar file and send that to = them in=20 email.  Then they would simply double click the vCalendar file and = it would=20 add the appointments.  I found 2 problems with = this:
  1. When they=20 click the vCalendar file that contains more than one vCalendar event, = it only=20 adds the first one.  I could not find a way to process them = all.=20
  2. If a = duplicate=20 vCalendar entry is in the file, we want to ignore it.  It creates = a=20 duplicate record in MS Outlook.
Any ideas=20 about our approach?  My thought at = this=20 point is to have the client do an EXPORT of their calendar information = in CSV=20 format and allow us to import it into our web application, replacing = duplicates=20 and finding items that are on the web site but not locally.  Then = we could=20 send the missing ones back to the client in via email with a vCalendar=20 attachment.  Then they could import that vCalendar file. =20
 
Is there a better way?  =
 
Steve Miller, = Pragmatic Software Co., Inc., = 303.471.8355
 
------=_NextPart_000_001C_01C169B1.0701A240-- From owner-ietf-calendar@mail.imc.org Sat Nov 10 10:37:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28629 for ; Sat, 10 Nov 2001 10:37:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAAFEwD23845 for ietf-calendar-bks; Sat, 10 Nov 2001 07:14:58 -0800 (PST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAAFEv823841 for ; Sat, 10 Nov 2001 07:14:57 -0800 (PST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA27648; Sat, 10 Nov 2001 10:13:50 -0500 (EST) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4VQ8R2BT>; Sat, 10 Nov 2001 10:12:32 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6C5FC53@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Doug Royer'" Cc: ietf@ietf.org, ietf-calendar@imc.org Subject: RE: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard Date: Sat, 10 Nov 2001 10:05:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Doug Royer [mailto:Doug@ROYER.COM] > Sent: Friday, November 09, 2001 6:36 PM > > The iCalendar date-time format is restricted to exactly one > representation of date-time (not optional spaces, dashes, ...). > There was a large debate on this before rfc2445 came out. > We decided on ONE format for date time based on ISO-8601 > > YYYYMMDDTHHMMSS [+/- ...] > > If the intent is to be human readable - both loose. > If the intent is to be machine readable - why another similar format? One possible issue involves incompatibility with standard formats defined by other organizations, such as the W3C. XML Schema (for example) defines a date-time format [1] per ISO-8601's extended form; the shorter format described in RFC2445 and ISO-8601 is invalid per XML Schema. If the IETF were to "require" RFC2445-compliant date-time values in protocols we'd be imposing a format that restricts use of XML Schema (and who knows what else) in protocol design. The formats specified in this new document provide some flexibility that may be useful in varied date-time specification contexts. -Scott- [1] http://www.w3.org/TR/xmlschema-2/#dateTime From owner-ietf-calendar@mail.imc.org Sat Nov 10 11:30:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29211 for ; Sat, 10 Nov 2001 11:30:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAAGET800665 for ietf-calendar-bks; Sat, 10 Nov 2001 08:14:29 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAAGEQ800654 for ; Sat, 10 Nov 2001 08:14:26 -0800 (PST) To: "John Stracke" Cc: iesg@ietf.org, ietf@ietf.org, ietf-calendar@imc.org, impp@iastate.edu, owner-ietf-calendar@mail.imc.org Subject: Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Sat, 10 Nov 2001 11:13:51 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/10/2001 11:13:59 AM, Serialize complete at 11/10/2001 11:13:59 AM Content-Type: multipart/alternative; boundary="=_alternative 00593E0C85256B00_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00593E0C85256B00_= Content-Type: text/plain; charset="us-ascii" John, where is the original of this note? Did it go to the calendar list? If it's on another list, can you point me to it so I (and the list) can see the text of the whole note. Thanks. "John Stracke" Sent by: owner-ietf-calendar@mail.imc.org 11/09/01 18:10 To: ietf@ietf.org cc: iesg@ietf.org, impp@iastate.edu, ietf-calendar@imc.org Subject: Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard Keith Moore wrote: >However, many events are actually specified relative to a particular >timezone, and timezone offsets occasionally change with little advance >warning. As such, this representation may not be sufficient for >specifying dates and times of some kinds of events, particularly >future events. This is correct. The IMPP group covered this in Minneapolis, I think. The draft alludes to the problem, but may not be explicit enough (probably isn't, if Keith felt it necessary to comment): o All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC). (This is distinct from some usage in scheduling applications where a local time and location may be known, but the actual relationship to UTC may be dependent on the unknown or unknowable actions of politicians or administrators. The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time. This specification steers well clear of such considerations.) I believe that Keith is right, that this paragraph should include a reference to iCalendar (RFC-2445) and point readers to that for use when a simple timestamp won't do. It's a small point, but it could prevent some confusion. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |"Time is money, and price is information." --Russ Nelson| \========================================================/ --=_alternative 00593E0C85256B00_= Content-Type: text/html; charset="us-ascii"
John, where is the original of this note?  Did it go to the calendar list? If it's on another list, can you point me to it so I (and the list) can see the text of the whole note.  Thanks.


"John Stracke" <jstracke@incentivesystems.com>
Sent by: owner-ietf-calendar@mail.imc.org

11/09/01 18:10

       
        To:        ietf@ietf.org
        cc:        iesg@ietf.org, impp@iastate.edu, ietf-calendar@imc.org
        Subject:        Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard




Keith Moore wrote:

>However, many events are actually specified relative to a particular
>timezone, and timezone offsets occasionally change with little advance
>warning.  As such, this representation may not be sufficient for
>specifying dates and times of some kinds of events, particularly
>future events.

This is correct.  The IMPP group covered this in Minneapolis, I think. The
draft alludes to the problem, but may not be explicit enough (probably
isn't, if Keith felt it necessary to comment):

  o  All times expressed have a stated relationship (offset) to
     Coordinated Universal Time (UTC).  (This is distinct from some
     usage in scheduling applications where a local time and location
     may be known, but the actual relationship to UTC may be dependent
     on the unknown or unknowable actions of politicians or
     administrators.  The UTC time corresponding to 17:00 on 23rd March
     2005 in New York may depend on administrative decisions about
     daylight savings time.  This specification steers well clear of
     such considerations.)

I believe that Keith is right, that this paragraph should include a
reference to iCalendar (RFC-2445) and point readers to that for use when a
simple timestamp won't do.  It's a small point, but it could prevent some
confusion.

/========================================================\
|John Stracke                    |Principal Engineer     |
|jstracke@incentivesystems.com   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|"Time is money, and price is information." --Russ Nelson|
\========================================================/

--=_alternative 00593E0C85256B00_=-- From owner-ietf-calendar@mail.imc.org Sat Nov 10 13:03:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29937 for ; Sat, 10 Nov 2001 13:03:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAAHd7d03999 for ietf-calendar-bks; Sat, 10 Nov 2001 09:39:07 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAAHd6803991 for ; Sat, 10 Nov 2001 09:39:06 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAAHdBQ15255 for ; Sat, 10 Nov 2001 11:39:11 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 10 Nov 2001 11:39:06 -0600 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 10 Nov 2001 11:39:06 -0600 content-class: urn:content-classes:message Subject: RE: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard Date: Sat, 10 Nov 2001 11:39:12 -0600 Message-ID: <15A85922ED48294F80973D83F95074B64E05B4@daebe006.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcFp/dx9YynI09XuEdWJVQAIx6TWpQAEEGbw From: "Dawson Frank (NMP/Irving)" To: "'ext Hollenbeck, Scott'" Cc: , X-OriginalArrivalTime: 10 Nov 2001 17:39:06.0618 (UTC) FILETIME=[98A5E5A0:01C16A0E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fAAHd6803993 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > The iCalendar date-time format is restricted to exactly one > > representation of date-time (not optional spaces, dashes, ...). > > There was a large debate on this before rfc2445 came out. > > We decided on ONE format for date time based on ISO-8601 > > > > YYYYMMDDTHHMMSS [+/- ...] > > > > If the intent is to be human readable - both loose. > > If the intent is to be machine readable - why another > similar format? > > One possible issue involves incompatibility with standard > formats defined by > other organizations, such as the W3C. XML Schema (for > example) defines a > date-time format [1] per ISO-8601's extended form; the shorter format > described in RFC2445 and ISO-8601 is invalid per XML Schema. > If the IETF > were to "require" RFC2445-compliant date-time values in > protocols we'd be > imposing a format that restricts use of XML Schema (and who > knows what else) > in protocol design. The formats specified in this new > document provide some > flexibility that may be useful in varied date-time > specification contexts. > The W3C Schema work just ignored the previously published IETF iCalendar work effort. The issue is not that iCalendar is different than this yet-to-be-proven XML Schema data type for date time, but rather that the W3C work ignored the recommendations of the "time lords" in the IETF. In addition, the XML Schema date/time data type includes a UTC offset. This mixes time zone specification with date/time data types. Such coupling was found to be inappropriate for a data type that is used for calendaring and scheduling applications or other date/time dependent applications. So, the RFC2445 isn't "invalid per XML schema". Rather the opposite is true. From owner-ietf-calendar@mail.imc.org Sat Nov 10 14:48:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00819 for ; Sat, 10 Nov 2001 14:48:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAAJMx708294 for ietf-calendar-bks; Sat, 10 Nov 2001 11:22:59 -0800 (PST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAAJMv808290 for ; Sat, 10 Nov 2001 11:22:57 -0800 (PST) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA28812; Sat, 10 Nov 2001 14:22:22 -0500 (EST) Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4VR9M962>; Sat, 10 Nov 2001 14:19:47 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6C5FC54@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Dawson Frank (NMP/Irving)'" Cc: ietf@ietf.org, ietf-calendar@imc.org Subject: RE: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard Date: Sat, 10 Nov 2001 14:14:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Dawson Frank (NMP/Irving) [mailto:Frank.Dawson@nokia.com] > Sent: Saturday, November 10, 2001 12:39 PM > To: 'ext Hollenbeck, Scott' > Cc: ietf@ietf.org; ietf-calendar@imc.org > Subject: RE: Last Call: Date and Time on the Internet: Timestamps to > Proposed Standard > > > > So, the RFC2445 isn't "invalid per XML schema". Rather the opposite is > true. Perhaps, but the point I was trying to make isn't about the W3C ignoring IETF work or vice-versa. A "one size fits all" specification isn't likely to meet everyone's needs, and the situation with 2445 and XML Schema is just one example of a situation where the given size didn't fit someone for some reason. The point I was trying to make is that the timestamps document seems to provide a reasonable compromise between being too restrictive and too permissive. -Scott- From owner-ietf-calendar@mail.imc.org Sat Nov 10 14:51:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00855 for ; Sat, 10 Nov 2001 14:51:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAAJTUl08867 for ietf-calendar-bks; Sat, 10 Nov 2001 11:29:30 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAAJTT808863 for ; Sat, 10 Nov 2001 11:29:29 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAAJTZQ18674 for ; Sat, 10 Nov 2001 13:29:35 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 10 Nov 2001 13:29:31 -0600 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 10 Nov 2001 13:29:37 -0600 content-class: urn:content-classes:message Subject: RE: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard Date: Sat, 10 Nov 2001 13:29:37 -0600 Message-ID: <15A85922ED48294F80973D83F95074B64E05BD@daebe006.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcFqHUWEXpnxsdYEEdWrywAIx6S5QwAAJAog From: "Dawson Frank (NMP/Irving)" To: "'ext Hollenbeck, Scott'" Cc: , X-OriginalArrivalTime: 10 Nov 2001 19:29:37.0880 (UTC) FILETIME=[09302D80:01C16A1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fAAJTT808864 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit "One size fits all"? This isn't about haberdashery. The point of a standard format is exactly that there needs to be a single precise format. If you are going to use an Internet date/time standard, then it ought to be same or at least an isomer (ie, iCalendar date/time format). Especially, when it comes to basic data types like date/time. -- Frank > Perhaps, but the point I was trying to make isn't about the > W3C ignoring > IETF work or vice-versa. A "one size fits all" specification > isn't likely > to meet everyone's needs, and the situation with 2445 and XML > Schema is just > one example of a situation where the given size didn't fit > someone for some > reason. The point I was trying to make is that the > timestamps document > seems to provide a reasonable compromise between being too > restrictive and > too permissive. From owner-ietf-calendar@mail.imc.org Sat Nov 10 15:42:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01295 for ; Sat, 10 Nov 2001 15:42:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAAKSmD11458 for ietf-calendar-bks; Sat, 10 Nov 2001 12:28:48 -0800 (PST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAAKSl811452 for ; Sat, 10 Nov 2001 12:28:47 -0800 (PST) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA29176; Sat, 10 Nov 2001 15:28:12 -0500 (EST) Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4VR9M0AM>; Sat, 10 Nov 2001 15:25:37 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6C5FC56@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Dawson Frank (NMP/Irving)'" Cc: ietf@ietf.org, ietf-calendar@imc.org Subject: RE: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard Date: Sat, 10 Nov 2001 15:20:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Dawson Frank (NMP/Irving) [mailto:Frank.Dawson@nokia.com] > Sent: Saturday, November 10, 2001 2:30 PM > To: 'ext Hollenbeck, Scott' > Cc: ietf@ietf.org; ietf-calendar@imc.org > Subject: RE: Last Call: Date and Time on the Internet: Timestamps to > Proposed Standard > > > "One size fits all"? This isn't about haberdashery. Obviously. Sorry if the point of the analogy wasn't clear. > The point of a standard format is exactly that there needs to be a > single precise format. If you are going to use an Internet date/time > standard, then it ought to be same or at least an isomer (ie, iCalendar > date/time format). > > Especially, when it comes to basic data types like date/time. Yes, we should have a standard, but that standard should be usable across the IETF. In the provreg WG, we're using XML Schema to specify a protocol because XML and XML Schema provide needed extensibility features. I can't use 2445-compliant date-time format because XML Schema won't accept it. We can debate the merits (or detriments) of using non-IETF specified technologies for IETF work, but that's not the issue at hand. The Timestamps draft describes formats that can be used where 2445-format can't, and at least in the case of the provreg WG that flexibility is needed. -Scott- From owner-ietf-calendar@mail.imc.org Sun Nov 11 08:23:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24570 for ; Sun, 11 Nov 2001 08:23:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fABCuUi03729 for ietf-calendar-bks; Sun, 11 Nov 2001 04:56:30 -0800 (PST) Received: from bakou.hn.org (APh-Aug-103-1-4-24.abo.wanadoo.fr [80.11.245.24]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fABCuP803721 for ; Sun, 11 Nov 2001 04:56:29 -0800 (PST) Received: from there (ben.bakou.hn.org [192.168.0.2]) by bakou.hn.org (Postfix) with SMTP id D7C9632F5A for ; Sun, 11 Nov 2001 13:56:18 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Benjamin Sonntag To: ietf-calendar@imc.org Subject: Re: Synchronization issues Date: Sun, 11 Nov 2001 13:56:08 +0100 X-Mailer: KMail [version 1.3.1] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011111125618.D7C9632F5A@bakou.hn.org> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Le Samedi 10 Novembre 2001 14:29, vous avez écrit : Hello, > We are using vCalendar to store our web appointments locally in our MS > Outlook appointment books. This works well, but our clients now want to > be able to synchronize all our web appointments with their MS Outlook > appointment book. > Any ideas about our approach? My thought at this point is to have the > client do an EXPORT of their calendar information in CSV format and allow > us to import it into our web application, replacing duplicates and > finding items that are on the web site but not locally. Then we could > send the missing ones back to the client in via email with a vCalendar > attachment. Then they could import that vCalendar file. > > Is there a better way? There is, in fact, a better way, but it requires some software development. Your can create a small Visual Basic script that will be associated to a special extension (e.g. .vce for VCalendar Export) This script will use the Component Object Model, Outlook classes and Folders to add them to your Calendar. As a result you only need : 1. An adequate Visual Basic Script (.vbs) 2. A .reg file to associate this script to your extension. I already developped this type of script, and it worked pretty well. It was part of a MsAccess 2000 Project that authomatically updated the user's Outlook appointment books. You should create one that fit your needs. Regards Benjamin Sonntag From owner-ietf-calendar@mail.imc.org Mon Nov 12 09:57:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04293 for ; Mon, 12 Nov 2001 09:57:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fACENf303904 for ietf-calendar-bks; Mon, 12 Nov 2001 06:23:41 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fACENd803900 for ; Mon, 12 Nov 2001 06:23:40 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA15801; Mon Nov 12 09:21:20 2001 Subject: Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 12 Nov 2001 09:26:08 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/12/2001 09:26:09 AM, Serialize complete at 11/12/2001 09:26:09 AM Content-Type: text/plain; charset="us-ascii" To: ietf@ietf.org, "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug Royer wrote: >Why not just specify that dates/times are RFC2445 compliant? [...] >We decided on ONE format for date time based on ISO-8601 > > YYYYMMDDTHHMMSS [+/- ...] Not quite; RFC-2445 doesn't have the UTC offset. (See section 4.3.5 of RFC-2445; at the bottom of page 35, it says, "The form of date and time with UTC offset MUST NOT be used".) This was debated in the IMPP group; some suggested forgetting about timezones and just specifying that all timestamps had to be in UTC. The counterargument was that knowing somebody's timezone offset helps you guess whether he's likely to be in the office, etc. I did argue for using the pure-numeral form from RFC2445, until it was pointed out that we had to add the offset, which meant breaking compatibility with 2445 anyway. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |I used to belong to a solipsism club, but I got bored & voted| |everybody else out. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 12 10:09:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05083 for ; Mon, 12 Nov 2001 10:09:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fACEeCl04457 for ietf-calendar-bks; Mon, 12 Nov 2001 06:40:12 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fACEeB804453 for ; Mon, 12 Nov 2001 06:40:11 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA18818; Mon Nov 12 09:37:54 2001 Subject: Re: CAP TODO: single threaded MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 12 Nov 2001 09:42:42 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/12/2001 09:42:43 AM, Serialize complete at 11/12/2001 09:42:43 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >And I don't know of any Unix that can not do alarms well. No Unix does alarm() well. They all implement it with SIGALRM, and signals are purest evil. Once you start using them, you have to start worrying about signals interrupting system calls. Every *single* time you make a system call, you have to retry if it fails with errno==EINTR. This could be done, except that you're also calling into libraries, which also make system calls; and you have no control over those. >The API's to backend databases - from mSQL, MySQL, the GNU-SQL, >Oracle, and MANY others have nothing to-do with alarms. Many (all these?) >allow for submitting the query and going back later for the answer. Huh. Maybe; I've never seen the feature, but then I've never needed to look for it. >If your OS can't do OS alarms - then how will it ever handle iCal alarms? Multiple processes. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |============================================================| |The Player's Litany: The Wind is the Storm, and the Storm is| |Data, and the Data is Life. --Daniel Keys Moran | \============================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 12 10:17:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05639 for ; Mon, 12 Nov 2001 10:17:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fACEopw04856 for ietf-calendar-bks; Mon, 12 Nov 2001 06:50:51 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fACEoo804852 for ; Mon, 12 Nov 2001 06:50:50 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA22193; Mon Nov 12 09:48:33 2001 Subject: Re: MIME Multiple body parts (Was Re: uid...) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 12 Nov 2001 09:53:21 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/12/2001 09:53:22 AM, Serialize complete at 11/12/2001 09:53:22 AM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I agree. I am NOT saying it is a must for MUA's. I am saying >lets not limit ourselves to what MUA's can do today. OK, then we're in agreement: I just said it was risky. Probably that'll change. /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===========================================================| |A computer without Windows is like a chocolate cake without| |mustard. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 12 11:03:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08583 for ; Mon, 12 Nov 2001 11:03:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fACFc9E08284 for ietf-calendar-bks; Mon, 12 Nov 2001 07:38:09 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fACFc8808279 for ; Mon, 12 Nov 2001 07:38:08 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA03357; Mon Nov 12 10:35:51 2001 Subject: Re: CAP TODO - CRISP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 12 Nov 2001 10:40:40 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/12/2001 10:40:41 AM, Serialize complete at 11/12/2001 10:40:41 AM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug Royer wrote: >How about if a server sends out CRISP and not CAPVERSION, then >it is a CRISP server and not a CAP server. Mmm...we can do that. Then CRISP clients just have to know that a server that replies with CAPVERSION is a legitimate CRISP server even if it doesn't send a CRISP capability. (See, if you have a CRISP client, it should be able to talk to a regular CAP server; capabilities negotiation aside, CRISP is a subset of CAP.) If people agree with this approach, I can update the CRISP draft. We will still need changes to the CAP draft, to mention that "CRISP=1.0" is a legitimate alternative to "CAPVERSION=1.0, CAR=..., QUERYLEVEL=...". /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Amazing Fact: If there are three cats in a room, they will form a| |triangle! | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 12 14:43:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16284 for ; Mon, 12 Nov 2001 14:43:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fACJPMp25489 for ietf-calendar-bks; Mon, 12 Nov 2001 11:25:22 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fACJPL825484 for ; Mon, 12 Nov 2001 11:25:21 -0800 (PST) From: Robert_Ransdell@iris.com To: ietf-calendar@imc.org Subject: Fw: Re: MIME Multiple body parts (Was Re: uid...) MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10302001 Beta 4 October 30, 2001 Message-ID: Date: Mon, 12 Nov 2001 14:25:11 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_10252001|October 25, 2001) at 11/12/2001 02:21:00 PM Content-Type: multipart/mixed; boundary="=_mixed 006A2C5685256B02_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 006A2C5685256B02_= Content-Type: multipart/alternative; boundary="=_alternative 006A2C5685256B02_=" --=_alternative 006A2C5685256B02_= Content-Type: text/plain; charset="US-ASCII" ----- Forwarded by Robert Ransdell/Westford/IBM on 11/12/2001 02:19 PM ----- Steve Mansour Sent by: sman@netscape.com (Steve Mansour) 11/12/2001 01:49 PM To: Robert_Ransdell@iris.com cc: Subject: Re: MIME Multiple body parts (Was Re: uid...) I absolutely agree that we *should* have allowed for multiple UIDs in iTIP messages. As I said, I was overruled :-) Why did you not post this to the group? -STeve Robert_Ransdell@iris.com wrote: > > The one that would cause you a problem is posting a conference. For > example all the events at Lotussphere; In this case each event is a > different uid. The .ics stream is all the possible events at the > conference. > > sman > To: Robert Ransdell/Westford/IBM > 11/12/2001 12:37 > PM cc: > Subject: Re: MIME Multiple body > parts (Was Re: uid...) > > That should be no problem, right? The UID will still be the same. So > that doesn't violate the RFC as I read it. > > -Steve > > Robert Ransdell/Westford/IBM wrote: > > > You have to allow, at least, an iCalendar stream with multiple > VEvents to > > handle the case of an additional invitee to an already existing > repeating > > event where some of the individual events have been modified. > > > > > |---------+--------------------------------+-----------------------------------------------------------------------------------> > > | | sman | > | > > | | Sent by: | To: > ietf-calendar@imc.org | > > | | owner-ietf-calendar@m| cc: (bcc: > Robert Ransdell/Westford/IBM) | > > | | ail.imc.org | Subject: Re: > MIME Multiple body parts (Was Re: uid...) | > > | | | > | > > | | | > | > > | | 11/10/2001 12:35 AM | > | > > | | | > | > > > |---------+--------------------------------+-----------------------------------------------------------------------------------> > > >------------------------| > > | | > > >------------------------| > > > > Doug Royer wrote: > > > > > (I think Steve was sleeping when he sent his reply :-) > > > > that could be true, but see below... > > > > > Steve Mansour wrote: > > > > > > > > "Shannon J. Clark" wrote: > > > > > > > > > > There is a common trend to associate ONE MIME object holding > an > > iCalendar > > > > > object with ONE vEVENT (and perhaps a vTimezone object). In > fact I > > think > > > > > some vendors may ONLY deal with iCalendar objects that contain > only > > one > > > > > vEVENT. > > > > > > > > > > However it is clearly valid to have a vCalendar with multiple > vEVENT > > objects > > > > > (or else what are we doing here???) > > > > > > > > you'd think it would be clearly valid wouldnt you? Actually, > there was > > > > a very persuasive group of folks that wanted text/calendar mime > parts > > to > > > > only contain components with a single UID. And they won :-) > Have a > > > > look at the restriction tables in iTIP. For VEVENTs, where the > presence > > > > value is 1+, the text specifies that all components must have > the same > > > > UID. > > > > > > No: You can have multiple VEVENTS in one VCALENDAR each with > > > its own UID. > > > > > > BEGIN:VCALENDAR > > > ... > > > BEGIN:VEVENT > > > UID:1 > > > ... > > > END:VEVENT > > > BEGIN:EVENT > > > UID:2 > > > ... > > > END:VEVENT > > > END:VCALENDAR > > > > > > The restriction is per VEVENT, not PER VCALENDAR. > > > > Hmm... that's not the way I read RFC2446. Have a look at 3.2.2 > REQUEST. > > The > > restriction table says > > > > VEVENT 1+ All components MUST have the same > UID > > > > I take this to mean that in a REQUEST you can have 1 or more VEVENTs > but > > they all > > must have the same UID. How do others read this? > > > > -Steve > > (See attached file: sman.vcf) --=_alternative 006A2C5685256B02_= Content-Type: text/html; charset="US-ASCII"
----- Forwarded by Robert Ransdell/Westford/IBM on 11/12/2001 02:19 PM -----
Steve Mansour <sman@netscape.com>
Sent by: sman@netscape.com (Steve Mansour)

11/12/2001 01:49 PM

       
        To:        Robert_Ransdell@iris.com
        cc:        
        Subject:        Re: MIME Multiple body parts (Was Re: uid...)



I absolutely agree that we *should* have allowed for multiple UIDs in
iTIP messages.  As I said, I was overruled :-)

Why did you not post this to the group?

-STeve

Robert_Ransdell@iris.com wrote:
>
> The one that would cause you a problem is posting a conference.  For
> example all the events at Lotussphere;    In this case each event is a
> different uid.  The .ics stream is all the possible events at the
> conference.
>
>   sman
>                            To:        Robert Ransdell/Westford/IBM
>   11/12/2001 12:37 <Robert_Ransdell@iris.com>
>   PM                       cc:
>                            Subject:        Re: MIME Multiple body
>                    parts (Was Re: uid...)
>
> That should be no problem, right?  The UID will still be the same.  So
> that doesn't violate the RFC as I read it.
>
> -Steve
>
> Robert Ransdell/Westford/IBM wrote:
>
> > You have to allow, at least,  an iCalendar stream with multiple
> VEvents to
> > handle the case of an additional invitee to an already existing
> repeating
> > event where some of the individual events have been modified.
> >
> >
> |---------+--------------------------------+----------------------------------------------------------------------------------->
> > |         |           sman                 |
>                                                           |
> > |         |           Sent by:             |       To:
> ietf-calendar@imc.org                                             |
> > |         |           owner-ietf-calendar@m|       cc:       (bcc:
> Robert Ransdell/Westford/IBM)                               |
> > |         |           ail.imc.org          |       Subject:  Re:
> MIME Multiple body parts (Was Re: uid...)                     |
> > |         |                                |
>                                                           |
> > |         |                                |
>                                                           |
> > |         |           11/10/2001 12:35 AM  |
>                                                           |
> > |         |                                |
>                                                           |
> >
> |---------+--------------------------------+----------------------------------------------------------------------------------->
> >   >------------------------|
> >   |                        |
> >   >------------------------|
> >
> > Doug Royer wrote:
> >
> > > (I think Steve was sleeping when he sent his reply :-)
> >
> > that could be true, but see below...
> >
> > > Steve Mansour wrote:
> > > >
> > > > "Shannon J. Clark" wrote:
> > > > >
> > > > > There is a common trend to associate ONE MIME object holding
> an
> > iCalendar
> > > > > object with ONE vEVENT (and perhaps a vTimezone object). In
> fact I
> > think
> > > > > some vendors may ONLY deal with iCalendar objects that contain
> only
> > one
> > > > > vEVENT.
> > > > >
> > > > > However it is clearly valid to have a vCalendar with multiple
> vEVENT
> > objects
> > > > > (or else what are we doing here???)
> > > >
> > > > you'd think it would be clearly valid wouldnt you?  Actually,
> there was
> > > > a very persuasive group of folks that wanted text/calendar mime
> parts
> > to
> > > > only contain components with a single UID.  And they won :-)
>  Have a
> > > > look at the restriction tables in iTIP. For VEVENTs, where the
> presence
> > > > value is 1+, the text specifies that all components must have
> the same
> > > > UID.
> > >
> > > No:  You can have multiple VEVENTS in one VCALENDAR each with
> > > its own UID.
> > >
> > >         BEGIN:VCALENDAR
> > >         ...
> > >         BEGIN:VEVENT
> > >         UID:1
> > >         ...
> > >         END:VEVENT
> > >         BEGIN:EVENT
> > >         UID:2
> > >         ...
> > >         END:VEVENT
> > >         END:VCALENDAR
> > >
> > > The restriction is per VEVENT, not PER VCALENDAR.
> >
> > Hmm... that's not the way I read RFC2446.  Have a look at 3.2.2
> REQUEST.
> > The
> > restriction table says
> >
> >     VEVENT              1+      All components MUST have the same
> UID
> >
> > I take this to mean that in a REQUEST you can have 1 or more VEVENTs
> but
> > they all
> > must have the same UID.  How do others read this?
> >
> > -Steve
> > (See attached file: sman.vcf)
--=_alternative 006A2C5685256B02_=-- --=_mixed 006A2C5685256B02_= Content-Type: application/octet-stream; name="sman.vcf" Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOk1hbnNvdXI7U3RldmUNCngtbW96aWxsYS1odG1sOkZBTFNFDQphZHI7 ZG9tO3F1b3RlZC1wcmludGFibGU6Ozs1MDEgRWFzdCBNaWRkbGVmaWVsZCBSb2FkPTBEPTBBO01v dW50YWluIFZpZXc7Q0E7OTQwNDM7DQpvcmc6TmV0c2NhcGUNCnZlcnNpb246Mi4xDQplbWFpbDtp bnRlcm5ldDpzbWFuQG5ldHNjYXBlLmNvbQ0KdGl0bGU6SnVkZ2UsIEp1cnksIGFuZCBFeGVjdXRp b25lcg0KdGVsO2ZheDooNDE1KSA0MjgtNDA1OQ0KdGVsO3dvcms6KDQxNSkgOTM3LTIzNzgNCngt bW96aWxsYS1jcHQ6OzANCmZuOlN0ZXZlIE1hbnNvdXINCmVuZDp2Y2FyZA0K --=_mixed 006A2C5685256B02_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 12 14:57:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16633 for ; Mon, 12 Nov 2001 14:57:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fACJfMj26571 for ietf-calendar-bks; Mon, 12 Nov 2001 11:41:22 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fACJfL826566 for ; Mon, 12 Nov 2001 11:41:21 -0800 (PST) From: Robert_Ransdell@iris.com To: ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10302001 Beta 4 October 30, 2001 Message-ID: Date: Mon, 12 Nov 2001 14:41:03 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_10252001|October 25, 2001) at 11/12/2001 02:36:59 PM Content-Type: multipart/mixed; boundary="=_mixed 006BA08885256B02_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 006BA08885256B02_= Content-Type: multipart/alternative; boundary="=_alternative 006BA08885256B02_=" --=_alternative 006BA08885256B02_= Content-Type: text/plain; charset="US-ASCII" I think your code has to allow this because that was the most common use for vCalendar objects on the web. IE public events such as band schedules. Steve Mansour Sent by: sman@netscape.com (Steve Mansour) 11/12/2001 01:49 PM To: Robert_Ransdell@iris.com cc: Subject: Re: MIME Multiple body parts (Was Re: uid...) I absolutely agree that we *should* have allowed for multiple UIDs in iTIP messages. As I said, I was overruled :-) Why did you not post this to the group? -STeve Robert_Ransdell@iris.com wrote: > > The one that would cause you a problem is posting a conference. For > example all the events at Lotussphere; In this case each event is a > different uid. The .ics stream is all the possible events at the > conference. > > sman > To: Robert Ransdell/Westford/IBM > 11/12/2001 12:37 > PM cc: > Subject: Re: MIME Multiple body > parts (Was Re: uid...) > > That should be no problem, right? The UID will still be the same. So > that doesn't violate the RFC as I read it. > > -Steve > > Robert Ransdell/Westford/IBM wrote: > > > You have to allow, at least, an iCalendar stream with multiple > VEvents to > > handle the case of an additional invitee to an already existing > repeating > > event where some of the individual events have been modified. > > > > > |---------+--------------------------------+-----------------------------------------------------------------------------------> > > | | sman | > | > > | | Sent by: | To: > ietf-calendar@imc.org | > > | | owner-ietf-calendar@m| cc: (bcc: > Robert Ransdell/Westford/IBM) | > > | | ail.imc.org | Subject: Re: > MIME Multiple body parts (Was Re: uid...) | > > | | | > | > > | | | > | > > | | 11/10/2001 12:35 AM | > | > > | | | > | > > > |---------+--------------------------------+-----------------------------------------------------------------------------------> > > >------------------------| > > | | > > >------------------------| > > > > Doug Royer wrote: > > > > > (I think Steve was sleeping when he sent his reply :-) > > > > that could be true, but see below... > > > > > Steve Mansour wrote: > > > > > > > > "Shannon J. Clark" wrote: > > > > > > > > > > There is a common trend to associate ONE MIME object holding > an > > iCalendar > > > > > object with ONE vEVENT (and perhaps a vTimezone object). In > fact I > > think > > > > > some vendors may ONLY deal with iCalendar objects that contain > only > > one > > > > > vEVENT. > > > > > > > > > > However it is clearly valid to have a vCalendar with multiple > vEVENT > > objects > > > > > (or else what are we doing here???) > > > > > > > > you'd think it would be clearly valid wouldnt you? Actually, > there was > > > > a very persuasive group of folks that wanted text/calendar mime > parts > > to > > > > only contain components with a single UID. And they won :-) > Have a > > > > look at the restriction tables in iTIP. For VEVENTs, where the > presence > > > > value is 1+, the text specifies that all components must have > the same > > > > UID. > > > > > > No: You can have multiple VEVENTS in one VCALENDAR each with > > > its own UID. > > > > > > BEGIN:VCALENDAR > > > ... > > > BEGIN:VEVENT > > > UID:1 > > > ... > > > END:VEVENT > > > BEGIN:EVENT > > > UID:2 > > > ... > > > END:VEVENT > > > END:VCALENDAR > > > > > > The restriction is per VEVENT, not PER VCALENDAR. > > > > Hmm... that's not the way I read RFC2446. Have a look at 3.2.2 > REQUEST. > > The > > restriction table says > > > > VEVENT 1+ All components MUST have the same > UID > > > > I take this to mean that in a REQUEST you can have 1 or more VEVENTs > but > > they all > > must have the same UID. How do others read this? > > > > -Steve > > (See attached file: sman.vcf) --=_alternative 006BA08885256B02_= Content-Type: text/html; charset="US-ASCII"
I think your code has to  allow this because that was the most common use for vCalendar objects on the web.  IE public events such as band schedules.


Steve Mansour <sman@netscape.com>
Sent by: sman@netscape.com (Steve Mansour)

11/12/2001 01:49 PM

       
        To:        Robert_Ransdell@iris.com
        cc:        
        Subject:        Re: MIME Multiple body parts (Was Re: uid...)



I absolutely agree that we *should* have allowed for multiple UIDs in
iTIP messages.  As I said, I was overruled :-)

Why did you not post this to the group?

-STeve

Robert_Ransdell@iris.com wrote:
>
> The one that would cause you a problem is posting a conference.  For
> example all the events at Lotussphere;    In this case each event is a
> different uid.  The .ics stream is all the possible events at the
> conference.
>
>   sman
>                            To:        Robert Ransdell/Westford/IBM
>   11/12/2001 12:37 <Robert_Ransdell@iris.com>
>   PM                       cc:
>                            Subject:        Re: MIME Multiple body
>                    parts (Was Re: uid...)
>
> That should be no problem, right?  The UID will still be the same.  So
> that doesn't violate the RFC as I read it.
>
> -Steve
>
> Robert Ransdell/Westford/IBM wrote:
>
> > You have to allow, at least,  an iCalendar stream with multiple
> VEvents to
> > handle the case of an additional invitee to an already existing
> repeating
> > event where some of the individual events have been modified.
> >
> >
> |---------+--------------------------------+----------------------------------------------------------------------------------->
> > |         |           sman                 |
>                                                           |
> > |         |           Sent by:             |       To:
> ietf-calendar@imc.org                                             |
> > |         |           owner-ietf-calendar@m|       cc:       (bcc:
> Robert Ransdell/Westford/IBM)                               |
> > |         |           ail.imc.org          |       Subject:  Re:
> MIME Multiple body parts (Was Re: uid...)                     |
> > |         |                                |
>                                                           |
> > |         |                                |
>                                                           |
> > |         |           11/10/2001 12:35 AM  |
>                                                           |
> > |         |                                |
>                                                           |
> >
> |---------+--------------------------------+----------------------------------------------------------------------------------->
> >   >------------------------|
> >   |                        |
> >   >------------------------|
> >
> > Doug Royer wrote:
> >
> > > (I think Steve was sleeping when he sent his reply :-)
> >
> > that could be true, but see below...
> >
> > > Steve Mansour wrote:
> > > >
> > > > "Shannon J. Clark" wrote:
> > > > >
> > > > > There is a common trend to associate ONE MIME object holding
> an
> > iCalendar
> > > > > object with ONE vEVENT (and perhaps a vTimezone object). In
> fact I
> > think
> > > > > some vendors may ONLY deal with iCalendar objects that contain
> only
> > one
> > > > > vEVENT.
> > > > >
> > > > > However it is clearly valid to have a vCalendar with multiple
> vEVENT
> > objects
> > > > > (or else what are we doing here???)
> > > >
> > > > you'd think it would be clearly valid wouldnt you?  Actually,
> there was
> > > > a very persuasive group of folks that wanted text/calendar mime
> parts
> > to
> > > > only contain components with a single UID.  And they won :-)
>  Have a
> > > > look at the restriction tables in iTIP. For VEVENTs, where the
> presence
> > > > value is 1+, the text specifies that all components must have
> the same
> > > > UID.
> > >
> > > No:  You can have multiple VEVENTS in one VCALENDAR each with
> > > its own UID.
> > >
> > >         BEGIN:VCALENDAR
> > >         ...
> > >         BEGIN:VEVENT
> > >         UID:1
> > >         ...
> > >         END:VEVENT
> > >         BEGIN:EVENT
> > >         UID:2
> > >         ...
> > >         END:VEVENT
> > >         END:VCALENDAR
> > >
> > > The restriction is per VEVENT, not PER VCALENDAR.
> >
> > Hmm... that's not the way I read RFC2446.  Have a look at 3.2.2
> REQUEST.
> > The
> > restriction table says
> >
> >     VEVENT              1+      All components MUST have the same
> UID
> >
> > I take this to mean that in a REQUEST you can have 1 or more VEVENTs
> but
> > they all
> > must have the same UID.  How do others read this?
> >
> > -Steve
> > (See attached file: sman.vcf)

--=_alternative 006BA08885256B02_=-- --=_mixed 006BA08885256B02_= Content-Type: application/octet-stream; name="sman.vcf" Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOk1hbnNvdXI7U3RldmUNCngtbW96aWxsYS1odG1sOkZBTFNFDQphZHI7 ZG9tO3F1b3RlZC1wcmludGFibGU6Ozs1MDEgRWFzdCBNaWRkbGVmaWVsZCBSb2FkPTBEPTBBO01v dW50YWluIFZpZXc7Q0E7OTQwNDM7DQpvcmc6TmV0c2NhcGUNCnZlcnNpb246Mi4xDQplbWFpbDtp bnRlcm5ldDpzbWFuQG5ldHNjYXBlLmNvbQ0KdGl0bGU6SnVkZ2UsIEp1cnksIGFuZCBFeGVjdXRp b25lcg0KdGVsO2ZheDooNDE1KSA0MjgtNDA1OQ0KdGVsO3dvcms6KDQxNSkgOTM3LTIzNzgNCngt bW96aWxsYS1jcHQ6OzANCmZuOlN0ZXZlIE1hbnNvdXINCmVuZDp2Y2FyZA0K --=_mixed 006BA08885256B02_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 12 15:52:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18209 for ; Mon, 12 Nov 2001 15:52:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fACKaxd01030 for ietf-calendar-bks; Mon, 12 Nov 2001 12:36:59 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fACKat801019 for ; Mon, 12 Nov 2001 12:36:55 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id PAA23865; Mon Nov 12 15:34:37 2001 Subject: Re: MIME Multiple body parts (Was Re: uid...) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 12 Nov 2001 15:39:23 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/12/2001 03:39:27 PM, Serialize complete at 11/12/2001 03:39:27 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert_Ransdell wrote: >>I absolutely agree that we *should* have allowed for multiple UIDs in >>iTIP messages. As I said, I was overruled :-) >I think your code has to allow this because that was the most common use for vCalendar objects on the web. IE public events such as band schedules. I suspect you're talking about raw iCalendar objects, not iTIP messages. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |The plural of mongoose is polygoose. | \========================================================/ From owner-ietf-calendar@mail.imc.org Wed Nov 14 16:24:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17243 for ; Wed, 14 Nov 2001 16:24:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAEL4QN21652 for ietf-calendar-bks; Wed, 14 Nov 2001 13:04:26 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEL4P821644 for ; Wed, 14 Nov 2001 13:04:25 -0800 (PST) To: ietf-calendar@imc.org Subject: Posts missing/dropped (again) MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Wed, 14 Nov 2001 16:04:23 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/14/2001 04:10:53 PM, Serialize complete at 11/14/2001 04:10:53 PM Content-Type: multipart/alternative; boundary="=_alternative 0073455D85256B04_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073455D85256B04_= Content-Type: text/plain; charset="US-ASCII" Ok, I know Ive had problems w/posts not getting here but when I just checked the archives Im seeing that it too is missing posts. I was trying to get back into the WG backlog after a week long bug and I noticed that some of Dougs or Johns posts referred to postings I never got to either me or the archives. (I dont see Keith Moores cited posting nor did I see a couple other replys). Anyone else notice an apparent discontinuity in the threads at their end (or is it just my system and the archive server)?? 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 0073455D85256B04_= Content-Type: text/html; charset="US-ASCII"
Ok, I know Ive had problems w/posts not getting here but when I just checked the archives Im seeing that it too is missing posts.  I was trying to get back into the WG backlog after a week long bug and I noticed that some of Dougs or Johns posts referred to postings I never got to either me or the archives.  (I dont see Keith Moores cited posting nor did I see a couple other replys).  Anyone else notice an apparent discontinuity in the threads at their end (or is it just my system and the archive server)??

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 0073455D85256B04_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 16:27:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17315 for ; Wed, 14 Nov 2001 16:27:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAELEq422563 for ietf-calendar-bks; Wed, 14 Nov 2001 13:14:52 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAELEo822559 for ; Wed, 14 Nov 2001 13:14:50 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA21107; Wed, 14 Nov 2001 13:14:20 -0800 (PST) Message-ID: <3BF2DE9F.56D2E043@Royer.com> Date: Wed, 14 Nov 2001 14:14:07 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: "'Dawson Frank (NMP/Irving)'" , ietf@ietf.org, ietf-calendar@imc.org Subject: Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard References: <3CD14E451751BD42BA48AAA50B07BAD6C5FC56@vsvapostal3.prod.netsol.com> Content-Type: multipart/mixed; boundary="------------6916EBEBFF5ADD15B5EB22D9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6916EBEBFF5ADD15B5EB22D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Hollenbeck, Scott" wrote: . ... > > Yes, we should have a standard, but that standard should be usable across > the IETF. In the provreg WG, we're using XML Schema to specify a protocol > because XML and XML Schema provide needed extensibility features. I can't > use 2445-compliant date-time format because XML Schema won't accept it. Now I am confused, one of the formats in that draft is without dashes and spaces - then it is EXACTLY like RFC2445. So how can XML Schema handle them then? It looks like the draft is saying "this is the proposed standard including a version that XML can not use". So I would agree that there are different needs. That point does not seem to persuade me that a 3rd format should also be documented. > We can debate the merits (or detriments) of using non-IETF specified > technologies for IETF work, but that's not the issue at hand. The > Timestamps draft describes formats that can be used where 2445-format can't, > and at least in the case of the provreg WG that flexibility is needed. I also don't care if it is IETF or W3C work. I just don't see the need to create a proposed standard this is mostly like ISO, kind of like 2445, and you think would work with a (not yet?) recommended W3C proposal. My point is - what's the point? -Doug --------------6916EBEBFF5ADD15B5EB22D9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------6916EBEBFF5ADD15B5EB22D9-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 16:32:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17489 for ; Wed, 14 Nov 2001 16:32:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAELHp022851 for ietf-calendar-bks; Wed, 14 Nov 2001 13:17:51 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAELHo822846 for ; Wed, 14 Nov 2001 13:17:50 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA21181 for ; Wed, 14 Nov 2001 13:17:51 -0800 (PST) Message-ID: <3BF2DF71.7EF6C686@Royer.com> Date: Wed, 14 Nov 2001 14:17:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: single threaded References: Content-Type: multipart/mixed; boundary="------------2C65E5D8898614E25C317DDC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2C65E5D8898614E25C317DDC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >And I don't know of any Unix that can not do alarms well. > > No Unix does alarm() well. They all implement it with SIGALRM, and > signals are purest evil. Yes - you do think that :-) However, the WG decided for bounded latency a long time ago. --------------2C65E5D8898614E25C317DDC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------2C65E5D8898614E25C317DDC-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 16:35:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17571 for ; Wed, 14 Nov 2001 16:35:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAELKQ223094 for ietf-calendar-bks; Wed, 14 Nov 2001 13:20:26 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAELKP823089 for ; Wed, 14 Nov 2001 13:20:25 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA21249 for ; Wed, 14 Nov 2001 13:20:26 -0800 (PST) Message-ID: <3BF2E00C.8DD37AE9@Royer.com> Date: Wed, 14 Nov 2001 14:20:12 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO - CRISP References: Content-Type: multipart/mixed; boundary="------------21D73564E0DF3A73BE4E9220" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------21D73564E0DF3A73BE4E9220 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > > >How about if a server sends out CRISP and not CAPVERSION, then > >it is a CRISP server and not a CAP server. > > Mmm...we can do that. Then CRISP clients just have to know that a server > that replies with CAPVERSION is a legitimate CRISP server even if it > doesn't send a CRISP capability. (See, if you have a CRISP client, it > should be able to talk to a regular CAP server; capabilities negotiation > aside, CRISP is a subset of CAP.) > > If people agree with this approach, I can update the CRISP draft. We will > still need changes to the CAP draft, to mention that "CRISP=1.0" is a > legitimate alternative to "CAPVERSION=1.0, CAR=..., QUERYLEVEL=...". We can not mention CRISP in CAP unless they both go through the IETF process together. --------------21D73564E0DF3A73BE4E9220 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------21D73564E0DF3A73BE4E9220-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 17:01:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18769 for ; Wed, 14 Nov 2001 17:01:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAELfij24770 for ietf-calendar-bks; Wed, 14 Nov 2001 13:41:44 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAELfh824765 for ; Wed, 14 Nov 2001 13:41:43 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA21540 for ; Wed, 14 Nov 2001 13:41:44 -0800 (PST) Message-ID: <3BF2E501.9C9F7058@Royer.com> Date: Wed, 14 Nov 2001 14:41:22 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) References: <3BEB18DE.9F679F89@netscape.com> <3BEC5EE8.BBB97DAB@Royer.com> <3BECBC8D.F55294E6@netscape.com> Content-Type: multipart/mixed; boundary="------------745D5C26B6117938A6333150" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------745D5C26B6117938A6333150 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > Hmm... that's not the way I read RFC2446. Have a look at 3.2.2 REQUEST. The > restriction table says > > VEVENT 1+ All components MUST have the same UID > > I take this to mean that in a REQUEST you can have 1 or more VEVENTs > but they all must have the same UID. How do others read this? That's per METHOD. And iMIP (or iTIP) restricted all VCALENAR objects to the same METHOD per MIME body part. - So if you have to send multiple METHOD's, send one MIME object with multiple MIME body parts. There no restriction on non-iTIP METHODs. In fact that what (whoever it was)'s question. How to represent an entire calendar in iCalendar format for the purpose of copying or synchronizing calendars. And if someone placed that restriction in CAP - lets rip it out as there is not reason you can not do that. BEGIN:VCALENDAR METHOD:CREATE ... You should be able to create multiple VEVENTS, VTODO, and VJOURNAL components in one CUA -> CAP transfer. With iTIP one of the problems was with scheduling, replying to parts of a MIME body part. CAP METHOD:{CREATE,DELETE,...} would not have the same issues as we have included in the CAP replies, the information to know the problem or success results. -Doug --------------745D5C26B6117938A6333150 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------745D5C26B6117938A6333150-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 17:14:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19259 for ; Wed, 14 Nov 2001 17:14:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAEM2fC26694 for ietf-calendar-bks; Wed, 14 Nov 2001 14:02:41 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEM2e826690 for ; Wed, 14 Nov 2001 14:02:40 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21849; Wed, 14 Nov 2001 14:02:40 -0800 (PST) Message-ID: <3BF2E9DE.6F52B7B7@Royer.com> Date: Wed, 14 Nov 2001 15:02:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: Bruce_Kahn@iris.com Subject: Re: Posts missing/dropped (again) References: Content-Type: multipart/mixed; boundary="------------1A98746A4F36CAA833F42E0D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1A98746A4F36CAA833F42E0D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Several of the date-time draft were originally sent to the ietf-general list, I Cc'd ietf-calendar on my replies so this WG could get involved. Two of which I set the REPLY-TO back to this list so it would get off of the ietf-general list. I have not noticed any missing posts. -Doug Bruce_Kahn@iris.com wrote: > > Ok, I know Ive had problems w/posts not getting here but when I just checked > the archives Im seeing that it too is missing posts. I was trying to get > back into the WG backlog after a week long bug and I noticed that some of > Dougs or Johns posts referred to postings I never got to either me or the > archives. (I dont see Keith Moores cited posting nor did I see a couple > other replys). Anyone else notice an apparent discontinuity in the threads > at their end (or is it just my system and the archive server)?? > > 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... --------------1A98746A4F36CAA833F42E0D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------1A98746A4F36CAA833F42E0D-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 17:55:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20446 for ; Wed, 14 Nov 2001 17:55:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAEMdBt01601 for ietf-calendar-bks; Wed, 14 Nov 2001 14:39:11 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEMd9801593 for ; Wed, 14 Nov 2001 14:39:09 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id QAA04589 for ; Wed, 14 Nov 2001 16:37:53 -0600 From: "Shannon J. Clark" To: Subject: RE: MIME Multiple body parts (Was Re: uid...) Date: Wed, 14 Nov 2001 16:39:10 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BF2E501.9C9F7058@Royer.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, I believe it was I who posed the initial question: How to encapsulate an entire calendar for sync or copying purposes? In particular I noted that this appears to inherently assumed by the discussions about "local calendar store" vs. "remote calendar store" - unless it has been assumed that every entry in a calendar would be sent one entry at a time...??? Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Wednesday, November 14, 2001 3:41 PM Cc: ietf-calendar@imc.org Subject: Re: MIME Multiple body parts (Was Re: uid...) Steve Mansour wrote: > Hmm... that's not the way I read RFC2446. Have a look at 3.2.2 REQUEST. The > restriction table says > > VEVENT 1+ All components MUST have the same UID > > I take this to mean that in a REQUEST you can have 1 or more VEVENTs > but they all must have the same UID. How do others read this? That's per METHOD. And iMIP (or iTIP) restricted all VCALENAR objects to the same METHOD per MIME body part. - So if you have to send multiple METHOD's, send one MIME object with multiple MIME body parts. There no restriction on non-iTIP METHODs. In fact that what (whoever it was)'s question. How to represent an entire calendar in iCalendar format for the purpose of copying or synchronizing calendars. And if someone placed that restriction in CAP - lets rip it out as there is not reason you can not do that. BEGIN:VCALENDAR METHOD:CREATE ... You should be able to create multiple VEVENTS, VTODO, and VJOURNAL components in one CUA -> CAP transfer. With iTIP one of the problems was with scheduling, replying to parts of a MIME body part. CAP METHOD:{CREATE,DELETE,...} would not have the same issues as we have included in the CAP replies, the information to know the problem or success results. -Doug From owner-ietf-calendar@mail.imc.org Wed Nov 14 17:58:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20540 for ; Wed, 14 Nov 2001 17:58:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAEMiw902339 for ietf-calendar-bks; Wed, 14 Nov 2001 14:44:58 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEMiv802332 for ; Wed, 14 Nov 2001 14:44:57 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA22422 for ; Wed, 14 Nov 2001 14:44:58 -0800 (PST) Message-ID: <3BF2F39C.8C48F95D@Royer.com> Date: Wed, 14 Nov 2001 15:43:40 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAPABILITY/ITIPVERSION. 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 ITIPVERSION - Why is '0' instances allowed? I suggest '1'. -Doug From owner-ietf-calendar@mail.imc.org Wed Nov 14 18:19:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21020 for ; Wed, 14 Nov 2001 18:19:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAEMtH703196 for ietf-calendar-bks; Wed, 14 Nov 2001 14:55:17 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEMtG803192 for ; Wed, 14 Nov 2001 14:55:17 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA22568 for ; Wed, 14 Nov 2001 14:55:18 -0800 (PST) Message-ID: <3BF2F600.953AC7C3@Royer.com> Date: Wed, 14 Nov 2001 15:53:52 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: ALARMID to VALARM after stored? Content-Type: multipart/mixed; boundary="------------DEE65EA24BBF2847F2E4C08F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DEE65EA24BBF2847F2E4C08F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In the restriction table for METHOD:CREATE . . . . ALARMID 0 or 1 MUST be 1 if multiple VALARMs are present in same component. Issue? If a VEVENT is created with a VALARM that DOES NOT contain a ALARMID, what is the procedure for adding a new VALARM to that VEVENT? You just can't add one, you have for first modify the existing VALARM and add a ALARMID for it, so... I think we should declare that this is a '1' and not a '0 or 1'. Any CUA that gets a non-CAP object can easily add a ALARMID, but it would be a pain to add one later. -Doug --------------DEE65EA24BBF2847F2E4C08F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------DEE65EA24BBF2847F2E4C08F-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 18:20:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21084 for ; Wed, 14 Nov 2001 18:20:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAEN3l903883 for ietf-calendar-bks; Wed, 14 Nov 2001 15:03:47 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEN3k803878 for ; Wed, 14 Nov 2001 15:03:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA22705 for ; Wed, 14 Nov 2001 15:03:47 -0800 (PST) Message-ID: <3BF2F7F9.D7E69274@Royer.com> Date: Wed, 14 Nov 2001 16:02:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Server replies to CREATE Content-Type: multipart/mixed; boundary="------------54558669EB2BA10475E4069A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------54558669EB2BA10475E4069A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The restriction tables for CREATE server replies, needs to include UID (or ALARMID for VALARM) with the replies. Otherwise you could not discern which REQUEST-STATUS is for which object? VEVENT Example: . . . VEVENT 0+ add . . . . UID 1 The UID for which this add REQUEST-STATUS applies. . . . . REQUEST-STATUS 1+ . . . . * 0 No other VEVENT properties are present And it is needed for VTODO, VJOURNAL, and VALARM (with ALARMID). -Doug --------------54558669EB2BA10475E4069A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------54558669EB2BA10475E4069A-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 18:32:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21433 for ; Wed, 14 Nov 2001 18:32:23 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAENIgI05079 for ietf-calendar-bks; Wed, 14 Nov 2001 15:18:42 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAENIg805075 for ; Wed, 14 Nov 2001 15:18:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA22920 for ; Wed, 14 Nov 2001 15:18:43 -0800 (PST) Message-ID: <3BF2FB71.C9C72F03@Royer.com> Date: Wed, 14 Nov 2001 16:17:05 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Creating new components Content-Type: multipart/mixed; boundary="------------4851381916042E78F3083229" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4851381916042E78F3083229 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IN: 7.2.1.2.1 Creating New Calendars It says: The response contains the calendar (CALID) and UID of the component so that the CUA can match up the TARGET from multiple objects created on multiple calendars (TARGETs). Yet the example above it is missing the UID. --------------4851381916042E78F3083229 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------4851381916042E78F3083229-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 18:33:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21465 for ; Wed, 14 Nov 2001 18:33:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAENEPg04718 for ietf-calendar-bks; Wed, 14 Nov 2001 15:14:25 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAENEO804712 for ; Wed, 14 Nov 2001 15:14:24 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA22851 for ; Wed, 14 Nov 2001 15:14:25 -0800 (PST) Message-ID: <3BF2FA71.21E811C3@Royer.com> Date: Wed, 14 Nov 2001 16:12:49 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CREATE calendar - confused. Content-Type: multipart/mixed; boundary="------------1572B642C41392252E62B492" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1572B642C41392252E62B492 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IN: 7.2.1.2.1 Creating New Calendars ... C: SENDDATA C: CONTENT-TYPE: text/calendar; method=CREATE; C: component=VCOMMAND C: Content-Transfer-Encoding:7bit C: C: BEGIN:VCAP C: VERSION:2.1 C: BEGIN:VCOMMAND C: METHOD:CREATE C: TARGET:cap://cal.example.com/ C: TARGET:relcal4 C: BEGIN:VAGENDA C: RELCALID:relcalz1 Does this mean that you are creating TWO calendars? One cap://cal.example.com/relcalz2 And relcalz1/relcalz2 C: NAME;LANGUAGE=EN-us:Bill's Soccer Team C: OWNER:bill C: CALMASTER:mailto:bill@example.com C: TZID:US_PST C: END:VAGENDA C: BEGIN:VAGENDA C: RELCALID:relcalz2 C: NAME;LANGUAGE=EN-us:Mary's personal calendar C: OWNER:mary C: CALMASTER:mailto:mary@example.com C: TZID:US_PST C: END:VAGENDA C: END:VCOMMAND C: END:VCAP C: . S: 2.0 S: . S: Content-Type:text/calendar; method=RESPONSE; S: OPTINFO="CMDID:abcde" # This 2.0 is the transport reply status and ends with a # CRLF.CRLF (below) S: BEGIN:VCAP S: METHOD:RESPONSE S: TARGET:cap://cal.example.com/ <--- S: REQUEST-STATUS:2.0 S: END:VCAP S: BEGIN:VCAP S: METHOD:RESPONSE <--- Why no TARGET for 2nd create? S: REQUEST-STATUS:2.0 S: END:VCAP S: . AND I thought we agreed that ALL target replies would the the FULL CAL-ID: TARGET:cap://cal.example.com/relcalz2 --------------1572B642C41392252E62B492 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------1572B642C41392252E62B492-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 18:55:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21958 for ; Wed, 14 Nov 2001 18:55:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAENi0U06870 for ietf-calendar-bks; Wed, 14 Nov 2001 15:44:00 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAENhw806865 for ; Wed, 14 Nov 2001 15:43:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA23270 for ; Wed, 14 Nov 2001 15:44:00 -0800 (PST) Message-ID: <3BF30154.13D54329@Royer.com> Date: Wed, 14 Nov 2001 16:42:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: From CAP DELETE... Content-Type: multipart/mixed; boundary="------------A369C926A0A80F57DABBB528" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A369C926A0A80F57DABBB528 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [EDITORS NOTE: Issues: - Currently CAP requires that the server return a response status. However, if there are multiple components deleted, should the UID also be returned? Yes! - VQUERY EXPAND and MAXSIZE parameters do not seem to apply to deletion? For DELETE - EXPAND has no meaning... Some implementors were talking about expanding recurring VEVENTs as the store them (vs expanding them when queried). So it does bring up a good point. However, you would be deleting by date range or UID (all). Deleting a VEVENT by UID would result in ONE reply as no matter how the CS stores the VEVENT, there is only ONE VEVENT with that UID. Deleting a VEVENT by date/range would be done with a MODIFY and not a DELETE - you would get one reply. You DELETE COMPONENTS (or calendars) - not instances of recurrence. And for MAXSIZE: Deleting with something like 'all VEVENTs where ATTENDEE contains user-x' could return N number of replies. So it does sound like a good idea - as long as the CUA knows that it can not specify which N are deleted. The CUA would then have to re-issue the DELETE METHOD - over and over? ** WE NEED A STATEMENT in CAP that says that commands issued with a MAXSIZE limit MUST BE be repeatedly called until the end is reached as there is no way to tell which 'N-number' of components were acted upon. And that failure to do this probably will result in undesired effects. - Can one use DELETE to remove all VALARMs and VTIMEZONEs that match a certain search criteria and that belong to all components, event though VALARMs and VTIMEZONEs never exist as independent components? Or should one use MODIFY? If they can be deleted, do we return the REQUEST-STATUS of their deletion in a VEVENT or separately? VALARMS should have a ALARMID (see my previous post). VTIMEZONEs have an id. MODIFY - tricky, as a VALARM and VTIMEZONE have a minimum set of properties - how could you delete the contents of one of them, unless you declare that when you do is is the same as DELETE. So why should we have two ways to do the same thing? - In the example in CAP where a calendar is deleted all the server returns is 2.0, nothing else? I would say the TARGET should be returned also - or PIPELINING is busted. - We should not be able to delete any VFREEBUSY components? I had always assumed that a CS would calculate a VFREEBUSY. Also a CS VFREEBUSY returned value could be an accumulation of information stored. So how could you delete that? On the other hand - if you can store it - you must be able to delete it? - Currently one can not delete a VAGENDA and some other component in the same DELETE command. This seems OK. Anyone see any need to be able to do this? I agree. - Should the MAXRESULTS property of VQUERY apply to deletion? We can use it to delete only the first n components that match. ] Then delete by date range if that is what you want. Otherwise there is no way to know which N instances you deleted. (see above). -Doug --------------A369C926A0A80F57DABBB528 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------A369C926A0A80F57DABBB528-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 19:05:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22201 for ; Wed, 14 Nov 2001 19:05:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAENojp07426 for ietf-calendar-bks; Wed, 14 Nov 2001 15:50:45 -0800 (PST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAENoh807420 for ; Wed, 14 Nov 2001 15:50:43 -0800 (PST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id SAA24468; Wed, 14 Nov 2001 18:49:38 -0500 (EST) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4VQ8TY8R>; Wed, 14 Nov 2001 18:48:14 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD6C5FC73@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Doug Royer'" Cc: ietf@ietf.org, "'ietf-calendar@imc.org'" Subject: RE: Last Call: Date and Time on the Internet: Timestamps to Propo sed Standard Date: Wed, 14 Nov 2001 18:41:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Doug Royer [mailto:Doug@royer.com] > Sent: Wednesday, November 14, 2001 4:14 PM > To: Hollenbeck, Scott > Cc: 'Dawson Frank (NMP/Irving)'; ietf@ietf.org; ietf-calendar@imc.org > Subject: Re: Last Call: Date and Time on the Internet: Timestamps to > Proposed Standard > > > > > "Hollenbeck, Scott" wrote: > . ... > > > > Yes, we should have a standard, but that standard should be > usable across > > the IETF. In the provreg WG, we're using XML Schema to > specify a protocol > > because XML and XML Schema provide needed extensibility > features. I can't > > use 2445-compliant date-time format because XML Schema > won't accept it. > > Now I am confused, one of the formats in that draft is without > dashes and spaces - then it is EXACTLY like RFC2445. > So how can XML Schema handle them then? It looks like the draft > is saying "this is the proposed standard including a version > that XML can not use". True, the draft specifies a format that is exactly like the 2445 format. That's good, it doesn't preclude the earlier work. It also specifies another format (the "extended" format) that _does_ work with XML Schema. I believe that's good as well. > So I would agree that there are different needs. That point > does not seem to persuade me that a 3rd format should also be > documented. > > > We can debate the merits (or detriments) of using non-IETF specified > > technologies for IETF work, but that's not the issue at hand. The > > Timestamps draft describes formats that can be used where > 2445-format can't, > > and at least in the case of the provreg WG that flexibility > is needed. > > I also don't care if it is IETF or W3C work. I just don't see the > need to create a proposed standard this is mostly like ISO, kind > of like 2445, and you think would work with a (not yet?) recommended > W3C proposal. My point is - what's the point? XML Schema is a W3C Recommendation as of 2 May 2001 (reference provided in three parts below). It's being used in other IETF work. In that other work I currently have to cite an ISO document as the normative date-time format reference. I can cite the Timestamps draft if it becomes an RFC. I can't cite 2445. Maybe citing an ISO document isn't a big deal, but I'd rather cite a freely available RFC if I could. -Scott- [1] http://www.w3.org/TR/xmlschema-0/ [2] http://www.w3.org/TR/xmlschema-1/ [3] http://www.w3.org/TR/xmlschema-2/ From owner-ietf-calendar@mail.imc.org Wed Nov 14 19:13:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22363 for ; Wed, 14 Nov 2001 19:13:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAENuJw07979 for ietf-calendar-bks; Wed, 14 Nov 2001 15:56:19 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAENuI807974 for ; Wed, 14 Nov 2001 15:56:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA23421 for ; Wed, 14 Nov 2001 15:56:19 -0800 (PST) Message-ID: <3BF30434.78007D47@Royer.com> Date: Wed, 14 Nov 2001 16:54:28 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: MODIFY restriction table... Content-Type: multipart/mixed; boundary="------------1529D6462BE49320171E14E9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1529D6462BE49320171E14E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (I included some cut-paste text from CAP) I think they MUST BE changed per my comments. This would be removed. . . . METHOD 1 <> These would be '0 or 1' or '0+', if they are not being changed with the MODIFY method - they MUST NOT be included (EXCEPT UID which CAN NOT BE CHANGED and ALARMID - which CAN NOT BE CHANGED). . . . OWNER 1+ . . . RELCALID 1 . . . QUERYNAME 1 . . . QUERY 1 . . . SUMMARY 1 Can be null . . . DTSTAMP 1 . . . DTSTART 1 . . . ORGANIZER 1 . . . . ACTION 1 . . . . TRIGGER 1 . . . METHOD 1 <> . . . ORGANIZER 1 . . . PRIORITY 1 . . . . . TZOFFSET 1 . . . . . TZOFFSETFROM 1 . . . . . TZOFFSETTO 1 . . . TZID 1 These MUST BE '1' and CAN NOT BE CHANGED by the MODIFY command. . . . UID 1 If ANY VALARM is being modified - MUST BE '1' and CAN NOT BE CHANGED by the MODIFY command. . . . . ALARMID 0 or 1 MUST be 1 if multiple VALARMs are present in same component. --------------1529D6462BE49320171E14E9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------1529D6462BE49320171E14E9-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 22:17:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25949 for ; Wed, 14 Nov 2001 22:17:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAF31OC22990 for ietf-calendar-bks; Wed, 14 Nov 2001 19:01:24 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAF31M822984 for ; Wed, 14 Nov 2001 19:01:22 -0800 (PST) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Posts missing/dropped (again) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 14 Nov 2001 22:01:20 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/14/2001 10:01:24 PM, Serialize complete at 11/14/2001 10:01:24 PM Content-Type: multipart/alternative; boundary="=_alternative 0010AD5685256B05_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0010AD5685256B05_= Content-Type: text/plain; charset="us-ascii" Bruce, I sent a note to John asking for the text of the full note from Keith. I think it appeared on another list. So, you're not imaging missing notes - they were missing - at least from our List. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bruce_Kahn@iris.com Sent by: owner-ietf-calendar@mail.imc.org 11/14/01 16:04 To: ietf-calendar@imc.org cc: Subject: Posts missing/dropped (again) Ok, I know Ive had problems w/posts not getting here but when I just checked the archives Im seeing that it too is missing posts. I was trying to get back into the WG backlog after a week long bug and I noticed that some of Dougs or Johns posts referred to postings I never got to either me or the archives. (I dont see Keith Moores cited posting nor did I see a couple other replys). Anyone else notice an apparent discontinuity in the threads at their end (or is it just my system and the archive server)?? 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 0010AD5685256B05_= Content-Type: text/html; charset="us-ascii"
Bruce, I sent a note to John asking for the text of the full note from Keith.  I think it appeared on another list.  So, you're not imaging missing notes - they were missing - at least from our List.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

11/14/01 16:04

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Posts missing/dropped (again)




Ok, I know Ive had problems w/posts not getting here but when I just checked the archives Im seeing that it too is missing posts.  I was trying to get back into the WG backlog after a week long bug and I noticed that some of Dougs or Johns posts referred to postings I never got to either me or the archives.  (I dont see Keith Moores cited posting nor did I see a couple other replys).  Anyone else notice an apparent discontinuity in the threads at their end (or is it just my system and the archive server)??

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 0010AD5685256B05_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 14 23:50:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28182 for ; Wed, 14 Nov 2001 23:50:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAF4bLj01267 for ietf-calendar-bks; Wed, 14 Nov 2001 20:37:21 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAF4bK801261 for ; Wed, 14 Nov 2001 20:37:20 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fAF4bGY05145 for ; Wed, 14 Nov 2001 20:37:16 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMTRI600.S0E for ; Wed, 14 Nov 2001 20:37:18 -0800 Message-ID: <3BF347FC.4D780C59@netscape.com> Date: Wed, 14 Nov 2001 20:43:40 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MIME Multiple body parts (Was Re: uid...) References: <3BEB18DE.9F679F89@netscape.com> <3BEC5EE8.BBB97DAB@Royer.com> <3BECBC8D.F55294E6@netscape.com> <3BF2E501.9C9F7058@Royer.com> Content-Type: multipart/mixed; boundary="------------285DC0D07BE5D812DBD9867B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------285DC0D07BE5D812DBD9867B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > Hmm... that's not the way I read RFC2446. Have a look at 3.2.2 REQUEST. The > > restriction table says > > > > VEVENT 1+ All components MUST have the same UID > > > > I take this to mean that in a REQUEST you can have 1 or more VEVENTs > > but they all must have the same UID. How do others read this? > > That's per METHOD. And iMIP (or iTIP) restricted all VCALENAR objects > to the same METHOD per MIME body part. - So if you have to > send multiple METHOD's, send one MIME object with multiple > MIME body parts. yes. exactly. you just have to send multiple mime parts. But again, that means only one UID per VCALENDAR object in iTIP. > There no restriction on non-iTIP METHODs. In fact that what (whoever it was)'s > question. How to represent an entire calendar in iCalendar format for the purpose > of copying or synchronizing calendars. > > And if someone placed that restriction in CAP - lets rip it out as > there is not reason you can not do that. agreed. There is no such restriction in CAP as far as I know. > > > BEGIN:VCALENDAR > METHOD:CREATE > ... > > You should be able to create multiple VEVENTS, VTODO, and VJOURNAL > components in one CUA -> CAP transfer. yep -Steve --------------285DC0D07BE5D812DBD9867B 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 --------------285DC0D07BE5D812DBD9867B-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 00:06:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28342 for ; Thu, 15 Nov 2001 00:06:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAF4tPw02555 for ietf-calendar-bks; Wed, 14 Nov 2001 20:55:25 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAF4tO802550 for ; Wed, 14 Nov 2001 20:55:24 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fAF4tKY14437 for ; Wed, 14 Nov 2001 20:55:20 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMTSCA00.QZQ for ; Wed, 14 Nov 2001 20:55:22 -0800 Message-ID: <3BF34C38.D76F858B@netscape.com> Date: Wed, 14 Nov 2001 21:01:44 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: <3BF2F600.953AC7C3@Royer.com> Content-Type: multipart/mixed; boundary="------------350CF13C504104F000D66CBA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------350CF13C504104F000D66CBA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > In the restriction table for METHOD:CREATE > > . . . . ALARMID 0 or 1 MUST be 1 if multiple > VALARMs are present in > same component. > > Issue? > > If a VEVENT is created with a VALARM that DOES NOT contain > a ALARMID, what is the procedure for adding a new VALARM > to that VEVENT? You just can't add one, you have for first > modify the existing VALARM and add a ALARMID for it, so... > > I think we should declare that this is a '1' and not > a '0 or 1'. Any CUA that gets a non-CAP object can > easily add a ALARMID, but it would be a pain to add > one later. I agree. I think it is far simpler to just always add the alarmid. I'll make the update. If anyone has any objections let's go through it on the list. (we can always pull it out later if someone comes up with a good reason for NOT having an alarm id). For people who are concerned about small-footprint devices not being able to generate guids, remember that is why we added the GENERATEUID command. You can always ask the server to generate them for you. -Steve --------------350CF13C504104F000D66CBA 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 --------------350CF13C504104F000D66CBA-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 00:07:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28357 for ; Thu, 15 Nov 2001 00:07:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAF4ohZ02176 for ietf-calendar-bks; Wed, 14 Nov 2001 20:50:43 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAF4of802171 for ; Wed, 14 Nov 2001 20:50:41 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fAF4ocY11427 for ; Wed, 14 Nov 2001 20:50:38 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMTS4G00.A8Y for ; Wed, 14 Nov 2001 20:50:40 -0800 Message-ID: <3BF34B1E.2977511F@netscape.com> Date: Wed, 14 Nov 2001 20:57:02 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAPABILITY/ITIPVERSION. References: <3BF2F39C.8C48F95D@Royer.com> Content-Type: multipart/mixed; boundary="------------EC0A202DF34B893FD49E2CE9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EC0A202DF34B893FD49E2CE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > ITIPVERSION - Why is '0' instances allowed? > I suggest '1'. Where did you find this? I just pulled the latest cap.xml. I could only find ITIPVERSION 0 or 1 -Steve --------------EC0A202DF34B893FD49E2CE9 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 --------------EC0A202DF34B893FD49E2CE9-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 10:46:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29058 for ; Thu, 15 Nov 2001 10:46:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFFW8t04193 for ietf-calendar-bks; Thu, 15 Nov 2001 07:32:08 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFFW6804189 for ; Thu, 15 Nov 2001 07:32:07 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA08613; Thu Nov 15 10:29:28 2001 Subject: Re: CAP TODO - CRISP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 15 Nov 2001 10:34:23 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/15/2001 10:34:34 AM, Serialize complete at 11/15/2001 10:34:34 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug wrote: >We can not mention CRISP in CAP unless they both go through the >IETF process together. Is that a problem? CRISP is a pretty simple document; I'd be surprised if it held back CAP. If it did pose a threat, we could disentagle them at the time. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=============================================================| |*BOOM* "Thank you, Beaker. Now we know that is definitely too| |much gunpowder." -- Dr. Bunsen Honeydew | \=============================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 15 10:50:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29324 for ; Thu, 15 Nov 2001 10:50:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFFUhT04122 for ietf-calendar-bks; Thu, 15 Nov 2001 07:30:43 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFFUe804117 for ; Thu, 15 Nov 2001 07:30:40 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA08446; Thu Nov 15 10:28:18 2001 Subject: Re: CAP TODO: single threaded MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 15 Nov 2001 10:33:13 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/15/2001 10:33:24 AM, Serialize complete at 11/15/2001 10:33:24 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >However, the WG decided for bounded latency a long time ago. I actually can't find such a decision in the archives. Key points: * The first mention of bounded latency is in ietf-calsch-rtreq-00.txt, posted in March 1997 (http://www.imc.org/ietf-calendar/archive1/msg00906.html); it includes a requirement for bounded latency. However, there is no explanation for this requirement, nor, as near as I can tell, was there consensus on it on the list; see, for example, , where Einar Stefferud takes the position that a realtime requirement is not achievable in general. The ensuing thread includes support from various people (e.g., John Klensin, , and Bob Mahoney, ). * In April 1997, the notes from the Memphis meeting (http://www.imc.org/ietf-calendar/archive1/msg00970.html) indicate that the sense of the meeting had been that bounded latency was not needed, and asks for consensus from the list. * Bounded latency is not mentioned again on the list until May 1998 (http://www.imc.org/ietf-calendar/archive1/msg02569.html), when Steve mentions that, as of the LA meeting, he got the sense from people that bounded latency "was not really an issue". * The next time bounded latency is mentioned is in ietf-draft-calsch-irip-04.txt, posted in March 1999 (http://www.imc.org/ietf-calendar/archive1/msg02940.html), which contains the feature. As near as I can tell, it was added with no discussion on the list. * The first version of CAP (http://www.egenconsulting.com/cap.txt) was posted in June 1999; it seems to have inherited bounded latency from iRIP. Again, I cannot find discussion on the list supporting it. * I haven't dug through the archives past this point; but I have been in the group since January 1999, and I do not remember any active decision in favor of bounded latency. So. It may be true that the people writing the iRIP and CAP documents decided on bounded latency a long time ago; but, if it was not discussed on the list, the WG has not decided. Can anybody explain to me whom bounded latency is supposed to benefit? It wastes CS resources to cancel a request that's taken too long; it complicates the protocol for implementors; and it impairs usability by complicating the user's view of the system. /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Belief is not relevant to truth. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 15 12:27:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05940 for ; Thu, 15 Nov 2001 12:27:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFHDut13636 for ietf-calendar-bks; Thu, 15 Nov 2001 09:13:56 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFHDt813630 for ; Thu, 15 Nov 2001 09:13:55 -0800 (PST) From: Bruce_Kahn@iris.com To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: CAP TODO: single threaded MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: Date: Thu, 15 Nov 2001 12:13:15 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/15/2001 12:28:27 PM, Serialize complete at 11/15/2001 12:28:27 PM Content-Type: multipart/alternative; boundary="=_alternative 005E258B85256B05_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E258B85256B05_= Content-Type: text/plain; charset="US-ASCII" John replied: > because the APIs used >to access the backend database are typically blocking calls. That all depends on what your CS uses for a back end store/API. I know of at least 1 API that is built so that calls can be done async for some stuff.. :^b Sorry, couldnt resist that one while playing 'resync my archives'... 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 005E258B85256B05_= Content-Type: text/html; charset="US-ASCII"
John replied:
>                                    because the APIs used
>to access the backend database are typically blocking calls.

That all depends on what your CS uses for a back end store/API.   I know of at least 1 API that is built so that calls can be done async for some stuff..  :^b

Sorry, couldnt resist that one while playing 'resync my archives'...

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 005E258B85256B05_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 12:34:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06418 for ; Thu, 15 Nov 2001 12:34:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFHATW13237 for ietf-calendar-bks; Thu, 15 Nov 2001 09:10:29 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFHAS813233 for ; Thu, 15 Nov 2001 09:10:28 -0800 (PST) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Re: CAP TODO: single threaded MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_10292001 Beta 4 October 29, 2001 Message-ID: Date: Thu, 15 Nov 2001 12:09:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/15/2001 12:24:59 PM, Serialize complete at 11/15/2001 12:24:59 PM Content-Type: multipart/alternative; boundary="=_alternative 005DD0DE85256B05_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DD0DE85256B05_= Content-Type: text/plain; charset="US-ASCII" Doug responded: > I always said if the CUA >does not want to wait, it can cancel the request. This does not work if the CS does not read the 'cancel' request off the wire, your "(b)" case. The CUA has no way to cancel the command in progress unless the CS does read the requests off the wire and 'queues' them up (a variant of your "(b.1)" which allows a command cancellation to have a higher priority than other commands that would be pended.) 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 005DD0DE85256B05_= Content-Type: text/html; charset="US-ASCII"
Doug responded:
>                        I always said if the CUA
>does not want to wait, it can cancel the request.

This does not work if the CS does not read the 'cancel' request off the wire, your "(b)" case.  The CUA has no way to cancel the command in progress unless the CS does read the requests off the wire and 'queues' them up (a variant of your "(b.1)" which allows a command cancellation to have a higher priority than other commands that would be pended.)

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 005DD0DE85256B05_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 13:45:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10962 for ; Thu, 15 Nov 2001 13:45:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFIT6h17083 for ietf-calendar-bks; Thu, 15 Nov 2001 10:29:06 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFIT5817078 for ; Thu, 15 Nov 2001 10:29:05 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA08587 for ; Thu, 15 Nov 2001 13:29:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA08003 for ; Thu, 15 Nov 2001 13:25:23 -0500 (EST) Received: from [66.92.67.186] (airport.bobmah.com [66.92.67.186]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA14435 for ; Thu, 15 Nov 2001 13:25:21 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Thu, 15 Nov 2001 13:25:14 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Some recent internationalization drafts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For those who might have missed them in the past, there are two recent draft revisions that bear on our efforts to address internationalization in our drafts. Recommended reading... -Bob "Terminology Used in Internationalization in the IETF" http://www.ietf.org/internet-drafts/draft-hoffman-i18n-terms-03.txt "Protocol Redesigner's Handbook? volume i18n Guidelines for internationalization of protocols" http://www.ietf.org/internet-drafts/draft-alvestrand-i18n-howto-01.txt From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:05:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20506 for ; Thu, 15 Nov 2001 16:05:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFKm5G23762 for ietf-calendar-bks; Thu, 15 Nov 2001 12:48:05 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFKm4823756 for ; Thu, 15 Nov 2001 12:48:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA10442 for ; Thu, 15 Nov 2001 12:48:05 -0800 (PST) Message-ID: <3BF429F3.E6BD8E4B@Royer.com> Date: Thu, 15 Nov 2001 13:47:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAPABILITY/ITIPVERSION. References: <3BF2F39C.8C48F95D@Royer.com> <3BF34B1E.2977511F@netscape.com> Content-Type: multipart/mixed; boundary="------------CBDDE89C8AA20811E6E6321D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CBDDE89C8AA20811E6E6321D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Same difference, '0' should not be allowed. Steve Mansour wrote: > > Doug Royer wrote: > > > ITIPVERSION - Why is '0' instances allowed? > > I suggest '1'. > > Where did you find this? I just pulled the latest cap.xml. I could > only find > > ITIPVERSION 0 or 1 > > -Steve --------------CBDDE89C8AA20811E6E6321D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------CBDDE89C8AA20811E6E6321D-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:20:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21417 for ; Thu, 15 Nov 2001 16:20:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFL29624598 for ietf-calendar-bks; Thu, 15 Nov 2001 13:02:09 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFL28824594 for ; Thu, 15 Nov 2001 13:02:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA10654 for ; Thu, 15 Nov 2001 13:02:09 -0800 (PST) Message-ID: <3BF42D3E.84EE3BFF@Royer.com> Date: Thu, 15 Nov 2001 14:01:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: <3BF2F600.953AC7C3@Royer.com> <3BF34C38.D76F858B@netscape.com> Content-Type: multipart/mixed; boundary="------------449C5CB18A80202180F6D516" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------449C5CB18A80202180F6D516 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > For people who are concerned about small-footprint devices not being > able to generate guids, remember that is why we added the GENERATEUID > command. You can always ask the server to generate them for you. ALARMID != UID, but you could use it for that I guess. And in I can not find the definition of ALARMID in CAP. NEW TODO - add definition if ALARMID to CAP? --------------449C5CB18A80202180F6D516 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------449C5CB18A80202180F6D516-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:29:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21913 for ; Thu, 15 Nov 2001 16:29:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFLBEg25199 for ietf-calendar-bks; Thu, 15 Nov 2001 13:11:14 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLBC825195 for ; Thu, 15 Nov 2001 13:11:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA10800 for ; Thu, 15 Nov 2001 13:11:13 -0800 (PST) Message-ID: <3BF42F5D.689047F1@Royer.com> Date: Thu, 15 Nov 2001 14:10:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: single threaded References: Content-Type: multipart/mixed; boundary="------------21A981BB5983C80EF7CC065A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------21A981BB5983C80EF7CC065A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > Doug responded: > > I always said if the CUA > >does not want to wait, it can cancel the request. > > This does not work if the CS does not read the 'cancel' request off the > wire, your "(b)" case. The CUA has no way to cancel the command in > progress unless the CS does read the requests off the wire and 'queues' > them up (a variant of your "(b.1)" which allows a command > cancellation to have a higher > priority than other commands that would be pended.) I think we agree. If the CS has PIPELINE set to '1', then the CS is telling the CUA it is not going to read the request until the current command is completed. Maybe we should say that in CAP: In order to support bound latency then PIPELINE MUST BE set to '2' or higher. If the CS can not support this, you can't use bound latency. This is not a new restriction, it just describes the issue. -Doug --------------21A981BB5983C80EF7CC065A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------21A981BB5983C80EF7CC065A-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:29:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21924 for ; Thu, 15 Nov 2001 16:29:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFL8kc24979 for ietf-calendar-bks; Thu, 15 Nov 2001 13:08:46 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFL8i824974 for ; Thu, 15 Nov 2001 13:08:44 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id QAA12897; Thu Nov 15 16:06:24 2001 Subject: Re: CAP TODO: single threaded MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 15 Nov 2001 16:11:15 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/15/2001 04:11:31 PM, Serialize complete at 11/15/2001 04:11:31 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Stracke wrote: >> Can anybody explain to me whom bounded latency is supposed to benefit? It >> wastes CS resources to cancel a request that's taken too long; it >> complicates the protocol for implementors; > >assuming a forking server in Perl that performs actions >by making virtual atomic alterations to a file system, here's >how to make it crap out if there's no response in 90 seconds. I'm afraid "crap out" is an excellent term for what will happen. That "atomic" is the hard part. Even if you're using an API that guarantees atomicity, consider what happens if the modification succeeds, and then the alarm goes off before you can cancel it. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=============================================================| |For an engineer, paranoia is not an affliction; it's a tool. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:32:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22097 for ; Thu, 15 Nov 2001 16:31:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFL6HN24788 for ietf-calendar-bks; Thu, 15 Nov 2001 13:06:17 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFL6G824784 for ; Thu, 15 Nov 2001 13:06:16 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA10728 for ; Thu, 15 Nov 2001 13:06:17 -0800 (PST) Message-ID: <3BF42E35.6D7A2241@Royer.com> Date: Thu, 15 Nov 2001 14:05:57 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: single threaded References: Content-Type: multipart/mixed; boundary="------------10931BCB80139E508F43CCF3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------10931BCB80139E508F43CCF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >However, the WG decided for bounded latency a long time ago. > > I actually can't find such a decision in the archives. Key points: It pre-dates CAP when there was iRIP and the proposal for an HTTP based CAP. When iRIP went away, the agreement with the iRIP proponents was the it remain in CAP. I know it was a discussion, but it was a long time ago. The real issue here is that we can't keep re-opening old issues if we want CAP out the door. We are removing the CAP transport in favor of BXXP, and that is a good thing. I understand that BXXP might have issues with bound latency, we could do in the in data (vs transport). Or we could drop it. But we really need to be careful not to just keep reopening old issues just because we don't like them. -Doug --------------10931BCB80139E508F43CCF3 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------10931BCB80139E508F43CCF3-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:44:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22760 for ; Thu, 15 Nov 2001 16:44:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFLQCp26332 for ietf-calendar-bks; Thu, 15 Nov 2001 13:26:12 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLQB826328 for ; Thu, 15 Nov 2001 13:26:11 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11012 for ; Thu, 15 Nov 2001 13:26:12 -0800 (PST) Message-ID: <3BF432DA.33795CE0@Royer.com> Date: Thu, 15 Nov 2001 14:25:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MODIFY restriction table... References: <3BF30434.78007D47@Royer.com> Content-Type: multipart/mixed; boundary="------------CB34CF93CD068C6567F8ABFD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CB34CF93CD068C6567F8ABFD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit An error in my post... Doug Royer wrote: > > (I included some cut-paste text from CAP) I think they MUST BE > changed per my comments. > > This would be removed. > > . . . METHOD 1 < to meta-info>> This CAN NOT be removed (I forgot). In CAP, there is a METHOD per stored component, where: CREATED = booked = iTIP status DELETE = Marked as deleted (1) So, MODIFY MAY have a METHOD ('0 or 1') per component. And the The value can be , CREATE, or DELETE (2) And CREATE MUST have a METHOD ('1') per component. The value can be or CREATE. (3) And DELETE MAY have a METHOD ('0 or 1') but it would be useless. -Doug --------------CB34CF93CD068C6567F8ABFD Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------CB34CF93CD068C6567F8ABFD-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:49:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22987 for ; Thu, 15 Nov 2001 16:49:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFLWLJ26615 for ietf-calendar-bks; Thu, 15 Nov 2001 13:32:21 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLWK826611 for ; Thu, 15 Nov 2001 13:32:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11089 for ; Thu, 15 Nov 2001 13:32:21 -0800 (PST) Message-ID: <3BF43449.AF2B014C@Royer.com> Date: Thu, 15 Nov 2001 14:31:53 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: MOVE issue. Content-Type: multipart/mixed; boundary="------------C6B186C54E6568941931D945" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C6B186C54E6568941931D945 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In: 2.3 Protocol Model It says: MOVE Move a calendar. It should say? MOVE Move a calendar or component -Doug --------------C6B186C54E6568941931D945 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------C6B186C54E6568941931D945-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:50:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23063 for ; Thu, 15 Nov 2001 16:50:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFLaLE26695 for ietf-calendar-bks; Thu, 15 Nov 2001 13:36:21 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLaK826690 for ; Thu, 15 Nov 2001 13:36:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11168 for ; Thu, 15 Nov 2001 13:36:21 -0800 (PST) Message-ID: <3BF4352C.7D9E713F@Royer.com> Date: Thu, 15 Nov 2001 14:35:40 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VCAR - ordering Content-Type: multipart/mixed; boundary="------------862C1E248B798036DB56F1DC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------862C1E248B798036DB56F1DC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > 2.4.4.1 VCalendar Access Right (VCAR) > > Access rights within CAP are specified with the "VCAR" calendar > component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" > component properties. > > Properties within an iCalendar object are unordered. This also is > the case for the "GRANT", "DENY" and "CARID" properties. Likewise, > there is no implied ordering required for components of a "RIGHTS" > value type other than that specified by the ABNF. [EDITOR'S NOTE, > this requires a lot of review. We think that this paragraph may be . incorrect. ] I think we can remove the editors note. For a component the ordering is not important - other than what is said above ... in 2.4.4 > The access for a particular UPN is the union of all grants for that > UPN minus the union of its denies. -Doug --------------862C1E248B798036DB56F1DC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------862C1E248B798036DB56F1DC-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:57:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23407 for ; Thu, 15 Nov 2001 16:57:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFLhGm26971 for ietf-calendar-bks; Thu, 15 Nov 2001 13:43:16 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLhF826967 for ; Thu, 15 Nov 2001 13:43:15 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11248 for ; Thu, 15 Nov 2001 13:43:16 -0800 (PST) Message-ID: <3BF436C8.EBA17786@Royer.com> Date: Thu, 15 Nov 2001 14:42:32 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: PIPELINE and bound latency Content-Type: multipart/mixed; boundary="------------DDD03768909D5CD3C436BDA7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DDD03768909D5CD3C436BDA7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > 4.5 Bounded Latency > > CAP is designed so that the CUA can either obtain an immediate > response from a request or discover within a specified amount of time > that the request could not be completed in the requested amount of > time. When the CUA initiates a command that the server cannot > complete within the specified latency time, the server returns an > appropriate response code. The CUA then issues either a CONTINUE or > ABORT command. The ABORT command immediately terminates the command > in progress identified by CMDID and the connection returns to the > Identified state. The CONTINUE command instructs the server to > continue processing the command identified by the CMDID. I think we need to add: If PIPELINE is set to '1', then bounded latency can not be ABORT-ed by the CUA. (See the ABORT command). --------------DDD03768909D5CD3C436BDA7 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------DDD03768909D5CD3C436BDA7-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 16:58:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23477 for ; Thu, 15 Nov 2001 16:58:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFLhdq26983 for ietf-calendar-bks; Thu, 15 Nov 2001 13:43:39 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLhb826979 for ; Thu, 15 Nov 2001 13:43:37 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA15928 for ; Thu, 15 Nov 2001 16:43:34 -0500 Received: from steltor.com ([192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAFLhUH04046 for ; Thu, 15 Nov 2001 16:43:30 -0500 (EST) Message-ID: <3BF436E1.F6D0E563@steltor.com> Date: Thu, 15 Nov 2001 16:42:57 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: <3BF2F600.953AC7C3@Royer.com> <3BF34C38.D76F858B@netscape.com> <3BF42D3E.84EE3BFF@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: > > Steve Mansour wrote: > > > For people who are concerned about small-footprint devices not being > > able to generate guids, remember that is why we added the GENERATEUID > > command. You can always ask the server to generate them for you. > > ALARMID != UID, but you could use it for that I guess. Why can't we simply use UID in VALARM? Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Nov 15 17:04:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23746 for ; Thu, 15 Nov 2001 17:04:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFLlov27155 for ietf-calendar-bks; Thu, 15 Nov 2001 13:47:50 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLln827151 for ; Thu, 15 Nov 2001 13:47:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11317 for ; Thu, 15 Nov 2001 13:47:50 -0800 (PST) Message-ID: <3BF437D8.11B85F10@Royer.com> Date: Thu, 15 Nov 2001 14:47:04 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Minor Search issues Content-Type: multipart/mixed; boundary="------------B403A6A5BB1F4A5D89D68006" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B403A6A5BB1F4A5D89D68006 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > 5.1.1 Grammar For Search Mechanism > > maxresults = "MAXRESULTS" ":" integer CRLF Add: # If not specified then MAXRESULTS is unlimited. > maxsize = "MAXSIZE" ":" integer CRLF Add: # If not specified then MAXSIZE is unlimited. --------------B403A6A5BB1F4A5D89D68006 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------B403A6A5BB1F4A5D89D68006-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 17:07:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23852 for ; Thu, 15 Nov 2001 17:07:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFLr0i27337 for ietf-calendar-bks; Thu, 15 Nov 2001 13:53:00 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFLqx827333 for ; Thu, 15 Nov 2001 13:52:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11394 for ; Thu, 15 Nov 2001 13:53:00 -0800 (PST) Message-ID: <3BF4390D.3F2B1D99@Royer.com> Date: Thu, 15 Nov 2001 14:52:13 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: SQL-MIN fix Content-Type: multipart/mixed; boundary="------------3B2C7EADDC4C308A6D17D2B7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3B2C7EADDC4C308A6D17D2B7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is: capmin-col = # Any property name found in any of the components. Should be: capmin-col = (# Any property name found in any of the components. / "*" ) --------------3B2C7EADDC4C308A6D17D2B7 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------3B2C7EADDC4C308A6D17D2B7-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 17:21:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24531 for ; Thu, 15 Nov 2001 17:21:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFM9Kn28693 for ietf-calendar-bks; Thu, 15 Nov 2001 14:09:20 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFM9I828689 for ; Thu, 15 Nov 2001 14:09:19 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA22806; Thu Nov 15 17:06:55 2001 Subject: OK, then Re: CAP TODO: single threaded] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 15 Nov 2001 17:11:46 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/15/2001 05:12:03 PM, Serialize complete at 11/15/2001 05:12:03 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >The real issue here is that we can't keep re-opening old >issues if we want CAP out the door. My point was that I don't think this issue was ever closed. *However*, given the other message you just sent (PIPELINE=1 implies no bounded latency), I'll withdraw my objection; I don't object to bounded latency as an optional feature. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=============================================================| |Almost no one has ever wanted a 1/4" drill bit; all they ever| |wanted was a 1/4" hole. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 15 17:23:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24596 for ; Thu, 15 Nov 2001 17:23:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFM95t28681 for ietf-calendar-bks; Thu, 15 Nov 2001 14:09:05 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFM94828675 for ; Thu, 15 Nov 2001 14:09:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA11624 for ; Thu, 15 Nov 2001 14:09:05 -0800 (PST) Message-ID: <3BF43CCE.AA0655D2@Royer.com> Date: Thu, 15 Nov 2001 15:08:14 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Wildcard for componet name. Content-Type: multipart/mixed; boundary="------------D154B454A2509829129AF0C9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D154B454A2509829129AF0C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To allow for future components and remove an existing limitation. > 5.1.4 Example, Query by UID > This example would select the entire contents of the component with > the UID property equal to "uid123" and not expand any multiple > instances of the component. If the CUA does not know if "uid123" was > a VEVENT, VTODO, VJOURNAL, or other component, then all components > that the CUA supports MUST be supplied on the QUERY property. This > example assumes the CUA only supports VTODO and VEVENT. I propose an addition that would allow CUAs the ability to fetch components that it does not support, but the CU may wish to view: Additionally a wild card ("*") value MAY BE be be supplied as the component name that will cause the CS to search all components even if the CUA does not understand all of the component types. I think this is simply removing a limitation, not adding any more complexity. --------------D154B454A2509829129AF0C9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------D154B454A2509829129AF0C9-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 17:31:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25046 for ; Thu, 15 Nov 2001 17:31:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFMFZj29107 for ietf-calendar-bks; Thu, 15 Nov 2001 14:15:35 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFMFX829098 for ; Thu, 15 Nov 2001 14:15:33 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA11711 for ; Thu, 15 Nov 2001 14:15:34 -0800 (PST) Message-ID: <3BF43E4F.5883F10F@Royer.com> Date: Thu, 15 Nov 2001 15:14:39 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: single threaded References: Content-Type: multipart/mixed; boundary="------------A3155450C6A955E909A73465" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A3155450C6A955E909A73465 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > >assuming a forking server in Perl that performs actions > >by making virtual atomic alterations to a file system, here's > >how to make it crap out if there's no response in 90 seconds. > > I'm afraid "crap out" is an excellent term for what will happen. That > "atomic" is the hard part. > > Even if you're using an API that guarantees atomicity, consider what > happens if the modification succeeds, and then the alarm goes off before > you can cancel it. This issue is not unique to CAP. If the alarm (server times out?), then the server would send a reply that said so. If the next command is a CANCEL, then it is canceled. You ether cancel it before it is done, or not. If the reply to the CANCEL is 'no command in progress' - then it was not canceled as it finished before you canceled it. If you cancel (ABORT) it before it is done, the CS replies to the cancel with 'yep - canceled it'. Is there another state? -Doug --------------A3155450C6A955E909A73465 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------A3155450C6A955E909A73465-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 17:40:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25415 for ; Thu, 15 Nov 2001 17:40:08 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFMSuK00593 for ietf-calendar-bks; Thu, 15 Nov 2001 14:28:56 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFMSt800586 for ; Thu, 15 Nov 2001 14:28:55 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA11952 for ; Thu, 15 Nov 2001 14:28:56 -0800 (PST) Message-ID: <3BF4416F.7A2D1822@Royer.com> Date: Thu, 15 Nov 2001 15:27:59 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Method missing from example and text. Content-Type: multipart/mixed; boundary="------------24AEDC990852795C97F5E648" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------24AEDC990852795C97F5E648 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (1) Title change: Is: 7.2.1.2.1 Creating New Calendars Should be: 7.2.1.2.1 Creating New Calendars and Components (2) The second example: Is: ... Example to create a new component. ... C: BEGIN:VEVENT C: DTSTART:99990307T180000Z C: UID:abcd12345 C: DTEND:99990307T190000Z C: SUMMARY:Important Meeting C: END:VEVENT C: END:VCOMMAND C: END:VCAP (2.a) It is missing the METHOD: poperty that tells the CS the status of the component: (2.b) Should be (changes marked with a '*') ... * Example to create a new booked component. ... C: BEGIN:VEVENT C: METHOD:CREATE C: DTSTART:99990307T180000Z C: UID:abcd12345 C: DTEND:99990307T190000Z C: SUMMARY:Important Meeting C: END:VEVENT C: END:VCOMMAND C: END:VCAP --------------24AEDC990852795C97F5E648 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------24AEDC990852795C97F5E648-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:10:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26606 for ; Thu, 15 Nov 2001 18:10:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFMqbf01782 for ietf-calendar-bks; Thu, 15 Nov 2001 14:52:37 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFMqY801777 for ; Thu, 15 Nov 2001 14:52:34 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA00359; Thu Nov 15 17:49:40 2001 Subject: Re: Wildcard for componet name. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 15 Nov 2001 17:54:31 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/15/2001 05:54:48 PM, Serialize complete at 11/15/2001 05:54:48 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I like the wildcard idea. It's the same sort of idea as the MIME rule that, if you don't understand multipart/foo, you treat it as multipart/mixed, so that at least the user can see all the parts. Sort of "First, do no harm". /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Solipsists have all the fun. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:15:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26908 for ; Thu, 15 Nov 2001 18:15:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFMsm001883 for ietf-calendar-bks; Thu, 15 Nov 2001 14:54:48 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFMsl801879 for ; Thu, 15 Nov 2001 14:54:47 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA12316 for ; Thu, 15 Nov 2001 14:54:48 -0800 (PST) Message-ID: <3BF4477B.4AF91EE1@Royer.com> Date: Thu, 15 Nov 2001 15:53:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CMDID required in reply if supplied in command Content-Type: multipart/mixed; boundary="------------DBE11F6C1BD6730B33FAB612" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DBE11F6C1BD6730B33FAB612 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In 7.2.1.2: ... The response contains the calendar (CALID) and UID of the component so that the CUA can match up the TARGET from multiple objects created on multiple calendars (TARGETs). Should say: The response contains the calendar (CALID) and UID of the component so that the CUA can match up the TARGET from multiple objects created * on multiple calendars (TARGETs). Additionally if the original command * had a CMDID, then that CMDID MUST BE supplied in the reply. --------------DBE11F6C1BD6730B33FAB612 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------DBE11F6C1BD6730B33FAB612-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:16:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26946 for ; Thu, 15 Nov 2001 18:16:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFN3Hu02119 for ietf-calendar-bks; Thu, 15 Nov 2001 15:03:17 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFN3G802115 for ; Thu, 15 Nov 2001 15:03:16 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA12459; Thu, 15 Nov 2001 15:03:17 -0800 (PST) Message-ID: <3BF44975.37152AB2@Royer.com> Date: Thu, 15 Nov 2001 16:02:13 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: <3BF2F600.953AC7C3@Royer.com> <3BF34C38.D76F858B@netscape.com> <3BF42D3E.84EE3BFF@Royer.com> <3BF436E1.F6D0E563@steltor.com> Content-Type: multipart/mixed; boundary="------------B3707FE041C0638AAB2C2E6D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B3707FE041C0638AAB2C2E6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > ALARMID != UID, but you could use it for that I guess. > > Why can't we simply use UID in VALARM? It could make a VQUERY command a mess to read. ALARMID's are unique per component and UIDs are unique. No other reasons that I can think of. --------------B3707FE041C0638AAB2C2E6D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------B3707FE041C0638AAB2C2E6D-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:24:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27287 for ; Thu, 15 Nov 2001 18:24:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFNBMQ02358 for ietf-calendar-bks; Thu, 15 Nov 2001 15:11:22 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNBL802354 for ; Thu, 15 Nov 2001 15:11:21 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA12543 for ; Thu, 15 Nov 2001 15:11:22 -0800 (PST) Message-ID: <3BF44B58.D8692099@Royer.com> Date: Thu, 15 Nov 2001 16:10:16 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: DELETE restriction table - QUERYNAME/QUERY Content-Type: multipart/mixed; boundary="------------E4AE6DE7FC7F880C726D6DF9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E4AE6DE7FC7F880C726D6DF9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 7.2.1.3 DELETE Method Says ... QUERYNAME 1 Name by which this query is referenced QUERY 1 The query Should be: QUERYNAME 0 or 1 Name by which this query is referenced QUERY 0 or 1 The query. MUST BE supplied if QUERYNAME is not supplied. As you may use a stored QUERY by name. --------------E4AE6DE7FC7F880C726D6DF9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------E4AE6DE7FC7F880C726D6DF9-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:27:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27386 for ; Thu, 15 Nov 2001 18:27:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFNED802482 for ietf-calendar-bks; Thu, 15 Nov 2001 15:14:13 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNEC802478 for ; Thu, 15 Nov 2001 15:14:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA12616 for ; Thu, 15 Nov 2001 15:14:13 -0800 (PST) Message-ID: <3BF44C01.5EAD7CAB@Royer.com> Date: Thu, 15 Nov 2001 16:13:05 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: MODIFY missing error numbers. Content-Type: multipart/mixed; boundary="------------61ACAA4FD43D6D6A3B5FB344" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------61ACAA4FD43D6D6A3B5FB344 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Error numbers missing, and 'Permission' . -- 7.2.1.4 MODIFY Method Arguments: None Data: no specific data for this command Result: 2.0 - successfully modified the component or calendar Permission Calendar or component not found Bad args Container(s) not found --------------61ACAA4FD43D6D6A3B5FB344 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------61ACAA4FD43D6D6A3B5FB344-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:36:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27711 for ; Thu, 15 Nov 2001 18:36:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFNQBC03072 for ietf-calendar-bks; Thu, 15 Nov 2001 15:26:11 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNQA803066 for ; Thu, 15 Nov 2001 15:26:10 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA12749 for ; Thu, 15 Nov 2001 15:26:11 -0800 (PST) Message-ID: <3BF44ECA.2CFA8F2F@Royer.com> Date: Thu, 15 Nov 2001 16:24:58 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: MODIFY - eliminate unneeded data. Content-Type: multipart/mixed; boundary="------------4588B0250C1A045D6CAD7DF5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4588B0250C1A045D6CAD7DF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In MODIFY, is an example (below) it contains data that is not being modified and MUST NOT be included in the MODIFY request. I think we should add a paragraph something like: Only properties that are being modified can be included in the OLD-VALUES and NEW-VALUES sections of the MODIFY request. NEW-VALUES MAY BE empty, but MUST BE supplied. The DTSTART/DTEND are NOT needed in the example below and are not being changed. (See '*') They need to be removed from the example. -- From cap: In the example below, the start and end time of the event with UID abcd12345 is changed and the LOCATION property is removed. C: SENDDATA C: Content-type:text/calendar; Method=MODIFY; C: Component=VCOMMAND C: C: BEGIN:VCAP C: VERSION:2.1 C: BEGIN:VCOMMAND C: METHOD:MODIFY C: TARGET:relcal2 C: BEGIN:VCOMMAND C: BEGIN:VQUERY C: QUERY:SELECT UID FROM VEVENT WHERE UID = 'abcd12345' C: END:VQUERY C: BEGIN:VEVENT * C: DTSTART:19990421T160000Z * C: DTEND:19990421T163000Z C: LOCATION:Joe's Diner C: END:VEVENT C: END:VCOMMAND C: BEGIN:VEVENT * C: DTSTART:19990421T160000Z * C: DTEND:19990421T163000Z C: END:VEVENT C: END:VCOMMAND C: END:VCAP C: . --------------4588B0250C1A045D6CAD7DF5 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------4588B0250C1A045D6CAD7DF5-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:38:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27768 for ; Thu, 15 Nov 2001 18:38:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFNOFS02977 for ietf-calendar-bks; Thu, 15 Nov 2001 15:24:15 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNOD802972 for ; Thu, 15 Nov 2001 15:24:13 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fAFNOAY05966 for ; Thu, 15 Nov 2001 15:24:10 -0800 (PST) Received: from netscape.com ([206.222.228.213]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMV7OA00.OD8; Thu, 15 Nov 2001 15:24:10 -0800 Message-ID: <3BF44DC2.10DC7E5F@netscape.com> Date: Thu, 15 Nov 2001 15:20:34 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Desruisseaux CC: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: <3BF2F600.953AC7C3@Royer.com> <3BF34C38.D76F858B@netscape.com> <3BF42D3E.84EE3BFF@Royer.com> <3BF436E1.F6D0E563@steltor.com> Content-Type: multipart/mixed; boundary="------------0C0183AA289926560C64C23D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0C0183AA289926560C64C23D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Doug Royer wrote: > > > > Steve Mansour wrote: > > > > > For people who are concerned about small-footprint devices not being > > > able to generate guids, remember that is why we added the GENERATEUID > > > command. You can always ask the server to generate them for you. > > > > ALARMID != UID, but you could use it for that I guess. > > Why can't we simply use UID in VALARM? what if there are multiple valarms? -Steve --------------0C0183AA289926560C64C23D 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:408-276-4930 tel;work:408-276-4268 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 --------------0C0183AA289926560C64C23D-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:40:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27937 for ; Thu, 15 Nov 2001 18:40:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFNTTk03213 for ietf-calendar-bks; Thu, 15 Nov 2001 15:29:29 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNTS803209 for ; Thu, 15 Nov 2001 15:29:28 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA12817 for ; Thu, 15 Nov 2001 15:29:29 -0800 (PST) Message-ID: <3BF44F8F.F176F901@Royer.com> Date: Thu, 15 Nov 2001 16:28:15 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Missing errno number and text Content-Type: multipart/mixed; boundary="------------358A1DA00026CF1F92274863" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------358A1DA00026CF1F92274863 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Permission and missing error numbers. 7.2.1.5 MOVE Method Arguments: ContainerId Data: data as described below Result: 2.0 - success 2.2 - will attempt operation on the remote CAP server Permission Bad args Parent Calendar(s) not found --------------358A1DA00026CF1F92274863 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------358A1DA00026CF1F92274863-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 18:54:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28392 for ; Thu, 15 Nov 2001 18:54:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFNeJA03608 for ietf-calendar-bks; Thu, 15 Nov 2001 15:40:19 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNeH803604 for ; Thu, 15 Nov 2001 15:40:17 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA12958 for ; Thu, 15 Nov 2001 15:40:19 -0800 (PST) Message-ID: <3BF45215.DDFBCA83@Royer.com> Date: Thu, 15 Nov 2001 16:39:01 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: From MOVE [EDITORS NOTE... Content-Type: multipart/mixed; boundary="------------79F62AD8F66F0C4170DAD7B9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------79F62AD8F66F0C4170DAD7B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [EDITORS NOTE: Issues: 1) Should one be able to move a calendar owned by person X into a calendar owned by person Y. (Can these such rights be specified in VCARs?) If they have the VCAR - that is what they are for. Yes - you can GRANT any UPN rights. 2) Should we also be able to move components from one calendar to another? What if the calendars are owned by different users? (With components one can do a copy, then delete the original.) I say yes if you have the VCAR. Moving of components: I don't think that we intended to limit moving to calendars only. I think we just forgot to write it down - comments? 3) There was very little information about MOVE in CAP. Why was it added? Was there some major need for it? It was added because people wanted it :-) Need: people reorganize themselves, so they will want to reorganize their calendars. 4) Can one move multiple calendars into one calendar?] Moving a calendar into another creates a sub-calendar - yes. There is no restriction on the number of sub-calendars. -Doug --------------79F62AD8F66F0C4170DAD7B9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------79F62AD8F66F0C4170DAD7B9-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 19:00:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28606 for ; Thu, 15 Nov 2001 19:00:26 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFNn9C03998 for ietf-calendar-bks; Thu, 15 Nov 2001 15:49:09 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNn8803994 for ; Thu, 15 Nov 2001 15:49:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA13108 for ; Thu, 15 Nov 2001 15:49:10 -0800 (PST) Message-ID: <3BF45426.D0DBE786@Royer.com> Date: Thu, 15 Nov 2001 16:47:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: READ - include readable properties? Content-Type: multipart/mixed; boundary="------------301CABE357E320B601557D30" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------301CABE357E320B601557D30 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In CAP/READ: > [EDITORS NOTE: Should the one(s) that the UPN has access to - be > returned?] Yes - that should also be in the example? --------------301CABE357E320B601557D30 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------301CABE357E320B601557D30-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 19:14:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29048 for ; Thu, 15 Nov 2001 19:14:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAFNwg304326 for ietf-calendar-bks; Thu, 15 Nov 2001 15:58:42 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNwf804322 for ; Thu, 15 Nov 2001 15:58:41 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA13255 for ; Thu, 15 Nov 2001 15:58:42 -0800 (PST) Message-ID: <3BF4565D.783FA1CF@Royer.com> Date: Thu, 15 Nov 2001 16:57:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: iTIP restriction tables in CAP Content-Type: multipart/mixed; boundary="------------F68B8E5E6673E7ED5790E3DA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F68B8E5E6673E7ED5790E3DA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 7.2.2 Scheduling Commands > [EDITORS NOTE: This section needs to be completed by adding the > restriction tables for each of these iTIP methods. The basis for the > text is to be taken from [iTIP].] I would disagree. We should point to the iTIP restrictions tables and add only exceptions. The only exception that I can think of is: In CAP all components MUST BE stored with their METHOD property. The CAP restriction rules for iTIP METHODS are the iTIP restriction tables. Plus each restriction table would also include: METHOD '1' The METHOD MUST BE included in the object. --------------F68B8E5E6673E7ED5790E3DA Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------F68B8E5E6673E7ED5790E3DA-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 19:19:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29140 for ; Thu, 15 Nov 2001 19:19:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAG05dB04667 for ietf-calendar-bks; Thu, 15 Nov 2001 16:05:39 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG05c804663 for ; Thu, 15 Nov 2001 16:05:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA13350 for ; Thu, 15 Nov 2001 16:05:40 -0800 (PST) Message-ID: <3BF457F9.76AC3953@Royer.com> Date: Thu, 15 Nov 2001 17:04:09 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: REQUEST - wrong text Content-Type: multipart/mixed; boundary="------------3A41C741BA4820BDC57F3319" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3A41C741BA4820BDC57F3319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In REQUEST, the text is: If the CU wishes to keep the published entry, a METHOD:MODIFY changing the entries METHOD from PUBLISH to CREATE would be done, booking the entry. Or METHOD:DELETE if the CU did not wish this scheduled item to exist in their calendar. Should be: If the CU wishes to accept the REQUEST entry, a METHOD:MODIFY would be made to the original component. The CUA would then METHOD:REPLY if needed or desired. Then a METHOD:DELETE would delete the REQUEST. If the CU did not wish to accept the REQUEST, then the CUA could METHOD:DELETE it, or do a METHOD:REPLY followed by a METHOD:DELETE of the REQUEST. --------------3A41C741BA4820BDC57F3319 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------3A41C741BA4820BDC57F3319-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 19:25:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29452 for ; Thu, 15 Nov 2001 19:25:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAG0C5D04953 for ietf-calendar-bks; Thu, 15 Nov 2001 16:12:05 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0C3804949 for ; Thu, 15 Nov 2001 16:12:03 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA13429 for ; Thu, 15 Nov 2001 16:12:04 -0800 (PST) Message-ID: <3BF45974.41E40D17@Royer.com> Date: Thu, 15 Nov 2001 17:10:28 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: REPLY - missing text. Content-Type: multipart/mixed; boundary="------------C97B932714E3A1D15B5ECFD6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C97B932714E3A1D15B5ECFD6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 7.2.2.4 REPLY Add a description to REPLY: When the CUA processes a REPLY entry, the CUA would then METHOD:MODIFY it's copy of the entry. Followed by a METHOD:DELETE of the REPLY entry. Then if the CUA/CS had kept a copy of the REQUEST that had been sent (identifyable by a REQUEST where the ORGANIZER of the original componennt is not self), the CUA would METHOD:DELETE that REQUEST. --------------C97B932714E3A1D15B5ECFD6 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------C97B932714E3A1D15B5ECFD6-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 19:32:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29646 for ; Thu, 15 Nov 2001 19:32:08 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAG0JRT05300 for ietf-calendar-bks; Thu, 15 Nov 2001 16:19:27 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0JQ805296 for ; Thu, 15 Nov 2001 16:19:26 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA13568 for ; Thu, 15 Nov 2001 16:19:28 -0800 (PST) Message-ID: <3BF45B2B.A49CF11B@Royer.com> Date: Thu, 15 Nov 2001 17:17:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: ADD: mising text. Content-Type: multipart/mixed; boundary="------------5B73249EE392D9C586D0263B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5B73249EE392D9C586D0263B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 7.2.2.5 ADD We need to add a description: When a METHOD:ADD, the CUA would fist add the information to the named commented with METHOD:MODIFY. Then METHOD:DELETE the ADD entry. --------------5B73249EE392D9C586D0263B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------5B73249EE392D9C586D0263B-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 20:02:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00481 for ; Thu, 15 Nov 2001 20:02:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAG0jUA06332 for ietf-calendar-bks; Thu, 15 Nov 2001 16:45:30 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0jT806328 for ; Thu, 15 Nov 2001 16:45:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA13918 for ; Thu, 15 Nov 2001 16:45:30 -0800 (PST) Message-ID: <3BF46132.A7BD64B3@Royer.com> Date: Thu, 15 Nov 2001 17:43:30 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: COUNTER: missing text Content-Type: multipart/mixed; boundary="------------C6B19C940390ABDCF2A980D6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C6B19C940390ABDCF2A980D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 7.2.2.8 COUNTER Add text: The CUA presents the COUNTER request to the CU. Then if the CU accepts the COUNTER, then a METHOD:MODIFY changes the original entry. Followed by iTIP methods as specified in iTIP using iMIP or CAP. Followed by by a METHOD:DELETE of the COUNTER entry. Followed by a iTIP METHOD using iMIP or CAP as described in iTIP. If the CU rejects the COUNTER, then it would send a METHOD:DECLINECOUNTER using iMIP or CAP. Followed by a METHOD:DELETE of the COUNTER entry. --------------C6B19C940390ABDCF2A980D6 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------C6B19C940390ABDCF2A980D6-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 20:06:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00540 for ; Thu, 15 Nov 2001 20:06:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAG0qIw06560 for ietf-calendar-bks; Thu, 15 Nov 2001 16:52:18 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0qH806556 for ; Thu, 15 Nov 2001 16:52:17 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA13994 for ; Thu, 15 Nov 2001 16:52:19 -0800 (PST) Message-ID: <3BF462C3.7F33197C@Royer.com> Date: Thu, 15 Nov 2001 17:50:11 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Typo - wrap. Content-Type: multipart/mixed; boundary="------------1985168DE32C2A5542D5C1D4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1985168DE32C2A5542D5C1D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following text is badly formatted in the CAP draft and it looks as if text is missing from the first paragraph: 7.2.3.1 Sending and Receiving an iTIP request In this example A invites B and C to a meeting, B accepts the meeting and BEGIN:VEVENT UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- ACTION:cap://cal.foo.com/relcal2 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- ACTION:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting END:VEVENT END:VCOMMAND END:VCALENDAR --------------1985168DE32C2A5542D5C1D4 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------1985168DE32C2A5542D5C1D4-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 20:06:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00552 for ; Thu, 15 Nov 2001 20:06:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAG0ls306401 for ietf-calendar-bks; Thu, 15 Nov 2001 16:47:54 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0lr806397 for ; Thu, 15 Nov 2001 16:47:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA13923 for ; Thu, 15 Nov 2001 16:47:54 -0800 (PST) Message-ID: <3BF461BF.897F70C7@Royer.com> Date: Thu, 15 Nov 2001 17:45:51 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: DECLINECOUNTER: missing text Content-Type: multipart/mixed; boundary="------------9D909D1038CA826839B9FC5B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9D909D1038CA826839B9FC5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 7.2.2.9 DECLINECOUNTER Add: The CUA would present it to the CU. Then the CUA would METHOD:DELETE the DECLINECOUNTER entry. --------------9D909D1038CA826839B9FC5B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------9D909D1038CA826839B9FC5B-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 20:12:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00740 for ; Thu, 15 Nov 2001 20:12:58 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAG0xBG06791 for ietf-calendar-bks; Thu, 15 Nov 2001 16:59:11 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG0xA806787 for ; Thu, 15 Nov 2001 16:59:10 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA14126 for ; Thu, 15 Nov 2001 16:59:12 -0800 (PST) Message-ID: <3BF4645B.3ED5C9A2@Royer.com> Date: Thu, 15 Nov 2001 17:56:59 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Delete old information. Content-Type: multipart/mixed; boundary="------------283E20DFE680507E0B9D198F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------283E20DFE680507E0B9D198F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following can be delete? 9. Implementation Issues 1. What are the minimum component properties set required to create a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and UID. [EDITORS NOTE (dr): They MUST be the same as for iTIP] 2. What is the state of all undefined properties? PROPOSAL: Not defined. So a query will not return them, if they are selected. [EDITORS NOTE (dr): Many have default values, a CS may return the default values?] --------------283E20DFE680507E0B9D198F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------283E20DFE680507E0B9D198F-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 20:25:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00977 for ; Thu, 15 Nov 2001 20:25:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAG1CDT07389 for ietf-calendar-bks; Thu, 15 Nov 2001 17:12:13 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG1CC807385 for ; Thu, 15 Nov 2001 17:12:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA14297 for ; Thu, 15 Nov 2001 17:12:13 -0800 (PST) Message-ID: <3BF4675E.E85CB922@Royer.com> Date: Thu, 15 Nov 2001 18:09:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Specify LANG values. Content-Type: multipart/mixed; boundary="------------3FC01E5841A556867EE0AB81" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3FC01E5841A556867EE0AB81 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit LANGUAGE N TEXT The default language for localizable strings in this calendar. There is no default. This value MUST NOT be empty. We need to add something like: The value of this property is those specified in {RFCxxxx ISOxxxx ???) The one that specifies: en_us, fr_ca, ..... --------------3FC01E5841A556867EE0AB81 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------3FC01E5841A556867EE0AB81-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 20:28:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01052 for ; Thu, 15 Nov 2001 20:28:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAG18OO07244 for ietf-calendar-bks; Thu, 15 Nov 2001 17:08:24 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG18N807240 for ; Thu, 15 Nov 2001 17:08:23 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA14224 for ; Thu, 15 Nov 2001 17:08:25 -0800 (PST) Message-ID: <3BF4667E.ADD8653B@Royer.com> Date: Thu, 15 Nov 2001 18:06:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CHILDREN calendar attribute and comma. Content-Type: multipart/mixed; boundary="------------A3DEA97C851F6AF7F9A19E3B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A3DEA97C851F6AF7F9A19E3B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This implies that a CALID MUST NOT contain a comma. If so we need to say that in the description of CALID. I think this should be a multi-instance (and not multi-valued) entry. That is a calendar may have 0+ CHILDREN entries. Is: CHILDREN Y TEXT The list of sub-calendars Belonging to this calendar. An empty list means no children. The results may be a comma separated list of children. Each entry returned is a CALID. The default is an empty list. Should be ? : This list of sub-calendars belonging to this calendar. There may be multiple sub-calendars, each returning a CHILDREN property. Each instance of of CHILDREN would return a single CALID. --------------A3DEA97C851F6AF7F9A19E3B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------A3DEA97C851F6AF7F9A19E3B-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 20:34:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01189 for ; Thu, 15 Nov 2001 20:34:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAG1E8Z07552 for ietf-calendar-bks; Thu, 15 Nov 2001 17:14:08 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG1E7807548 for ; Thu, 15 Nov 2001 17:14:07 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA14301 for ; Thu, 15 Nov 2001 17:14:08 -0800 (PST) Message-ID: <3BF467CF.B6F4C15A@Royer.com> Date: Thu, 15 Nov 2001 18:11:43 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Uniqueness of RELCALID Content-Type: multipart/mixed; boundary="------------6F74E556C9A90ABE164E5202" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6F74E556C9A90ABE164E5202 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Where it says: RELCALID N URI A unique identifier for the calendar. There is no default value and This value MUST NOT be empty. Perhaps: A unique identifier within this cal-store for the calendar. ... --------------6F74E556C9A90ABE164E5202 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------6F74E556C9A90ABE164E5202-- From owner-ietf-calendar@mail.imc.org Thu Nov 15 20:36:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01215 for ; Thu, 15 Nov 2001 20:36:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAG1GqQ07638 for ietf-calendar-bks; Thu, 15 Nov 2001 17:16:52 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG1Gp807633 for ; Thu, 15 Nov 2001 17:16:51 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA14378 for ; Thu, 15 Nov 2001 17:16:52 -0800 (PST) Message-ID: <3BF46870.6B18BE8A@Royer.com> Date: Thu, 15 Nov 2001 18:14:24 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [EDITORS NOTE: John Stracke to review... Content-Type: multipart/mixed; boundary="------------1DE364FE40E55FE54B901715" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1DE364FE40E55FE54B901715 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In 12.2 ... [EDITORS NOTE: John Stracke to review any updates] John, this is an old one - have you reviewed this? -Doug --------------1DE364FE40E55FE54B901715 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------1DE364FE40E55FE54B901715-- From owner-ietf-calendar@mail.imc.org Fri Nov 16 10:30:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05716 for ; Fri, 16 Nov 2001 10:30:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAGEmpU04297 for ietf-calendar-bks; Fri, 16 Nov 2001 06:48:51 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGEmg804284 for ; Fri, 16 Nov 2001 06:48:46 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA05983; Fri Nov 16 09:45:32 2001 Subject: Re: [EDITORS NOTE: John Stracke to review... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 16 Nov 2001 09:50:29 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/16/2001 09:50:43 AM, Serialize complete at 11/16/2001 09:50:43 AM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Cc: paf@cisco.com Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (Patrik, I'm CC:ing you because this is a process problem, and I'd like your input.) >In 12.2 ... > > [EDITORS NOTE: John Stracke to review any updates] > >John, this is an old one - have you reviewed this? Let's see, is this the Method Reviewer thing...yes. Yeah, this still has the same problem that the iCalendar Method Reviewer process has: the only appeal available is if the MR rejects a proposal. If the MR accepts a proposal, nobody can object. I first brought this up in Oslo; at the time, people seemed to agree that it was something to fix. The main problem is that the MR can add whatever extensions to iCalendar they please. Now, we can expect that most people won't abuse this power most of the time; but, at a minimum, having the power could put them in a painful position when their employer wants them to abuse it. And adding bad extensions isn't the only way this power could be abused. Suppose I propose Extension X, which does such-and-so. The MR doesn't like it, so they propose Extension Y, which does the same thing, differently. They accept Y, and then reject X. I could try to appeal the decision to reject X, but it'd be hard to make the case that both X and Y should be standardized. In addition, only the original proposer can appeal a decision to reject. Suppose the original proposer no longer has time to work on the idea; a third party who wants the proposal to go through has to resubmit it themselves, and wait for it to be rejected. Not an insurmountable problem, but it's an extra barrier. I think I see two meta-problems here. This process was based on the MIME type registration process. The first meta-problem is that the process was changed; the MIME process permits all decisions to be appealed. The second meta-problem is that the needs of iCalendar, or CAP, are fundamentally different from the needs of MIME types. A new MIME type can be registered without having to worry about its interaction with other MIME types; they're orthogonal. But a new iCalendar/CAP property, or a change to an existing property (the same process applies), cannot be considered in isolation; it's necessary to consider its interactions with other properties. This becomes a harder problem, a problem for the full WG, not an appointed reviewer. For this reason, I believe that the Method Reviewer process should be abandoned altogether. Extensions and modifications to the spec can be done via the normal RFC process, just as with other standards. /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |If you're omniscient, how do you know? | \=======================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 16 11:47:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09804 for ; Fri, 16 Nov 2001 11:47:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAGGKJb15605 for ietf-calendar-bks; Fri, 16 Nov 2001 08:20:19 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGGKH815599 for ; Fri, 16 Nov 2001 08:20:17 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id KAA06954 for ; Fri, 16 Nov 2001 10:18:13 -0600 From: "Shannon J. Clark" To: Subject: RE: Specify LANG values. Date: Fri, 16 Nov 2001 10:20:22 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3BF4675E.E85CB922@Royer.com> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, Perhaps a minor point - but could you specify the document you are making changes to? Would be very helpful for casual and non-casual readers alike (I'm assuming this is from CAP - but that is just by context of your other messages at the same time) thanks, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Thursday, November 15, 2001 7:10 PM To: ietf-calendar@imc.org Subject: Specify LANG values. LANGUAGE N TEXT The default language for localizable strings in this calendar. There is no default. This value MUST NOT be empty. We need to add something like: The value of this property is those specified in {RFCxxxx ISOxxxx ???) The one that specifies: en_us, fr_ca, ..... From owner-ietf-calendar@mail.imc.org Fri Nov 16 12:04:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10968 for ; Fri, 16 Nov 2001 12:04:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAGGgVi17404 for ietf-calendar-bks; Fri, 16 Nov 2001 08:42:31 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGGgT817398 for ; Fri, 16 Nov 2001 08:42:29 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fAGGgSx21082 for ; Fri, 16 Nov 2001 08:42:28 -0800 (PST) Received: from netscape.com ([206.222.228.213]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMWJQP00.PPX for ; Fri, 16 Nov 2001 08:42:25 -0800 Message-ID: <3BF54118.592B94D4@netscape.com> Date: Fri, 16 Nov 2001 08:38:48 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAPABILITY/ITIPVERSION. References: <3BF2F39C.8C48F95D@Royer.com> <3BF34B1E.2977511F@netscape.com> <3BF429F3.E6BD8E4B@Royer.com> Content-Type: multipart/mixed; boundary="------------0F9D37279D274A2FB460218D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0F9D37279D274A2FB460218D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Agreed. I've made the change. If anyone sees it different, please speak up. -Steve Doug Royer wrote: > Same difference, '0' should not be allowed. > > Steve Mansour wrote: > > > > Doug Royer wrote: > > > > > ITIPVERSION - Why is '0' instances allowed? > > > I suggest '1'. > > > > Where did you find this? I just pulled the latest cap.xml. I could > > only find > > > > ITIPVERSION 0 or 1 > > > > -Steve --------------0F9D37279D274A2FB460218D 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:408-276-4930 tel;work:408-276-4268 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 --------------0F9D37279D274A2FB460218D-- From owner-ietf-calendar@mail.imc.org Fri Nov 16 12:20:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11945 for ; Fri, 16 Nov 2001 12:20:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAGH3qQ21255 for ietf-calendar-bks; Fri, 16 Nov 2001 09:03:52 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGH3p821248 for ; Fri, 16 Nov 2001 09:03:51 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fAGH3sx00496 for ; Fri, 16 Nov 2001 09:03:54 -0800 (PST) Received: from netscape.com ([206.222.228.213]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMWKQF00.3PR; Fri, 16 Nov 2001 09:03:51 -0800 Message-ID: <3BF5461D.D1012BD@netscape.com> Date: Fri, 16 Nov 2001 09:00:14 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Royer CC: "ietf-calendar@imc.org" Subject: Re: Creating new components References: <3BF2FB71.C9C72F03@Royer.com> Content-Type: multipart/mixed; boundary="------------3ED36B6CA064A776951062A0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3ED36B6CA064A776951062A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is great debugging work you're doing Doug. I really appreciate it. Doug Royer wrote: > IN: > > 7.2.1.2.1 Creating New Calendars > > It says: > The response contains the calendar (CALID) and UID of the component > so that the CUA can match up the TARGET from multiple objects created > on multiple calendars (TARGETs). > > Yet the example above it is missing the UID. done! -Steve --------------3ED36B6CA064A776951062A0 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:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------3ED36B6CA064A776951062A0-- From owner-ietf-calendar@mail.imc.org Fri Nov 16 12:23:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12161 for ; Fri, 16 Nov 2001 12:23:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAGGxkR20467 for ietf-calendar-bks; Fri, 16 Nov 2001 08:59:46 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGGxi820459 for ; Fri, 16 Nov 2001 08:59:44 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fAGGxXx28750 for ; Fri, 16 Nov 2001 08:59:33 -0800 (PST) Received: from netscape.com ([206.222.228.213]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GMWKIX00.H0T for ; Fri, 16 Nov 2001 08:59:21 -0800 Message-ID: <3BF5450F.DD6E28F3@netscape.com> Date: Fri, 16 Nov 2001 08:55:43 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Server replies to CREATE References: <3BF2F7F9.D7E69274@Royer.com> Content-Type: multipart/mixed; boundary="------------36DFF9959E3F14CBAEA519ED" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------36DFF9959E3F14CBAEA519ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Additionally, won't we need to supply the RECURRENCE-ID if the create was for a new instance? Or do people see that as a MODIFY operation? Doug Royer wrote: > The restriction tables for CREATE server replies, needs > to include UID (or ALARMID for VALARM) with the replies. > Otherwise you could not discern which REQUEST-STATUS is for > which object? > > VEVENT Example: > > . . . VEVENT 0+ > add . . . . UID 1 The UID for which this > add REQUEST-STATUS applies. done! > . . . . REQUEST-STATUS 1+ > . . . . * 0 No other VEVENT properties > are present > > And it is needed for VTODO, VJOURNAL, and VALARM (with ALARMID). done! -Steve --------------36DFF9959E3F14CBAEA519ED 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:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------36DFF9959E3F14CBAEA519ED-- From owner-ietf-calendar@mail.imc.org Fri Nov 16 13:21:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15315 for ; Fri, 16 Nov 2001 13:21:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAGHVAm24339 for ietf-calendar-bks; Fri, 16 Nov 2001 09:31:10 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGHV9824333 for ; Fri, 16 Nov 2001 09:31:09 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id MAA00866; Fri Nov 16 12:28:39 2001 Subject: Re: Specify LANG values. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 16 Nov 2001 12:33:35 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/16/2001 12:33:51 PM, Serialize complete at 11/16/2001 12:33:51 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >We need to add something like: > > The value of this property is those specified in > {RFCxxxx ISOxxxx ???) RFC-3066. /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Belief is not relevant to truth. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 16 17:15:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27181 for ; Fri, 16 Nov 2001 17:15:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAGLxJ421017 for ietf-calendar-bks; Fri, 16 Nov 2001 13:59:19 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGLxI821012 for ; Fri, 16 Nov 2001 13:59:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA01660; Fri, 16 Nov 2001 13:59:08 -0800 (PST) Message-ID: <3BF58C1A.6EA832F3@Royer.com> Date: Fri, 16 Nov 2001 14:58:51 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Server replies to CREATE References: <3BF2F7F9.D7E69274@Royer.com> <3BF5450F.DD6E28F3@netscape.com> Content-Type: multipart/mixed; boundary="------------CBB1791460460DF2DA0FB980" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CBB1791460460DF2DA0FB980 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > Additionally, won't we need to supply the RECURRENCE-ID if the create > was for a new instance? Or do people see that as a MODIFY operation? Yes - if you created multiple with the same UID, each of which was a METHOD:ADD - add byCAP METHOD:CREATE. If you MODIFY more than one instance, but not all instances - yes. And likewise QUERYNAME should be returned for CREATE VQUERYs. And TZ when CREATing a VTIMEZONEs. And CARID when CREATing VCARs. Any others? > Doug Royer wrote: > > > The restriction tables for CREATE server replies, needs > > to include UID (or ALARMID for VALARM) with the replies. > > Otherwise you could not discern which REQUEST-STATUS is for > > which object? > > > > VEVENT Example: > > > > . . . VEVENT 0+ > > add . . . . UID 1 The UID for which this > > add REQUEST-STATUS applies. > > done! > > > . . . . REQUEST-STATUS 1+ > > . . . . * 0 No other VEVENT properties > > are present > > > > And it is needed for VTODO, VJOURNAL, and VALARM (with ALARMID). > > done! > > -Steve --------------CBB1791460460DF2DA0FB980 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------CBB1791460460DF2DA0FB980-- From owner-ietf-calendar@mail.imc.org Fri Nov 16 17:15:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27192 for ; Fri, 16 Nov 2001 17:15:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAGM0Um21131 for ietf-calendar-bks; Fri, 16 Nov 2001 14:00:30 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGM0S821124 for ; Fri, 16 Nov 2001 14:00:28 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA01732; Fri, 16 Nov 2001 14:00:29 -0800 (PST) Message-ID: <3BF58C6A.DB9C0BEF@Royer.com> Date: Fri, 16 Nov 2001 15:00:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Specify LANG values. References: Content-Type: multipart/mixed; boundary="------------93BA606720B418E7C37D4342" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------93BA606720B418E7C37D4342 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Doug, > > Perhaps a minor point - but could you specify the document you are making > changes to? Would be very helpful for casual and non-casual readers alike > (I'm assuming this is from CAP - but that is just by context of your other > messages at the same time) Yes - I'll do that to all new posts. And - I talked to George - he preferred that I email the changes. I am not making any myself. -Doug --------------93BA606720B418E7C37D4342 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------93BA606720B418E7C37D4342-- From owner-ietf-calendar@mail.imc.org Mon Nov 19 16:33:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26886 for ; Mon, 19 Nov 2001 16:33:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAJLIxO23362 for ietf-calendar-bks; Mon, 19 Nov 2001 13:18:59 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLIw823358 for ; Mon, 19 Nov 2001 13:18:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA28191 for ; Mon, 19 Nov 2001 13:18:58 -0800 (PST) Message-ID: <3BF94A22.A791DF21@Royer.com> Date: Mon, 19 Nov 2001 11:06:26 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: VCAR - limiting READ Content-Type: multipart/mixed; boundary="------------E5AA214F9EA67C454C2AC610" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E5AA214F9EA67C454C2AC610 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For security reasons, a site may wish a CUA to only see GRANT and DENY values for which it has access. So I propose an additional paragraph to section "2.4.4 Access Rights - Summary": A CS may limit the results sent to a CUA in reply to a METHOD READ on a VCAR to a set that applies to the current session identity. That is if user 'Joe' is the current session identity, then when 'Joe' asks to see the VCARs, the CS might only return a VCAR that effects 'Joe'. In this way 'Joe' can not see who does have other access. --------------E5AA214F9EA67C454C2AC610 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------E5AA214F9EA67C454C2AC610-- From owner-ietf-calendar@mail.imc.org Mon Nov 19 16:33:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26897 for ; Mon, 19 Nov 2001 16:33:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAJLJ9e23386 for ietf-calendar-bks; Mon, 19 Nov 2001 13:19:09 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLJ8823381 for ; Mon, 19 Nov 2001 13:19:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA28198 for ; Mon, 19 Nov 2001 13:19:08 -0800 (PST) Message-ID: <3BF9616A.2CA04B46@Royer.com> Date: Mon, 19 Nov 2001 12:45:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: PRODID capability Content-Type: multipart/mixed; boundary="------------42098F62C257E3AA1561B8E6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------42098F62C257E3AA1561B8E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I thought that PRODID was going to be returned in CAPABILITY? It is in the examples, but not in the 7.1.4 section. Please add to 7.1.4: PRODID 0 or 1 The PRODID of the CS. --------------42098F62C257E3AA1561B8E6 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------42098F62C257E3AA1561B8E6-- From owner-ietf-calendar@mail.imc.org Mon Nov 19 16:33:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26908 for ; Mon, 19 Nov 2001 16:33:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJLJ5223378 for ietf-calendar-bks; Mon, 19 Nov 2001 13:19:05 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLJ4823372 for ; Mon, 19 Nov 2001 13:19:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA28195; Mon, 19 Nov 2001 13:19:05 -0800 (PST) Message-ID: <3BF960AB.29E5B6BC@Royer.com> Date: Mon, 19 Nov 2001 12:42:35 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: search ABNF sql-min Content-Type: multipart/mixed; boundary="------------BDF92C5D0C708FDC3A06A65B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BDF92C5D0C708FDC3A06A65B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To correct for omissions and errors I propose the following changes to the text. I don't think I have added anything new. I think the text below is just more accurate. search = "BEGIN:VQUERY" CRLF [expand] [maxresults] [maxsize] querycomp "END:VQUERY" CRLF expand = "EXPAND" ":" ( "TRUE" / "FALSE") CRLF # the default is EXPAND:FALSE comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VCAR" / iana-name / x-name maxresults = "MAXRESULTS" ":" integer CRLF # Where integer MUST BE greater then or equal to zero. maxsize = "MAXSIZE" ":" integer CRLF # Where integer MUST BE greater then or equal to zero. querycomp = ( query ) / ( queryname query ) / queryname # If only queryname is supplied, then queryname # MUST BE an already stored VQUERY. queryname = "QUERYNAME:" text query = "QUERY:" ( query-min / query-92 ) # # NOTE: query-min MUST be implemented in CSs. # # query-92 is ONLY used if CAPABILITY returns SQL-92 # as the QUERYLEVEL value or if QUERYLEVEL is not # specified. # query-min = "SELECT" capmin-cols-wild " FROM" capmin-comps "WHERE" capmin-cmp prop-name = # Any property name found in any of the components. capmin-col = ( prop-name / comp-name "." prop-name # Where: comp-name MUST BE a sub-componet # of one or more of the capfrom-min values # in the same VQUERY. # # Example: UID # Example : VALARM.ALARMID capmin-col-wild = ( capmin-col / prop-name ".*" ) # Example: UID # Example: VALARM.ALARMID # Example: VALARM.* capmin-cols-wild = ( capmin-col-wild / capmin-col-wild "," capmin-cols-wild ) / ( "*") # Example: UID # Example: VALARM.ALARMID # Example: VALARM.* # Example: * - which includes sub-components capmin-comps = ( comp-name / comp-name "," compmin-comps ) / "*" # Example: VEVENT - which includes sub-components # Example: * - which includes sub-components capmin-cmp = ( capmin-col cmpmin-oper colvalue / capmin-col cmpmin-oper colvalue capmin-logical capmin-cmp ) # Precedence is from left to right. And # there is no grouping. # # Implementations MUST support at least one # capmin-logical per VQUERY. cmpmin-oper = ( " = " / " != " / " < " / " > " / " <= " / " >= " ) # Only times, integers, and float values may # use the "<", ">", "<=", ">=' cmpmin-oper's. # # If times are compared, they must be compared # in UTC. All implementations MUST be provided # times for comparison in UTC. capmin-logical = ( " AND " / " OR " ) colvalue = # Any valid value for the column name supplied. query-92 = capselect-92 capfrom-92 capwhere-92 [ caporderby-92 ] capselect-92 = "SELECT " capselect-92-col capselect-92-col = capmin-cols-wild # Plus any valid [SQL] string that goes # into an SQL SELECT clause. capfrom-92 = "FROM " capfrom-92-cols capfrom-92-cols = capmin-comps # Plus any valid [SQL] string that goes # into an SQL FROM clause. capwhere-92 = "WHERE" capwhere-92-cols capwhere-92-cols = capmin-cmp # Plus any valid [SQL] string that goes # into an SQL WHERE clause. # Any valid [SQL] string that goes into a # WHERE clause. caporderby-92 = "ORDERBY" # followed by any valid [SQL] string that goes # into an [SQL] ORDERBY clause. --------------BDF92C5D0C708FDC3A06A65B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------BDF92C5D0C708FDC3A06A65B-- From owner-ietf-calendar@mail.imc.org Mon Nov 19 16:35:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26953 for ; Mon, 19 Nov 2001 16:35:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAJLIsO23350 for ietf-calendar-bks; Mon, 19 Nov 2001 13:18:54 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLIr823342 for ; Mon, 19 Nov 2001 13:18:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA28183 for ; Mon, 19 Nov 2001 13:18:43 -0800 (PST) Message-ID: <3BF931BE.36E82DF5@Royer.com> Date: Mon, 19 Nov 2001 09:22:22 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: typo 2.4.4.2 Content-Type: multipart/mixed; boundary="------------9B3363755FA07D352D543AA3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9B3363755FA07D352D543AA3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is: BEGIN:VCAR CARID:Users Default Access GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; VALUE="Users Default Access" ;OBJECT=METHOD,VALUE=DELETE,MODIFY END:VCAR Should be (see * for error - two OBJECT= values in a row): BEGIN:VCAR CARID:Users Default Access * GRANT:UPN=OWNER;OBJECT=*;OBJECT=METHOD;VALUE=* DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; VALUE="Users Default Access" ;OBJECT=METHOD,VALUE=DELETE,MODIFY END:VCAR --------------9B3363755FA07D352D543AA3 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------9B3363755FA07D352D543AA3-- From owner-ietf-calendar@mail.imc.org Mon Nov 19 16:36:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27005 for ; Mon, 19 Nov 2001 16:36:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJLJCk23392 for ietf-calendar-bks; Mon, 19 Nov 2001 13:19:12 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLJB823388 for ; Mon, 19 Nov 2001 13:19:11 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA28203 for ; Mon, 19 Nov 2001 13:19:12 -0800 (PST) Message-ID: <3BF96C5F.974BB803@Royer.com> Date: Mon, 19 Nov 2001 13:32:31 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: storing new components Content-Type: multipart/mixed; boundary="------------A3A3CFA202311AB7856AB5A9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A3A3CFA202311AB7856AB5A9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would like to see the following text added to CAP. (someone might want to re-check these against the iTIP and CAP restriction tables - I did - but checking your own work often misses things). Add?: In addition to being able to create new components, a CS must be able to store iTIP methods. Here are some examples: This example adds to the calendar in one operation, a booked VEVENT; an iTIP, REPLY, ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER, PUBLISH, and REQUEST. It is not likely that a CUA will need to do all of this in one operation. This example simply shows how all of these are done using CAP. (spaces between components for ease of reading only. Hash (#) marks denote comments in this text only and are not part of the data). BEGIN:VCAP VERSION:2.1 CMDID:big-command BEGIN:VCOMMAND METHOD:CREATE TARGET:cap://Royer.com/Doug BEGIN:VEVENT METHOD:CREATE # This one is created - booked DTSTAMP:20011119T101214 ORGANIZER:cap://cal.example.com/BigBadWolf DTSTART:19580205T0631Z DTEND:19580205T0730Z UID:unique#1 SUMMARY:A big day END:VEVENT BEGIN:VEVENT METHOD:REPLY # The iTIP REPLY is stored. DTSTAMP:20011119T130124 ORGANIZER:cap://Royer.com/Doug UID:unique#2 ATTENDEE;PARTSTAT=ACCEPTED:iMIP-user@cal.example.com END:VEVENT BEGIN:VEVENT METHOD:ADD # Stores an iTIP notification of a DTSTAMP:20011119T123000 # new instance of an existing UID:unique#3 # VEVENT. DTSTART:20011226 DTEND:20011227 ORGANIZER:cap://Royer.com/CompanyHolidays SEQUENCE:1 SUMMARY:Additional HOLIDAY END:VEVENT BEGIN:VEVENT # Stores the iTIP CANCEL METHOD:CANCEL # notification. DTSTAMP:20011119T130138 UID:unique#4 ATTENDEE:user1 ATTENDEE:user2 END:VEVENT BEGIN:VEVENT METHOD:REFRESH # Stores the request for REFRESH. DTSTAMP:20011119T131123 ORGANIZER:cap://cal.example.com/cal ATTENDEE:Doug@Royer.com UID:some-unique-id END:VEVENT BEGIN:VEVENT METHOD:COUNTER # Stores the request for change. DTSTAMP:20011119T131254 DTSTART:20011124T110000 SUMMARY:Weekly meeting UID:a-unique-value LOCATION:The other building END:VEVENT BEGIN:VEVENT METHOD:DECLINECOUNTER # Stores the denial for request DTSTAMP:20011119T131514 # of the COUNTER. ORGANIZER:cap://cal.example.com/cal UID:some-unique-id END:VEVENT BEGIN:VEVENT METHOD:PUBLISH # Stores the published VEVENT DTSTAMP:20011119T131744 # for review by the OWNER. DTSTART:20011123T110000 DTEND:20011123T120000 UID:another-unique-id SUMMARY:Another open meeting ORGINIZER:cap://Royer.com/Doug END:VEVENT BEGIN:VEVENT METHOD:REQUEST # Stores the VEVENT that the OWNER DTSTAMP:20011119T131744 # is requested to attend. DTSTART:20011201T120000 DTEND:20011207T180000 UID:a-good-uid SUMMARY:Salt Lake IETF meeting ORGINIZER:cap://cal.ietf.com/ietf ATTENDEE;RSVP=YES:cap://Royer.com/Doug END:VEVENT BEGIN:VEVENT METHOD:REPLY # Stores the REPLY recieved. DTSTAMP:20011119T122413 ORGANIZER:cap://cal.ietf.com/ietf UID:a-good-uid ATTENDEE;PARTSTAT=ACCEPTED:cap://Royer.com/Doug END:VEVENT END:VCMD END:VCAP --------------A3A3CFA202311AB7856AB5A9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------A3A3CFA202311AB7856AB5A9-- From owner-ietf-calendar@mail.imc.org Mon Nov 19 16:37:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27107 for ; Mon, 19 Nov 2001 16:37:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJLIs423355 for ietf-calendar-bks; Mon, 19 Nov 2001 13:18:54 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLIr823343 for ; Mon, 19 Nov 2001 13:18:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA28187 for ; Mon, 19 Nov 2001 13:18:53 -0800 (PST) Message-ID: <3BF9485D.69E8DF89@Royer.com> Date: Mon, 19 Nov 2001 10:58:53 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: DEFAULT_VCARS Content-Type: multipart/mixed; boundary="------------407A39DD78EFFD9E02B5317F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------407A39DD78EFFD9E02B5317F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In: 10.1 Calendar Store Properties Is: DEFAULT_VCARS N TEXT A multivalued property containing the default VCARs for newly created top level calendars. Each entry is a CARID. It MUST include at a minimum READBUSYTIMEINFO,REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER. As part of the debate that separated SQL into SQL-MIN and SQL-92, there was an agreement (Insisted upon by I think Frank and perhaps Bruce), for some pre-defined VCARS. They were agreed to be: READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER. The following text (or equivalent) needs to be added: (Perhaps as section 2.4.4.3) x.x.x.x Default VCARs In order for any calendar to function, there must be a minimum set of VCARs defined. This specification does not mandate the contents of these VCARs as that is a site policy and an implementation detail. These default VCARs can be hard coded into the implementation or stored as immutable VCARs by QUERYNAME. They MUST BE readable by an UPN that has access, using a METHOD:READ of a VQUERY for the calendar and MUST BE in VCAR format. The administration of these VCARs can be through CAP or any implementation specific or site policy administration tools provided by the implementation. These predefined VCARs can be defined at the calendar store level and inherited by calendars as they are created. Implementations should verify any modifications (if allowed) of these default VCARs by the calendar OWNER to ensure that the OWNER still has access consistent with site policy. This will ensure that a faulty or malicious CUA can not remove the OWNERs rights to their own calendar. Note that READBUSYTIMEINFO, REQUESTONLY, and UPDATEPARTSTATUS default VCARs apply to everyone except the OWNER of the calendar. The only exception is that a site may include a DENY that prevents the calendar OWNER from METHOD:MODIFY or METHOD:DELETE of the target default VCAR. The owners access is otherwise through the DEFAULTOWNER default VCAR and any other non-default VCARs that may be defined. CARIDs of these names MUST BE defined for all calendars at all times (possibly defined by inheritance from the store or parent calendar). The contents are not defined as they are subject to OWNER and site policy. And these default VCARs are: READBUSYTIMEINFO REQUESTONLY UPDATEPARTSTATUS DEFAULTOWNER And they are described in the four subsections that below. x.x.x.x.1 READBUSTIMEINFO VCAR A READBUSYTIMEINFO VCAR MUST BE defined for each calendar (possibly inherited from the calendar store or parent calendar). This VCAR applies to everyone except the calendar OWNER. This VCAR may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR. This VCAR defines the default VCAR for reading both any VFREEBUSY components and any other components or properties that would help a CUA determine if a calendar was busy. An example might be to allow everyone to read any VFREEBUSY components, and any DTSTART, DTEND, and DURATION values from a VEVENT where the VEVENT was booked (VEVENT with METHOD set to CREATE), within the calendar in order to determine if the calendar is busy. This example also DENYs the OWNER permission to MODIFY or DELETE this VCAR. BEGIN:VCAR CARID:READBUSYTIMEINFO GRANT:UPN=*;OBJECT=VFREEBUSY;VALUE=* GRANT:OBJECT=VEVENT;VALUE=DTSTART,DTEND,DURATION ;OBJECT=METHOD;VALUE=CREATE DENY:UPN=owner;OBJECT=VCAR;OBJECT=CARID;VALUE=READBUSYTIMEINFO ;OBJECT=METHOD;VALUE=MODIFY,DELETE END:VCAR Or to just allow VFREEBUSY: BEGIN:VCAR CARID:READBUSYTIMEINFO RAND:UPN=*;OBJECT=VFREEBUSY;VALUE=* END:VCAR x.x.x.x.2 REQUESTONLY A REQUESTONLY VCAR MUST BE defined for each calendar (possibly inherited from the calendar store or parent calendar). This VCAR applies to everyone except the calendar OWNER. This VCAR may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR. The REQUESTONLY VCAR sets the GRAND and DENY values for performing a METHOD:REQUEST on a calendar. This VCAR applies to everyone except the OWNER. If an OWNER, administrator or site policy, wishes anyone to be able to make requests of the calendar time using REQUEST for VEVENTs or VTODOs, they might use this example VCAR: BEGIN:VCAR CARID:REQUESTONLY GRANT:UPN=*;OBJECT=VEVENT,VTODO;VALUE=* ;OBJECT=METHOD;VALUE=REQUEST END:VCAR If this calendar were private to the OWNER and the OWNER did not wish anyone else the ability to REQUEST time on the calendar, the owner might use this VCAR: BEGIN:VCAR CARID:REQUESTONLY END:VCAR As the default for any access is DENY, only the CARID:REQUESTONLY MUST BE defined (because all default VCARs defined in this specification MUST BE defined). x.x.x.x.3 UPDATEPARTSTATUS A UPDATEPARTSTATUS VCAR MUST BE defined for each calendar (possibly inherited from the calendar store or parent calendar). This VCAR applies to everyone except the calendar OWNER. This VCAR may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR. This VCAR informs CUAs if they have permission to update ATTENDEEs participation status (PARTSTAT) in the calendar using METHOD:MODIFY for the current sessions identity. This VCAR applies only to the ATTENDEE property and its PARTSTAT parameter. The session identy must also have an ATTENDEE property with their value in the target componet. If an OWNER did wish to allow anyone that could login and be identified by the CS permission to update their own participation status in a VEVENT except anonymous users: BEGIN:VCAR CARID:UPDATEPARTSTATUS GRANT:UPN=*;OBJECT=VEVENT;OBJECT=ATTENDEE;VALUE=self ;OBJECT=PARTSTATUS;VALUE=*;OBJECT=METHOD;VALUE=MODIFY DENY:UPN=anonmous;OBJECT=VEVENT;OBJECT=ATTENDEE;VALUE=* ;OBJECT=PARTSTATUS;VALUE=*;OBJECT=METHOD;VALUE=MODIFY END:VCAR And to DENY anyone this could be used. BEGIN:VCAR CARID:UPDATEPARTSTATUS END:VCAR Any UPN that has a DENY, must use the iTIP METHOD:REPLY to notify the calendar OWNER of any updates. x.x.x.4 DEFAULTOWNER A REQUESTONLY VCAR MUST BE defined for each calendar (possibly inherited from the calendar store or parent calendar). This VCAR applies to only the calendar OWNER. This VCAR may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR. This VCAR defines the calendars OWNERs rights to the target calendar. An owner might be given unlimited access to a calendar: BEGIN:VCAR CARID:DEFAULTOWNER GRANT:UPN=owner;OBJECT=*;VALUE=* END:VCAR Or of the site policy only allowed a calendar OWNER to have VEVENTs and to be able to read the VCARs (perhaps because the site only allows the default VCARs and they are not alterable by the OWNER). BEGIN:VCAR CARID:DEFAULTOWNER GRANT:UPN=owner;OBJECT=VEVENT;OBJECT=METHOD;VALUE=* GRANT:UPN=owner;OBJECT=VCAR;OBJECT=METHOD;VALUE=READ END:VCAR --------------407A39DD78EFFD9E02B5317F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------407A39DD78EFFD9E02B5317F-- From owner-ietf-calendar@mail.imc.org Mon Nov 19 17:40:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01120 for ; Mon, 19 Nov 2001 17:40:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJMQBM27286 for ietf-calendar-bks; Mon, 19 Nov 2001 14:26:11 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJMQA827282 for ; Mon, 19 Nov 2001 14:26:10 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA04872; Mon Nov 19 17:22:55 2001 Subject: Re: CAP: VCAR - limiting READ MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 19 Nov 2001 17:27:31 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/19/2001 05:27:58 PM, Serialize complete at 11/19/2001 05:27:58 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >For security reasons, a site may wish a CUA to only see GRANT and DENY >values for which it has access. This sounds like a good idea to me. Of course, a CS could probably get away with doing it even if it's not in the spec (it probably won't break interop); but better to document it. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |==============================================================| |"HTTP is what happens in the absence of good design." -- Keith| |Moore | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 20 04:26:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02550 for ; Tue, 20 Nov 2001 04:26:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAK9C0q02563 for ietf-calendar-bks; Tue, 20 Nov 2001 01:12:00 -0800 (PST) Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK9Bw802555 for ; Tue, 20 Nov 2001 01:11:58 -0800 (PST) Received: from khazad-dum.copa.nl ([212.187.86.233]) by amsfep12-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011120091152.GHTT1203.amsfep12-int.chello.nl@khazad-dum.copa.nl> for ; Tue, 20 Nov 2001 10:11:52 +0100 Received: from martijn by khazad-dum.copa.nl with local (Exim 3.32 #1 (Debian)) id 16670K-00060r-00 for ; Tue, 20 Nov 2001 10:15:44 +0100 Date: Tue, 20 Nov 2001 10:15:43 +0100 From: Martijn van Beers To: "ietf-calendar@imc.org" Subject: Re: CAP: search ABNF sql-min Message-ID: <20011120101543.A23100@khazad-dum.copa.nl> Mail-Followup-To: Martijn van Beers , "ietf-calendar@imc.org" References: <3BF960AB.29E5B6BC@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BF960AB.29E5B6BC@Royer.com> User-Agent: Mutt/1.3.23i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Nov 19, 2001 at 12:42:35PM -0700, Doug Royer wrote: > > To correct for omissions and errors I propose the following changes > to the text. I don't think I have added anything new. I think the > text below is just more accurate. [...] > capmin-logical = ( " AND " / " OR " ) [...] As I wrote before, > I was looking at the query-min syntax for the VQUERY component, and > I was wondering how to handle AND/OR. there's no parentheses in the > syntax, so 'expr AND expr OR expr' seem ambiguous to me. Is it > supposed to mean '(expr) AND (expr OR expr)' or > '(expr AND expr) OR expr'? Or are things like that just not > allowed? I think at least some clarification is in order. Martijn From owner-ietf-calendar@mail.imc.org Tue Nov 20 13:07:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24770 for ; Tue, 20 Nov 2001 13:07:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKHpbH14792 for ietf-calendar-bks; Tue, 20 Nov 2001 09:51:37 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKHpZ814784 for ; Tue, 20 Nov 2001 09:51:36 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA07020; Tue, 20 Nov 2001 12:51:31 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKHpUH22678; Tue, 20 Nov 2001 12:51:30 -0500 (EST) Message-ID: <3BFA9821.388A789@steltor.com> Date: Tue, 20 Nov 2001 12:51:29 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP DODO: VQUERY - partial access References: <3BEC3678.F9E424E7@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 I'll remove it from the to-do list. We should add an example of such a search. George Doug Royer wrote: > > > - VQUERY: if the user does not have access to some, but not > > all of properties that were specified > > should the acessible properties be returned along with an error code > > This is already described in CAP. > > They do not return the properties that the UPN does > not have access to. If you ask for ATTENDEEs and you > don't have permission, the results are returned without > the ATTENDEE property: > > If you send: > > BEGIN:VQUERY > QUERY:SELECT DTSTART,DTEND,ATTENDEE FROM VEVENT WHERE UID="123" > END:VQUERY > > and get back: > > BEGIN:VCALENDAR > DTSTART: > DTEND: > END:VCALENDAR > > Is a valid reply that means you have access to the calendar, > but not all the properties you requested. (It could return and empty > set with nothing between the BEGIN/END. > > -Doug From owner-ietf-calendar@mail.imc.org Tue Nov 20 13:08:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24948 for ; Tue, 20 Nov 2001 13:08:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKHoI714654 for ietf-calendar-bks; Tue, 20 Nov 2001 09:50:18 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKHoG814644 for ; Tue, 20 Nov 2001 09:50:17 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA06924; Tue, 20 Nov 2001 12:47:53 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKHlqH22368; Tue, 20 Nov 2001 12:47:52 -0500 (EST) Message-ID: <3BFA9747.5BA6252@steltor.com> Date: Tue, 20 Nov 2001 12:47:51 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: undefined properties References: <3BEC373B.7B2F3D90@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 I think that it is logically implied by the definition of VQUERY since an experimental property is a property like any other. I'll remove it from the to-do list. George Doug Royer wrote: > > >- What is the state of all undefined properties? PROPOSAL: > > Not defined. So a query will not return them, if they are > > selected. > > Do you mean experimental (x-) properties? > If you ask for them you get them. > If you ask for all you get them > If you don't ask for them, you don't get them. > > -Doug From owner-ietf-calendar@mail.imc.org Tue Nov 20 13:10:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25154 for ; Tue, 20 Nov 2001 13:10:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKHsK015208 for ietf-calendar-bks; Tue, 20 Nov 2001 09:54:20 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKHsJ815201 for ; Tue, 20 Nov 2001 09:54:19 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA07075; Tue, 20 Nov 2001 12:54:13 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKHs9H22772; Tue, 20 Nov 2001 12:54:10 -0500 (EST) Message-ID: <3BFA98C1.F620FA04@steltor.com> Date: Tue, 20 Nov 2001 12:54:09 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: UID References: <3BEC30E7.9CF7BF99@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 Updated the to do list. George Doug Royer wrote: > > > - Do we want/need the CAP server to auto-mangle (aka autoinsert) an > > incoming stream of data with a generated UID? Especially if > 1 > > operation is going to be needed (ie: "Put this on my calendar and > > send invitations to the ATTENDEEs" = 1 CREATE and 1 or more > > other operations). Wouldn't it be simpler and more efficient to have the > > client request a UID and have the CAP server generate and return it ala > > NNTP does with Message-IDs)?? > > > > Besides, the client will _probably_ need to have the UID for other > > operations (like saving in its local store if is does sync work!). > > (from Bruce) > > I assume this is one is dead - as in client does use GENERATEUID > and that's the way it is. > > -Doug From owner-ietf-calendar@mail.imc.org Tue Nov 20 13:11:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25380 for ; Tue, 20 Nov 2001 13:11:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKHveH15461 for ietf-calendar-bks; Tue, 20 Nov 2001 09:57:40 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKHvc815457 for ; Tue, 20 Nov 2001 09:57:39 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA06698; Tue, 20 Nov 2001 12:33:12 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKHX9H21518; Tue, 20 Nov 2001 12:33:09 -0500 (EST) Message-ID: <3BFA93D4.F39C67C6@steltor.com> Date: Tue, 20 Nov 2001 12:33:08 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: MITM References: <3BEC314A.34086AC0@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 I'll remove it from the to do list. Let me know if you have any objections. BTW, the CAP to-do and issues list can be accessed at: http://calsch.org/ietf/cap-ToDo.html George Doug Royer wrote: > > > - Danger of MITM attacks with weak authentication? > > see post: "CAP: SASL mechanisms and MITM attacks" > > We mandate that DIGEST be implemented. Is that subject > to MITM attacks - I don't think so. > > If a CUA/CS decide on a weak authentication - that is out > of scope for CAP. We might want to in the security section > point out why doing weak authentication is stupid and don't do that. > > CAP is not designing security. > > We are using already designed security - I don't think > we picked a bad one. > > -Doug From owner-ietf-calendar@mail.imc.org Tue Nov 20 13:52:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28343 for ; Tue, 20 Nov 2001 13:52:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKI9ss15906 for ietf-calendar-bks; Tue, 20 Nov 2001 10:09:54 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKI9r815902 for ; Tue, 20 Nov 2001 10:09:53 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA07420; Tue, 20 Nov 2001 13:09:48 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKI9lH23869; Tue, 20 Nov 2001 13:09:47 -0500 (EST) Message-ID: <3BFA9C6A.3F06BD4C@steltor.com> Date: Tue, 20 Nov 2001 13:09:46 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: mimium componet properties References: <3BEC36D9.5E681544@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 Yes, it is specified in the restriction tables. Perhaps the idea was to have an example where a component is created with the minimum required properties. I'll update the to do list. George Doug Royer wrote: > > > - What are the minimum component properties set required to > > create a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, > > SUMMARY and UID. > > I think this is already done in CAP? > > -Doug From owner-ietf-calendar@mail.imc.org Tue Nov 20 14:04:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29222 for ; Tue, 20 Nov 2001 14:04:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKIQFf16298 for ietf-calendar-bks; Tue, 20 Nov 2001 10:26:15 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKIQE816294 for ; Tue, 20 Nov 2001 10:26:14 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA07847; Tue, 20 Nov 2001 13:26:00 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKIPvH25292; Tue, 20 Nov 2001 13:25:57 -0500 (EST) Message-ID: <3BFAA034.B584B0E3@steltor.com> Date: Tue, 20 Nov 2001 13:25:56 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: <3BF2F600.953AC7C3@Royer.com> <3BF34C38.D76F858B@netscape.com> <3BF42D3E.84EE3BFF@Royer.com> <3BF436E1.F6D0E563@steltor.com> <3BF44975.37152AB2@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 We could generate a UID instead of using an ALARMID. It will be one less property to define, and UIDs are used as unique ids for many other components: VEVENT, VTODO, VJOURNAL, etc. George Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > ALARMID != UID, but you could use it for that I guess. > > > > Why can't we simply use UID in VALARM? > > It could make a VQUERY command a mess to read. > ALARMID's are unique per component and UIDs are unique. > > No other reasons that I can think of. From owner-ietf-calendar@mail.imc.org Tue Nov 20 14:08:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29459 for ; Tue, 20 Nov 2001 14:08:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKItfY16778 for ietf-calendar-bks; Tue, 20 Nov 2001 10:55:41 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKIte816774 for ; Tue, 20 Nov 2001 10:55:40 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA09200; Tue, 20 Nov 2001 13:55:35 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKItZH28568; Tue, 20 Nov 2001 13:55:35 -0500 (EST) Message-ID: <3BFAA726.EAA93F4E@steltor.com> Date: Tue, 20 Nov 2001 13:55:34 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Server replies to CREATE References: <3BF2F7F9.D7E69274@Royer.com> <3BF5450F.DD6E28F3@netscape.com> <3BF58C1A.6EA832F3@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 Added recurrence id to the server's response. George Doug Royer wrote: > > Steve Mansour wrote: > > > > Additionally, won't we need to supply the RECURRENCE-ID if the create > > was for a new instance? Or do people see that as a MODIFY operation? > > Yes - if you created multiple with the same UID, each of which > was a METHOD:ADD - add byCAP METHOD:CREATE. > > If you MODIFY more than one instance, but not all instances - yes. > > And likewise QUERYNAME should be returned for CREATE VQUERYs. > And TZ when CREATing a VTIMEZONEs. > And CARID when CREATing VCARs. > Any others? > > > Doug Royer wrote: > > > > > The restriction tables for CREATE server replies, needs > > > to include UID (or ALARMID for VALARM) with the replies. > > > Otherwise you could not discern which REQUEST-STATUS is for > > > which object? > > > > > > VEVENT Example: > > > > > > . . . VEVENT 0+ > > > add . . . . UID 1 The UID for which this > > > add REQUEST-STATUS applies. > > > > done! > > > > > . . . . REQUEST-STATUS 1+ > > > . . . . * 0 No other VEVENT properties > > > are present > > > > > > And it is needed for VTODO, VJOURNAL, and VALARM (with ALARMID). > > > > done! > > > > -Steve From owner-ietf-calendar@mail.imc.org Tue Nov 20 15:28:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03543 for ; Tue, 20 Nov 2001 15:28:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKJZGG18941 for ietf-calendar-bks; Tue, 20 Nov 2001 11:35:16 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJZE818936 for ; Tue, 20 Nov 2001 11:35:14 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id OAA02685; Tue Nov 20 14:32:47 2001 Subject: Re: ALARMID to VALARM after stored? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 20 Nov 2001 14:37:54 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/20/2001 02:37:55 PM, Serialize complete at 11/20/2001 02:37:55 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >We could generate a UID instead of using an ALARMID. >It will be one less property to define, and UIDs are >used as unique ids for many other components: VEVENT, >VTODO, VJOURNAL, etc. Yes, but those are all top-level components; a VALARM is contained within a VEVENT or VTODO. Myself, I took the original suggestion to mean that the UID returned by GENERATEUID could be used as the value for an ALARMID, not that we would actually rename ALARMID. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=============================================================| |"I think we'd get fewer bug reports if we stopped selling our| |software off planet." | \=============================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 20 16:34:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07121 for ; Tue, 20 Nov 2001 16:34:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKJuw420504 for ietf-calendar-bks; Tue, 20 Nov 2001 11:56:58 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJuu820496 for ; Tue, 20 Nov 2001 11:56:56 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA08798; Tue, 20 Nov 2001 13:43:49 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKIhmH27396; Tue, 20 Nov 2001 13:43:48 -0500 (EST) Message-ID: <3BFAA463.1E158DD@steltor.com> Date: Tue, 20 Nov 2001 13:43:47 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: autologout disconnect notification References: <3BEC3116.73BB5FCA@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 With BEEP, it is now out of the scope of CAP. George Doug Royer wrote: > > > - Have a notification for the timeout of an idle connection > > see post "CAP: autologout" > > Why? Any OS that I have seen the CUA can register for 'tell me > when the other end went away'. Lets keep the hang up wait burden > on the CUA and not the CS. If the connection drops, what would > the CS do - wait until the connection came back to say - 'I > am hanging up on you"? When the CUA noticed the connection > went away, the CUA can attempt to re-establish the connection. > > I say if the client is not sending data (for what ever reason), > then the CS MAY disconnect when the idle time is reached. Or > if it is notified by the CS's OS that the CUA has hung up. > Only the CUA knows if it cares to keep the connection alive. > And if the connection is not working for whatever reason - let > the CS close its session with that CUA. > > -Doug From owner-ietf-calendar@mail.imc.org Tue Nov 20 16:35:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07157 for ; Tue, 20 Nov 2001 16:35:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKJv4h20524 for ietf-calendar-bks; Tue, 20 Nov 2001 11:57:04 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJv3820517 for ; Tue, 20 Nov 2001 11:57:03 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA08734; Tue, 20 Nov 2001 13:41:24 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKIfKH27266; Tue, 20 Nov 2001 13:41:20 -0500 (EST) Message-ID: <3BFAA3CF.882E1A5C@steltor.com> Date: Tue, 20 Nov 2001 13:41:19 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: disconnect References: <3BEC3090.7B2AA267@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 By doing CAP's transport layer with BEEP, disconnect will be out of the scope of CAP. George Doug Royer wrote: > > > - DISCONNECT: should the client now wait for a response > > from the server before disconnecting? > > YES!! > > For two reasons: > > 1) To make sure the CS got the request. > > 2) To keep the CS from hanging open that connection for > a while in TCP-WAIT state when: > > CUA: sends - goodbye > CS: sends - goodbye reply > CUA: physical hang-up before it gets the CS reply. > CS: TCP waiting for the ill-mannered CUA's > TCP stack to say 'got message' > > This was discussed in a SMTP IETF meeting. It can cause > the server side to hang for a while in TCP-WAIT state while > the TCP stack determines if the connection died or is just slow. > > SPANNERS loved the fact you could fire off junk to an smtp-server > and disconnect without waiting for the spam target system to reply, > sometimes resulting in possibly a HUGE NUMBER of sessions hung for > a couple of minutes while the TCP-stack determining if they hung up > or are slow. I think that on most Unix systems the default is a 2 minute > wait per connection. > > -Doug From owner-ietf-calendar@mail.imc.org Tue Nov 20 16:36:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07168 for ; Tue, 20 Nov 2001 16:36:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKJuiP20456 for ietf-calendar-bks; Tue, 20 Nov 2001 11:56:44 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJuh820450 for ; Tue, 20 Nov 2001 11:56:43 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA08152 for ; Tue, 20 Nov 2001 13:37:42 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKIbcH26065 for ; Tue, 20 Nov 2001 13:37:38 -0500 (EST) Message-ID: <3BFAA304.F9F8904B@steltor.com> Date: Tue, 20 Nov 2001 13:37:56 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: VCAR: Overriding inherited VCAR Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit CAP avoids precedence problems with VCAR by specifying the following in section 2.4.4 (Access Rights - Summary): The access for a particular UPN is the union of all grants for that UPN minus the union of its denies. which implies that a RIGHTS that denies access always takes precedence over a RIGHTS that grant access. On the other hand, in section 2.4.5 (Inheritance) it specifies that: VCARs specified in a calendar or a sub-calendar override all inherited VCARs. What does "override" means/implies? As soon a VCAR is stored in a calendar all inherited VCARs, except decreed VCARs, are completely ignored? Or, simply, individual RIGHTS denied in a parent calendar could be granted in a sub-calendar? Does anybody know why the ability to override inherited VCARs is required in CAP? Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Nov 20 16:36:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07180 for ; Tue, 20 Nov 2001 16:36:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKJupA20483 for ietf-calendar-bks; Tue, 20 Nov 2001 11:56:51 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJuo820473 for ; Tue, 20 Nov 2001 11:56:50 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA07577; Tue, 20 Nov 2001 13:17:15 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKIHEH24523; Tue, 20 Nov 2001 13:17:14 -0500 (EST) Message-ID: <3BFA9E29.BA1412F7@steltor.com> Date: Tue, 20 Nov 2001 13:17:13 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: Stored queries. References: <3BEC324A.DBAB9FD0@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 I'll remove the issue from the to do list. Any objections? George Doug Royer wrote: > > > - make stored VQUERYs optional? > > see thread: "CAP: stored queries" > > First I assume you mean 'MAY' and not 'optional'. > > SQL-MIN are stored queries as they are called by name. > So they MUST be implemented. This was a BIG BIG BIG issue in the WG. > > All others are a MAY. > > -Doug From owner-ietf-calendar@mail.imc.org Tue Nov 20 17:03:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08319 for ; Tue, 20 Nov 2001 17:03:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKLojb24767 for ietf-calendar-bks; Tue, 20 Nov 2001 13:50:45 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKLoi824761 for ; Tue, 20 Nov 2001 13:50:44 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA14403 for ; Tue, 20 Nov 2001 16:50:42 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKLocH13159 for ; Tue, 20 Nov 2001 16:50:38 -0500 (EST) Message-ID: <3BFAD03F.EDF760AD@steltor.com> Date: Tue, 20 Nov 2001 16:50:55 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > >We could generate a UID instead of using an ALARMID. > >It will be one less property to define, and UIDs are > >used as unique ids for many other components: VEVENT, > >VTODO, VJOURNAL, etc. > > Yes, but those are all top-level components; a VALARM is contained within > a VEVENT or VTODO. Actually, it would be useful to allow VALARMs contained within VEVENT and VTODO to make reference to VALARMs contained in VAGENDAs to allow calendar users to easily manage their preferred alarm properties (e.g., alarm lead time) in few VALARMs. For instance, I could store the following VALARM in a VAGENDA: BEGIN:VALARM UID:20011121T120000Z-00002@host.com TRIGGER:-PT30M REPEAT:2 DURATION:PT15M ACTION:DISPLAY END:VALARM and make reference to it in a VALARM contained within a VEVENT as follows: BEGIN:VEVENT UID:20011121T120000Z-00001@host.com DTSTART:20011121T220000Z DTEND:20011121T230000Z SUMMARY:Important Meeting BEGIN:VALARM ALARMREF:20011121T120000Z-00002@host.com END:VALARM END:VEVENT To make this possible we need unique identifiers (UID) for VALARMs. > Myself, I took the original suggestion to mean that the UID returned by > GENERATEUID could be used as the value for an ALARMID, not that we would > actually rename ALARMID. I meant to rename ALARMID to UID. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Nov 20 17:05:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08406 for ; Tue, 20 Nov 2001 17:05:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKLsrr24994 for ietf-calendar-bks; Tue, 20 Nov 2001 13:54:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKLsq824989 for ; Tue, 20 Nov 2001 13:54:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA14545 for ; Tue, 20 Nov 2001 16:54:49 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKLsmH13420 for ; Tue, 20 Nov 2001 16:54:48 -0500 (EST) Message-ID: <3BFAD13A.4AF1B800@steltor.com> Date: Tue, 20 Nov 2001 16:55:06 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VCAR: CARID Property 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 Here's some issues with the CARID property specified in the document "Proposed changes to iCalendar needed for CAP" (iCal-updates) which is available at the following URL: http://calsch.org/ietf/iCal-updates.html 1- The "CARID" property specifies the local identifier for the "VCAR" calendar components. By looking at the examples provided in the document "iCal-updates" it seems that an additional property should be added to the VCAR component to allow users to specify a localizable display name in their VCARs. In my opinion CARID should not be displayed to users. The value of CARID should only be used with CARREF. I propose to add the property NAME in VCAR components. 2- Do we really need a VCAR specific property to hold VCAR identifiers? Couldn't we simply use the UID property for that purpose? Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Nov 20 17:06:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08453 for ; Tue, 20 Nov 2001 17:06:23 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKLqcD24888 for ietf-calendar-bks; Tue, 20 Nov 2001 13:52:38 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKLqb824884 for ; Tue, 20 Nov 2001 13:52:37 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA14464 for ; Tue, 20 Nov 2001 16:52:34 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKLqXH13270 for ; Tue, 20 Nov 2001 16:52:33 -0500 (EST) Message-ID: <3BFAD0B3.66B94DF0@steltor.com> Date: Tue, 20 Nov 2001 16:52:51 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VCAR: Why only in CALSTORE and VAGENDA? 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 The scope of VCARs depends on their location in the calendar hierarchy. Shouldn't we allow VCAR to be stored within all components and not only within the CALSTORE and VAGENDAs? Allowing VCAR in VEVENT, VTODO, etc. would provide a simple way of writing VCAR specific to one component and making sure the VCAR remains with the component when it is moved within the calendar hierarchy. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Nov 20 17:10:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08603 for ; Tue, 20 Nov 2001 17:10:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAKLtqb25061 for ietf-calendar-bks; Tue, 20 Nov 2001 13:55:52 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKLtp825057 for ; Tue, 20 Nov 2001 13:55:51 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA14589 for ; Tue, 20 Nov 2001 16:55:48 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKLtlH13707 for ; Tue, 20 Nov 2001 16:55:47 -0500 (EST) Message-ID: <3BFAD175.78970A48@steltor.com> Date: Tue, 20 Nov 2001 16:56:05 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VCAR: Default CAR capability 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 Since the support of CAR-FULL-1 is optional (MAY) while the support of CAR-MIN is required (MUST) I believe that CAR-MIN should be the default value of the CAR capability instead of CAR-FULL-1 as specified in the section on the CAPABILITY command. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Nov 20 17:30:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09309 for ; Tue, 20 Nov 2001 17:30:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKMIEI25957 for ietf-calendar-bks; Tue, 20 Nov 2001 14:18:14 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKMIC825953 for ; Tue, 20 Nov 2001 14:18:12 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA15364 for ; Tue, 20 Nov 2001 17:18:10 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAKMI6H15615 for ; Tue, 20 Nov 2001 17:18:06 -0500 (EST) Message-ID: <3BFAD6B0.245B3AFA@steltor.com> Date: Tue, 20 Nov 2001 17:18:24 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@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: > > In: > > 10.1 Calendar Store Properties > > Is: > > DEFAULT_VCARS N TEXT A multivalued property > containing the default VCARs > for newly created top level > calendars. Each entry is a > CARID. It MUST include at a > minimum > READBUSYTIMEINFO,REQUESTONLY, > UPDATEPARTSTATUS, and > DEFAULTOWNER. Do we need this calendar store properties given that we have VCAR inheritance? Currently, the specs only says that these VCARs MUST be implemented, not that they be created in every VAGENDA (maintenance hell). > > As part of the debate that separated SQL into SQL-MIN and SQL-92, > there was an agreement (Insisted upon by I think Frank and perhaps > Bruce), for some pre-defined VCARS. They were agreed to be: > > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER. > > The following text (or equivalent) needs to be added: > > (Perhaps as section 2.4.4.3) > > x.x.x.x Default VCARs > > In order for any calendar to function, there must be a minimum > set of VCARs defined. This specification does not mandate the contents > of these VCARs as that is a site policy and an implementation detail. > > These default VCARs can be hard coded into the implementation > or stored as immutable VCARs by QUERYNAME. They MUST BE readable by > an UPN that has access, using a METHOD:READ of a VQUERY for the calendar > and MUST BE in VCAR format. What do you mean by "stored as immutable VCARs by QUERYNAME" ? > > The administration of these VCARs can be through CAP or any > implementation specific or site policy administration tools provided > by the implementation. > > These predefined VCARs can be defined at the calendar store level > and inherited by calendars as they are created. > > Implementations should verify any modifications (if allowed) of > these default VCARs by the calendar OWNER to ensure that the > OWNER still has access consistent with site policy. This will ensure > that a faulty or malicious CUA can not remove the OWNERs rights to > their own calendar. > > Note that READBUSYTIMEINFO, REQUESTONLY, and UPDATEPARTSTATUS default > VCARs apply to everyone except the OWNER of the calendar. The only > exception is that a site may include a DENY that prevents the calendar > OWNER from METHOD:MODIFY or METHOD:DELETE of the target default VCAR. > The owners access is otherwise through the DEFAULTOWNER default VCAR > and any other non-default VCARs that may be defined. > > CARIDs of these names MUST BE defined for all calendars at all > times (possibly defined by inheritance from the store or parent > calendar). The contents are not defined as they are subject to > OWNER and site policy. And these default VCARs are: > > READBUSYTIMEINFO > REQUESTONLY > UPDATEPARTSTATUS > DEFAULTOWNER > > And they are described in the four subsections that below. > > x.x.x.x.1 READBUSTIMEINFO VCAR > > A READBUSYTIMEINFO VCAR MUST BE defined for each calendar (possibly > inherited from the calendar store or parent calendar). This > VCAR applies to everyone except the calendar OWNER. This VCAR > may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR. > > This VCAR defines the default VCAR for reading both any VFREEBUSY > components and any other components or properties that would help a CUA > determine if a calendar was busy. > > An example might be to allow everyone to read any VFREEBUSY components, > and any DTSTART, DTEND, and DURATION values from a VEVENT where the > VEVENT was booked (VEVENT with METHOD set to CREATE), within the calendar > in order to determine if the calendar is busy. This example also DENYs > the OWNER permission to MODIFY or DELETE this VCAR. > > BEGIN:VCAR > CARID:READBUSYTIMEINFO > GRANT:UPN=*;OBJECT=VFREEBUSY;VALUE=* > GRANT:OBJECT=VEVENT;VALUE=DTSTART,DTEND,DURATION > ;OBJECT=METHOD;VALUE=CREATE > DENY:UPN=owner;OBJECT=VCAR;OBJECT=CARID;VALUE=READBUSYTIMEINFO > ;OBJECT=METHOD;VALUE=MODIFY,DELETE > END:VCAR > > Or to just allow VFREEBUSY: > > BEGIN:VCAR > CARID:READBUSYTIMEINFO > RAND:UPN=*;OBJECT=VFREEBUSY;VALUE=* > END:VCAR > > x.x.x.x.2 REQUESTONLY > > A REQUESTONLY VCAR MUST BE defined for each calendar (possibly > inherited from the calendar store or parent calendar). This > VCAR applies to everyone except the calendar OWNER. This VCAR > may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR. > > The REQUESTONLY VCAR sets the GRAND and DENY values for performing > a METHOD:REQUEST on a calendar. This VCAR applies to everyone > except the OWNER. > > If an OWNER, administrator or site policy, wishes anyone to be able > to make requests of the calendar time using REQUEST for VEVENTs > or VTODOs, they might use this example VCAR: > > BEGIN:VCAR > CARID:REQUESTONLY > GRANT:UPN=*;OBJECT=VEVENT,VTODO;VALUE=* > ;OBJECT=METHOD;VALUE=REQUEST > END:VCAR > > If this calendar were private to the OWNER and the OWNER did > not wish anyone else the ability to REQUEST time on the calendar, > the owner might use this VCAR: > > BEGIN:VCAR > CARID:REQUESTONLY > END:VCAR > > As the default for any access is DENY, only the CARID:REQUESTONLY > MUST BE defined (because all default VCARs defined in this specification > MUST BE defined). > > x.x.x.x.3 UPDATEPARTSTATUS > > A UPDATEPARTSTATUS VCAR MUST BE defined for each calendar (possibly > inherited from the calendar store or parent calendar). This > VCAR applies to everyone except the calendar OWNER. This VCAR > may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR. > > This VCAR informs CUAs if they have permission to update ATTENDEEs > participation status (PARTSTAT) in the calendar using METHOD:MODIFY > for the current sessions identity. This VCAR applies only > to the ATTENDEE property and its PARTSTAT parameter. The session > identy must also have an ATTENDEE property with their value > in the target componet. > > If an OWNER did wish to allow anyone that could login and be identified > by the CS permission to update their own participation status in > a VEVENT except anonymous users: > > BEGIN:VCAR > CARID:UPDATEPARTSTATUS > GRANT:UPN=*;OBJECT=VEVENT;OBJECT=ATTENDEE;VALUE=self > ;OBJECT=PARTSTATUS;VALUE=*;OBJECT=METHOD;VALUE=MODIFY > DENY:UPN=anonmous;OBJECT=VEVENT;OBJECT=ATTENDEE;VALUE=* > ;OBJECT=PARTSTATUS;VALUE=*;OBJECT=METHOD;VALUE=MODIFY > END:VCAR > > And to DENY anyone this could be used. > > BEGIN:VCAR > CARID:UPDATEPARTSTATUS > END:VCAR > > Any UPN that has a DENY, must use the iTIP METHOD:REPLY to notify > the calendar OWNER of any updates. > > x.x.x.4 DEFAULTOWNER > > A REQUESTONLY VCAR MUST BE defined for each calendar (possibly > inherited from the calendar store or parent calendar). This > VCAR applies to only the calendar OWNER. This VCAR may DENY the > calendar OWNER the ability to MODIFY or DELETE this VCAR. > > This VCAR defines the calendars OWNERs rights to the target calendar. > An owner might be given unlimited access to a calendar: > > BEGIN:VCAR > CARID:DEFAULTOWNER > GRANT:UPN=owner;OBJECT=*;VALUE=* > END:VCAR > > Or of the site policy only allowed a calendar OWNER to have VEVENTs and > to be able to read the VCARs (perhaps because the site only allows > the default VCARs and they are not alterable by the OWNER). > > BEGIN:VCAR > CARID:DEFAULTOWNER > GRANT:UPN=owner;OBJECT=VEVENT;OBJECT=METHOD;VALUE=* > GRANT:UPN=owner;OBJECT=VCAR;OBJECT=METHOD;VALUE=READ > END:VCAR I notice that none of the RIGHTS value type of the VCARs specified above make use of the ACTION rule part defined in the document "Proposed changes to iCalendar needed for CAP" (iCal-updates) which is available at the following URL: http://calsch.org/ietf/iCal-updates.html Where can I get the most up to date specification of VCARs? Regards, Benrard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Nov 20 18:16:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10321 for ; Tue, 20 Nov 2001 18:15:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKMpm527748 for ietf-calendar-bks; Tue, 20 Nov 2001 14:51:48 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKMpk827739 for ; Tue, 20 Nov 2001 14:51:46 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA05046; Tue Nov 20 17:49:44 2001 Subject: Re: VCAR: CARID Property MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 20 Nov 2001 17:54:50 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/20/2001 05:54:52 PM, Serialize complete at 11/20/2001 05:54:52 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >2- Do we really need a VCAR specific property to hold > VCAR identifiers? Couldn't we simply use the UID > property for that purpose? Note that this is the same issue as with ALARMID. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=================================================================| |I'm a zygote, he's a zygote, she's a zygote, wouldn't you like to| |be a zygote, too? | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 20 18:16:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10333 for ; Tue, 20 Nov 2001 18:16:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAKMpTA27734 for ietf-calendar-bks; Tue, 20 Nov 2001 14:51:29 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKMpR827730 for ; Tue, 20 Nov 2001 14:51:27 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA05034; Tue Nov 20 17:49:25 2001 Subject: Re: ALARMID to VALARM after stored? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 20 Nov 2001 17:54:31 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/20/2001 05:54:33 PM, Serialize complete at 11/20/2001 05:54:33 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Actually, it would be useful to allow VALARMs contained >within VEVENT and VTODO to make reference to VALARMs >contained in VAGENDAs What is a VAGENDA? It's not in 2445 or in draft-ietf-calsch-cap-05. > to allow calendar users to easily >manage their preferred alarm properties (e.g., alarm lead >time) in few VALARMs. I absolutely disagree. Once you do that, you have to start establishing an infrastructure to let the CUA know which VALARMs store "preferred alarm properties" and which don't. We have no need to add preferences support to CAP; those who want to store prefs on the server can use ACAP. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===============================================================| |The Net was designed to survive nukes, but not lawsuits. Wait a| |minute. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Nov 21 10:16:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19018 for ; Wed, 21 Nov 2001 10:16:40 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALF1ub00760 for ietf-calendar-bks; Wed, 21 Nov 2001 07:01:56 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALF1t800756 for ; Wed, 21 Nov 2001 07:01:55 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA24367 for ; Wed, 21 Nov 2001 10:01:50 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fALF1nH04587 for ; Wed, 21 Nov 2001 10:01:49 -0500 (EST) Message-ID: <3BFBC1EF.3D704E4B@steltor.com> Date: Wed, 21 Nov 2001 10:02:07 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > >Actually, it would be useful to allow VALARMs contained > >within VEVENT and VTODO to make reference to VALARMs > >contained in VAGENDAs > > What is a VAGENDA? It's not in 2445 or in draft-ietf-calsch-cap-05. VAGENDA was introduced in September and was added to the lastest interim version of CAP. You can look at the following posts: http://www.imc.org/ietf-calendar/mail-archive/msg02124.html http://www.imc.org/ietf-calendar/mail-archive/msg02129.html http://www.imc.org/ietf-calendar/mail-archive/msg02627.html > > to allow calendar users to easily > >manage their preferred alarm properties (e.g., alarm lead > >time) in few VALARMs. > > I absolutely disagree. Once you do that, you have to start establishing > an infrastructure to let the CUA know which VALARMs store "preferred alarm > properties" and which don't. We have no need to add preferences support > to CAP; those who want to store prefs on the server can use ACAP. The same way VCARs can make reference to other VCARs (CARREF), and VEVENTs can make reference to VTIMEZONE components (TZID), why couldn't VALARMs make reference to other VALARMs? CUAs already have to deal with stored VQUERYs and VTIMEZONEs as top level components, I don't see why they would be confused with VALARMs as top level components. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Nov 21 11:08:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21888 for ; Wed, 21 Nov 2001 11:08:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALFsrH03864 for ietf-calendar-bks; Wed, 21 Nov 2001 07:54:53 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALFso803855 for ; Wed, 21 Nov 2001 07:54:50 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA20535; Wed Nov 21 10:52:24 2001 Subject: Re: ALARMID to VALARM after stored? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 21 Nov 2001 10:57:34 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/21/2001 10:57:36 AM, Serialize complete at 11/21/2001 10:57:36 AM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >VAGENDA was introduced in September That would be it--I was between jobs at the time, and not on the list. >CUAs already have to deal with stored VQUERYs and VTIMEZONEs as >top level components, I don't see why they would be confused >with VALARMs as top level components. These three cases are nonparallel. Stored VQUERYs are purely a CAP matter; they involve no change to iCalendar. (They could be implemented via ACAP, but putting them into CAP makes it possible for an implementor to optimize them--something you might prefer not to do for on-the-fly queries.) VTIMEZONEs are contained within the same component that contains the VEVENT; modifying one's iCalendar code to cope with that container being a VAGENDA instead of a VCALENDAR is minor. Top-level VALARMs, though, are *not* a minor change. You're moving from searching for a VALARM within the VEVENT to searching within the VEVENT's container. Your VEVENT cannot then be passed to a non-CAP implementation (say, via iMIP) without transforming it. More fundamentally, the alleged convenience of storing one's "preferred alarm properties" as VALARMs, and then using those VALARMs by reference, is a Bad Thing. What happens when I change my preferences? Suddenly, all my VEVENTs that used the default VALARM are changed. That's surprising. Usable designs strive to *avoid* surprise. A properly designed CUA would have the preferred alarm settings stored as normal preferences (either client-side or via ACAP), and create a VALARM with a *copy* of those preferences for each new VEVENT. (One might argue that the user might sometimes want to change all the default-settings alarms at once. I suppose that's theoretically possible; but I believe it would be rare--I know I've never wanted to on any of my calendars. If necessary, it can be done by, well, changing all the alarms: the CUA issues a VQUERY to find all VALARMs that match the default settings, then changes them.) /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |================================================================| |"The struggle is always worthwhile, if the end be worthwhile and| |the means honorable; foreknowledge of defeat is not sufficient | |reason to withdraw from the contest." -- Adron e'Kieron, by | |Steven Brust | \================================================================/ From owner-ietf-calendar@mail.imc.org Wed Nov 21 11:19:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22533 for ; Wed, 21 Nov 2001 11:19:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALG3E605874 for ietf-calendar-bks; Wed, 21 Nov 2001 08:03:14 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALG3C805865 for ; Wed, 21 Nov 2001 08:03:12 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA26160; Wed, 21 Nov 2001 11:03:06 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fALG35H09523; Wed, 21 Nov 2001 11:03:05 -0500 (EST) Message-ID: <3BFBD038.23EF389F@steltor.com> Date: Wed, 21 Nov 2001 11:03:04 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Latest Version Of CAP 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 Hello, The latest version of CAP submitted to internet-drafts. Many changes were made since the last interim version was posted. The biggest change was to use BEEP as the transport mechanism in CAP. Please review it and send us your comments. You can get the latest version at: http://www.calsch.org/ietf/drafts.html List of changes since the last interim version was posted: o Transforming CAP to a BEEP profile: 1. Remove duplication (things that are defined in BEEP) - Authentication (AUTHENTICATE) - Encryption (STARTTLS) - Session management (DISCONNECT). - Pipelining of commands. - BEEP one-to-many exchange style is used for commands that target more than one calendar (VCOMMAND, VRESULT). 2. Remove features no longer under the scope of a profile: - Auto-logout 3. Dissociate calendaring commands from the iCalendar objects. - Use the "application/beep+xml" mime content-type for commands and results, and "text/calendar" for the calendaring data. - Minimize changes to iCalendar. - iTip restriction tables can be reused as is. - SENDDATA is replaced by the following commands: 1. create 2. delete 3. modify 4. move 5. schedule 6. search o Fixed many typos and added clarifications. o Changed the calendar store model to allow VQUERY in CALSTORE. o VSCHEDULE is now a "set" instead of a "queue" since a "queue" implies ordering. o Removed unused and unnecessary definitions. George From owner-ietf-calendar@mail.imc.org Wed Nov 21 15:29:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04394 for ; Wed, 21 Nov 2001 15:29:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALKETF17904 for ietf-calendar-bks; Wed, 21 Nov 2001 12:14:29 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALKER817900 for ; Wed, 21 Nov 2001 12:14:28 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA00872 for ; Wed, 21 Nov 2001 15:14:23 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fALKEMH29689 for ; Wed, 21 Nov 2001 15:14:22 -0500 (EST) Message-ID: <3BFC0B31.BF1BDCED@steltor.com> Date: Wed, 21 Nov 2001 15:14:41 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MODIFY restriction table... References: <3BF30434.78007D47@Royer.com> <3BF432DA.33795CE0@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: > > An error in my post... > > Doug Royer wrote: > > > > (I included some cut-paste text from CAP) I think they MUST BE > > changed per my comments. > > > > This would be removed. > > > > . . . METHOD 1 < > to meta-info>> > > This CAN NOT be removed (I forgot). > > In CAP, there is a METHOD per stored component, where: > > CREATED = booked > = iTIP status > DELETE = Marked as deleted I'm not sure how you could marked components as deleted, given that after METHOD:DELETE components no longer exist. > (1) So, MODIFY MAY have a METHOD ('0 or 1') per component. And the > The value can be , CREATE, or DELETE > > (2) And CREATE MUST have a METHOD ('1') per component. > The value can be or CREATE. > > (3) And DELETE MAY have a METHOD ('0 or 1') but it would be useless. > > -Doug Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Nov 21 16:04:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05821 for ; Wed, 21 Nov 2001 16:04:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALKr3419838 for ietf-calendar-bks; Wed, 21 Nov 2001 12:53:03 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALKr2819834 for ; Wed, 21 Nov 2001 12:53:02 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA06584 for ; Wed, 21 Nov 2001 12:53:02 -0800 (PST) Message-ID: <3BFC1414.1477EFCA@Royer.com> Date: Wed, 21 Nov 2001 13:52:36 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: Overriding inherited VCAR References: <3BFAA304.F9F8904B@steltor.com> Content-Type: multipart/mixed; boundary="------------FDEBFB219E2CB1489EF95C15" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FDEBFB219E2CB1489EF95C15 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > CAP avoids precedence problems with VCAR by specifying the > following in section 2.4.4 (Access Rights - Summary): > > The access for a particular UPN is the union of all > grants for that UPN minus the union of its denies. > > which implies that a RIGHTS that denies access always takes > precedence over a RIGHTS that grant access. > > On the other hand, in section 2.4.5 (Inheritance) it > specifies that: > > VCARs specified in a calendar or a sub-calendar override > all inherited VCARs. > > What does "override" means/implies? As soon a VCAR is > stored in a calendar all inherited VCARs, except decreed > VCARs, are completely ignored? No. > Or, simply, individual > RIGHTS denied in a parent calendar could be granted in > a sub-calendar? Yes. It is worded badly. New text needed. Calendar specific GRANT and DENY override inherited GRANT/DENY. > Does anybody know why the ability to override inherited > VCARs is required in CAP? So the calendar owners can control their own calendars. So all sub-calendars do not have to have exactly the same access rights as their parent calendar. Otherwise the site administrator would have to GRANT or DENY all UPN's access to all calendars or none of them. And you would have to GRANT or DENY all UPN's to any calendar to all of the sub-calendars. --------------FDEBFB219E2CB1489EF95C15 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------FDEBFB219E2CB1489EF95C15-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 16:09:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06064 for ; Wed, 21 Nov 2001 16:09:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALKuN820083 for ietf-calendar-bks; Wed, 21 Nov 2001 12:56:23 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALKuM820079 for ; Wed, 21 Nov 2001 12:56:22 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA06657 for ; Wed, 21 Nov 2001 12:56:23 -0800 (PST) Message-ID: <3BFC14DB.7A95EC91@Royer.com> Date: Wed, 21 Nov 2001 13:55:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: Why only in CALSTORE and VAGENDA? References: <3BFAD0B3.66B94DF0@steltor.com> Content-Type: multipart/mixed; boundary="------------358E06A34BB9E7A9A7E817F1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------358E06A34BB9E7A9A7E817F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The scope of VCARs depends on their location in the > calendar hierarchy. Shouldn't we allow VCAR to be > stored within all components and not only within the > CALSTORE and VAGENDAs? > > Allowing VCAR in VEVENT, VTODO, etc. would provide a > simple way of writing VCAR specific to one component > and making sure the VCAR remains with the component > when it is moved within the calendar hierarchy. Sounds good to me. --------------358E06A34BB9E7A9A7E817F1 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------358E06A34BB9E7A9A7E817F1-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 16:13:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06291 for ; Wed, 21 Nov 2001 16:13:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALL21220586 for ietf-calendar-bks; Wed, 21 Nov 2001 13:02:01 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALL20820576 for ; Wed, 21 Nov 2001 13:02:00 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA06745; Wed, 21 Nov 2001 13:02:00 -0800 (PST) Message-ID: <3BFC1629.F0138621@Royer.com> Date: Wed, 21 Nov 2001 14:01:29 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> Content-Type: multipart/mixed; boundary="------------6E5E68EA920FDC90AA7C583B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6E5E68EA920FDC90AA7C583B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Here's some issues with the CARID property specified in > the document "Proposed changes to iCalendar needed for CAP" > (iCal-updates) which is available at the following URL: > > http://calsch.org/ietf/iCal-updates.html > > 1- The "CARID" property specifies the local identifier > for the "VCAR" calendar components. > > By looking at the examples provided in the document > "iCal-updates" it seems that an additional property > should be added to the VCAR component to allow users > to specify a localizable display name in their VCARs. > In my opinion CARID should not be displayed to users. > The value of CARID should only be used with CARREF. > > I propose to add the property NAME in VCAR components. I could go for that. > 2- Do we really need a VCAR specific property to hold > VCAR identifiers? Couldn't we simply use the UID > property for that purpose? Same as with ALARMID. They could use the name UID. --------------6E5E68EA920FDC90AA7C583B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------6E5E68EA920FDC90AA7C583B-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 16:13:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06308 for ; Wed, 21 Nov 2001 16:13:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALL2wA20667 for ietf-calendar-bks; Wed, 21 Nov 2001 13:02:58 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALL2v820663 for ; Wed, 21 Nov 2001 13:02:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA06749 for ; Wed, 21 Nov 2001 13:02:58 -0800 (PST) Message-ID: <3BFC165E.42FEEC3F@Royer.com> Date: Wed, 21 Nov 2001 14:02:22 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: Default CAR capability References: <3BFAD175.78970A48@steltor.com> Content-Type: multipart/mixed; boundary="------------E68B2BBF54957351A9953CD9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E68B2BBF54957351A9953CD9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Since the support of CAR-FULL-1 is optional (MAY) while > the support of CAR-MIN is required (MUST) I believe that > CAR-MIN should be the default value of the CAR capability > instead of CAR-FULL-1 as specified in the section on the > CAPABILITY command. Ether way - as long as there is a default and it is spelled out. --------------E68B2BBF54957351A9953CD9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------E68B2BBF54957351A9953CD9-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 16:26:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07301 for ; Wed, 21 Nov 2001 16:26:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALLFob21105 for ietf-calendar-bks; Wed, 21 Nov 2001 13:15:50 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALLFm821101 for ; Wed, 21 Nov 2001 13:15:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA06899 for ; Wed, 21 Nov 2001 13:15:49 -0800 (PST) Message-ID: <3BFC1958.E1E201CA@Royer.com> Date: Wed, 21 Nov 2001 14:15:04 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> Content-Type: multipart/mixed; boundary="------------60BBB8FFA10F432249381965" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------60BBB8FFA10F432249381965 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > DEFAULT_VCARS N TEXT A multivalued property > > containing the default VCARs > > for newly created top level > > calendars. Each entry is a > > CARID. It MUST include at a > > minimum > > READBUSYTIMEINFO,REQUESTONLY, > > UPDATEPARTSTATUS, and > > DEFAULTOWNER. > > Do we need this calendar store properties given that > we have VCAR inheritance? Currently, the specs only > says that these VCARs MUST be implemented, not that > they be created in every VAGENDA (maintenance hell). The intent was that they are the default VCARs for a new calendar. The reason they are listed is so a CUA can query for them and find out what they contain. Otherwise the only way to find out is to create a new calendar, then query for all of its VCARs, then delete the calendar if is all you really wanted to know was what the default calendar VCARs were. > > These default VCARs can be hard coded into the implementation > > or stored as immutable VCARs by QUERYNAME. They MUST BE readable by > > an UPN that has access, using a METHOD:READ of a VQUERY for the calendar > > and MUST BE in VCAR format. > > What do you mean by "stored as immutable VCARs by QUERYNAME" ? I meant that the name MUST exist and be accessible from a VQUERY. > > > > BEGIN:VCAR > > CARID:DEFAULTOWNER > > GRANT:UPN=owner;OBJECT=VEVENT;OBJECT=METHOD;VALUE=* > > GRANT:UPN=owner;OBJECT=VCAR;OBJECT=METHOD;VALUE=READ > > END:VCAR > > I notice that none of the RIGHTS value type of the VCARs > specified above make use of the ACTION rule part defined > in the document "Proposed changes to iCalendar needed for > CAP" (iCal-updates) which is available at the following URL: > > http://calsch.org/ietf/iCal-updates.html > > Where can I get the most up to date specification of VCARs? Someone ripped it out of CAP - plus what you point to is old text. RIGHTS were replaced with GRANT/DENY. And the ABNF for those is missing from CAP. --------------60BBB8FFA10F432249381965 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------60BBB8FFA10F432249381965-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 16:32:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07927 for ; Wed, 21 Nov 2001 16:32:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALLIa121188 for ietf-calendar-bks; Wed, 21 Nov 2001 13:18:36 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALLIU821180 for ; Wed, 21 Nov 2001 13:18:35 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id PAA13322 for ; Wed, 21 Nov 2001 15:18:22 -0600 From: "Shannon J. Clark" To: Subject: RE: VCAR: CARID Property Date: Wed, 21 Nov 2001 15:18:33 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <3BFC1629.F0138621@Royer.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit To be consistent should it be NAME or CN? (as in "common name" which I think is what we use elsewhere)? Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Wednesday, November 21, 2001 3:01 PM To: ietf-calendar@imc.org Subject: Re: VCAR: CARID Property Bernard Desruisseaux wrote: > > Here's some issues with the CARID property specified in > the document "Proposed changes to iCalendar needed for CAP" > (iCal-updates) which is available at the following URL: > > http://calsch.org/ietf/iCal-updates.html > > 1- The "CARID" property specifies the local identifier > for the "VCAR" calendar components. > > By looking at the examples provided in the document > "iCal-updates" it seems that an additional property > should be added to the VCAR component to allow users > to specify a localizable display name in their VCARs. > In my opinion CARID should not be displayed to users. > The value of CARID should only be used with CARREF. > > I propose to add the property NAME in VCAR components. I could go for that. > 2- Do we really need a VCAR specific property to hold > VCAR identifiers? Couldn't we simply use the UID > property for that purpose? Same as with ALARMID. They could use the name UID. From owner-ietf-calendar@mail.imc.org Wed Nov 21 16:41:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08595 for ; Wed, 21 Nov 2001 16:41:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALLTFo21524 for ietf-calendar-bks; Wed, 21 Nov 2001 13:29:15 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALLTD821520 for ; Wed, 21 Nov 2001 13:29:14 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA02915; Wed, 21 Nov 2001 16:29:09 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fALLT5H05869; Wed, 21 Nov 2001 16:29:05 -0500 (EST) Message-ID: <3BFC1CA1.6F3ED399@steltor.com> Date: Wed, 21 Nov 2001 16:29:05 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@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 The VCAR specification in: http://calsch.org/ietf/iCal-updates.html was the latest one. It used to be in CAP, but was ripped out, and put into a separate document, since we thought it belonged in iCalendar. George Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > Doug Royer wrote: > > > > > > > DEFAULT_VCARS N TEXT A multivalued property > > > containing the default VCARs > > > for newly created top level > > > calendars. Each entry is a > > > CARID. It MUST include at a > > > minimum > > > READBUSYTIMEINFO,REQUESTONLY, > > > UPDATEPARTSTATUS, and > > > DEFAULTOWNER. > > > > Do we need this calendar store properties given that > > we have VCAR inheritance? Currently, the specs only > > says that these VCARs MUST be implemented, not that > > they be created in every VAGENDA (maintenance hell). > > The intent was that they are the default VCARs for a new calendar. > The reason they are listed is so a CUA can query for them and > find out what they contain. Otherwise the only way to find out > is to create a new calendar, then query for all of its VCARs, then > delete the calendar if is all you really wanted to know was what > the default calendar VCARs were. > > > > These default VCARs can be hard coded into the implementation > > > or stored as immutable VCARs by QUERYNAME. They MUST BE readable by > > > an UPN that has access, using a METHOD:READ of a VQUERY for the calendar > > > and MUST BE in VCAR format. > > > > What do you mean by "stored as immutable VCARs by QUERYNAME" ? > > I meant that the name MUST exist and be accessible from a VQUERY. > > > > > > > > BEGIN:VCAR > > > CARID:DEFAULTOWNER > > > GRANT:UPN=owner;OBJECT=VEVENT;OBJECT=METHOD;VALUE=* > > > GRANT:UPN=owner;OBJECT=VCAR;OBJECT=METHOD;VALUE=READ > > > END:VCAR > > > > I notice that none of the RIGHTS value type of the VCARs > > specified above make use of the ACTION rule part defined > > in the document "Proposed changes to iCalendar needed for > > CAP" (iCal-updates) which is available at the following URL: > > > > http://calsch.org/ietf/iCal-updates.html > > > > Where can I get the most up to date specification of VCARs? > > Someone ripped it out of CAP - plus what you point to is old text. > RIGHTS were replaced with GRANT/DENY. And the ABNF for those > is missing from CAP. From owner-ietf-calendar@mail.imc.org Wed Nov 21 16:57:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10015 for ; Wed, 21 Nov 2001 16:57:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALLeJM21955 for ietf-calendar-bks; Wed, 21 Nov 2001 13:40:19 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALLeH821951 for ; Wed, 21 Nov 2001 13:40:17 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA07250 for ; Wed, 21 Nov 2001 13:40:18 -0800 (PST) Message-ID: <3BFC1F0A.4A736942@Royer.com> Date: Wed, 21 Nov 2001 14:39:22 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MODIFY restriction table... References: <3BF30434.78007D47@Royer.com> <3BF432DA.33795CE0@Royer.com> <3BFC0B31.BF1BDCED@steltor.com> Content-Type: multipart/mixed; boundary="------------5EEA118E015DDB304F874800" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5EEA118E015DDB304F874800 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > An error in my post... > > > > Doug Royer wrote: > > > > > > (I included some cut-paste text from CAP) I think they MUST BE > > > changed per my comments. > > > > > > This would be removed. > > > > > > . . . METHOD 1 < > > to meta-info>> > > > > This CAN NOT be removed (I forgot). > > > > In CAP, there is a METHOD per stored component, where: > > > > CREATED = booked > > = iTIP status > > DELETE = Marked as deleted > > I'm not sure how you could marked components as deleted, > given that after METHOD:DELETE components no longer exist. Not true - exactly. With iTIP there is no DELETE - only CANCEL. So the argument was that CAP needed to be able to mark things as DELETE, so the CUA + CU could later determine if it was to be removed from the CS. The 'command' METHOD:MODIFY could mark a component as 'METHOD:DELETE'. Don't confuse that with a 'command' METHOD:DELETE that removes the named targets. Why you need to mark *components* METHOD:DELETE: With iMIP/iTIP, you can get data out of order. So, if the ORGANIZER sends a METHOD:REQUEST SEQUENCE:0, then later a METHOD:REQUEST SEQUENCE:1 then later a METHOD:CANCEL SEQUENCE:1 . But in iMIP you get METHOD:REQUEST SEQUENCE:0 then you get METHOD:CANCEL, and later you get the METHOD:REQUEST SEQUENCE:1. If you do not METHOD:MODIFY the METHOD:CREATE SEQUENCE:0 component as METHOD:DELETE (instead you deleted the component), then when you get the out of order METHOD:REQUEST SEQUENCE:1, you would create a new entry in you CS --- ERROR! I might not have the argument exactly right, but there are times when you can get the iTIP data out of order and you could create zombie events in your calendar. If however you marked the component as METHOD:DELETE and you saved the METHOD:CANCEL (for how long?), then when you later got the old METHOD:REQUEST, your CS/CUA would know that it was received out of order and clean up the mess. OR the CUA could send a METHOD:REFRESH SEQUENCE:1 when it got the CANCEL with the newer SEQUENCE number. But still you have to mark the data in the CS somehow while you wait for the reply - the talk was to mark such components as marked for delete - they contain METHOD:DELETE. When the CUA got the 'no such UID (or whatever)' error from the ORGANIZER, then it could remove the component. For single instances this looks easy. When a specific instance is CANCEL'ed - then you have to keep things some how until the CUA can determine what happened. --------------5EEA118E015DDB304F874800 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------5EEA118E015DDB304F874800-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 17:08:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10614 for ; Wed, 21 Nov 2001 17:08:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALLs9t22833 for ietf-calendar-bks; Wed, 21 Nov 2001 13:54:09 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALLs8822826 for ; Wed, 21 Nov 2001 13:54:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA07476 for ; Wed, 21 Nov 2001 13:54:09 -0800 (PST) Message-ID: <3BFC2230.84893D03@Royer.com> Date: Wed, 21 Nov 2001 14:52:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARID Property References: Content-Type: multipart/mixed; boundary="------------440E3BF1173C25BB44625363" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------440E3BF1173C25BB44625363 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > To be consistent should it be NAME or CN? (as in "common name" which I think > is what we use elsewhere)? CN is a parameter (not a property). That is: CARID;CN="My calendar rights as owner.":OWERRIGHTS I think that Bernard proposed: CARID:OWNERRIGHTS NAME:My calendar rights as owner. From 2445 (CN) - I don't think it matches: Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter specifies the common name to be associated with the calendar user specified by the property. The parameter value is text. The parameter value can be used for display text to be associated with the calendar address specified by the property. > Shannon > > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer > Sent: Wednesday, November 21, 2001 3:01 PM > To: ietf-calendar@imc.org > Subject: Re: VCAR: CARID Property > > Bernard Desruisseaux wrote: > > > > Here's some issues with the CARID property specified in > > the document "Proposed changes to iCalendar needed for CAP" > > (iCal-updates) which is available at the following URL: > > > > http://calsch.org/ietf/iCal-updates.html > > > > 1- The "CARID" property specifies the local identifier > > for the "VCAR" calendar components. > > > > By looking at the examples provided in the document > > "iCal-updates" it seems that an additional property > > should be added to the VCAR component to allow users > > to specify a localizable display name in their VCARs. > > In my opinion CARID should not be displayed to users. > > The value of CARID should only be used with CARREF. > > > > I propose to add the property NAME in VCAR components. > > I could go for that. > > > 2- Do we really need a VCAR specific property to hold > > VCAR identifiers? Couldn't we simply use the UID > > property for that purpose? > > Same as with ALARMID. They could use the name UID. --------------440E3BF1173C25BB44625363 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------440E3BF1173C25BB44625363-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 17:15:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11063 for ; Wed, 21 Nov 2001 17:15:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALM1gw23467 for ietf-calendar-bks; Wed, 21 Nov 2001 14:01:42 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALM1f823461 for ; Wed, 21 Nov 2001 14:01:41 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA03977 for ; Wed, 21 Nov 2001 17:01:38 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fALM1bH08784 for ; Wed, 21 Nov 2001 17:01:37 -0500 (EST) Message-ID: <3BFC2454.194551A5@steltor.com> Date: Wed, 21 Nov 2001 17:01:56 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARID Property References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > To be consistent should it be NAME or CN? (as in "common name" which I think > is what we use elsewhere)? No. CN is a parameter, not a property, and was meant for something else. Here's what iCalendar says for CN: > 4.2.2 Common Name > > Parameter Name: CN > > Purpose: To specify the common name to be associated with the > calendar user specified by the property. The property NAME which is already used in VAGENDAs, could be defined to specify a localizable display name for components (e.g., VAGENDAs, VCARs, and VQUERYs). Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Nov 21 17:56:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12244 for ; Wed, 21 Nov 2001 17:56:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALMjCU27341 for ietf-calendar-bks; Wed, 21 Nov 2001 14:45:12 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALMjB827336 for ; Wed, 21 Nov 2001 14:45:11 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA04740 for ; Wed, 21 Nov 2001 17:45:08 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fALMj6H11410 for ; Wed, 21 Nov 2001 17:45:07 -0500 (EST) Message-ID: <3BFC2E86.204FC6CF@steltor.com> Date: Wed, 21 Nov 2001 17:45:26 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARID Property References: <3BFC2230.84893D03@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: > > "Shannon J. Clark" wrote: > > > > To be consistent should it be NAME or CN? (as in "common name" which I think > > is what we use elsewhere)? > > CN is a parameter (not a property). > > That is: > > CARID;CN="My calendar rights as owner.":OWERRIGHTS > > I think that Bernard proposed: > > CARID:OWNERRIGHTS > NAME:My calendar rights as owner. In fact, I proposed to use UID instead of CARID, so that would be: UID:OWNERRIGHTS NAME:My calendar rights as owner. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Nov 21 17:56:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12262 for ; Wed, 21 Nov 2001 17:56:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fALMhwT27214 for ietf-calendar-bks; Wed, 21 Nov 2001 14:43:58 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALMhv827207 for ; Wed, 21 Nov 2001 14:43:57 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA04723 for ; Wed, 21 Nov 2001 17:43:54 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fALMhqH11378 for ; Wed, 21 Nov 2001 17:43:53 -0500 (EST) Message-ID: <3BFC2E3C.375E9640@steltor.com> Date: Wed, 21 Nov 2001 17:44:12 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@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: > > Bernard Desruisseaux wrote: > > > > Doug Royer wrote: > > > > > > > DEFAULT_VCARS N TEXT A multivalued property > > > containing the default VCARs > > > for newly created top level > > > calendars. Each entry is a > > > CARID. It MUST include at a > > > minimum > > > READBUSYTIMEINFO,REQUESTONLY, > > > UPDATEPARTSTATUS, and > > > DEFAULTOWNER. > > > > Do we need this calendar store properties given that > > we have VCAR inheritance? Currently, the specs only > > says that these VCARs MUST be implemented, not that > > they be created in every VAGENDA (maintenance hell). > > The intent was that they are the default VCARs for a new calendar. > The reason they are listed is so a CUA can query for them and > find out what they contain. Otherwise the only way to find out > is to create a new calendar, then query for all of its VCARs, then > delete the calendar if is all you really wanted to know was what > the default calendar VCARs were. Sorry. My question should have been: Do we need "default VCARs for newly created top level calendars" given that we have VCAR inheritance? That is, a newly created top level calendar automatically inherits the VCARs directly contained under CALSTORE. The default VCARs could simply be all the VCARs directly contained under CALSTORE. I don't understand why we would need to copy the default VCARs in every top level calendar. > > http://calsch.org/ietf/iCal-updates.html > > > > Where can I get the most up to date specification of VCARs? > > Someone ripped it out of CAP - plus what you point to is old text. > RIGHTS were replaced with GRANT/DENY. And the ABNF for those > is missing from CAP. The GRANT and DENY properties don't replace RIGHTS, they are RIGHTS value types. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Nov 21 18:53:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13845 for ; Wed, 21 Nov 2001 18:53:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALNfkE00458 for ietf-calendar-bks; Wed, 21 Nov 2001 15:41:46 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALNfj800454 for ; Wed, 21 Nov 2001 15:41:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA08965; Wed, 21 Nov 2001 15:41:45 -0800 (PST) Message-ID: <3BFC3A84.57438517@Royer.com> Date: Wed, 21 Nov 2001 16:36:36 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@Royer.com> <3BFC2E3C.375E9640@steltor.com> Content-Type: multipart/mixed; boundary="------------BE37FCB442F4309B1B765014" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BE37FCB442F4309B1B765014 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Sorry. My question should have been: > > Do we need "default VCARs for newly created top level > calendars" given that we have VCAR inheritance? > > That is, a newly created top level calendar automatically inherits > the VCARs directly contained under CALSTORE. The default VCARs > could simply be all the VCARs directly contained under CALSTORE. > > I don't understand why we would need to copy the default VCARs > in every top level calendar. I was getting these confused: 11.1 Calendar Store Properties / DEFAULT_VCAR 11.2 Calendar Properties / DEFAULT_VCAR I agree, 11.2 DEFAULT_VCARS is not needed. > > > http://calsch.org/ietf/iCal-updates.html > > > > > > Where can I get the most up to date specification of VCARs? > > > > Someone ripped it out of CAP - plus what you point to is old text. > > RIGHTS were replaced with GRANT/DENY. And the ABNF for those > > is missing from CAP. > > The GRANT and DENY properties don't replace RIGHTS, > they are RIGHTS value types. Sorry - there used to be a RIGHTS property in CAP. --------------BE37FCB442F4309B1B765014 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------BE37FCB442F4309B1B765014-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 19:12:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14124 for ; Wed, 21 Nov 2001 19:12:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fALNpTE01001 for ietf-calendar-bks; Wed, 21 Nov 2001 15:51:29 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALNpS800997 for ; Wed, 21 Nov 2001 15:51:28 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA09104 for ; Wed, 21 Nov 2001 15:51:29 -0800 (PST) Message-ID: <3BFC3CC5.35DA5A2E@Royer.com> Date: Wed, 21 Nov 2001 16:46:13 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> Content-Type: multipart/mixed; boundary="------------B6F7BFE1B2C753B4736B7DC9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B6F7BFE1B2C753B4736B7DC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > 2- Do we really need a VCAR specific property to hold > VCAR identifiers? Couldn't we simply use the UID > property for that purpose? The more I think about this, the more I am concerned that it's not a good idea. Take the predefined CARID's for example: OWNERRIGHTS is the CARID. However MANY different calendars will not have the same contents for that VCAR. So it is no longer a unique ID for a VCAR. It is only unique for its scope. So by definition we would be defining VCARS with Unique IDs that were not Unique IDs. And a VCAR/UID would then not uniquely define a VCAR. For ALARMID, we are not pre-defining any, so UID would be okay with me. -Doug --------------B6F7BFE1B2C753B4736B7DC9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------B6F7BFE1B2C753B4736B7DC9-- From owner-ietf-calendar@mail.imc.org Wed Nov 21 20:21:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15420 for ; Wed, 21 Nov 2001 20:21:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAM16DN06014 for ietf-calendar-bks; Wed, 21 Nov 2001 17:06:13 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM16C806009 for ; Wed, 21 Nov 2001 17:06:12 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id UAA06241 for ; Wed, 21 Nov 2001 20:06:09 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAM15xH19197 for ; Wed, 21 Nov 2001 20:05:59 -0500 (EST) Message-ID: <3BFC4F8B.287BB80F@steltor.com> Date: Wed, 21 Nov 2001 20:06:19 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@Royer.com> <3BFC2E3C.375E9640@steltor.com> <3BFC3A84.57438517@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: > > Bernard Desruisseaux wrote: > > > > > Sorry. My question should have been: > > > > Do we need "default VCARs for newly created top level > > calendars" given that we have VCAR inheritance? > > > > That is, a newly created top level calendar automatically inherits > > the VCARs directly contained under CALSTORE. The default VCARs > > could simply be all the VCARs directly contained under CALSTORE. > > > > I don't understand why we would need to copy the default VCARs > > in every top level calendar. > > I was getting these confused: > > 11.1 Calendar Store Properties / DEFAULT_VCAR > 11.2 Calendar Properties / DEFAULT_VCAR > > I agree, 11.2 DEFAULT_VCARS is not needed. Why do you think 11.1 DEFAULT_VCARS is needed? The list of DEFAULT_VCARS is simply the list of all the VCARs directly contained under the CALSTORE. There is no need to define this one as well. It can be obtained with a simple VQUERY. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Nov 22 10:41:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16956 for ; Thu, 22 Nov 2001 10:41:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAMFPwS07742 for ietf-calendar-bks; Thu, 22 Nov 2001 07:25:58 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAMFPt807732 for ; Thu, 22 Nov 2001 07:25:56 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA15653 for ; Thu, 22 Nov 2001 10:25:50 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAMFPnH10123 for ; Thu, 22 Nov 2001 10:25:49 -0500 (EST) Message-ID: <3BFD1911.C0FF7D79@steltor.com> Date: Thu, 22 Nov 2001 10:26:09 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@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: > > Bernard Desruisseaux wrote: > > > 2- Do we really need a VCAR specific property to hold > > VCAR identifiers? Couldn't we simply use the UID > > property for that purpose? > > The more I think about this, the more I am concerned that > it's not a good idea. Take the predefined CARID's for example: > > OWNERRIGHTS is the CARID. > > However MANY different calendars will not have the same contents > for that VCAR. So it is no longer a unique ID for a VCAR. It is only > unique for its scope. So by definition we would be defining VCARS > with Unique IDs that were not Unique IDs. And a VCAR/UID would then > not uniquely define a VCAR. > > For ALARMID, we are not pre-defining any, so UID would be okay > with me. On the other hand, when I would write the following VCAR: BEGIN:VCAR GRANT:CARREF:OWNERRIGHTS ... END:VCAR I wouldn't know for sure that it will always make reference to the same VCAR. Furthermore, a VQUERY performed on a hierarchy of VAGENDAs could return multiple VCARs with the same CARID. The calendar user wouldn't have any way to distinguish the returned VCARs. Finally, enforcing specific identifier for the CAR-MIN VCAR will not allow users to make reference to the VCAR they are re-defining (their new definition would hide the previous definition(s)). What would you think of using reserved names for the CAR-MIN VCARs instead? It is not ideal, since we would have to make the CUA responsible for the localization of these reserved names, but on the other hand, it should be sufficient to meet our requirements. For instance: BEGIN:VCAR UID:20011121T120000Z-00003@host.com NAME:OWNERRIGHTS ... END:VCAR That raises another question with respect to overriding inherited VCARs: Was a VCAR with the CARID:OWNERRIGHTS (a) supposed to override all RIGHTS value type of other VCARs with the same CARID in the calendar hierarchy, or (b) simply specific GRANT and DENY as you mentioned in your reply to (VCAR: Overriding inherited VCAR)? If (a) is true, why the CAR-MIN VCAR need to be handled in a special way? If (b) is true, there is no reason to use the same CARID more than once. Any VCAR can override the CAR-MIN VCARs regardless of its CARID. BTW, OWNERRIGHTS is not part of the predefined CARID, but that's beside the point. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Nov 22 18:04:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22463 for ; Thu, 22 Nov 2001 18:04:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAMMlnH07400 for ietf-calendar-bks; Thu, 22 Nov 2001 14:47:49 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAMMlm807396 for ; Thu, 22 Nov 2001 14:47:48 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA23787 for ; Thu, 22 Nov 2001 17:47:45 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAMMliH27996 for ; Thu, 22 Nov 2001 17:47:44 -0500 (EST) Message-ID: <3BFD80A5.4F481F2D@steltor.com> Date: Thu, 22 Nov 2001 17:48:05 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: 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 John Stracke wrote: > > >VAGENDA was introduced in September > > That would be it--I was between jobs at the time, and not on the list. > > >CUAs already have to deal with stored VQUERYs and VTIMEZONEs as > >top level components, I don't see why they would be confused > >with VALARMs as top level components. > > These three cases are nonparallel. > > Stored VQUERYs are purely a CAP matter; they involve no change to > iCalendar. (They could be implemented via ACAP, but putting them into CAP > makes it possible for an implementor to optimize them--something you might > prefer not to do for on-the-fly queries.) > > VTIMEZONEs are contained within the same component that contains the > VEVENT; modifying one's iCalendar code to cope with that container being a > VAGENDA instead of a VCALENDAR is minor. > > Top-level VALARMs, though, are *not* a minor change. You're moving from > searching for a VALARM within the VEVENT to searching within the VEVENT's > container. Your VEVENT cannot then be passed to a non-CAP implementation > (say, via iMIP) without transforming it. The required transformation would be pretty straightforward. Really minor compared to the required conversion of CAP calendar addresses to mailto URLs. Furthermore, in most cases you should probably not send the VALARM to the other attendees. What's the point of sending your VALARM to other people? > More fundamentally, the alleged convenience of storing one's "preferred > alarm properties" as VALARMs, and then using those VALARMs by reference, > is a Bad Thing. What happens when I change my preferences? Suddenly, all > my VEVENTs that used the default VALARM are changed. That's surprising. > Usable designs strive to *avoid* surprise. A properly designed CUA would > have the preferred alarm settings stored as normal preferences (either > client-side or via ACAP), and create a VALARM with a *copy* of those > preferences for each new VEVENT. A CUA could easily remind the CU about the impact of changing a VALARM referenced by other VALARMs before sending the "modify" command to the CAP server. Personally, I would be more concerned about the consequences of modifying a VCAR referenced by other VCARs, or a VTIMEZONE on which multiple VEVENTs may depend. > (One might argue that the user might sometimes want to change all the > default-settings alarms at once. I suppose that's theoretically possible; > but I believe it would be rare--I know I've never wanted to on any of my > calendars. If necessary, it can be done by, well, changing all the > alarms: the CUA issues a VQUERY to find all VALARMs that match the default > settings, then changes them.) Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Recherche et développement Tél. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri Nov 23 15:11:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22825 for ; Fri, 23 Nov 2001 15:11:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANJnxj20087 for ietf-calendar-bks; Fri, 23 Nov 2001 11:49:59 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANJnv820083 for ; Fri, 23 Nov 2001 11:49:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA02241; Fri, 23 Nov 2001 14:49:52 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANJneH04193; Fri, 23 Nov 2001 14:49:40 -0500 (EST) Message-ID: <3BFEA8C0.7346C691@steltor.com> Date: Fri, 23 Nov 2001 14:51:28 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: From CAP DELETE... References: <3BF30154.13D54329@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: > > [EDITORS NOTE: Issues: > > - Currently CAP requires that the server return a response status. > However, if there are multiple components deleted, should the UID > also be returned? > > Yes! The UIDs are a must in the server restriction table. The example now returns a UID. > > - VQUERY EXPAND and MAXSIZE parameters do not seem to apply to > deletion? > > For DELETE - EXPAND has no meaning... > > Some implementors were talking about expanding recurring VEVENTs > as the store them (vs expanding them when queried). So it does > bring up a good point. However, you would be deleting by > date range or UID (all). > > Deleting a VEVENT by UID would result in ONE reply as no > matter how the CS stores the VEVENT, there is only ONE VEVENT > with that UID. > You can also delete a range of events by doing a query on SUMMARY. > Deleting a VEVENT by date/range would be done with a MODIFY > and not a DELETE - you would get one reply. > > You DELETE COMPONENTS (or calendars) - not instances of recurrence. But can not instances be expressed as components? One would use modify to remove properties, delete to remove components, and what to remove instances? > > And for MAXSIZE: > > Deleting with something like 'all VEVENTs where ATTENDEE contains > user-x' could return N number of replies. So it does sound > like a good idea - as long as the CUA knows that it can not > specify which N are deleted. The CUA would then have to > re-issue the DELETE METHOD - over and over? > > ** WE NEED A STATEMENT in CAP that says that commands > issued with a MAXSIZE limit MUST BE be repeatedly > called until the end is reached as there is no way > to tell which 'N-number' of components were acted upon. > And that failure to do this probably will result in > undesired effects. Does it have to be a must? There may be cases where the CUA only wants to check if there is at least one match, or if the user aborts a search because what he was looking for was in the first "N" number of components returned. However, I do not see cases where a user will want to delete only the first N components matching the query. > > - Can one use DELETE to remove all VALARMs and VTIMEZONEs that > match a certain search criteria and that belong to all components, > event though VALARMs and VTIMEZONEs never exist as independent > components? Or should one use MODIFY? If they can be deleted, do > we return the REQUEST-STATUS of their deletion in a VEVENT or > separately? > > VALARMS should have a ALARMID (see my previous post). > VTIMEZONEs have an id. We only have to make sure that the syntax for VQUERY permits this. > > MODIFY - tricky, as a VALARM and VTIMEZONE have a minimum set > of properties - how could you delete the contents of one of them, > unless you declare that when you do is is the same as DELETE. > So why should we have two ways to do the same thing? > > - In the example in CAP where a calendar is deleted all the server > returns is 2.0, nothing else? The example has been updated. > > I would say the TARGET should be returned also - or PIPELINING > is busted. > > - We should not be able to delete any VFREEBUSY components? > > I had always assumed that a CS would calculate a VFREEBUSY. > Also a CS VFREEBUSY returned value could be an accumulation > of information stored. So how could you delete that? Yes. We should be able to delete VFREEBUSY components. I'll remove from to do list. > > On the other hand - if you can store it - you must be > able to delete it? > > - Currently one can not delete a VAGENDA and some other component > in the same DELETE command. This seems OK. Anyone see any need > to be able to do this? > > I agree. I will remove this from the To Do list, unless someone disagrees. > > - Should the MAXRESULTS property of VQUERY apply to deletion? We > can use it to delete only the first n components that match. ] > > Then delete by date range if that is what you want. Otherwise there > is no way to know which N instances you deleted. (see above). > > -Doug George From owner-ietf-calendar@mail.imc.org Fri Nov 23 15:13:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22848 for ; Fri, 23 Nov 2001 15:13:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANK0I320558 for ietf-calendar-bks; Fri, 23 Nov 2001 12:00:18 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANK0G820553 for ; Fri, 23 Nov 2001 12:00:17 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA02439; Fri, 23 Nov 2001 15:00:12 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANK0BH04942; Fri, 23 Nov 2001 15:00:11 -0500 (EST) Message-ID: <3BFEAB35.1B637688@steltor.com> Date: Fri, 23 Nov 2001 15:01:57 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MOVE issue. References: <3BF43449.AF2B014C@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 In the latest version of CAP a "move" can move a calendar or a component. George Doug Royer wrote: > > In: 2.3 Protocol Model > > It says: > > MOVE Move a calendar. > > It should say? > > MOVE Move a calendar or component > > -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 23 15:19:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22921 for ; Fri, 23 Nov 2001 15:19:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANK3U720789 for ietf-calendar-bks; Fri, 23 Nov 2001 12:03:30 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANK3T820785 for ; Fri, 23 Nov 2001 12:03:29 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA02569; Fri, 23 Nov 2001 15:03:23 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANK3LH05328; Fri, 23 Nov 2001 15:03:21 -0500 (EST) Message-ID: <3BFEABF4.E8255CB7@steltor.com> Date: Fri, 23 Nov 2001 15:05:08 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: PIPELINE and bound latency References: <3BF436C8.EBA17786@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 With the addition of BEEP, it no longer applies. George Doug Royer wrote: > > > 4.5 Bounded Latency > > > > CAP is designed so that the CUA can either obtain an immediate > > response from a request or discover within a specified amount of time > > that the request could not be completed in the requested amount of > > time. When the CUA initiates a command that the server cannot > > complete within the specified latency time, the server returns an > > appropriate response code. The CUA then issues either a CONTINUE or > > ABORT command. The ABORT command immediately terminates the command > > in progress identified by CMDID and the connection returns to the > > Identified state. The CONTINUE command instructs the server to > > continue processing the command identified by the CMDID. > > I think we need to add: > > If PIPELINE is set to '1', then bounded latency can not > be ABORT-ed by the CUA. (See the ABORT command). From owner-ietf-calendar@mail.imc.org Fri Nov 23 15:29:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23028 for ; Fri, 23 Nov 2001 15:29:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fANKCuE21625 for ietf-calendar-bks; Fri, 23 Nov 2001 12:12:56 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANKCr821611 for ; Fri, 23 Nov 2001 12:12:53 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA02757; Fri, 23 Nov 2001 15:12:49 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANKCkH05981; Fri, 23 Nov 2001 15:12:46 -0500 (EST) Message-ID: <3BFEAE26.62904E93@steltor.com> Date: Fri, 23 Nov 2001 15:14:30 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Minor Search issues References: <3BF437D8.11B85F10@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 Done! Doug Royer wrote: > > > 5.1.1 Grammar For Search Mechanism > > > > > maxresults = "MAXRESULTS" ":" integer CRLF > Add: # If not specified then MAXRESULTS is unlimited. > > > maxsize = "MAXSIZE" ":" integer CRLF > Add: # If not specified then MAXSIZE is unlimited. From owner-ietf-calendar@mail.imc.org Fri Nov 23 15:48:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23271 for ; Fri, 23 Nov 2001 15:48:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANKWu422970 for ietf-calendar-bks; Fri, 23 Nov 2001 12:32:56 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANKWs822966 for ; Fri, 23 Nov 2001 12:32:54 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA14417 for ; Fri, 23 Nov 2001 12:32:55 -0800 (PST) Message-ID: <3BFEB264.634AA9C5@Royer.com> Date: Fri, 23 Nov 2001 13:32:36 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (ALARMREF?) ALARMID to VALARM after stored? References: <3BFD80A5.4F481F2D@steltor.com> Content-Type: multipart/mixed; boundary="------------0E84221D8E247AEDA6780AEC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0E84221D8E247AEDA6780AEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The required transformation would be pretty straightforward. > Really minor compared to the required conversion of CAP calendar > addresses to mailto URLs. Furthermore, in most cases you should > probably not send the VALARM to the other attendees. What's the > point of sending your VALARM to other people? Maybe they want it? Maybe it is not a person, but a program that is doing work for you and the action in the alarm is a program to run? Maybe the real need for the request is to synchronize or copy a calendar? I think the point is that they can send VALARMs, and you can get VALARMs. So John's point is valid - if we do this - there must be an iTIP transformation process when sending/getting iTIP messages. iTIP does not handle them, so any iTIP messages sent would have to include them and not reference them. But the same is true for VCARs and VTIMEZONEs. We can't break RFC2446, so there MUST BE a transformation. > A CUA could easily remind the CU about the impact of changing a > VALARM referenced by other VALARMs before sending the "modify" > command to the CAP server. > > Personally, I would be more concerned about the consequences of > modifying a VCAR referenced by other VCARs, or a VTIMEZONE on > which multiple VEVENTs may depend. Time zones do change and thus any good implementation MUST NOT think they are static. The same is true of a VCAR, they are not static. And a CUA can change any VALARM already. The only real change is do we allow VALARMs outside of a VEVENT or VTODO? If yes, then we MUST specify rules for modification. Do we say that if a CUA modifies a VALARM that is common to more than one VEVENT do we: 1) MODIFY the one global and warn the user? 2) Replace the VALARM in the component with the global VALARM. Remove the ALARMREF in the copy. Then modify the copy in that target component? 3) Add a parameter that says 'target components only' or 'all'. Then apply rule (2). 4) Not allow global VALARMs? I would lean to (4) in CAP, just to get it out the door. However if the WG wants global VALARMs - I would not object. -Doug --------------0E84221D8E247AEDA6780AEC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------0E84221D8E247AEDA6780AEC-- From owner-ietf-calendar@mail.imc.org Fri Nov 23 16:19:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23569 for ; Fri, 23 Nov 2001 16:19:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANL1rg24833 for ietf-calendar-bks; Fri, 23 Nov 2001 13:01:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANL1q824825 for ; Fri, 23 Nov 2001 13:01:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA03862; Fri, 23 Nov 2001 16:01:48 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANL1iH09947; Fri, 23 Nov 2001 16:01:45 -0500 (EST) Message-ID: <3BFEB9A3.EBF10FAF@steltor.com> Date: Fri, 23 Nov 2001 16:03:31 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: SQL-MIN fix References: <3BF4390D.3F2B1D99@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 Done! Doug Royer wrote: > > Is: > capmin-col = # Any property name found in any of the components. > > Should be: > capmin-col = (# Any property name found in any of the components. > / "*" ) From owner-ietf-calendar@mail.imc.org Fri Nov 23 16:28:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23630 for ; Fri, 23 Nov 2001 16:28:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANLDcx25185 for ietf-calendar-bks; Fri, 23 Nov 2001 13:13:38 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANLDa825181 for ; Fri, 23 Nov 2001 13:13:37 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA04165; Fri, 23 Nov 2001 16:13:32 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANLDUH10866; Fri, 23 Nov 2001 16:13:30 -0500 (EST) Message-ID: <3BFEBC62.EEA25EF8@steltor.com> Date: Fri, 23 Nov 2001 16:15:14 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Method missing from example and text. References: <3BF4416F.7A2D1822@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 The section has been fixed in the latest version of CAP. George Doug Royer wrote: > > (1) Title change: > > Is: > 7.2.1.2.1 Creating New Calendars > > Should be: > > 7.2.1.2.1 Creating New Calendars and Components > > (2) The second example: > > Is: > > ... > Example to create a new component. > ... > > C: BEGIN:VEVENT > C: DTSTART:99990307T180000Z > C: UID:abcd12345 > C: DTEND:99990307T190000Z > C: SUMMARY:Important Meeting > C: END:VEVENT > C: END:VCOMMAND > C: END:VCAP > > (2.a) It is missing the METHOD: poperty that tells the CS the status > of the component: > > (2.b) Should be (changes marked with a '*') > > ... > * Example to create a new booked component. > ... > > C: BEGIN:VEVENT > C: METHOD:CREATE > C: DTSTART:99990307T180000Z > C: UID:abcd12345 > C: DTEND:99990307T190000Z > C: SUMMARY:Important Meeting > C: END:VEVENT > C: END:VCOMMAND > C: END:VCAP From owner-ietf-calendar@mail.imc.org Fri Nov 23 16:30:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23687 for ; Fri, 23 Nov 2001 16:30:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fANLGHs25249 for ietf-calendar-bks; Fri, 23 Nov 2001 13:16:17 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANLGG825245 for ; Fri, 23 Nov 2001 13:16:16 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA04243; Fri, 23 Nov 2001 16:16:11 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANLG9H11181; Fri, 23 Nov 2001 16:16:09 -0500 (EST) Message-ID: <3BFEBD03.686018B9@steltor.com> Date: Fri, 23 Nov 2001 16:17:55 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DELETE restriction table - QUERYNAME/QUERY References: <3BF44B58.D8692099@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 This has been fixed in the latest version of CAP. George Doug Royer wrote: > > 7.2.1.3 DELETE Method > > Says ... > > QUERYNAME 1 Name by which this query is > referenced > QUERY 1 The query > > Should be: > > QUERYNAME 0 or 1 Name by which this query is > referenced > QUERY 0 or 1 The query. MUST BE supplied if > QUERYNAME is not supplied. > > As you may use a stored QUERY by name. From owner-ietf-calendar@mail.imc.org Fri Nov 23 16:32:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23721 for ; Fri, 23 Nov 2001 16:32:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fANLJGZ25317 for ietf-calendar-bks; Fri, 23 Nov 2001 13:19:16 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANLJF825313 for ; Fri, 23 Nov 2001 13:19:15 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA04330; Fri, 23 Nov 2001 16:19:10 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANLJ8H11373; Fri, 23 Nov 2001 16:19:09 -0500 (EST) Message-ID: <3BFEBDB7.8CA2010D@steltor.com> Date: Fri, 23 Nov 2001 16:20:55 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MODIFY missing error numbers. References: <3BF44C01.5EAD7CAB@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 Was fixed in the latest version. George Doug Royer wrote: > > Error numbers missing, and 'Permission' . > > -- > > 7.2.1.4 MODIFY Method > > Arguments: None > > Data: no specific data for this command > > Result: > > 2.0 - successfully modified the component or calendar > > Permission > > Calendar or component not found > > Bad args > > Container(s) not found From owner-ietf-calendar@mail.imc.org Fri Nov 23 16:47:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23846 for ; Fri, 23 Nov 2001 16:47:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANLQU325544 for ietf-calendar-bks; Fri, 23 Nov 2001 13:26:30 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANLQT825540 for ; Fri, 23 Nov 2001 13:26:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA15199 for ; Fri, 23 Nov 2001 13:26:29 -0800 (PST) Message-ID: <3BFEBEE2.2F736E3D@Royer.com> Date: Fri, 23 Nov 2001 14:25:54 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> Content-Type: multipart/mixed; boundary="------------714BFF851F76D480E19E3B90" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------714BFF851F76D480E19E3B90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > BTW, OWNERRIGHTS is not part of the predefined CARID, > but that's beside the point. Should have said DEFAULTOWNER -- :-) (This one moved from the end, I modified the text send by Bernard and myself by replacing OWNERRIGHTS with the correct tag: DEFAULTOWNER). > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > 2- Do we really need a VCAR specific property to hold > > > VCAR identifiers? Couldn't we simply use the UID > > > property for that purpose? > > > > The more I think about this, the more I am concerned that > > it's not a good idea. Take the predefined CARID's for example: > > > > DEFAULTOWNER is the CARID. > > > > However MANY different calendars will not have the same contents > > for that VCAR. So it is no longer a unique ID for a VCAR. It is only > > unique for its scope. So by definition we would be defining VCARS > > with Unique IDs that were not Unique IDs. And a VCAR/UID would then > > not uniquely define a VCAR. > > > > For ALARMID, we are not pre-defining any, so UID would be okay > > with me. > > On the other hand, when I would write the following VCAR: > > BEGIN:VCAR > GRANT:CARREF:DEFAULTOWER > ... > END:VCAR You could, but I don't think that is a valid VCAR. Did you mean the following VCAR that uses an existing VCAR? BEGIN:VCAR GRANT;CARID=DEFAULTOWNER:... ... END:VCAR > I wouldn't know for sure that it will always make reference > to the same VCAR. > > Furthermore, a VQUERY performed on a hierarchy of VAGENDAs > could return multiple VCARs with the same CARID. The calendar > user wouldn't have any way to distinguish the returned VCARs. For the same TARGET, the contents of CARID 'foo' is only the same at one instance in time. And a VCAR is contained in the hierarchy of BEGIN/END matched to a TARGET and CMDID, thus TARGET+CARID is unique at one point in time. It is true that TARGET:1 and TARGET:2 can each have a CARID:123 and they might not have same contents. That's my point - it is CARID is only unique per calendar. Unlike UID which is supposed to be unique in the world. With CARID, a CUA can find out what it can do, and there is a handle to help organize them in a calendar. But the contents of that VCAR are not static - only the CARID value is static and as CUA's need to find out what they can do, that is why the predefined CARIDs were created - so a CUA can find things by predefined name - CARID. > Finally, enforcing specific identifier for the CAR-MIN VCAR > will not allow users to make reference to the VCAR they are > re-defining (their new definition would hide the previous > definition(s)). The point of the defined VCARs is that a CUA can find if it can do specific things and find the calendars specific contents for that known named CARID. So no matter what the contents of that VCAR, a CUA can find its REQUESTONLY by doing a VQUERY for REQUESTONLY by name. Otherwise a CUA would have to VQUERY for all VCARs, then sort them itself. > What would you think of using reserved names for the CAR-MIN > VCARs instead? The predefined CARIDs are part of CAR-MIN. So, what do you mean by 'instead'? Did you mean CAR-MIN only? If so we would have two version of VCAR. Currently one is just an extension of the other. > It is not ideal, since we would have to make > the CUA responsible for the localization of these reserved > names, The point is that they are FIXED names, so a CUA can do a VQUERY by name - localizing the 'reserved names' breaks that ability. >but on the other hand, it should be sufficient to meet > our requirements. For instance: > > BEGIN:VCAR > UID:20011121T120000Z-00003@host.com > NAME:DEFAULTOWNER > ... > END:VCAR How? Above you said that DEFAULTOWNER can be localized, so tell me, how I find the DEFAULTOWNER if you call it 'asldkfjfjs' in your locale? Show me a VQUERY that can fetch DEFAULTOWNER no matter what the localized name? > That raises another question with respect to overriding > inherited VCARs: > > Was a VCAR with the CARID:DEFALTOWNER(a) supposed to override > all RIGHTS value type of other VCARs with the same CARID > in the calendar hierarchy, or (b) simply specific GRANT and > DENY as you mentioned in your reply to (VCAR: Overriding > inherited VCAR)? In all cases, a calendars specific VCARS details override any inherited VCAR details. So yes (b). I took your original question to mean: What happens if the VCAR for a calendar overrides some (but not all) of the GRANT/DENY that it would have inherited? I think I said that those specific differences are resolved to the calendar specific VCARs - the specific calendar VCAR details win. Top level calendar: BEGIN:VCAR CARID:REQUESTONLY GRANT:UPN=joe,sam,tom;.... ... END:VCAR Target Sub-Calendar under the Top level calendar: BEGIN:VCAR CARID:REQUESTONLY DENY:UPN=joe:... ... END:VCAR Sam and Tom only can do METHOD:REQUEST on the target calendar. A VQUERY for REQUSESTONLY on the target calendar would return: BEGIN:VCAR CARID:REQUESTONLY GRANT:UPN=sam,tom ... END:VCAR Even though no specific VCAR with those contents was specifically stored. The predefined VCARs are by function identifiable by CARID, not by contents. That's why UID is not valid, at no point would that UID in a VCAR uniquely identify any contents. > If (a) is true, why the CAR-MIN VCAR need to be handled in > a special way? CAR-MIN is a subset of CAR-FULL. The fact is that there are some VCARs predefined by 'function', VQUERYable by predefined CARIDs who's contents are not predefined and thus not unique. > If (b) is true, there is no reason to use the same CARID > more than once. Any VCAR can override the CAR-MIN VCARs > regardless of its CARID. I think that my example shows that the same CARID is used more than once in a CS- and needs to be. -Doug --------------714BFF851F76D480E19E3B90 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------714BFF851F76D480E19E3B90-- From owner-ietf-calendar@mail.imc.org Fri Nov 23 16:49:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23883 for ; Fri, 23 Nov 2001 16:49:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANLZRD25962 for ietf-calendar-bks; Fri, 23 Nov 2001 13:35:27 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANLZP825957 for ; Fri, 23 Nov 2001 13:35:25 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA04652; Fri, 23 Nov 2001 16:35:21 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANLZJH12494; Fri, 23 Nov 2001 16:35:19 -0500 (EST) Message-ID: <3BFEC181.A6AD7A52@steltor.com> Date: Fri, 23 Nov 2001 16:37:05 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Missing errno number and text References: <3BF44F8F.F176F901@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 It has been fixed in the latest version. George Doug Royer wrote: > > Permission and missing error numbers. > > 7.2.1.5 MOVE Method > > Arguments: ContainerId > > Data: data as described below > > Result: > > 2.0 - success > > 2.2 - will attempt operation on the remote CAP server > > Permission > > Bad args > > Parent Calendar(s) not found From owner-ietf-calendar@mail.imc.org Fri Nov 23 16:55:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24000 for ; Fri, 23 Nov 2001 16:55:22 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fANLbEI26054 for ietf-calendar-bks; Fri, 23 Nov 2001 13:37:14 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANLbD826046 for ; Fri, 23 Nov 2001 13:37:13 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA04700; Fri, 23 Nov 2001 16:37:09 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANLb7H12763; Fri, 23 Nov 2001 16:37:07 -0500 (EST) Message-ID: <3BFEC1ED.1D0A2B6@steltor.com> Date: Fri, 23 Nov 2001 16:38:53 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: From MOVE [EDITORS NOTE... References: <3BF45215.DDFBCA83@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 I agree. Removed all these issues from the to do list. Anyone disagree? George Doug Royer wrote: > > [EDITORS NOTE: Issues: > > 1) Should one be able to move a calendar owned by person X into a > calendar owned by person Y. (Can these such rights be specified > in VCARs?) > > If they have the VCAR - that is what they are for. > Yes - you can GRANT any UPN rights. > > 2) Should we also be able to move components from one calendar to > another? What if the calendars are owned by different users? (With > components one can do a copy, then delete the original.) > > I say yes if you have the VCAR. > > Moving of components: > I don't think that we intended to limit moving to calendars only. > I think we just forgot to write it down - comments? > > 3) There was very little information about MOVE in CAP. Why was > it added? Was there some major need for it? > > It was added because people wanted it :-) > Need: people reorganize themselves, so they will want to reorganize > their calendars. > > 4) Can one move multiple calendars into one calendar?] > > Moving a calendar into another creates a sub-calendar - yes. > There is no restriction on the number of sub-calendars. > > -Doug From owner-ietf-calendar@mail.imc.org Fri Nov 23 16:55:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24021 for ; Fri, 23 Nov 2001 16:55:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fANLeb626237 for ietf-calendar-bks; Fri, 23 Nov 2001 13:40:37 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANLea826233 for ; Fri, 23 Nov 2001 13:40:36 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA04848; Fri, 23 Nov 2001 16:40:32 -0500 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fANLeTH13133; Fri, 23 Nov 2001 16:40:29 -0500 (EST) Message-ID: <3BFEC2B7.CE1947D5@steltor.com> Date: Fri, 23 Nov 2001 16:42:15 -0500 From: George Babics X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: READ - include readable properties? References: <3BF45426.D0DBE786@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 There is already an item on the to list for such an example. Removed the editors note. George Doug Royer wrote: > > In CAP/READ: > > > [EDITORS NOTE: Should the one(s) that the UPN has access to - be > > returned?] > > Yes - that should also be in the example? From owner-ietf-calendar@mail.imc.org Fri Nov 23 17:03:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24106 for ; Fri, 23 Nov 2001 17:03:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANLqaE26480 for ietf-calendar-bks; Fri, 23 Nov 2001 13:52:36 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANLqY826476 for ; Fri, 23 Nov 2001 13:52:34 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA15552 for ; Fri, 23 Nov 2001 13:52:35 -0800 (PST) Message-ID: <3BFEC4F7.FD7A6CD1@Royer.com> Date: Fri, 23 Nov 2001 14:51:51 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@Royer.com> <3BFC2E3C.375E9640@steltor.com> <3BFC3A84.57438517@Royer.com> <3BFC4F8B.287BB80F@steltor.com> Content-Type: multipart/mixed; boundary="------------EB5951BC768A5BA3BCC86D76" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EB5951BC768A5BA3BCC86D76 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > > Sorry. My question should have been: > > > > > > Do we need "default VCARs for newly created top level > > > calendars" given that we have VCAR inheritance? > > > > > > That is, a newly created top level calendar automatically inherits > > > the VCARs directly contained under CALSTORE. The default VCARs > > > could simply be all the VCARs directly contained under CALSTORE. > > > > > > I don't understand why we would need to copy the default VCARs > > > in every top level calendar. > > > > I was getting these confused: > > > > 11.1 Calendar Store Properties / DEFAULT_VCAR > > 11.2 Calendar Properties / DEFAULT_VCAR > > > > I agree, 11.2 DEFAULT_VCARS is not needed. > > Why do you think 11.1 DEFAULT_VCARS is needed? > > The list of DEFAULT_VCARS is simply the list of > all the VCARs directly contained under the > CALSTORE. No, it is a list of the defined CARIDs at the CS level. Not all VCARs at the CS level need to be named with a CARID. > There is no need to define this one > as well. It can be obtained with a simple VQUERY. It lists any predefined VCARS that exist by CARID. It allowed small devices to determine which 'predefined' VCARs the CS knows, that the small CUA understands. So the small CUA can just query for what it wants and does not have to do a full VQUERY of what might be a large set of VCARs - then sort them. REQUESTONLY is by definition limited to what the authenticated entity can do, so the small CUA does not have to care about anything other than understanding that what comes back applied to the current authenticated entity. A small CUA can say: 'I know the function of CARID:REQUESTONLY', but I don't care about the rest of them. There was a lot of resistance to not having predefined CARID's by function VQUERYable by name. So then the debate went to, how do I find out which predefined CARIDs does the CS support? The answer was to add DEFAULT_VCAR at the CS level. Then we agreed that any predefined 'access' MUST BE identifiable by a VCAR. Then others asked - 'how can we expand this list in the future?'. Then others asked what about any current VCAR with a CARID at the CS level, so then DEFAULT_VCARs was expanded to include any VCAR in the CS that had a CARID. In that way any CARID in DEFAULT_VCAR might be a predefined CARID, and it no long matters to the CUA, it simply gets a list, some of which may be predefined in an RFC. --------------EB5951BC768A5BA3BCC86D76 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------EB5951BC768A5BA3BCC86D76-- From owner-ietf-calendar@mail.imc.org Fri Nov 23 17:58:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24505 for ; Fri, 23 Nov 2001 17:58:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fANMfeF28599 for ietf-calendar-bks; Fri, 23 Nov 2001 14:41:40 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANMfd828595 for ; Fri, 23 Nov 2001 14:41:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA16275 for ; Fri, 23 Nov 2001 14:41:40 -0800 (PST) Message-ID: <3BFED068.350C4671@Royer.com> Date: Fri, 23 Nov 2001 15:40:40 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: From CAP DELETE... References: <3BF30154.13D54329@Royer.com> <3BFEA8C0.7346C691@steltor.com> Content-Type: multipart/mixed; boundary="------------ADD184B7357AEF66CCC68788" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ADD184B7357AEF66CCC68788 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > > > > - VQUERY EXPAND and MAXSIZE parameters do not seem to apply to > > deletion? > > > > For DELETE - EXPAND has no meaning... > > > > Some implementors were talking about expanding recurring VEVENTs > > as the store them (vs expanding them when queried). So it does > > bring up a good point. However, you would be deleting by > > date range or UID (all). > > > > Deleting a VEVENT by UID would result in ONE reply as no > > matter how the CS stores the VEVENT, there is only ONE VEVENT > > with that UID. > > > > You can also delete a range of events by doing a query on > SUMMARY. EXPAND applied to the expansion of one VEVENT into multiple instances. Okay - so I think it is still true - For DELETE - EXPAND has no meaning? Do you agree? As in you do not get a reply to each instance (RRULE) of VEVENT times each match of SUMMARY. If you delete N VEVENTs because of the contents of their SUMMARY, they each have one UID. You would get N replies, but not because any one or more VEVENTs had multiple instances. And you would not get (N * instnaces) replies. > > Deleting a VEVENT by date/range would be done with a MODIFY > > and not a DELETE - you would get one reply. > > > > You DELETE COMPONENTS (or calendars) - not instances of recurrence. > > But can not instances be expressed as components? > One would use modify to remove properties, delete to remove > components, and what to remove instances? iTIP CANCEL with a recurrance-id. Then use METHOD:MODIFY to update the data in the store. The CUA could MODIFY the entry with an EXRULE, EXDATE, or whatever it needed to modify the entry to exclude the instance(s) what was canceled. > > > > And for MAXSIZE: > > > > Deleting with something like 'all VEVENTs where ATTENDEE contains > > user-x' could return N number of replies. So it does sound > > like a good idea - as long as the CUA knows that it can not > > specify which N are deleted. The CUA would then have to > > re-issue the DELETE METHOD - over and over? > > > > ** WE NEED A STATEMENT in CAP that says that commands > > issued with a MAXSIZE limit MUST BE be repeatedly > > called until the end is reached as there is no way > > to tell which 'N-number' of components were acted upon. > > And that failure to do this probably will result in > > undesired effects. > > Does it have to be a must? There may be cases where the CUA > only wants to check if there is at least one match, or if the > user aborts a search because what he was looking for was in > the first "N" number of components returned. If you want to check, don't do a DELETE METHOD. Then how about prefixing it with some like: For actions by the CUA that modify or delete anything in the calendar with MAXSIZE set, .... ... Otherwise the results are unpredictable. > However, I do not see cases where a user will want to delete > only the first N components matching the query. > > > > > - Can one use DELETE to remove all VALARMs and VTIMEZONEs that > > match a certain search criteria and that belong to all components, > > event though VALARMs and VTIMEZONEs never exist as independent > > components? Or should one use MODIFY? If they can be deleted, do > > we return the REQUEST-STATUS of their deletion in a VEVENT or > > separately? > > > > VALARMS should have a ALARMID (see my previous post). > > VTIMEZONEs have an id. > > We only have to make sure that the syntax for VQUERY permits > this. It does. --------------ADD184B7357AEF66CCC68788 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------ADD184B7357AEF66CCC68788-- From owner-ietf-calendar@mail.imc.org Mon Nov 26 10:50:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05350 for ; Mon, 26 Nov 2001 10:50:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAQFWQA11769 for ietf-calendar-bks; Mon, 26 Nov 2001 07:32:26 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQFWO811765 for ; Mon, 26 Nov 2001 07:32:24 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA20112; Mon Nov 26 10:30:02 2001 Subject: Re: ALARMID to VALARM after stored? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 26 Nov 2001 10:35:38 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/26/2001 10:35:41 AM, Serialize complete at 11/26/2001 10:35:41 AM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Top-level VALARMs, though, are *not* a minor change. You're moving from >> searching for a VALARM within the VEVENT to searching within the VEVENT's >> container. Your VEVENT cannot then be passed to a non-CAP implementation >> (say, via iMIP) without transforming it. > >The required transformation would be pretty straightforward. Depends on your internal data representation for your iCalendar objects. In any event, the cost of the transformation is definitely greater than zero. You have not established that the benefits of top-level VALARMs are greater than zero (I still maintain that the benefits are negative). >Furthermore, in most cases you should >probably not send the VALARM to the other attendees. What's the >point of sending your VALARM to other people? Aside from the points Doug's already made: iTIP is not the only way, other than CAP, to use iCalendar. Maybe I just want to export a VEVENT to a file, or a PDA. My Nokia cellphone, for example, uses [iv]Calendar to send and receive calendar entries via SMS; if AT&T's email-to-SMS gateway recognized text/calendar, I could send the VEVENT to my phone. >A CUA could easily remind the CU about the impact of changing a >VALARM referenced by other VALARMs before sending the "modify" >command to the CAP server.; Rule of thumb for usability: don't let the user make mistakes. Warning the user when they're about to make a mistake does not cut it. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=============================================================| |The cheapest, fastest, most reliable components of a computer| |system are those that aren't there.--Gordon Bell | \=============================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 27 14:20:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19509 for ; Tue, 27 Nov 2001 14:20:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fARIoqx24236 for ietf-calendar-bks; Tue, 27 Nov 2001 10:50:52 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARIon824231 for ; Tue, 27 Nov 2001 10:50:50 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA19089 for ; Tue, 27 Nov 2001 12:47:59 -0600 From: "Shannon J. Clark" To: "Ietf-Calendar@Imc. Org" Subject: iCalendar - "octets" question Date: Tue, 27 Nov 2001 12:51:02 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A developer just asked me "What is an octet?" Perhaps this is fairly basic - but it does not appear to be clearly defined anywhere in our standard - and it is used in section 4.1 on content lines. In general my developer (and I) expected to read "75 characters" - but instead read "75 octets" - does this related to multi-byte encoding? In any case I suspect that a simple definition of the term would help. thanks, Shannon Shannon J. Clark President - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Tue Nov 27 14:58:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22206 for ; Tue, 27 Nov 2001 14:58:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fARJhUx25967 for ietf-calendar-bks; Tue, 27 Nov 2001 11:43:30 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARJhT825961 for ; Tue, 27 Nov 2001 11:43:29 -0800 (PST) To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: Re: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_11202001 November 20, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Tue, 27 Nov 2001 14:52:42 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/27/2001 02:50:00 PM, Serialize complete at 11/27/2001 02:50:00 PM Content-Type: multipart/alternative; boundary="=_alternative 006B7EB385256B11_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B7EB385256B11_= Content-Type: text/plain; charset="US-ASCII" Shannon asked: >A developer just asked me "What is an octet?" >[Snip] >In general my developer (and I) expected to read "75 characters" - but >instead read "75 octets" - does this related to multi-byte encoding? Octet is used in tons of RFCs w/o actually defining it (go ahead and do a FT search like I did). Its actually defined WAAAAAAAAAAY back in RFC 760 / STD 5 (Internet Protocol), top of Page 43: octet An eight bit byte. However, w/o actually doing lots of digging you could also use your Latin to the question too since Octet is defined as "a group of 8". Instead of saying "75 characters" that would imply that it could in fact be >200 8-bit bytes long in some Multi-byte character sets or using "75 bytes" which can vary in size based on the platform in use (8-bit byte, 16-bit bytes, etc), we wanted to indicate "75 8-bit bytes" so that any implementation conforms properly. 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 006B7EB385256B11_= Content-Type: text/html; charset="US-ASCII"
Shannon asked:
>A developer just asked me "What is an octet?"
>[Snip]
>In general my developer (and I) expected to read "75 characters" - but
>instead read "75 octets" - does this related to multi-byte encoding?

Octet is used in tons of RFCs w/o actually defining it (go ahead and do a FT search like I did).  Its actually defined WAAAAAAAAAAY back in RFC 760 / STD 5 (Internet Protocol), top of Page 43:

octet
         An eight bit byte.

However, w/o actually doing lots of digging you could also use your Latin to the question too since Octet is defined as "a group of 8".

Instead of saying "75 characters" that would imply that it could in fact be >200 8-bit bytes long in some Multi-byte character sets or using "75 bytes" which can vary in size based on the platform in use (8-bit byte, 16-bit bytes, etc), we wanted to indicate "75 8-bit bytes" so that any implementation conforms properly.

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 006B7EB385256B11_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 27 15:18:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22880 for ; Tue, 27 Nov 2001 15:18:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fARK1Jg26739 for ietf-calendar-bks; Tue, 27 Nov 2001 12:01:19 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARK1H826734 for ; Tue, 27 Nov 2001 12:01:17 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id OAA24965; Tue Nov 27 14:58:57 2001 Subject: Re: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 27 Nov 2001 15:04:39 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/27/2001 03:04:42 PM, Serialize complete at 11/27/2001 03:04:42 PM Content-Type: text/plain; charset="us-ascii" To: "Ietf-Calendar@Imc. Org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >A developer just asked me "What is an octet?" A byte. The word's use in RFCs seems to trace back to the days when people could still disagree on how many bits in a byte. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |==============================================================| |In the long run, there is no middle ground between justice and| |genocide. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 27 15:35:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23605 for ; Tue, 27 Nov 2001 15:35:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fARKJU727420 for ietf-calendar-bks; Tue, 27 Nov 2001 12:19:30 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARKJS827416 for ; Tue, 27 Nov 2001 12:19:28 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA19246; Tue, 27 Nov 2001 14:16:35 -0600 From: "Shannon J. Clark" To: Cc: Subject: RE: iCalendar - "octets" question Date: Tue, 27 Nov 2001 14:19:41 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C1774E.8DE16D40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C1774E.8DE16D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bruce, Thanks - I suspect I am not the only person to wonder about this - I did guess that it had something to do with 8 - but its exact meaning and implications for multi-bytes was unclear. Does this mean that in a multi-byte object you SHOULD wrap potentially in the middle of character? Does this have any potential problems? Or would it be recommended that the wrapping happen only at the ends of a character - i.e. at 73 or 74 octets if 75 might cause a break of a character? Should any of this be further detailed? As we look at internationalization this strikes me as one area to look at - clearly it was considered in the writing - just want to make sure we don't have any unintended consequences. Shannon -----Original Message----- From: Bruce_Kahn@iris.com [mailto:Bruce_Kahn@iris.com] Sent: Tuesday, November 27, 2001 1:53 PM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: Re: iCalendar - "octets" question Shannon asked: >A developer just asked me "What is an octet?" >[Snip] >In general my developer (and I) expected to read "75 characters" - but >instead read "75 octets" - does this related to multi-byte encoding? Octet is used in tons of RFCs w/o actually defining it (go ahead and do a FT search like I did). Its actually defined WAAAAAAAAAAY back in RFC 760 / STD 5 (Internet Protocol), top of Page 43: octet An eight bit byte. However, w/o actually doing lots of digging you could also use your Latin to the question too since Octet is defined as "a group of 8". Instead of saying "75 characters" that would imply that it could in fact be >200 8-bit bytes long in some Multi-byte character sets or using "75 bytes" which can vary in size based on the platform in use (8-bit byte, 16-bit bytes, etc), we wanted to indicate "75 8-bit bytes" so that any implementation conforms properly. 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... ------=_NextPart_000_0004_01C1774E.8DE16D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bruce,
 
Thanks = - I suspect I=20 am not the only person to wonder about this - I did guess that it had = something=20 to do with 8 - but its exact meaning and implications for multi-bytes = was=20 unclear.
 
Does = this mean that=20 in a multi-byte object you SHOULD wrap potentially in the middle of = character?=20 Does this have any potential problems? Or would it be recommended that = the=20 wrapping happen only at the ends of a character - i.e. at 73 or 74 = octets if 75=20 might cause a break of a character?
 
Should = any of this=20 be further detailed? As we look at internationalization this strikes me = as one=20 area to look at - clearly it was considered in the writing - just want = to make=20 sure we don't have any unintended consequences.
 
Shannon
-----Original Message-----
From: = Bruce_Kahn@iris.com=20 [mailto:Bruce_Kahn@iris.com]
Sent: Tuesday, November 27, = 2001 1:53=20 PM
To: Shannon J. Clark
Cc:=20 ietf-calendar@imc.org
Subject: Re: iCalendar - "octets"=20 question


Shannon=20 asked:
>A=20 developer just asked me "What is an octet?"
>[Snip]
>In = general my=20 developer (and I) expected to read "75 characters" - = but
>instead read=20 "75 octets" - does this related to multi-byte encoding?=20

Octet is used in tons of RFCs = w/o=20 actually defining it (go ahead and do a FT search like I did). =  Its=20 actually defined WAAAAAAAAAAY back in RFC 760 / STD 5 (Internet = Protocol), top=20 of Page 43:

octet
    =  =20    An eight bit byte.

However, w/o actually doing lots of digging you could also = use your=20 Latin to the question too since Octet is defined as "a group of = 8".=20

Instead of saying "75 = characters" that=20 would imply that it could in fact be >200 8-bit bytes long in some=20 Multi-byte character sets or using "75 bytes" which can vary in size = based on=20 the platform in use (8-bit byte, 16-bit bytes, etc), we wanted to = indicate "75=20 8-bit bytes" so that any implementation conforms properly.=20

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=20 Kahn                   =  =20            INet: = Bruce_Kahn@iris.com
Iris=20 Associates                 =  =20        Phone: 978.392.5335
Westford, MA, USA = 01886=20                   =  FAX: and=20 nothing but the FAX...
Standard disclaimers apply, even where = prohibited by=20 law...
------=_NextPart_000_0004_01C1774E.8DE16D40-- From owner-ietf-calendar@mail.imc.org Tue Nov 27 16:34:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25890 for ; Tue, 27 Nov 2001 16:34:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fARLLvY29395 for ietf-calendar-bks; Tue, 27 Nov 2001 13:21:57 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARLLt829391 for ; Tue, 27 Nov 2001 13:21:56 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id QAA14915; Tue Nov 27 16:19:35 2001 Subject: RE: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 27 Nov 2001 16:25:17 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/27/2001 04:25:21 PM, Serialize complete at 11/27/2001 04:25:21 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Does this mean that in a multi-byte object you SHOULD wrap potentially in the middle of character? Probably MAY, rather than SHOULD. >Does this have any potential problems? It shouldn't; folding and unfolding lines is defined to be irrelevant to the semantics of the lines, which means that the simplest way to do it is to do it below the level of the parser/lexer. By the time the lines reach the parser, they've been unfolded. One reason to make sure that splitting characters is explicitly permitted is that there are legitimate cases in which the code that folds the lines doesn't actually know it's using multibyte characters. For example, the iCalendar implementation I did for eCal didn't contain any explicit character-set code; it was assumed that all the character sets we would support sending would be supersets of ASCII. The code that did a MIME wrapper could tag the object as, say, UTF-8, but there was no need for the code that generated the lines to understand UTF-8; it just used whatever strings it was given. /==========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |==========================================================| |A man's concepts should exceed his vocabulary, or what's a| |metaphor? | \==========================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 27 17:14:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27414 for ; Tue, 27 Nov 2001 17:14:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fARLwEU00613 for ietf-calendar-bks; Tue, 27 Nov 2001 13:58:14 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARLwC800608 for ; Tue, 27 Nov 2001 13:58:12 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id PAA19414; Tue, 27 Nov 2001 15:55:18 -0600 From: "Shannon J. Clark" To: "John Stracke" , Subject: RE: iCalendar - "octets" question Date: Tue, 27 Nov 2001 15:58:26 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, Thanks - that seems very reasonable, does anyone have proposed text to add to this section to make this explicitly permitted? (and perhaps to also define what an "octet" is...) Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Tuesday, November 27, 2001 3:25 PM To: ietf-calendar@imc.org Subject: RE: iCalendar - "octets" question >Does this mean that in a multi-byte object you SHOULD wrap potentially in the middle of character? Probably MAY, rather than SHOULD. >Does this have any potential problems? It shouldn't; folding and unfolding lines is defined to be irrelevant to the semantics of the lines, which means that the simplest way to do it is to do it below the level of the parser/lexer. By the time the lines reach the parser, they've been unfolded. One reason to make sure that splitting characters is explicitly permitted is that there are legitimate cases in which the code that folds the lines doesn't actually know it's using multibyte characters. For example, the iCalendar implementation I did for eCal didn't contain any explicit character-set code; it was assumed that all the character sets we would support sending would be supersets of ASCII. The code that did a MIME wrapper could tag the object as, say, UTF-8, but there was no need for the code that generated the lines to understand UTF-8; it just used whatever strings it was given. /==========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |==========================================================| |A man's concepts should exceed his vocabulary, or what's a| |metaphor? | \==========================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 27 20:03:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01693 for ; Tue, 27 Nov 2001 20:03:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAS0lbk06521 for ietf-calendar-bks; Tue, 27 Nov 2001 16:47:37 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS0la806516 for ; Tue, 27 Nov 2001 16:47:36 -0800 (PST) To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: RE: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_11202001 November 20, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Tue, 27 Nov 2001 19:47:36 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/27/2001 08:02:36 PM, Serialize complete at 11/27/2001 08:02:36 PM Content-Type: multipart/alternative; boundary="=_alternative 00040AA285256B12_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00040AA285256B12_= Content-Type: text/plain; charset="US-ASCII" Shannon replied on 11/27/2001 03:19:41 PM: > Does this mean that in a multi-byte object you SHOULD wrap > potentially in the middle of character? Id agree w/John that it is a MAY rather than a SHOULD. The folding / unfolding should be happening at a different level than the character set encodings. > Does this have any potential > problems? Only if someone built a bad parser / generator that mixed in character set encodings as part of the folding / unfolding process. It can be done but you cannot spec out stupidity... > Or would it be recommended that the wrapping happen only > at the ends of a character - i.e. at 73 or 74 octets if 75 might > cause a break of a character? Keep the layers properly separated and this is a non-issue. The parser just sees a stream of bytes that it interprets properly; the lower layer code should be doing the folding/unfolding magic transparently. Id say this is one time that John and I are in 100% agreement for a 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 00040AA285256B12_= Content-Type: text/html; charset="US-ASCII"
Shannon replied on 11/27/2001 03:19:41 PM:
> Does this mean that in a multi-byte object you SHOULD wrap
> potentially in the middle of character?

Id agree w/John that it is a MAY rather than a SHOULD.  The folding / unfolding should be happening at a different level than the character set encodings.

>                                         Does this have any potential
> problems?

Only if someone built a bad parser / generator that mixed in character set encodings as part of the folding / unfolding process.  It can be done but you cannot spec out stupidity...

>           Or would it be recommended that the wrapping happen only
> at the ends of a character - i.e. at 73 or 74 octets if 75 might
> cause a break of a character?
Keep the layers properly separated and this is a non-issue.  The parser just sees a stream of bytes that it interprets properly; the lower layer code should be doing the folding/unfolding magic transparently.

Id say this is one time that John and I are in 100% agreement for a 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 00040AA285256B12_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 27 20:11:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01866 for ; Tue, 27 Nov 2001 20:11:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAS0n2K06596 for ietf-calendar-bks; Tue, 27 Nov 2001 16:49:02 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS0n1806592 for ; Tue, 27 Nov 2001 16:49:01 -0800 (PST) To: "Shannon J. Clark" Cc: "John Stracke" , ietf-calendar@imc.org Subject: RE: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_11202001 November 20, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Tue, 27 Nov 2001 19:49:01 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/27/2001 08:04:01 PM, Serialize complete at 11/27/2001 08:04:01 PM Content-Type: multipart/alternative; boundary="=_alternative 00042B9985256B12_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00042B9985256B12_= Content-Type: text/plain; charset="US-ASCII" Shannon wrote on 11/27/2001 04:58:26 PM: > (and perhaps to also define what an "octet" is...) Just reference RFC 760 / STD 5 (Internet Protocol). Its defined in that RFCs glossary (and a 'standard' now). 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 00042B9985256B12_= Content-Type: text/html; charset="US-ASCII"
Shannon wrote on 11/27/2001 04:58:26 PM:
> (and perhaps to also define what an "octet" is...)
Just reference RFC 760 / STD 5 (Internet Protocol).  Its defined in that RFCs glossary (and a 'standard' now).

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 00042B9985256B12_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 28 09:35:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10316 for ; Wed, 28 Nov 2001 09:35:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fASEHtN16347 for ietf-calendar-bks; Wed, 28 Nov 2001 06:17:55 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASEHq816341 for ; Wed, 28 Nov 2001 06:17:53 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA31368; Wed, 28 Nov 2001 09:17:47 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fASEHkH28823; Wed, 28 Nov 2001 09:17:46 -0500 (EST) Message-ID: <3C04F209.7EB6CE09@steltor.com> Date: Wed, 28 Nov 2001 09:17:45 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (ALARMREF?) ALARMID to VALARM after stored? References: <3BFD80A5.4F481F2D@steltor.com> <3BFEB264.634AA9C5@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 This is what we can do: 1) Not allow global VALARMs 2) Replace ALARMID by UID. It will be one less property to define. Furthermore, if in a future version of CAP we will want to have global VALARMs, they will be easier to add. Everyone agree? If not, speak up now! George Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > > The required transformation would be pretty straightforward. > > Really minor compared to the required conversion of CAP calendar > > addresses to mailto URLs. Furthermore, in most cases you should > > probably not send the VALARM to the other attendees. What's the > > point of sending your VALARM to other people? > > Maybe they want it? Maybe it is not a person, but a program > that is doing work for you and the action in the alarm is > a program to run? Maybe the real need for the request is > to synchronize or copy a calendar? I think the point is that > they can send VALARMs, and you can get VALARMs. So John's point > is valid - if we do this - there must be an iTIP transformation > process when sending/getting iTIP messages. > > iTIP does not handle them, so any iTIP messages sent would > have to include them and not reference them. But the same > is true for VCARs and VTIMEZONEs. We can't break RFC2446, so > there MUST BE a transformation. > > > A CUA could easily remind the CU about the impact of changing a > > VALARM referenced by other VALARMs before sending the "modify" > > command to the CAP server. > > > > Personally, I would be more concerned about the consequences of > > modifying a VCAR referenced by other VCARs, or a VTIMEZONE on > > which multiple VEVENTs may depend. > > Time zones do change and thus any good implementation MUST NOT > think they are static. The same is true of a VCAR, they > are not static. And a CUA can change any VALARM already. > > The only real change is do we allow VALARMs outside of a VEVENT > or VTODO? If yes, then we MUST specify rules for modification. > Do we say that if a CUA modifies a VALARM that is common to > more than one VEVENT do we: > > 1) MODIFY the one global and warn the user? > > 2) Replace the VALARM in the component with the global VALARM. > Remove the ALARMREF in the copy. > Then modify the copy in that target component? > > 3) Add a parameter that says 'target components only' or 'all'. > Then apply rule (2). > > 4) Not allow global VALARMs? > > I would lean to (4) in CAP, just to get it out the door. However > if the WG wants global VALARMs - I would not object. > > -Doug From owner-ietf-calendar@mail.imc.org Wed Nov 28 10:05:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12270 for ; Wed, 28 Nov 2001 10:05:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fASEpjV17787 for ietf-calendar-bks; Wed, 28 Nov 2001 06:51:45 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASEph817778 for ; Wed, 28 Nov 2001 06:51:44 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA14356; Wed Nov 28 09:48:34 2001 Subject: RE: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 28 Nov 2001 09:54:18 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/28/2001 09:54:23 AM, Serialize complete at 11/28/2001 09:54:24 AM, Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/28/2001 09:54:24 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Id say this is one time that John and I are in 100% agreement for a change.. . :^) Yeah, but we could probably find a way to disagree about it if we tried. :-) /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Never do card tricks for your poker buddies. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Wed Nov 28 18:57:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26613 for ; Wed, 28 Nov 2001 18:57:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fASNbN623487 for ietf-calendar-bks; Wed, 28 Nov 2001 15:37:23 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASNbL823483 for ; Wed, 28 Nov 2001 15:37:21 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA23954 for ; Wed, 28 Nov 2001 15:37:23 -0800 (PST) Message-ID: <3C05752E.54A5DF87@Royer.com> Date: Wed, 28 Nov 2001 16:37:18 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: iCalendar - "octets" question References: Content-Type: multipart/mixed; boundary="------------B5BBA0DBE9553D92CA46FEF3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B5BBA0DBE9553D92CA46FEF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > It shouldn't; folding and unfolding lines is defined to be irrelevant to > the semantics of the lines, which means that the simplest way to do it is > to do it below the level of the parser/lexer. By the time the lines reach > the parser, they've been unfolded. > > One reason to make sure that splitting characters is explicitly permitted > is that there are legitimate cases in which the code that folds the lines > doesn't actually know it's using multibyte characters. For example, the > iCalendar implementation I did for eCal didn't contain any explicit > character-set code; it was assumed that all the character sets we would > support sending would be supersets of ASCII. The code that did a MIME > wrapper could tag the object as, say, UTF-8, but there was no need for the > code that generated the lines to understand UTF-8; it just used whatever > strings it was given. Wrong: For any character set, if your program knows that character set, simply reading or writing a char in a I18N way will do the correct thing. You can't even wrap a multibyte character because you MUST NOT do OCTET counting, you MUST DO character counting. If you don't know the character set, you have no business creating the object. If someone sends you an object, and you don't understand or can not process the character set listed in the MIME header, you have two choices: (1) Throw it away - because you would have no way to know if it is single byte, double byte, or a variable (multi) byte character set. (2) Try to parse it, if anything looks odd - go to step (1). The only reason to wrap iCalendar object lines is for presentation as it is *not* a must in 2445. If you can't present it because you don't know the charset, don't process it. If you were to accidentally wrap in after the first byte of a two (or more) byte charset, the recipient would NEVER be able to reassemble the object. Don't do OCTET counting. --------------B5BBA0DBE9553D92CA46FEF3 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------B5BBA0DBE9553D92CA46FEF3-- From owner-ietf-calendar@mail.imc.org Wed Nov 28 19:34:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29557 for ; Wed, 28 Nov 2001 19:34:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAT0A5a26109 for ietf-calendar-bks; Wed, 28 Nov 2001 16:10:05 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT0A2826104 for ; Wed, 28 Nov 2001 16:10:02 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA24424 for ; Wed, 28 Nov 2001 16:10:04 -0800 (PST) Message-ID: <3C057CCE.EBAF0A0F@Royer.com> Date: Wed, 28 Nov 2001 17:09:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iCalendar - "octets" question References: Content-Type: multipart/mixed; boundary="------------B09EF113D90A3304E8A27C61" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B09EF113D90A3304E8A27C61 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >Does this mean that in a multi-byte object you SHOULD wrap potentially in > the middle of character? > > Probably MAY, rather than SHOULD. NO! -> MUST NOT <- > >Does this have any potential problems? BIG PROBLEMS! If you were to break apart the sequence 'AB' in this factious multi and variable byte charset: If the (factious) multi byte two octet sequence for the letter 'A' (in hex): 8A 0C And the (factious) 'B' were: 8A 0D And you wrap (8A 0C 8A 0D) in the middle with a CR (OC) and a newline (OD) followed by a space (20), it would look like: 8A 0C 0D 20 0C 8A 0D It would see the stream as: 'A' newline space CR 'B' And NOT: 'A' newline CR space 'B' BUSTED! > One reason to make sure that splitting characters is explicitly permitted > is that there are legitimate cases in which the code that folds the lines > doesn't actually know it's using multibyte characters. ... If you don't know the data format, don't muck with the data. Most, but NOT all charsets are based on US-ASCII. > ...For example, the > iCalendar implementation I did for eCal didn't contain any explicit > character-set code; it was assumed that all the character sets we would > support sending would be supersets of ASCII. ... That will work much of the time for non-asian native charset. But we MUST NOT support that - as there is NO way to predict what the results would be. > ... The code that did a MIME > wrapper could tag the object as, say, UTF-8, but there was no need for the > code that generated the lines to understand UTF-8; it just used whatever > strings it was given. Did you ever test against any 8-bit UTF-8 strings that had variable byte counts? I am guessing - no, or you were very lucky that none of the wraps were in the middle of a variable byte sequence. --------------B09EF113D90A3304E8A27C61 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------B09EF113D90A3304E8A27C61-- From owner-ietf-calendar@mail.imc.org Wed Nov 28 20:02:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01759 for ; Wed, 28 Nov 2001 20:02:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAT0jil27065 for ietf-calendar-bks; Wed, 28 Nov 2001 16:45:44 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT0jh827061 for ; Wed, 28 Nov 2001 16:45:43 -0800 (PST) To: ietf-calendar@imc.org Subject: Salt Lake City meeting MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 28 Nov 2001 19:45:39 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/28/2001 07:45:47 PM, Serialize complete at 11/28/2001 07:45:47 PM Content-Type: multipart/alternative; boundary="=_alternative 00042E4E85256B13_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00042E4E85256B13_= Content-Type: text/plain; charset="us-ascii" FYI - the Calsch group meeting day and time in Salt Lake City is as follows: Wednesday - 1530-1730 APP calsch Calendaring and Scheduling WG Any one interested in dinner on Monday evening of that week should meet in the lobby of the conference hotel at 6:30 pm ( a little earlier in case anyone needs to get back for other sessions). ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 00042E4E85256B13_= Content-Type: text/html; charset="us-ascii"
FYI - the Calsch group meeting day and time in Salt Lake City  is as follows:

Wednesday - 1530-1730 APP     calsch   Calendaring and Scheduling WG

Any one interested in dinner on Monday evening of that week should meet in the lobby of the conference hotel at 6:30 pm ( a little earlier in case anyone needs to get back for other sessions).
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 00042E4E85256B13_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 29 06:26:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22100 for ; Thu, 29 Nov 2001 06:26:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATB5Lp10073 for ietf-calendar-bks; Thu, 29 Nov 2001 03:05:21 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATB5J810063 for ; Thu, 29 Nov 2001 03:05:19 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20223; Thu, 29 Nov 2001 06:05:16 -0500 (EST) Message-Id: <200111291105.GAA20223@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cap-06.txt Date: Thu, 29 Nov 2001 06:05:16 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendar Access Protocol (CAP) Author(s) : S. Mansour, D. Royer, G. Babics, P. Hill Filename : draft-ietf-calsch-cap-06.txt Pages : 108 Date : 28-Nov-01 The Calendar Access Protocol (CAP) is an Internet protocol that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). This memo defines the CAP specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-cap-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cap-06.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: <20011128143415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128143415.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Thu Nov 29 09:59:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06936 for ; Thu, 29 Nov 2001 09:59:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATEfGE25805 for ietf-calendar-bks; Thu, 29 Nov 2001 06:41:16 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATEfE825800 for ; Thu, 29 Nov 2001 06:41:15 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA13285; Thu Nov 29 09:37:35 2001 Subject: Re: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 29 Nov 2001 09:43:22 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/29/2001 09:43:30 AM, Serialize complete at 11/29/2001 09:43:30 AM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >If you don't know the data format, don't muck with the data. >Most, but NOT all charsets are based on US-ASCII. RFC-2445, section 2.3, "International Considerations": "Use of non-US-ASCII-compatible character sets is NOT recommended." That's not quite the same as "not supported", but I'd say that, as poor as 2445's i18n is, it would be foolish to expect a recipient to handle a non-US-ASCII-compatible character set. Now, if we revise 2445 to deal better with character sets, maybe we could expect to enable the use of non-US-ASCII-compatible character sets. It'll be a lot of work, though. Might even be impossible; how many non-ASCII-based character sets are there that contain the Roman alphabet? (Aside from EBCDIC; but banning EBCDIC does not disenfranchize based on nationality. :-) Still...I could see a middle ground on this particular question: senders SHOULD NOT split multibyte characters; recipients SHOULD accept split characters. /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Two words that do not go together: "Memorial Cookbook".| \=======================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 29 11:10:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17128 for ; Thu, 29 Nov 2001 11:10:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATFsdD00755 for ietf-calendar-bks; Thu, 29 Nov 2001 07:54:39 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATFsb800747 for ; Thu, 29 Nov 2001 07:54:38 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_11202001 November 20, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 29 Nov 2001 10:53:03 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/29/2001 10:54:40 AM, Serialize complete at 11/29/2001 10:54:40 AM Content-Type: multipart/alternative; boundary="=_alternative 00570BA285256B13_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00570BA285256B13_= Content-Type: text/plain; charset="US-ASCII" Doug shot back on 11/28/2001 07:09:50 PM: > If you were to break apart the sequence 'AB' in this > factious multi and variable byte charset: > > If the (factious) multi byte two octet sequence for the letter > 'A' (in hex): > > 8A 0C > > And the (factious) 'B' were: > > 8A 0D > > > And you wrap (8A 0C 8A 0D) in the middle with a CR (OC) and a > newline (OD) followed by a space (20), it would look like: > > 8A 0C 0D 20 0C 8A 0D > > It would see the stream as: > > 'A' newline space CR 'B' > > And NOT: > > 'A' newline CR space 'B' > > BUSTED! Not Busted! Thats an incorrect example of folding. From 2445, Section 4.1 Content Lines: That is, a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white space character (i.e., SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence of CRLF followed immediately by a single linear white space character is ignored (i.e., removed) when processing the content type. so properly splitting your factious example it would become: 8A 0D 0A 20 0C 8A 0D which would look like: 'B' LF space FF 'B' _if_ you just took the raw stream at face value. However the un/folding should be handled before parsing (but you CAN do it concurently if you are BIG GLUTTON for punishment). As such, if you actually followed the last line cited above then your code SHOULD be converting: 8A 0D 0A 20 0C 8A 0D (back) to the expected: 8A 0C 8A 0D "when processing the content type". Un/folding should be done before attempting to match character content but Im not going to say someone has to do it; let 'em take the harder path if they really want to. I took that path on my first iCalendar parser and quickly realized the error of my ways... Shannon: Add an issue to the iCalendar list to change the use of "two characters" in the 1st sentence above since we only care about octets as initially noted in the 1st line of the paragraph cited above: Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. 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 00570BA285256B13_= Content-Type: text/html; charset="US-ASCII"
Doug shot back on 11/28/2001 07:09:50 PM:
>    If you were to break apart the sequence 'AB' in this
>    factious multi and variable byte charset:
>
>    If the (factious) multi byte two octet sequence for the letter
>    'A' (in hex):
>
>       8A 0C
>
>    And the (factious) 'B' were:
>
>       8A 0D
>
>    
>    And you wrap (8A 0C 8A 0D) in the middle with a CR (OC) and a
>    newline (OD) followed by a space (20), it would look like:
>
>       8A 0C 0D 20 0C 8A 0D
>
>    It would see the stream as:
>
>       'A' newline space CR 'B'
>
>    And NOT:
>
>       'A' newline CR space 'B'
>
> BUSTED!
Not Busted!  Thats an incorrect example of folding.  From 2445, Section 4.1 Content Lines:

                                                     That is, a long
  line can be split between any two characters by inserting a CRLF
  immediately followed by a single linear white space character (i.e.,
  SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
  of CRLF followed immediately by a single linear white space character
  is ignored (i.e., removed) when processing the content type.

so properly splitting your factious example it would become:

        8A 0D 0A 20 0C 8A 0D

which would look like:

        'B' LF space FF 'B'

_if_ you just took the raw stream at face value.  However the un/folding should be handled before parsing (but you CAN do it concurently if you are BIG GLUTTON for punishment).  As such, if you actually followed the last line cited above then your code SHOULD be converting:

        8A 0D 0A 20 0C 8A 0D

(back) to the expected:

        8A 0C 8A 0D

"when processing the content type".  Un/folding should be done before attempting to match character content but Im not going to say someone has to do it; let 'em take the harder path if they really want to.  I took that path on my first iCalendar parser and quickly realized the error of my ways...  

Shannon:  Add an issue to the iCalendar list to change the use of "two characters" in the 1st sentence above since we only care about octets as initially noted in the 1st line of the paragraph cited above:

   Lines of text SHOULD NOT be longer than 75 octets, excluding the line
  break.

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 00570BA285256B13_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 29 13:50:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01552 for ; Thu, 29 Nov 2001 13:50:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATIVL014253 for ietf-calendar-bks; Thu, 29 Nov 2001 10:31:21 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATIVK814249 for ; Thu, 29 Nov 2001 10:31:20 -0800 (PST) To: ietf-calendar@imc.org Subject: Internationalization issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 29 Nov 2001 13:31:16 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/29/2001 01:31:22 PM, Serialize complete at 11/29/2001 01:31:22 PM Content-Type: multipart/alternative; boundary="=_alternative 0065BDB285256B13_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065BDB285256B13_= Content-Type: text/plain; charset="us-ascii" The IETF has asked all working groups to look at their documents in motion or in place to validate that Internationalization issues are "handled" - in particular, Unicode. Many of us feel that iCalendar by it's very nature is covered. The same is probably true for iMIP and iTIP. I'm not sure if this is the case for CAP. However, I'd like to start a dialog here so that if anyone feels we have areas that may not satisfy Internationalization requirements, speak up now. Also, if someone can summarize any other items pertaining to the internationalization issue, I'd appreciate it. --=_alternative 0065BDB285256B13_= Content-Type: text/html; charset="us-ascii"
The IETF has asked all working groups to look at their documents in motion or in place to validate that Internationalization issues are "handled" - in particular, Unicode.  Many of us feel that iCalendar by it's very nature is covered.  The same is probably true for iMIP and iTIP.  I'm not sure if this is the case for CAP.

However, I'd like to start a dialog here so that if anyone feels we have areas that may not satisfy Internationalization requirements, speak up now.  Also, if someone can summarize any other items pertaining to the internationalization issue, I'd appreciate it. --=_alternative 0065BDB285256B13_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 29 14:37:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05399 for ; Thu, 29 Nov 2001 14:37:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATJGDx15862 for ietf-calendar-bks; Thu, 29 Nov 2001 11:16:13 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATJGB815858 for ; Thu, 29 Nov 2001 11:16:11 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id NAA21770 for ; Thu, 29 Nov 2001 13:12:27 -0600 From: "Shannon J. Clark" To: Subject: Summary of Editors Call - Thursday Nov 29th Date: Thu, 29 Nov 2001 13:16:28 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, In an editors call this afternoon the following topics were discussed: - CAP - Changes to the new draft that went out, in particular the MODIFY section was highlighted as one that requires the attention of the full group, George Babics will be mailing the relevant sections to the list. Also discussed was SCHEDULE vs. CREATE with the thought that SCHEDULE may be redundant? - The upcoming IETF meeting in Salt Lake City (Dec 9th-14th 2001, see www.ietf.org) Wednesday 3:30pm CALSCH meeting, Monday night dinner are planned - Octet vs Character and Folding/unfolding - discussed where when these actions need to occur, whether the line mentioning "at a character" is an oversight or intentional. It was suggested that an explanatory paragraph be added to highlight the suggested order of handling this something like - please refine my rough word ... "Unfolding SHOULD (perhaps MUST?) occur AFTER the charset has been recognized and dealt with. Unfolding of an object in an unknown charset can have unforeseen consequences." - I18N issues - it was suggested that an RFC and/or Workshop papers been located to be cited as references on I18N issues for protocol and application developers Shannon Shannon J. Clark President - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Thu Nov 29 15:23:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08801 for ; Thu, 29 Nov 2001 15:23:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATK9eh17787 for ietf-calendar-bks; Thu, 29 Nov 2001 12:09:40 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATK9d817782 for ; Thu, 29 Nov 2001 12:09:39 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id PAA20719; Thu Nov 29 15:06:02 2001 Subject: Re: Summary of Editors Call - Thursday Nov 29th MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 29 Nov 2001 15:11:47 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/29/2001 03:11:58 PM, Serialize complete at 11/29/2001 03:11:58 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > "Unfolding SHOULD (perhaps MUST?) occur AFTER the charset has been >recognized and dealt with. Unfolding of an object in an unknown charset can >have unforeseen consequences." Yes, this has been proposed on the list, too, and we don't seem to have consensus. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |============================================================| |Just because we are out to get you does not mean you are not| |paranoid. | \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 30 15:30:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04662 for ; Fri, 30 Nov 2001 15:30:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAUKG6E18990 for ietf-calendar-bks; Fri, 30 Nov 2001 12:16:06 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUKG5818983 for ; Fri, 30 Nov 2001 12:16:05 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA00299 for ; Fri, 30 Nov 2001 12:16:05 -0800 (PST) Message-ID: <3C07E901.825F7BA4@Royer.com> Date: Fri, 30 Nov 2001 13:16:01 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iCalendar - "octets" question References: Content-Type: multipart/mixed; boundary="------------822DB0636B94030CDA3CFD21" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------822DB0636B94030CDA3CFD21 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >If you don't know the data format, don't muck with the data. > >Most, but NOT all charsets are based on US-ASCII. > > RFC-2445, section 2.3, "International Considerations": "Use of non-US-ASCII-compatible character sets is NOT recommended." But not dis-allowed. > That's not quite the same as "not supported", but I'd say that, as poor as > 2445's i18n is, it would be foolish to expect a recipient to handle a > non-US-ASCII-compatible character set. No - if you can charset convert - it works. > Now, if we revise 2445 to deal better with character sets, maybe we could > expect to enable the use of non-US-ASCII-compatible character sets. It'll > be a lot of work, though. Might even be impossible; how many > non-ASCII-based character sets are there that contain the Roman alphabet? > (Aside from EBCDIC; but banning EBCDIC does not disenfranchize based on > nationality. :-) Irrelevant - break 'between' characters as RFC2445 says - and it will work in any charset. > Still...I could see a middle ground on this particular question: senders > SHOULD NOT split multibyte characters; recipients SHOULD accept split > characters. If you don't know the charset, you can't always tell how to put it back together. I see no change needed to 2445, it says split between characters. Perhaps some additional text to explain that does not mean splitting in the middle of characters. --------------822DB0636B94030CDA3CFD21 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------822DB0636B94030CDA3CFD21-- From owner-ietf-calendar@mail.imc.org Fri Nov 30 16:35:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08515 for ; Fri, 30 Nov 2001 16:35:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAULLaH23354 for ietf-calendar-bks; Fri, 30 Nov 2001 13:21:36 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAULLZ823350 for ; Fri, 30 Nov 2001 13:21:35 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id QAA01669; Fri Nov 30 16:17:56 2001 Subject: Re: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 30 Nov 2001 16:23:43 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 11/30/2001 04:23:58 PM, Serialize complete at 11/30/2001 04:23:58 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >If you don't know the charset, you can't always tell how to put it >back together. You're right. The problem I didn't see before is that, in a 2-byte character set, you might have the characters 0D0A 2041, which, to something built for ASCII, would look like CR LF SP A; the CR LF SP would then get dropped. I think this complicates the story for senders; they need to split lines at the 75-octet mark, but the code that splits the lines only sees characters, not octets. You said that splitting lines was only for presentation (does anybody disagree?); if so, we can change "75 octets" to "75 characters". Make sense? /=========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=========================================================| |NT's lack of reliability is only surpassed by its lack of| |scalability. --John Kirch | \=========================================================/