[Ietf-calsify] Re: Chair review of draft-ietf-calsify-rfc2445bis
Bernard Desruisseaux <bernard.desruisseaux@oracle.com> Fri, 01 February 2008 04:30 UTC
Return-Path: <ietf-calsify-bounces@osafoundation.org>
X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A3B28C0D7 for <ietfarch-calsify-archive-Feit0ahl@core3.amsl.com>; Thu, 31 Jan 2008 20:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rds1TybknzCh for <ietfarch-calsify-archive-Feit0ahl@core3.amsl.com>; Thu, 31 Jan 2008 20:30:52 -0800 (PST)
Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by core3.amsl.com (Postfix) with ESMTP id E197228C101 for <calsify-archive-Feit0ahl@lists.ietf.org>; Thu, 31 Jan 2008 20:30:52 -0800 (PST)
Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 8644E7FED3; Thu, 31 Jan 2008 20:31:56 -0800 (PST)
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 899167FE2D for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 20:31:55 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7AB79142207 for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 20:31:58 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q0Oe5TzWClE for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 20:31:51 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F18C1421FD for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 20:31:51 -0800 (PST)
Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m114VfuB032579; Thu, 31 Jan 2008 22:31:41 -0600
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m0VIVeN1024626; Thu, 31 Jan 2008 21:31:40 -0700
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-209.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3550199441201840187; Thu, 31 Jan 2008 20:29:47 -0800
Message-ID: <47A2A03A.5000805@oracle.com>
Date: Thu, 31 Jan 2008 23:29:46 -0500
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Aki Niemi <aki.niemi@nokia.com>
References: <1198075717.13738.82.camel@scotty>
In-Reply-To: <1198075717.13738.82.camel@scotty>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: ietf-calsify <ietf-calsify@osafoundation.org>
Subject: [Ietf-calsify] Re: Chair review of draft-ietf-calsify-rfc2445bis
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
Sender: ietf-calsify-bounces@osafoundation.org
Errors-To: ietf-calsify-bounces@osafoundation.org
Hi Aki,
Aki Niemi wrote:
> All,
>
> I've now reviewed RFC2445-bis, and am currently working on the PROTO
> writeup, which is a document that accompanies the draft as we request
> publication.
>
> I'll also send some typos and such to Bernard privately.
>
> Cheers,
> Aki
>
>
> Technical:
> ==========
>
> * Sec 3.2.3: an implementation should treat an unrecognized CUTYPE value
> as UNKNOWN as opposed to INDIVIDUAL:
>
> OLD:
>
> Applications MUST treat x-name and iana-token value they don't
> recognized the same way as the INDIVIDUAL value.
>
> NEW:
>
> Applications MUST treat x-name and iana-token value they don't
> recognized the same way as the UNKNOWN value.
Done.
>
> * Section 3.2.19: treating unknown VALUE data types. Rather than
> treating unrecognized values as TEXT, I think the draft should instruct
> implementations to ignore them:
>
> OLD:
>
> Applications MUST treat x-name and iana-token value they don't
> recognized the same way as the TEXT value.
>
> NEW:
>
> Applications MUST ignore x-name and iana-token values that they
> don't recognize.
Changed with the text provided by Cyrus, that is:
Applications MUST preserve the value data for x-name and iana-token
values that they don't recognize without attempting to interpret or
parse the value data.
>
> * Sec 3.2.4/3.2.5: the DELEGATED-TO and DELEGATED-FROM parameters say
> that the cal-address MUST be a mailto URI. However, the actual
> definition of cal-address is more liberal; it says MUST be a mailto URI
> but only when email is used as transport.
>
> Assuming DELEGATED-* can be used with any transport, either their
> definition needs to add the same transport disclaimer, or the MUST needs
> to be removed altogether (and rely only on cal-address definition here)
This issue was discussed during IETF-65.
Slide 7:
http://www.ietf.org/proceedings/06mar/slides/calsify-1/sld7.htm
Minutes [From 03:08:46 to 03:15:38]:
http://tools.ietf.org/wg/calsify/minutes?item=minutes65.html
Back then the idea was to remove these restrictions on mailto URI
and to specify a set of URI types that should be allowed. Given
that we never got around to define this set, I will simply remove
the MUST specified for DELEGATED-TO and DELEGATED-FROM and rely
only on cal-address definition.
>
> * Sec 3.6.6: alarm component. I think it is useful to add a short note
> about dealing with alarm components from untrusted sources. I think
> there used to be some "handwaiving" about that in the security
> considerations, but I think it got removed. Suggest something like:
>
> OLD:
>
> The "ACTION" property is used within the "VALARM" calendar
> component to specify the type of action invoked when the alarm
> is triggered. The "VALARM" properties provide enough information
> for a specific action to be invoked. It is typically the
> responsibility of a "Calendar User Agent" (CUA) to deliver the
> alarm in the specified fashion. An "ACTION" property value of
> AUDIO specifies an alarm that causes a sound to be played to
> alert the user; DISPLAY specifies an alarm that causes a text
> message to be displayed to the user; and EMAIL specifies an
> alarm that causes an electronic email message to be delivered to
> one or more email addresses.
>
> NEW:
>
> The "ACTION" property is used within the "VALARM" calendar
> component to specify the type of action invoked when the alarm
> is triggered. The "VALARM" properties provide enough information
> for a specific action to be invoked. It is typically the
> responsibility of a "Calendar User Agent" (CUA) to deliver the
> alarm in the specified fashion. An "ACTION" property value of
> AUDIO specifies an alarm that causes a sound to be played to
> alert the user; DISPLAY specifies an alarm that causes a text
> message to be displayed to the user; and EMAIL specifies an
> alarm that causes an electronic email message to be delivered to
> one or more email addresses.
>
> Note: implementations should carefully consider whether
> they accept alarm components from untrusted sources,
> e.g., when importing calendar objects from external
> sources. One reasonable policy is to always ignore alarm
> components that the calendar user has not set herself,
> or at least ask for confirmation in such a case.
Done. I added the note at the very end of the "Description:" part
of VALARM.
>
> * Section 8.1, 2nd sentence: what does this mean? Suggest removing it.
>
>> However, the implementation of the memo is in no way limited solely as
>> a MIME content type.
Done.
>
>
> Structure:
> ==========
>
> * Sec 3: it would help readability a lot to explain in the introduction
> some basics of iCalendar, and how exactly the section that follows is
> structured. Currently, it's easy to miss the bigger picture, as the
> section jumps directly into content lines formatting, and the data types
> used in properties, without a clear picture as to where and how they
> will be used.
>
> My proposal is to add the following passage to the top of Section 3:
>
> OLD:
>
> The following sections define the details of a Calendaring and
> Scheduling Core Object Specification. This information is
> intended to be an integral part of the MIME content type
> registration. In addition, this information can be used
> independent of such content registration. In particular, this
> memo has direct applicability for use as a calendaring and
> scheduling exchange format in file-, memory- or network-based
> transport mechanisms.
>
> NEW:
>
> The following sections define the details of a Calendaring and
> Scheduling Core Object Specification. The Calendaring and
> Scheduling Core Object is a collection of calendaring and
> scheduling information. Typically, this information will consist
> of an iCalendar stream with one or more iCalendar objects. The
> body of the iCalendar object consists of a sequence of calendar
> properties and one or more calendar components.
>
> Section 3.1. defines the content line format; Section 3.2.
> defines the property parameter format; Section 3.3. defines the
> data types for property values; Section 3.4. defines the
> iCalendar object format; Section 3.5. defines the iCalendar
> property format; Section 3.6. defines the calendar component
> format; Section 3.7. defines calendar properties; and Sectiopn
> 3.8. defines calendar component properties.
>
> This information is intended to be an integral part of the MIME
> content type registration. In addition, this information can be
> used independent of such content registration. In particular,
> this memo has direct applicability for use as a calendaring and
> scheduling exchange format in file-, memory- or network-based
> transport mechanisms.
Done.
>
> * Sec 3.3.1:
>
>> No additional content value encoding (i.e., BACKSLASH character
>> encoding) is defined for this value type.
>
> This is the first time BACKSLASH character encoding is mentioned. What
> is it? Suggest adding a forward reference to Sec 3.3.11., where it is
> defined.
Done.
>
> Nits:
> =====
>
> * Section 2, first sentence: RFC2119 doesn't have a "NOT RECOMMENDED"
> key word. (Caught by I-D nits tool)
Check Errata ID 499.
http://www.rfc-editor.org/errata.php
The idnits tool should be fixed to allow this.
Thanks,
Bernard
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
From ietf-calsify-bounces@osafoundation.org Thu Jan 31 20:59:14 2008
Return-Path: <ietf-calsify-bounces@osafoundation.org>
X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 14D5728C146
for <ietfarch-calsify-archive-Feit0ahl@core3.amsl.com>; Thu, 31 Jan 2008 20:59:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NJg64La1Spzd
for <ietfarch-calsify-archive-Feit0ahl@core3.amsl.com>;
Thu, 31 Jan 2008 20:59:13 -0800 (PST)
Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93])
by core3.amsl.com (Postfix) with ESMTP id 39A5F28C178
for <calsify-archive-Feit0ahl@lists.ietf.org>; Thu, 31 Jan 2008 20:59:13 -0800 (PST)
Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1])
by leilani.osafoundation.org (Postfix) with ESMTP id 751A3804CA;
Thu, 31 Jan 2008 21:00:16 -0800 (PST)
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org
[204.152.186.98])
by leilani.osafoundation.org (Postfix) with ESMTP id CACD77FE2D
for <ietf-calsify@osafoundation.org>;
Thu, 31 Jan 2008 21:00:15 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
by laweleka.osafoundation.org (Postfix) with ESMTP id BB4D4142207
for <ietf-calsify@osafoundation.org>;
Thu, 31 Jan 2008 21:00:18 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id 9e-VqCMM46Ez for <ietf-calsify@osafoundation.org>;
Thu, 31 Jan 2008 21:00:12 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by laweleka.osafoundation.org (Postfix) with ESMTP id 7FC711421FD
for <ietf-calsify@osafoundation.org>;
Thu, 31 Jan 2008 21:00:12 -0800 (PST)
Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111])
by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id
m11506D4018497; Thu, 31 Jan 2008 23:00:06 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151])
by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id
m115033I027843; Thu, 31 Jan 2008 22:00:03 -0700
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-209.vpn.oracle.com by
acsmt350.oracle.com
with ESMTP id 3550705161201841944; Thu, 31 Jan 2008 20:59:04 -0800
Message-ID: <47A2A717.4060607@oracle.com>
Date: Thu, 31 Jan 2008 23:59:03 -0500
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Mike Douglass <douglm@rpi.edu>
Subject: Re: [Ietf-calsify] dtstamp twice
References: <47A08EF3.3070500@rpi.edu>
In-Reply-To: <47A08EF3.3070500@rpi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: Calsify <ietf-calsify@osafoundation.org>
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,
<mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,
<mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
Sender: ietf-calsify-bounces@osafoundation.org
Errors-To: ietf-calsify-bounces@osafoundation.org
Fixed.
Thanks,
Bernard
Mike Douglass wrote:
> Maybe corrected but draft 7 has dtstamp and uid both required and
> optional for freebusy
>
> ; the following are REQUIRED,
> ; but MUST NOT occur more than once
>
> dtstamp / uid /
>
> ; the following are OPTIONAL,
> ; but MUST NOT occur more than once
>
> contact / dtstart / dtend / duration / dtstamp /
> organizer / uid / url /
>
>
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
From ietf-calsify-bounces@osafoundation.org Thu Jan 31 21:15:23 2008
Return-Path: <ietf-calsify-bounces@osafoundation.org>
X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8103728C1C0
for <ietfarch-calsify-archive-Feit0ahl@core3.amsl.com>; Thu, 31 Jan 2008 21:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5
tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_44=0.6,
J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id KBly4XeH0A0b
for <ietfarch-calsify-archive-Feit0ahl@core3.amsl.com>;
Thu, 31 Jan 2008 21:15:22 -0800 (PST)
Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93])
by core3.amsl.com (Postfix) with ESMTP id C6DA628C1B5
for <calsify-archive-Feit0ahl@lists.ietf.org>; Thu, 31 Jan 2008 21:15:22 -0800 (PST)
Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1])
by leilani.osafoundation.org (Postfix) with ESMTP id 747C280103;
Thu, 31 Jan 2008 21:16:26 -0800 (PST)
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org
[204.152.186.98])
by leilani.osafoundation.org (Postfix) with ESMTP id E69247FEF1
for <ietf-calsify@osafoundation.org>;
Thu, 31 Jan 2008 21:16:24 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
by laweleka.osafoundation.org (Postfix) with ESMTP id D84AC142203
for <ietf-calsify@osafoundation.org>;
Thu, 31 Jan 2008 21:16:27 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1])
by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id lN5zrA30yvlX for <ietf-calsify@osafoundation.org>;
Thu, 31 Jan 2008 21:16:21 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by laweleka.osafoundation.org (Postfix) with ESMTP id 98BD71421FD
for <ietf-calsify@osafoundation.org>;
Thu, 31 Jan 2008 21:16:21 -0800 (PST)
Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212])
by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id
m115GGOt004380; Thu, 31 Jan 2008 23:16:16 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151])
by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id
m0VAeisM006406; Thu, 31 Jan 2008 22:16:15 -0700
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-209.vpn.oracle.com by
acsmt350.oracle.com
with ESMTP id 3550211601201842919; Thu, 31 Jan 2008 21:15:19 -0800
Message-ID: <47A2AAE6.2080807@oracle.com>
Date: Fri, 01 Feb 2008 00:15:18 -0500
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: John W Noerenberg II <jwn2@qualcomm.com>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
References: <20080119215144.96514142254@laweleka.osafoundation.org>
<p06300008c3bae792120d@[129.46.77.134]>
In-Reply-To: <p06300008c3bae792120d@[129.46.77.134]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,
<mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,
<mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
Sender: ietf-calsify-bounces@osafoundation.org
Errors-To: ietf-calsify-bounces@osafoundation.org
Hi John,
John W Noerenberg II wrote:
>> At 2:08 PM -0800 1/21/08, John W Noerenberg II wrote:
>>> IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a subsequent
>>> UPDATE, then the REPLY should probably not be accepted. Do others
>>> agree and should we clarify this?
>
> Forgive me if I'm dragging out a dead horse...
>
> Why do we have both PARTSTAT and RSVP parameters? Is there ever a
> condition in a REQUEST that a CUA would set PARTSTAT=NEEDS-ACTION and
> not set RSVP=TRUE?
Here's one:
The "Organizer" of a VTODO is requesting an updated status from an
"Attendee" that currently has PARTSTAT=IN-PROCESS. The "Attendee" will
either reply with PARTSTAT=COMPLETED, or with PARTSTAT=IN-PROCESS with
perhaps a greater PERCENT-COMPLETE value.
Cheers,
Bernard
> Is there ever a condition where a CUA would omit
> PARTSTAT=NEEDS-ACTION and could not include an RSVP=FALSE?
>
> If it were up to me, I'd get rid of RSVP. I know the RSVP parameter is
> used. In 2445bis and 2446bis, I'd say the RSVP parameter and it's value
> have no semantic meaning. It's presence in an ATTENDEE property is not
> an error, but it's use is discouraged.
>
> This is just my way of striking a blow for brevity in VEVENTs. ;-)
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Return-Path: <bernard.desruisseaux@oracle.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E69247FEF1 for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 21:16:24 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D84AC142203 for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 21:16:27 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.361
X-Spam-Level:
X-Spam-Status: No, score=-2.361 tagged_above=-50 required=4 tests=[AWL=0.237, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, UPPERCASE_25_50=0]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN5zrA30yvlX for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 21:16:21 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 98BD71421FD for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 21:16:21 -0800 (PST)
Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m115GGOt004380; Thu, 31 Jan 2008 23:16:16 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m0VAeisM006406; Thu, 31 Jan 2008 22:16:15 -0700
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-209.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3550211601201842919; Thu, 31 Jan 2008 21:15:19 -0800
Message-ID: <47A2AAE6.2080807@oracle.com>
Date: Fri, 01 Feb 2008 00:15:18 -0500
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: John W Noerenberg II <jwn2@qualcomm.com>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
References: <20080119215144.96514142254@laweleka.osafoundation.org> <p06300008c3bae792120d@[129.46.77.134]>
In-Reply-To: <p06300008c3bae792120d@[129.46.77.134]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Feb 2008 05:16:25 -0000
Hi John,
John W Noerenberg II wrote:
>> At 2:08 PM -0800 1/21/08, John W Noerenberg II wrote:
>>> IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a subsequent
>>> UPDATE, then the REPLY should probably not be accepted. Do others
>>> agree and should we clarify this?
>
> Forgive me if I'm dragging out a dead horse...
>
> Why do we have both PARTSTAT and RSVP parameters? Is there ever a
> condition in a REQUEST that a CUA would set PARTSTAT=NEEDS-ACTION and
> not set RSVP=TRUE?
Here's one:
The "Organizer" of a VTODO is requesting an updated status from an
"Attendee" that currently has PARTSTAT=IN-PROCESS. The "Attendee" will
either reply with PARTSTAT=COMPLETED, or with PARTSTAT=IN-PROCESS with
perhaps a greater PERCENT-COMPLETE value.
Cheers,
Bernard
> Is there ever a condition where a CUA would omit
> PARTSTAT=NEEDS-ACTION and could not include an RSVP=FALSE?
>
> If it were up to me, I'd get rid of RSVP. I know the RSVP parameter is
> used. In 2445bis and 2446bis, I'd say the RSVP parameter and it's value
> have no semantic meaning. It's presence in an ATTENDEE property is not
> an error, but it's use is discouraged.
>
> This is just my way of striking a blow for brevity in VEVENTs. ;-)
Return-Path: <bernard.desruisseaux@oracle.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CACD77FE2D for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 21:00:15 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BB4D4142207 for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 21:00:18 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.359
X-Spam-Level:
X-Spam-Status: No, score=-2.359 tagged_above=-50 required=4 tests=[AWL=0.239, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e-VqCMM46Ez for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 21:00:12 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7FC711421FD for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 21:00:12 -0800 (PST)
Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m11506D4018497; Thu, 31 Jan 2008 23:00:06 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m115033I027843; Thu, 31 Jan 2008 22:00:03 -0700
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-209.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3550705161201841944; Thu, 31 Jan 2008 20:59:04 -0800
Message-ID: <47A2A717.4060607@oracle.com>
Date: Thu, 31 Jan 2008 23:59:03 -0500
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Mike Douglass <douglm@rpi.edu>
Subject: Re: [Ietf-calsify] dtstamp twice
References: <47A08EF3.3070500@rpi.edu>
In-Reply-To: <47A08EF3.3070500@rpi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: Calsify <ietf-calsify@osafoundation.org>
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Feb 2008 05:00:15 -0000
Fixed.
Thanks,
Bernard
Mike Douglass wrote:
> Maybe corrected but draft 7 has dtstamp and uid both required and
> optional for freebusy
>
> ; the following are REQUIRED,
> ; but MUST NOT occur more than once
>
> dtstamp / uid /
>
> ; the following are OPTIONAL,
> ; but MUST NOT occur more than once
>
> contact / dtstart / dtend / duration / dtstamp /
> organizer / uid / url /
>
>
Return-Path: <bernard.desruisseaux@oracle.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 899167FE2D for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 20:31:55 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7AB79142207 for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 20:31:58 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.357
X-Spam-Level:
X-Spam-Status: No, score=-2.357 tagged_above=-50 required=4 tests=[AWL=0.241, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q0Oe5TzWClE for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 20:31:51 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F18C1421FD for <ietf-calsify@osafoundation.org>; Thu, 31 Jan 2008 20:31:51 -0800 (PST)
Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m114VfuB032579; Thu, 31 Jan 2008 22:31:41 -0600
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m0VIVeN1024626; Thu, 31 Jan 2008 21:31:40 -0700
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-209.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3550199441201840187; Thu, 31 Jan 2008 20:29:47 -0800
Message-ID: <47A2A03A.5000805@oracle.com>
Date: Thu, 31 Jan 2008 23:29:46 -0500
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Aki Niemi <aki.niemi@nokia.com>
References: <1198075717.13738.82.camel@scotty>
In-Reply-To: <1198075717.13738.82.camel@scotty>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: ietf-calsify <ietf-calsify@osafoundation.org>
Subject: [Ietf-calsify] Re: Chair review of draft-ietf-calsify-rfc2445bis
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Feb 2008 04:31:55 -0000
Hi Aki,
Aki Niemi wrote:
> All,
>
> I've now reviewed RFC2445-bis, and am currently working on the PROTO
> writeup, which is a document that accompanies the draft as we request
> publication.
>
> I'll also send some typos and such to Bernard privately.
>
> Cheers,
> Aki
>
>
> Technical:
> ==========
>
> * Sec 3.2.3: an implementation should treat an unrecognized CUTYPE value
> as UNKNOWN as opposed to INDIVIDUAL:
>
> OLD:
>
> Applications MUST treat x-name and iana-token value they don't
> recognized the same way as the INDIVIDUAL value.
>
> NEW:
>
> Applications MUST treat x-name and iana-token value they don't
> recognized the same way as the UNKNOWN value.
Done.
>
> * Section 3.2.19: treating unknown VALUE data types. Rather than
> treating unrecognized values as TEXT, I think the draft should instruct
> implementations to ignore them:
>
> OLD:
>
> Applications MUST treat x-name and iana-token value they don't
> recognized the same way as the TEXT value.
>
> NEW:
>
> Applications MUST ignore x-name and iana-token values that they
> don't recognize.
Changed with the text provided by Cyrus, that is:
Applications MUST preserve the value data for x-name and iana-token
values that they don't recognize without attempting to interpret or
parse the value data.
>
> * Sec 3.2.4/3.2.5: the DELEGATED-TO and DELEGATED-FROM parameters say
> that the cal-address MUST be a mailto URI. However, the actual
> definition of cal-address is more liberal; it says MUST be a mailto URI
> but only when email is used as transport.
>
> Assuming DELEGATED-* can be used with any transport, either their
> definition needs to add the same transport disclaimer, or the MUST needs
> to be removed altogether (and rely only on cal-address definition here)
This issue was discussed during IETF-65.
Slide 7:
http://www.ietf.org/proceedings/06mar/slides/calsify-1/sld7.htm
Minutes [From 03:08:46 to 03:15:38]:
http://tools.ietf.org/wg/calsify/minutes?item=minutes65.html
Back then the idea was to remove these restrictions on mailto URI
and to specify a set of URI types that should be allowed. Given
that we never got around to define this set, I will simply remove
the MUST specified for DELEGATED-TO and DELEGATED-FROM and rely
only on cal-address definition.
>
> * Sec 3.6.6: alarm component. I think it is useful to add a short note
> about dealing with alarm components from untrusted sources. I think
> there used to be some "handwaiving" about that in the security
> considerations, but I think it got removed. Suggest something like:
>
> OLD:
>
> The "ACTION" property is used within the "VALARM" calendar
> component to specify the type of action invoked when the alarm
> is triggered. The "VALARM" properties provide enough information
> for a specific action to be invoked. It is typically the
> responsibility of a "Calendar User Agent" (CUA) to deliver the
> alarm in the specified fashion. An "ACTION" property value of
> AUDIO specifies an alarm that causes a sound to be played to
> alert the user; DISPLAY specifies an alarm that causes a text
> message to be displayed to the user; and EMAIL specifies an
> alarm that causes an electronic email message to be delivered to
> one or more email addresses.
>
> NEW:
>
> The "ACTION" property is used within the "VALARM" calendar
> component to specify the type of action invoked when the alarm
> is triggered. The "VALARM" properties provide enough information
> for a specific action to be invoked. It is typically the
> responsibility of a "Calendar User Agent" (CUA) to deliver the
> alarm in the specified fashion. An "ACTION" property value of
> AUDIO specifies an alarm that causes a sound to be played to
> alert the user; DISPLAY specifies an alarm that causes a text
> message to be displayed to the user; and EMAIL specifies an
> alarm that causes an electronic email message to be delivered to
> one or more email addresses.
>
> Note: implementations should carefully consider whether
> they accept alarm components from untrusted sources,
> e.g., when importing calendar objects from external
> sources. One reasonable policy is to always ignore alarm
> components that the calendar user has not set herself,
> or at least ask for confirmation in such a case.
Done. I added the note at the very end of the "Description:" part
of VALARM.
>
> * Section 8.1, 2nd sentence: what does this mean? Suggest removing it.
>
>> However, the implementation of the memo is in no way limited solely as
>> a MIME content type.
Done.
>
>
> Structure:
> ==========
>
> * Sec 3: it would help readability a lot to explain in the introduction
> some basics of iCalendar, and how exactly the section that follows is
> structured. Currently, it's easy to miss the bigger picture, as the
> section jumps directly into content lines formatting, and the data types
> used in properties, without a clear picture as to where and how they
> will be used.
>
> My proposal is to add the following passage to the top of Section 3:
>
> OLD:
>
> The following sections define the details of a Calendaring and
> Scheduling Core Object Specification. This information is
> intended to be an integral part of the MIME content type
> registration. In addition, this information can be used
> independent of such content registration. In particular, this
> memo has direct applicability for use as a calendaring and
> scheduling exchange format in file-, memory- or network-based
> transport mechanisms.
>
> NEW:
>
> The following sections define the details of a Calendaring and
> Scheduling Core Object Specification. The Calendaring and
> Scheduling Core Object is a collection of calendaring and
> scheduling information. Typically, this information will consist
> of an iCalendar stream with one or more iCalendar objects. The
> body of the iCalendar object consists of a sequence of calendar
> properties and one or more calendar components.
>
> Section 3.1. defines the content line format; Section 3.2.
> defines the property parameter format; Section 3.3. defines the
> data types for property values; Section 3.4. defines the
> iCalendar object format; Section 3.5. defines the iCalendar
> property format; Section 3.6. defines the calendar component
> format; Section 3.7. defines calendar properties; and Sectiopn
> 3.8. defines calendar component properties.
>
> This information is intended to be an integral part of the MIME
> content type registration. In addition, this information can be
> used independent of such content registration. In particular,
> this memo has direct applicability for use as a calendaring and
> scheduling exchange format in file-, memory- or network-based
> transport mechanisms.
Done.
>
> * Sec 3.3.1:
>
>> No additional content value encoding (i.e., BACKSLASH character
>> encoding) is defined for this value type.
>
> This is the first time BACKSLASH character encoding is mentioned. What
> is it? Suggest adding a forward reference to Sec 3.3.11., where it is
> defined.
Done.
>
> Nits:
> =====
>
> * Section 2, first sentence: RFC2119 doesn't have a "NOT RECOMMENDED"
> key word. (Caught by I-D nits tool)
Check Errata ID 499.
http://www.rfc-editor.org/errata.php
The idnits tool should be fixed to allow this.
Thanks,
Bernard
Return-Path: <timhare@comcast.net>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3847D8012F for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 08:24:09 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2218C1421FD for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 08:24:12 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 1.297
X-Spam-Level: *
X-Spam-Status: No, score=1.297 tagged_above=-50 required=4 tests=[AWL=-1.198, BAYES_20=-0.74, DNS_FROM_RFC_POST=1.708, HTML_50_60=0.134, HTML_MESSAGE=0.001, MSGID_FROM_MTA_ID=1.393, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaYq8TsMdmzY for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 08:24:05 -0800 (PST)
Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0CAF91422A0 for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 08:23:49 -0800 (PST)
Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id jPpy1Y00B0EPcho0A0il00; Wed, 30 Jan 2008 16:23:46 +0000
Received: from THare ([71.203.100.120]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id jUPe1Y0042brFRz8M00000; Wed, 30 Jan 2008 16:23:45 +0000
X-Authority-Analysis: v=1.0 c=1 a=aBRke-9JdhYA:10 a=14gpSlnFNGW5h3C02z4A:9 a=Vo0qDQP4xzpJD2dXB2jH4G9d__0A:4 a=gi0PWCVxevcA:10 a=7fDqCWwGyM60EotUREoA:9 a=6hQfJFcp_ahTclsxThAA:7 a=2vsoB9skK-I_XsVBcJ7reEj75_EA:4 a=AfD3MYMu9mQA:10
From: "Tim Hare" <TimHare@comcast.net>
To: <ietf-calsify@osafoundation.org>
Subject: RE: [Ietf-calsify] Imprecise and alternative events foriCalendarandiTIP
Date: Wed, 30 Jan 2008 11:23:40 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01C86332.92B502B0"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <003901c8635a$98584fb0$6e2c2a0a@rockliffe.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchjWrx0Yzs2oCS3QAqm6Evi0a9e4AAAPANw
Message-Id: <20080130162350.0CAF91422A0@laweleka.osafoundation.org>
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2008 16:24:09 -0000
This is a multi-part message in MIME format.
------=_NextPart_000_00F2_01C86332.92B502B0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
I was trying to come up with solutions that don't require adding new
component types, since getting to simplification and standardization of the
current components has been such a long and winding road.
I take your point about transparency not reflecting the fact that you're
"busy". It's a general problem in calendaring tools - there's not an easy
way to say things like:
"I'm POTENTIALLY busy during that time, please don't schedule then" or
"I've got something planned during that time, but of course my boss can
override that".
I guess the best thing for the individual, currently, for your use case,
would be to mark the time as busy from 5pm to 11:59pm which at least has the
positive effect of preventing over-scheduling; and then using your CUA to
reduce the endpoints of the appointment as it becomes clearer exactly when
it will happen.
Tim Hare
Interested Bystander, Non-Inc.
------=_NextPart_000_00F2_01C86332.92B502B0
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>I was trying to come up with solutions that =
don't=20
require adding new component types, since getting to simplification and=20
standardization of the current components has been such a long and =
winding road.=20
</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008></SPAN></FONT> </DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>I take your point about transparency not =
reflecting the=20
fact that you're "busy". It's a general problem in calendaring =
tools -=20
there's not an easy way to say things like:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008></SPAN></FONT> </DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>"I'm POTENTIALLY busy during that time, =
please don't=20
schedule then" or</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>"I've got something planned during that time, =
but of=20
course my boss can override that".</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008></SPAN></FONT> </DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D762561716-30012008>I guess the best thing for the individual, =
currently,=20
for your use case, would be to mark the time as busy from 5pm to 11:59pm =
which=20
at least has the positive effect of preventing over-scheduling; and then =
using=20
your CUA to reduce the endpoints of the appointment as it becomes =
clearer=20
exactly when it will happen.</SPAN></FONT></DIV>
<DIV> </DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Tim Hare</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Interested Bystander,=20
Non-Inc.</FONT></DIV>
<DIV> </DIV><BR></BODY></HTML>
------=_NextPart_000_00F2_01C86332.92B502B0--
Return-Path: <douglm@rpi.edu>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4CDE48012F for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 06:51:24 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 354F914220C for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 06:51:27 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.968
X-Spam-Level:
X-Spam-Status: No, score=-1.968 tagged_above=-50 required=4 tests=[AWL=0.631, BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHM8aHdbuTEG for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 06:51:20 -0800 (PST)
Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 96F7E142201 for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 06:51:20 -0800 (PST)
Received: from [128.113.124.156] (crustacean-27.dynamic.rpi.edu [128.113.124.156]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id m0UEpF5M031280 for <ietf-calsify@osafoundation.org>; Wed, 30 Jan 2008 09:51:15 -0500
Message-ID: <47A08EF3.3070500@rpi.edu>
Date: Wed, 30 Jan 2008 09:51:31 -0500
From: Mike Douglass <douglm@rpi.edu>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Calsify <ietf-calsify@osafoundation.org>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RPI-SA-Score: undef - spam scanning disabled
X-CanItPRO-Stream: default
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.228
Subject: [Ietf-calsify] dtstamp twice
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2008 14:51:24 -0000
Maybe corrected but draft 7 has dtstamp and uid both required and
optional for freebusy
; the following are REQUIRED,
; but MUST NOT occur more than once
dtstamp / uid /
; the following are OPTIONAL,
; but MUST NOT occur more than once
contact / dtstart / dtend / duration / dtstamp /
organizer / uid / url /
--
Mike Douglass douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies 518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Return-Path: <timhare@comcast.net>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9A1758029C for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 17:22:38 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7A768142245 for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 17:22:41 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.338
X-Spam-Level:
X-Spam-Status: No, score=0.338 tagged_above=-50 required=4 tests=[AWL=-0.298, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, HTML_50_60=0.134, HTML_MESSAGE=0.001, MSGID_FROM_MTA_ID=1.393, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrn7u6bAMhG5 for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 17:22:34 -0800 (PST)
Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2FF25142254 for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 17:22:34 -0800 (PST)
Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id jB0N1Y00t16AWCU0A0AQ00; Wed, 30 Jan 2008 01:22:30 +0000
Received: from THare ([71.203.100.120]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id jDNQ1Y00V2brFRz8S00000; Wed, 30 Jan 2008 01:22:30 +0000
X-Authority-Analysis: v=1.0 c=1 a=VNWYfktXTpYA:10 a=HwOEHIZrOG3EIiPVvsYA:9 a=KASQF4MYEj_xsC2XTwgA:7 a=BkObnYNL7NrrQ8GNd7THUExF68AA:4 a=YewFc9KQ5U8A:10 a=Tv9MN5NUkNkA:10 a=Y6qChIQXU1wA:10 a=GL-Re4spl-cA:10 a=D2Slf8gdsRLDOa1uiOAA:9 a=jJ0WSVgvGhGgEe8aG40A:7 a=S-wsK2HrXWwd_YkWsPHWgyWWRTEA:4 a=BmBTXyoo3qoA:10 a=AfD3MYMu9mQA:10
From: "Tim Hare" <TimHare@comcast.net>
To: <ietf-calsify@osafoundation.org>
Subject: RE: [Ietf-calsify] Imprecise and alternative events for iCalendarandiTIP
Date: Tue, 29 Jan 2008 20:22:25 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BF_01C862B4.AAC71BF0"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <f6c025310801291638g35d48388y2034221488f91de1@mail.gmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Achi2G2FArAOWX43QBuwaDPUk4QJMwABQz3w
Message-Id: <20080130012234.2FF25142254@laweleka.osafoundation.org>
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2008 01:22:38 -0000
This is a multi-part message in MIME format.
------=_NextPart_000_00BF_01C862B4.AAC71BF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Would the "pencil in" function of a VEVENT for four hours with TRANSP:
TRANSPARENT provide a similar function to what is described in your use =
case
for VIMPRECISEEVENT?=20
=20
Similarly, for scheduling, would it be simpler to define iTIP such that =
a
METHOD: REQUEST for scheduling an appointment, which included VFREEBUSY
components; i.e. " I'd like to schedule an appointment, and I'm free =
during
these times", would indicate the preference of the time to be scheduled =
by
the order of the VFREEBUSY components? That would allow for an unlimited
number of potential openings for scheduling, without having to have a
defined RANK property, and it's certainly not that difficult for
implementations to ennumerate the VFREEBUSY components in that way.
=20
=20
=20
Tim Hare
Interested Bystander, Non-Inc.
=20
_____ =20
From: ietf-calsify-bounces@osafoundation.org
[mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of F=E1bio =
Henrique
da Silva
Sent: Tuesday, January 29, 2008 7:38 PM
To: Nigel Swinson
Cc: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] Imprecise and alternative events for
iCalendarandiTIP
Dear Nigel,
Thanks for the comments! Yes, I think that, even with the difficulties
presented on the appendix of the draft, we should look for solutions
preserving backward compatibility. It would be nice to hear some =
opinions
about these alternative design solutions you proposed =3Do)
I would only point that, apart from the discussion on the number of =
levels
(0-100 is only an initial hint based on PERCENT-COMPLETE), the concept =
of
rank is relevant, since some event descriptions and time ranges must be
marked as more appropriate/desired/likely to be scheduled/... than =
others.
But the primary purpose of the draft is that: to start a discussion on =
how
to give more flexibility to iCalendar in a standard way, pointing that =
such
mechanisms would be really useful for scheduling negotiation.
Cheers,
F=E1bio.
On Jan 24, 2008 3:09 PM, Nigel Swinson <Nigel.Swinson@mailsite.com> =
wrote:
Title : Imprecise and alternative events for iCalendar =
and
iTIP
Author(s) : F. Silva, R. Drummond
Filename : draft-silva-events-01.txt
Pages : 55=20
Date : 2007-12-21
This has long been something that has annoyed me about digital =
calendaring,
so I'm delighted to see that this work is proceeding :o) I've finally =
found
the time to read the document, and have the following comments.
=20
3.1. Imprecise Event Component
Given that calendars are being shared so much between so many clients, I
feel uneasy about the lack of backward compatibility expressed in the
document as it stands. Suppose I was to arrange with my mum to have =
dinner
tonight, but we hadn't yet agreed a time. I would then "guess" than the
meal would start somewhere between 5pm and 8pm and last until midnight. =
To
begin with I don't think I can say the event will last until midnight,
regardless of it's start time, so lets assume I say it is going to last =
4
hours. Writing this as a VIMPRECISEEVENT I think I'd have to write this =
as:
=20
BEGIN:VIMPRECISEEVENT
UID:20071005T133225Z-00001@example.com
DTSTAMP:20080124T160825Z
SUMMARY:Dinner with my mum
DURATION:PT4H
BEGIN:VFREEBUSY
UID:20071005T133225Z-00001A@example.com
DTSTAMP:20080124T160825Z
FREEBUSY;FBTYPE=3DFREE:20080124T170000Z/20080125T000000Z
END:VFREEBUSY
END:VIMPRECISEEVENT
=20
If I look at this inside a client that supports VIMPRECISEEVENT then =
perhaps
it'll show it with appropriate annotation, but then when I view it in a
client that doesn't support it I'll see absolutely nothing at all, =
implying
that my evening is free. =20
=20
I expected imprecise events to be specified by some modifier on the
DTSTART/DTEND properties. ie something like this (which also allows me =
to
say it ends at midnight):
=20
BEGIN:VIMPRECISEEVENT
UID:20071005T133225Z-00001@example.com
DTSTAMP:20080124T160825Z
SUMMARY:Dinner with my mum
DURATION:PT4H
DTSTART;RANGE=3D3H:20080124170000Z
DTEND:20081225000000Z
END:VIMPRECISEEVENT
=20
Now when I look at this in a client that doesn't understand the RANGE
parameter on DTSTART, it'll show up as busy from 5pm-12pm, and in a =
client
that does, it can show a "fuzzy" start from 5pm-8pm, and then definately
busy up until 12pm. =20
=20
A freebusy lookup could also then return meaningful data from both =
clients,
whereas you've specified that VIMPRECISEEVENT is invisible to free busy
lookups. The one that didn't support RANGE for DTSTART might return =
busy
from 8-12, while the other could return:
=20
BEGIN:VFREEBUSY
UID:20071005T133225Z-00001A@example.com
DTSTAMP:20080124T160825Z
=
FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20080124T170000Z/20080124T200000Z
FREEBUSY;FBTYPE=3DBUSY:20080124T200000Z/20080125T000000Z
END:VFREEBUSY
Admittedly adding a RANGE parameter to DTSTART and DTEND would not be as
flexibly as specifying a duration and a list of constraints by means of
free/busy, but it has the advantage of being far easier to apply to an
existing iCalendar parser, rather than having to deal with an entirely =
new
iCalendar component, so I think it might get a substantially bigger =
uptake.
=20
WRT to an event that specifies a medical appointment that occurs within =
one
of several time periods (the second example in the spec), that could =
then be
implemented either by means of STATUS:TENTATIVE on an appointment with =
an
RRULE, or else by using VALTERNATIVEEVENTS.
=20
3.2. Alternative Events Component
In the interests of parser re-use, rather than specifying the default =
event
properties in the alternativeeventsprop and then overridden in the =
*eventc
I'd be inclined to specify them by means of a "master event" section, of
type eventc. Then if some new event property comes out, only the parser =
for
eventc needs to be updated, rather than also the alternativeeventsprop
collection. One slight problem is that for a vevent to be valid, it =
must
have a dtstart, so I'd suggest we just refer to one of our alternative
events as our "master event" that contains default properties. The =
example
would become something like:
=20
BEGIN:VALTERNATIVEEVENTS
UID:20071005T133225Z-00001@example.com
DTSTAMP:20071005T133225Z
DEFAULTPROPERTIES:20071005T133225Z-00001-B@example.com
BEGIN:VEVENT
UID:20071005T133225Z-00001-B@example.com
DTSTAMP:20071005T133225Z
DTSTART:20071005T133225Z
SUMMARY:Quick interop test
COMMENT:Trying the options that seem most likely to be accepted...
END:VEVENT
BEGIN:VEVENT
UID:20071005T133225Z-00001-A@example.com
DTSTAMP:20071005T133225Z
DTSTART:20080406T090000Z
DTEND:20080405T120000Z
RANK:100
COMMENT:It would be perfect if we could meet at that same time!
END:VEVENT
BEGIN:VIMPRECISEEVENT
..etc...
END:VIMPRECISEEVENT
END:VALTERNATIVEEVENTS
=20
3.3/3.4/3.5 Minimum/Maximum Granularity/Rank Component Property
=20
I think these are icing that I'd be inclined to ignore in an initial
implementation. Even writing the gui and trying to communicate the =
concepts
would be challenging. I'm also not sure why it's worth saying that Rank =
is
defined as a %. Why not just an unsigned number? Then if you want to
communicate it as a % you can evaluate the max/min Rank, and convert to =
a %.
I'm sure 100 levels is plenty, but for the sake of writing a =
specification,
I don't see why you couldn't just say it's an arbitrary number. It =
would be
very annoying to find you needed more levels, but the standard didn't =
permit
it.
=20
Cheers
=20
Nigel
------=_NextPart_000_00BF_01C862B4.AAC71BF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D216361401-30012008>Would the "pencil in" function of a VEVENT =
for four=20
hours with TRANSP: TRANSPARENT provide a similar function to what is =
described=20
in your use case for VIMPRECISEEVENT? </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D216361401-30012008></SPAN></FONT> </DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D216361401-30012008>Similarly, for scheduling, would it be =
simpler to=20
define iTIP such that a METHOD: REQUEST for scheduling an appointment, =
which=20
included VFREEBUSY components; i.e. " I'd like to schedule an =
appointment, and=20
I'm free during these times", would indicate the preference of the =
time to=20
be scheduled by the order of the VFREEBUSY components? That would allow =
for an=20
unlimited number of potential openings for scheduling, without having to =
have a=20
defined RANK property, and it's certainly not that difficult for =
implementations=20
to ennumerate the VFREEBUSY components in that way.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D216361401-30012008></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Tim Hare</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Interested Bystander,=20
Non-Inc.</FONT></DIV>
<DIV> </DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> =
ietf-calsify-bounces@osafoundation.org=20
[mailto:ietf-calsify-bounces@osafoundation.org] <B>On Behalf Of =
</B>F=E1bio=20
Henrique da Silva<BR><B>Sent:</B> Tuesday, January 29, 2008 7:38=20
PM<BR><B>To:</B> Nigel Swinson<BR><B>Cc:</B>=20
ietf-calsify@osafoundation.org<BR><B>Subject:</B> Re: [Ietf-calsify] =
Imprecise=20
and alternative events for iCalendarandiTIP<BR></FONT><BR></DIV>
<DIV></DIV>Dear Nigel,<BR><BR>Thanks for the comments! Yes, I think =
that, even=20
with the difficulties presented on the appendix of the draft, we should =
look for=20
solutions preserving backward compatibility. It would be nice to hear =
some=20
opinions about these alternative design solutions you proposed =
=3Do)<BR><BR>I=20
would only point that, apart from the discussion on the number of levels =
(0-100=20
is only an initial hint based on PERCENT-COMPLETE), the concept of rank =
is=20
relevant, since some event descriptions and time ranges must be marked =
as more=20
appropriate/desired/likely to be scheduled/... than others.<BR><BR>But =
the=20
primary purpose of the draft is that: to start a discussion on how to =
give more=20
flexibility to iCalendar in a standard way, pointing that such =
mechanisms would=20
be really useful for scheduling=20
negotiation.<BR><BR>Cheers,<BR><BR>F=E1bio.<BR><BR>
<DIV class=3Dgmail_quote>On Jan 24, 2008 3:09 PM, Nigel Swinson <<A=20
href=3D"mailto:Nigel.Swinson@mailsite.com"=20
target=3D_blank>Nigel.Swinson@mailsite.com</A>> wrote:<BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
<DIV bgcolor=3D"#ffffff">
<DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: rgb(0,0,0) 2px solid; MARGIN-RIGHT: =
0px"> Title=20
: Imprecise and alternative =
events for=20
iCalendar and iTIP<BR> Author(s) =
=20
: F. Silva, R. Drummond<BR> =
Filename =20
: draft-silva-events-01.txt<BR> =
=20
Pages : 55 <BR> =
=20
Date :=20
2007-12-21</BLOCKQUOTE></DIV>
<DIV><FONT face=3DArial size=3D2>This has long been something that has =
annoyed me=20
about digital calendaring, so I'm delighted to see that this work is=20
proceeding :o) I've finally found the time to read the document, =
and=20
have the following comments.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><SPAN><A=20
=
name=3D117c2dc35508f571_117acfd71130c051_section-3.1><B>3.1</B></A><B>.&n=
bsp;=20
Imprecise Event Component</B></SPAN><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Given that calendars are being shared =
so much=20
between so many clients, I feel uneasy about the lack of backward=20
compatibility expressed in the document as it stands. Suppose I =
was to=20
arrange with my mum to have dinner tonight, but we hadn't yet =
agreed a=20
time. I would then "guess" than the meal would start somewhere =
between=20
5pm and 8pm and last until midnight. To begin with I don't think =
I can=20
say the event will last until midnight, regardless of it's start =
time, so=20
lets assume I say it is going to last 4 hours. Writing this as a =
<FONT=20
size=3D3>VIMPRECISEEVENT </FONT></FONT><FONT face=3DArial size=3D2>I =
think I'd have=20
to write this as:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> =20
BEGIN:VIMPRECISEEVENT<BR> <A =
href=3D"mailto:UID:20071005T133225Z-00001@example.com"=20
=
target=3D_blank>UID:20071005T133225Z-00001@example.com</A><BR>  =
; =20
DTSTAMP:20080124T160825Z<BR> =
SUMMARY:Dinner with =
my mum<BR> =20
DURATION:PT4H<BR> =20
BEGIN:VFREEBUSY<BR> <A=20
href=3D"mailto:UID:20071005T133225Z-00001A@example.com"=20
=
target=3D_blank>UID:20071005T133225Z-00001A@example.com</A><BR> &nbs=
p; =20
DTSTAMP:20080124T160825Z<BR> =
=
FREEBUSY;FBTYPE=3DFREE:20080124T170000Z/20080125T000000Z<BR> &=
nbsp; =20
END:VFREEBUSY<BR> =20
END:VIMPRECISEEVENT</DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>If I look at this inside a client =
that=20
supports <FONT face=3D"Times New Roman" =
size=3D3>VIMPRECISEEVENT</FONT> then=20
perhaps it'll show it with appropriate annotation, but then when I =
view it in=20
a client that doesn't support it I'll see absolutely nothing at all, =
implying=20
that my evening is free. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I expected </FONT><FONT face=3DArial=20
size=3D2>imprecise events to be specified by some modifier on the =
DTSTART/DTEND properties. ie something like this (which also =
allows me=20
to say it ends at midnight):</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> =20
BEGIN:VIMPRECISEEVENT<BR> <A =
href=3D"mailto:UID:20071005T133225Z-00001@example.com"=20
=
target=3D_blank>UID:20071005T133225Z-00001@example.com</A><BR>  =
; =20
DTSTAMP:20080124T160825Z<BR> =
SUMMARY:Dinner with =
my mum<BR> =20
DURATION:PT4H</DIV>
=
<DIV> DTSTART;RANGE=3D3H:2=
0080124170000Z</DIV>
=
<DIV> DTEND:20081225000000=
Z<BR> =20
END:VIMPRECISEEVENT</DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Now when I look at this in a client =
that doesn't=20
understand the RANGE parameter on DTSTART, it'll show up as busy from=20
5pm-12pm, and in a client that does, it can show a "fuzzy" start from =
5pm-8pm,=20
and then definately busy up until 12pm. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>A freebusy lookup could also then =
return=20
meaningful data from both clients, whereas you've specified that <FONT =
face=3D"Times New Roman" size=3D3>VIMPRECISEEVENT</FONT> is =
invisible to free=20
busy lookups. The one that didn't support RANGE for=20
DTSTART might return busy from 8-12, while the other could=20
return:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3> =20
BEGIN:VFREEBUSY<BR> <A=20
href=3D"mailto:UID:20071005T133225Z-00001A@example.com"=20
=
target=3D_blank>UID:20071005T133225Z-00001A@example.com</A><BR> &nbs=
p; =20
DTSTAMP:20080124T160825Z<BR> =
=
FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20080124T170000Z/20080124T200000Z<BR>&nb=
sp; =20
=
FREEBUSY;FBTYPE=3DBUSY:20080124T200000Z/20080125T000000Z<BR> &=
nbsp; =20
END:VFREEBUSY</FONT><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Admittedly adding a RANGE parameter =
to DTSTART=20
and DTEND would not be as flexibly as specifying a duration and a list =
of=20
constraints by means of free/busy, but it has the advantage of being =
far=20
easier to apply to an existing iCalendar parser, rather than having to =
deal=20
with an entirely new iCalendar component, so I think it might get a=20
substantially bigger uptake.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>WRT to an event that specifies a =
medical=20
appointment that occurs within one of several time periods (the =
second=20
example in the spec), that could then be implemented either by =
means of=20
STATUS:TENTATIVE on an appointment with an RRULE, or else by using =
<FONT=20
size=3D3>VALTERNATIVEEVENTS.</FONT></FONT></DIV>
<DIV><SPAN></SPAN> </DIV>
<DIV><SPAN><A=20
=
name=3D117c2dc35508f571_117acfd71130c051_section-3.2><B>3.2</B></A><B>.&n=
bsp;=20
Alternative Events Component</B></SPAN><BR></DIV>
<DIV><FONT face=3DArial size=3D2>In the interests of parser re-use, =
rather than=20
specifying the default event properties in the <FONT=20
size=3D3>alternativeeventsprop </FONT><FONT size=3D2>and then =
overridden in=20
the <FONT size=3D3>*eventc</FONT> I'd be inclined to specify them =
by means=20
of a "master event" section, of type eventc. Then if some new =
event=20
property comes out, only the parser for eventc needs to be updated, =
rather=20
than also the alternativeeventsprop collection. One=20
slight problem is that for a vevent to be valid, it must have a =
dtstart,=20
so I'd suggest we just refer to one of our alternative events as =
our=20
"master event" that contains default properties. The example =
would become=20
something like:</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> BEGIN:VALTERNATIVEEVENTS</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3> <A=20
href=3D"mailto:UID:20071005T133225Z-00001@example.com"=20
=
target=3D_blank>UID:20071005T133225Z-00001@example.com</A><BR>  =
; =20
DTSTAMP:20071005T133225Z</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3> <A=20
href=3D"mailto:DEFAULTPROPERTIES:20071005T133225Z-00001-B@example.com" =
=
target=3D_blank>DEFAULTPROPERTIES:20071005T133225Z-00001-B@example.com</A=
><BR></FONT></FONT> BEGIN:VEVENT<BR>&n=
bsp; =20
<A href=3D"mailto:UID:20071005T133225Z-00001-B@example.com"=20
=
target=3D_blank>UID:20071005T133225Z-00001-B@example.com</A><BR> &nb=
sp; =20
DTSTAMP:20071005T133225Z<BR> =20
DTSTART:20071005T133225Z<BR> =
SUMMARY:Quick=20
interop test<BR> COMMENT:Trying the =
options that=20
seem most likely to be accepted...</DIV>
<DIV> END:VEVENT</DIV>
<DIV> =20
BEGIN:VEVENT<BR> <A=20
href=3D"mailto:UID:20071005T133225Z-00001-A@example.com"=20
=
target=3D_blank>UID:20071005T133225Z-00001-A@example.com</A><BR> &nb=
sp; =20
DTSTAMP:20071005T133225Z<BR> =20
DTSTART:20080406T090000Z<BR> =20
DTEND:20080405T120000Z<BR> =20
RANK:100<BR> COMMENT:It would be perfect =
if we=20
could meet at that same time!<BR> =20
END:VEVENT<BR> =20
=
BEGIN:VIMPRECISEEVENT<BR> ..etc...<BR>=
=20
END:VIMPRECISEEVENT<BR> =20
END:VALTERNATIVEEVENTS<BR></DIV>
<DIV><FONT face=3DArial></FONT> </DIV>
<DIV><FONT face=3DArial><SPAN><A=20
=
name=3D117c2dc35508f571_117acfd71130c051_section-3.3><B>3.3</B></A><B>/3.=
4/3.5 =20
Minimum/Maximum Granularity/Rank Component =
Property</B></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think these are icing that I'd be =
inclined to=20
ignore in an initial implementation. Even writing the gui and =
trying to=20
communicate the concepts would be challenging. I'm also not sure =
why=20
it's worth saying that Rank is defined as a %. Why not just an =
unsigned=20
number? Then if you want to communicate it as a % you can =
evaluate the=20
max/min Rank, and convert to a %. I'm sure 100 levels is plenty, =
but for=20
the sake of writing a specification, I don't see why you couldn't just =
say=20
it's an arbitrary number. It would be very annoying to find you =
needed=20
more levels, but the standard didn't permit it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Cheers</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial=20
size=3D2>Nigel</FONT></DIV></DIV></BLOCKQUOTE></DIV><BR></BODY></HTML>
------=_NextPart_000_00BF_01C862B4.AAC71BF0--
Return-Path: <fabio.silva@gmail.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1894F8012F for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 16:38:22 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id ED9B4142217 for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 16:38:24 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egj8YKMK+InC for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 16:38:17 -0800 (PST)
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D16914220C for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 16:38:17 -0800 (PST)
Received: by wx-out-0506.google.com with SMTP id h27so35450wxd.15 for <ietf-calsify@osafoundation.org>; Tue, 29 Jan 2008 16:38:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=fWFHtGrAM5B8PqDK2PAMk2OyYyA/01qNppWQeSsW7UE=; b=ZN17oeW085hALuVwA60SCmmT9JSkzWHaELY0s2oQFOlIPF5kcFNLlkLxenoqJCcidl2gEZT+RlUKW2F9pNs0GZ6yOfylFRvnEEbGB8VgFwxOaPlC7uDbjl3WKCdx3YCDkNUliKpD7anqNL5fsROijsOTrMz4RMaVOatm4cUGP9U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=vV5o+kYdKwI7fL/2sBGC5pPjQ9aY3DwEpeb8rqgERLO1zWnrL/mywjxeFJ0KJnuIc6UvUoEQJOxhI0GIQCpw37rm1d/gfmsl8nZ8bhh5wQUtpqMzYAhliWgqv1K+BJWEDw3Q6qitMc/7L0Vxht7b85Pr8hwmhr9psmNTv96z498=
Received: by 10.142.162.5 with SMTP id k5mr30506wfe.171.1201653492441; Tue, 29 Jan 2008 16:38:12 -0800 (PST)
Received: by 10.142.49.6 with HTTP; Tue, 29 Jan 2008 16:38:12 -0800 (PST)
Message-ID: <f6c025310801291638g35d48388y2034221488f91de1@mail.gmail.com>
Date: Tue, 29 Jan 2008 21:38:12 -0300
From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" <fabio.silva@gmail.com>
To: "Nigel Swinson" <Nigel.Swinson@mailsite.com>
Subject: Re: [Ietf-calsify] Imprecise and alternative events for iCalendar andiTIP
In-Reply-To: <008601c85eb4$39d0ab40$6e2c2a0a@rockliffe.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_16649_5123350.1201653492421"
References: <f6c025310712270927r2d432319w9e93caeae2343a5e@mail.gmail.com> <008601c85eb4$39d0ab40$6e2c2a0a@rockliffe.com>
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2008 00:38:22 -0000
------=_Part_16649_5123350.1201653492421
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Dear Nigel,
Thanks for the comments! Yes, I think that, even with the difficulties
presented on the appendix of the draft, we should look for solutions
preserving backward compatibility. It would be nice to hear some opinions
about these alternative design solutions you proposed =3Do)
I would only point that, apart from the discussion on the number of levels
(0-100 is only an initial hint based on PERCENT-COMPLETE), the concept of
rank is relevant, since some event descriptions and time ranges must be
marked as more appropriate/desired/likely to be scheduled/... than others.
But the primary purpose of the draft is that: to start a discussion on how
to give more flexibility to iCalendar in a standard way, pointing that such
mechanisms would be really useful for scheduling negotiation.
Cheers,
F=E1bio.
On Jan 24, 2008 3:09 PM, Nigel Swinson <Nigel.Swinson@mailsite.com> wrote:
> Title : Imprecise and alternative events for iCalendar
> and iTIP
> Author(s) : F. Silva, R. Drummond
> Filename : draft-silva-events-01.txt
> Pages : 55
> Date : 2007-12-21
>
> This has long been something that has annoyed me about digital
> calendaring, so I'm delighted to see that this work is proceeding :o) I'=
ve
> finally found the time to read the document, and have the following
> comments.
>
> *3.1**. Imprecise Event Component*
> Given that calendars are being shared so much between so many clients, I
> feel uneasy about the lack of backward compatibility expressed in the
> document as it stands. Suppose I was to arrange with my mum to have
> dinner tonight, but we hadn't yet agreed a time. I would then "guess" th=
an
> the meal would start somewhere between 5pm and 8pm and last until midnigh=
t.
> To begin with I don't think I can say the event will last until midnight,
> regardless of it's start time, so lets assume I say it is going to last 4
> hours. Writing this as a VIMPRECISEEVENT I think I'd have to write this
> as:
>
> BEGIN:VIMPRECISEEVENT
> UID:20071005T133225Z-00001@example.com
> DTSTAMP:20080124T160825Z
> SUMMARY:Dinner with my mum
> DURATION:PT4H
> BEGIN:VFREEBUSY
> UID:20071005T133225Z-00001A@example.com
> DTSTAMP:20080124T160825Z
> FREEBUSY;FBTYPE=3DFREE:20080124T170000Z/20080125T000000Z
> END:VFREEBUSY
> END:VIMPRECISEEVENT
>
> If I look at this inside a client that supports VIMPRECISEEVENT then
> perhaps it'll show it with appropriate annotation, but then when I view i=
t
> in a client that doesn't support it I'll see absolutely nothing at all,
> implying that my evening is free.
>
> I expected imprecise events to be specified by some modifier on the
> DTSTART/DTEND properties. ie something like this (which also allows me t=
o
> say it ends at midnight):
>
> BEGIN:VIMPRECISEEVENT
> UID:20071005T133225Z-00001@example.com
> DTSTAMP:20080124T160825Z
> SUMMARY:Dinner with my mum
> DURATION:PT4H
> DTSTART;RANGE=3D3H:20080124170000Z
> DTEND:20081225000000Z
> END:VIMPRECISEEVENT
>
> Now when I look at this in a client that doesn't understand the RANGE
> parameter on DTSTART, it'll show up as busy from 5pm-12pm, and in a clien=
t
> that does, it can show a "fuzzy" start from 5pm-8pm, and then definately
> busy up until 12pm.
>
> A freebusy lookup could also then return meaningful data from both
> clients, whereas you've specified that VIMPRECISEEVENT is invisible to
> free busy lookups. The one that didn't support RANGE for DTSTART might
> return busy from 8-12, while the other could return:
>
> BEGIN:VFREEBUSY
> UID:20071005T133225Z-00001A@example.com
> DTSTAMP:20080124T160825Z
> FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20080124T170000Z/20080124T200000=
Z
> FREEBUSY;FBTYPE=3DBUSY:20080124T200000Z/20080125T000000Z
> END:VFREEBUSY
> Admittedly adding a RANGE parameter to DTSTART and DTEND would not be as
> flexibly as specifying a duration and a list of constraints by means of
> free/busy, but it has the advantage of being far easier to apply to an
> existing iCalendar parser, rather than having to deal with an entirely ne=
w
> iCalendar component, so I think it might get a substantially bigger uptak=
e.
>
> WRT to an event that specifies a medical appointment that occurs
> within one of several time periods (the second example in the spec), that
> could then be implemented either by means of STATUS:TENTATIVE on an
> appointment with an RRULE, or else by using VALTERNATIVEEVENTS.
>
> *3.2**. Alternative Events Component*
> In the interests of parser re-use, rather than specifying the default
> event properties in the alternativeeventsprop and then overridden in the
> *eventc I'd be inclined to specify them by means of a "master event"
> section, of type eventc. Then if some new event property comes out, only
> the parser for eventc needs to be updated, rather than also the
> alternativeeventsprop collection. One slight problem is that for a veven=
t
> to be valid, it must have a dtstart, so I'd suggest we just refer to one =
of
> our alternative events as our "master event" that contains default
> properties. The example would become something like:
>
> BEGIN:VALTERNATIVEEVENTS
> UID:20071005T133225Z-00001@example.com
> DTSTAMP:20071005T133225Z
> DEFAULTPROPERTIES:20071005T133225Z-00001-B@example.com
> BEGIN:VEVENT
> UID:20071005T133225Z-00001-B@example.com
> DTSTAMP:20071005T133225Z
> DTSTART:20071005T133225Z
> SUMMARY:Quick interop test
> COMMENT:Trying the options that seem most likely to be accepted...
> END:VEVENT
> BEGIN:VEVENT
> UID:20071005T133225Z-00001-A@example.com
> DTSTAMP:20071005T133225Z
> DTSTART:20080406T090000Z
> DTEND:20080405T120000Z
> RANK:100
> COMMENT:It would be perfect if we could meet at that same time!
> END:VEVENT
> BEGIN:VIMPRECISEEVENT
> ..etc...
> END:VIMPRECISEEVENT
> END:VALTERNATIVEEVENTS
>
> *3.3**/3.4/3.5 Minimum/Maximum Granularity/Rank Component Property*
>
> I think these are icing that I'd be inclined to ignore in an initial
> implementation. Even writing the gui and trying to communicate the conce=
pts
> would be challenging. I'm also not sure why it's worth saying that Rank =
is
> defined as a %. Why not just an unsigned number? Then if you want to
> communicate it as a % you can evaluate the max/min Rank, and convert to a
> %. I'm sure 100 levels is plenty, but for the sake of writing a
> specification, I don't see why you couldn't just say it's an arbitrary
> number. It would be very annoying to find you needed more levels, but th=
e
> standard didn't permit it.
>
> Cheers
>
> Nigel
>
------=_Part_16649_5123350.1201653492421
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Dear Nigel,<br><br>Thanks for the comments! Yes, I think that, even with th=
e difficulties presented on the appendix of the draft, we should look for s=
olutions preserving backward compatibility. It would be nice to hear some o=
pinions about these alternative design solutions you proposed =3Do)<br>
<br>I would only point that, apart from the discussion on the number of lev=
els (0-100 is only an initial hint based on PERCENT-COMPLETE), the concept =
of rank is relevant, since some event descriptions and time ranges must be =
marked as more appropriate/desired/likely to be scheduled/... than others.<=
br>
<br>But the primary purpose of the draft is that: to start a discussion on =
how to give more flexibility to iCalendar in a standard way, pointing that =
such mechanisms would be really useful for scheduling negotiation.<br><br>
Cheers,<br>
<br>F=E1bio.<br><br><div class=3D"gmail_quote">On Jan 24, 2008 3:09 PM, Nig=
el Swinson <<a href=3D"mailto:Nigel.Swinson@mailsite.com" target=3D"_bla=
nk">Nigel.Swinson@mailsite.com</a>> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt=
0pt 0.8ex; padding-left: 1ex;">
<div bgcolor=3D"#ffffff"><div>
<blockquote style=3D"border-left: 2px solid rgb(0, 0, 0); padding-right: 0p=
x; padding-left: 5px; margin-left: 5px; margin-right: 0px;"> &nb=
sp; Title=20
: Imprecise and alternative events for=
=20
iCalendar and iTIP<br> Author(s) =
=20
: F. Silva, R. Drummond<br> Filename &nb=
sp;=20
: draft-silva-events-01.txt<br> =
=20
Pages : 55 <br> &nb=
sp;=20
Date : 2007-12-21</blockqu=
ote></div>
<div><font face=3D"Arial" size=3D"2">This has long been something that has =
annoyed me=20
about digital calendaring, so I'm delighted to see that this work is pr=
oceeding=20
:o) I've finally found the time to read the document, and have th=
e=20
following comments.</font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><span><a name=3D"117c2dc35508f571_117acfd71130c051_section-3.1"><b>3.1=
</b></a><b>. =20
Imprecise Event Component</b></span><br></div>
<div><font face=3D"Arial" size=3D"2">Given that calendars are being shared =
so much=20
between so many clients, I feel uneasy about the lack of backward compatibi=
lity=20
expressed in the document as it stands. Suppose I was to arrange with=
my=20
mum to have dinner tonight, but we hadn't yet agreed a time. =
I would=20
then "guess" than the meal would start somewhere between 5pm and =
8pm and last=20
until midnight. To begin with I don't think I can say the ev=
ent will=20
last until midnight, regardless of it's start time, so lets assume I sa=
y it is=20
going to last 4 hours. Writing this as a <font size=3D"3">VIMPRECISEE=
VENT=20
</font></font><font face=3D"Arial" size=3D"2">I think I'd have to write=
this=20
as:</font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div> =20
BEGIN:VIMPRECISEEVENT<br> =20
<a href=3D"mailto:UID:20071005T133225Z-00001@example.com" target=3D"_blank"=
>UID:20071005T133225Z-00001@example.com</a><br> &nbs=
p; =20
DTSTAMP:20080124T160825Z<br> =20
SUMMARY:Dinner with my mum<br> &nbs=
p;=20
DURATION:PT4H<br> =20
BEGIN:VFREEBUSY<br> =20
<a href=3D"mailto:UID:20071005T133225Z-00001A@example.com" target=3D"_blank=
">UID:20071005T133225Z-00001A@example.com</a><br> &n=
bsp; =20
DTSTAMP:20080124T160825Z<br> =20
FREEBUSY;FBTYPE=3DFREE:20080124T170000Z/20080125T000000Z<br> &nb=
sp; =20
END:VFREEBUSY<br> =20
END:VIMPRECISEEVENT</div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2">If I look at this inside a client that=
=20
supports <font face=3D"Times New Roman" size=3D"3">VIMPRECISEEVENT</fo=
nt> then=20
perhaps it'll show it with appropriate annotation, but then when I view=
it in a=20
client that doesn't support it I'll see absolutely nothing at all, =
implying that=20
my evening is free. </font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2">I expected </font><font face=3D"Arial"=
size=3D"2">imprecise=20
events to be specified by some modifier on the DTSTART/DTEND=20
properties. ie something like this (which also allows me to say it en=
ds at=20
midnight):</font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div> =20
BEGIN:VIMPRECISEEVENT<br> =20
<a href=3D"mailto:UID:20071005T133225Z-00001@example.com" target=3D"_blank"=
>UID:20071005T133225Z-00001@example.com</a><br> &nbs=
p; =20
DTSTAMP:20080124T160825Z<br> =20
SUMMARY:Dinner with my mum<br> &nbs=
p;=20
DURATION:PT4H</div>
<div> DTSTART;RANGE=3D3H:200=
80124170000Z</div>
<div> DTEND:20081225000000Z<=
br> =20
END:VIMPRECISEEVENT</div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2">Now when I look at this in a client th=
at doesn't=20
understand the RANGE parameter on DTSTART, it'll show up as busy from 5=
pm-12pm,=20
and in a client that does, it can show a "fuzzy" start from 5pm-8=
pm, and then=20
definately busy up until 12pm. </font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2">A freebusy lookup could also then retu=
rn meaningful=20
data from both clients, whereas you've specified that <font face=3D"Tim=
es New Roman" size=3D"3">VIMPRECISEEVENT</font> is invisible to free=
=20
busy lookups. The one that didn't support RANGE for=20
DTSTART might return busy from 8-12, while the other could=20
return:</font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2"><font face=3D"Times New Roman" size=3D=
"3"> =20
BEGIN:VFREEBUSY<br> =20
<a href=3D"mailto:UID:20071005T133225Z-00001A@example.com" target=3D"_blank=
">UID:20071005T133225Z-00001A@example.com</a><br> &n=
bsp; =20
DTSTAMP:20080124T160825Z<br> =20
FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20080124T170000Z/20080124T200000Z<br> =
; =20
FREEBUSY;FBTYPE=3DBUSY:20080124T200000Z/20080125T000000Z<br> &nb=
sp; =20
END:VFREEBUSY</font><br></font></div>
<div><font face=3D"Arial" size=3D"2">Admittedly adding a RANGE parameter to=
DTSTART and=20
DTEND would not be as flexibly as specifying a duration and a list of=20
constraints by means of free/busy, but it has the advantage of being far ea=
sier=20
to apply to an existing iCalendar parser, rather than having to deal with a=
n=20
entirely new iCalendar component, so I think it might get a substantially b=
igger=20
uptake.</font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2">WRT to an event that specifies a medic=
al=20
appointment that occurs within one of several time periods (the second=
=20
example in the spec), that could then be implemented either by means o=
f=20
STATUS:TENTATIVE on an appointment with an RRULE, or else by using <font si=
ze=3D"3">VALTERNATIVEEVENTS.</font></font></div>
<div><span></span> </div>
<div><span><a name=3D"117c2dc35508f571_117acfd71130c051_section-3.2"><b>3.2=
</b></a><b>. =20
Alternative Events Component</b></span><br></div>
<div><font face=3D"Arial" size=3D"2">In the interests of parser re-use, rat=
her than=20
specifying the default event properties in the <font size=3D"3">altern=
ativeeventsprop </font><font size=3D"2">and then overridden in the=20
<font size=3D"3">*eventc</font> I'd be inclined to specify them by=
means of a=20
"master event" section, of type eventc. Then if some new ev=
ent property=20
comes out, only the parser for eventc needs to be updated, rather than =
;also=20
the alternativeeventsprop collection. One slight problem is that=
for=20
a vevent to be valid, it must have a dtstart, so I'd suggest we ju=
st refer=20
to one of our alternative events as our "master event" that conta=
ins default=20
properties. The example would become something like:</font></font></di=
v>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div> BEGIN:VALTERNATIVEEVENTS</div>
<div><font face=3D"Arial" size=3D"2"><font face=3D"Times New Roman" size=3D=
"3"> =20
<a href=3D"mailto:UID:20071005T133225Z-00001@example.com" target=3D"_blank"=
>UID:20071005T133225Z-00001@example.com</a><br> &nbs=
p;=20
DTSTAMP:20071005T133225Z</font></font></div>
<div><font face=3D"Arial" size=3D"2"><font face=3D"Times New Roman" size=3D=
"3"> <a href=3D"mailto:DEFAULTPROPERTIES=
:20071005T133225Z-00001-B@example.com" target=3D"_blank">DEFAULTPROPERTIES:=
20071005T133225Z-00001-B@example.com</a><br>
</font></font> BEGIN:VEVENT<br> &nb=
sp; =20
<a href=3D"mailto:UID:20071005T133225Z-00001-B@example.com" target=3D"_blan=
k">UID:20071005T133225Z-00001-B@example.com</a><br> =
=20
DTSTAMP:20071005T133225Z<br> =20
DTSTART:20071005T133225Z<br> SUMMARY:Quick in=
terop=20
test<br> COMMENT:Trying the options that seem=
most=20
likely to be accepted...</div>
<div> END:VEVENT</div>
<div> =20
BEGIN:VEVENT<br> =20
<a href=3D"mailto:UID:20071005T133225Z-00001-A@example.com" target=3D"_blan=
k">UID:20071005T133225Z-00001-A@example.com</a><br> =
=20
DTSTAMP:20071005T133225Z<br> =20
DTSTART:20080406T090000Z<br> =20
DTEND:20080405T120000Z<br> =20
RANK:100<br> COMMENT:It would be perfect if w=
e=20
could meet at that same time!<br> =20
END:VEVENT<br> =20
BEGIN:VIMPRECISEEVENT<br> ..etc...<br>&n=
bsp; =20
END:VIMPRECISEEVENT<br> =20
END:VALTERNATIVEEVENTS<br></div>
<div><font face=3D"Arial"></font> </div>
<div><font face=3D"Arial"><span><a name=3D"117c2dc35508f571_117acfd71130c05=
1_section-3.3"><b>3.3</b></a><b>/3.4/3.5 Minimum/Maximum=20
Granularity/Rank Component Property</b></span></font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2">I think these are icing that I'd b=
e inclined to=20
ignore in an initial implementation. Even writing the gui and trying =
to=20
communicate the concepts would be challenging. I'm also not sure =
why it's=20
worth saying that Rank is defined as a %. Why not just an unsigned=20
number? Then if you want to communicate it as a % you can evaluate th=
e=20
max/min Rank, and convert to a %. I'm sure 100 levels is plenty, =
but for=20
the sake of writing a specification, I don't see why you couldn't j=
ust say it's=20
an arbitrary number. It would be very annoying to find you needed mor=
e=20
levels, but the standard didn't permit it.</font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2">Cheers</font></div>
<div><font face=3D"Arial" size=3D"2"></font> </div>
<div><font face=3D"Arial" size=3D"2">Nigel</font></div></div>
</blockquote></div><br>
------=_Part_16649_5123350.1201653492421--
Return-Path: <dgc@funambol.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0C6347F635 for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 20:57:08 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D31AA14220E for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 20:57:10 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si4YkYCwxW8M for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 20:57:02 -0800 (PST)
Received: from a.mail.sonomait.com (a.mail.sonomait.com [64.142.123.30]) by laweleka.osafoundation.org (Postfix) with ESMTP id 51D4B142217 for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 20:57:02 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by a.mail.sonomait.com (Postfix) with ESMTP id 4EA391EEC02D; Mon, 28 Jan 2008 20:56:59 -0800 (PST)
Received: from a.mail.sonomait.com ([127.0.0.1]) by localhost (a.mail.sonomait.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzcaIHU6jEb5; Mon, 28 Jan 2008 20:56:52 -0800 (PST)
Received: from DGCSonyFS (c-75-67-229-125.hsd1.nh.comcast.net [75.67.229.125]) by a.mail.sonomait.com (Postfix) with ESMTP id 484201EEC039; Mon, 28 Jan 2008 20:56:52 -0800 (PST)
From: "Darryl Champagne" <dgc@funambol.com>
To: "'Tim Hare'" <TimHare@comcast.net>, <ietf-calsify@osafoundation.org>
References: <p06300006c3c447f9a694@[199.106.106.52]> <20080129032724.BC71B14220E@laweleka.osafoundation.org>
Subject: RE: [Ietf-calsify] RFC2445 latest IETF document?
Date: Mon, 28 Jan 2008 23:56:48 -0500
Message-ID: <034f01c86233$5baf5310$6e02a8c0@DGCSonyFS>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20080129032724.BC71B14220E@laweleka.osafoundation.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchiJHWENtTQWun8R1+AmSu+kSJZywAAjJ5QAAKkUJA=
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2008 04:57:08 -0000
Hi,
I believe the last version posted was:
Title : Internet Calendaring and Scheduling Core Object
Specification (iCalendar)
Author(s) : B. Desruisseaux
Filename : draft-ietf-calsify-rfc2445bis-07.txt
Pages : 177
Date : 2007-7-9
Per IETF policy, it is deleted from the www.ietf.org/internet-drafts area
after 6 months (which is why the link no longer works), but is still
available in the tools /id area.
The drafts are available via the Calsify status page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
Specifically, the html version is at
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-07 or the text
version at http://tools.ietf.org/id/draft-ietf-calsify-rfc2445bis-07.txt.
dgc
-----Original Message-----
From: ietf-calsify-bounces@osafoundation.org
[mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Tim Hare
Sent: Monday, January 28, 2008 10:27 PM
To: ietf-calsify@osafoundation.org
Subject: [Ietf-calsify] RFC2445 latest IETF document?
I cannot seem to find the latest RFC2445 document at IETF. Could someone
please post the correct URL since I must be doing something dumb?
Thanks
Tim Hare
Interested Bystander, Non-Inc.
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Return-Path: <timhare@comcast.net>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2563A7F777 for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 19:27:28 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E9E21142254 for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 19:27:30 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.632
X-Spam-Level:
X-Spam-Status: No, score=0.632 tagged_above=-50 required=4 tests=[AWL=-0.761, BAYES_50=0.001, MSGID_FROM_MTA_ID=1.393, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITvQ+KbAVcae for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 19:27:24 -0800 (PST)
Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by laweleka.osafoundation.org (Postfix) with ESMTP id BC71B14220E for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 19:27:24 -0800 (PST)
Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id iq9t1Y00D0b6N64AA03Z00; Tue, 29 Jan 2008 03:27:00 +0000
Received: from THare ([71.203.100.120]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id irTG1Y0012brFRz8P00000; Tue, 29 Jan 2008 03:27:21 +0000
X-Authority-Analysis: v=1.0 c=1 a=lZJ7f9q6KR-Ld2OepLsA:9 a=5FhCKpFAnlpBOAKnWQ-w-K3TbEgA:4 a=gJcimI5xSWUA:10
From: "Tim Hare" <TimHare@comcast.net>
To: <ietf-calsify@osafoundation.org>
Date: Mon, 28 Jan 2008 22:27:13 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <p06300006c3c447f9a694@[199.106.106.52]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchiJHWENtTQWun8R1+AmSu+kSJZywAAjJ5Q
Message-Id: <20080129032724.BC71B14220E@laweleka.osafoundation.org>
Subject: [Ietf-calsify] RFC2445 latest IETF document?
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2008 03:27:28 -0000
I cannot seem to find the latest RFC2445 document at IETF. Could someone
please post the correct URL since I must be doing something dumb?
Thanks
Tim Hare
Interested Bystander, Non-Inc.
Return-Path: <jwn2@qualcomm.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 60B277F586 for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 19:10:06 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30D0A142217 for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 19:10:09 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 tagged_above=-50 required=4 tests=[AWL=0.558, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-6+AZRg3vR3 for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 19:10:02 -0800 (PST)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C32FB14220E for <ietf-calsify@osafoundation.org>; Mon, 28 Jan 2008 19:10:02 -0800 (PST)
Received: from snape.qualcomm.com (snape.qualcomm.com [129.46.132.184]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0T39sYq014677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Jan 2008 19:09:55 -0800
Received: from [199.106.106.52] (dhcp-bldg-l6-76-4.qualcomm.com [129.46.76.42]) by snape.qualcomm.com (8.14.2/8.12.3/1.0) with ESMTP id m0T39psd013447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 19:09:54 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06300006c3c447f9a694@[199.106.106.52]>
In-Reply-To: <p06300000c3bbe02c9b45@[129.46.77.134]>
References: <20080119215144.96514142254@laweleka.osafoundation.org> <p06300008c3bae792120d@[129.46.77.134]> <9B326483310292E596429C20@ninevah.local> <p06300000c3bbe02c9b45@[129.46.77.134]>
User-Agent: eudora6.3a0carbon-1009061025
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Mon, 28 Jan 2008 19:09:12 -0800
To: ietf-calsify@osafoundation.org
From: John W Noerenberg II <jwn2@qualcomm.com>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2008 03:10:06 -0000
At 10:30 AM -0800 1/22/08, John W Noerenberg II wrote:
>>Actually I think a valid situation is to have PARTSTAT=ACCEPTED and
>>RSVP=TRUE. That is called out in iTIP as a case of an organizer
>>requesting a participant to re-confirm their status for the meeting
>>(see section 3.2.2.7). So at least in that case there is a need for
>>RSVP separate from the PARTSTAT value. Though you could argue that
>>the organizer should just set PARTSTAT back to NEEDS-ACTION.
>
>That's my argument. I think 3.2.2.7 can safely be deleted. There's
>nothing preventing the ORGANIZER from setting PARTSTAT=NEEDS-ACTION
>for an ATTENDEE in a subsequent REQUEST, regardless of the value of
>PARTSTAT for an ATTENDEE in a previous REPLY.
Judging by the resounding silence, no else seems to think this worth
discussion.
Is it because most everyone thinks this is too late in the game to
make changes like this; is it because y'all think I'm crazy (I've
been called worse, I can handle it. :-)); or is it something in
between?
--
john noerenberg
--------------------------------------------------------------------
"We need not to be left alone. We need to be really
bothered once in a while."
-- Ray Bradbury, Farhenheit 451, 1953
--------------------------------------------------------------------
Return-Path: <jwn2@qualcomm.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E073F7F8D0 for <ietf-calsify@osafoundation.org>; Tue, 22 Jan 2008 13:06:01 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8041014274C for <ietf-calsify@osafoundation.org>; Tue, 22 Jan 2008 13:06:04 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-50 required=4 tests=[AWL=0.579, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzISTwnD78Hl for <ietf-calsify@osafoundation.org>; Tue, 22 Jan 2008 13:05:58 -0800 (PST)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 17F19142254 for <ietf-calsify@osafoundation.org>; Tue, 22 Jan 2008 13:05:58 -0800 (PST)
Received: from snape.qualcomm.com (snape.qualcomm.com [129.46.132.184]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0ML0jYs011224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Jan 2008 13:00:45 -0800
Received: from [129.46.77.134] (valinor.qualcomm.com [129.46.77.134]) by snape.qualcomm.com (8.14.2/8.12.3/1.0) with ESMTP id m0ML0hGO005019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2008 13:00:44 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06300006c3bbf660cf74@[129.46.77.134]>
In-Reply-To: <9B326483310292E596429C20@ninevah.local>
References: <20080119215144.96514142254@laweleka.osafoundation.org> <p06300008c3bae792120d@[129.46.77.134]> <9B326483310292E596429C20@ninevah.local>
User-Agent: eudora6.3a0carbon-1009061025
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Tue, 22 Jan 2008 12:56:18 -0800
To: Cyrus Daboo <cyrus@daboo.name>
From: John W Noerenberg II <jwn2@qualcomm.com>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2008 21:06:02 -0000
At 9:38 PM -0500 1/21/08, Cyrus Daboo wrote:
>One could argue that was too strict a reading of the RFC but I think
>its a fair reading of the current state.
I'd go a little further and say this is an incorrect reading. RSVP
is always optional for VEVENTS. So a CUA or CSA that demands it has
gone too far. :-)
Curiously, I did find references in VTODOs that make it mandatory.
I'm not liking that.
(It's probably more appropriate to ask this in the context of
calconnect, but...) Is anybody doing anything with VTODOs? As a
creator and consumer of iCalendar objects, I've never encountered
one. I notice that CalConnect's test suite mentions them not at all.
I confess I'm leery of loping off VTODO and VJOURNAL, but it's a
tempting thought. It would certainly reduce my angst over RSVP.
--
john noerenberg
----------------------------------------------------------------------
All actions are wrought by the qualities of nature only.
The self, deluded by egoism, thinketh, "I am the doer."
-- Bhagavad Gita
----------------------------------------------------------------------
Return-Path: <jwn2@qualcomm.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 62C7A8058E for <ietf-calsify@osafoundation.org>; Tue, 22 Jan 2008 10:30:56 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0296B14274B for <ietf-calsify@osafoundation.org>; Tue, 22 Jan 2008 10:30:59 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-50 required=4 tests=[AWL=0.601, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJhMh77xDR2L for <ietf-calsify@osafoundation.org>; Tue, 22 Jan 2008 10:30:52 -0800 (PST)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 38C45142746 for <ietf-calsify@osafoundation.org>; Tue, 22 Jan 2008 10:30:52 -0800 (PST)
Received: from snape.qualcomm.com (snape.qualcomm.com [129.46.132.184]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0MIUjwt029621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Jan 2008 10:30:46 -0800
Received: from [129.46.77.134] (valinor.qualcomm.com [129.46.77.134]) by snape.qualcomm.com (8.14.2/8.12.3/1.0) with ESMTP id m0MIUfuw023403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2008 10:30:45 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06300000c3bbe02c9b45@[129.46.77.134]>
In-Reply-To: <9B326483310292E596429C20@ninevah.local>
References: <20080119215144.96514142254@laweleka.osafoundation.org> <p06300008c3bae792120d@[129.46.77.134]> <9B326483310292E596429C20@ninevah.local>
User-Agent: eudora6.3a0carbon-1009061025
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Tue, 22 Jan 2008 10:30:21 -0800
To: Cyrus Daboo <cyrus@daboo.name>
From: John W Noerenberg II <jwn2@qualcomm.com>
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2008 18:30:56 -0000
At 9:38 PM -0500 1/21/08, Cyrus Daboo wrote:
>Hi John,
>
>--On January 21, 2008 4:38:39 PM -0800 John W Noerenberg II
><jwn2@qualcomm.com> wrote:
>
>>>>subsequent UPDATE, then the REPLY should probably not be accepted.
>>>>Do others agree and should we clarify this?
>>
>>Forgive me if I'm dragging out a dead horse...
>>
>>Why do we have both PARTSTAT and RSVP parameters? Is there ever a
>>condition in a REQUEST that a CUA would set PARTSTAT=NEEDS-ACTION and not
>>set RSVP=TRUE? Is there ever a condition where a CUA would omit
>>PARTSTAT=NEEDS-ACTION and could not include an RSVP=FALSE?
>>
>>If it were up to me, I'd get rid of RSVP. I know the RSVP parameter is
>>used. In 2445bis and 2446bis, I'd say the RSVP parameter and it's value
>>have no semantic meaning. It's presence in an ATTENDEE property is not
>>an error, but it's use is discouraged.
>>
>>This is just my way of striking a blow for brevity in VEVENTs. ;-)
>
>Actually I think a valid situation is to have PARTSTAT=ACCEPTED and
>RSVP=TRUE. That is called out in iTIP as a case of an organizer
>requesting a participant to re-confirm their status for the meeting
>(see section 3.2.2.7). So at least in that case there is a need for
>RSVP separate from the PARTSTAT value. Though you could argue that
>the organizer should just set PARTSTAT back to NEEDS-ACTION.
That's my argument. I think 3.2.2.7 can safely be deleted. There's
nothing preventing the ORGANIZER from setting PARTSTAT=NEEDS-ACTION
for an ATTENDEE in a subsequent REQUEST, regardless of the value of
PARTSTAT for an ATTENDEE in a previous REPLY.
>
>On your point, it would seem natural to say that anytime PARTSTAT is
>NEEDS-ACTION that a reply is expected. However, if ROLE is set to
>indicate a non-required participant, perhaps the organizer does not
>care about whether a reply is returned or not.
On a REQUEST, If ROLE=OPT-PARTICIPANT or NON-PARTICIPANT, then
omitting the PARTSTAT parameter if no response is required is
legitimate.
What underlies my argument is my unwillingness to anthropomorphize
the ORGANIZER. If the ORGANIZER requires a response, then
PARTSTAT=NEEDS-ACTION fills the bill. Whether the organizer cares is
out-of-scope, I claim.
>
>I'll note that one of the things I did in the Apple CalDAV server
>was to require the presence of RSVP=TRUE for invites to
>auto-responding resources (e.g. locations) that the server itself
>generated iTIP replies for. This did cause at least one client to
>change its behavior because it was not setting RSVP=TRUE. One could
>argue that was too strict a reading of the RFC but I think its a
>fair reading of the current state.
Was the client not responding to PARTSTAT=NEEDS-ACTION?
I suppose one could say that setting PARSTAT=NEEDS-ACTION and
RSVP=TRUE amounts to the ORGANIZER really, really needs a response.
But now we're sliding down the slippery slope of
anthropomorphization. ;-)
--
john noerenberg
----------------------------------------------------------------------
While the belief we have found the Answer can separate us
and make us forget our humanity, it is the seeking that continues
to bring us together, that makes and keeps us human.
-- Daniel J. Boorstin, "The Seekers", 1998
----------------------------------------------------------------------
Return-Path: <cyrus@daboo.name>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EFF6E7F77B for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 18:38:30 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 860E914274E for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 18:38:33 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.464
X-Spam-Level:
X-Spam-Status: No, score=-2.464 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlJhrDbIIWut for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 18:38:27 -0800 (PST)
Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id BF31414274C for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 18:38:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9A858192919; Mon, 21 Jan 2008 21:38:23 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcem6Kt0zx4r; Mon, 21 Jan 2008 21:38:23 -0500 (EST)
Received: from [10.0.1.2] (unknown [66.90.26.201]) by daboo.name (Postfix) with ESMTP id 2D0D0192912; Mon, 21 Jan 2008 21:38:21 -0500 (EST)
Date: Mon, 21 Jan 2008 21:38:17 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: John W Noerenberg II <jwn2@qualcomm.com>, ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] As long as we're talking about PARTSTAT...
Message-ID: <9B326483310292E596429C20@ninevah.local>
In-Reply-To: <p06300008c3bae792120d@[129.46.77.134]>
References: <20080119215144.96514142254@laweleka.osafoundation.org> <p06300008c3bae792120d@[129.46.77.134]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2008 02:38:31 -0000
Hi John,
--On January 21, 2008 4:38:39 PM -0800 John W Noerenberg II
<jwn2@qualcomm.com> wrote:
>>> subsequent UPDATE, then the REPLY should probably not be accepted.
>>> Do others agree and should we clarify this?
>
> Forgive me if I'm dragging out a dead horse...
>
> Why do we have both PARTSTAT and RSVP parameters? Is there ever a
> condition in a REQUEST that a CUA would set PARTSTAT=NEEDS-ACTION and not
> set RSVP=TRUE? Is there ever a condition where a CUA would omit
> PARTSTAT=NEEDS-ACTION and could not include an RSVP=FALSE?
>
> If it were up to me, I'd get rid of RSVP. I know the RSVP parameter is
> used. In 2445bis and 2446bis, I'd say the RSVP parameter and it's value
> have no semantic meaning. It's presence in an ATTENDEE property is not
> an error, but it's use is discouraged.
>
> This is just my way of striking a blow for brevity in VEVENTs. ;-)
Actually I think a valid situation is to have PARTSTAT=ACCEPTED and
RSVP=TRUE. That is called out in iTIP as a case of an organizer requesting
a participant to re-confirm their status for the meeting (see section
3.2.2.7). So at least in that case there is a need for RSVP separate from
the PARTSTAT value. Though you could argue that the organizer should just
set PARTSTAT back to NEEDS-ACTION.
On your point, it would seem natural to say that anytime PARTSTAT is
NEEDS-ACTION that a reply is expected. However, if ROLE is set to indicate
a non-required participant, perhaps the organizer does not care about
whether a reply is returned or not.
I'll note that one of the things I did in the Apple CalDAV server was to
require the presence of RSVP=TRUE for invites to auto-responding resources
(e.g. locations) that the server itself generated iTIP replies for. This
did cause at least one client to change its behavior because it was not
setting RSVP=TRUE. One could argue that was too strict a reading of the RFC
but I think its a fair reading of the current state.
--
Cyrus Daboo
Return-Path: <jwn2@qualcomm.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0A4A780705 for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:47:37 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8DA7714274B for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:47:39 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.975
X-Spam-Level:
X-Spam-Status: No, score=-1.975 tagged_above=-50 required=4 tests=[AWL=0.625, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVZY-nnhFvzU for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:47:33 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4FDED14274D for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:47:33 -0800 (PST)
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Mime-Version: Message-Id:In-Reply-To:References:User-Agent: X-PGP-RSA-Fingerprint:X-PGP-DH-Fingerprint:Date:To:From: Subject:Content-Type; b=V6VWWmsG18MZqessvHVOUpCw8A2fnRgwMr4XxqJ3OW9j3gqi6GTQpoE2 TaZ5kbVZ1Hi7xB1lAwCq6qS3C9/wvxCDRyiTYG0y01JjPYhwOLeAyQnNy R/eVG/vkdCcxr6ulM1qwrVzZfcUqRYUXHFG9MgTe6O8yqDygZEUwsF0ET s=;
X-IronPort-AV: E=McAfee;i="5100,188,5212"; a="620636"
Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jan 2008 16:47:30 -0800
Received: from snape.qualcomm.com (snape.qualcomm.com [129.46.132.184]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0M0lTE2022281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:47:30 -0800
Received: from [129.46.77.134] (valinor.qualcomm.com [129.46.77.134]) by snape.qualcomm.com (8.14.2/8.12.3/1.0) with ESMTP id m0M0lS4p018970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:47:29 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06300008c3bae792120d@[129.46.77.134]>
In-Reply-To: <20080119215144.96514142254@laweleka.osafoundation.org>
References: <20080119215144.96514142254@laweleka.osafoundation.org>
User-Agent: eudora6.3a0carbon-1009061025
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Mon, 21 Jan 2008 16:38:39 -0800
To: <ietf-calsify@osafoundation.org>
From: John W Noerenberg II <jwn2@qualcomm.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Ietf-calsify] As long as we're talking about PARTSTAT...
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2008 00:47:37 -0000
>At 2:08 PM -0800 1/21/08, John W Noerenberg II wrote:
>>IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a
>>subsequent UPDATE, then the REPLY should probably not be accepted.
>>Do others agree and should we clarify this?
Forgive me if I'm dragging out a dead horse...
Why do we have both PARTSTAT and RSVP parameters? Is there ever a
condition in a REQUEST that a CUA would set PARTSTAT=NEEDS-ACTION and
not set RSVP=TRUE? Is there ever a condition where a CUA would omit
PARTSTAT=NEEDS-ACTION and could not include an RSVP=FALSE?
If it were up to me, I'd get rid of RSVP. I know the RSVP parameter
is used. In 2445bis and 2446bis, I'd say the RSVP parameter and it's
value have no semantic meaning. It's presence in an ATTENDEE
property is not an error, but it's use is discouraged.
This is just my way of striking a blow for brevity in VEVENTs. ;-)
--
john noerenberg
----------------------------------------------------------------------
The Constitution of the United States is a law for rulers and people
equally in war and in peace, and covers with the shield of its
protection all classes of men, at all times, and under all
circumstances.
-- U.S. Supreme Court, Ex Parte Milligan, 71 U.S. 2, 120-121 (1866)
----------------------------------------------------------------------
Return-Path: <jwn2@qualcomm.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9C4AE80705 for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:32:45 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2FF0A142753 for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:32:48 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-50 required=4 tests=[AWL=0.651, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibvGZuMAG-tg for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:32:41 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6FBDE14274B for <ietf-calsify@osafoundation.org>; Mon, 21 Jan 2008 16:32:41 -0800 (PST)
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Mime-Version: Message-Id:In-Reply-To:References:User-Agent: X-PGP-RSA-Fingerprint:X-PGP-DH-Fingerprint:Date:To:From: Subject:Cc:Content-Type; b=XgVqhvYupsmzz0DKVXb5PO1piuw6Qpd64zWdSIp68Gjy6+TpZqO8nm4O UOi+2mQJRcO5HoXgEMm2KDsrsvZRzSkFV9H5qGNUJxloBAnIx0QukT+De 5QidrdMb//wrUsJk3VnuTC/6tkhnTFHzjq4fuzG2IuyFvY8JXtq560Dvn A=;
X-IronPort-AV: E=McAfee;i="5100,188,5212"; a="620501"
Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jan 2008 16:32:38 -0800
Received: from snape.qualcomm.com (snape.qualcomm.com [129.46.132.184]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0M0WbcB020813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Jan 2008 16:32:37 -0800
Received: from [129.46.77.134] (valinor.qualcomm.com [129.46.77.134]) by snape.qualcomm.com (8.14.2/8.12.3/1.0) with ESMTP id m0M0WZ5k017918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jan 2008 16:32:37 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06300007c3bac872c67d@[129.46.77.134]>
In-Reply-To: <4791EE2D.8070808@cisco.com>
References: <p06300008c3b6d7cd7d44@[129.46.77.134]> <4791EE2D.8070808@cisco.com>
User-Agent: eudora6.3a0carbon-1009061025
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Mon, 21 Jan 2008 16:20:57 -0800
To: Eliot Lear <lear@cisco.com>
From: John W Noerenberg II <jwn2@qualcomm.com>
Subject: Re: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2008 00:32:45 -0000
At 1:33 PM +0100 1/19/08, Eliot Lear wrote:
>Hello John,
>>2.1.5 3. says:
>>
>>"Attendees" send "REPLY" messages to the "Organizer". For
>>replies where the "UID" property value is the same, the value of
>>the "SEQUENCE" property indicates the revision of the component
>>to which the "Attendee" is replying. The reply with the highest
>>numeric value for the "SEQUENCE" property obsoletes all other
>>replies with lower values.
>>
>>Should I take this to mean that the VEVENT in a REPLY only matches
>>the VEVENT in the corresponding REQUEST if both the value of UID
>>and SEQUENCE in each message match? Or should it be that the REPLY
>>matches the REQUEST if SEQUENCE.REPLY is greater than or equal to
>>SEQUENCE.REQUEST?
>
>There are two contexts to consider - that of the PARTICIPANT and
>that of the ORGANIZER.
Yup. I should have made it clear I was speaking from the perspective
of the ORGANIZER's interpreting a PARTICIPANT's reply.
>The PARTICIPANT is REPLYing to a specific VEVENT with a specific
>SEQUENCE, and so there is not interpreting involved at that end.
>The ORGANIZER receiving REPLYs can use SEQUENCE to detect out of
>order messages, such that if a REPLY with a lower SEQUENCE number is
>received subsequent to one with a higher SEQUENCE, the REPLY with
>the lower value can be safely ignored.
>
>The converse is *not* necessarily true: if an ORGANIZER sends an
>UPDATE that bumped the SEQUENCE and then received a REPLY with lower
>SEQUENCE, the ORGANIZER should consider whether he or she reset
>PARTSTAT on the later SEQUENCE in order to make a sane decision as
>to how to consider the PARTICIPANT's REPLY. If the ORGANIZER did
>not reset PARTSTAT, then one may not wish to simply ignore the
>REPLY. Indeed the text currently says the following:
>
>> The value of the "SEQUENCE" property contained in a response from an
>> "Attendee" may not always match the "Organizer's" revision.
>> Implementations may choose to have the CUA indicate to the CU that
>> the response is to an entry that has been revised and allow the CU to
>> decide whether or not to accept the response.
>
>IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a subsequent
>UPDATE, then the REPLY should probably not be accepted. Do others
>agree and should we clarify this?
Suppose a PARTICIPANT replies with a SEQUENCE value greater than the
ORGANIZER's value. Should the ORGANIZER send some sort of error
status to the PARTICIPANT? Perhaps better, the CUA should notify the
CU there's a problem. Otherwise a malicious ATTENDEE CUA could cause
the organizer's CUA to spew error messages.
I don't mean to be disingenuous, but what do you mean by UPDATE?
AFAIK, it's not a term of art in the iCalendar world - and there
probably are too many ways to construct a message some reader would
believe was an update message of one kind or another. :-)
But for the sake of answering your question, I'll just consider
METHOD:REPLY. You can tell me if I got it right. ;-) Essentially, I
agree. If the ORGANIZER sets an ATTENDEE's PARTSTAT=NEEDS-ACTION and
receives a REPLY from that ATTENDEE which has a value for SEQUENCE
not only lower, but different than the REQUEST from the ORGANIZER,
then the ORGANIZER can discard the REPLY.
--
john noerenberg
----------------------------------------------------------------------
The Constitution of the United States is a law for rulers and people
equally in war and in peace, and covers with the shield of its
protection all classes of men, at all times, and under all
circumstances.
-- U.S. Supreme Court, Ex Parte Milligan, 71 U.S. 2, 120-121 (1866)
----------------------------------------------------------------------
Return-Path: <timhare@comcast.net>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8ABB18061D for <ietf-calsify@osafoundation.org>; Sat, 19 Jan 2008 13:51:48 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 00EDC142274 for <ietf-calsify@osafoundation.org>; Sat, 19 Jan 2008 13:51:51 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.141
X-Spam-Level:
X-Spam-Status: No, score=0.141 tagged_above=-50 required=4 tests=[AWL=-0.360, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_ID=1.393, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1fpSpUdkJTV for <ietf-calsify@osafoundation.org>; Sat, 19 Jan 2008 13:51:44 -0800 (PST)
Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by laweleka.osafoundation.org (Postfix) with ESMTP id 96514142254 for <ietf-calsify@osafoundation.org>; Sat, 19 Jan 2008 13:51:44 -0800 (PST)
Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id f7Vw1Y00P0lTkoCAA08x00; Sat, 19 Jan 2008 21:51:30 +0000
Received: from THare ([71.203.100.120]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id f9rc1Y00E2brFRz8Q00000; Sat, 19 Jan 2008 21:51:41 +0000
X-Authority-Analysis: v=1.0 c=1 a=utkeCFPfR4MA:10 a=PFsjAnyDAAAA:8 a=Id2LQgM-GT1tfNtmj3IA:9 a=S0rdocWhh-sSibaO6LMA:7 a=ecUDPu0wVX__N83t9kZecVp_zXAA:4 a=YewFc9KQ5U8A:10 a=oltX7JrCFroA:10
From: "Tim Hare" <TimHare@comcast.net>
To: <ietf-calsify@osafoundation.org>
Subject: RE: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
Date: Sat, 19 Jan 2008 16:51:45 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <4791EE2D.8070808@cisco.com>
Thread-Index: Achal5I7Q6n4mUs1RA20ijEu/gJq1AAKtNfg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Message-Id: <20080119215144.96514142254@laweleka.osafoundation.org>
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Jan 2008 21:51:48 -0000
A case _could_ be made, that when you as ORGANIZER receive a REPLY with a
lower SEQUENCE, that you accept it and set PARTSTAT to reflect the status as
"what we know so far". This reflects how meeting organization works in the
phone-call-and-pencil (PCAP) system.
Tim Hare
Interested Bystander, Non-Inc.
-----Original Message-----
From: ietf-calsify-bounces@osafoundation.org
[mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Eliot Lear
Sent: Saturday, January 19, 2008 7:34 AM
To: John W Noerenberg II
Cc: ietf-calsify@osafoundation.org
Subject: Re: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in
rfc2446bis
Hello John,
> 2.1.5 3. says:
>
> "Attendees" send "REPLY" messages to the "Organizer". For replies
> where the "UID" property value is the same, the value of the
> "SEQUENCE" property indicates the revision of the component to which
> the "Attendee" is replying. The reply with the highest numeric value
> for the "SEQUENCE" property obsoletes all other replies with lower
> values.
>
> Should I take this to mean that the VEVENT in a REPLY only matches the
> VEVENT in the corresponding REQUEST if both the value of UID and
> SEQUENCE in each message match? Or should it be that the REPLY
> matches the REQUEST if SEQUENCE.REPLY is greater than or equal to
> SEQUENCE.REQUEST?
There are two contexts to consider - that of the PARTICIPANT and that of the
ORGANIZER. The PARTICIPANT is REPLYing to a specific VEVENT with a specific
SEQUENCE, and so there is not interpreting involved at that end. The
ORGANIZER receiving REPLYs can use SEQUENCE to detect out of order messages,
such that if a REPLY with a lower SEQUENCE number is received subsequent to
one with a higher SEQUENCE, the REPLY with the lower value can be safely
ignored.
The converse is *not* necessarily true: if an ORGANIZER sends an UPDATE
that bumped the SEQUENCE and then received a REPLY with lower SEQUENCE, the
ORGANIZER should consider whether he or she reset PARTSTAT on the later
SEQUENCE in order to make a sane decision as to how to consider the
PARTICIPANT's REPLY. If the ORGANIZER did not reset PARTSTAT, then one may
not wish to simply ignore the REPLY. Indeed the text currently says the
following:
> The value of the "SEQUENCE" property contained in a response from an
> "Attendee" may not always match the "Organizer's" revision.
> Implementations may choose to have the CUA indicate to the CU that
> the response is to an entry that has been revised and allow the CU to
> decide whether or not to accept the response.
IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a subsequent UPDATE,
then the REPLY should probably not be accepted. Do others agree and should
we clarify this?
Eliot
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Return-Path: <lear@cisco.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5C53880A2D for <ietf-calsify@osafoundation.org>; Sat, 19 Jan 2008 04:33:58 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C107D142254 for <ietf-calsify@osafoundation.org>; Sat, 19 Jan 2008 04:34:00 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.983
X-Spam-Level:
X-Spam-Status: No, score=-1.983 tagged_above=-50 required=4 tests=[AWL=0.482, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+65noI10CDq for <ietf-calsify@osafoundation.org>; Sat, 19 Jan 2008 04:33:54 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 03815142274 for <ietf-calsify@osafoundation.org>; Sat, 19 Jan 2008 04:33:53 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.25,220,1199660400"; d="scan'208";a="3433842"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2008 13:33:50 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0JCXo9g002706; Sat, 19 Jan 2008 13:33:50 +0100
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4135.cisco.com [10.61.80.38]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0JCXngo020879; Sat, 19 Jan 2008 12:33:49 GMT
Message-ID: <4791EE2D.8070808@cisco.com>
Date: Sat, 19 Jan 2008 13:33:49 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: John W Noerenberg II <jwn2@qualcomm.com>
Subject: Re: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
References: <p06300008c3b6d7cd7d44@[129.46.77.134]>
In-Reply-To: <p06300008c3b6d7cd7d44@[129.46.77.134]>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2168; t=1200746030; x=1201610030; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20Re=3A=20[Ietf-calsify]=20Interpreting=202.1.5=2 0Message=20Sequencing=20in=20rfc2446bis |Sender:=20; bh=iTt+9a1b2jOivocyD9TRYQmjkM/HXpFv5Ef2fqgDY/k=; b=WFSEAX7XLRnbAqfKkhLsUJkz7tb4KlqQCWQ5SCsmJBbhjmjdggcCYN/7rB G3s1rM/haAoQbOU0miIqr2JymaGQRd1BGm7Vr32Aj3ATuW4ebxwv9LYYAeqU ZZOXQzEAYX;
Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Jan 2008 12:33:58 -0000
Hello John,
> 2.1.5 3. says:
>
> "Attendees" send "REPLY" messages to the "Organizer". For
> replies where the "UID" property value is the same, the value of
> the "SEQUENCE" property indicates the revision of the component
> to which the "Attendee" is replying. The reply with the highest
> numeric value for the "SEQUENCE" property obsoletes all other
> replies with lower values.
>
> Should I take this to mean that the VEVENT in a REPLY only matches the
> VEVENT in the corresponding REQUEST if both the value of UID and
> SEQUENCE in each message match? Or should it be that the REPLY
> matches the REQUEST if SEQUENCE.REPLY is greater than or equal to
> SEQUENCE.REQUEST?
There are two contexts to consider - that of the PARTICIPANT and that of
the ORGANIZER. The PARTICIPANT is REPLYing to a specific VEVENT with a
specific SEQUENCE, and so there is not interpreting involved at that
end. The ORGANIZER receiving REPLYs can use SEQUENCE to detect out of
order messages, such that if a REPLY with a lower SEQUENCE number is
received subsequent to one with a higher SEQUENCE, the REPLY with the
lower value can be safely ignored.
The converse is *not* necessarily true: if an ORGANIZER sends an UPDATE
that bumped the SEQUENCE and then received a REPLY with lower SEQUENCE,
the ORGANIZER should consider whether he or she reset PARTSTAT on the
later SEQUENCE in order to make a sane decision as to how to consider
the PARTICIPANT's REPLY. If the ORGANIZER did not reset PARTSTAT, then
one may not wish to simply ignore the REPLY. Indeed the text currently
says the following:
> The value of the "SEQUENCE" property contained in a response from an
> "Attendee" may not always match the "Organizer's" revision.
> Implementations may choose to have the CUA indicate to the CU that
> the response is to an entry that has been revised and allow the CU to
> decide whether or not to accept the response.
IMHO if the ORGANIZER set PARTSTAT to "NEEDS-ACTION" in a subsequent
UPDATE, then the REPLY should probably not be accepted. Do others agree
and should we clarify this?
Eliot
Return-Path: <timhare@comcast.net>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D470A80B25 for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 18:27:38 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F5A8142254 for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 18:27:41 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.631
X-Spam-Level:
X-Spam-Status: No, score=-0.631 tagged_above=-50 required=4 tests=[AWL=0.576, BAYES_00=-2.599, MSGID_FROM_MTA_ID=1.393, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofPMYZr32H-A for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 18:27:34 -0800 (PST)
Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by laweleka.osafoundation.org (Postfix) with ESMTP id D8AD7142203 for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 18:27:34 -0800 (PST)
Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id eaum1Y0061HpZEs0A1A600; Sat, 19 Jan 2008 02:27:32 +0000
Received: from THare ([71.203.100.120]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id eqSi1Y0032brFRz8a00000; Sat, 19 Jan 2008 02:26:47 +0000
X-Authority-Analysis: v=1.0 c=1 a=utkeCFPfR4MA:10 a=PFsjAnyDAAAA:8 a=VkrFwHKdAb8ac-Q_ckYA:9 a=kyZDhcZcZLSff058A9UA:7 a=dpvIkmzd1TBafEcdPxJWuTdYsBMA:4 a=YewFc9KQ5U8A:10 a=oH_WKSxD8ioA:10
From: "Tim Hare" <TimHare@comcast.net>
To: <ietf-calsify@osafoundation.org>
Subject: RE: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
Date: Fri, 18 Jan 2008 21:27:31 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <p06300008c3b6d7cd7d44@[129.46.77.134]>
Thread-Index: AchaJe5lxNbRPB43QBiZacYo1kgV3QAHGnaA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Message-Id: <20080119022734.D8AD7142203@laweleka.osafoundation.org>
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Jan 2008 02:27:39 -0000
My understanding is that the VEVENT matches if UID is the same, and SEQUENCE
is the same.
Reasoning logically, rather than reading the spec, if you are the organizer
and you receive a reply with a SEQUENCE higher than yours, something is
wrong (for example, your calendar store has been restored from a backup
before all REPLY items were received and processed). If the SEQUENCE is
lower, then the client is responding to a previous REQUEST; we can (should
we?) presume you sent a new REQUEST when whatever changed happened that
caused SEQUENCE to be incremented, and therefore you might want to wait
until the response to that revision arrives.
Tim Hare
Interested Bystander, Non-Inc.
-----Original Message-----
From: ietf-calsify-bounces@osafoundation.org
[mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of John W
Noerenberg II
Sent: Friday, January 18, 2008 5:59 PM
To: ietf-calsify@osafoundation.org
Subject: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
2.1.5 3. says:
"Attendees" send "REPLY" messages to the "Organizer". For replies where the
"UID" property value is the same, the value of the "SEQUENCE" property
indicates the revision of the component to which the "Attendee" is replying.
The reply with the highest numeric value for the "SEQUENCE" property
obsoletes all other replies with lower values.
Should I take this to mean that the VEVENT in a REPLY only matches the
VEVENT in the corresponding REQUEST if both the value of UID and SEQUENCE in
each message match? Or should it be that the REPLY matches the REQUEST if
SEQUENCE.REPLY is greater than or equal to SEQUENCE.REQUEST?
--
john noerenberg
----------------------------------------------------------------------
The Constitution of the United States is a law for rulers and people
equally in war and in peace, and covers with the shield of its
protection all classes of men, at all times, and under all
circumstances.
-- U.S. Supreme Court, Ex Parte Milligan, 71 U.S. 2, 120-121 (1866)
----------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Return-Path: <jwn2@qualcomm.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D46B2804C0 for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 14:59:42 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 48B10142274 for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 14:59:25 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-50 required=4 tests=[AWL=0.680, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7AB8eK1RWcJ for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 14:59:18 -0800 (PST)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8CB67142217 for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 14:59:18 -0800 (PST)
Received: from snape.qualcomm.com (snape.qualcomm.com [129.46.132.184]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m0IMxF7t019397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 14:59:15 -0800
Received: from [129.46.77.134] (valinor.qualcomm.com [129.46.77.134]) by snape.qualcomm.com (8.14.2/8.12.3/1.0) with ESMTP id m0IMxD81007243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 18 Jan 2008 14:59:14 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06300008c3b6d7cd7d44@[129.46.77.134]>
User-Agent: eudora6.3a0carbon-1009061025
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Fri, 18 Jan 2008 14:58:35 -0800
To: ietf-calsify@osafoundation.org
From: John W Noerenberg II <jwn2@qualcomm.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [Ietf-calsify] Interpreting 2.1.5 Message Sequencing in rfc2446bis
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jan 2008 22:59:42 -0000
2.1.5 3. says:
"Attendees" send "REPLY" messages to the "Organizer". For
replies where the "UID" property value is the same, the value of
the "SEQUENCE" property indicates the revision of the component
to which the "Attendee" is replying. The reply with the highest
numeric value for the "SEQUENCE" property obsoletes all other
replies with lower values.
Should I take this to mean that the VEVENT in a REPLY only matches
the VEVENT in the corresponding REQUEST if both the value of UID and
SEQUENCE in each message match? Or should it be that the REPLY
matches the REQUEST if SEQUENCE.REPLY is greater than or equal to
SEQUENCE.REQUEST?
--
john noerenberg
----------------------------------------------------------------------
The Constitution of the United States is a law for rulers and people
equally in war and in peace, and covers with the shield of its
protection all classes of men, at all times, and under all
circumstances.
-- U.S. Supreme Court, Ex Parte Milligan, 71 U.S. 2, 120-121 (1866)
----------------------------------------------------------------------
Return-Path: <lear@cisco.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3D8EE80B19 for <ietf-calsify@osafoundation.org>; Thu, 17 Jan 2008 07:52:01 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9FA2E142203 for <ietf-calsify@osafoundation.org>; Thu, 17 Jan 2008 07:51:43 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-50 required=4 tests=[AWL=0.485, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVlGuP5TV7qc for <ietf-calsify@osafoundation.org>; Thu, 17 Jan 2008 07:51:37 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 334EF14220C for <ietf-calsify@osafoundation.org>; Thu, 17 Jan 2008 07:51:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,301,1196636400"; d="scan'208";a="3284212"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2008 16:51:33 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0HFpXiD011155 for <ietf-calsify@osafoundation.org>; Thu, 17 Jan 2008 16:51:33 +0100
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4513.cisco.com [10.61.81.160]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0HFpXgo025135 for <ietf-calsify@osafoundation.org>; Thu, 17 Jan 2008 15:51:33 GMT
Message-ID: <478F7985.3020008@cisco.com>
Date: Thu, 17 Jan 2008 16:51:33 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org" <ietf-calsify@osafoundation.org>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=365; t=1200585093; x=1201449093; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20Issue=20list=20for=20rfc2446bis=20closes=20on=2 0March=201! |Sender:=20; bh=RDMePxTE6t0EWZ6NVCTJpUS7PxVT1EcR8ta/5vgI5EY=; b=EfALxINMs4/ZGBl9c96ZGNG1BQ+l7XfSAclqC4fMgGWH1WSBN6qT7n9Db8 jxC/hOr1mYkcHKv7ETfk6EELwUyLw+23c/kHnn46U+wb1IdFXfcX+SShElyd cLd+mPVsbQ;
Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Subject: [Ietf-calsify] Issue list for rfc2446bis closes on March 1!
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jan 2008 15:52:01 -0000
Dear all,
In an effort to bring this group's efforts to a close the chairs would
like to close the issues list for rfc2446bis. The primary topic for the
IETF meeting will be any open issues. After March 1, only those issues
that arise due to resolution of open issues will be entertained.
Thanks for your support,
For Aki, Eliot
Calsify co-chair
Return-Path: <lear@cisco.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DF14980AF8 for <ietf-calsify@osafoundation.org>; Wed, 16 Jan 2008 04:19:03 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 435B9142245 for <ietf-calsify@osafoundation.org>; Wed, 16 Jan 2008 04:19:06 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-50 required=4 tests=[AWL=0.486, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM75aXF0e2dX for <ietf-calsify@osafoundation.org>; Wed, 16 Jan 2008 04:19:01 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2BB00142217 for <ietf-calsify@osafoundation.org>; Wed, 16 Jan 2008 04:19:00 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,293,1196636400"; d="scan'208";a="3149030"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jan 2008 13:18:57 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0GCIvoX028684 for <ietf-calsify@osafoundation.org>; Wed, 16 Jan 2008 13:18:57 +0100
Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4463.cisco.com [10.61.81.110]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0GCImgo012254 for <ietf-calsify@osafoundation.org>; Wed, 16 Jan 2008 12:18:57 GMT
Message-ID: <478DF628.9030104@cisco.com>
Date: Wed, 16 Jan 2008 13:18:48 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org" <ietf-calsify@osafoundation.org>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8797; t=1200485937; x=1201349937; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20reminder=3A=20Calsify=20call=20today,=209=3A30a m=20US/New=20York.=20=20Call=20information=0A=20follows=20be low |Sender:=20; bh=KUYh4dKqf8LjSWqKNZKzudQ4FIKyqSNT6oYtZf8DsvM=; b=dUJtR5G7r1xZ+DvXQTzlVX541PySRuzNz0lifogMwV83NmmaosgC2XNFlU /0Jkz2M87UgRRFEgtxJzc1//7iDVi5uNyvZ2k9xvwW6vikzkUrPf4WtJBky6 IACyJ1Qgvs;
Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Subject: [Ietf-calsify] reminder: Calsify call today, 9:30am US/New York. Call information follows below
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jan 2008 12:19:04 -0000
The agenda will be the changes Bernard proposed, as well as (hopefully)
those that Cyrus will have proposed.
Eliot
*
Meeting ID:* 312147852
*Meeting Password:*
*Global Access Numbers:*
*http://cisco.com/en/US/about/doing_business/conferencing/index.html*
* US/Canada:* +1.866.432.9903 * United Kingdom:* +44.20.8824.0117
* India:* +91.80.4103.3979 * Germany:* +49.619.6773.9002
* Japan:* +81.3.5763.9394 * China:* +86.10.8515.5666
*TO ATTEND A WEB AND VOICE CONFERENCE*
*CISCO INTRANET ATTENDEES*
*Join the Web & Voice Conference**
1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
2. Enter your* CEC User ID* &* Password* then click* OK*
- Accept any security warnings you receive and wait for the Meeting Room
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference
portion of the meeting
*EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
*Join the Web & Voice Conference**
1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
2. Fill in the* My Name is* field then click* Attend Meeting*
- If you have a* CEC User ID*, click on the* Cisco icon*
- Accept any security warnings you receive and wait for the Meeting Room
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference
portion of the meeting
-* Note:* Guest users will see a link to the Global Access Numbers.
***If this is your first time attending a Web Conference, disable any
pop-up blockers and visit*
http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to
test your web browser for compatibility with the Web Conference.
****Not all meetings are scheduled to allow external attendees into the
Web Conference portion of the meeting, if the URL does not work, please
follow the Voice only Conference instructions below to attend.
*TO ATTEND A VOICE ONLY CONFERENCE*
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link
above)
2. Press* 1* to attend the meeting
3. Follow the prompts to enter the Meeting ID* 312147852* and join the
meeting
*SUPPORT*
*Information about this Conference:* Contact Eliot Lear, 41448787525
*Cisco IT Support Center:* Attend the Voice Conference and then press #0
on your phone keypad
*GLOBAL ACCESS NUMBERS*
*COUNTRY LOCATION LOCAL NUMBER TOLL
FREE-FREEFONE*
*Algeria * Algiers +213.21.98.9047
*Argentina* Buenos Aires +54.11.4341.0101
*Australia* All Locations +86.16.0643
Canberra +61.2.6216.0643
Melbourne +61.3.9659.4173
North Sydney +61.2.8446.5260
*Austria* Vienna +43.12.4030.6022
*Azerbaijan * Baku +994.12.437.4829
*Belgium* Brussels +32.2.704.5072
*Bosnia & *
*Herzegovina * Sarajevo +387.33.56.2898
*Brazil* Brasilia +55.613.424.0220
Rio de Janeiro +55.21.2483.6302
Sao Paulo +55.11.5508.6311
*Bulgaria* Sofia +359.2.937.5938
*Canada* Calgary +1.403.514.2435
Edmonton +1.780.441.3715
Halifax +1.902.474.0214
Kanata +1.613.254.0005
Markham +1.905.470.4810
Montreal +1.514.847.6875
Ottawa +1.613.788.7250
Quebec +1.418.634.5645
Regina +1.306.566.6410
Toronto +1.416.306.7230
Vancouver +1.604.647.2350
Winnipeg +1.204.336.6610
*Chile* Santiago +56.2.431.4936
*China* Beijing +86.10.8515.5666
Chengdu +86.28.8696.1333
Guangzhou +86.20.8519.3333
Shanghai +86.21.2302.4333
*Colombia* Bogota +57.1.325.6065
*Costa Rica * San Jose +506.201.3617
*Croatia* Zagreb +385.1.462.8908
*Czech Republic * Prague +420.22.143.5100
*Denmark* Aabyhoj +45.8.939.7131
Copenhagen +45.3.958.5010
*Dominican Republic* Santo Domingo +45.8.939.7131
*Egypt * Cairo +20.22.488.5377
*Estonia * Tallinn +372.6.67.5998
*Finland* Espoo +358.204.70.6227
*France* Paris +33.15.804.3116
*Germany* Eschborn +49.619.6773.9002
Hallbergmoos +49.811.554.3016
*Greece* Athens +30.210.638.1303
*Hong Kong* Hong Kong +852.3406.1000
*Hungary* Budapest +36.1.225.4621
*India* Bangalore +91.80.4103.3979
Chennai
+1.800.102.3979
Mumbai IL & FS +91.22.4043.4030
New Delhi +91.11.4261.1088
*Indonesia* Jakarta +62.21.7854.7476
*Ireland* Dublin +353.1.819.2717
*Israel* Netanya +972.9.892.7026
*Italy * Milan +39.039.629.5068
Rome +39.06.5164.4006
*Japan* Tokyo Akasaka +81.3.5763.9394
+0120.312271
*Kazakhstan* Almaty +7.327.244.2198
*Korea* Seoul Asem +82.2.3429.8102
*Latvia* Please see Finland
Number
*Lebanon* Beirut +961.1.97.7011
*Malaysia* Kuala Lumpur +60.3.2081.1515
Penang +60.4.631.5125
*Mexico* Mexico City +52.55.5267.1800
Monterrey +52.81.8221.2462
Guadalajara +52.33.3770.1206
*Morocco * Casablanca +212.2.242.4088
*Netherlands * Amsterdam +31.20.357.1487
*New Zealand* Auckland +64.9.355.1968
Wellington +64.4.496.5554
*Nigeria* Lagos +234.1.462.1048
*Norway* Oslo +47.23.27.3647
*Pakistan* Islamabad +92.51.209.7994
*Peru * Lima +51.1.215.5101
*Philippines * Makati (Manila) +63.2.750.5886
*Poland* Warsaw +48.22.572.2615
*Portugal* Lisbon +351.21.446.8756
*Puerto Rico* San Juan +1.787.620.1865
*Romania* Bucharest +40.21.302.3511
*Russia* Moscow +7.495.230.5612
*Saudi Arabia* Dhahran +966.3.865.7998
Jeddah +966.2.653.6555
Riyadh +966.1.218.2666
*Serbia* Belgrade +381.11.209.2098
*Singapore* Singapore Capital +65.6317.7088
*Slovakia* Bratislava +421.2.5825.5309
*Slovenia* Ljubljana +386.1.582.3158
*South Africa* Cape Town +27.21.413.4502
Johannesburg +27.11.267.1011
Pretoria +27.12.844.7401
*Spain* Barcelona +34.93.393.4037
Madrid +34.91.201.2149
*Sweden* Gothenburg +46.31.63.4409
Stockholm +46.8.685.9035
*Switzerland* Glattzentrum +41.44.878.7335
*Taiwan* Taipei +886.2.8758.7088
*Thailand* Bangkok +66.2.263.7008
*Turkey* Istanbul +90.212.335.0208
*Ukraine* Kiev +380.44.391.3698
*United Arab *
*Emirates(UAE) * Dubai +971.4.390.7840
*United Kingdom* Bedfont Lakes +44.20.8824.0117
Edinburgh +44.131.561.3643
London City +44.20.7496.3743
*United States* East +1.919.392.3330
+1.866.349.3520
West +1.408.525.6800
+1.866.432.9903
*Venezuela* Caracas +58.212.902.0210
*Vietnam* Ho Chi Minh +84.8.823.3418
City (Saigon)
Hanoi +84.4.974.6250
Return-Path: <bernard.desruisseaux@oracle.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EE66580B6B for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 19:02:24 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5D08F142213 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 19:02:27 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-50 required=4 tests=[AWL=0.250, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnVIKRkJd-1z for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 19:02:23 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9106514220C for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 19:02:21 -0800 (PST)
Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m0B32Fhh025502 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 21:02:15 -0600
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m0AC6b3l019218 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 20:02:14 -0700
Received: from dhcp-amer-rmdc-csvpn-gw5-141-144-107-31.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3491955111200020473; Thu, 10 Jan 2008 19:01:13 -0800
Message-ID: <4786DBF5.6000508@oracle.com>
Date: Thu, 10 Jan 2008 22:01:09 -0500
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Calsify WG <ietf-calsify@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Subject: [Ietf-calsify] Issue 48: Section 4.2.13 Recurrence Identifier Range
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jan 2008 03:02:25 -0000
Back in October 2006, we decided to deprecate the RANGE parameter
from iCalendar. See:
http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001239.html
http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue48
As we found out, it is hard to do without RANGE=THISANDFUTURE
with unbounded recurring calendar components when the Organizer
wants to modify all future instances, or when an Attendee wants
to modify his participation status to all future instances.
Here's a proposal along the lines of what was discussed at the
last IETF meeting in Vancouver.
- Revert the change to deprecate the RANGE parameter.
- Only the THISANDPRIOR value would be deprecated.
- Clarify that THISANDFUTURE is based on RECURRENCE-ID
values and not the current value of DTSTART.
- Clarify that exception components have precedence
over THISANDFUTURE.
- Clarify that when the recurrence instance specified with
RANGE=THISANDFUTURE is rescheduled, that all future recurrence
instances ends up being rescheduled "the same way". For
instance, if the recurrence instance specified with
RANGE=THISANDFUTURE is rescheduled to start 2 hours later
then all future instances will also be rescheduled to start
2 hours later. Similarly, if the duration of the recurrence
instance specified with RANGE=THISANDFUTURE is modified then
all future recurrence instances should be changed to have this
new duration.
Obviously, there will be cases where this approach will not be
sufficient to reschedule all future instances exactly like the
end user wants. Let's take the case of a recurrence meeting
scheduled to occur on Monday and Wednesday for ever. At some
point the Organizer decides to reschedule all future Wednesday
instances to occur on Thursday instead. With the approach
mentioned above this is not possible, since all future
instances (i.e., including the Monday instances) would end up
being rescheduled to start 24 hours later (i.e., the Monday
instances would be rescheduled on Tuesday). In such situations
the calendar application should truncate the unbounded
recurring calendar components and create a new unbounded
recurring calendar components for the future instances.
Cheers,
Bernard
Return-Path: <thnetila@kerio.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EA1AF80902 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 09:09:53 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 578F9142203 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 09:09:56 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-50 required=4 tests=[AWL=0.478, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLzIak0vBVGQ for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 09:09:52 -0800 (PST)
Received: from stoupa.kerio.com (stoupa.kerio.com [195.113.184.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5775A1421EB for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 09:09:52 -0800 (PST)
Received: from [192.168.5.21] ([195.113.184.99]) (authenticated user thnetila@kerio.com) by stoupa.kerio.com (Kerio MailServer 6.5.0 rc 1) (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 10 Jan 2008 18:09:44 +0100
Message-Id: <B55C0041-BC87-4A0F-A264-F8F9A9D2EDC5@kerio.com>
From: Tomas Hnetila <thnetila@kerio.com>
To: Eliot Lear <lear@cisco.com>
In-Reply-To: <477CEB65.2060406@cisco.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-1-486966204
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [Ietf-calsify] preliminary minutes
Date: Thu, 10 Jan 2008 18:09:41 +0100
References: <477CEB65.2060406@cisco.com>
X-Mailer: Apple Mail (2.915)
Cc: ietf-calsify@osafoundation.org
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2008 17:09:54 -0000
--Apple-Mail-1-486966204
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit
Hi Eliot,
We currently doesn't officially support counter/decline-counter
methods exactly as it defined in RFC in Kerio MailServer, but our
intention improve it to be in conformance with the RFC.
"Propose new time" function is supported by Microsoft Outlook and
Windows Mobile (ActiveSync) devices.
This function is very useful for busy people who uses calendaring
product often. I recommend to keep counter methode in RFC.
Tom
On Jan 3, 2008, at 3:04 PM, Eliot Lear wrote:
>
> Issue #87
> Eliot queried how many clients support counter/decline-counter,
> and there seem to be at least some. There was no consensus to
> remove, and so the issue is rejected.
--Apple-Mail-1-486966204
Content-Type: text/html;
charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>Hi Eliot,</div><div><br =
class=3D"webkit-block-placeholder"></div><div>We currently doesn=
't officially support =
counter/decline-counter methods exactly as it defined in =
RFC in Kerio MailServer, but our intention improve it to be in =
conformance with the RFC.</div><div>"Propose new time" function is =
supported by Microsoft Outlook and Windows Mobile (ActiveSync) =
devices.</div><div><br></div><div>This function is very useful for busy =
people who uses calendaring product often. I recommend to keep counter =
methode in RFC.</div><div><br></div><div>Tom</div><div><br =
class=3D"webkit-block-placeholder"></div><div><br></div><div><div>On Jan =
3, 2008, at 3:04 PM, Eliot Lear wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><br> Issue =
#87<br> Eliot queried how many clients support =
counter/decline-counter,<br> and there seem to be at =
least some. There was no consensus to<br> remove, =
and so the issue is =
rejected.</span></blockquote></div><br></body></html>=
--Apple-Mail-1-486966204--
Return-Path: <lear@cisco.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D22ED7F513 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 01:19:34 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 426B4142765 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 01:19:37 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-50 required=4 tests=[AWL=0.489, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gR7mNmMNlA2 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 01:19:31 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id BFD3F142203 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 01:19:30 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,265,1196636400"; d="scan'208";a="2627732"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2008 10:19:17 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0A9JGcg007164 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 10:19:16 +0100
Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4367.cisco.com [10.61.81.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0A9JGWs010156 for <ietf-calsify@osafoundation.org>; Thu, 10 Jan 2008 09:19:16 GMT
Message-ID: <4785E314.4050008@cisco.com>
Date: Thu, 10 Jan 2008 10:19:16 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org" <ietf-calsify@osafoundation.org>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=386; t=1199956757; x=1200820757; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20no=20quorum=20for=20yesterday's=20call |Sender:=20; bh=hFpxYpaDJKtkLpTetd4ZZcA12d0wyX7mPLdvrp5MeH8=; b=O7gUpn1yZ4F6GwPPwA/j/4K83ssBsNF5F4MeRXt3DCyDib1vicuXnstIeM Br32wqhNxvdJ0bURdPxKsfnUd+NVPmtgf65SJm5G55F3DLcKq3CWiyXnAgFn 42VP+E4b/R;
Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Subject: [Ietf-calsify] no quorum for yesterday's call
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2008 09:19:35 -0000
Dear all,
As yesterday's call was very small (4 people) we decided to put off any
substantial discussions. You can expect proposals from Bernard and
Cyrus on issues relating to their drafts within the week. These calls
are meant to be weekly, and so we will have another one next Wednesday,
9:30am America/New York. I will put out an iCal invite sometime today.
Eliot
Return-Path: <lear@cisco.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1F5857FB12 for <ietf-calsify@osafoundation.org>; Wed, 9 Jan 2008 06:29:15 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7CF4A142201 for <ietf-calsify@osafoundation.org>; Wed, 9 Jan 2008 06:29:17 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.974
X-Spam-Level:
X-Spam-Status: No, score=-1.974 tagged_above=-50 required=4 tests=[AWL=0.491, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuBOpS30erQK for <ietf-calsify@osafoundation.org>; Wed, 9 Jan 2008 06:29:13 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id E8F6B142254 for <ietf-calsify@osafoundation.org>; Wed, 9 Jan 2008 06:29:12 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,262,1196636400"; d="scan'208";a="2565985"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jan 2008 15:29:09 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m09ET8Dq031050 for <ietf-calsify@osafoundation.org>; Wed, 9 Jan 2008 15:29:08 +0100
Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp935.cisco.com [10.61.67.167]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m09ET7Ws003108 for <ietf-calsify@osafoundation.org>; Wed, 9 Jan 2008 14:29:08 GMT
Message-ID: <4784DA32.5000701@cisco.com>
Date: Wed, 09 Jan 2008 15:29:06 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org" <ietf-calsify@osafoundation.org>
X-Enigmail-Version: 0.95.6
Content-Type: multipart/mixed; boundary="------------040701020007000003030308"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15249; t=1199888948; x=1200752948; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20reminder=3A=20calsify=20call=20now!! |Sender:=20; bh=pzqf9eesmQ3MeCYin8xvFso7HSRsMfHuTk3HIYwt0Do=; b=qFsObjNyO48h2+y/wDyFx+s4ppJ500RqetaudqtIkTY1Hr/Q2ctj+11Z/X JEVmevTLAJkUmLKyeN+ZlTXNGLuFw473TmpxiwN1S1/3qrhmh9ugBkI8SLqU ujC/75XkSb;
Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
Subject: [Ietf-calsify] reminder: calsify call now!!
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2008 14:29:15 -0000
This is a multi-part message in MIME format.
--------------040701020007000003030308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
--------------040701020007000003030308
Content-Type: message/rfc822;
name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Attached Message"
Received: from xbh-ams-331.emea.cisco.com ([144.254.231.71]) by
xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 7 Jan 2008 13:30:08 +0100
Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by
xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 7 Jan 2008 13:30:08 +0100
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by
xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 7 Jan 2008 04:30:03 -0800
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
by sj-iport-6.cisco.com with ESMTP; 07 Jan 2008 04:29:58 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m07CTwWl017915;
Mon, 7 Jan 2008 04:29:58 -0800
Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com
[128.107.234.205])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m07CTgHK007724;
Mon, 7 Jan 2008 12:29:58 GMT
X-from-outside-Cisco: 204.152.186.93
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAANupgUfMmLpdn2dsb2JhbACBWI48AQEBAQcKCSCBFJEahCs
X-IronPort-AV: E=Sophos;i="4.24,253,1196668800";
d="scan'208";a="9274562"
Received: from leilani.osafoundation.org ([204.152.186.93])
by sj-inbound-b.cisco.com with ESMTP; 07 Jan 2008 04:29:56 -0800
Received: from leilani.osafoundation.org (leilani.osafoundation.org
[127.0.0.1])
by leilani.osafoundation.org (Postfix) with ESMTP id 389B780AF4;
Mon, 7 Jan 2008 04:29:52 -0800 (PST)
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org
[204.152.186.98])
by leilani.osafoundation.org (Postfix) with ESMTP id 2256880A69
for <ietf-calsify@osafoundation.org>;
Mon, 7 Jan 2008 04:29:51 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1])
by laweleka.osafoundation.org (Postfix) with ESMTP id 703B714229D
for <ietf-calsify@osafoundation.org>;
Mon, 7 Jan 2008 04:29:53 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-50 required=4 tests=[AWL=-0.813,
BAYES_50=0.001, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1])
by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id 1yljd-O1T7hm for <ietf-calsify@osafoundation.org>;
Mon, 7 Jan 2008 04:29:49 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140])
by laweleka.osafoundation.org (Postfix) with ESMTP id DD77D14220C
for <ietf-calsify@osafoundation.org>;
Mon, 7 Jan 2008 04:29:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,253,1196636400";
d="scan'208";a="2320395"
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
by ams-iport-1.cisco.com with ESMTP; 07 Jan 2008 13:29:45 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m07CTidX015589
for <ietf-calsify@osafoundation.org>; Mon, 7 Jan 2008 13:29:45 +0100
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp584.cisco.com
[10.61.66.72])
by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m07CTiBF020023
for <ietf-calsify@osafoundation.org>; Mon, 7 Jan 2008 12:29:44 GMT
Message-ID: <47821B38.4080305@cisco.com>
Date: Mon, 07 Jan 2008 13:29:44 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org" <ietf-calsify@osafoundation.org>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9197; t=1199708985;
x=1200572985; c=relaxed/simple; s=amsdkim2001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=lear@cisco.com;
z=From:=20Eliot=20Lear=20<lear@cisco.com>
|Subject:=20reminder=3A=20phone=20call=20january=209,=209=3
A30am=20EST=20=20/=203=3A30pm=20CET |Sender:=20;
bh=UVALOvNaBo4aDZ0ItkT75+P8Y227Z0nHjJXoyeQCvkk=;
b=AH9qd50WoP8hgVmg0vcuUtLaq9sYQZwbu0Uwyp6ohZkgKXTbMO6zNEQir7
hEZq9B/fkMYYXd+FE0RymvdSNLaZsKfGwRb/TVR9U3a/lfmLjgfBlD0fWxsB
TPfEzSELba;
Authentication-Results: sj-dkim-4; header.From=lear@cisco.com; dkim=pass (
sig from cisco.com/amsdkim2001 verified; );
Subject: [Ietf-calsify] reminder: phone call january 9,
9:30am EST / 3:30pm CET
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,
<mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,
<mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
Sender: ietf-calsify-bounces@osafoundation.org
Errors-To: ietf-calsify-bounces@osafoundation.org
Return-Path: ietf-calsify-bounces@osafoundation.org
X-OriginalArrivalTime: 07 Jan 2008 12:30:03.0355 (UTC)
FILETIME=[070842B0:01C85129]
The agenda will be to go over remaining items in iTIP. Here is the
call-in information:
*Eliot Lear has invited you to a Cisco Unified MeetingPlace Conference*
*Date/Time:* January 09, 2008 at 03:30PM Europe/Amsterdam
*Length:* 70
*Frequency:* This meeting is scheduled to occur every
Wednesday for 6 weeks.
*Meeting ID:* 312147852
*Meeting Password:*
*Global Access Numbers:*
*http://cisco.com/en/US/about/doing_business/conferencing/index.html*
* US/Canada:* +1.866.432.9903 * United Kingdom:* +44.20.8824.0117
* India:* +91.80.4103.3979 * Germany:* +49.619.6773.9002
* Japan:* +81.3.5763.9394 * China:* +86.10.8515.5666
*TO ATTEND A WEB AND VOICE CONFERENCE*
*CISCO INTRANET ATTENDEES*
*Join the Web & Voice Conference**
1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
2. Enter your* CEC User ID* &* Password* then click* OK*
- Accept any security warnings you receive and wait for the Meeting Room
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference
portion of the meeting
*EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
*Join the Web & Voice Conference**
1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
2. Fill in the* My Name is* field then click* Attend Meeting*
- If you have a* CEC User ID*, click on the* Cisco icon*
- Accept any security warnings you receive and wait for the Meeting Room
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference
portion of the meeting
-* Note:* Guest users will see a link to the Global Access Numbers.
***If this is your first time attending a Web Conference, disable any
pop-up blockers and visit*
http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to
test your web browser for compatibility with the Web Conference.
****Not all meetings are scheduled to allow external attendees into the
Web Conference portion of the meeting, if the URL does not work, please
follow the Voice only Conference instructions below to attend.
*TO ATTEND A VOICE ONLY CONFERENCE*
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link
above)
2. Press* 1* to attend the meeting
3. Follow the prompts to enter the Meeting ID* 312147852* and join the
meeting
*SUPPORT*
*Information about this Conference:* Contact Eliot Lear, 41448787525
*Cisco IT Support Center:* Attend the Voice Conference and then press #0
on your phone keypad
*GLOBAL ACCESS NUMBERS*
*COUNTRY LOCATION LOCAL NUMBER TOLL
FREE-FREEFONE*
*Algeria * Algiers +213.21.98.9047
*Argentina* Buenos Aires +54.11.4341.0101
*Australia* All Locations +86.16.0643
Canberra +61.2.6216.0643
Melbourne +61.3.9659.4173
North Sydney +61.2.8446.5260
*Austria* Vienna +43.12.4030.6022
*Azerbaijan * Baku +994.12.437.4829
*Belgium* Brussels +32.2.704.5072
*Bosnia & *
*Herzegovina * Sarajevo +387.33.56.2898
*Brazil* Brasilia +55.613.424.0220
Rio de Janeiro +55.21.2483.6302
Sao Paulo +55.11.5508.6311
*Bulgaria* Sofia +359.2.937.5938
*Canada* Calgary +1.403.514.2435
Edmonton +1.780.441.3715
Halifax +1.902.474.0214
Kanata +1.613.254.0005
Markham +1.905.470.4810
Montreal +1.514.847.6875
Ottawa +1.613.788.7250
Quebec +1.418.634.5645
Regina +1.306.566.6410
Toronto +1.416.306.7230
Vancouver +1.604.647.2350
Winnipeg +1.204.336.6610
*Chile* Santiago +56.2.431.4936
*China* Beijing +86.10.8515.5666
Chengdu +86.28.8696.1333
Guangzhou +86.20.8519.3333
Shanghai +86.21.2302.4333
*Colombia* Bogota +57.1.325.6065
*Costa Rica * San Jose +506.201.3617
*Croatia* Zagreb +385.1.462.8908
*Czech Republic * Prague +420.22.143.5100
*Denmark* Aabyhoj +45.8.939.7131
Copenhagen +45.3.958.5010
*Dominican Republic* Santo Domingo +45.8.939.7131
*Egypt * Cairo +20.22.488.5377
*Estonia * Tallinn +372.6.67.5998
*Finland* Espoo +358.204.70.6227
*France* Paris +33.15.804.3116
*Germany* Eschborn +49.619.6773.9002
Hallbergmoos +49.811.554.3016
*Greece* Athens +30.210.638.1303
*Hong Kong* Hong Kong +852.3406.1000
*Hungary* Budapest +36.1.225.4621
*India* Bangalore +91.80.4103.3979
Chennai
+1.800.102.3979
Mumbai IL & FS +91.22.4043.4030
New Delhi +91.11.4261.1088
*Indonesia* Jakarta +62.21.7854.7476
*Ireland* Dublin +353.1.819.2717
*Israel* Netanya +972.9.892.7026
*Italy * Milan +39.039.629.5068
Rome +39.06.5164.4006
*Japan* Tokyo Akasaka +81.3.5763.9394
+0120.312271
*Kazakhstan* Almaty +7.327.244.2198
*Korea* Seoul Asem +82.2.3429.8102
*Latvia* Please see Finland
Number
*Lebanon* Beirut +961.1.97.7011
*Malaysia* Kuala Lumpur +60.3.2081.1515
Penang +60.4.631.5125
*Mexico* Mexico City +52.55.5267.1800
Monterrey +52.81.8221.2462
Guadalajara +52.33.3770.1206
*Morocco * Casablanca +212.2.242.4088
*Netherlands * Amsterdam +31.20.357.1487
*New Zealand* Auckland +64.9.355.1968
Wellington +64.4.496.5554
*Nigeria* Lagos +234.1.462.1048
*Norway* Oslo +47.23.27.3647
*Pakistan* Islamabad +92.51.209.7994
*Peru * Lima +51.1.215.5101
*Philippines * Makati (Manila) +63.2.750.5886
*Poland* Warsaw +48.22.572.2615
*Portugal* Lisbon +351.21.446.8756
*Puerto Rico* San Juan +1.787.620.1865
*Romania* Bucharest +40.21.302.3511
*Russia* Moscow +7.495.230.5612
*Saudi Arabia* Dhahran +966.3.865.7998
Jeddah +966.2.653.6555
Riyadh +966.1.218.2666
*Serbia* Belgrade +381.11.209.2098
*Singapore* Singapore Capital +65.6317.7088
*Slovakia* Bratislava +421.2.5825.5309
*Slovenia* Ljubljana +386.1.582.3158
*South Africa* Cape Town +27.21.413.4502
Johannesburg +27.11.267.1011
Pretoria +27.12.844.7401
*Spain* Barcelona +34.93.393.4037
Madrid +34.91.201.2149
*Sweden* Gothenburg +46.31.63.4409
Stockholm +46.8.685.9035
*Switzerland* Glattzentrum +41.44.878.7335
*Taiwan* Taipei +886.2.8758.7088
*Thailand* Bangkok +66.2.263.7008
*Turkey* Istanbul +90.212.335.0208
*Ukraine* Kiev +380.44.391.3698
*United Arab *
*Emirates(UAE) * Dubai +971.4.390.7840
*United Kingdom* Bedfont Lakes +44.20.8824.0117
Edinburgh +44.131.561.3643
London City +44.20.7496.3743
*United States* East +1.919.392.3330
+1.866.349.3520
West +1.408.525.6800
+1.866.432.9903
*Venezuela* Caracas +58.212.902.0210
*Vietnam* Ho Chi Minh +84.8.823.3418
City (Saigon)
Hanoi +84.4.974.6250
Microsoft Outlook Web Access:
http://email.cisco.com/exchange/elear/Inbox/Meeting%3A%20IETF%20Calsify%20%7BMeeting%20ID%3A%20312147852%7D.EML?cmd=open
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
--------------040701020007000003030308--
Return-Path: <lear@cisco.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2256880A69 for <ietf-calsify@osafoundation.org>; Mon, 7 Jan 2008 04:29:51 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 703B714229D for <ietf-calsify@osafoundation.org>; Mon, 7 Jan 2008 04:29:53 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-50 required=4 tests=[AWL=-0.813, BAYES_50=0.001, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yljd-O1T7hm for <ietf-calsify@osafoundation.org>; Mon, 7 Jan 2008 04:29:49 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id DD77D14220C for <ietf-calsify@osafoundation.org>; Mon, 7 Jan 2008 04:29:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,253,1196636400"; d="scan'208";a="2320395"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2008 13:29:45 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m07CTidX015589 for <ietf-calsify@osafoundation.org>; Mon, 7 Jan 2008 13:29:45 +0100
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp584.cisco.com [10.61.66.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m07CTiBF020023 for <ietf-calsify@osafoundation.org>; Mon, 7 Jan 2008 12:29:44 GMT
Message-ID: <47821B38.4080305@cisco.com>
Date: Mon, 07 Jan 2008 13:29:44 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org" <ietf-calsify@osafoundation.org>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9197; t=1199708985; x=1200572985; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20reminder=3A=20phone=20call=20january=209,=209=3 A30am=20EST=20=20/=203=3A30pm=20CET |Sender:=20; bh=UVALOvNaBo4aDZ0ItkT75+P8Y227Z0nHjJXoyeQCvkk=; b=AH9qd50WoP8hgVmg0vcuUtLaq9sYQZwbu0Uwyp6ohZkgKXTbMO6zNEQir7 hEZq9B/fkMYYXd+FE0RymvdSNLaZsKfGwRb/TVR9U3a/lfmLjgfBlD0fWxsB TPfEzSELba;
Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Subject: [Ietf-calsify] reminder: phone call january 9, 9:30am EST / 3:30pm CET
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2008 12:29:51 -0000
The agenda will be to go over remaining items in iTIP. Here is the
call-in information:
*Eliot Lear has invited you to a Cisco Unified MeetingPlace Conference*
*Date/Time:* January 09, 2008 at 03:30PM Europe/Amsterdam
*Length:* 70
*Frequency:* This meeting is scheduled to occur every
Wednesday for 6 weeks.
*Meeting ID:* 312147852
*Meeting Password:*
*Global Access Numbers:*
*http://cisco.com/en/US/about/doing_business/conferencing/index.html*
* US/Canada:* +1.866.432.9903 * United Kingdom:* +44.20.8824.0117
* India:* +91.80.4103.3979 * Germany:* +49.619.6773.9002
* Japan:* +81.3.5763.9394 * China:* +86.10.8515.5666
*TO ATTEND A WEB AND VOICE CONFERENCE*
*CISCO INTRANET ATTENDEES*
*Join the Web & Voice Conference**
1. Go to* http://meetingplaceinternal.cisco.com/join.asp?312147852*
2. Enter your* CEC User ID* &* Password* then click* OK*
- Accept any security warnings you receive and wait for the Meeting Room
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference
portion of the meeting
*EXTERNAL ATTENDEES* -* Outside the Cisco Intranet***
*Join the Web & Voice Conference**
1. Go to* http://meetingplace.cisco.com/join.asp?312147852*
2. Fill in the* My Name is* field then click* Attend Meeting*
- If you have a* CEC User ID*, click on the* Cisco icon*
- Accept any security warnings you receive and wait for the Meeting Room
to initialize
3. Click on* CONNECT* from the Meeting Room to join the Voice Conference
portion of the meeting
-* Note:* Guest users will see a link to the Global Access Numbers.
***If this is your first time attending a Web Conference, disable any
pop-up blockers and visit*
http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp* to
test your web browser for compatibility with the Web Conference.
****Not all meetings are scheduled to allow external attendees into the
Web Conference portion of the meeting, if the URL does not work, please
follow the Voice only Conference instructions below to attend.
*TO ATTEND A VOICE ONLY CONFERENCE*
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link
above)
2. Press* 1* to attend the meeting
3. Follow the prompts to enter the Meeting ID* 312147852* and join the
meeting
*SUPPORT*
*Information about this Conference:* Contact Eliot Lear, 41448787525
*Cisco IT Support Center:* Attend the Voice Conference and then press #0
on your phone keypad
*GLOBAL ACCESS NUMBERS*
*COUNTRY LOCATION LOCAL NUMBER TOLL
FREE-FREEFONE*
*Algeria * Algiers +213.21.98.9047
*Argentina* Buenos Aires +54.11.4341.0101
*Australia* All Locations +86.16.0643
Canberra +61.2.6216.0643
Melbourne +61.3.9659.4173
North Sydney +61.2.8446.5260
*Austria* Vienna +43.12.4030.6022
*Azerbaijan * Baku +994.12.437.4829
*Belgium* Brussels +32.2.704.5072
*Bosnia & *
*Herzegovina * Sarajevo +387.33.56.2898
*Brazil* Brasilia +55.613.424.0220
Rio de Janeiro +55.21.2483.6302
Sao Paulo +55.11.5508.6311
*Bulgaria* Sofia +359.2.937.5938
*Canada* Calgary +1.403.514.2435
Edmonton +1.780.441.3715
Halifax +1.902.474.0214
Kanata +1.613.254.0005
Markham +1.905.470.4810
Montreal +1.514.847.6875
Ottawa +1.613.788.7250
Quebec +1.418.634.5645
Regina +1.306.566.6410
Toronto +1.416.306.7230
Vancouver +1.604.647.2350
Winnipeg +1.204.336.6610
*Chile* Santiago +56.2.431.4936
*China* Beijing +86.10.8515.5666
Chengdu +86.28.8696.1333
Guangzhou +86.20.8519.3333
Shanghai +86.21.2302.4333
*Colombia* Bogota +57.1.325.6065
*Costa Rica * San Jose +506.201.3617
*Croatia* Zagreb +385.1.462.8908
*Czech Republic * Prague +420.22.143.5100
*Denmark* Aabyhoj +45.8.939.7131
Copenhagen +45.3.958.5010
*Dominican Republic* Santo Domingo +45.8.939.7131
*Egypt * Cairo +20.22.488.5377
*Estonia * Tallinn +372.6.67.5998
*Finland* Espoo +358.204.70.6227
*France* Paris +33.15.804.3116
*Germany* Eschborn +49.619.6773.9002
Hallbergmoos +49.811.554.3016
*Greece* Athens +30.210.638.1303
*Hong Kong* Hong Kong +852.3406.1000
*Hungary* Budapest +36.1.225.4621
*India* Bangalore +91.80.4103.3979
Chennai
+1.800.102.3979
Mumbai IL & FS +91.22.4043.4030
New Delhi +91.11.4261.1088
*Indonesia* Jakarta +62.21.7854.7476
*Ireland* Dublin +353.1.819.2717
*Israel* Netanya +972.9.892.7026
*Italy * Milan +39.039.629.5068
Rome +39.06.5164.4006
*Japan* Tokyo Akasaka +81.3.5763.9394
+0120.312271
*Kazakhstan* Almaty +7.327.244.2198
*Korea* Seoul Asem +82.2.3429.8102
*Latvia* Please see Finland
Number
*Lebanon* Beirut +961.1.97.7011
*Malaysia* Kuala Lumpur +60.3.2081.1515
Penang +60.4.631.5125
*Mexico* Mexico City +52.55.5267.1800
Monterrey +52.81.8221.2462
Guadalajara +52.33.3770.1206
*Morocco * Casablanca +212.2.242.4088
*Netherlands * Amsterdam +31.20.357.1487
*New Zealand* Auckland +64.9.355.1968
Wellington +64.4.496.5554
*Nigeria* Lagos +234.1.462.1048
*Norway* Oslo +47.23.27.3647
*Pakistan* Islamabad +92.51.209.7994
*Peru * Lima +51.1.215.5101
*Philippines * Makati (Manila) +63.2.750.5886
*Poland* Warsaw +48.22.572.2615
*Portugal* Lisbon +351.21.446.8756
*Puerto Rico* San Juan +1.787.620.1865
*Romania* Bucharest +40.21.302.3511
*Russia* Moscow +7.495.230.5612
*Saudi Arabia* Dhahran +966.3.865.7998
Jeddah +966.2.653.6555
Riyadh +966.1.218.2666
*Serbia* Belgrade +381.11.209.2098
*Singapore* Singapore Capital +65.6317.7088
*Slovakia* Bratislava +421.2.5825.5309
*Slovenia* Ljubljana +386.1.582.3158
*South Africa* Cape Town +27.21.413.4502
Johannesburg +27.11.267.1011
Pretoria +27.12.844.7401
*Spain* Barcelona +34.93.393.4037
Madrid +34.91.201.2149
*Sweden* Gothenburg +46.31.63.4409
Stockholm +46.8.685.9035
*Switzerland* Glattzentrum +41.44.878.7335
*Taiwan* Taipei +886.2.8758.7088
*Thailand* Bangkok +66.2.263.7008
*Turkey* Istanbul +90.212.335.0208
*Ukraine* Kiev +380.44.391.3698
*United Arab *
*Emirates(UAE) * Dubai +971.4.390.7840
*United Kingdom* Bedfont Lakes +44.20.8824.0117
Edinburgh +44.131.561.3643
London City +44.20.7496.3743
*United States* East +1.919.392.3330
+1.866.349.3520
West +1.408.525.6800
+1.866.432.9903
*Venezuela* Caracas +58.212.902.0210
*Vietnam* Ho Chi Minh +84.8.823.3418
City (Saigon)
Hanoi +84.4.974.6250
Microsoft Outlook Web Access:
http://email.cisco.com/exchange/elear/Inbox/Meeting%3A%20IETF%20Calsify%20%7BMeeting%20ID%3A%20312147852%7D.EML?cmd=open
Return-Path: <lear@cisco.com>
X-Original-To: ietf-calsify@osafoundation.org
Delivered-To: ietf-calsify@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A8F407F8C4 for <ietf-calsify@osafoundation.org>; Thu, 3 Jan 2008 06:04:27 -0800 (PST)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F2E33142207 for <ietf-calsify@osafoundation.org>; Thu, 3 Jan 2008 06:04:29 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.973
X-Spam-Level:
X-Spam-Status: No, score=-1.973 tagged_above=-50 required=4 tests=[AWL=0.492, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNvL6X+C3gsW for <ietf-calsify@osafoundation.org>; Thu, 3 Jan 2008 06:04:26 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 09F1B142203 for <ietf-calsify@osafoundation.org>; Thu, 3 Jan 2008 06:04:25 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.24,239,1196636400"; d="scan'208";a="2110304"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jan 2008 15:04:22 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m03E4MCj009202 for <ietf-calsify@osafoundation.org>; Thu, 3 Jan 2008 15:04:22 +0100
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp342.cisco.com [10.61.65.86]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m03E4LBF013359 for <ietf-calsify@osafoundation.org>; Thu, 3 Jan 2008 14:04:22 GMT
Message-ID: <477CEB65.2060406@cisco.com>
Date: Thu, 03 Jan 2008 15:04:21 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: "ietf-calsify@osafoundation.org" <ietf-calsify@osafoundation.org>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2761; t=1199369062; x=1200233062; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20preliminary=20minutes |Sender:=20; bh=izrdtj2Xxl3CtI3InnK9jjQW1660rnuteFsJWOsghj8=; b=DJg1F/Ejk1evHyBFxkt7Rs0Vss0/okJeoEtOobv4n/xK/vlWuYqT+Sfj3u LO2C0Wv5znJ2rFxFH5dtYHcD3lWB0zH2i3ssQauZqktQOzrQiqvl9f1JmTSV 9Sc6dDlPt/;
Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Subject: [Ietf-calsify] preliminary minutes
X-BeenThere: ietf-calsify@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:ietf-calsify@osafoundation.org>
List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jan 2008 14:04:27 -0000
Thanks to Kurt for taking notes. Please send comments to the list.
The Calsify WG met at the IETF meeting in Vancouver on December 3rd,
2007. We started off with a status on rfc2445bis, which was that it
was in Shepherd review (that review is now completed). The chairs
have recommitted to working with the authors to get these documents
done. That will require interim phone calls. We announced voice
meetings that will take place on Wednesdays, 9:30am, US/Eastern
starting next week. If you wish to participate, please RSVP to Eliot.
Below are preliminary and rough minutes courtesy of Kurt. Please
comment now about the discussion. Note that Cyrus' slides are
available online at the IETF web site.
iTIP - Cyrus
Provided summary of issues (no significant concerns to presentation
unless noted).
Issue #85
This issue boils down to whether we can manage with unbounded
ranges, and the answer today seemed to be that we cannot manage with
unbounded ranges. The working group discussed reintroducing
"THISANDFUTURE". Cyrus and Bernard are to propose text.
Issue #86
There was a lengthy discussion as to whether incrementing or not
incrementing the SEQUENCE number meant anything from a UI
perspective. Cyrus pointed out that the client really needs to
compare all details and make an appropriate determination. The
chairs note that there is not consensus at this point to remove
SEQUENCE, however. Pete Resnick pointed out that we need to
separate "nagging the user" from notice to the organizer.
Bernard pointed out that we need SEQUENCE to keep track of
out-of-order messages. Cyrus to offer proposal.
Issue #87
Eliot queried how many clients support counter/decline-counter,
and there seem to be at least some. There was no consensus to
remove, and so the issue is rejected.
Issue #90
Eliot: defer until resolution of Issue#85
More range= discussion.
Eliot: no firm proposal, assume range is back, cyrus should
propose text else close.
Issue #95
Issue seems to revolve around precedence (presently not specified)
of error codes. Resolution: Cyrus will propose solution
Issue #67
Resolution: remove statement (no objections in room)
Cyrus summarized removed xrole and removed references to procedural
alarms in iTIP I-D, no concerns from room.
Bernard at mic regarding Issue 63
Bernard: made proposal on list
Eliot: there was an objection made on the list, no consensus at present.
Cyrus: simple solution would be status quo.
Bernard: will think about this hard before bringing it to the list.
Eliot: status quo
Done @ 4:43
- Re: [Ietf-calsify] Chair review of draft-ietf-cal… Alexey Melnikov
- [Ietf-calsify] Chair review of draft-ietf-calsify… Aki Niemi
- Re: [Ietf-calsify] Chair review of draft-ietf-cal… Cyrus Daboo
- Re: [Ietf-calsify] Chair review of draft-ietf-cal… Aki Niemi
- [Ietf-calsify] Re: Chair review of draft-ietf-cal… Bernard Desruisseaux
- [Ietf-calsify] Re: Chair review of draft-ietf-cal… Aki Niemi