[Ietf-calsify] jabber starts now

[lear at cisco.com (Eliot Lear)]

topic will be itip
From jeffrey at osafoundation.org  Thu Jun 28 17:19:56 2007
From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Thu Jun 28 17:21:03 2007
Subject: [Ietf-calsify] floating RRULEs and UNTIL values
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>

Hi Bernard,

> Given all of the above, here's what I propose:
> 
>  The UNTIL rule part MUST be specified as a date with UTC time,
>  unless DTSTART is specified as a date with local time, except
>  in VTIMEZONE sub-components where the UNTIL rule part MUST
>  always be specified as a date with UTC time.

Yup, that sounds fine.

Sincerely,
Jeffrey

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 287DB80627 for <[e-mail]>; Thu, 28 Jun 2007 17:21:01 -0700 (PDT)
Received: from [192.168.103.105] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D9EFA14220F for <[e-mail]>; Thu, 28 Jun 2007 17:20:05 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 28 Jun 2007 17:19:56 -0700
From: Jeffrey Harris <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] floating RRULEs and UNTIL values
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2007 00:21:01 -0000

Hi Bernard,

> Given all of the above, here's what I propose:
> 
>  The UNTIL rule part MUST be specified as a date with UTC time,
>  unless DTSTART is specified as a date with local time, except
>  in VTIMEZONE sub-components where the UNTIL rule part MUST
>  always be specified as a date with UTC time.

Yup, that sounds fine.

Sincerely,
Jeffrey


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8425580608 for <[e-mail]>; Thu, 28 Jun 2007 06:58:42 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4C449142212 for <[e-mail]>; Thu, 28 Jun 2007 06:57:47 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.54
X-Spam-Level: 
X-Spam-Status: No, score=-1.54 tagged_above=-50 required=4 tests=[AWL=0.925, 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 m75XVGE3GQAR for <[e-mail]>; Thu, 28 Jun 2007 06:57:45 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6BA0F14220C for <[e-mail]>; Thu, 28 Jun 2007 06:57:45 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Jun 2007 15:57:41 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAIRbg0aQ/uCLh2dsb2JhbACBT41cAgkOLA
X-IronPort-AV: i="4.16,470,1175464800";  d="scan'208"; a="146765220:sNHT6007616674"
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 l5SDve2V010060 for <[e-mail]>; Thu, 28 Jun 2007 15:57:40 +0200
Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4262.cisco.com [10.61.80.165]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5SDvaTC015284 for <[e-mail]>; Thu, 28 Jun 2007 13:57:40 GMT
Message-ID: <[e-mail]>
Date: Thu, 28 Jun 2007 15:57:26 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20; t=1183039060; x=1183903060; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20jabber=20starts=20now |Sender:=20; bh=yOXP/C6TdPQMLt7/sBvl+UfzWmGdSkCLEOtSWav0amU=; b=d3mDNCoZUjkte8yAmQ3Q3TxVqCZG9KeSYBt4bciSus04fCuzFdyXyaaz7fmi+vp/6n0fUdAd LNkX2FMlqf26XAYEJzUv5njiFW7TlDzzKZfAw0abTFIyybwQBU9Glz+3;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] jabber starts now
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 13:58:42 -0000

topic will be itip


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 051A880501 for <[e-mail]>; Wed, 27 Jun 2007 22:40:12 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C087114220C for <[e-mail]>; Wed, 27 Jun 2007 22:39:16 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.123
X-Spam-Level: 
X-Spam-Status: No, score=-1.123 tagged_above=-50 required=4 tests=[AWL=0.380,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961]
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 wVFcjKl42uce for <[e-mail]>; Wed, 27 Jun 2007 22:39:14 -0700 (PDT)
Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AAA44142207 for <[e-mail]>; Wed, 27 Jun 2007 22:39:14 -0700 (PDT)
Received: from localhost.localdomain (webmail1.server.rpi.edu [128.113.2.169]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l5S5d8kr019080; Thu, 28 Jun 2007 01:39:08 -0400
Message-Id: <[e-mail]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Originating-Ip: 72.224.123.130
X-Http_host: webmail.rpi.edu
Date: Thu, 28 Jun 2007 1:39:08 -0400
MIME-Version: 1.0
Organization: Rensselaer Polytechnic Institute
Subject: Re: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameter  specified on DATE property
X-Mailer: EMUmail 6.0.1.30
From: [e-mail]
X-Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20061201 Firefox/2.0.0.4 (Ubuntu-feisty)
X-Webmail-User: [e-mail]
To: [e-mail]
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.226
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 05:40:12 -0000

I suppose I agree with reservations...

>From a ui perspective it's useful to be able to flag something as an all
day event without the precision implied by setting the start and end to
specific times.

For personal events it's probably not an issue. However, when trying to
use rfc2445 objects to advertise public events it's more problematical.

For example, we have graduation at RPI. It doesn't start at midnight and
end at midnight but for all intents and purposes it's an all-day event.
Some of it is webcast. If we mark it as an all day event without a
timezome the New Zealand parents will tune in 12 hours out (assuming they 
trust calendars and timezones).

One solution is to allow a TZID on a DATE. Then we interpret the date in
the intended timezone - whatever our personal timezone. This appears to
be a matter of just firming up an omission in the rfc.

Also it doesn't disallow 'floating' dates i.e  a DATE without a TZID so
we can still say - all day on March 15th is my birthday (yes it is)

Another option is to flag date/time as being really all day - microsoft
have an x-property which does just that. This would work but seems more
complex.

All-day already has some implied fuzziness to it which is useful and
perhaps we should extend that rather than trying to add fuzziness to a
precise definition of time implied by DATETIME

==============Original message text===============
On Wed, 27 Jun 2007 13:15:51 EDT Bernard Desruisseaux wrote:

Section 4.2.19 Time Zone Identifier of RFC 2445 says nothing about the
use of the TZID parameter on DATE properties. This section specifies
when this parameter MUST or MUST NOT be specified on DATE-TIME or TIME
values, but says nothing about DATE.

Furthermore, unlike section 4.3.5 Date-Time, section 4.3.4 Date doesn't
discuss the TZID parameter at all.

I'm bringing this up since Mozilla Sunbird specifies the TZID parameter
on DTSTART and DTEND of "All Day" events. For instance, here's an All
Day VEVENT created by Mozilla Sunbird with my time zone set to
Asia/Shanghai (UTC+08:00):

BEGIN:VEVENT
CREATED:20070627T160534Z
LAST-MODIFIED:20070627T160607Z
DTSTAMP:20070627T160650Z
UID:d9a9e2e4-4123-4b06-8dca-c10f791f8700
SUMMARY:All Day Event June 28th 2007 (Asia/Shanghai UTC+08:00)
DTSTART;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070628
DTEND;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070629
END:VEVENT

To find out whether Mozilla Sunbird actually cares about the TZID
itself I changed my time zone to America/Montreal (UTC-4:00). Given
that June 28th, 2007 00:00 (midnight) Asia/Shanghai corresponds to
June 27th, 12:00 (noon) America/Montreal I was wondering if this
All Day event would be displayed on June 27th, 2007. It turns out
that Mozilla Sunbird still displayed the event on June 28th.

    Note: If you want to try this yourself with Mozilla Sunbird,
    you'll actually need to change the time zone of your OS to
    match the time zone you configured in Mozilla Sunbird.  Else
    Mozilla Sunbird will end up creating the All Day event on the
    wrong day altogether. For instance, if you configure Sunbird
    with Asia/Shanghai but have your OS configured with
    America/Montreal and create an All Day event on June 28th, 2007,
    Mozilla Sunbird will create an All Day event that start on
    June 29th!

While iCalendar currently doesn't forbid the use of the TZID parameter
on DATE value properties, it certainly doesn't look like it was ever
meant to be used. If one wants to ground a given DATE to midnight of
a specific time zone I believe one should simply use a DATE-TIME value.

I propose to change the following statement in section 4.2.19 Time Zone
Identifier, from:

 > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
 > properties whose time values are specified in UTC.

to:

 > The TZID property parameter MUST NOT be applied to DATE properties,
 > and DATE-TIME or TIME properties whose time values are specified in
 > UTC.

Cheers,
Bernard
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
===========End of original message text===========


-- 

Mike Douglass                           [e-mail]
Senior Systems Programmer
Communication & Collaboration Technologies
518 276 6780(voice) 518 276 2809(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9EB6D804C0 for <[e-mail]>; Wed, 27 Jun 2007 19:45:18 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 66F1114220C for <[e-mail]>; Wed, 27 Jun 2007 19:44:23 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.038
X-Spam-Level: 
X-Spam-Status: No, score=-2.038 tagged_above=-50 required=4 tests=[AWL=0.560,  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 JP8gBi62xMcO for <[e-mail]>; Wed, 27 Jun 2007 19:44:21 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9F5D7142203 for <[e-mail]>; Wed, 27 Jun 2007 19:44:21 -0700 (PDT)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5S2iJxP031449 for <[e-mail]>; Wed, 27 Jun 2007 20:44:19 -0600
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5S2Ttal032349 for <[e-mail]>; Wed, 27 Jun 2007 20:44:18 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-7.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2994688251182998639; Wed, 27 Jun 2007 19:43:59 -0700
Message-ID: <[e-mail]>
Date: Wed, 27 Jun 2007 22:43:58 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 02:45:18 -0000

In section 6 Recommended Practices of RFC 2445 it says:

 > 3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
 >     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
 >     "VTODO" calendar components, have the same value data type (e.g.,
 >     DATE-TIME), they SHOULD specify values in the same time format
 >     (e.g., UTC time format).

Would we be okay to had the following MUST requirements:

If DTSTART is specified as a "DATE WITH UTC TIME" (FORM #2) or
a "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE" (FORM #3) then
DTEND/DUE *MUST* be specified as either a "DATE WITH UTC TIME"
(FORM #2) or a "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE"
(FORM #3).  Else, if DTSTART is specified as a "DATE WITH LOCAL
TIME" (FORM #1) then DTEND/DUE *MUST* also be specified as a
"DATE WITH LOCAL TIME" (FORM #1).

Cheers,
Bernard

Bernard Desruisseaux wrote:
> [ Note to the chairs: This issue is related to issue 65. ]
> 
> This is currently specified as a SHOULD in section 6 Recommended
> Practices of RFC 2445:
> 
>  > 3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
>  >     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
>  >     "VTODO" calendar components, have the same value data type (e.g.,
>  >     DATE-TIME), they SHOULD specify values in the same time format
>  >     (e.g., UTC time format).
> 
> I wouldn't mind adding a requirement to specify that if DTSTART is
> specified as a "DATE WITH LOCAL TIME" (FORM #1) then DTEND/DUE MUST
> also be specified as a "DATE WITH LOCAL TIME" (FORM #1).
> 
> That being said, I think we could accept DTSTART and DTEND/DUE to mix
> "DATE WITH UTC TIME" (FORM #2) with "DATE WITH LOCAL TIME AND TIME
> ZONE REFERENCE" (FORM #3).
> 
> Finally, as was already clarified for issue 65, if DTSTART and DTEND/DUE
> are both specified as "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE"
> (FORM #3) a different time zone MAY be used for each property.
> 
> Cheers,
> Bernard
> 
> Arnaud Quillaud wrote:
>> The Calsify draft now clarifies in the DTEND definition that:
>> <<
>> The value type
>>    of this property MUST be the same as the "DTSTART" property, and
>>    the value of this property MUST be later in time than the value of
>>    the "DTSTART" property.
>> (See 
>> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001519.html). 
>>
>>
>> Nevertheless the value type just allows us to distinguish between DATE 
>> and DATETIME.
>>
>> Shouldn't we go one step further and say that if the DTSTART value 
>> type is FORM #1: DATE WITH LOCAL TIME (See 
>> http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-06.html#VALUE.DATE-TIME), 
>> DTEND should also be of the same form.
>> Otherwise, if we allow a mix of floating time + utc time (or time with 
>> tz), one can create an event which is valid in some timezones but 
>> invalid in some others (you may end up with DTEND < DTSTART).
>>
>>
>> Arnaud Q
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [e-mail]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D7A8E80406; Wed, 27 Jun 2007 19:39:14 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A028A14220C; Wed, 27 Jun 2007 19:38:19 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.024
X-Spam-Level: 
X-Spam-Status: No, score=-2.024 tagged_above=-50 required=4 tests=[AWL=0.574,  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 YeT5bWnTbA7p; Wed, 27 Jun 2007 19:38:17 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A52D5142203; Wed, 27 Jun 2007 19:38:17 -0700 (PDT)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5S2cFJh025651; Wed, 27 Jun 2007 20:38:15 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5S2cEUi021502; Wed, 27 Jun 2007 20:38:14 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-7.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2994685811182998264; Wed, 27 Jun 2007 19:37:44 -0700
Message-ID: <[e-mail]>
Date: Wed, 27 Jun 2007 22:37:42 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Jeffrey Harris <[e-mail]>
Subject: Re: [Ietf-calsify] floating RRULEs and UNTIL values
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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 WG <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2007 02:39:15 -0000

Here's how the story goes:

- The requirement to have UNTIL specified in UTC was specified
   in RFC 2445:

   > If specified as a date-time value, then it MUST be specified
   > in an UTC time format.

- At the 66th IETF Meeting in Montreal (July 2006) we've agreed
   to clarify that the value of the UNTIL rule part MUST have the
   same value type as the "DTSTART" property (Issue 23). As you'll
   see in the minutes the issue you are bringing up was briefly
   discussed:

   http://www3.ietf.org/proceedings/06jul/minutes/calsify.txt

   > 4 4.3.10 on UNTIL rule.  Should clarify whether UNTIL can use a DATE
   > value type.
   >
   > AI: Room showing agreement that the draft should state that
   > the UNTIL value type MUST match DTSTART value type.
   >
   > Another issue with whether UNTIL DATE-TIME should be allowed to float
   > or not (currently UTC a MUST). Might still be a problem if DTSTART is
   > a local time; however, JeffMc points out later that DTSTART is not
   > allowed to float currently, so should not be an issue.

- At the 67th IETF meeting in San Diego (November 2006) we've agreed
   to clarify that all forms of DATE-TIME were allowed for DTSTART and
   DTEND/DUE in recurring components (i.e., also DATE WITH UTC TIME).
   (Issue 43). Except for VTIMEZONE sub-components where DTSTART is
   REQUIRED to be in UTC:

   http://tools.ietf.org/wg/calsify/minutes?item=minutes67.html

   You can also check:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-September/001172.html

- Also in November 2006, Tim and Cyrus pointed out that we must allow
   floating time recurring events.  See thread:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001353.html

Given what was previously agreed for issue 23 and issue 43 I believe
a change to the specification for the UNTIL rule part is advisable.

In the case of VTIMEZONE sub-components the DTSTART is specified as a
date with local time but is not really floating since "TZOFFSETFROM"
always gives you its UTC offset. As such it does make sense to have
a "floating" DTSTART and an UNTIL rule part with a UTC time in a
VTIMEZONE sub-component.

In the case of VEVENT components if the DTSTART is specified as a
date with local time and the UNTIL rule part is specified as a date
with UTC time then people in different time zones could end up with
a different number of recurrence instances.  Not good.

Given all of the above, here's what I propose:

  The UNTIL rule part MUST be specified as a date with UTC time,
  unless DTSTART is specified as a date with local time, except
  in VTIMEZONE sub-components where the UNTIL rule part MUST
  always be specified as a date with UTC time.

Thanks,
Bernard

Jeffrey Harris wrote:
> There are a few places in draft 6 that say something like this:
> 
>       The UNTIL rule part defines a DATE or DATE-TIME value which bounds
>       the recurrence rule in an inclusive manner.  If the value
>       specified by UNTIL is synchronized with the specified recurrence,
>       this DATE or DATE-TIME becomes the last instance of the
>       recurrence.  The value of the UNTIL rule part MUST have the same
>       value type as the "DTSTART" property.  If specified as a DATE-TIME
>       value, then it MUST be specified in a UTC time format.  If not
>       present, and the COUNT rule part is also not present, the "RRULE"
>       is considered to repeat forever.
> 
> and later,
> 
>       *  If observance is known to have an effective end date, the
>          "UNTIL" recurrence rule parameter MUST be used to specify the
>          last valid onset of this observance (i.e., the UNTIL date-time
>          will be equal to the last instance generated by the recurrence
>          pattern).  It MUST be specified in UTC time.
> 
> What about recurring floating events?  Seems like we're either
> forbidding floating events from using UNTIL, or we're saying even
> floating recurring events need to have UNTIL values in UTC, which I
> think is a bad idea.
> 
> How about removing the latter paragraph's insistence on UTC, since it
> doesn't apply to DATE valued recurring events or floating events, and
> changing the first to:
> 
>       The UNTIL rule part defines a DATE or DATE-TIME value which bounds
>       the recurrence rule in an inclusive manner.  If the value
>       specified by UNTIL is synchronized with the specified recurrence,
>       this DATE or DATE-TIME becomes the last instance of the
>       recurrence.  The value of the UNTIL rule part MUST have the same
>       value type as the "DTSTART" property.  If DTSTART is specified as
>       a DATE-TIME value with a timezone, then UNTIL MUST be specified in
>       a UTC time format.  If DTSTART is specified as a floating
>       DATE-TIME, UNTIL MUST specified as a floating DATE-TIME.  If not
>       present, and the COUNT rule part is also not present, the "RRULE"
>       is considered to repeat forever.
> 
> Sincerely,
> Jeffrey
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9022D7F9C3 for <[e-mail]>; Wed, 27 Jun 2007 14:41:07 -0700 (PDT)
Received: from [192.168.0.106] (c-76-21-72-142.hsd1.ca.comcast.net [76.21.72.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E1A6142213 for <[e-mail]>; Wed, 27 Jun 2007 14:40:12 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 27 Jun 2007 14:40:05 -0700
From: Jeffrey Harris <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: Calsify WG <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Ietf-calsify] floating RRULEs and UNTIL values
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2007 21:41:07 -0000

There are a few places in draft 6 that say something like this:

      The UNTIL rule part defines a DATE or DATE-TIME value which bounds
      the recurrence rule in an inclusive manner.  If the value
      specified by UNTIL is synchronized with the specified recurrence,
      this DATE or DATE-TIME becomes the last instance of the
      recurrence.  The value of the UNTIL rule part MUST have the same
      value type as the "DTSTART" property.  If specified as a DATE-TIME
      value, then it MUST be specified in a UTC time format.  If not
      present, and the COUNT rule part is also not present, the "RRULE"
      is considered to repeat forever.

and later,

      *  If observance is known to have an effective end date, the
         "UNTIL" recurrence rule parameter MUST be used to specify the
         last valid onset of this observance (i.e., the UNTIL date-time
         will be equal to the last instance generated by the recurrence
         pattern).  It MUST be specified in UTC time.

What about recurring floating events?  Seems like we're either
forbidding floating events from using UNTIL, or we're saying even
floating recurring events need to have UNTIL values in UTC, which I
think is a bad idea.

How about removing the latter paragraph's insistence on UTC, since it
doesn't apply to DATE valued recurring events or floating events, and
changing the first to:

      The UNTIL rule part defines a DATE or DATE-TIME value which bounds
      the recurrence rule in an inclusive manner.  If the value
      specified by UNTIL is synchronized with the specified recurrence,
      this DATE or DATE-TIME becomes the last instance of the
      recurrence.  The value of the UNTIL rule part MUST have the same
      value type as the "DTSTART" property.  If DTSTART is specified as
      a DATE-TIME value with a timezone, then UNTIL MUST be specified in
      a UTC time format.  If DTSTART is specified as a floating
      DATE-TIME, UNTIL MUST specified as a floating DATE-TIME.  If not
      present, and the COUNT rule part is also not present, the "RRULE"
      is considered to repeat forever.

Sincerely,
Jeffrey


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BE6F77F7AA for <[e-mail]>; Wed, 27 Jun 2007 14:04:51 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 85F8114220E for <[e-mail]>; Wed, 27 Jun 2007 14:03:56 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.398
X-Spam-Level: 
X-Spam-Status: No, score=-1.398 tagged_above=-50 required=4 tests=[AWL=1.201,  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 D130QFZobSAO for <[e-mail]>; Wed, 27 Jun 2007 14:03:54 -0700 (PDT)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E555F14220C for <[e-mail]>; Wed, 27 Jun 2007 14:03:53 -0700 (PDT)
Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l5RL3ojZ025440 for <[e-mail]>; Wed, 27 Jun 2007 23:03:50 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameterspecified on DATE property
Date: Wed, 27 Jun 2007 23:03:46 +0200
User-Agent: KMail/1.9.5 + Features
References: <[e-mail]> <[e-mail]> <00aa01c7b8f9$d2ae8a50$d201a8c0@nigelhome>
In-Reply-To: <00aa01c7b8f9$d2ae8a50$d201a8c0@nigelhome>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2007 21:04:53 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 27. Juni 2007 schrieb Nigel Swinson:
> > > I propose to change the following statement in section 4.2.19 Time Zone
> > >
> > > Identifier, from:
> > > > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
> > > > properties whose time values are specified in UTC.
> > >
> > > to:
> > > > The TZID property parameter MUST NOT be applied to DATE properties,
> > > > and DATE-TIME or TIME properties whose time values are specified in
> > > > UTC.
> >
> > Hooray!  I second the change.
>
> We'd encountered this issue and come to similar conclusions, so I'd also be
> happy for the clarity offered by this change.


Just another "Me too" from my side.
Reinhold


- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGgtC2TqjEwhXvPN0RAvTtAKCzFdjV07zHDlLg07xlFHn4vjs4RACgnf+7
h/jYCvmVSzogOiTGjqnQ5YU=
=uNG0
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6A48C804B8 for <[e-mail]>; Wed, 27 Jun 2007 13:29:13 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 31A38142212 for <[e-mail]>; Wed, 27 Jun 2007 13:28:18 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.581
X-Spam-Level: 
X-Spam-Status: No, score=-0.581 tagged_above=-50 required=4 tests=[AWL=0.530,  BAYES_05=-1.11, 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 H1-IN2VIml93 for <[e-mail]>; Wed, 27 Jun 2007 13:28:16 -0700 (PDT)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 98EF6142211 for <[e-mail]>; Wed, 27 Jun 2007 13:28:16 -0700 (PDT)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 455b75f593e13070f4ebd399412bcfaf
X-Spam-Score-Summary: 2, 0, 0, cdd93278e63df3ee, 79df6408548511e2, [e-mail], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1538:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2393:2559:2562:2828:3027:3352:3865:3867:3868:3870:4250:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigelhome (unverified [10.42.40.209]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.1) with ESMTP id <[e-mail]>; Wed, 27 Jun 2007 13:28:15 -0700
Message-ID: <00aa01c7b8f9$d2ae8a50$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Bernard Desruisseaux" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameterspecified on DATE property
Date: Wed, 27 Jun 2007 21:29:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2007 20:29:13 -0000

> > I propose to change the following statement in section 4.2.19 Time =
Zone
> > Identifier, from:
> >
> > > The TZID property parameter MUST NOT be applied to DATE-TIME or =
TIME
> > > properties whose time values are specified in UTC.
> >
> > to:
> >
> > > The TZID property parameter MUST NOT be applied to DATE =
properties,
> > > and DATE-TIME or TIME properties whose time values are specified =
in
> > > UTC.
> >
> Hooray!  I second the change.

We'd encountered this issue and come to similar conclusions, so I'd also =
be happy for the clarity offered by this change.

Nigel


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DFB0B802A1 for <[e-mail]>; Wed, 27 Jun 2007 10:46:16 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A6EAB142209 for <[e-mail]>; Wed, 27 Jun 2007 10:45:21 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-50 required=4 tests=[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 lW7sPp8-qkeq for <[e-mail]>; Wed, 27 Jun 2007 10:45:19 -0700 (PDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by laweleka.osafoundation.org (Postfix) with ESMTP id 03A951421FD for <[e-mail]>; Wed, 27 Jun 2007 10:45:18 -0700 (PDT)
Received: by wa-out-1112.google.com with SMTP id j40so371559wah for <[e-mail]>; Wed, 27 Jun 2007 10:45:18 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pBPqx2Mlu3huaKTNCiMJHw2PYwlh0IeP7GSa7CZVObGbbfdcLM77aSIKRKk79wf5MIU6KW6zSaIR0xJ/WGPBmjbr+5E2dxjjmLFvIw/yCWmTBkJ859S1LaRMbphO6T0h1nVj1wnDu2vyiqPTf2bvRwStf9RjLijvDAztXY+oa6I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cCn2KVaMyorj0pcTCmNJD1OLl9RecUOqEMqv8fip6KhpLQ6sbcJWIFpjXzeMxnDdpRA+a8Pmw7p241Ixxh3gPBi4GHOVRsvJHulAdc89YoNdYFgov/KIIlzdmy1tjppiWzS4GUGaj3dNJHCK4s9YXAO3pbPqSyiA+F+QnXHRU5A=
Received: by 10.114.80.4 with SMTP id d4mr717824wab.1182966318170; Wed, 27 Jun 2007 10:45:18 -0700 (PDT)
Received: from clint-talberts-computer.local ( [71.145.176.16]) by mx.google.com with ESMTP id m40sm6804256waf.2007.06.27.10.45.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 10:45:17 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 27 Jun 2007 12:45:12 -0500
From: Clint Talbert <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameter specified on DATE property
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2007 17:46:17 -0000

Bernard Desruisseaux wrote:
> Section 4.2.19 Time Zone Identifier of RFC 2445 says nothing about the
> use of the TZID parameter on DATE properties. This section specifies
> when this parameter MUST or MUST NOT be specified on DATE-TIME or TIME
> values, but says nothing about DATE.
>
> Furthermore, unlike section 4.3.5 Date-Time, section 4.3.4 Date doesn't
> discuss the TZID parameter at all.
>
I'm glad that you're addressing this because I believe the behavior you 
note resulted from a misunderstanding of section 4.3.4.
> .. snip..

> To find out whether Mozilla Sunbird actually cares about the TZID
> itself I changed my time zone to America/Montreal (UTC-4:00). Given
> that June 28th, 2007 00:00 (midnight) Asia/Shanghai corresponds to
> June 27th, 12:00 (noon) America/Montreal I was wondering if this
> All Day event would be displayed on June 27th, 2007. It turns out
> that Mozilla Sunbird still displayed the event on June 28th.
>
I believe this is the proper behavior, to tie the all-day event to a 
specific numerical date.  It sounds like you also think so, given the 
change you suggest below.
>    Note: If you want to try this yourself with Mozilla Sunbird,
>    you'll actually need to change the time zone of your OS to
>    match the time zone you configured in Mozilla Sunbird.  Else
>    Mozilla Sunbird will end up creating the All Day event on the
>    wrong day altogether. For instance, if you configure Sunbird
>    with Asia/Shanghai but have your OS configured with
>    America/Montreal and create an All Day event on June 28th, 2007,
>    Mozilla Sunbird will create an All Day event that start on
>    June 29th!
>
This is an unfortunate, known issue in Sunbird/Lightning that we are 
addressing in our next (0.7) release (work is actually underway on it, 
though the bug report below does not reflect it). I apologize for the 
inconvenience. 

For more information, please see: 
https://bugzilla.mozilla.org/show_bug.cgi?id=337191.  And if you'd like 
to be notified of changes to the bug, feel free to CC yourself on it.
>
> I propose to change the following statement in section 4.2.19 Time Zone
> Identifier, from:
>
> > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
> > properties whose time values are specified in UTC.
>
> to:
>
> > The TZID property parameter MUST NOT be applied to DATE properties,
> > and DATE-TIME or TIME properties whose time values are specified in
> > UTC.
>
Hooray!  I second the change.

I'll file another bug to no longer add TZID to DATE properties in 
Sunbird as well.  Thanks for bringing this to our attention. :-)

Thanks,

Clint Talbert
Mozilla Calendar Project QA Coordinator



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3D5F2802A1 for <[e-mail]>; Wed, 27 Jun 2007 10:18:52 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 041D8142209 for <[e-mail]>; Wed, 27 Jun 2007 10:17:57 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-50 required=4 tests=[AWL=0.588, 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 O97YzIXM9hsz for <[e-mail]>; Wed, 27 Jun 2007 10:17:54 -0700 (PDT)
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 55063142207 for <[e-mail]>; Wed, 27 Jun 2007 10:17:54 -0700 (PDT)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5RHHpSO011711; Wed, 27 Jun 2007 12:17:51 -0500
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5RGpGbE002442; Wed, 27 Jun 2007 11:17:50 -0600
Received: from bdesruis-ca.ca.oracle.com by acsmt351.oracle.com with ESMTP id 2993887851182964558; Wed, 27 Jun 2007 10:15:58 -0700
Message-ID: <[e-mail]>
Date: Wed, 27 Jun 2007 13:15:51 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Calsify WG <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
Subject: [Ietf-calsify] Section 4.2.19 Time Zone Identifier: TZID parameter specified on DATE property
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2007 17:18:52 -0000

Section 4.2.19 Time Zone Identifier of RFC 2445 says nothing about the
use of the TZID parameter on DATE properties. This section specifies
when this parameter MUST or MUST NOT be specified on DATE-TIME or TIME
values, but says nothing about DATE.

Furthermore, unlike section 4.3.5 Date-Time, section 4.3.4 Date doesn't
discuss the TZID parameter at all.

I'm bringing this up since Mozilla Sunbird specifies the TZID parameter
on DTSTART and DTEND of "All Day" events. For instance, here's an All
Day VEVENT created by Mozilla Sunbird with my time zone set to
Asia/Shanghai (UTC+08:00):

BEGIN:VEVENT
CREATED:20070627T160534Z
LAST-MODIFIED:20070627T160607Z
DTSTAMP:20070627T160650Z
UID:d9a9e2e4-4123-4b06-8dca-c10f791f8700
SUMMARY:All Day Event June 28th 2007 (Asia/Shanghai UTC+08:00)
DTSTART;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070628
DTEND;VALUE=DATE;TZID=/mozilla.org/20070129_1/Asia/Shanghai:20070629
END:VEVENT

To find out whether Mozilla Sunbird actually cares about the TZID
itself I changed my time zone to America/Montreal (UTC-4:00). Given
that June 28th, 2007 00:00 (midnight) Asia/Shanghai corresponds to
June 27th, 12:00 (noon) America/Montreal I was wondering if this
All Day event would be displayed on June 27th, 2007. It turns out
that Mozilla Sunbird still displayed the event on June 28th.

    Note: If you want to try this yourself with Mozilla Sunbird,
    you'll actually need to change the time zone of your OS to
    match the time zone you configured in Mozilla Sunbird.  Else
    Mozilla Sunbird will end up creating the All Day event on the
    wrong day altogether. For instance, if you configure Sunbird
    with Asia/Shanghai but have your OS configured with
    America/Montreal and create an All Day event on June 28th, 2007,
    Mozilla Sunbird will create an All Day event that start on
    June 29th!

While iCalendar currently doesn't forbid the use of the TZID parameter
on DATE value properties, it certainly doesn't look like it was ever
meant to be used. If one wants to ground a given DATE to midnight of
a specific time zone I believe one should simply use a DATE-TIME value.

I propose to change the following statement in section 4.2.19 Time Zone
Identifier, from:

 > The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
 > properties whose time values are specified in UTC.

to:

 > The TZID property parameter MUST NOT be applied to DATE properties,
 > and DATE-TIME or TIME properties whose time values are specified in
 > UTC.

Cheers,
Bernard


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B6F26804CA for <[e-mail]>; Sat, 23 Jun 2007 15:27:27 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7AFAD14220E for <[e-mail]>; Sat, 23 Jun 2007 15:26:32 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.381
X-Spam-Level: 
X-Spam-Status: No, score=-1.381 tagged_above=-50 required=4 tests=[AWL=1.218,  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 9TMpihAcRkJz for <[e-mail]>; Sat, 23 Jun 2007 15:26:28 -0700 (PDT)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EF88F142206 for <[e-mail]>; Sat, 23 Jun 2007 15:26:27 -0700 (PDT)
Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l5NMQPeU028511 for <[e-mail]>; Sun, 24 Jun 2007 00:26:25 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Struggling with BYxxx
Date: Sun, 24 Jun 2007 00:26:20 +0200
User-Agent: KMail/1.9.5 + Features
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 23 Jun 2007 22:27:27 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Samstag, 23. Juni 2007 schrieb Mr. Demeanour:
> Hi,
>
> What is the correct interpretation of a YEARLY rule in which BYMONTH and
> BYYEARDAY are both specified?
>
> I can't find this described anywhere, but my interpretation would be to
> /expand/ in accordance with the BYMONTH part, and then to /expand/ in
> accordance with the BYYEARDAY part. So consider the rule
>
>      RRULE:FREQ=YEARLY;BYMONTH=6,12;BYMONTHDAY=25;BYYEARDAY=1
>
> I would expect this rule to expand to two Christmases per year, on the
> 25th of June and December respectively, and one New Year's Day.
>
> Is that correct?

I don't think so. The dates matched by the rule have to fulfill all the BY* 
restrictions. In your case, there are not dates that are the first day of the 
year and lie in June or december...

Or to make it more formal according to the evaluation order in the RFC:
For year YY, the recurrence set is generated as:
BYMONTH: Only all days in June or December
BYYEARDAY: only those days in the set that are the first day of the year 
(which are none, so our recurrence set is empty here, already).
BYMONTHDAY: No effect, since the set is already empty.

The BY* rule parts must all be matched by a date/time in the recurrence set, 
but the BY* rule part values (e.g. 6,12 for BYMONTH here) are or'ed together.

Cheers,
Reinhold


- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGfZ4OTqjEwhXvPN0RAmfNAJ9mycdOoAx0vNT/vVLFv1ZhVUpdMQCeO9Td
iMJq7yMfBZOPxSA9rlKlpCs=
=xTXt
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0E3FD7F51C for <[e-mail]>; Sat, 23 Jun 2007 04:37:56 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C79EE142201 for <[e-mail]>; Sat, 23 Jun 2007 04:37:00 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.443
X-Spam-Level: 
X-Spam-Status: No, score=-2.443 tagged_above=-50 required=4 tests=[AWL=0.022,  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 yAWWTFIPXBC3 for <[e-mail]>; Sat, 23 Jun 2007 04:36:58 -0700 (PDT)
Received: from saraha.jackpot.uk.net (jackpot-adsl.demon.co.uk [80.177.236.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 28A611421F9 for <[e-mail]>; Sat, 23 Jun 2007 04:36:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by saraha.jackpot.uk.net (Postfix) with ESMTP id 21698737A2 for <[e-mail]>; Sat, 23 Jun 2007 12:36:56 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at jackpot.uk.net
Received: from saraha.jackpot.uk.net ([127.0.0.1]) by localhost (saraha.jackpot.uk.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUzQU3euNk3x for <[e-mail]>; Sat, 23 Jun 2007 12:36:55 +0100 (BST)
Received: from [192.168.101.2] (unknown [192.168.101.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by saraha.jackpot.uk.net (Postfix) with ESMTP for <[e-mail]>; Sat, 23 Jun 2007 12:36:55 +0100 (BST)
Message-ID: <[e-mail]>
Date: Sat, 23 Jun 2007 12:40:23 +0100
From: "Mr. Demeanour" <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Ietf-calsify] Struggling with BYxxx
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 23 Jun 2007 11:37:56 -0000

Hi,

What is the correct interpretation of a YEARLY rule in which BYMONTH and
BYYEARDAY are both specified?

I can't find this described anywhere, but my interpretation would be to
/expand/ in accordance with the BYMONTH part, and then to /expand/ in
accordance with the BYYEARDAY part. So consider the rule

     RRULE:FREQ=YEARLY;BYMONTH=6,12;BYMONTHDAY=25;BYYEARDAY=1

I would expect this rule to expand to two Christmases per year, on the
25th of June and December respectively, and one New Year's Day.

Is that correct?

Thanks,
Jack.


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 29E5380614 for <[e-mail]>; Thu, 21 Jun 2007 12:42:05 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E07D814220D for <[e-mail]>; Thu, 21 Jun 2007 12:41:09 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.275
X-Spam-Level: 
X-Spam-Status: No, score=-1.275 tagged_above=-50 required=4 tests=[AWL=1.325,  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 xk+zjgQj8WNm for <[e-mail]>; Thu, 21 Jun 2007 12:41:07 -0700 (PDT)
Received: from mail.mhsoftware.com (mail.mhsoftware.com [216.17.130.186]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 806D214220E for <[e-mail]>; Thu, 21 Jun 2007 12:41:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id E22A629BE082 for <[e-mail]>; Thu, 21 Jun 2007 13:41:06 -0600 (MDT)
X-Virus-Scanned: amavisd-new at mhsoftware.com
Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid.mhsoftware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtvZ8kRoh+jL for <[e-mail]>; Thu, 21 Jun 2007 13:41:06 -0600 (MDT)
Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 2436B299A0FE for <[e-mail]>; Thu, 21 Jun 2007 13:41:06 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Thu, 21 Jun 2007 13:41:13 -0600
From: George Sexton <[e-mail]>
Organization: MH Software, Inc.
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: ietf-calsify <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Ietf-calsify] OT: Anyone know anyone at Apple 
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 19:42:05 -0000

I'm hitting a problem with RFC-2445 compatibility on Apple iCal (2.0.5).

Essentially, the presence of an RDATE entry in an iCal file will cause 
iCal to terminate with some sort of exception. I suppose that if someone 
were really interested, this could probably be exploited to do something 
bad.

I've submitted it as a bug at least 3 times to Apple over the past year, 
and it's just not getting fixed.

If anyone could mail me off list with information to contact someone at 
Apple I would appreciate it.

-- 
George Sexton
MH Software, Inc.
Voice: [phone]
URL:   http://www.mhsoftware.com/



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CD55A80460 for <[e-mail]>; Thu, 21 Jun 2007 09:17:42 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8F98814220A for <[e-mail]>; Thu, 21 Jun 2007 09:16:47 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-50 required=4 tests=[AWL=1.000, 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 5b9wc05PLr6s for <[e-mail]>; Thu, 21 Jun 2007 09:16:46 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id C0FC5142207 for <[e-mail]>; Thu, 21 Jun 2007 09:16:45 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 21 Jun 2007 17:16:41 +0100
Message-ID: <[e-mail]>
Date: Thu, 21 Jun 2007 17:15:15 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 16:17:42 -0000

Eliot Lear wrote:

> Alexey Melnikov wrote:
>
>>
>> I think all templates need to have a Usage field, which contains one 
>> of the following: limited, global, obsolete.
>
> Sounds like you're mixing semantics.  Do you mean "status"?  I think 
> that's important too.

SASL registry uses "Usage", which is one of "limited", "common" or 
"obsolete". "obsolete" is something that shouldn't be used. "common" is 
something that is applicable to various use cases. "limited" is 
something known to be somewhat restricted/broken, but not sufficiently 
bad in order to be marked "obsolete".

So what do you mean by "status"?

>   Also...
>
>>> X.X.X  Registration Template for New Components
>>>
>>>     A component is defined by completing the following template.
>>>
>>>         To: [e-mail]
>>>
>>>         Subject: Registration of new iCalendar component XXX
>>>
>>>         Component Name:
>>>
>>>         Purpose:
>>>
>>>         Format Definition:
>>>
>>>         Description:
>>
> You don't need the "To: " line.

This is more of a convention used by many IANA templates.



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 95D4F7FE03 for <[e-mail]>; Thu, 21 Jun 2007 07:03:40 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 578DE14220D for <[e-mail]>; Thu, 21 Jun 2007 07:02:45 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.522
X-Spam-Level: 
X-Spam-Status: No, score=-1.522 tagged_above=-50 required=4 tests=[AWL=0.943,  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 YdDosoB3g30I for <[e-mail]>; Thu, 21 Jun 2007 07:02:43 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C8E714220A for <[e-mail]>; Thu, 21 Jun 2007 07:02:43 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2007 16:02:43 +0200
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 l5LE2gDU024927;  Thu, 21 Jun 2007 16:02:42 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp353.cisco.com [10.61.65.97]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5LE2gTC008288;  Thu, 21 Jun 2007 14:02:42 GMT
Message-ID: <[e-mail]>
Date: Thu, 21 Jun 2007 16:02:38 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=652; t=1182434562; x=1183298562; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20Re=3A=20additional=20IANA=20consider ations |Sender:=20; bh=r/8vGjNjq4q4I/4h+Utk87EZlNx5cj/uIDiejBIJ/wI=; b=m9gYUPFG6tq73aJLgDcZc3ZVwmRSnqou78SA8mSWKDSWWJwdbfP+QvLhm9hh07SQTl8laQcW zBzpXYSDcaJD6M3ofJmA1iZEp/nJiAPZoLEtZ4M8080IRMpmjH1V8447;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
Cc: "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 14:03:40 -0000

Alexey Melnikov wrote:
>
> I think all templates need to have a Usage field, which contains one 
> of the following: limited, global, obsolete.

Sounds like you're mixing semantics.  Do you mean "status"?  I think 
that's important too.  Also...
>
>> X.X.X  Registration Template for New Components
>>
>>     A component is defined by completing the following template.
>>
>>         To: [e-mail]
>>
>>         Subject: Registration of new iCalendar component XXX
>>
>>         Component Name:
>>
>>         Purpose:
>>
>>         Format Definition:
>>
>>         Description:
>

You don't need the "To: " line.

Eliot


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4A2DD7FE03 for <[e-mail]>; Thu, 21 Jun 2007 06:57:09 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0CFDB14220D for <[e-mail]>; Thu, 21 Jun 2007 06:56:14 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-50 required=4 tests=[AWL=1.000, 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 0-N4HWG0qNJa for <[e-mail]>; Thu, 21 Jun 2007 06:56:12 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id CFF3B14220A for <[e-mail]>; Thu, 21 Jun 2007 06:56:11 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 21 Jun 2007 14:55:04 +0100
Message-ID: <[e-mail]>
Date: Thu, 21 Jun 2007 14:53:38 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 13:57:09 -0000

Hi Bernard,
Some questions/comments about the proposed templates below:

Bernard Desruisseaux wrote:

>>> Also, I think we should consider having 4 templates:
>>>
>>> - Registration of New Components
>>> - Registration of New Properties
>>> - Registration of New Parameters
>>> - Registration of New Values
>>>
>>> What do you think?
>>
>>
>> I think there needs to be a substantial difference in the templates 
>> to justify four of them.  Do you think there is?
>
>
> Here's what I have in mind.  A total of 5 templates.
>
>   - Registration Template for New Components
>   - Registration Template for New Properties
>   - Registration Template for New Parameters
>   - Registration Template for New Value Data Types
>   - Registration Template for New Values

I think all templates need to have a Usage field, which contains one of 
the following: limited, global, obsolete.

> X.X.X  Registration Template for New Components
>
>     A component is defined by completing the following template.
>
>         To: [e-mail]
>
>         Subject: Registration of new iCalendar component XXX
>
>         Component Name:
>
>         Purpose:
>
>         Format Definition:
>
>         Description:

How is Purpose different from Description?

What is Format Definition? Is it supposed to be ABNF or RFC reference?

>         Example:
>
> X.X.X  Registration Template for New Properties
>
>     A property is defined by completing the following template.
>
>         To: [e-mail]
>
>         Subject: Registration of new iCalendar property XXX
>
>         Property name:
>
>         Purpose:
>
>         Value type(s):
>
>         Property parameter(s):
>
>         Conformance:

And this is an RFC reference? Why have you omitted this from the 
previous template?

>         Description:
>
>         Format definition:
>
>         Example(s):




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 12BED801B0 for <[e-mail]>; Thu, 21 Jun 2007 06:37:45 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C931814220A for <[e-mail]>; Thu, 21 Jun 2007 06:36:49 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.513
X-Spam-Level: 
X-Spam-Status: No, score=-1.513 tagged_above=-50 required=4 tests=[AWL=0.952,  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 SeV2SInFjq1C for <[e-mail]>; Thu, 21 Jun 2007 06:36:48 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1B996142210 for <[e-mail]>; Thu, 21 Jun 2007 06:36:47 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2007 15:36:48 +0200
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 l5LDakcD005316 for <[e-mail]>; Thu, 21 Jun 2007 15:36:46 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp353.cisco.com [10.61.65.97]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5LDaiTC028924 for <[e-mail]>; Thu, 21 Jun 2007 13:36:46 GMT
Message-ID: <[e-mail]>
Date: Thu, 21 Jun 2007 15:36:40 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18; t=1182433006; x=1183297006; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20jabber=20starts=20in=2020=20minutes |Sender:=20; bh=2whMBU1GuJ674fCxFg/N6dQRcrgyo8v04ToFVAjlVN4=; b=G/cUurF64kIwIbFB+MSK5npSon04s6eh75V5SC026EIfa6O8YHRf1qLTofZ56OZTWvnWmk6P 0E/nmOU0xe0BMVhbrtkFHIngqE/oTb53zrCLKdUX0JopAWZ0MSxIMg2d;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] jabber starts in 20 minutes
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2007 13:37:45 -0000

see you there!


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4C1317FA6C for <[e-mail]>; Wed, 20 Jun 2007 12:03:47 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0D315142212 for <[e-mail]>; Wed, 20 Jun 2007 12:02:52 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-50 required=4 tests=[AWL=0.602,  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 ZNZSPtkbOSjk for <[e-mail]>; Wed, 20 Jun 2007 12:02:50 -0700 (PDT)
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 2C151142210 for <[e-mail]>; Wed, 20 Jun 2007 12:02:50 -0700 (PDT)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5KJ2eXG007448; Wed, 20 Jun 2007 14:02:40 -0500
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5KJ2dKO027637; Wed, 20 Jun 2007 13:02:39 -0600
Received: from bdesruis-ca.ca.oracle.com by acsmt350.oracle.com with ESMTP id 2972233871182366071; Wed, 20 Jun 2007 12:01:11 -0700
Message-ID: <[e-mail]>
Date: Wed, 20 Jun 2007 15:00:58 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: Eliot Lear <[e-mail]>, "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 19:03:47 -0000

Eliot Lear wrote:
> Bernard Desruisseaux wrote:
>> Hi Eliot,
>>
>> Your proposal doesn't take into account the existing
>> Section 6 "Registration of Content Type Elements".
>>
>> We should either:
>>
>> 1- Extend this section to contain all templates.
>> 2- Move this section *in* the IANA Considerations section.
> 
> I think it was intended for (2), Bernard (insert in front of existing 
> text).  I'm sorry if I didn't make that clear.  It wasn't a great "diff".

I'm okay to move section 6 into the IANA Considerations section.

>> Also, I think we should consider having 4 templates:
>>
>> - Registration of New Components
>> - Registration of New Properties
>> - Registration of New Parameters
>> - Registration of New Values
>>
>> What do you think?
> 
> I think there needs to be a substantial difference in the templates to 
> justify four of them.  Do you think there is?

Here's what I have in mind.  A total of 5 templates.

   - Registration Template for New Components
   - Registration Template for New Properties
   - Registration Template for New Parameters
   - Registration Template for New Value Data Types
   - Registration Template for New Values

X.X.X  Registration Template for New Components

     A component is defined by completing the following template.

         To: [e-mail]

         Subject: Registration of new iCalendar component XXX

         Component Name:

         Purpose:

         Format Definition:

         Description:

         Example:

X.X.X  Registration Template for New Properties

     A property is defined by completing the following template.

         To: [e-mail]

         Subject: Registration of new iCalendar property XXX

         Property name:

         Purpose:

         Value type(s):

         Property parameter(s):

         Conformance:

         Description:

         Format definition:

         Example(s):

X.X.X  Registration Template for New Parameters

    A parameter is defined by completing the following template.

         To: [e-mail]

         Subject: Registration of new iCalendar parameter XXX

         Parameter Name:

         Purpose:

         Format Definition:

         Description:

         Example(s):

X.X.X  Registration Template for New Value Data Types

    A value data type is defined by completing the following template.

         To: [e-mail]

         Subject: Registration of new iCalendar value type XXX

         Value Name:

         Purpose:

         Format Definition:

         Description:

         Example(s):

X.X.X  Registration Template for New Values

    A value is defined by completing the following template.

         To: [e-mail]

         Subject: Registration of iCalendar value XXX

         Value:

         Conformance:

         Example(s):

Everybody should be familiar with the first four templates as
there are numerous examples of their use in RFC2445. As for the
last template, here's a fictitious example:

         To: [e-mail]

         Subject: Registration of iCalendar value TOP-SECRET

         Value: TOP-SECRET

         Conformance: This value can be used with the CLASS
            property.

         Example(s):

            CLASS:TOP-SECRET

Cheers,
Bernard


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 99EA67FA20 for <[e-mail]>; Wed, 20 Jun 2007 05:58:04 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BD9D14220F for <[e-mail]>; Wed, 20 Jun 2007 05:57:09 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.503
X-Spam-Level: 
X-Spam-Status: No, score=-1.503 tagged_above=-50 required=4 tests=[AWL=0.961,  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 jkvo7S2tVJUy for <[e-mail]>; Wed, 20 Jun 2007 05:57:07 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 550E51421FC for <[e-mail]>; Wed, 20 Jun 2007 05:57:07 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 14:57:06 +0200
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 l5KCv5Sk001122;  Wed, 20 Jun 2007 14:57:05 +0200
Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp258.cisco.com [10.61.65.2]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KCuuDR026984;  Wed, 20 Jun 2007 12:56:57 GMT
Message-ID: <[e-mail]>
Date: Wed, 20 Jun 2007 14:56:54 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=520; t=1182344225; x=1183208225; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20Re=3A=20additional=20IANA=20consider ations |Sender:=20; bh=rkyICQbkNejmkFwfQ1scO6hKjNof2RSJypOZZSeX8B0=; b=kN5TbPipopVHwQZradKbyh54irNkdWI07sMKAPgIBPWrcu0k+VVN058vQ7V2/itJA29IQfHQ mcG+dI8CkJd8+M7RrRFPUWAEriFICqmykmf1i+qXcIid0lFoVl+1rfqj;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Cc: Eliot Lear <[e-mail]>, "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 12:58:04 -0000

Alexey Melnikov wrote:
>>>
>>> <t>
>>>    This section contains initial registrations for various protocol
>>>    elements specified in this memo, as well as a table that explains
>>>    what is required to add a new element.  Changing or removing an
>>>    existing element requires a standards action.
>>
> I disagree about removing existing elements. An element must never be 
> removed, it should be marked as "obsolete" instead.

You are, of course, correct.  Replace word "removing" with "obsoleting".




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 648767FA20 for <[e-mail]>; Wed, 20 Jun 2007 05:54:34 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2636114220F for <[e-mail]>; Wed, 20 Jun 2007 05:53:39 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.594
X-Spam-Level: 
X-Spam-Status: No, score=-1.594 tagged_above=-50 required=4 tests=[AWL=1.006,  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 DncZrEesxFyJ for <[e-mail]>; Wed, 20 Jun 2007 05:53:37 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id E31641421FC for <[e-mail]>; Wed, 20 Jun 2007 05:53:36 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 20 Jun 2007 13:53:30 +0100
Message-ID: <[e-mail]>
Date: Wed, 20 Jun 2007 13:52:05 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Bernard Desruisseaux <[e-mail]>, Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 12:54:34 -0000

Bernard Desruisseaux wrote:

> Hi Eliot,
>
> Your proposal doesn't take into account the existing
> Section 6 "Registration of Content Type Elements".
>
> We should either:
>
> 1- Extend this section to contain all templates.
> 2- Move this section *in* the IANA Considerations section.
> 3- Move this section *after* the IANA Considerations section.

IANA likes templates and all initial registrations to be subsections of 
a single top level section called "IANA considerations".
It is Ok to register things in other places, as long as the IANA 
considerations section contains pointers to relevant sections.

> Also, I think we should consider having 4 templates:
>
> - Registration of New Components
> - Registration of New Properties
> - Registration of New Parameters
> - Registration of New Values
>
> What do you think?

We can and should have 4 templates if they are sufficiently different.
In general I prefer separate templates, as it is easier to read (and 
this will also make IANA's job easier, as IANA people get occasionally 
confused by complex templates).

> Cheers,
> Bernard
>
> Eliot Lear wrote:
>
>> Hi,
>>
>> Apologies for this being in XML, but it is intended for insertion.  I 
>> propose the following be inserted at the top of the IANA 
>> Considerations section.
>>
>>
>> <t>
>>    This section contains initial registrations for various protocol
>>    elements specified in this memo, as well as a table that explains
>>    what is required to add a new element.  Changing or removing an
>>    existing element requires a standards action.
>
I disagree about removing existing elements. An element must never be 
removed, it should be marked as "obsolete" instead.

>>   In order to add
>>    a new element, where marked "RFC", that specification MUST
>>    make use of the following template:
>> </t>
>> <figure>
>> <artwork>
>> <![CDATA[
>>
>>    Protocol Element Type:
>>    (e.g., Component, Property, Property Parameter, etc)
>>    Protocol element name:
>>    (MUST NOT begin with "X-")
>>    Short Description:
>>    (What it is)
>>    Long Description:
>>    In what contexts are the element valid?
>>    (Specify, for instance, where a property would be valid)
>>    Does this protocol element modify other existing elements?
>>    If so, describe:
>>    (For example, if a property parameter, how does it modify the
>>    property?)
>>
>> ]]></artwork>
>> </figure>
>> <t>
>>    Each answer MAY contain a normative reference.  No default values
>>    are allowed for properties or parameters.  Implementations that
>>    make use of a new protocol element MUST assume that they will
>>    interact with implementations that do not understand it.
>> </t>
>>
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 67ADD80460 for <[e-mail]>; Tue, 19 Jun 2007 22:49:53 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2A143142219 for <[e-mail]>; Tue, 19 Jun 2007 22:48:58 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.493
X-Spam-Level: 
X-Spam-Status: No, score=-1.493 tagged_above=-50 required=4 tests=[AWL=0.971,  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 Bc5Pe-6Bn42v for <[e-mail]>; Tue, 19 Jun 2007 22:48:56 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 508B914220E for <[e-mail]>; Tue, 19 Jun 2007 22:48:56 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 07:48:55 +0200
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 l5K5mt3f032376;  Wed, 20 Jun 2007 07:48:55 +0200
Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4335.cisco.com [10.61.80.238]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5K5moDR016356;  Wed, 20 Jun 2007 05:48:50 GMT
Message-ID: <[e-mail]>
Date: Wed, 20 Jun 2007 07:48:47 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Re: additional IANA considerations
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=803; t=1182318535; x=1183182535; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20Re=3A=20additional=20IANA=20consider ations |Sender:=20; bh=k9T6oHA6ZNLH1dNRhhUAb4+q16+ngfoO8Oq8qogP3vY=; b=UUCZss1OknNdktpMkLQnHV0dwHrjbTfTkF0RKwhFhJQEaEIYFfM4Qf+D62KqcWQfqy4+h85e UUYaWShw66Iml5Tlla9EALZW05njw01iuttNJn/0AR8MMoGhQdk3Tm62;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Cc: Eliot Lear <[e-mail]>, "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 05:49:53 -0000

Bernard Desruisseaux wrote:
> Hi Eliot,
>
> Your proposal doesn't take into account the existing
> Section 6 "Registration of Content Type Elements".
>
> We should either:
>
> 1- Extend this section to contain all templates.
> 2- Move this section *in* the IANA Considerations section.

I think it was intended for (2), Bernard (insert in front of existing 
text).  I'm sorry if I didn't make that clear.  It wasn't a great "diff". 

> Also, I think we should consider having 4 templates:
>
> - Registration of New Components
> - Registration of New Properties
> - Registration of New Parameters
> - Registration of New Values
>
> What do you think?

I think there needs to be a substantial difference in the templates to 
justify four of them.  Do you think there is?

Eliot


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 93E4780490 for <[e-mail]>; Tue, 19 Jun 2007 17:23:45 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 53FBC142223 for <[e-mail]>; Tue, 19 Jun 2007 17:22:50 -0700 (PDT)
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.618, 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 S-5bfJ+xlyyF for <[e-mail]>; Tue, 19 Jun 2007 17:22:48 -0700 (PDT)
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 AAB2014221E for <[e-mail]>; Tue, 19 Jun 2007 17:22:48 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5K0Mfo5013503; Tue, 19 Jun 2007 19:22:41 -0500
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5JKEb1B005425; Tue, 19 Jun 2007 18:22:40 -0600
Received: from dhcp-amer-rmdc-csvpn-gw5-141-144-106-232.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2970108971182298905; Tue, 19 Jun 2007 17:21:45 -0700
Message-ID: <[e-mail]>
Date: Tue, 19 Jun 2007 20:21:46 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Eliot Lear <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
Cc: "[e-mail]" <[e-mail]>
Subject: [Ietf-calsify] Re: additional IANA considerations
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2007 00:23:46 -0000

Hi Eliot,

Your proposal doesn't take into account the existing
Section 6 "Registration of Content Type Elements".

We should either:

1- Extend this section to contain all templates.
2- Move this section *in* the IANA Considerations section.
3- Move this section *after* the IANA Considerations section.

Also, I think we should consider having 4 templates:

- Registration of New Components
- Registration of New Properties
- Registration of New Parameters
- Registration of New Values

What do you think?

Cheers,
Bernard

Eliot Lear wrote:
> Hi,
> 
> Apologies for this being in XML, but it is intended for insertion.  I 
> propose the following be inserted at the top of the IANA Considerations 
> section.
> 
> 
> <t>
>    This section contains initial registrations for various protocol
>    elements specified in this memo, as well as a table that explains
>    what is required to add a new element.  Changing or removing an
>    existing element requires a standards action.  In order to add
>    a new element, where marked "RFC", that specification MUST
>    make use of the following template:
> </t>
> <figure>
> <artwork>
> <![CDATA[
> 
>    Protocol Element Type:
>    (e.g., Component, Property, Property Parameter, etc)
>    Protocol element name:
>    (MUST NOT begin with "X-")
>    Short Description:
>    (What it is)
>    Long Description:
>    In what contexts are the element valid?
>    (Specify, for instance, where a property would be valid)
>    Does this protocol element modify other existing elements?
>    If so, describe:
>    (For example, if a property parameter, how does it modify the
>    property?)
> 
> ]]></artwork>
> </figure>
> <t>
>    Each answer MAY contain a normative reference.  No default values
>    are allowed for properties or parameters.  Implementations that
>    make use of a new protocol element MUST assume that they will
>    interact with implementations that do not understand it.
> </t>
> 




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 72F8D803A7 for <[e-mail]>; Mon, 18 Jun 2007 00:26:24 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30FE41422F2 for <[e-mail]>; Mon, 18 Jun 2007 00:25:29 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.705
X-Spam-Level: 
X-Spam-Status: No, score=-1.705 tagged_above=-50 required=4 tests=[AWL=0.759,  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 p-Xe4T+wTpcO for <[e-mail]>; Mon, 18 Jun 2007 00:25:27 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [212.254.247.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 03CF41422F1 for <[e-mail]>; Mon, 18 Jun 2007 00:25:26 -0700 (PDT)
Received: from adsl-247-6-fixip.tiscali.ch (ams3-dmznat-ext1.cisco.com [64.103.37.2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.13.3/8.13.3) with ESMTP id l5I7PGpR008280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jun 2007 09:25:18 +0200
DKIM-Signature: a=rsa-sha1; c=simple/simple; d=ofcourseimright.com; s=upstairs; t=1182151519; bh=0ny7QDF2p9oGk/YIA93AyHXqGVM=; h=Message-ID: Date:From:User-Agent:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=N31IsiXRG3GDdqJg4qkbKwm5IpYd7HQaiT7p4 fhVymUNc8jngBgyMp3NP804hJj0lwOU64JEssrZUP8UHnrGGaTjstCHjLdwJhJZejnL Qs7VyjbgvIMwNt41MOt+Cun2nNNzX5eJVJiQ6t66QPV8kXoyLFhk198g/Xf76557DyU =
Message-ID: <[e-mail]>
Date: Mon, 18 Jun 2007 09:25:10 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Bernard Desruisseaux <[e-mail]>, "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Ietf-calsify] additional IANA considerations
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2007 07:26:24 -0000

Hi,

Apologies for this being in XML, but it is intended for insertion.  I 
propose the following be inserted at the top of the IANA Considerations 
section.


<t>
    This section contains initial registrations for various protocol
    elements specified in this memo, as well as a table that explains
    what is required to add a new element.  Changing or removing an
    existing element requires a standards action.  In order to add
    a new element, where marked "RFC", that specification MUST
    make use of the following template:
</t>
<figure>
<artwork>
<![CDATA[

    Protocol Element Type:
    (e.g., Component, Property, Property Parameter, etc)
    Protocol element name:
    (MUST NOT begin with "X-")
    Short Description:
    (What it is)
    Long Description:
    In what contexts are the element valid?
    (Specify, for instance, where a property would be valid)
    Does this protocol element modify other existing elements?
    If so, describe:
    (For example, if a property parameter, how does it modify the
    property?)

]]></artwork>
</figure>
<t>
    Each answer MAY contain a normative reference.  No default values
    are allowed for properties or parameters.  Implementations that
    make use of a new protocol element MUST assume that they will
    interact with implementations that do not understand it.
</t>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AA6DF802A3 for <[e-mail]>; Sat, 16 Jun 2007 12:27:26 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 651B9142277 for <[e-mail]>; Sat, 16 Jun 2007 12:26:31 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.463
X-Spam-Level: 
X-Spam-Status: No, score=-1.463 tagged_above=-50 required=4 tests=[AWL=1.001,  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 kn3xjYVS3c2u for <[e-mail]>; Sat, 16 Jun 2007 12:26:29 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 23AFC142273 for <[e-mail]>; Sat, 16 Jun 2007 12:26:28 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2007 21:26:28 +0200
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 l5GJQRmn030460 for <[e-mail]>; Sat, 16 Jun 2007 21:26:27 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4219.cisco.com [10.61.80.122]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5GJQMDR018395 for <[e-mail]>; Sat, 16 Jun 2007 19:26:27 GMT
Message-ID: <[e-mail]>
Date: Sat, 16 Jun 2007 21:26:22 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4113; t=1182021987; x=1182885987; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20NOMCOM |Sender:=20; bh=E42u0KpfrW3B8/wq66cMyPxkBGA/3gj/sb4OMf7KAkU=; b=XV0verF2d+vOEu6rHLn3qXN4kmIKqnOy2m20A99GODNQQsP7pSO4im4NsIaXh+54WXWSVT7G bXCgeIOVjID4u+5JQ0sNKUsM5dOs0OXRZvYZj84drIHvDLxlM87+Prkg;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
Subject: [Ietf-calsify] NOMCOM
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Jun 2007 19:27:29 -0000

As you probably know, IETF chooses its leadership through the NOMCOM 
process.  In order for that process to work properly we need eligible 
members of the IETF community to volunteer to serve on the NOMCOM 
committee.  While NOMCOM does take some time, you get what you deserve 
if you leave the choice of leadership to others.  And so I urge you to 
volunteer.  Please see below on how to do that.


Thanks,

Eliot


From: Lakshminath Dondeti
To: IETF Announcement
Date: June 4, 2007
Subject: Nomcom 2007-8: First Call for Volunteers

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

Folks,

If you have attended 3 out of the past 5 IETF meetings, you are eligible to
serve on Nomcom 2007-2008.  Please volunteer and you may become one of the
voting members of the committee that selects about half of the members to the
IESG and IAB and one IAOC member.  RFC 3777 describes the process and the
responsibilities in detail.  Below is the list of people from the IESG, IAB and
IAOC whose terms end during the March 2008 IETF meeting.

IAOC:

Ed Juskevicius

IAB:

Leslie Daigle
Elwyn Davies
Kevin Fall
Olaf Kolkman
David Oran
Eric Rescorla

IESG:

Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area
Director Dan Romascanu -- Operations and Management Area Director Cullen
Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon
--- Routing Area Director Sam Hartman -- Security Area Director Magnus
Westerlund -- Transport Area Director

Before volunteering, please think about whether you want to be considered for
one of those positions instead.  If you are already convinced, please send an
email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please
read on)

To: [e-mail]
Subject: Nomcom 2007-8 Volunteer
Body:

<Your Full Name>   // As you enter in the IETF Registration Form,
                           // First/Given name followed by Last/Family Name
<Current Primary Affiliation> // typically what goes in the Company field
                                          //  in the IETF Registration Form
[<all email addresses used to Register for the past 5 IETF meetings>] <Preferred
email address>  //
<Telephone number>         // For confirmation if selected

Please expect an email response from me within 1-2 days stating whether you are
qualified or not.  If you don't receive anything, please re-send your email with
the tag (duplicate) in the subject line.

Not convinced yet?  Please consider that nomcom members play an important role
in shaping the leadership of the IETF.  If you are a people person, you will
enjoy meeting many of the active contributors to the IETF.  If you prefer
instead to read a lot of email, well, we have that too.  Being a nomcom member
is also an important responsibility: it requires adherence to confidentiality
rules and some time commitment from the members.  The term begins just prior to
the Chicago meeting and we expect most of the work to be completed by January
2008.  During this period, the nomcom members

-- collect requirements from the community and interviews candidates
     during the Chicago and Vancouver IETF meetings
-- review candidates' statements and weighs community feedback
-- participate in candidate selection deliberations (weekly conferences
calls)

Nomcom members are selected following a publicly verifiable random selection
method specified in RFC 3797.

For the nomcom to work as it should, the pool from which the volunteers are
chosen should be as large as possible. The more people who volunteer, the better
chance we have of choosing a random yet representative cross section of the IETF
population.

Ensuring the leadership of the IETF is fair and balanced and comprised of those
who can lead the IETF in the right direction is an important responsibility that
rests on the IETF participants at large.  Volunteering for the nomcom is a good
way of contributing in that direction.  So please volunteer!

thanks,
Lakshminath


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2E9DE7F8E0 for <[e-mail]>; Thu, 14 Jun 2007 04:53:48 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D531B142227 for <[e-mail]>; Thu, 14 Jun 2007 04:52:52 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.628
X-Spam-Level: 
X-Spam-Status: No, score=-1.628 tagged_above=-50 required=4 tests=[AWL=0.971,  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 afZ8WulaSJYs for <[e-mail]>; Thu, 14 Jun 2007 04:52:47 -0700 (PDT)
Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BF1B1142223 for <[e-mail]>; Thu, 14 Jun 2007 04:52:46 -0700 (PDT)
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5EBqYOX019007 for <[e-mail]>; Thu, 14 Jun 2007 14:52:42 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 14 Jun 2007 14:52:27 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:52:27 +0300
Received: from [172.21.40.100] (esdhcp040100.research.nokia.com [172.21.40.100]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5EBqPZ4003509 for <[e-mail]>; Thu, 14 Jun 2007 14:52:26 +0300
Message-ID: <[e-mail]>
Date: Thu, 14 Jun 2007 14:52:24 +0300
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jun 2007 11:52:27.0492 (UTC) FILETIME=[7AECA240:01C7AE7A]
X-Nokia-AV: Clean
Subject: [Ietf-calsify] Reminder: Jabber chat today at 4:00pm CEDT / 10:00am EDT / 7:00am PDT
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2007 11:53:49 -0000

Hi,

Address is [e-mail].

On the agenda:

- finishing up rfc2445bis and closing its remaining issues
- moving on to rfc2446bis issues

See you there!

Cheers,
Aki


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 738A27F67E for <[e-mail]>; Thu, 14 Jun 2007 02:48:50 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2243B14221E for <[e-mail]>; Thu, 14 Jun 2007 02:47:55 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-50 required=4 tests=[AWL=0.981,  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 y-Hqkjn6jfLw for <[e-mail]>; Thu, 14 Jun 2007 02:47:53 -0700 (PDT)
Received: from mgw-ext11.nokia.com (smtp.nokia.com [131.228.20.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B9CBD14221D for <[e-mail]>; Thu, 14 Jun 2007 02:47:52 -0700 (PDT)
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5E9lQdM010892; Thu, 14 Jun 2007 12:47:43 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 14 Jun 2007 12:47:23 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 14 Jun 2007 12:47:23 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 12:47:23 +0300
Received: from [172.21.40.100] (esdhcp040100.research.nokia.com [172.21.40.100]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5E9lLlS002469; Thu, 14 Jun 2007 12:47:21 +0300
Message-ID: <[e-mail]>
Date: Thu, 14 Jun 2007 12:47:20 +0300
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: ext Reinhold Kainhofer <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 80: security considerations section -- proposal
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jun 2007 09:47:23.0135 (UTC) FILETIME=[01FAA0F0:01C7AE69]
X-Nokia-AV: Clean
Cc: [e-mail]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2007 09:48:50 -0000

ext Reinhold Kainhofer wrote:
>> This is a point that has been discussed a lot. It is true that RFC2119
>> text should only be used when there is an actual implementation choice
>> that is observable from the outside. Here, I agree that a "MUST" is just
>> hand-waiving, so I'm ok making it a "must" instead.
> 
> I think it's rather a SHOULD (or a should?). It'a really up to the groupware 
> server developers/designers and out of scope for the data format definition. 
> If a server team has good reasons against implementing some security measure, 
> it's their business, not ours.

Yes, agree. And this is why it says capabilities. It's always in the 
admin's or user's discretion whether to turn them on.

Cheers,
Aki


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 402657F5C2 for <[e-mail]>; Thu, 14 Jun 2007 01:02:05 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 84229142211 for <[e-mail]>; Thu, 14 Jun 2007 01:01:10 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.365
X-Spam-Level: 
X-Spam-Status: No, score=-1.365 tagged_above=-50 required=4 tests=[AWL=1.234,  BAYES_00=-2.599, SUBJECT_EXCESS_QP=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 MvO1JTgbfBX0 for <[e-mail]>; Thu, 14 Jun 2007 01:01:08 -0700 (PDT)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 167D214220D for <[e-mail]>; Thu, 14 Jun 2007 01:01:07 -0700 (PDT)
Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l5E813sn003517 for <[e-mail]>; Thu, 14 Jun 2007 10:01:03 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Issue 80: security considerations section =?iso-8859-1?q?--=09proposal?=
Date: Thu, 14 Jun 2007 10:00:58 +0200
User-Agent: KMail/1.9.5 + Features
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2007 08:02:06 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Donnerstag, 14. Juni 2007 schrieb Aki Niemi:
> Hi Oliver,
>
> This is a point that has been discussed a lot. It is true that RFC2119
> text should only be used when there is an actual implementation choice
> that is observable from the outside. Here, I agree that a "MUST" is just
> hand-waiving, so I'm ok making it a "must" instead.

I think it's rather a SHOULD (or a should?). It'a really up to the groupware 
server developers/designers and out of scope for the data format definition. 
If a server team has good reasons against implementing some security measure, 
it's their business, not ours.

Cheers, 
Reinhold

> > Am Dienstag, 12. Juni 2007 09:54 schrieb Aki Niemi:
> >>    <p>
> >>      Because calendaring and scheduling information is very
> >>      privacy-sensitive, the protocol used for the transmission of
> >>      calendaring and scheduling information MUST have capabilities to
> >>      protect the information from possible threats, such as
> >>      eavesdropping, replay, message insertion, deletion, modification
> >>      and man-in-the-middle attacks.
> >>    </p>


- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGcPW+TqjEwhXvPN0RAuPXAKCOPxuV7vFc52Irrj/06tRAO28GgwCgl4HJ
Hj69uRsHbxBUOc/TonYsH4o=
=V7+Z
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 90DA07F552 for <[e-mail]>; Thu, 14 Jun 2007 00:25:27 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BEF6B142211 for <[e-mail]>; Thu, 14 Jun 2007 00:24:31 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.609
X-Spam-Level: 
X-Spam-Status: No, score=-1.609 tagged_above=-50 required=4 tests=[AWL=0.990,  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 NlgnJdmgTDHo for <[e-mail]>; Thu, 14 Jun 2007 00:24:29 -0700 (PDT)
Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E953A14220D for <[e-mail]>; Thu, 14 Jun 2007 00:24:28 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5E7OJ1c014740; Thu, 14 Jun 2007 10:24:24 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 14 Jun 2007 10:24:02 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 10:24:03 +0300
Received: from [172.21.40.100] (esdhcp040100.research.nokia.com [172.21.40.100]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5E7O0g3014520; Thu, 14 Jun 2007 10:24:01 +0300
Message-ID: <[e-mail]>
Date: Thu, 14 Jun 2007 10:24:00 +0300
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: ext Oliver Block <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 80: security considerations section --	proposal
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jun 2007 07:24:03.0063 (UTC) FILETIME=[FBEFC870:01C7AE54]
X-Nokia-AV: Clean
Cc: [e-mail]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2007 07:25:31 -0000

Hi Oliver,

This is a point that has been discussed a lot. It is true that RFC2119 
text should only be used when there is an actual implementation choice 
that is observable from the outside. Here, I agree that a "MUST" is just 
hand-waiving, so I'm ok making it a "must" instead.

Cheers,
Aki

ext Oliver Block wrote:
> Hello Aki,
> 
> even though I like your proposal and to know that my calendar data is safe, Is 
> the MUST admissible in this context?
> 
> <copy src="rfc2119">
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> </copy>
> 
> Regards,
> 
> Oliver
> 
> Am Dienstag, 12. Juni 2007 09:54 schrieb Aki Niemi:
>> In one of the recent Jabber chats, I promised to take a stab at new text
>> for the section. Here's the proposal:
>>
>> <section title='Security Considerations'>
>>
>>    <p>
>>      Because calendaring and scheduling information is very
>>      privacy-sensitive, the protocol used for the transmission of
>>      calendaring and scheduling information MUST have capabilities to
>>      protect the information from possible threats, such as
>>      eavesdropping, replay, message insertion, deletion, modification
>>      and man-in-the-middle attacks.
>>    </p>
>>
>>    <p>
>>      As this document only defines the data format and media type of
>>      text/calendar that is independent of any calendar service or
>>      protocol, it is up to the actual protocol specifications such as
>>      <xref target="I-D.xxx">iTIP</xref>, <xref
>>      target="I-D.xxx">iMIP</xref> and <xref
>>      target="RFC4791">CalDAV</xref> to describe the threats that the
>>      above attacks present, as well as ways in which to mitigate them.
>>    </p>
>>
>> In other words, rfc2445bis would now be completely silent about
>> authorization issues, and instead move responsibility over to actual
>> calendaring protocols and/or services. I'll note that a similar approach
>> has been taken in at least in RFC3863, Presence Information Data Format
>> (PIDF).
>>
>> Any opinions?
>>
>> Cheers,
>> Aki
>> (as individual contributor)
>> _______________________________________________
>> Ietf-calsify mailing list
>> [e-mail]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C27B87F67E for <[e-mail]>; Wed, 13 Jun 2007 13:13:26 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F57D142219 for <[e-mail]>; Wed, 13 Jun 2007 13:12:31 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.213
X-Spam-Level: 
X-Spam-Status: No, score=-1.213 tagged_above=-50 required=4 tests=[AWL=1.251,  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 YxWjiP0f48Fk for <[e-mail]>; Wed, 13 Jun 2007 13:12:29 -0700 (PDT)
Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2D52914220E for <[e-mail]>; Wed, 13 Jun 2007 13:12:28 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-176-061.pools.arcor-ip.net [84.63.176.61]) by post.webmailer.de (klopstock mo47) (RZmta 7.2) with ESMTP id H0530aj5DH2kh9 for <[e-mail]>; Wed, 13 Jun 2007 22:12:27 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Issue 80: security considerations section -- proposal
Date: Wed, 13 Jun 2007 22:10:45 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-RZG-AUTH: jsAgD75E4FZRsMYse5W8COLJ40bV42cELvihCND/Uu2brXmKBiVnjTTA02o=
X-RZG-CLASS-ID: mo00
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2007 20:13:27 -0000

Hello Aki,

even though I like your proposal and to know that my calendar data is safe, Is 
the MUST admissible in this context?

<copy src="rfc2119">
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
</copy>

Regards,

Oliver

Am Dienstag, 12. Juni 2007 09:54 schrieb Aki Niemi:
> In one of the recent Jabber chats, I promised to take a stab at new text
> for the section. Here's the proposal:
>
> <section title='Security Considerations'>
>
>    <p>
>      Because calendaring and scheduling information is very
>      privacy-sensitive, the protocol used for the transmission of
>      calendaring and scheduling information MUST have capabilities to
>      protect the information from possible threats, such as
>      eavesdropping, replay, message insertion, deletion, modification
>      and man-in-the-middle attacks.
>    </p>
>
>    <p>
>      As this document only defines the data format and media type of
>      text/calendar that is independent of any calendar service or
>      protocol, it is up to the actual protocol specifications such as
>      <xref target="I-D.xxx">iTIP</xref>, <xref
>      target="I-D.xxx">iMIP</xref> and <xref
>      target="RFC4791">CalDAV</xref> to describe the threats that the
>      above attacks present, as well as ways in which to mitigate them.
>    </p>
>
> In other words, rfc2445bis would now be completely silent about
> authorization issues, and instead move responsibility over to actual
> calendaring protocols and/or services. I'll note that a similar approach
> has been taken in at least in RFC3863, Presence Information Data Format
> (PIDF).
>
> Any opinions?
>
> Cheers,
> Aki
> (as individual contributor)
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7F09E7F5CC for <[e-mail]>; Wed, 13 Jun 2007 06:40:13 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2ECF5142203 for <[e-mail]>; Wed, 13 Jun 2007 06:39:18 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.947
X-Spam-Level: 
X-Spam-Status: No, score=-1.947 tagged_above=-50 required=4 tests=[AWL=0.651,  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 Xtgr+Fri8Zgz for <[e-mail]>; Wed, 13 Jun 2007 06:39:16 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4C20714220C for <[e-mail]>; Wed, 13 Jun 2007 06:39:16 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5DDd9U7031277; Wed, 13 Jun 2007 07:39:10 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5DDCkHH006846; Wed, 13 Jun 2007 07:39:09 -0600
Received: from bdesruis-ca.ca.oracle.com by acsmt351.oracle.com with ESMTP id 2893070791181741934; Wed, 13 Jun 2007 06:38:54 -0700
Message-ID: <[e-mail]>
Date: Wed, 13 Jun 2007 09:38:53 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Aki Niemi <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 80: security considerations section -- proposal
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
Cc: [e-mail]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2007 13:40:13 -0000

+1

Aki Niemi wrote:
> Hi all,
> 
> A while back, Jay posted an issue about the security considerations of 
> rfc2445bis, which is tracked as issue 80.
> 
> In one of the recent Jabber chats, I promised to take a stab at new text 
> for the section. Here's the proposal:
> 
> <section title='Security Considerations'>
> 
>   <p>
>     Because calendaring and scheduling information is very
>     privacy-sensitive, the protocol used for the transmission of
>     calendaring and scheduling information MUST have capabilities to
>     protect the information from possible threats, such as
>     eavesdropping, replay, message insertion, deletion, modification
>     and man-in-the-middle attacks.
>   </p>
> 
>   <p>
>     As this document only defines the data format and media type of
>     text/calendar that is independent of any calendar service or
>     protocol, it is up to the actual protocol specifications such as
>     <xref target="I-D.xxx">iTIP</xref>, <xref
>     target="I-D.xxx">iMIP</xref> and <xref
>     target="RFC4791">CalDAV</xref> to describe the threats that the
>     above attacks present, as well as ways in which to mitigate them.
>   </p>
> 
> In other words, rfc2445bis would now be completely silent about 
> authorization issues, and instead move responsibility over to actual 
> calendaring protocols and/or services. I'll note that a similar approach 
> has been taken in at least in RFC3863, Presence Information Data Format 
> (PIDF).
> 
> Any opinions?
> 
> Cheers,
> Aki
> (as individual contributor)
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0DF587F994 for <[e-mail]>; Tue, 12 Jun 2007 23:42:43 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B0D93142210 for <[e-mail]>; Tue, 12 Jun 2007 23:41:47 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-50 required=4 tests=[AWL=1.000,  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 LF1+RAdwkXD0 for <[e-mail]>; Tue, 12 Jun 2007 23:41:46 -0700 (PDT)
Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9F44314220F for <[e-mail]>; Tue, 12 Jun 2007 23:41:45 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5D6fagf015075; Wed, 13 Jun 2007 09:41:37 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 13 Jun 2007 09:41:32 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 09:41:32 +0300
Received: from [172.21.41.89] (esdhcp04189.research.nokia.com [172.21.41.89]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5D6fQhV000473; Wed, 13 Jun 2007 09:41:30 +0300
Message-ID: <[e-mail]>
Date: Wed, 13 Jun 2007 09:41:26 +0300
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: ext Reinhold Kainhofer <[e-mail]>
Subject: Re: [Ietf-calsify] I18n considerations section in rfc2445bis
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 13 Jun 2007 06:41:32.0168 (UTC) FILETIME=[E1125880:01C7AD85]
X-Nokia-AV: Clean
Cc: [e-mail]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2007 06:42:43 -0000

ext Reinhold Kainhofer wrote:
>>      All the implementations of iCalendar conformant to this
>>      specification MUST generate UTF-8 and accept either UTF-8 or
>>      US-ASCII encoding.
> 
> Hmm, isn't US-ASCII a subset of UTF-8? What's the exact meaning of the second 
> part? An Implementation that only accepts US-ASCII is worthless, as it breaks 
> with all international characters (German umlaute, French accents, the 
> Spanish ñ, etc.), and should not be considered conformant in my opinion. And 
> an implementation that accepts UTF-8 automatically accepts US-ASCII.

This text was supposed to merely point out in summary what the 
specification says elsewhere. Namely that UTF-8 is the default charset, 
but implementations must also accept iCalendar objects whose MIME type 
has s charset=us-ascii parameter.

I'd welcome suggestions for better wording; I realize this is important 
to get right and definitely don't want this sections to say anything 
contradictory to the main body of text.

Cheers,
Aki


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C1FBB7F713 for <[e-mail]>; Tue, 12 Jun 2007 10:33:47 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6FF1214220C for <[e-mail]>; Tue, 12 Jun 2007 10:32:52 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.687
X-Spam-Level: 
X-Spam-Status: No, score=-0.687 tagged_above=-50 required=4 tests=[AWL=1.913,  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 f6lxEKQzRsNF for <[e-mail]>; Tue, 12 Jun 2007 10:32:50 -0700 (PDT)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by laweleka.osafoundation.org (Postfix) with ESMTP id 663F9142209 for <[e-mail]>; Tue, 12 Jun 2007 10:32:50 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id d30so488048and for <[e-mail]>; Tue, 12 Jun 2007 10:32:49 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Sc6LTITobgw6UnxyO8JELzzSO2ZLtAFzefMxwMm99sNH7IJZx5E0vWJiSnayFKlvdsGJZ8EFv+zEnzvcCBXyWqhZfVMwrublaYoeJF2FOsUARC2wNjreT9M25nrDBEZIdhWuPXzHpyW3n/7DpKCsqL/MOY0GB/muf+2gjr5QP2s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bnXz8Lv8agqtEumbj/iCC0GZaUfB02F5PeyqNbfGSY3MKIz4fFSXJAcZDwwpt8uyJlNBxJc8G5MZ3/r+W2n9ahNkrnbhC4FJqor6u5j2yvguLOE/5YQopD7+4/CX456laokavN68KE7+cUsYrDYL4GwoFp0xNXSz9v5IB1B4nKM=
Received: by 10.100.42.7 with SMTP id p7mr4237112anp.1181669567508; Tue, 12 Jun 2007 10:32:47 -0700 (PDT)
Received: by 10.100.124.6 with HTTP; Tue, 12 Jun 2007 10:32:47 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 12 Jun 2007 10:32:47 -0700
From: "Mike Samuel" <[e-mail]>
To: "Reinhold Kainhofer" <[e-mail]>
Subject: Re: [Ietf-calsify] I18n considerations section in rfc2445bis
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2007 17:33:47 -0000

How many projects out there support unicode pages 0x100000 - 0x10ffff?

Do most of the java projects out there support proper UTF-8 or will
they UTF-16 encode codepoints >=3D 0x10000 the way java.lang.String
does?

mike



On 12/06/07, Reinhold Kainhofer <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Dienstag, 12. Juni 2007 schrieb Aki Niemi:
> > The current rfc2445bis draft has an internationalization considerations
> > section but it's empty. How about:
> >
> > <section title=3D'Internationalization Considerations'>
> >
> >    <p>
> >      All the implementations of iCalendar conformant to this
> >      specification MUST generate UTF-8 and accept either UTF-8 or
> >      US-ASCII encoding.
>
> Hmm, isn't US-ASCII a subset of UTF-8? What's the exact meaning of the se=
cond
> part? An Implementation that only accepts US-ASCII is worthless, as it br=
eaks
> with all international characters (German umlaute, French accents, the
> Spanish =F1, etc.), and should not be considered conformant in my opinion=
. And
> an implementation that accepts UTF-8 automatically accepts US-ASCII.
>
>
> Cheers,
> Reinhold
>
> - --
> - ------------------------------------------------------------------
> Reinhold Kainhofer, Vienna University of Technology, Austria
> email: [e-mail], http://reinhold.kainhofer.com/
>  * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac=
.at/
>  * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGbm0ZTqjEwhXvPN0RAjRZAJ9EAvz4HthAM12kMsfFZtT6Bx8NgwCgic0A
> 2zvTAATl17vCAnNbsi2o77k=3D
> =3Ddcvn
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B1D517F517 for <[e-mail]>; Tue, 12 Jun 2007 02:55:14 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 61F9C1421F9 for <[e-mail]>; Tue, 12 Jun 2007 02:54:19 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-50 required=4 tests=[AWL=1.252,  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 2P+nsNf-XWBH for <[e-mail]>; Tue, 12 Jun 2007 02:54:12 -0700 (PDT)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C8D8C1421FB for <[e-mail]>; Tue, 12 Jun 2007 02:54:11 -0700 (PDT)
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l5C9s6L2013547 for <[e-mail]>; Tue, 12 Jun 2007 11:54:08 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] I18n considerations section in rfc2445bis
Date: Tue, 12 Jun 2007 11:53:24 +0200
User-Agent: KMail/1.9.5 + Features
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2007 09:55:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 12. Juni 2007 schrieb Aki Niemi:
> The current rfc2445bis draft has an internationalization considerations
> section but it's empty. How about:
>
> <section title='Internationalization Considerations'>
>
>    <p>
>      All the implementations of iCalendar conformant to this
>      specification MUST generate UTF-8 and accept either UTF-8 or
>      US-ASCII encoding.

Hmm, isn't US-ASCII a subset of UTF-8? What's the exact meaning of the second 
part? An Implementation that only accepts US-ASCII is worthless, as it breaks 
with all international characters (German umlaute, French accents, the 
Spanish ñ, etc.), and should not be considered conformant in my opinion. And 
an implementation that accepts UTF-8 automatically accepts US-ASCII.


Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGbm0ZTqjEwhXvPN0RAjRZAJ9EAvz4HthAM12kMsfFZtT6Bx8NgwCgic0A
2zvTAATl17vCAnNbsi2o77k=
=dcvn
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AF5AD7F9FB for <[e-mail]>; Tue, 12 Jun 2007 02:06:25 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 59F9D1421FB for <[e-mail]>; Tue, 12 Jun 2007 02:05:30 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.589
X-Spam-Level: 
X-Spam-Status: No, score=-1.589 tagged_above=-50 required=4 tests=[AWL=1.010,  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 mL2HOrgEZZXy for <[e-mail]>; Tue, 12 Jun 2007 02:05:28 -0700 (PDT)
Received: from mgw-ext12.nokia.com (smtp.nokia.com [131.228.20.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BBD21421F7 for <[e-mail]>; Tue, 12 Jun 2007 02:05:28 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C94xUi011017 for <[e-mail]>; Tue, 12 Jun 2007 12:05:25 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 12 Jun 2007 12:05:21 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 12:05:20 +0300
Received: from [172.21.40.99] (esdhcp04099.research.nokia.com [172.21.40.99]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C95IHD001158 for <[e-mail]>; Tue, 12 Jun 2007 12:05:19 +0300
Message-ID: <[e-mail]>
Date: Tue, 12 Jun 2007 12:05:19 +0300
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Jun 2007 09:05:20.0465 (UTC) FILETIME=[CD863C10:01C7ACD0]
X-Nokia-AV: Clean
Subject: [Ietf-calsify] I18n considerations section in rfc2445bis
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2007 09:06:25 -0000

Hi all,

The current rfc2445bis draft has an internationalization considerations 
section but it's empty. How about:

<section title='Internationalization Considerations'>

   <p>
     All the implementations of iCalendar conformant to this
     specification MUST generate UTF-8 and accept either UTF-8 or
     US-ASCII encoding.
   </p>

</section>

Cheers,
Aki
(as individual contributor)


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2357D7F9EB for <[e-mail]>; Tue, 12 Jun 2007 00:55:57 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C7A9F14221E for <[e-mail]>; Tue, 12 Jun 2007 00:55:01 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.578
X-Spam-Level: 
X-Spam-Status: No, score=-1.578 tagged_above=-50 required=4 tests=[AWL=1.021,  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 c6X5E08Ki2UK for <[e-mail]>; Tue, 12 Jun 2007 00:55:00 -0700 (PDT)
Received: from mgw-ext12.nokia.com (smtp.nokia.com [131.228.20.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B0ACB1421FB for <[e-mail]>; Tue, 12 Jun 2007 00:54:59 -0700 (PDT)
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C7sV9p012842 for <[e-mail]>; Tue, 12 Jun 2007 10:54:55 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 12 Jun 2007 10:54:53 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 10:54:53 +0300
Received: from [172.21.40.99] (esdhcp04099.research.nokia.com [172.21.40.99]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C7spgb018950 for <[e-mail]>; Tue, 12 Jun 2007 10:54:52 +0300
Message-ID: <[e-mail]>
Date: Tue, 12 Jun 2007 10:54:52 +0300
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Jun 2007 07:54:53.0343 (UTC) FILETIME=[F5F69AF0:01C7ACC6]
X-Nokia-AV: Clean
Subject: [Ietf-calsify] Issue 80: security considerations section -- proposal
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2007 07:55:57 -0000

Hi all,

A while back, Jay posted an issue about the security considerations of 
rfc2445bis, which is tracked as issue 80.

In one of the recent Jabber chats, I promised to take a stab at new text 
for the section. Here's the proposal:

<section title='Security Considerations'>

   <p>
     Because calendaring and scheduling information is very
     privacy-sensitive, the protocol used for the transmission of
     calendaring and scheduling information MUST have capabilities to
     protect the information from possible threats, such as
     eavesdropping, replay, message insertion, deletion, modification
     and man-in-the-middle attacks.
   </p>

   <p>
     As this document only defines the data format and media type of
     text/calendar that is independent of any calendar service or
     protocol, it is up to the actual protocol specifications such as
     <xref target="I-D.xxx">iTIP</xref>, <xref
     target="I-D.xxx">iMIP</xref> and <xref
     target="RFC4791">CalDAV</xref> to describe the threats that the
     above attacks present, as well as ways in which to mitigate them.
   </p>

In other words, rfc2445bis would now be completely silent about 
authorization issues, and instead move responsibility over to actual 
calendaring protocols and/or services. I'll note that a similar approach 
has been taken in at least in RFC3863, Presence Information Data Format 
(PIDF).

Any opinions?

Cheers,
Aki
(as individual contributor)


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 55D5C7F50F for <[e-mail]>; Thu,  7 Jun 2007 06:38:40 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 03E35142206 for <[e-mail]>; Thu,  7 Jun 2007 06:37:45 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.397
X-Spam-Level: 
X-Spam-Status: No, score=-1.397 tagged_above=-50 required=4 tests=[AWL=1.068,  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 qY5W92Dhlbh2 for <[e-mail]>; Thu,  7 Jun 2007 06:37:39 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id A27731421FB for <[e-mail]>; Thu,  7 Jun 2007 06:37:38 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Jun 2007 15:37:38 +0200
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 l57Dbbg7004465 for <[e-mail]>; Thu, 7 Jun 2007 15:37:37 +0200
Received: from elear-mac.local (ams3-vpn-dhcp437.cisco.com [10.61.65.181]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l57DbaDR013912 for <[e-mail]>; Thu, 7 Jun 2007 13:37:37 GMT
Message-ID: <[e-mail]>
Date: Thu, 07 Jun 2007 14:37:36 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=26; t=1181223457; x=1182087457; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20reminder=3A=20calsify=20jabber=20session=20starts=20at=204=3A 00pm=20CEDT=20/=2010=3A00am=0A=20EDT=20/=207=3A00am=20PDT |Sender:=20; bh=MwwsPhluBPN4jlD666hTIPMgF+DnZU95ejSkU6BylBQ=; b=USqKDIYR+XqvCcz3LrknDuWLCVD6HQ8RuBHh8aPVlg3rwzXko+UPcmttuqvqBd8JLjdldIXc 5zFHvaCBrEwrLJ2mosvCkoxb7eEqkJITHsMR8MzlEdqc75DAQ9mVuuR9;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] reminder: calsify jabber session starts at 4:00pm CEDT / 10:00am EDT / 7:00am PDT
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 13:38:40 -0000

[e-mail].


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 160497F99A for <[e-mail]>; Thu,  7 Jun 2007 02:03:39 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BA6B7142202 for <[e-mail]>; Thu,  7 Jun 2007 02:02:43 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.385
X-Spam-Level: 
X-Spam-Status: No, score=-1.385 tagged_above=-50 required=4 tests=[AWL=1.080,  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 1eFvU4dL6pIn for <[e-mail]>; Thu,  7 Jun 2007 02:02:40 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5DD50142201 for <[e-mail]>; Thu,  7 Jun 2007 02:02:39 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Jun 2007 11:02:37 +0200
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 l5792aHv015896 for <[e-mail]>; Thu, 7 Jun 2007 11:02:36 +0200
Received: from elear-mac.local (ams3-vpn-dhcp96.cisco.com [10.61.64.96]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5792ZDR016975 for <[e-mail]>; Thu, 7 Jun 2007 09:02:36 GMT
Message-ID: <[e-mail]>
Date: Thu, 07 Jun 2007 10:02:35 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: multipart/mixed; boundary="------------000906010006090303090704"
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23005; t=1181206956; x=1182070956; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20[Fwd=3A=20[IANA=20#79134]=20Early=20Review=20of=20draft-ietf- calsify-rfc2445bis] |Sender:=20; bh=jsdRewuM+r/ZXQhxrc7zZkWnGhTp14URLGzEqxz7K3o=; b=Q/NT7M1oSjZEpzhguhwSNznouj4oIrGsSXxayZGl1TeyzgIyjZ0w3AwrVP8KyWF/nDWhdKFr s6espkStgHdSOA+/yPAVneGqBgYTPfNS8ISXoFtyI8jd22XRjxrlMcHf;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] [Fwd: [IANA #79134] Early Review of draft-ietf-calsify-rfc2445bis]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2007 09:03:39 -0000

This is a multi-part message in MIME format.
--------------000906010006090303090704
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

FYI - perhaps for discussion on today's jabber?

--------------000906010006090303090704
Content-Type: message/rfc822;
	name="[IANA #79134] Early Review of draft-ietf-calsify-rfc2445bis.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename*0="[IANA #79134] Early Review of
	draft-ietf-calsify-rfc2445bis."; filename*1="eml"

X-Account-Key: account2
X-Mozilla-Keys: 
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); 
	Wed, 6 Jun 2007 22:03:25 +0200
Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by
	xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 6 Jun 2007 22:03:25 +0200
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 6 Jun 2007 13:03:17 -0700
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-5.cisco.com with ESMTP; 06 Jun 2007 13:03:17 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l56K3DCx008665
	for <[e-mail]>; Wed, 6 Jun 2007 13:03:13 -0700
Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l56K3CV2008658
	for <[e-mail]>; Wed, 6 Jun 2007 20:03:13 GMT
Received: from rs.icann.org ([208.77.188.50])
	by sj-inbound-e.cisco.com with ESMTP; 06 Jun 2007 13:03:08 -0700
X-from-outside-Cisco: 208.77.188.50
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAKauZkbQTbwy/2dsb2JhbAA
X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="7749397:sNHT35135958"
Received: by rs.icann.org (Postfix, from userid 80)
	id 12AAC3F420; Wed,  6 Jun 2007 13:03:45 -0700 (PDT)
Subject: [IANA #79134] Early Review of draft-ietf-calsify-rfc2445bis 
From: "Michelle Cotton via RT" <[e-mail]>
Reply-To: [e-mail]
In-Reply-To: 
References: <[e-mail]>
Message-ID: <[e-mail]>
Precedence: bulk
X-RT-Loop-Prevention: IANA
RT-Ticket: IANA #79134
Managed-by: RT 3.5.HEAD (http://www.bestpractical.com/rt/)
RT-Originator: [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-RT-Original-Encoding: utf-8
Date: Wed, 06 Jun 2007 13:03:44 -0700
Authentication-Results: sj-dkim-4; header.From=[e-mail];
	dkim=neutral
Return-Path: [e-mail]
X-OriginalArrivalTime: 06 Jun 2007 20:03:17.0064 (UTC)
	FILETIME=[B8EEB480:01C7A875]

Eliot,

Apologies for the delay in getting this information to you.  Your document has been reviewed.
Our reviewer had the following comments (see below).  We hope you find this information helpful.
We had created this ticket to make sure that this request was completed.  I'm closing this ticket at this 
time as we have provided early feedback.

IANA will also review the document when it goes through IESG Last Call.

Thank you,

Michelle Cotton
IANA


IANA has Questions..

In general the IANA Considerations in this document is superb.
However there are still a few open questions.

The main IANA Considerations (section 9) lays out the set of
sub-registries to get created (see table below) but doesn't
suggest a name of the overarching calendar registry.

QUESTION: What should be the name of this overarching registry?
Should it be "iCalendar Parameters" or something else?

The document then lays out twelve additional actions for IANA,
summerized by the following table (plus an additional mime-type
registration) and then clearly enumerated in the following sections:

+---------------+------------------------------------+--------------+
| Registry Name | Registration Requirements | Reference |
+---------------+------------------------------------+--------------+
| Components | RFC, Expert Review | Section 9.1 |
| Properties | RFC, Expert Review | Section 9.2 |
| Property | RFC, Expert Review | Section 9.3 |
| Parameters | | |
| Value Data | Standards Action Required for new | Section 9.4 |
| Type Values | values that modify existing | |
| | parameters | |
| Calendar User | RFC, Expert Review | Section 9.5 |
| Type Values | | |
| Free/Busy | RFC, Expert Review | Section 9.6 |
| Time Type | | |
| Values | | |
| Participation | Internet Standards Action for | Section 9.7 |
| Status Values | VEVENTs, otherwise Expert Review | |
| Relationship | RFC, Expert Review | Section 9.8 |
| Type Values | | |
| Participation | RFC, Expert Review | Section 9.9 |
| Role Values | | |
| Action Values | RFC, Expert Review | Section 9.10 |
| Method Values | RFC, Expert Review | Section 9.11 |
+---------------+------------------------------------+--------------+



9.1. Components Registry

The following table is to be used to initialize the components
registry.

+----------------+---------+------------------------+
| Component Name | Status | Reference |
+----------------+---------+------------------------+
| VCALENDAR | Current | RFCXXXX, Section 3.4 |
| VEVENT | Current | RFCXXXX, Section 3.6.1 |
| VTODO | Current | RFCXXXX, Section 3.6.2 |
| VJOURNAL | Current | RFCXXXX, Section 3.6.3 |
| VFREEBUSY | Current | RFCXXXX, Section 3.6.4 |
| VTIMEZONE | Current | RFCXXXX, Section 3.6.5 |
| VALARM | Current | RFCXXXX, Section 3.6.6 |
| STANDARD | Current | RFCXXXX, Section 3.6.5 |
| DAYLIGHT | Current | RFCXXXX, Section 3.6.5 |
+----------------+---------+------------------------+

9.2. Properties Registry

Properties that are registered with IANA are to be document via the
RFC process. It is not necessary for properties to be placed on the
standards track to be registered unless the usage of other standard
properties, parameters, or enumerations are changed. Components
specifically require standards action. However, each property MUST
specify what standard parameters, if any, are allowed, and in what
components the property is valid (e.g., "VEVENT", "VTODO", etc.).
The IANA is requested to maintain a table of such properties with
pointers to appropriate reference documents.

The following table is to be used to initialize the property
registry.

+------------------+------------+---------------------------+
| Property Name | Status | Reference |
+------------------+------------+---------------------------+
| CALSCALE | Current | RFCXXXX, Section 3.7.1 |
| METHOD | Current | RFCXXXX, Section 3.7.2 |
| PRODID | Current | RFCXXXX, Section 3.7.3 |
| VERSION | Current | RFCXXXX, Section 3.7.4 |
| ATTACH | Current | RFCXXXX, Section 3.8.1.1 |
| CATEGORIES | Current | RFCXXXX, Section 3.8.1.2 |
| CLASS | Current | RFCXXXX, Section 3.8.1.3 |
| COMMENT | Current | RFCXXXX, Section 3.8.1.4 |
| DESCRIPTION | Current | RFCXXXX, Section 3.8.1.5 |
| GEO | Current | RFCXXXX, Section 3.8.1.6 |
| LOCATION | Current | RFCXXXX, Section 3.8.1.7 |
| PERCENT-COMPLETE | Current | RFCXXXX, Section 3.8.1.8 |
| PRIORITY | Current | RFCXXXX, Section 3.8.1.9 |
| RESOURCES | Current | RFCXXXX, Section 3.8.1.10 |
| STATUS | Current | RFCXXXX, Section 3.8.1.11 |
| SUMMARY | Current | RFCXXXX, Section 3.8.1.12 |
| COMPLETED | Current | RFCXXXX, Section 3.8.2.1 |
| DTEND | Current | RFCXXXX, Section 3.8.2.2 |
| DUE | Current | RFCXXXX, Section 3.8.2.3 |
| DTSTART | Current | RFCXXXX, Section 3.8.2.4 |
| DURATION | Current | RFCXXXX, Section 3.8.2.5 |
| FREEBUSY | Current | RFCXXXX, Section 3.8.2.6 |
| TRANSP | Current | RFCXXXX, Section 3.8.2.7 |
| TZID | Current | RFCXXXX, Section 3.8.3.1 |
| TZNAME | Current | RFCXXXX, Section 3.8.3.2 |
| TZOFFSETFROM | Current | RFCXXXX, Section 3.8.3.3 |
| TZOFFSETTO | Current | RFCXXXX, Section 3.8.3.4 |
| TZURL | Current | RFCXXXX, Section 3.8.3.5 |
| ATTENDEE | Current | RFCXXXX, Section 3.8.4.1 |
| CONTACT | Current | RFCXXXX, Section 3.8.4.2 |
| ORGANIZER | Current | RFCXXXX, Section 3.8.4.3 |
| RECURRENCE-ID | Current | RFCXXXX, Section 3.8.4.4 |
| RELATED-TO | Current | RFCXXXX, Section 3.8.4.5 |
| URL | Current | RFCXXXX, Section 3.8.4.6 |
| UID | Current | RFCXXXX, Section 3.8.4.7 |
| EXDATE | Current | RFCXXXX, Section 3.8.5.1 |
| EXRULE | Deprecated | RFC2445, Section 4.8.5.2 |
| RDATE | Current | RFCXXXX, Section 3.8.5.2 |
| RRULE | Current | RFCXXXX, Section 3.8.5.3 |
| ACTION | Current | RFCXXXX, Section 3.8.6.1 |
| REPEAT | Current | RFCXXXX, Section 3.8.6.2 |
| TRIGGER | Current | RFCXXXX, Section 3.8.6.3 |
| CREATED | Current | RFCXXXX, Section 3.8.7.1 |
| DTSTAMP | Current | RFCXXXX, Section 3.8.7.2 |
| LAST-MODIFIED | Current | RFCXXXX, Section 3.8.7.3 |
| SEQUENCE | Current | RFCXXXX, Section 3.8.7.4 |
| REQUEST-STATUS | Current | RFCXXXX, Section 3.8.8.3 |
+------------------+------------+---------------------------+


QUESTION: what about the request-status values (section 3.8.8.3)? Do
you want/need a registry for potential values for this property? In
particular do you want to make sure that status codes are not re-used
across different responses?




9.3. Property Parameters Registry

The IANA is requested to establish and maintain a table of property
parameters for the iCalendar standard. Additional parameters may be
added to this table as follows:

o Those parameters that do not modify standard properties or
parameters may be added through the publishing of informational or
experimental RFCs with expert review through the APPS Area of the
IETF.

o Those property parameters that modify existing standard properties
or parameters MUST update this memo, and hence be promoted through
the Internet standards process.

In all cases, each parameter MUST list the property it will be used
with. Implementations that are unable to recognize a property
parameter MUST ignore the property.

The following table is to be initialized with the following values:

+-------------------------+------------+-------------------------+
| Property Parameter Name | Status | Reference |
+-------------------------+------------+-------------------------+
| ALTREP | Current | RFCXXXX, Section 3.2.1 |
| CN | Current | RFCXXXX, Section 3.2.2 |
| CUTYPE | Current | RFCXXXX, Section 3.2.3 |
| DELEGATED-FROM | Current | RFCXXXX, Section 3.2.4 |
| DELEGATED-TO | Current | RFCXXXX, Section 3.2.5 |
| DIR | Current | RFCXXXX, Section 3.2.6 |
| ENCODING | Current | RFCXXXX, Section 3.2.7 |
| FMTTYPE | Current | RFCXXXX, Section 3.2.8 |
| FBTYPE | Current | RFCXXXX, Section 3.2.9 |
| LANGUAGE | Current | RFCXXXX, Section 3.2.10 |
| MEMBER | Current | RFCXXXX, Section 3.2.11 |
| PARTSTAT | Current | RFCXXXX, Section 3.2.12 |
| RANGE | Deprecated | RFC2445, Section 4.2.13 |
| RELATED | Current | RFCXXXX, Section 3.2.13 |
| RELTYPE | Current | RFCXXXX, Section 3.2.14 |
| ROLE | Current | RFCXXXX, Section 3.2.15 |
| RSVP | Current | RFCXXXX, Section 3.2.16 |
| SENT-BY | Current | RFCXXXX, Section 3.2.17 |
| TZID | Current | RFCXXXX, Section 3.2.18 |
| VALUE | Current | RFCXXXX, Section 3.2.19 |
+-------------------------+------------+-------------------------+

9.4. Value Data Type Values Registry

The IANA is requested to establish a registry of Property Value Data
Types for the iCalendar standard. Additional data types may only be
added through the Internet standards process. The initial values are
as follows:


+-------------------------------+---------+-------------------------+
| Property Parameter Value Type | Status | Reference |
+-------------------------------+---------+-------------------------+
| BINARY | Current | RFCXXXX, Section 3.3.1 |
| BOOLEAN | Current | RFCXXXX, Section 3.3.2 |
| CAL-ADDRESS | Current | RFCXXXX, Section 3.3.3 |
| DATE | Current | RFCXXXX, Section 3.3.4 |
| DATE-TIME | Current | RFCXXXX, Section 3.3.5 |
| DURATION | Current | RFCXXXX, Section 3.3.6 |
| FLOAT | Current | RFCXXXX, Section 3.3.7 |
| INTEGER | Current | RFCXXXX, Section 3.3.8 |
| PERIOD | Current | RFCXXXX, Section 3.3.9 |
| RECUR | Current | RFCXXXX, Section 3.3.10 |
| TEXT | Current | RFCXXXX, Section 3.3.11 |
| TIME | Current | RFCXXXX, Section 3.3.12 |
| URI | Current | RFCXXXX, Section 3.3.13 |
| UTC-OFFSET | Current | RFCXXXX, Section 3.3.14 |
+-------------------------------+---------+-------------------------+

QUESTION: what about the contents of recur-rule-part? Do you want
a registry of the values in the RECUR rule (section 3.3.10)? Are
there other potential things that could go into this entry or is
this truly a fixed list?


9.5. Calendar User Type Values Registry

Calendar user types (CUTYPEs) are used to indicate the sort of user
associated with a CAL-ADDRESS. It is described in more detail in
Section 3.2.3. Expert review is required for an IANA assignment.
The following values are currently allowed:

+--------------------+---------+------------------------+
| Calendar User Type | Status | Reference |
+--------------------+---------+------------------------+
| INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 |
| GROUP | Current | RFCXXXX, Section 3.2.3 |
| RESOURCE | Current | RFCXXXX, Section 3.2.3 |
| ROOM | Current | RFCXXXX, Section 3.2.3 |
| UNKNOWN | Current | RFCXXXX, Section 3.2.3 |
+--------------------+---------+------------------------+

Implementations that do not recognize a calendar user type MUST treat
the CAL-ADDRESS as an INDIVIDUAL.

9.6. Free/Busy Time Type Values Registry

This parameter is described in Section 3.2.9. New entries require
expert review. The table below specifies the initial registry:


+------------------+---------+------------------------+
| Free/Busy Type | Status | Reference |
+------------------+---------+------------------------+
| FREE | Current | RFCXXXX, Section 3.2.9 |
| BUSY | Current | RFCXXXX, Section 3.2.9 |
| BUSY-UNAVAILABLE | Current | RFCXXXX, Section 3.2.9 |
| BUSY-TENTATIVE | Current | RFCXXXX, Section 3.2.9 |
+------------------+---------+------------------------+

Implementations that do not recognize a particular fbtype MUST treat
that calendar user as BUSY.

9.7. Participation Status Values Registry

PARTSTAT denotes participate status and is described in
Section 3.2.12. The following table initializes the registry for
participant status:

+--------------------------+---------+-------------------------+
| Participant Status Value | Status | Reference |
+--------------------------+---------+-------------------------+
| NEEDS-ACTION | Current | RFCXXXX, Section 3.2.12 |
| ACCEPTED | Current | RFCXXXX, Section 3.2.12 |
| DECLINED | Current | RFCXXXX, Section 3.2.12 |
| TENTATIVE | Current | RFCXXXX, Section 3.2.12 |
| DELEGATED | Current | RFCXXXX, Section 3.2.12 |
| COMPLETED | Current | RFCXXXX, Section 3.2.12 |
| IN-PROCESS | Current | RFCXXXX, Section 3.2.12 |
+--------------------------+---------+-------------------------+

Existing implementations MUST treat an unknown PARTSTAT value as
NEEDS-ACTION.

9.8. Relationship Type Values Registry

This parameter is described in Section 3.2.14. Expert review is
required for an addition. The table below initializes the registry.

+-------------------+---------+-------------------------+
| Relationship Type | Status | Reference |
+-------------------+---------+-------------------------+
| CHILD | Current | RFCXXXX, Section 3.2.14 |
| PARENT | Current | RFCXXXX, Section 3.2.14 |
| SIBLING | Current | RFCXXXX, Section 3.2.14 |
+-------------------+---------+-------------------------+

Implementations MUST treat an unknown relationship as a PARENT.


9.9. Participation Role Values Registry

Roles are described in Section 3.2.15. The initial registration is
as follows:

+-----------------+---------+-------------------------+
| Role Type | Status | Reference |
+-----------------+---------+-------------------------+
| CHAIR | Current | RFCXXXX, Section 3.2.15 |
| REQ-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
| OPT-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
| NON-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
+-----------------+---------+-------------------------+

Implementations that do not recognize a specific ROLE should treat
the calendar user as REQ-PARTICIPANT.

9.10. Action Values Registry

Actions are covered in Section 3.8.6.1. The following table
intializes the registry.

+-----------------------+------------+--------------------------+
| ACTION Property Value | Status | Reference |
+-----------------------+------------+--------------------------+
| AUDIO | Current | RFCXXXX, Section 3.8.6.1 |
| DISPLAY | Current | RFCXXXX, Section 3.8.6.1 |
| EMAIL | Current | RFCXXXX, Section 3.8.6.1 |
| PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 |
+-----------------------+------------+--------------------------+

Implementations MUST ignore unrecognized "ACTION" property values.

9.11. Method Values Registry

Methods are covered in Section 3.7.2. No values are defined in this
document for the "METHOD" property.

9.12. Media Type Registration Information

The Calendaring and Scheduling Core Object Specification is intended
for use as a MIME content type. However, the implementation of the
memo is in no way limited solely as a MIME content type.

To: [e-mail]
Subject: Registration of media type text/calendar

Type name: text

Subtype name: calendar

Required parameters: none

Optional parameters: charset, method, component and optinfo

The "charset" parameter is defined in [RFC2046] for subtypes of
the "text" media type. It is used to indicate the charset used in
the body part. The charset supported by this revision of
iCalendar is UTF-8. The use of any other charset is deprecated by
this revision of iCalendar; however note that this revision
requires that compliant applications MUST accept iCalendar objects
using either the UTF-8 or US-ASCII charset.

The "method" parameter is used to convey the iCalendar object
method or transaction semantics for the calendaring and scheduling
information. It also is an identifier for the restricted set of
properties and values that the iCalendar object consists of. The
parameter is to be used as a guide for applications interpreting
the information contained within the body part. It SHOULD NOT be
used to exclude or require particular pieces of information unless
the identified method definition specifically calls for this
behavior. Unless specifically forbidden by a particular method
definition, a text/calendar content type can contain any set of
properties permitted by the Calendaring and Scheduling Core Object
Specification. The "method" parameter MUST be specified and MUST
be set to the same value as the "METHOD" component property of the
iCalendar objects of the iCalendar stream if and only if the
iCalendar objects in the iCalendar stream all have a "METHOD"
component property set to the same value.

The value for the "method" parameter is defined as follows:

method = 1*(ALPHA / DIGIT / "-")
; IANA registered iCalendar object method

The "component" parameter conveys the type of iCalendar calendar
component within the body part. If the iCalendar object contains
more than one calendar component type, then multiple component
parameters MUST be specified.

The value for the "component" parameter is defined as follows:

component = "VEVENT"
/ "VTODO"
/ "VJOURNAL"
/ "VFREEBUSY"
/ "VTIMEZONE"
/ iana-token
/ x-name

The "optinfo" parameter conveys optional information about the
iCalendar object within the body part. This parameter can only
specify semantics already specified by the iCalendar object and
that can be otherwise determined by parsing the body part. In
addition, the optional information specified by this parameter
MUST be consistent with that information specified by the
iCalendar object. For example, it can be used to convey the
"Attendee" response status to a meeting request. The parameter
value consists of a string value.

The parameter can be specified multiple times.

The value for the "optinfo" parameter is defined as follows:

optinfo = infovalue / qinfovalue

infovalue = iana-token / x-name

qinfovalue = DQUOTE (infovalue) DQUOTE

Encoding considerations: This media type can contain 8bit
characters, so the use of quoted-printable or base64 MIME Content-
Transfer-Encodings might be necessary when iCalendar objects are
transferred across protocols restricted to the 7bit repertoire.
Note that a text valued property in the content entity can also
have content encoding of special characters using a BACKSLASH
character (US-ASCII decimal 92) escapement technique. This means
that content values can end up encoded twice.

Security considerations: See Section 8.

Interoperability considerations: This media type is intended to
define a common format for conveying calendaring and scheduling
information between different systems. It is heavily based on the
earlier [VCAL] industry specification.

Published specification: This specification.

Applications which use this media type: This media type is designed
for widespread use by Internet calendaring and scheduling
applications. In addition, applications in the workflow and
document management area might find this content-type applicable.
The iTIP [I-D.ietf-calsify-2446bis], iMIP
[I-D.ietf-calsify-rfc2447bis] and CalDAV [I-D.dusseault-caldav]
Internet protocols directly use this media type also.

Additional information:

Magic number(s): None.

File extension(s): The file extension of "ics" is to be used to
designate a file containing (an arbitrary set of) calendaring
and scheduling information consistent with this MIME content
type.

The file extension of "ifb" is to be used to designate a file
containing free or busy time information consistent with this
MIME content type.

Macintosh file type code(s): The file type code of "iCal" is to
be used in Apple MacIntosh operating system environments to
designate a file containing calendaring and scheduling
information consistent with this MIME media type.

The file type code of "iFBf" is to be used in Apple MacIntosh
operating system environments to designate a file containing
free or busy time information consistent with this MIME media
type.

Person & email address to contact for further information: TBD

Intended usage: COMMON

Restrictions on usage: There are no restrictions on where this media
type can be used.

Author: TBD

Change controller: IETF


--------------000906010006090303090704--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1BB7C7F7AA for <[e-mail]>; Tue,  5 Jun 2007 10:01:19 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE5FF1421FF for <[e-mail]>; Tue,  5 Jun 2007 10:00:23 -0700 (PDT)
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, 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 7TdAMk+KcABV for <[e-mail]>; Tue,  5 Jun 2007 10:00:21 -0700 (PDT)
Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.237]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3D73E1421FB for <[e-mail]>; Tue,  5 Jun 2007 10:00:21 -0700 (PDT)
Received: by qb-out-0506.google.com with SMTP id z8so1655599qbc for <[e-mail]>; Tue, 05 Jun 2007 10:00:20 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=iQYRw0jo6GT882fQTaXQa23Q82kB4qyXM1lg1Fu6Pxwa0G5zvK+UAyWeYcB7bNhR0EcVey+Vs206IqDg6TlkS6Orqirg4rxSjhDzOwBmhBMqVvDIgBGuL+OjMd+ahjjDGYFMCYnpWXz5vYW5fgb3KauYHeRYskcv5TJBEH9gtK0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=arHpnmvrI+WR3UqZUgt3wwmTZ5XUn10nIlzo1iKLz7FdI6zy3O6sP98RZac/kMctA+wfyEEIsizjRUCXzmvCoFUnpUEAFy3twRivED3aQUo8pJygplq1pqwbJwEL0EtY9uhqGrRS/h8cE3J3Ow9QNdeN34zIH700dkZ0Gu+pmaU=
Received: by 10.142.102.5 with SMTP id z5mr296116wfb.1181062819624; Tue, 05 Jun 2007 10:00:19 -0700 (PDT)
Received: by 10.143.7.10 with HTTP; Tue, 5 Jun 2007 10:00:19 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 5 Jun 2007 14:00:19 -0300
From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" <[e-mail]>
To: "Martin Kiff" <[e-mail]>
Subject: Re: [Ietf-calsify] Imprecise and alternative events
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_19062_21242877.1181062819599"
References: <[e-mail]> <[e-mail]>
Cc: [e-mail]
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2007 17:01:19 -0000

------=_Part_19062_21242877.1181062819599
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Martin,

Thanks for the feedback!

Yes, that flexibility is what we aimed by allowing several VEVENT and
VIMPRECISEEVENT components within a VALTERNATIVEEVENTS. The example at page
9 illustrated it poorly, because it used only one VEVENT and only one
VIMPRECISEEVENT; we'll improve the draft that by adding other examples.

As for imprecise events, two complementary mechanisms are needed to:
1 - Express the expected duration of the event
2 - Express the possible time ranges for event occurrence

In our proposal, VIMPRECISEEVENT doesn't make use of DTSTART. (1) is done
with DURATION, and (2) is done by using VFREEBUSY and VAVAILABILITY
components.

As long as I understand, you are suggesting to extend DTSTART to accomplish
both (although it would be possible to have just one "time range" for 2). I
am not sure if that would have some impact on current use of DTSTART (e.g.,
free-busy queries). The idea of using concepts like 'evening' is really
interesting, but I am concerned with possible interoperability problems -
that's why we have opted for "deterministic" forms to represent periods of
time ("canonical" VFREEBUSY and VAVAILABILITY). I believe that those who
have long discussed issues with time representation on 2445bis can give a
definitive opinion on this.

Anyway, if we are to use extended VEVENT components to represent imprecise
events, a discussion on the role of DTSTART in this context is fundamental.

Regards,

F=E1bio.

On 6/3/07, Martin Kiff < [e-mail]> wrote:
>
> F=E1bio Henrique da Silva wrote:
>
> > Dear all,
> >
> > This is to announce the new internet-draft:
> >
> > < http://www.ietf.org/internet-drafts/draft-silva-events-00.txt>
>
>
> Interesting, I've read through once and will definitely read through
> again.
> I wonder whether it would go with the flow better to have a 'negotiate'
> block round a set of Vevents? Was this sort of option considered (and
> discarded?)
>
> BEGIN:ALTERNATES
>
> BEGIN:VEVENT
> PREFERENCE:100
> ...
> END:VEVENT
>
> BEGIN:VEVENT
> PREFERENCE:50
> TRANSP:TRANSPARENT
> ...
> END:VEVENT
>
> END:ALTERNATES
>
> This would give flexibility to have different locations, different
> descriptions (and so on) for the different options.
>
> For imprecise events, I think a lot of the the requirements when
> publishing (rather then negotiating) events would be covered by
> accepting varying precision in the time:
>   DTSTART:VALUE=3DHOUR:20070603T090000
> maybe for something that could start between 9 and 11.
>   DTSTART:VALUE=3DPT2H:20070603T090000
> and, if you know it's an evening (or whatever) event but don't know
> when...
>   DTSTART:VALUE=3DEVENING:20070603
>
> My arguments are based on the premises:
>
> * People don't necessarily work to second-level-precision, I don't think
> calendaring software should inflict this on them :-)
> * Calendaring has to keep a distinction between a 'whole day event'
> (like an anniversary) and an 'event on a day' (but you don't yet know
> when) and it would be nice if this could be generalised
>
> Regards, Martin
>
>
>

------=_Part_19062_21242877.1181062819599
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Martin,<br><br>Thanks for the feedback!<br><br>Yes, that flexibility is =
what we aimed by allowing several VEVENT and VIMPRECISEEVENT components wit=
hin a VALTERNATIVEEVENTS. The example at page 9 illustrated it poorly, beca=
use it used only one VEVENT and only one VIMPRECISEEVENT; we&#39;ll improve=
 the draft that by adding other examples.
<br><br>As for imprecise events, two complementary mechanisms are needed to=
:<br>1 - Express the expected duration of the event<br>2 - Express the poss=
ible time ranges for event occurrence<br><br>In our proposal, VIMPRECISEEVE=
NT doesn&#39;t make use of DTSTART. (1) is done with DURATION, and (2) is d=
one by using VFREEBUSY and VAVAILABILITY components.
<br>
<br>As long as I understand, you are suggesting to extend DTSTART to accomp=
lish both (although it would be possible to have just one &quot;time range&=
quot; for 2). I am not sure if that would have some impact on current use o=
f DTSTART (
e.g., free-busy queries). The idea of using concepts like &#39;evening&#39;=
 is really interesting, but I am concerned with possible interoperability p=
roblems - that&#39;s why we have opted for &quot;deterministic&quot; forms =
to represent periods of time (&quot;canonical&quot; VFREEBUSY and VAVAILABI=
LITY). I believe that those who have long discussed issues with time repres=
entation on 2445bis can give a definitive opinion on this.
<br><br>Anyway, if we are to use extended VEVENT components to represent im=
precise events, a discussion on the role of DTSTART in this context is fund=
amental.<br><br>Regards,<br><br>F=E1bio.<br><br><div><span class=3D"gmail_q=
uote">
On 6/3/07, <b class=3D"gmail_sendername">Martin Kiff</b> &lt;<a href=3D"mai=
lto:[e-mail]" target=3D"_blank" onclick=3D"return top.js.OpenExtLi=
nk(window,event,this)">

[e-mail]</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" st=
yle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex=
; padding-left: 1ex;">F=E1bio Henrique da Silva wrote:<br><br>&gt; Dear all=
,
<br>
&gt;<br>&gt; This is to announce the new internet-draft:<br>&gt;<br>&gt; &l=
t;<a href=3D"http://www.ietf.org/internet-drafts/draft-silva-events-00.txt"=
 target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,event,this)"=
>

http://www.ietf.org/internet-drafts/draft-silva-events-00.txt</a>&gt;<br>
<br><br>Interesting, I&#39;ve read through once and will definitely read th=
rough again.<br>I wonder whether it would go with the flow better to have a=
 &#39;negotiate&#39;<br>block round a set of Vevents? Was this sort of opti=
on considered (and
<br>discarded?)<br><br>BEGIN:ALTERNATES<br><br>BEGIN:VEVENT<br>PREFERENCE:1=
00<br>...<br>END:VEVENT<br><br>BEGIN:VEVENT<br>PREFERENCE:50<br>TRANSP:TRAN=
SPARENT<br>...<br>END:VEVENT<br><br>END:ALTERNATES<br><br>This would give f=
lexibility to have different locations, different
<br>descriptions (and so on) for the different options.<br><br>For imprecis=
e events, I think a lot of the the requirements when<br>publishing (rather =
then negotiating) events would be covered by<br>accepting varying precision=
 in the time:
<br>&nbsp;&nbsp;DTSTART:VALUE=3DHOUR:20070603T090000<br>maybe for something=
 that could start between 9 and 11.<br>&nbsp;&nbsp;DTSTART:VALUE=3DPT2H:200=
70603T090000<br>and, if you know it&#39;s an evening (or whatever) event bu=
t don&#39;t know when...
<br>&nbsp;&nbsp;DTSTART:VALUE=3DEVENING:20070603<br><br>My arguments are ba=
sed on the premises:<br><br>* People don&#39;t necessarily work to second-l=
evel-precision, I don&#39;t think<br>calendaring software should inflict th=
is on them :-)
<br>* Calendaring has to keep a distinction between a &#39;whole day event&=
#39;<br>(like an anniversary) and an &#39;event on a day&#39; (but you don&=
#39;t yet know<br>when) and it would be nice if this could be generalised
<br><br>Regards, Martin<br><br><br></blockquote></div><br>

------=_Part_19062_21242877.1181062819599--