[Ietf-calsify] [Fwd: Issue 37 - minor typo/grammatical error]

[lear at cisco.com (Eliot Lear)]

Forwarding...

Eliot
-------------- next part --------------
An embedded message was scrubbed...
From: "Tim Hare" <[e-mail]>
Subject: Issue 37 - minor typo/grammatical error
Date: Thu, 24 Aug 2006 21:04:52 -0400
Size: 4902
Url: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060826/2c08c703/grammaticalerror.mht
From bernard.desruisseaux at oracle.com  Tue Aug 29 10:32:01 2006
From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Tue Aug 29 10:33:04 2006
Subject: [Ietf-calsify] rfc 2445 - typo correction(s)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

+1

Andrew N Dowden wrote:
> 4.8.6.3 Trigger
> 
>    If the trigger is set relative to START, then the "DTSTART" property
>    MUST be present in the associated "VEVENT" or "VTODO" calendar
>    component. If an alarm is specified for an event with the trigger set
>    relative to the END, then the "DTEND" property or the "DSTART" and
>    "DURATION' properties MUST be present in the associated "VEVENT"
>    calendar component. If the alarm is specified for a to-do with a
>    trigger set relative to the END, then either the "DUE" property or
>    the "DSTART" and "DURATION' properties MUST be present in the
>    associated "VTODO" calendar component.
> 
> CORRECTION:  replace  DSTART  with  DTSTART   (lines 4 & 8)
> 
> PS. have enjoyed recent discussions, more (contentious) comments /
> suggestions to follow ..
> 

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 71FBB7F992 for <[e-mail]>; Tue, 29 Aug 2006 10:33:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 63A2C1422C4 for <[e-mail]>; Tue, 29 Aug 2006 10:33:03 -0700 (PDT)
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 26494-02 for <[e-mail]>; Tue, 29 Aug 2006 10:33:01 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CD29D14227C for <[e-mail]>; Tue, 29 Aug 2006 10:33:01 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7T35eNJ022025; Tue, 29 Aug 2006 11:32:59 -0600
Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 1892011131156872771; Tue, 29 Aug 2006 11:32:51 -0600
Message-ID: <[e-mail]>
Date: Tue, 29 Aug 2006 13:32:01 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Andrew N Dowden <[e-mail]>
Subject: Re: [Ietf-calsify] rfc 2445 - typo correction(s)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: ietf-calsify <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 29 Aug 2006 17:33:03 -0000

+1

Andrew N Dowden wrote:
> 4.8.6.3 Trigger
> 
>    If the trigger is set relative to START, then the "DTSTART" property
>    MUST be present in the associated "VEVENT" or "VTODO" calendar
>    component. If an alarm is specified for an event with the trigger set
>    relative to the END, then the "DTEND" property or the "DSTART" and
>    "DURATION' properties MUST be present in the associated "VEVENT"
>    calendar component. If the alarm is specified for a to-do with a
>    trigger set relative to the END, then either the "DUE" property or
>    the "DSTART" and "DURATION' properties MUST be present in the
>    associated "VTODO" calendar component.
> 
> CORRECTION:  replace  DSTART  with  DTSTART   (lines 4 & 8)
> 
> PS. have enjoyed recent discussions, more (contentious) comments /
> suggestions to follow ..
> 


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 2A0DA7FB0E for <[e-mail]>; Fri, 25 Aug 2006 23:33:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1B82D142279 for <[e-mail]>; Fri, 25 Aug 2006 23:33:10 -0700 (PDT)
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 23615-03 for <[e-mail]>; Fri, 25 Aug 2006 23:33:07 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9F242142278 for <[e-mail]>; Fri, 25 Aug 2006 23:33:07 -0700 (PDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Aug 2006 23:33:07 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7Q6X7ps014172; Fri, 25 Aug 2006 23:33:07 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7Q6X7Yp006702; Fri, 25 Aug 2006 23:33:07 -0700 (PDT)
Received: from [212.254.247.4] (ams3-vpn-dhcp4503.cisco.com [10.61.81.150]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7Q6OL3m014608; Fri, 25 Aug 2006 23:24:24 -0700
Message-ID: <[e-mail]>
Date: Sat, 26 Aug 2006 08:33:01 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
Content-Type: multipart/mixed; boundary="------------010902030007020003000908"
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=5413; t=1156573987; x=1157437987; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:[Fwd=3A=20Issue=2037=20-=20minor=20typo/grammatical=20error];  X=v=3Dcisco.com=3B=20h=3DvYekqvHSP4nYFj6vkDh9VwfWZ3E=3D; b=kuHG8Qz7i2EW5vxJtbXiluxg80eid41tQPcDYck1g7oBzsUJxMEYWTokyRUv/k8DF5ZiCZU7 OitFP/wRZc73OfoFZW8N2viySW1WTSNA+ijKSnU0r6J9fgj9VMVlkg1k;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, HTML_MESSAGE, MIME_HTML_MOSTLY
X-Spam-Level: 
Subject: [Ietf-calsify] [Fwd: Issue 37 - minor typo/grammatical error]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 26 Aug 2006 06:33:10 -0000

This is a multi-part message in MIME format.
--------------010902030007020003000908
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Forwarding...

Eliot

--------------010902030007020003000908
Content-Type: message/rfc822;
 name="Issue 37 - minor typo/grammatical error"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="Issue 37 - minor typo/grammatical error"

X-Account-Key: account2
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); 
	Fri, 25 Aug 2006 03:05:04 +0200
Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by
	xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 25 Aug 2006 03:05:03 +0200
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 24 Aug 2006 18:04:56 -0700
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-1.cisco.com with ESMTP; 24 Aug 2006 18:04:56 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7P14uA3026059
	for <[e-mail]>; Thu, 24 Aug 2006 18:04:56 -0700
Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com
	[128.107.234.204])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7P14tYt000934
	for <[e-mail]>; Thu, 24 Aug 2006 18:04:56 -0700 (PDT)
Received: from rwcrmhc15.comcast.net ([204.127.192.85])
	by sj-inbound-a.cisco.com with ESMTP; 24 Aug 2006 18:04:56 -0700
Message-Id: <57d886$[e-mail]>
X-from-outside-Cisco: 204.127.192.85
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAQAAA+k=
X-IronPort-AV: i="4.08,166,1154934000"; 
	d="scan'208,217"; a="567871473:sNHT39121966"
Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33])
	by comcast.net (rwcrmhc15) with SMTP
	id <20060825010455m1500t2hvue>; Fri, 25 Aug 2006 01:04:55 +0000
From: "Tim Hare" <[e-mail]>
To: "'Eliot Lear'" <[e-mail]>
Subject: Issue 37 - minor typo/grammatical error
Date: Thu, 24 Aug 2006 21:04:52 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0038_01C6C7C0.F1F48520"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcbHh+ALvqIbVt0IQauSEmPTwEyyawAWeRGg
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail];
	dkim=neutral
Return-Path: [e-mail]
X-OriginalArrivalTime: 25 Aug 2006 01:04:56.0713 (UTC)
	FILETIME=[7B057790:01C6C7E2]

This is a multi-part message in MIME format.

------=_NextPart_000_0038_01C6C7C0.F1F48520
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In issue number 37 it reads "; the following are both REQUIRED,"  but then
lists _three_ items. 
It should read "; the following are all REQUIRED," 
 
to be clear: replace the word BOTH with ALL because there are more than two
items.
 
Also applies to Issues numbered 38, 39, and 40 since the text seems to have
been copied but I think in this case it should be OK to violate the one
message per issue rule?
 
Tim Hare
Interested Bystander, Non-Inc.

------=_NextPart_000_0038_01C6C7C0.F1F48520
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D174505900-25082006>In issue number 37 it reads "</SPAN>; the =
following are=20
both REQUIRED,<SPAN class=3D174505900-25082006>"&nbsp; but then lists =
_three_=20
items. </SPAN></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D174505900-25082006>It should read "<FONT size=3D3>; </FONT><FONT =
size=3D2>the=20
following are&nbsp;all REQUIRED," </FONT></SPAN></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D174505900-25082006></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D174505900-25082006>to be clear: replace the word BOTH with ALL =
because=20
there are more than two items.</SPAN></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D174505900-25082006></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D174505900-25082006>Also applies to Issues numbered 38, 39, and =
40 since=20
the text seems to have been copied but I think in this case it should be =
OK to=20
violate the one message per issue rule?</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Tim Hare</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Interested Bystander,=20
Non-Inc.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0038_01C6C7C0.F1F48520--


--------------010902030007020003000908--


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 1D73B7FA54 for <[e-mail]>; Fri, 25 Aug 2006 04:11:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0F769142286 for <[e-mail]>; Fri, 25 Aug 2006 04:11:30 -0700 (PDT)
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 24602-05 for <[e-mail]>; Fri, 25 Aug 2006 04:11:29 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 67FF6142284 for <[e-mail]>; Fri, 25 Aug 2006 04:11:29 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7OI3dMN019237; Fri, 25 Aug 2006 05:11:27 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-97-35.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1829624411156504271; Fri, 25 Aug 2006 05:11:11 -0600
Message-ID: <[e-mail]>
Date: Fri, 25 Aug 2006 07:11:14 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Tim Hare <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.4: "Single iCalendar object"	versus"Sequence of iCalendar objects"
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: 'Calsify WG' <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 25 Aug 2006 11:11:30 -0000

Hi Tim,

Tim Hare wrote:
> 1. If icalstream = 1*icalobject how does that allow n*icalobject ("multiple
> BEGIN/END:VCALENDAR objects) within one MIME part?

Read RFC 4234 (ABNF) section 3.6. Variable Repetition: *Rule.

> 2. I think the original iCalendar really intended to talk about multiple
> iCalendar _components_ within one iCalendar "stream", basically that one
> stream or serialized object / file could contain multiple VEVENTs, VTODOs,
> for one calendar; I never understood from reading it that it wss intended to
> handle multiple calendars for different "users" that way.

No. In RFC 2445 an "icalobject" allows 1 or more
"BEGIN:VCALENDAR ... END:VCALENDAR" while an
"icalbody" allows 1 or more components.

Cheers,
Bernard

> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Cyrus Daboo
> Sent: Monday, August 21, 2006 11:04 PM
> To: Bernard Desruisseaux; Calsify WG
> Subject: Re: [Ietf-calsify] Section 4.4: "Single iCalendar object"
> versus"Sequence of iCalendar objects"
> 
> Hi Bernard,
> 
> --On August 21, 2006 10:46:30 PM -0400 Bernard Desruisseaux
> <[e-mail]> wrote:
> 
>> Proposed new text:
>>
>>  > The Calendaring and Scheduling Core Object is a collection of  > 
>> calendaring and scheduling information. Typically, this information  > 
>> will consist of an iCalendar stream with a single iCalendar object.
>>  > However, multiple iCalendar objects can be sequentially grouped  > 
>> together in an iCalendar stream. The first line and last line of  > 
>> the iCalendar object MUST contain a pair of iCalendar object  > 
>> delimiter strings. The syntax for an iCalendar stream is as follows:
>>  >
>>  >   icalstream = 1*icalobject
>>  >
>>  >   icalobject = "BEGIN" ":" "VCALENDAR" CRLF
>>  >                icalbody
>>  >                "END" ":" "VCALENDAR" CRLF
> 
> +1
> 
> I definitely like the idea of icalstream as a way of describing multiple
> BEGIN/END:VCALENDAR objects within one mime part etc. Whilst this does not
> appear too frequently in iCalendar data, 2445 does make reference to such
> things.
> 
> --
> Cyrus Daboo
> 
> _______________________________________________
> 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 2A2347F8E0 for <[e-mail]>; Thu, 24 Aug 2006 08:52:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A419142288 for <[e-mail]>; Thu, 24 Aug 2006 08:52:29 -0700 (PDT)
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 30922-05 for <[e-mail]>; Thu, 24 Aug 2006 08:52:25 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4306B14227F for <[e-mail]>; Thu, 24 Aug 2006 08:52:25 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 24 Aug 2006 16:52:21 +0100
Message-ID: <[e-mail]>
Date: Thu, 24 Aug 2006 16:51:32 +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
MIME-Version: 1.0
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 24 Aug 2006 15:52:29 -0000

Bernard Desruisseaux wrote:

> Alexey Melnikov wrote:
>
>> Bernard Desruisseaux wrote:
>>
>>> New text:
>>>
>>> > The "method" parameter MUST be specified only for iCalendar
>>> > stream that contains a single iCalendar object.
>>
>> No, I think this is not correct. It is Ok to have multiple iCalendar 
>> objects in an iCalendar stream, as long as they all have the same 
>> METHOD property.
>
> Where is that defined?

It is nowhere prohibited :-).

> My reasoning is that if the iCalendar stream contains more than one
> iCalendar object then it most likely doesn't describe a scheduling
> transaction, and thus you probably shouldn't specify a "method"
> parameter in the Content-Type header field.

I don't feel good about disallowing "method" with iCalendar stream 
containing multiple objects.
An implementation already has to check if the "method" parameter matches 
what is specified in the calendar stream with a single object. It is not 
difficult to check all objects.

Does anybody have some statistics on how frequently a calendar stream 
can contain multiple calendar objects?



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 5F5487F8B1 for <[e-mail]>; Thu, 24 Aug 2006 07:16:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F3F914228C for <[e-mail]>; Thu, 24 Aug 2006 07:16:20 -0700 (PDT)
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 30204-09 for <[e-mail]>; Thu, 24 Aug 2006 07:16:16 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id DB4C5142288 for <[e-mail]>; Thu, 24 Aug 2006 07:16:12 -0700 (PDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2006 07:16:12 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OEGCvt007735; Thu, 24 Aug 2006 07:16:12 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7OEGC1E007706; Thu, 24 Aug 2006 07:16:12 -0700 (PDT)
Received: from [212.254.247.4] (ams3-vpn-dhcp126.cisco.com [10.61.64.126]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7OE7X0c026538; Thu, 24 Aug 2006 07:07:34 -0700
Message-ID: <[e-mail]>
Date: Thu, 24 Aug 2006 16:16:09 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: multipart/alternative; boundary="------------090604040605060603080805"
Authentication-Results: sj-dkim-4.cisco.com; header.From=[e-mail]; dkim=pass ( 60 extraneous bytes; sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=31757; t=1156428972; x=1157292972; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:current=20summary=20of=20issues; X=v=3Dcisco.com=3B=20h=3DOAgTBOt0mjQOqWFz4QrT4NjallY=3D; b=CsMtnxGknOelDn+cP+EirQq/u+2+E2/CWq07nexpYM8UUkN7cIItDwD3GoqafJbMP7sMOKCC fH7XejIoIRuVb2YY9AECGiAls0+X8qJXAMUbm6kGGYONLlH3tamIrw+5;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, HTML_40_50, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, TO_ADDRESS_EQ_REAL
X-Spam-Level: 
Subject: [Ietf-calsify] current summary of issues
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 24 Aug 2006 14:16:20 -0000

This is a multi-part message in MIME format.
--------------090604040605060603080805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<ChairHatOn>

[this message is hopefully best viewed as HTML]

Hello everyone,

What follows is a summary of where I think we are for each issue with
2445bis.  I ask that if you are going to comment about a particular
issue, PLEASE indicate which issue in the subject and keep it to one
issue per message.  This covers ALL issues with 2445bis with the
exception of Lisa's proposal, but I am mindful of that requiring
attention.  It would otherwise be the elephant in the living room. 
Please note the following:

    * If an issue indicates either "consensus" or "no objection" without
      additional annotation, the co-chair believes the issue is resolved.
    * If there is no entry in consensus state, that means there is no
      text to gain consensus around yet.
    * Feel free to discuss anything where more discussion is indicated ;-)

Finally, please take note of the amount of work Bernard has.  You can
help by proposing textual changes for open issues that have no text or
no consensus.


Here goes:

Issue Number
	Issue Topic
	Proposed Action
	Consensus State
1
	Line length limit and folding issues
	New text:

> Lines of text SHOULD NOT be longer than 75 octets, excluding the line
> break. Long content lines SHOULD be split into a multiple line
> representations using a line "folding" technique. That is, a long
> line can be split between any two characters by inserting a CRLF
> immediately followed by a single linear white space character (i.e.,
> SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9).  A multi-
> octet character MUST NOT be split across lines.  Any sequence of
> CRLF followed immediately by a single linear white space character
> is ignored (i.e., removed) when processing the content type. 	No
consensus yet.
2
	Typo in VTODO
	

4.8.6.3 Trigger

   If the trigger is set relative to START, then the "DTSTART" property
   MUST be present in the associated "VEVENT" or "VTODO" calendar
   component. If an alarm is specified for an event with the trigger set
   relative to the END, then the "DTEND" property or the "DSTART" and
   "DURATION' properties MUST be present in the associated "VEVENT"
   calendar component. If the alarm is specified for a to-do with a
   trigger set relative to the END, then either the "DUE" property or
   the "DSTART" and "DURATION' properties MUST be present in the
   associated "VTODO" calendar component.

CORRECTION:  replace  DSTART  with  DTSTART   (lines 4 & 8)

PS. have enjoyed recent discussions, more (contentious) comments /
suggestions to follow ..

	no objections
3
	Bunch of other typos
	bunch of minor fixes including:


 >     NON-US-ASCII       = %x80-FD
or
 >     NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
 >     ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629.

and if we agree to support ISO-8859-1, then it should be:

 >     NON-US-ASCII       = %x80-FF


	no objections
4
	Example error
	No proposed change yet.
	
5
	Andrew Bowden's Proposed changes to RRULE / EXDATE
	4.8.5.1

   .. The recurrence set is the complete set of
   recurrence instances for a calendar component. The recurrence set is
   generated by considering the "DTSTART" property along with the
   "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within
   the iCalendar object. The "DTSTART" property defines the first
   instance in the recurrence set. Multiple instances of the "RRULE" and
   "EXRULE" properties can also be specified to define more
   sophisticated recurrence sets. The final recurrence set is generated
   by gathering all of the date-times generated by any of the specified
   "RRULE" and "RDATE" properties, and then excluding any date-times
   which fall within the union of date-times generated by any specified
   "EXRULE" and "EXDATE" properties. This implies that date-times within
   exclusion related properties (i.e., "EXDATE" and "EXRULE") take
   precedence over those specified by inclusion properties (i.e.,
   "RDATE" and "RRULE"). Where duplicate instances are generated by the
   "RRULE" and "RDATE" properties, only one recurrence is considered.
   Duplicate instances are ignored.


	No consensus and there are other proposed changes to these properties.
6
	duplicate of 3
	(closed)
	
7
	duplicate of 4
	(closed)
	
8
	Deprecate P1D or P24H?
	No suggested text.
	
9
	Recurring events: Start / End Time
	No suggested text.
	
10
	End Date Not inclusive
	No suggested text
	
11
	Possible examples to be included in 2445bis
	Please see http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11
	No objections but no consensus either.  Discussion needed.
12
	Confusion about when FREQ is applied in RRULE 	No suggested text.
	
13
	Clarification wording for "if specified" in DTSTART
	Something close to a textual suggestion:

The "if specified" in 
this context is supposed to mean "if it matches the BY* rules", or "if it 
would be generated as a recurrence date by the RRULE". 
It does not mean if it is specified (i.e. exists) in the VEVENT at all.


	No objection but no consensus either.  More discussion needed.
14
	DTSTART/DTEND/DURATION clarification of text
	Section 4.8.5.4

Something close to a textual suggestion:

Here, "first instance of the recurrence" does NOT mean the recurrence 
generated by that particular RRULE, but it rather means the whole set of 
occurences of the event (which is calculated of the DTSTART + RRULE dates + 
RDATE - EXRULE dates - EXDATE). This is particularly important as otherwise 
an EXRULE would always exclude the original start date/time.


	No objection but no consensus either.  More discussion needed.
16
	BY parts to be ignored clarification
	Section 4.3.10

Something close to a textual suggestion:

-) Section 4.3.10 says:
   "If BYxxx rule part values are found which are beyond the available
   scope (ie, BYMONTHDAY=30 in February), they are simply ignored."
 
Here an example should be given (what the available scope is and what ignored 
means here). E.g.
 
   DTSTART;TZID=Europe/Vienna: 20050201T120000
   RRULE:FREQ=MONTHLY;BYMONTHDAY=30;FREQ=3
results in occurrences on 1 Feb 2006, 30 May 2006, 30 Aug 2006, 30 Nov 2006, 
30 May 2006.
I.e. "they are simply ignored" means that the whole occurrence is ignored, not 
the rule part value (which would result in the day being taken from the 
DTSTART) .


	No objection but no consensus either.  More discussion needed.
19
	IANA Considerations
	Text in draft already.
	No objections
23
	Contradiction regarding UNTIL BNF.
	

Room showing agreement that the draft should state that 
   the UNTIL value type MUST match DTSTART value type.

Exact textual change required.
      

	
24
	Clarification required for number of recurrences generated by multiple
RRULEs
	Bernard to add text.
	
25
	Is the first recurrence instance, defined by DTSTART, always excluded
by RRULE?
	No text.  Mailing list discussion required.
	
26
	BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE
	Consensue to add MUST not generate, but specific text required.
	
27
	Clarification of DTEND/DURATION
	Cyrus to propose text in 4.8.5.4.  Is this the same as issue 14?
	
28
	In 4.8.5.4 Is RDATE required even when the recurrence instance is
defined in a separate component
	Bernard to propose text.
	
29
	Is DTSTART required in VTODO/VJOURNAL?
	

Is DTSTART required in VTODO and VJOURNAL components when the RRULE
   or EXRULE properties are defined in those components?  

   Cyrus floated another idea that in the case of VTODO, perhaps the
   recurrence could use the DUE property. Bernard suggested that perhaps 
   in the absence of DTSTART, it could default to DUE.

   Lisa pointed out that this needs more discussion beyond the room, because
   different apps behave differently.

   In the end, some agreement that it's enough to clarify that for
   recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even 
   if it's otherwise optional.

   AI: Go forward with above clarification

	consensus
30
	Section 3.2: "charset" parameter
	

New text proposed:

> The "charset" parameter is defined in [RFC 2046] for subtypes of
> the "text" media type. It is used to indicate the character set
> used in the body part.

	consensus
31
	Character set restriction in Section 4.3.11 text
	

Proposed new text:

 > Formal Definition: The value type is defined by the following notation.

	No consensus, and substantial opposition.
32
	Section 4.4: Single iCalendar Object
	

Proposed new text:

 > The Calendaring and Scheduling Core Object is a collection of
 > calendaring and scheduling information. Typically, this information
 > will consist of an iCalendar stream with a single iCalendar object.
 > However, multiple iCalendar objects can be sequentially grouped
 > together in an iCalendar stream. The first line and last line of
 > the iCalendar object MUST contain a pair of iCalendar object
 > delimiter strings. The syntax for an iCalendar stream is as follows:
 >
 >   icalstream = 1*icalobject
 >
 >   icalobject = "BEGIN" ":" "VCALENDAR" CRLF
 >                icalbody
 >                "END" ":" "VCALENDAR" CRLF

      

	Weak consensus.  Would like more discussion.
33
	characters v. octets
	In both cases change 255 characters to 255 octets.
	consensus
34
	"method" parameter
	

New text:

 > The "method" parameter MUST be specified only for iCalendar
 > stream that contains a single iCalendar object. The "method"
 > parameter MUST be the same value as that specified in the "METHOD"
 > component property in the iCalendar object. If one is present,
 > the other MUST also be present.

      

	no consensus / disagreement
35
	Section 4.2.10 language / language property
	

Proposed new text:

 > Description: The parameter identifies the language of the text in
 > the property or property parameter value. The value of the "language"
 > property parameter is that defined in [RFC 1766].

	possible consensus.  need to update RFC reference.  More discussion needed.
36
	X-name
	

 > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
 > ; Reserved for non-standard names. Can be used by bilateral
 > ; agreement.


      

	No consensus on what bilateral means in this context.
37
	4.6.1 Event Component: eventprop
	

 >  eventprop  = *(
 >
 >             ; the following are both REQUIRED,
 >             ; but MUST NOT occur more than once
 >
 >             dtstamp / dtstart / uid /
 >
 >             ; the following are optional,
 >             ; but MUST NOT occur more than once

	No objections.
38
	VTODO todoprop
	

 >  todoprop  = *(
 >
 >            ; the following are both REQUIRED,
 >            ; but MUST NOT occur more than once
 >
 >            dtstamp / uid /
 >
 >            ; the following are optional,
 >            ; but MUST NOT occur more than once
 >
 >            ...

      

	No objections.
39
	VJOURNAL journalprop
	

 >  jourprop = *(
 >
 >           ; the following are both REQUIRED,
 >           ; but MUST NOT occur more than once
 >
 >           dtstamp / uid /
 >
 >           ; the following are optional,
 >           ; but MUST NOT occur more than once

	No objections.
40
	4.6.4 f/b component/ fbprop
	

 >  fbprop = *(
 >
 >         ; the following are both REQUIRED,
 >         ; but MUST NOT occur more than once
 >
 >         dtstamp / uid /
 >
 >         ; the following are optional,
 >         ; but MUST NOT occur more than once
 >
 >         ...

	No consensus as to what uid means in this context.



That is all for now.

<ChairHatOff>

--------------090604040605060603080805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
&lt;ChairHatOn&gt;<br>
<br>
[this message is hopefully best viewed as HTML]<br>
<br>
Hello everyone,<br>
<br>
What follows is a summary of where I think we are for each issue with
2445bis.&nbsp; I ask that if you are going to comment about a particular
issue, PLEASE indicate which issue in the subject and keep it to one
issue per message.&nbsp; This covers ALL issues with 2445bis with the
exception of Lisa's proposal, but I am mindful of that requiring
attention.&nbsp; It would otherwise be the elephant in the living room.&nbsp;
Please note the following:<br>
<br>
<ul>
  <li>If an issue indicates either "consensus" or "no objection"
without additional annotation, the co-chair believes the issue is
resolved.</li>
  <li>If there is no entry in consensus state, that means there is no
text to gain consensus around yet.</li>
  <li>Feel free to discuss anything where more discussion is indicated
;-)<br>
  </li>
</ul>
Finally, please take note of the amount of work Bernard has.&nbsp; You can
help by proposing textual changes for open issues that have no text or
no consensus.<br>
<br>
<br>
Here goes:<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
  <tbody>
    <tr>
      <td valign="top">Issue Number<br>
      </td>
      <td valign="top" width="30%">Issue Topic<br>
      </td>
      <td valign="top" width="40%">Proposed Action<br>
      </td>
      <td valign="top">Consensus State<br>
      </td>
    </tr>
    <tr>
      <td valign="top">1<br>
      </td>
      <td valign="top" width="30%">Line length limit and folding issues<br>
      </td>
      <td valign="top" width="40%">New text:
      <br>
      <br>
&gt; Lines of text SHOULD NOT be longer than 75 octets, excluding the
line
      <br>
&gt; break. Long content lines SHOULD be split into a multiple line
      <br>
&gt; representations using a line "folding" technique. That is, a long
      <br>
&gt; line can be split between any two characters by inserting a CRLF
      <br>
&gt; immediately followed by a single linear white space character
(i.e.,
      <br>
&gt; SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9).&nbsp; A multi-
      <br>
&gt; octet character MUST NOT be split across lines.&nbsp; Any sequence of
      <br>
&gt; CRLF followed immediately by a single linear white space character
      <br>
&gt; is ignored (i.e., removed) when processing the content type.</td>
      <td valign="top">No consensus yet.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">2<br>
      </td>
      <td valign="top" width="30%">Typo in VTODO<br>
      </td>
      <td valign="top" width="40%">
      <pre>4.8.6.3 Trigger

   If the trigger is set relative to START, then the "DTSTART" property
   MUST be present in the associated "VEVENT" or "VTODO" calendar
   component. If an alarm is specified for an event with the trigger set
   relative to the END, then the "DTEND" property or the "DSTART" and
   "DURATION' properties MUST be present in the associated "VEVENT"
   calendar component. If the alarm is specified for a to-do with a
   trigger set relative to the END, then either the "DUE" property or
   the "DSTART" and "DURATION' properties MUST be present in the
   associated "VTODO" calendar component.

CORRECTION:  replace  DSTART  with  DTSTART   (lines 4 &amp; 8)

PS. have enjoyed recent discussions, more (contentious) comments /
suggestions to follow ..</pre>
      </td>
      <td valign="top">no objections<br>
      </td>
    </tr>
    <tr>
      <td valign="top">3<br>
      </td>
      <td valign="top" width="30%">Bunch of other typos<br>
      </td>
      <td valign="top" width="40%">bunch of minor fixes including:<br>
      <br>
      <pre>

 &gt;     NON-US-ASCII       = %x80-FD
or
 &gt;     NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
 &gt;     ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629.

and if we agree to support ISO-8859-1, then it should be:

 &gt;     NON-US-ASCII       = %x80-FF</pre>
      <br>
      </td>
      <td valign="top">no objections<br>
      </td>
    </tr>
    <tr>
      <td valign="top">4<br>
      </td>
      <td valign="top" width="30%">Example error<br>
      </td>
      <td valign="top" width="40%">No proposed change yet.<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">5<br>
      </td>
      <td valign="top" width="30%">Andrew Bowden's Proposed changes to
RRULE / EXDATE<br>
      </td>
      <td valign="top" width="40%">4.8.5.1<br>
      <br>
      <pre>   .. The recurrence set is the complete set of
   recurrence instances for a calendar component. The recurrence set is
   generated by considering the "DTSTART" property along with the
   "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within
   the iCalendar object. The "DTSTART" property defines the first
   instance in the recurrence set. Multiple instances of the "RRULE" and
   "EXRULE" properties can also be specified to define more
   sophisticated recurrence sets. The final recurrence set is generated
   by gathering all of the date-times generated by any of the specified
   "RRULE" and "RDATE" properties, and then excluding any date-times
   which fall within the union of date-times generated by any specified
   "EXRULE" and "EXDATE" properties. This implies that date-times within
   exclusion related properties (i.e., "EXDATE" and "EXRULE") take
   precedence over those specified by inclusion properties (i.e.,
   "RDATE" and "RRULE"). Where duplicate instances are generated by the
   "RRULE" and "RDATE" properties, only one recurrence is considered.
   Duplicate instances are ignored.</pre>
      <br>
      </td>
      <td valign="top">No consensus and there are other proposed
changes to these properties.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">6<br>
      </td>
      <td valign="top" width="30%">duplicate of 3<br>
      </td>
      <td valign="top" width="40%">(closed)<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">7<br>
      </td>
      <td valign="top" width="30%">duplicate of 4<br>
      </td>
      <td valign="top" width="40%">(closed)<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">8<br>
      </td>
      <td valign="top" width="30%">Deprecate P1D or P24H?<br>
      </td>
      <td valign="top" width="40%">No suggested text.<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">9<br>
      </td>
      <td valign="top" width="30%">Recurring events: Start / End Time<br>
      </td>
      <td valign="top" width="40%">No suggested text.<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">10<br>
      </td>
      <td valign="top">End Date Not inclusive<br>
      </td>
      <td valign="top">No suggested text<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">11<br>
      </td>
      <td valign="top">Possible examples to be included in 2445bis<br>
      </td>
      <td valign="top">Please see
<a class="moz-txt-link-freetext" href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11">http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11</a><br>
      </td>
      <td valign="top">No objections but no consensus either.&nbsp;
Discussion needed.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">12<br>
      </td>
      <td valign="top">Confusion about when FREQ is applied in RRULE</td>
      <td valign="top">No suggested text.<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">13<br>
      </td>
      <td valign="top">Clarification wording for "if specified" in
DTSTART<br>
      </td>
      <td valign="top">Something close to a textual suggestion:<br>
      <pre>The "if specified" in 
this context is supposed to mean "if it matches the BY* rules", or "if it 
would be generated as a recurrence date by the RRULE". 
It does not mean if it is specified (i.e. exists) in the VEVENT at all.</pre>
      <br>
      </td>
      <td valign="top">No objection but no consensus either.&nbsp; More
discussion needed.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">14<br>
      </td>
      <td valign="top">DTSTART/DTEND/DURATION clarification of text<br>
      </td>
      <td valign="top">Section 4.8.5.4<br>
      <br>
Something close to a textual suggestion:<br>
      <br>
      <pre>Here, "first instance of the recurrence" does NOT mean the recurrence 
generated by that particular RRULE, but it rather means the whole set of 
occurences of the event (which is calculated of the DTSTART + RRULE dates + 
RDATE - EXRULE dates - EXDATE). This is particularly important as otherwise 
an EXRULE would always exclude the original start date/time.</pre>
      <br>
      </td>
      <td valign="top">No objection but no consensus either.&nbsp; More
discussion needed.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">16<br>
      </td>
      <td valign="top">BY parts to be ignored clarification<br>
      </td>
      <td valign="top">Section 4.3.10<br>
      <br>
Something close to a textual suggestion:<br>
      <br>
      <pre>-) Section 4.3.10 says:
   "If BYxxx rule part values are found which are beyond the available
   scope (ie, BYMONTHDAY=30 in February), they are simply ignored."
 
Here an example should be given (what the available scope is and what ignored 
means here). E.g.
 
   DTSTART;TZID=Europe/Vienna: 20050201T120000
   RRULE:FREQ=MONTHLY;BYMONTHDAY=30;FREQ=3
results in occurrences on 1 Feb 2006, 30 May 2006, 30 Aug 2006, 30 Nov 2006, 
30 May 2006.
I.e. "they are simply ignored" means that the whole occurrence is ignored, not 
the rule part value (which would result in the day being taken from the 
DTSTART) .</pre>
      <br>
      </td>
      <td valign="top">No objection but no consensus either.&nbsp; More
discussion needed.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">19<br>
      </td>
      <td valign="top">IANA Considerations<br>
      </td>
      <td valign="top">Text in draft already.<br>
      </td>
      <td valign="top">No objections<br>
      </td>
    </tr>
    <tr>
      <td valign="top">23<br>
      </td>
      <td valign="top">Contradiction regarding UNTIL BNF.<br>
      </td>
      <td valign="top">
      <pre>Room showing agreement that the draft should state that 
   the UNTIL value type MUST match DTSTART value type.

Exact textual change required.
      </pre>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">24<br>
      </td>
      <td valign="top">Clarification required for number of recurrences
generated by multiple RRULEs<br>
      </td>
      <td valign="top">Bernard to add text.<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">25<br>
      </td>
      <td valign="top">Is the first recurrence instance, defined by
DTSTART, always excluded by RRULE?<br>
      </td>
      <td valign="top">No text.&nbsp; Mailing list discussion required.<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">26<br>
      </td>
      <td valign="top">BYHOUR, BYMINUTE, and BYSECOND recurrence rules
where value type is DATE<br>
      </td>
      <td valign="top">Consensue to add MUST not generate, but specific
text required.<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">27<br>
      </td>
      <td valign="top">Clarification of DTEND/DURATION<br>
      </td>
      <td valign="top">Cyrus to propose text in 4.8.5.4.&nbsp; Is this the
same as issue 14?<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">28<br>
      </td>
      <td valign="top">In 4.8.5.4 Is RDATE required even when the
recurrence instance is defined in a separate component<br>
      </td>
      <td valign="top">Bernard to propose text.<br>
      </td>
      <td valign="top"><br>
      </td>
    </tr>
    <tr>
      <td valign="top">29<br>
      </td>
      <td valign="top">Is DTSTART required in VTODO/VJOURNAL?<br>
      </td>
      <td valign="top">
      <pre>Is DTSTART required in VTODO and VJOURNAL components when the RRULE
   or EXRULE properties are defined in those components?  

   Cyrus floated another idea that in the case of VTODO, perhaps the
   recurrence could use the DUE property. Bernard suggested that perhaps 
   in the absence of DTSTART, it could default to DUE.

   Lisa pointed out that this needs more discussion beyond the room, because
   different apps behave differently.

   In the end, some agreement that it's enough to clarify that for
   recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even 
   if it's otherwise optional.

   AI: Go forward with above clarification</pre>
      </td>
      <td valign="top">consensus<br>
      </td>
    </tr>
    <tr>
      <td valign="top">30<br>
      </td>
      <td valign="top">Section 3.2: "charset" parameter<br>
      </td>
      <td valign="top">
      <pre>New text proposed:

&gt; The "charset" parameter is defined in [RFC 2046] for subtypes of
&gt; the "text" media type. It is used to indicate the character set
&gt; used in the body part.</pre>
      </td>
      <td valign="top">consensus<br>
      </td>
    </tr>
    <tr>
      <td valign="top">31<br>
      </td>
      <td valign="top">Character set restriction in Section 4.3.11 text<br>
      </td>
      <td valign="top">
      <pre>Proposed new text:

 &gt; Formal Definition: The value type is defined by the following notation.</pre>
      </td>
      <td valign="top">No consensus, and substantial opposition.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">32<br>
      </td>
      <td valign="top">Section 4.4: Single iCalendar Object<br>
      </td>
      <td valign="top">
      <pre>Proposed new text:

 &gt; The Calendaring and Scheduling Core Object is a collection of
 &gt; calendaring and scheduling information. Typically, this information
 &gt; will consist of an iCalendar stream with a single iCalendar object.
 &gt; However, multiple iCalendar objects can be sequentially grouped
 &gt; together in an iCalendar stream. The first line and last line of
 &gt; the iCalendar object MUST contain a pair of iCalendar object
 &gt; delimiter strings. The syntax for an iCalendar stream is as follows:
 &gt;
 &gt;   icalstream = 1*icalobject
 &gt;
 &gt;   icalobject = "BEGIN" ":" "VCALENDAR" CRLF
 &gt;                icalbody
 &gt;                "END" ":" "VCALENDAR" CRLF

      </pre>
      </td>
      <td valign="top">Weak consensus.&nbsp; Would like more discussion.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">33<br>
      </td>
      <td valign="top">characters v. octets<br>
      </td>
      <td valign="top">In both cases change 255 characters to 255
octets.<br>
      </td>
      <td valign="top">consensus<br>
      </td>
    </tr>
    <tr>
      <td valign="top">34<br>
      </td>
      <td valign="top">"method" parameter<br>
      </td>
      <td valign="top">
      <pre>New text:

 &gt; The "method" parameter MUST be specified only for iCalendar
 &gt; stream that contains a single iCalendar object. The "method"
 &gt; parameter MUST be the same value as that specified in the "METHOD"
 &gt; component property in the iCalendar object. If one is present,
 &gt; the other MUST also be present.

      </pre>
      </td>
      <td valign="top">no consensus / disagreement<br>
      </td>
    </tr>
    <tr>
      <td valign="top">35<br>
      </td>
      <td valign="top">Section 4.2.10 language / language property<br>
      </td>
      <td valign="top">
      <pre>Proposed new text:

 &gt; Description: The parameter identifies the language of the text in
 &gt; the property or property parameter value. The value of the "language"
 &gt; property parameter is that defined in [RFC 1766].</pre>
      </td>
      <td valign="top">possible consensus.&nbsp; need to update RFC
reference.&nbsp; More discussion needed.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">36<br>
      </td>
      <td valign="top">X-name<br>
      </td>
      <td valign="top">
      <pre> &gt; x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
 &gt; ; Reserved for non-standard names. Can be used by bilateral
 &gt; ; agreement.


      </pre>
      </td>
      <td valign="top">No consensus on what bilateral means in this
context.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">37<br>
      </td>
      <td valign="top">4.6.1 Event Component: eventprop<br>
      </td>
      <td valign="top">
      <pre> &gt;  eventprop  = *(
 &gt;
 &gt;             ; the following are both REQUIRED,
 &gt;             ; but MUST NOT occur more than once
 &gt;
 &gt;             dtstamp / dtstart / uid /
 &gt;
 &gt;             ; the following are optional,
 &gt;             ; but MUST NOT occur more than once</pre>
      </td>
      <td valign="top">No objections.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">38<br>
      </td>
      <td valign="top">VTODO todoprop<br>
      </td>
      <td valign="top">
      <pre> &gt;  todoprop  = *(
 &gt;
 &gt;            ; the following are both REQUIRED,
 &gt;            ; but MUST NOT occur more than once
 &gt;
 &gt;            dtstamp / uid /
 &gt;
 &gt;            ; the following are optional,
 &gt;            ; but MUST NOT occur more than once
 &gt;
 &gt;            ...

      </pre>
      </td>
      <td valign="top">No objections.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">39<br>
      </td>
      <td valign="top">VJOURNAL journalprop<br>
      </td>
      <td valign="top">
      <pre> &gt;  jourprop = *(
 &gt;
 &gt;           ; the following are both REQUIRED,
 &gt;           ; but MUST NOT occur more than once
 &gt;
 &gt;           dtstamp / uid /
 &gt;
 &gt;           ; the following are optional,
 &gt;           ; but MUST NOT occur more than once</pre>
      </td>
      <td valign="top">No objections.<br>
      </td>
    </tr>
    <tr>
      <td valign="top">40<br>
      </td>
      <td valign="top">4.6.4 f/b component/ fbprop<br>
      </td>
      <td valign="top">
      <pre> &gt;  fbprop = *(
 &gt;
 &gt;         ; the following are both REQUIRED,
 &gt;         ; but MUST NOT occur more than once
 &gt;
 &gt;         dtstamp / uid /
 &gt;
 &gt;         ; the following are optional,
 &gt;         ; but MUST NOT occur more than once
 &gt;
 &gt;         ...</pre>
      </td>
      <td valign="top">No consensus as to what uid means in this
context.<br>
      </td>
    </tr>
  </tbody>
</table>
<br>
<br>
That is all for now.<br>
<br>
&lt;ChairHatOff&gt;<br>
</body>
</html>

--------------090604040605060603080805--


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 A65DD7F9E9 for <[e-mail]>; Thu, 24 Aug 2006 05:13:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9801C1422B2 for <[e-mail]>; Thu, 24 Aug 2006 05:13:11 -0700 (PDT)
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 29295-07 for <[e-mail]>; Thu, 24 Aug 2006 05:13:10 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id C808714227D for <[e-mail]>; Thu, 24 Aug 2006 05:13:09 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 24 Aug 2006 13:13:06 +0100
Message-ID: <[e-mail]>
Date: Thu, 24 Aug 2006 13:12:31 +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: Mark Crispin <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
References: <[e-mail]> <[e-mail]> <[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="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 24 Aug 2006 12:13:11 -0000

Mark Crispin wrote:

> Well, then, which is more important; having calendar fall back to 
> TEXT/PLAIN behavior (in which case you need CHARSET), or having 
> calendar objects be required to be UTF-8?
>
> Another thing that you could do is that TEXT/CALENDAR could require 
> that ;CHARSET=UTF-8 be present as a parameter.

I think this is the best way.

> Declare that a TEXT/CALENDAR which omits CHARSET, or has any charset 
> other than UTF-8, is undefined and not to be interpreted according to 
> the calendar specification.

I wouldn't go as far as saying that they are not covered by the calendar 
specification.
For example I find nothing wrong with a calendar that is entirely in 
US-ASCII and has to CHARSET parameter.

> By the way, all of these are to be treated as random ideas.  I'm not 
> pushing for any of this as a solution, although I believe that it 
> would be highly desirable to prevent any new application from getting 
> into the multi-charset business.

Right.



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 167E07FA08 for <[e-mail]>; Wed, 23 Aug 2006 18:39:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 06BEC1422AF for <[e-mail]>; Wed, 23 Aug 2006 18:39:50 -0700 (PDT)
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 31440-07 for <[e-mail]>; Wed, 23 Aug 2006 18:39:48 -0700 (PDT)
Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [204.127.192.85]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9659D1422A0 for <[e-mail]>; Wed, 23 Aug 2006 18:39:48 -0700 (PDT)
Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc15) with SMTP id <20060824013947m1500t4i8me>; Thu, 24 Aug 2006 01:39:48 +0000
From: "Tim Hare" <[e-mail]>
To: "'Calsify WG'" <[e-mail]>
Subject: RE: [Ietf-calsify] Section 4.1 Content Lines: x-name
Date: Wed, 23 Aug 2006 21:39:52 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcbF8W8yEerOieU0SI6UFnn5zbu1pABK8kNg
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=2.4 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID
X-Spam-Level: **
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 24 Aug 2006 01:39:50 -0000

Allowing vendor registration of extensions OR negotiation of bilateral
agreements about x-names _does_ move interoperability along, but I don't
think that it "simplifies" 2445/6/7.  In my personal opinion I would =
rather
see language that says that x-names are only guaranteed to be =
interoperable
between two identical instances of one vendor's software and that there =
is
no guarantee of interoperability when x-name collisions occur.  =
Registration
or x-name capability negotiation should be left to a later enhancement =
of
the standard, in my opion; trying to add such language now only seems to =
me
to slow down adoption of the "simplified" standard, and probably also =
incurs
delays in implementation of the standard.

I may be na=EFve on this subject, not being a calendar developer, but
common-sense reasoning leads me to believe that it is easier to restrict =
any
given implementation to simplified behavior than it is to add new =
function
to improve interoperability, because the restriction is a subset of =
already
working code.=20


Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Cyrus Daboo
Sent: Tuesday, August 22, 2006 9:47 AM
To: Bernard Desruisseaux; Calsify WG
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: x-name

Hi Bernard,

--On August 21, 2006 11:37:49 PM -0400 Bernard Desruisseaux
<[e-mail]> wrote:

>  > x-name             =3D "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
>  > ; Reserved for non-standard names. Can be used by bilateral  > ;=20
> agreement.

What does 'bilateral agreement' mean? iCalendar has no concept of =
content
negotiation between different clients/servers so I think that is
meaningless. Certainly I am not aware of anyone who checks to see =
whether
X- items are acceptable to a receiving entity.

I also don't like the use of 'non-standard' here. In fact what I would =
like
to see is vendors actually registering their properties so that
implementations may choose to inter operate if they so desire. To allow =
that
to work we need to setup the IANA registry to support vendor defined
properties, and we need a way to register vendorid's (note that ACAP has
already setup a vendor id registry that is also being used by some IMAP
extensions so we could re-use that, though the syntax would need to be
checked).

So I propose the following text instead:

 > x-name             =3D "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
 > ; Reserved for private names which may or may not be registered.

--
Cyrus Daboo

_______________________________________________
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 0948F7F99F for <[e-mail]>; Wed, 23 Aug 2006 18:27:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E7AA91422A6 for <[e-mail]>; Wed, 23 Aug 2006 18:27:07 -0700 (PDT)
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 13069-10 for <[e-mail]>; Wed, 23 Aug 2006 18:27:07 -0700 (PDT)
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by laweleka.osafoundation.org (Postfix) with ESMTP id 92FC01422A0 for <[e-mail]>; Wed, 23 Aug 2006 18:27:07 -0700 (PDT)
Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc11) with SMTP id <20060824012706m11002tj5ve>; Thu, 24 Aug 2006 01:27:06 +0000
From: "Tim Hare" <[e-mail]>
To: "'Calsify WG'" <[e-mail]>
Subject: RE: [Ietf-calsify] Section 4.4: "Single iCalendar object" versus"Sequence of iCalendar objects"
Date: Wed, 23 Aug 2006 21:27:11 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcbFl5GXZsskQ4zxSf+oEvQNVTZUxABhC4YQ
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=2.3 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID
X-Spam-Level: **
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 24 Aug 2006 01:27:08 -0000

1. If icalstream = 1*icalobject how does that allow n*icalobject ("multiple
BEGIN/END:VCALENDAR objects) within one MIME part?

2. I think the original iCalendar really intended to talk about multiple
iCalendar _components_ within one iCalendar "stream", basically that one
stream or serialized object / file could contain multiple VEVENTs, VTODOs,
for one calendar; I never understood from reading it that it wss intended to
handle multiple calendars for different "users" that way.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Cyrus Daboo
Sent: Monday, August 21, 2006 11:04 PM
To: Bernard Desruisseaux; Calsify WG
Subject: Re: [Ietf-calsify] Section 4.4: "Single iCalendar object"
versus"Sequence of iCalendar objects"

Hi Bernard,

--On August 21, 2006 10:46:30 PM -0400 Bernard Desruisseaux
<[e-mail]> wrote:

> Proposed new text:
>
>  > The Calendaring and Scheduling Core Object is a collection of  > 
> calendaring and scheduling information. Typically, this information  > 
> will consist of an iCalendar stream with a single iCalendar object.
>  > However, multiple iCalendar objects can be sequentially grouped  > 
> together in an iCalendar stream. The first line and last line of  > 
> the iCalendar object MUST contain a pair of iCalendar object  > 
> delimiter strings. The syntax for an iCalendar stream is as follows:
>  >
>  >   icalstream = 1*icalobject
>  >
>  >   icalobject = "BEGIN" ":" "VCALENDAR" CRLF
>  >                icalbody
>  >                "END" ":" "VCALENDAR" CRLF

+1

I definitely like the idea of icalstream as a way of describing multiple
BEGIN/END:VCALENDAR objects within one mime part etc. Whilst this does not
appear too frequently in iCalendar data, 2445 does make reference to such
things.

--
Cyrus Daboo

_______________________________________________
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 5DEA17F952 for <[e-mail]>; Wed, 23 Aug 2006 18:21:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F6B9142286 for <[e-mail]>; Wed, 23 Aug 2006 18:21:56 -0700 (PDT)
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 07598-08 for <[e-mail]>; Wed, 23 Aug 2006 18:21:54 -0700 (PDT)
Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by laweleka.osafoundation.org (Postfix) with ESMTP id D985114225E for <[e-mail]>; Wed, 23 Aug 2006 18:21:53 -0700 (PDT)
Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc14) with SMTP id <20060824012152m14002bjt6e>; Thu, 24 Aug 2006 01:21:53 +0000
From: "Tim Hare" <[e-mail]>
To: <[e-mail]>
Subject: RE: [Ietf-calsify] Section 4.1 Content Lines: x-name
Date: Wed, 23 Aug 2006 21:21:54 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcbFnWymWvk+Af7wRF++mevzMQIlkgBfhiBw
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=2.3 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID
X-Spam-Level: **
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 24 Aug 2006 01:21:56 -0000

Bilateral agreement between which two parties? 


Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Jay Batson
Sent: Monday, August 21, 2006 11:45 PM
To: Bernard Desruisseaux
Cc: Calsify WG
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: x-name

On Aug 21, 2006, at 11:37 PM, Bernard Desruisseaux wrote:

> In section 4.1 Content Lines of RFC 2445 it says:
>
> > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
> > ; Reservered for experimental use. Not intended for use in ; 
> > released products.
>
> The comment for x-name is in contradiction with the text in section
> 4.8.8.1 Non-standard Properties as well as the text in section 7.2 
> Registration of New Properties.
>
> New text proposed:
>
> > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
> > ; Reserved for non-standard names. Can be used by bilateral ; 
> > agreement.

+1

-------------
Jay Batson
[e-mail]
[phone] (w)
[phone] (m)


_______________________________________________
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 1F0F47F8F8 for <[e-mail]>; Wed, 23 Aug 2006 09:52:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0FCC51422AF for <[e-mail]>; Wed, 23 Aug 2006 09:52:47 -0700 (PDT)
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 31530-08 for <[e-mail]>; Wed, 23 Aug 2006 09:52:42 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 836411422AE for <[e-mail]>; Wed, 23 Aug 2006 09:52:42 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LGW0xr000497 for <[e-mail]>; Wed, 23 Aug 2006 11:52:40 -0500
Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 1776731051156351864; Wed, 23 Aug 2006 10:51:04 -0600
Message-ID: <[e-mail]>
Date: Wed, 23 Aug 2006 12:50:38 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Subject: [Ietf-calsify] RFC 2445: Updated references
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 23 Aug 2006 16:52:47 -0000

I propose to update the references of RFC 2445 as follows:

- RFC0822 changed to RFC2822 (Internet Message Format)

- RFC1738 changed to RFC3986 (URI Generic Syntax), and
                      RFC2368 (mailto URL scheme)

- RFC1766 changed to RFC3066 (Language Tag)

- RFC2234 changed to RFC4234 (ABNF)

- RFC2279 changed to RFC3629 (UTF-8).

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 4D8917F9A0 for <[e-mail]>; Wed, 23 Aug 2006 08:14:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3E6971422AC for <[e-mail]>; Wed, 23 Aug 2006 08:14:51 -0700 (PDT)
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 20991-01 for <[e-mail]>; Wed, 23 Aug 2006 08:14:48 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7A8961422AA for <[e-mail]>; Wed, 23 Aug 2006 08:14:48 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7NFEOLo026572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 11:14:27 -0400
Date: Wed, 23 Aug 2006 11:14:19 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>, Bill McQuillan <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt	/ UTF-8
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
Cc: Calsify List <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 23 Aug 2006 15:14:51 -0000

Hi Bernard,

--On August 23, 2006 11:06:13 AM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

> The question is "Do we actually care?".
>
> I would say that as long as the iCalendar stream is a valid
> UTF-8 document we are ok.

Agreed - my main concern is ensuring that the stream conforms to UTF-8 abnf 
- i.e. the characters are all valid. I don't really care whether the 'raw' 
unfolded text displays well or not in a text editor. After all, even in the 
absence of combining characters, the folding can occur in the middle of a 
word and the result may be nonsensical or even worse appear to be two valid 
words giving a different meaning to what was meant.

-- 
Cyrus Daboo



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 6A6EE7F943 for <[e-mail]>; Wed, 23 Aug 2006 08:08:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BF891422AA for <[e-mail]>; Wed, 23 Aug 2006 08:08:31 -0700 (PDT)
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 23787-02 for <[e-mail]>; Wed, 23 Aug 2006 08:08:28 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 94A6C1422A8 for <[e-mail]>; Wed, 23 Aug 2006 08:08:28 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7MCKmtA028329; Wed, 23 Aug 2006 09:08:23 -0600
Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 1776505591156345600; Wed, 23 Aug 2006 09:06:40 -0600
Message-ID: <[e-mail]>
Date: Wed, 23 Aug 2006 11:06:13 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Bill McQuillan <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[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-Whitelist: TRUE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify List <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 23 Aug 2006 15:08:31 -0000

Hi Bill,

The question is "Do we actually care?".

I would say that as long as the iCalendar stream is a valid
UTF-8 document we are ok.

Cheers,
Bernard

Bill McQuillan wrote:
> I think Bernard has pointed out one issue that occurred to me also--since
> the information is UTF8 text, an application that does not understand an
> iCalendar object could still read it, for instance a text editor. The
> question becomes how would it react to a line break in the middle of a
> composed character.
> 
> After browsing in the Unicode standard I found this sentence in Annex # 14
> - Line Breaking Properties:
> 
>    Combining character sequences are treated as units for the purpose of
>    line breaking.
> 
> If the text editor assumes this property, there will likely be some loss of
> information.
> 
> On Tue, 2006-08-22, Bernard Desruisseaux wrote:
>> [
>>    For those not familiar with "combining character sequence" here's
>>    how it is defined by Unicode: A character sequence consisting of
>>    either a base character followed by a sequence of one or more
>>    combining characters, or a sequence of one or more combining
>>    characters.
>> ]
> 
>> Let me try to put this another way. We need to decide and justify:
> 
>> 1- Whether we want to allow "multi-octet characters" to be split
>>     across lines.
> 
>> Answer: No.
>> Why   : Otherwise the resulting text would end up being invalid
>>          in the specified encoding.
> 
>> 2- Whether we want to allow "combining character sequences" to be
>>     split across lines.
> 
>> Answer: Yes.
>> Why   : (1) I'm assuming that it is valid for a "combining
>>          character" to be preceded by the LF character (but I
>>          don't know this for a fact...), and thus the resulting
>>          text would still be valid in the specified encoding
>>          (but would sure "look" different).
> 
>>          (2) A "combining character sequence" could probably be
>>          longer than 75 octets in *theory*! But I'm sure we would
>>          never see this in practice though...
> 
>> With this approach:
> 
>> - You could open an iCalendar object specified in the charset 'X'
>>    in any application that support 'X' without errors.
> 
>> - You would still need to unfold the iCalendar object to be able
>>    to "interpret" all the characters properly.
> 
>> What do you think?
> 
>> Cheers,
>> Bernard
> 
>> Mark Crispin wrote:
>>> Unfortunately, your answers are circular.
>>>
>>> I understand that you assert
>>>  (a) it is not alright to fold in the middle of a UTF-8 sequence
>>>      ("multi-octet sequence" is ambiguous and imprecise)
>>> but that
>>>  (b) it is alright to fold between a character and a combining character.
>>>
>>> However, you also give assertion (a) as the answer the "why" question 
>>> for (a) and (b).
>>>
>>> Why is it not alright to fold in the middle of a UTF-8 sequence?
>>>
>>> Why is it alright to fold between a character and a combining character?
>>>
>>>
>>> What is wrong with the assertation:
>>>     A proper interpretation of the text is impossible until
>>>     all folding is removed and the strings are catenated.
>>>     Therefore, folding may appear anywhere, even in the
>>>     middle of a UTF-8 sequence.
>>> or, alternatively:
>>>     A proper interpretation of a subtext is impossible unless
>>>     all UTF-8 sequences and combining characters appear in
>>>     that subtext.  Therefore, folding may not in the middle
>>>     of a UTF-8 sequence or separating the UTF-8 sequences of
>>>     any (and all) combining characters from the character
>>>     being combined.
>>>
>>> Why is one, or the other, of the above two assertations inferior to your
>>> pair of assertations?
>>>
>>> I'm sorry for being such a troublemaker, and to be honest I really don't
>>> know which of these is best.  But someone's got to do it.  Whatever 
>>> decision is made, we need to justify why that decision and not the 
>>> alternatives.
>>>
>>> -- Mark --
>>>
>>> http://staff.washington.edu/mrc
>>> Science does not emerge from voting, party politics, or public debate.
>>> Si vis pacem, para bellum.
> 


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 86B307F618 for <[e-mail]>; Wed, 23 Aug 2006 04:47:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7227A14221E for <[e-mail]>; Wed, 23 Aug 2006 04:47:01 -0700 (PDT)
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 28316-04 for <[e-mail]>; Wed, 23 Aug 2006 04:46:59 -0700 (PDT)
Received: from natblert.rzone.de (natblert.rzone.de [81.169.145.181]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C7D614228B for <[e-mail]>; Wed, 23 Aug 2006 04:46:58 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-169-012.pools.arcor-ip.net [84.63.169.12]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7NBkUmA021585; Wed, 23 Aug 2006 13:46:43 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Wed, 23 Aug 2006 13:45:51 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Mark Crispin <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 23 Aug 2006 11:47:01 -0000

Am Mittwoch, 23. August 2006 04:13 schrieb Bernard Desruisseaux:

> Let me try to put this another way. We need to decide and justify:
>
> 1- Whether we want to allow "multi-octet characters" to be split
>     across lines.
>
> Answer: No.
> Why   : Otherwise the resulting text would end up being invalid
>          in the specified encoding.
>
> 2- Whether we want to allow "combining character sequences" to be
>     split across lines.
>
> Answer: Yes.
> Why   : (1) I'm assuming that it is valid for a "combining
>          character" to be preceded by the LF character (but I
>          don't know this for a fact...), and thus the resulting
>          text would still be valid in the specified encoding
>          (but would sure "look" different).
>
>          (2) A "combining character sequence" could probably be
>          longer than 75 octets in *theory*! But I'm sure we would
>          never see this in practice though...
>
> With this approach:
>
> - You could open an iCalendar object specified in the charset 'X'
>    in any application that support 'X' without errors.
>
> - You would still need to unfold the iCalendar object to be able
>    to "interpret" all the characters properly.
>
> What do you think?

That's exactly how I understand your preceding proposal. Even if it did not 
mention combining character sequences. And that's how I understood Mark in 
his agreement on that issue.

Best Regards,

Oliver




-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 E01CA7FBAF for <[e-mail]>; Wed, 23 Aug 2006 01:59:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CF66B14229B for <[e-mail]>; Wed, 23 Aug 2006 01:59:08 -0700 (PDT)
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 23708-10 for <[e-mail]>; Wed, 23 Aug 2006 01:59:06 -0700 (PDT)
Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30B41142292 for <[e-mail]>; Wed, 23 Aug 2006 01:59:06 -0700 (PDT)
Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 6A95C24E15; Wed, 23 Aug 2006 04:59:27 -0400 (EDT)
Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id E016F82; Wed, 23 Aug 2006 04:59:25 -0400 (EDT)
Date: Wed, 23 Aug 2006 01:59:02 -0700
From: Bill McQuillan <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Calsify List <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, PRIORITY_NO_NAME
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 23 Aug 2006 08:59:09 -0000

I think Bernard has pointed out one issue that occurred to me also--since
the information is UTF8 text, an application that does not understand an
iCalendar object could still read it, for instance a text editor. The
question becomes how would it react to a line break in the middle of a
composed character.

After browsing in the Unicode standard I found this sentence in Annex # 14
- Line Breaking Properties:

   Combining character sequences are treated as units for the purpose of
   line breaking.

If the text editor assumes this property, there will likely be some loss of
information.

On Tue, 2006-08-22, Bernard Desruisseaux wrote:
> [
>    For those not familiar with "combining character sequence" here's
>    how it is defined by Unicode: A character sequence consisting of
>    either a base character followed by a sequence of one or more
>    combining characters, or a sequence of one or more combining
>    characters.
> ]

> Let me try to put this another way. We need to decide and justify:

> 1- Whether we want to allow "multi-octet characters" to be split
>     across lines.

> Answer: No.
> Why   : Otherwise the resulting text would end up being invalid
>          in the specified encoding.

> 2- Whether we want to allow "combining character sequences" to be
>     split across lines.

> Answer: Yes.
> Why   : (1) I'm assuming that it is valid for a "combining
>          character" to be preceded by the LF character (but I
>          don't know this for a fact...), and thus the resulting
>          text would still be valid in the specified encoding
>          (but would sure "look" different).

>          (2) A "combining character sequence" could probably be
>          longer than 75 octets in *theory*! But I'm sure we would
>          never see this in practice though...

> With this approach:

> - You could open an iCalendar object specified in the charset 'X'
>    in any application that support 'X' without errors.

> - You would still need to unfold the iCalendar object to be able
>    to "interpret" all the characters properly.

> What do you think?

> Cheers,
> Bernard

> Mark Crispin wrote:
>> Unfortunately, your answers are circular.
>> 
>> I understand that you assert
>>  (a) it is not alright to fold in the middle of a UTF-8 sequence
>>      ("multi-octet sequence" is ambiguous and imprecise)
>> but that
>>  (b) it is alright to fold between a character and a combining character.
>> 
>> However, you also give assertion (a) as the answer the "why" question 
>> for (a) and (b).
>> 
>> Why is it not alright to fold in the middle of a UTF-8 sequence?
>> 
>> Why is it alright to fold between a character and a combining character?
>> 
>> 
>> What is wrong with the assertation:
>>     A proper interpretation of the text is impossible until
>>     all folding is removed and the strings are catenated.
>>     Therefore, folding may appear anywhere, even in the
>>     middle of a UTF-8 sequence.
>> or, alternatively:
>>     A proper interpretation of a subtext is impossible unless
>>     all UTF-8 sequences and combining characters appear in
>>     that subtext.  Therefore, folding may not in the middle
>>     of a UTF-8 sequence or separating the UTF-8 sequences of
>>     any (and all) combining characters from the character
>>     being combined.
>> 
>> Why is one, or the other, of the above two assertations inferior to your
>> pair of assertations?
>> 
>> I'm sorry for being such a troublemaker, and to be honest I really don't
>> know which of these is best.  But someone's got to do it.  Whatever 
>> decision is made, we need to justify why that decision and not the 
>> alternatives.
>> 
>> -- Mark --
>> 
>> http://staff.washington.edu/mrc
>> Science does not emerge from voting, party politics, or public debate.
>> Si vis pacem, para bellum.

-- 
Bill McQuillan <[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 50F287FC4A for <[e-mail]>; Tue, 22 Aug 2006 19:13:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 41A371422A6 for <[e-mail]>; Tue, 22 Aug 2006 19:13:56 -0700 (PDT)
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 15610-02 for <[e-mail]>; Tue, 22 Aug 2006 19:13:54 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 69E89142292 for <[e-mail]>; Tue, 22 Aug 2006 19:13:54 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LI052S006198; Tue, 22 Aug 2006 21:13:48 -0500
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-97-45.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1770337361156299213; Tue, 22 Aug 2006 20:13:33 -0600
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 22:13:34 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Mark Crispin <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
References: <[e-mail]>	<[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-Whitelist: TRUE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 23 Aug 2006 02:13:56 -0000

[
   For those not familiar with "combining character sequence" here's
   how it is defined by Unicode: A character sequence consisting of
   either a base character followed by a sequence of one or more
   combining characters, or a sequence of one or more combining
   characters.
]

Let me try to put this another way. We need to decide and justify:

1- Whether we want to allow "multi-octet characters" to be split
    across lines.

Answer: No.
Why   : Otherwise the resulting text would end up being invalid
         in the specified encoding.

2- Whether we want to allow "combining character sequences" to be
    split across lines.

Answer: Yes.
Why   : (1) I'm assuming that it is valid for a "combining
         character" to be preceded by the LF character (but I
         don't know this for a fact...), and thus the resulting
         text would still be valid in the specified encoding
         (but would sure "look" different).

         (2) A "combining character sequence" could probably be
         longer than 75 octets in *theory*! But I'm sure we would
         never see this in practice though...

With this approach:

- You could open an iCalendar object specified in the charset 'X'
   in any application that support 'X' without errors.

- You would still need to unfold the iCalendar object to be able
   to "interpret" all the characters properly.

What do you think?

Cheers,
Bernard

Mark Crispin wrote:
> Unfortunately, your answers are circular.
> 
> I understand that you assert
>  (a) it is not alright to fold in the middle of a UTF-8 sequence
>      ("multi-octet sequence" is ambiguous and imprecise)
> but that
>  (b) it is alright to fold between a character and a combining character.
> 
> However, you also give assertion (a) as the answer the "why" question 
> for (a) and (b).
> 
> Why is it not alright to fold in the middle of a UTF-8 sequence?
> 
> Why is it alright to fold between a character and a combining character?
> 
> 
> What is wrong with the assertation:
>     A proper interpretation of the text is impossible until
>     all folding is removed and the strings are catenated.
>     Therefore, folding may appear anywhere, even in the
>     middle of a UTF-8 sequence.
> or, alternatively:
>     A proper interpretation of a subtext is impossible unless
>     all UTF-8 sequences and combining characters appear in
>     that subtext.  Therefore, folding may not in the middle
>     of a UTF-8 sequence or separating the UTF-8 sequences of
>     any (and all) combining characters from the character
>     being combined.
> 
> Why is one, or the other, of the above two assertations inferior to your 
> pair of assertations?
> 
> I'm sorry for being such a troublemaker, and to be honest I really don't 
> know which of these is best.  But someone's got to do it.  Whatever 
> decision is made, we need to justify why that decision and not the 
> alternatives.
> 
> -- Mark --
> 
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
> _______________________________________________
> 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 2615F7FBEF for <[e-mail]>; Tue, 22 Aug 2006 18:17:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1787D1422A4 for <[e-mail]>; Tue, 22 Aug 2006 18:17:12 -0700 (PDT)
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 02665-04 for <[e-mail]>; Tue, 22 Aug 2006 18:17:09 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8D249142294 for <[e-mail]>; Tue, 22 Aug 2006 18:17:09 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7LH4bob030952 for <[e-mail]>; Tue, 22 Aug 2006 19:17:07 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-97-45.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1769372091156295813; Tue, 22 Aug 2006 19:16:53 -0600
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 21:16:52 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: NON-US-ASCII
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 23 Aug 2006 01:17:12 -0000

Bernard Desruisseaux wrote:
> In section 4.1 Content Lines of RFC 2445 it says:
> 
>  >     NON-US-ASCII       = %x80-F8
>  >     ; Use restricted by charset parameter
>  >     ; on outer MIME object (UTF-8 preferred)
> 
> Unless I'm mistaken, the characters %xF9 to %xFD are allowed in UTF-8.

It seems I was mistaken.

I had come to this quick conclusion by reading the following
statement in RFC 2279:

- The octet values FE and FF never appear.

But RFC 3629 which obsoletes RFC 2279 specify has the following
statement instead:

- The octet values C0, C1, F5 to FF never appear.

As such, the NON-US-ASCII rule should be:

   NON-US-ASCII       = %x80-BF / %xC2-F4

Cheers,
Bernard

> 
> At a minimum this should be:
> 
>  >     NON-US-ASCII       = %x80-FD
> or
>  >     NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
>  >     ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629.
> 
> and if we agree to support ISO-8859-1, then it should be:
> 
>  >     NON-US-ASCII       = %x80-FF
> 
> Cheers,
> Bernard
> 
> _______________________________________________
> 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 AD19E7FBF1 for <[e-mail]>; Tue, 22 Aug 2006 16:28:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9EFE11422A0 for <[e-mail]>; Tue, 22 Aug 2006 16:28:44 -0700 (PDT)
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 23958-09 for <[e-mail]>; Tue, 22 Aug 2006 16:28:42 -0700 (PDT)
Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2269B14229F for <[e-mail]>; Tue, 22 Aug 2006 16:28:42 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MNSd5q005082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Aug 2006 16:28:39 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MNSd58002694 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Aug 2006 16:28:39 -0700
Date: Tue, 22 Aug 2006 16:27:58 -0700 (Pacific Daylight Time)
From: Mark Crispin <[e-mail]>
To: Oliver Block <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Networks & Distributed Computing
Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.22.160442
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 23:28:44 -0000

Unfortunately, your answers are circular.

I understand that you assert
  (a) it is not alright to fold in the middle of a UTF-8 sequence
      ("multi-octet sequence" is ambiguous and imprecise)
but that
  (b) it is alright to fold between a character and a combining character.

However, you also give assertion (a) as the answer the "why" question for 
(a) and (b).

Why is it not alright to fold in the middle of a UTF-8 sequence?

Why is it alright to fold between a character and a combining character?


What is wrong with the assertation:
 	A proper interpretation of the text is impossible until
 	all folding is removed and the strings are catenated.
 	Therefore, folding may appear anywhere, even in the
 	middle of a UTF-8 sequence.
or, alternatively:
 	A proper interpretation of a subtext is impossible unless
 	all UTF-8 sequences and combining characters appear in
 	that subtext.  Therefore, folding may not in the middle
 	of a UTF-8 sequence or separating the UTF-8 sequences of
 	any (and all) combining characters from the character
 	being combined.

Why is one, or the other, of the above two assertations inferior to your 
pair of assertations?

I'm sorry for being such a troublemaker, and to be honest I really don't 
know which of these is best.  But someone's got to do it.  Whatever 
decision is made, we need to justify why that decision and not the 
alternatives.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


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 928127FBDA for <[e-mail]>; Tue, 22 Aug 2006 15:49:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 83F861422A5 for <[e-mail]>; Tue, 22 Aug 2006 15:49:52 -0700 (PDT)
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 17751-05 for <[e-mail]>; Tue, 22 Aug 2006 15:49:49 -0700 (PDT)
Received: from natklopstock.rzone.de (natklopstock.rzone.de [81.169.145.174]) by laweleka.osafoundation.org (Postfix) with ESMTP id A0A4C1422A4 for <[e-mail]>; Tue, 22 Aug 2006 15:49:48 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-169-012.pools.arcor-ip.net [84.63.169.12]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7MMnPLt014176; Wed, 23 Aug 2006 00:49:40 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: Mark Crispin <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Wed, 23 Aug 2006 00:48:46 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 22:49:52 -0000

Am Dienstag, 22. August 2006 21:32 schrieben Sie:
> On Tue, 22 Aug 2006, Oliver Block wrote:
> > No, you've misunderstood me. I mean, if a composite character is a
> > multi-octet sequence.
>
> German lower-case umlaut-a can be transmitted as U+00e4 or U+0061 U+0308.
>
> In UTF-8, this is either C3 A4 and 61 CC 88.  Both of these are multi
> octet sequences.

That's right. C3 A4 and CC 88 are multi-octet sequences. 61 is 01100001 
(binary) and IMHO multi-octet bytes begin (1st byte) with 110..., 1110..., 
11110..., as you know. 

A well-formed multi-byte sequence (as called by the unicode standard), 
consisting of 3 bytes start with E0, E1..EC, ED, EE..EF. 
(Table 3-6, p. 78)

> Questions:
>   (a) is it alright to fold between C3 and A4?

No. (multi-octet sequence.)

>   (b) is it alright to fold between 61 and CC?

Yes. 0x61 is not part of a multi-octet sequence.

>   (c) is it alright to fold between CC and 88?

No. CC is part of the multi-octet sequence CC 88

> If the answer to (a) is "no", presumably it is also "no" for (c).  If not,
> why not?

I agree on that.

> If the answer is (a) is "no", is it also "no" for (b)?  Why?  Or, why not?

0x61 is IMHO not part of a multi-octet sequence.

[,,,]

> These questions need to be considered, and answered, carefully.  The more
> that I think about these questions, the less confident that I am that I
> know the answers.

That's the same with me. But having no answer does _sometimes_ indicate that 
the questions need to be thought over.

This answer took me two hours. I hope I passed the exam. :)

Sincerely,

Oliver


-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 173197FC41 for <[e-mail]>; Tue, 22 Aug 2006 13:20:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 087E71422AA for <[e-mail]>; Tue, 22 Aug 2006 13:20:42 -0700 (PDT)
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 29553-05 for <[e-mail]>; Tue, 22 Aug 2006 13:20:40 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4413314228E for <[e-mail]>; Tue, 22 Aug 2006 13:20:40 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MKKSde005348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 16:20:33 -0400
Date: Tue, 22 Aug 2006 16:20:22 -0400
From: Cyrus Daboo <[e-mail]>
To: Robert Ransdell <[e-mail]>, Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of	iCalendar objects
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <OFFC6B672B.20403666-ON852571D2.006E14BB-852571D2.006DE4AA@notes dev.ibm.com>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 20:20:42 -0000

Hi Robert,

--On August 22, 2006 4:03:50 PM -0400 Robert Ransdell 
<[e-mail]> wrote:

> If I invite a new attendee to a repeating meeting that has  been modified
> after the rule was created than the iCalendar stream should have original
> invite with rule plus additional VEvents for the modified dates.

Right, but in terms of iTIP that would all be sent as a single iCalendar 
object (one BEGIN/END:VCALENDAR) so there would be a single METHOD. As far 
as iTIP is concerned, you can only ever send one iCalendar object per 
transaction (i.e. per MIME type). However, iCalendar itself does not have 
that restriction - multiple iCalendar objects per iCalendar stream (mime 
part) is allowed.

The question is how to handle the method= mime parameter for multiple 
iCalendar objects per stream (mime part). I think Bernard's argument that 
method= is not specified is fine since such an object is not being used in 
iTIP, and thus method is not of interest.

-- 
Cyrus Daboo



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 64B497FC1E; Tue, 22 Aug 2006 13:03:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 56B1A1422A5; Tue, 22 Aug 2006 13:03:56 -0700 (PDT)
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 10678-08; Tue, 22 Aug 2006 13:03:53 -0700 (PDT)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8021514228E; Tue, 22 Aug 2006 13:03:53 -0700 (PDT)
In-Reply-To: <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V656_08202006NP August 20, 2006
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 16:03:50 -0400
From: "Robert Ransdell" <[e-mail]>
X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 7.0.1|January 17, 2006) at 08/22/2006 03:54:53 PM, Serialize complete at 08/22/2006 03:54:53 PM
Content-Type: multipart/alternative; boundary="=_alternative 006DE4A1852571D2_="
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, HTML_40_50, HTML_MESSAGE
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 20:03:56 -0000

This is a multipart message in MIME format.
--=_alternative 006DE4A1852571D2_=
Content-Type: text/plain; charset="US-ASCII"

If I invite a new attendee to a repeating meeting that has  been modified 
after the rule was created than the iCalendar stream should have original 
invite with rule plus additional VEvents for the modified dates.




Bernard Desruisseaux <[e-mail]> 
Sent by: [e-mail]
08/22/2006 04:00 PM

To
Alexey Melnikov <[e-mail]>
cc
Calsify WG <[e-mail]>
Subject
Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of 
iCalendar objects






Alexey Melnikov wrote:
> Bernard Desruisseaux wrote:
>> New text:
>>
>> > The "method" parameter MUST be specified only for iCalendar
>> > stream that contains a single iCalendar object.
> 
> No, I think this is not correct. It is Ok to have multiple iCalendar 
> objects in an iCalendar stream, as long as they all have the same METHOD 

> property.

Where is that defined?

My reasoning is that if the iCalendar stream contains more than one
iCalendar object then it most likely doesn't describe a scheduling
transaction, and thus you probably shouldn't specify a "method"
parameter in the Content-Type header field.

Cheers,
Bernard
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


--=_alternative 006DE4A1852571D2_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">If I invite a new attendee to a repeating
meeting that has &nbsp;been modified after the rule was created than the
iCalendar stream should have original invite with rule plus additional
VEvents for the modified dates.</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Bernard Desruisseaux &lt;[e-mail]&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: [e-mail]</font>
<p><font size=1 face="sans-serif">08/22/2006 04:00 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Alexey Melnikov &lt;[e-mail]&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">Calsify WG &lt;[e-mail]&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Ietf-calsify] Section 3.2: &quot;method&quot;
parameter and sequence of &nbsp; &nbsp; &nbsp; &nbsp;iCalendar
objects</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Alexey Melnikov wrote:<br>
&gt; Bernard Desruisseaux wrote:<br>
&gt;&gt; New text:<br>
&gt;&gt;<br>
&gt;&gt; &gt; The &quot;method&quot; parameter MUST be specified only for
iCalendar<br>
&gt;&gt; &gt; stream that contains a single iCalendar object.<br>
&gt; <br>
&gt; No, I think this is not correct. It is Ok to have multiple iCalendar
<br>
&gt; objects in an iCalendar stream, as long as they all have the same
METHOD <br>
&gt; property.<br>
<br>
Where is that defined?<br>
<br>
My reasoning is that if the iCalendar stream contains more than one<br>
iCalendar object then it most likely doesn't describe a scheduling<br>
transaction, and thus you probably shouldn't specify a &quot;method&quot;<br>
parameter in the Content-Type header field.<br>
<br>
Cheers,<br>
Bernard<br>
_______________________________________________<br>
Ietf-calsify mailing list<br>
[e-mail]<br>
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify<br>
</font></tt>
<br>
--=_alternative 006DE4A1852571D2_=--


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 D65D27FC1E for <[e-mail]>; Tue, 22 Aug 2006 12:59:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C78BD1422A5 for <[e-mail]>; Tue, 22 Aug 2006 12:59:57 -0700 (PDT)
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 27836-05 for <[e-mail]>; Tue, 22 Aug 2006 12:59:54 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5601114228E for <[e-mail]>; Tue, 22 Aug 2006 12:59:54 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LGRs8i026781; Tue, 22 Aug 2006 14:59:46 -0500
Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 1768930941156276684; Tue, 22 Aug 2006 13:58:04 -0600
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 15:57:41 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 19:59:58 -0000

Alexey Melnikov wrote:
> Bernard Desruisseaux wrote:
>> New text:
>>
>> > The "method" parameter MUST be specified only for iCalendar
>> > stream that contains a single iCalendar object.
> 
> No, I think this is not correct. It is Ok to have multiple iCalendar 
> objects in an iCalendar stream, as long as they all have the same METHOD 
> property.

Where is that defined?

My reasoning is that if the iCalendar stream contains more than one
iCalendar object then it most likely doesn't describe a scheduling
transaction, and thus you probably shouldn't specify a "method"
parameter in the Content-Type header field.

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 E031C7FC23 for <[e-mail]>; Tue, 22 Aug 2006 12:33:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D278914229B for <[e-mail]>; Tue, 22 Aug 2006 12:33:04 -0700 (PDT)
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 22241-04 for <[e-mail]>; Tue, 22 Aug 2006 12:33:02 -0700 (PDT)
Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3773A14228E for <[e-mail]>; Tue, 22 Aug 2006 12:33:02 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MJWx89027781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Aug 2006 12:32:59 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MJWx43002056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Aug 2006 12:32:59 -0700
Date: Tue, 22 Aug 2006 12:32:53 -0700 (Pacific Daylight Time)
From: Mark Crispin <[e-mail]>
To: Oliver Block <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Networks & Distributed Computing
Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.22.120942
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 19:33:05 -0000

On Tue, 22 Aug 2006, Oliver Block wrote:
> No, you've misunderstood me. I mean, if a composite character is a multi-octet
> sequence.

German lower-case umlaut-a can be transmitted as U+00e4 or U+0061 U+0308.

In UTF-8, this is either C3 A4 and 61 CC 88.  Both of these are multi 
octet sequences.

Questions:
  (a) is it alright to fold between C3 and A4?
  (b) is it alright to fold between 61 and CC?
  (c) is it alright to fold between CC and 88?

If the answer to (a) is "yes", presumably it is also "yes" for (b) and 
(c).  If not, why not?

If the answer to (a) is "no", presumably it is also "no" for (c).  If not, 
why not?

If the answer is (a) is "no", is it also "no" for (b)?  Why?  Or, why not?


The statement "nobody ever uses U+0061 U+0308 to send German umlaut-a" is 
not an acceptable answer.  The fact that there are some precomposed 
characters in Unicode does not mean that we can presume that all 
characters that will be used in email are precomposed.

So, to understand the problem properly, we should assume text with the 
decomposed form.

So, why is it any more wrong to fold in the middle of a UTF-8 sequence, as 
in (a) and (c) above, than it is to fold in the middle of a composed 
character sequence?

Doesn't an application need first to remove folding from a text prior to 
any other processing (including UTF-8 processing)?

Given that the combining characters modify the previous character, isn't 
is wrong to separate them into two UTF-8 strings by folding, even if the 
strings themselves appear to be valid UTF-8?

What does it mean when a string begins with a combining character? 
Does it modify the space of the line of the fold instead of the previous 
string?  If the two strings must be catenated prior to any interpretation, 
what is the harm of folding within a UTF-8 sequence?

If it is "alright" to allow a composed character sequence to be truncated, 
does it remain "alright" if the truncation results in some obscenity or 
blasphemy instead of the original piety?

These questions need to be considered, and answered, carefully.  The more 
that I think about these questions, the less confident that I am that I 
know the answers.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


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 2A2A57FBF8 for <[e-mail]>; Tue, 22 Aug 2006 12:05:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A81E1422AA for <[e-mail]>; Tue, 22 Aug 2006 12:05:03 -0700 (PDT)
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 17136-10 for <[e-mail]>; Tue, 22 Aug 2006 12:05:01 -0700 (PDT)
Received: from natlemon.rzone.de (natlemon.rzone.de [81.169.145.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6153C142282 for <[e-mail]>; Tue, 22 Aug 2006 12:05:01 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-169-012.pools.arcor-ip.net [84.63.169.12]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7MJ4sFp000887 for <[e-mail]>; Tue, 22 Aug 2006 21:04:55 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Tue, 22 Aug 2006 21:04:25 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 19:05:03 -0000

Am Dienstag, 22. August 2006 20:56 schrieben Sie:
> > What I'd like to know is: are your concerns about decompositions (or
> > composite characters) legitimate. I did not find anything in the unicode
> > specs, yet. But maybe you did!?
>
> I don't understand this comment either.  Do you claim that nobody uses any
> of the Unicode composing characters?

No, you've misunderstood me. I mean, if a composite character is a multi-octet 
sequence.

Regards,

Oliver


-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 11C967FBBF for <[e-mail]>; Tue, 22 Aug 2006 11:56:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 03BC91422AA for <[e-mail]>; Tue, 22 Aug 2006 11:56:25 -0700 (PDT)
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 10643-09 for <[e-mail]>; Tue, 22 Aug 2006 11:56:23 -0700 (PDT)
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 711A5142282 for <[e-mail]>; Tue, 22 Aug 2006 11:56:23 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MIuKlp031915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Aug 2006 11:56:20 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com (D-140-142-21-33.dhcp4.washington.edu [140.142.21.33]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MIuKpm016479 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Aug 2006 11:56:20 -0700
Date: Tue, 22 Aug 2006 11:56:18 -0700
From: Mark Crispin <[e-mail]>
To: Oliver Block <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Networks & Distributed Computing
Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.22.113942
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 18:56:25 -0000

On Tue, 22 Aug 2006, Oliver Block wrote:
> On one hand you are complaining about not folding properly, but on the other
> hand you do not complain about delivering invalid UTF-8.

I don't understand this comment.

Folding is a defined protocol concept.  The question is about what, if 
any, circumstances folding is prohibited.

The proposal is to prohibit folding within a UTF-8 sequence for a Unicode 
character.  The question is if folding should also be prohibited prior to 
Unicode composing characters.

> What I'd like to know is: are your concerns about decompositions (or composite
> characters) legitimate. I did not find anything in the unicode specs, yet.
> But maybe you did!?

I don't understand this comment either.  Do you claim that nobody uses any 
of the Unicode composing characters?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


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 6EEAB7F97E for <[e-mail]>; Tue, 22 Aug 2006 11:51:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6016E1422AA for <[e-mail]>; Tue, 22 Aug 2006 11:51:24 -0700 (PDT)
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 20136-01 for <[e-mail]>; Tue, 22 Aug 2006 11:51:22 -0700 (PDT)
Received: from natsmtp00.rzone.de (natsmtp00.rzone.de [81.169.145.165]) by laweleka.osafoundation.org (Postfix) with ESMTP id 83CF6142282 for <[e-mail]>; Tue, 22 Aug 2006 11:51:22 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-169-012.pools.arcor-ip.net [84.63.169.12]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7MIpIHr020784 for <[e-mail]>; Tue, 22 Aug 2006 20:51:19 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Tue, 22 Aug 2006 20:50:39 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 18:51:24 -0000

Am Dienstag, 22. August 2006 20:00 schrieb Mark Crispin:
> On Tue, 22 Aug 2006, Cyrus Daboo wrote:
> Once again, what problem are you trying to sold?
>
> I think that you are trying to solve the problem that a dumb application,
> which does not properly unfold first, would see a broken UTF-8 sequence.
> An example would be something that outputs this data as raw text.

On one hand you are complaining about not folding properly, but on the other 
hand you do not complain about delivering invalid UTF-8.

What I'd like to know is: are your concerns about decompositions (or composite 
characters) legitimate. I did not find anything in the unicode specs, yet. 
But maybe you did!?

Best Regards,

Oliver

-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 960B87F786 for <[e-mail]>; Tue, 22 Aug 2006 11:00:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 654BB142296 for <[e-mail]>; Tue, 22 Aug 2006 11:00:46 -0700 (PDT)
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 10679-09 for <[e-mail]>; Tue, 22 Aug 2006 11:00:43 -0700 (PDT)
Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D66FC142250 for <[e-mail]>; Tue, 22 Aug 2006 11:00:43 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MI0cco006562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Aug 2006 11:00:38 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MI0csd029131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Aug 2006 11:00:38 -0700
Date: Tue, 22 Aug 2006 11:00:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Networks & Distributed Computing
Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.22.104442
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 18:00:47 -0000

On Tue, 22 Aug 2006, Cyrus Daboo wrote:
>> Am I correct that the intent is to prohibit breaking up a UTF-8 sequence
>> for a single Unicode codepoint, and that there is no intent to prohibit
>> breaking up a sequence of character + combining characters?
> Yes.

OK.

>> What is the purpose for the prohibition?
> To ensure that the text data generated after folding remains valid UTF-8. 
> Obviously inserting CR-LF-SPACE into the middle of a multi-octet UTF-8 
> sequence invalidates that sequence.

But this only if the sequence is interpreted to treat the CR-LF-SPACE as 
significant text, as opposed to merely a protocol artifact to do 
continuation, correct?

Isn't it supposed to unfold first, before interpreting the contents?

Once again, what problem are you trying to sold?

I think that you are trying to solve the problem that a dumb application, 
which does not properly unfold first, would see a broken UTF-8 sequence. 
An example would be something that outputs this data as raw text.

If that's the problem, it should be stated as such.  But if that is the 
problem, then the problem is still not solved because of the combining 
character problem.  Unless you just seek a 98% solution.  In which case, 
that too should be stated.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


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 541DD7FBD9 for <[e-mail]>; Tue, 22 Aug 2006 10:44:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 44BDA14229F for <[e-mail]>; Tue, 22 Aug 2006 10:44:45 -0700 (PDT)
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 10679-02 for <[e-mail]>; Tue, 22 Aug 2006 10:44:44 -0700 (PDT)
Received: from bycast.com (bycast.com [207.61.255.252]) by laweleka.osafoundation.org (Postfix) with ESMTP id CB4BB142294 for <[e-mail]>; Tue, 22 Aug 2006 10:44:43 -0700 (PDT)
Received: from [192.168.110.126] (HELO localhost.localdomain) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTP id 1009620 for [e-mail]; Tue, 22 Aug 2006 10:44:41 -0700
Received: by localhost.localdomain (Postfix, from userid 2122) id 14E20510443; Tue, 22 Aug 2006 10:44:42 -0700 (PDT)
Date: Tue, 22 Aug 2006 10:44:42 -0700
From: Sam Roberts <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255	octets
Message-ID: <20060822174441.GA20752@pebble>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.11
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 17:44:45 -0000

On Tue, Aug 22, 2006 at 09:37:05AM -0400, Cyrus Daboo wrote:
> Good point. As per line folding, I think what should be said is something 
> like 'truncation can occur at 255 octets provided it does cause a 
Do you mean "does NOT cause"?

> multi-octet character to be split. If there is a multi-octet character at 
> the 255 octet position, then truncation can occur at the next whole 
> character below 255 octets'. Of course that could still result in some 
> weirdness with combining characters etc





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 4036F7FBC1 for <[e-mail]>; Tue, 22 Aug 2006 09:08:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 31BE51422AC for <[e-mail]>; Tue, 22 Aug 2006 09:08:21 -0700 (PDT)
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 06834-10 for <[e-mail]>; Tue, 22 Aug 2006 09:08:20 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7521D14228B for <[e-mail]>; Tue, 22 Aug 2006 09:08:20 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MG8AGc002962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 12:08:12 -0400
Date: Tue, 22 Aug 2006 12:08:04 -0400
From: Cyrus Daboo <[e-mail]>
To: Mark Crispin <[e-mail]>, Eliot Lear <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt	/ UTF-8
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 16:08:21 -0000

Hi Mark,

--On August 22, 2006 8:52:03 AM -0700 Mark Crispin <[e-mail]> 
wrote:

> Am I correct that the intent is to prohibit breaking up a UTF-8 sequence
> for a single Unicode codepoint, and that there is no intent to prohibit
> breaking up a sequence of character + combining characters?

Yes.

> What is the purpose for the prohibition?

To ensure that the text data generated after folding remains valid UTF-8. 
Obviously inserting CR-LF-SPACE into the middle of a multi-octet UTF-8 
sequence invalidates that sequence.

> Clearly, we have to fit within a buffer, such as the 75 octet limit for a
> MIME encoded-word.  But MIME encoded-word has rules for concatenation
> when the desired text is longer than can fit in a single encoded-word.

PS I believe the terminology Bernard originally proposed was copied from 
one of the MIME specs - of course that does not mean further clarification 
should not be done...

-- 
Cyrus Daboo



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 8B2257FB2A for <[e-mail]>; Tue, 22 Aug 2006 08:52:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7969B1422BC for <[e-mail]>; Tue, 22 Aug 2006 08:52:08 -0700 (PDT)
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 19679-03 for <[e-mail]>; Tue, 22 Aug 2006 08:52:06 -0700 (PDT)
Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6FDC61422B8 for <[e-mail]>; Tue, 22 Aug 2006 08:52:06 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MFq5Oi013626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Aug 2006 08:52:05 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MFq4AS009187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Aug 2006 08:52:04 -0700
Date: Tue, 22 Aug 2006 08:52:03 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Sender: [e-mail]
To: Eliot Lear <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.22.82942
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 15:52:08 -0000

On Tue, 22 Aug 2006, Eliot Lear wrote:
>> However, before we do this, I want to make sure that we are referring
>> to "characters" in the context of "Unicode codepoints"; and thus a
>> "multi-octet character" refers to a maximal-length UTF-8
>> representation of a Unicode character (4 octets).
>>
>> If, on the other hand, we are referring to the UTF-8 representation of
>> a composite character (that is, one composed of a base character and
>> one or more combining characters), we need to back off or at least
>> require precomposed forms.  I've seen some decomposed forms that are
>> quite lengthy.
>
> Can you please propose the exact alternate text you would like?  This
> will help move things along.

It's difficult to propose alternative text when I don't know, precisely, 
what the intent is.

Am I correct that the intent is to prohibit breaking up a UTF-8 sequence 
for a single Unicode codepoint, and that there is no intent to prohibit 
breaking up a sequence of character + combining characters?

What is the purpose for the prohibition?

Clearly, we have to fit within a buffer, such as the 75 octet limit for a 
MIME encoded-word.  But MIME encoded-word has rules for concatenation when 
the desired text is longer than can fit in a single encoded-word.

If the purpose is to assist dumb software that blats to a terminal 
emulator, I see little/no hope unless the buffer is huge.  IIRC, some 
UTF-8 sequences for character + combining character (take a look at some 
of the Arabic decompositions) are larger than what would fit in a MIME 
encoded-word.

If the software handles concatenation properly, then I don't see what the 
problem is even if the break is in the middle of a single UTF-8 sequence. 
If it doesn't, I see no hope of the software working right due to 
combining characters.

I won't object if the idea is to "cover the 98% case, and accept that the 
other 2% is broken."  But I haven't heard that stated as such yet.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.


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 16F2A7FA5A for <[e-mail]>; Tue, 22 Aug 2006 08:09:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 07DCD1422BD for <[e-mail]>; Tue, 22 Aug 2006 08:09:07 -0700 (PDT)
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 19651-04 for <[e-mail]>; Tue, 22 Aug 2006 08:09:05 -0700 (PDT)
Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8CDFB1422BC for <[e-mail]>; Tue, 22 Aug 2006 08:09:05 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MF92nU028282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Aug 2006 08:09:02 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7MF91s7031736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Aug 2006 08:09:02 -0700
Date: Tue, 22 Aug 2006 08:09:00 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Sender: [e-mail]
To: Oliver Block <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.22.74942
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 15:09:07 -0000

On Tue, 22 Aug 2006, Oliver Block wrote:
> Am Montag, 21. August 2006 23:18 schrieb Mark Crispin:
>> If, on the other hand, we are referring to the UTF-8 representation of a
>> composite character (that is, one composed of a base character and one or
>> more combining characters), we need to back off or at least require
>> precomposed forms.
> But those are IMHO _character_ sequences, aren't they?

I hope that those are "character sequences" and not "characters".  That's 
what they are in Unicode.  But we have a long history in the IETF of using 
words informally without agreement as to the precise meaning.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.


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 9CB967FBA4 for <[e-mail]>; Tue, 22 Aug 2006 07:39:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C78C1422B8 for <[e-mail]>; Tue, 22 Aug 2006 07:39:37 -0700 (PDT)
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 14829-05 for <[e-mail]>; Tue, 22 Aug 2006 07:39:37 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EA94D1422B6 for <[e-mail]>; Tue, 22 Aug 2006 07:39:36 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MEd7N8002146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 10:39:09 -0400
Date: Tue, 22 Aug 2006 10:39:01 -0400
From: Cyrus Daboo <[e-mail]>
To: Arnaud Quillaud <[e-mail]>, Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Subject: RE: [Ietf-calsify] Section 4.6.4 Free/Busy Component: fbprop
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 14:39:37 -0000

Hi Arnaud,

--On August 22, 2006 4:23:09 PM +0200 Arnaud Quillaud 
<[e-mail]> wrote:

> I suspect that most existing applications (if not all) use fb components
> only for publishing and hence generate them withough any UID. When
> publishing fb info what would be the meaning/usage of the UID ? It is not
> described in the spec.

Good point. In fact the original iTIP does not require UID in VFREEBUSY 
when using the PUBLISH method, but does require it for REQUEST and REPLY 
methods. However, UID is needed if you ever want to send out updates to 
published data (so that the update can replace the original), so in 2446bis 
I made UID a requirement for PUBLISH.

-- 
Cyrus Daboo



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 C77AA7FBA4 for <[e-mail]>; Tue, 22 Aug 2006 07:19:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B8CBC1422B8 for <[e-mail]>; Tue, 22 Aug 2006 07:19:34 -0700 (PDT)
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 15056-01 for <[e-mail]>; Tue, 22 Aug 2006 07:19:34 -0700 (PDT)
Received: from gmpea-pix-1.sun.com (gmpea-pix-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id BA1571422AB for <[e-mail]>; Tue, 22 Aug 2006 07:19:33 -0700 (PDT)
Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MEJWTp017354 for <[e-mail]>; Tue, 22 Aug 2006 15:19:32 +0100 (BST)
Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 22 Aug 2006 15:19:32 +0100 (BST)
Received: from vpn-129-150-116-103.UK.Sun.COM ([129.150.116.103]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005)) with ESMTPSA id <[e-mail]>; Tue, 22 Aug 2006 15:19:28 +0100 (BST)
Content-return: prohibited
Date: Tue, 22 Aug 2006 16:23:09 +0200
From: Arnaud Quillaud <[e-mail]>
Subject: RE: [Ietf-calsify] Section 4.6.4 Free/Busy Component: fbprop
In-reply-to: <[e-mail]>
Sender: [e-mail]
To: Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Outlook Connector 7.2.306.0
Content-type: TEXT/PLAIN; CHARSET=Windows-1252
Content-transfer-encoding: 7BIT
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 14:19:34 -0000

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Bernard
> Desruisseaux
> Sent: Tuesday, August 22, 2006 6:09 AM
> To: Calsify WG
> Subject: [Ietf-calsify] Section 4.6.4 Free/Busy Component: fbprop
> 
> 
> In section 4.6.4 Free/Busy Component of RFC 2445...
> 
> The rule fbprop specifies that DTSTAMP, and UID are
> OPTIONAL which is in contradiction with section 4.8.7.2
> Date/Time Stamp, and section 4.8.4.7 Unique Identifier
> which all specify that those two properties are REQUIRED
> in VFREEBUSY components.
> 

>From that same section 4.6.4, FREEBUSY components can be used for 3 purposes:
1) request for fb info
2) reply to a request for fb info
3) published fb info

I suspect that most existing applications (if not all) use fb components only for publishing and hence generate them withough any UID.
When publishing fb info what would be the meaning/usage of the UID ? It is not described in the spec.

All the examples in section 4.6.4 lack a UID.

Arnaud Q



> I propose to change the beginning of "todoprop" as follows:
> 
>  >  fbprop = *(
>  >
>  >         ; the following are both REQUIRED,
>  >         ; but MUST NOT occur more than once
>  >
>  >         dtstamp / uid /
>  >
>  >         ; the following are optional,
>  >         ; but MUST NOT occur more than once
>  >
>  >         ...
> 
> Cheers,
> Bernard
> 
> _______________________________________________
> 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 44B047FBD0 for <[e-mail]>; Tue, 22 Aug 2006 06:57:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 354B81422B6 for <[e-mail]>; Tue, 22 Aug 2006 06:57:09 -0700 (PDT)
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 07220-02 for <[e-mail]>; Tue, 22 Aug 2006 06:57:08 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9D3191422AB for <[e-mail]>; Tue, 22 Aug 2006 06:57:08 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MDv280001741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 09:57:04 -0400
Date: Tue, 22 Aug 2006 09:56:56 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.6.4 Free/Busy Component: fbprop
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 13:57:09 -0000

Hi Bernard,

--On August 22, 2006 12:08:44 AM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

> The rule fbprop specifies that DTSTAMP, and UID are
> OPTIONAL which is in contradiction with section 4.8.7.2
> Date/Time Stamp, and section 4.8.4.7 Unique Identifier
> which all specify that those two properties are REQUIRED
> in VFREEBUSY components.

+1 with similar changes as per VEVENT.


-- 
Cyrus Daboo



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 66C9F7FBCB for <[e-mail]>; Tue, 22 Aug 2006 06:56:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 572B21422B6 for <[e-mail]>; Tue, 22 Aug 2006 06:56:37 -0700 (PDT)
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 08777-04 for <[e-mail]>; Tue, 22 Aug 2006 06:56:37 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BC9561422AB for <[e-mail]>; Tue, 22 Aug 2006 06:56:36 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MDuUXn001728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 09:56:32 -0400
Date: Tue, 22 Aug 2006 09:56:25 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.6.3 Journal Component: jourprop
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 13:56:37 -0000

Hi Bernard,

--On August 22, 2006 12:08:41 AM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

> The rule jourprop specifies that DTSTAMP, and UID are
> OPTIONAL which is in contradiction with section 4.8.7.2
> Date/Time Stamp, and section 4.8.4.7 Unique Identifier
> which all specify that those two properties are REQUIRED
> in VJOURNAL components.

+1 with similar changes as per VEVENT.


-- 
Cyrus Daboo



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 9637A7FBC1 for <[e-mail]>; Tue, 22 Aug 2006 06:56:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 871961422B6 for <[e-mail]>; Tue, 22 Aug 2006 06:56:09 -0700 (PDT)
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 11283-07 for <[e-mail]>; Tue, 22 Aug 2006 06:56:09 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id ECBF61422AB for <[e-mail]>; Tue, 22 Aug 2006 06:56:08 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MDu1H3001714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 09:56:05 -0400
Date: Tue, 22 Aug 2006 09:55:56 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.6.2 To-do Component: todoprop
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 13:56:09 -0000

Hi Bernard,

--On August 22, 2006 12:08:38 AM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

> I propose to change the beginning of "todoprop" as follows:

+1 with similar changes as per VEVENT.

-- 
Cyrus Daboo



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 929C47FAEB for <[e-mail]>; Tue, 22 Aug 2006 06:55:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 832C91422AB for <[e-mail]>; Tue, 22 Aug 2006 06:55:20 -0700 (PDT)
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 27130-02 for <[e-mail]>; Tue, 22 Aug 2006 06:55:20 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DE8731422A7 for <[e-mail]>; Tue, 22 Aug 2006 06:55:19 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MDtDU0001699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 09:55:15 -0400
Date: Tue, 22 Aug 2006 09:55:08 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: eventprop
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 13:55:20 -0000

Hi Bernard,
+1 with minor corrections:

--On August 22, 2006 12:08:34 AM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

>  >  eventprop  = *(
>  >
>  >             ; the following are both REQUIRED,

                                     ^^^^ remove 'both'

>  >             ; but MUST NOT occur more than once
>  >
>  >             dtstamp / dtstart / uid /
>  >
>  >             ; the following are optional,

                                     ^^^^^^^^ capitalize to make it a 2119 
term

>  >             ; but MUST NOT occur more than once
>  >
>  >             ...

PS the optional -> OPTIONAL may be needed throughout the spec in similar 
cases.

-- 
Cyrus Daboo



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 A8EEF7F8B1 for <[e-mail]>; Tue, 22 Aug 2006 06:54:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9ADD71422AB for <[e-mail]>; Tue, 22 Aug 2006 06:54:53 -0700 (PDT)
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 08233-10 for <[e-mail]>; Tue, 22 Aug 2006 06:54:51 -0700 (PDT)
Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by laweleka.osafoundation.org (Postfix) with ESMTP id E91B01422A7 for <[e-mail]>; Tue, 22 Aug 2006 06:54:50 -0700 (PDT)
Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by cmsout02.mbox.net (Postfix) with ESMTP id E93134C9E1 for <[e-mail]>; Tue, 22 Aug 2006 13:54:49 +0000 (GMT)
Received: from cmsapps01.cms.usa.net [165.212.11.136] by cmsout02.mbox.net via smtad (C8.MAIN.3.27X); Tue, 22 Aug 2006 13:54:49 GMT
X-USANET-Source: 165.212.11.136 IN [e-mail] cmsapps01.cms.usa.net
X-USANET-MsgId: XID840kHVN3Y4197X02
Received: from cbryantlt2 [165.212.225.1] by cmsapps01.cms.usa.net (ASMTP/) via mtad (C8.MAIN.3.27X)  with ESMTP id 829kHVN3W0038M36; Tue, 22 Aug 2006 13:54:48 GMT
X-USANET-Auth: 165.212.225.1   AUTO [e-mail] cbryantlt2
Message-ID: <000c01c6c5f2$82dc48f0$[e-mail]>
From: "Chris Bryant" <[e-mail]>
To: "Calsify WG" <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Date: Tue, 22 Aug 2006 09:54:38 -0400
Organization: USA.NET
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Z-USANET-MsgId: XID829kHVN3W0038X36
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 13:54:53 -0000

What version of Outlook?  Outlook 2003 seems to encode properly in UTF-8 
from what I've looked at.

I agree that if we need to make an exception for 8859-1, then we need to 
allow any charset, but I don't think we should allow any charsets other than 
UTF-8 and US-ASCII.

Chris

----- Original Message ----- 
From: "Cyrus Daboo" <[e-mail]>


> Hi Mark,
>
> --On August 21, 2006 9:25:28 PM -0700 Mark Crispin 
> <[e-mail]> wrote:
>
>>> The result is that some iCalendar applications currently output
>>> iCalendar objects in ISO-8859-1.
>>
>> How many of these are there?  Is this widespread?
>
> Outlook - need I say more?
>
> -- 
> Cyrus Daboo




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 30F2E7FBB4 for <[e-mail]>; Tue, 22 Aug 2006 06:46:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A3EF1422B7 for <[e-mail]>; Tue, 22 Aug 2006 06:46:55 -0700 (PDT)
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 31444-10 for <[e-mail]>; Tue, 22 Aug 2006 06:46:54 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6AEEA1422B6 for <[e-mail]>; Tue, 22 Aug 2006 06:46:54 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MDkmQG001605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 09:46:50 -0400
Date: Tue, 22 Aug 2006 09:46:43 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: x-name
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 13:46:55 -0000

Hi Bernard,

--On August 21, 2006 11:37:49 PM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

>  > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
>  > ; Reserved for non-standard names. Can be used by bilateral
>  > ; agreement.

What does 'bilateral agreement' mean? iCalendar has no concept of content 
negotiation between different clients/servers so I think that is 
meaningless. Certainly I am not aware of anyone who checks to see whether 
X- items are acceptable to a receiving entity.

I also don't like the use of 'non-standard' here. In fact what I would like 
to see is vendors actually registering their properties so that 
implementations may choose to inter operate if they so desire. To allow 
that to work we need to setup the IANA registry to support vendor defined 
properties, and we need a way to register vendorid's (note that ACAP has 
already setup a vendor id registry that is also being used by some IMAP 
extensions so we could re-use that, though the syntax would need to be 
checked).

So I propose the following text instead:

 > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
 > ; Reserved for private names which may or may not be registered.

-- 
Cyrus Daboo



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 6464A7F96F for <[e-mail]>; Tue, 22 Aug 2006 06:37:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5529E1422A7 for <[e-mail]>; Tue, 22 Aug 2006 06:37:20 -0700 (PDT)
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 03762-03 for <[e-mail]>; Tue, 22 Aug 2006 06:37:20 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B45D91422A4 for <[e-mail]>; Tue, 22 Aug 2006 06:37:19 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MDbAkU001525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 09:37:13 -0400
Date: Tue, 22 Aug 2006 09:37:05 -0400
From: Cyrus Daboo <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255	octets
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 13:37:20 -0000

Hi Alexey,

--On August 22, 2006 11:36:14 AM +0100 Alexey Melnikov 
<[e-mail]> wrote:

>> In both sections I propose to change "255 characters" to "255 octets".
>
> Yes.
>
> Is this affected by ABNF for NON-US-ASCII? I.e. if we choose to define
> NON-US-ASCII as:
>      NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
>      ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629.
> then should we allow truncation at any octet?
>

Good point. As per line folding, I think what should be said is something 
like 'truncation can occur at 255 octets provided it does cause a 
multi-octet character to be split. If there is a multi-octet character at 
the 255 octet position, then truncation can occur at the next whole 
character below 255 octets'. Of course that could still result in some 
weirdness with combining characters etc

-- 
Cyrus Daboo



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 1D70C7FB80 for <[e-mail]>; Tue, 22 Aug 2006 06:31:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0F0011422B6 for <[e-mail]>; Tue, 22 Aug 2006 06:31:57 -0700 (PDT)
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 04688-07 for <[e-mail]>; Tue, 22 Aug 2006 06:31:55 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 511CD1422B5 for <[e-mail]>; Tue, 22 Aug 2006 06:31:55 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7MDVh26001479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 09:31:46 -0400
Date: Tue, 22 Aug 2006 09:31:38 -0400
From: Cyrus Daboo <[e-mail]>
To: Mark Crispin <[e-mail]>, Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 13:31:57 -0000

Hi Mark,

--On August 21, 2006 9:25:28 PM -0700 Mark Crispin <[e-mail]> 
wrote:

>> The result is that some iCalendar applications currently output
>> iCalendar objects in ISO-8859-1.
>
> How many of these are there?  Is this widespread?

Outlook - need I say more?

-- 
Cyrus Daboo



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 1AD997F977 for <[e-mail]>; Tue, 22 Aug 2006 05:08:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0D3761422B1 for <[e-mail]>; Tue, 22 Aug 2006 05:08:25 -0700 (PDT)
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 24176-03 for <[e-mail]>; Tue, 22 Aug 2006 05:08:23 -0700 (PDT)
Received: from natlemon.rzone.de (natlemon.rzone.de [81.169.145.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id 270A51422AA for <[e-mail]>; Tue, 22 Aug 2006 05:08:22 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-169-012.pools.arcor-ip.net [84.63.169.12]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7MC8KFg019767 for <[e-mail]>; Tue, 22 Aug 2006 14:08:21 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Tue, 22 Aug 2006 14:07:40 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 12:08:25 -0000

Am Montag, 21. August 2006 23:18 schrieb Mark Crispin:
> Another +1.
> If, on the other hand, we are referring to the UTF-8 representation of a
> composite character (that is, one composed of a base character and one or
> more combining characters), we need to back off or at least require
> precomposed forms.  

But those are IMHO _character_ sequences, aren't they?

Best Regards,

Oliver


-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 948317FB98 for <[e-mail]>; Tue, 22 Aug 2006 03:39:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8581C1422AF for <[e-mail]>; Tue, 22 Aug 2006 03:39:38 -0700 (PDT)
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 10428-10 for <[e-mail]>; Tue, 22 Aug 2006 03:39:38 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id BAB4C1422AE for <[e-mail]>; Tue, 22 Aug 2006 03:39:37 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 11:39:29 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 11:39:04 +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: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 10:39:38 -0000

Bernard Desruisseaux wrote:

> I propose to add the following statement in section 4.1 Content Lines:
>
>  A multi-octet character MUST NOT be split across lines.

+1.



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 725CD7FB60 for <[e-mail]>; Tue, 22 Aug 2006 03:36:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 639CA1422AF for <[e-mail]>; Tue, 22 Aug 2006 03:36:48 -0700 (PDT)
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 13164-04 for <[e-mail]>; Tue, 22 Aug 2006 03:36:48 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 981CC1422AE for <[e-mail]>; Tue, 22 Aug 2006 03:36:47 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 11:36:41 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 11:36:14 +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] Section 4.8.4.7 and 6: 255 characters versus 255 octets
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 10:36:48 -0000

Bernard Desruisseaux wrote:

> In section 4.8.4.7 Unique Identifier of RFC 2445 it says:
>
> > Implementations MUST be able to receive and persist values of at
> > least 255 characters for this property.
>
> And, in Section 6 Recommended Practices it also says:
>
> > 6. An implementation can truncate a "SUMMARY" property value to 255
> >    characters.
>
> In both sections I propose to change "255 characters" to "255 octets".

Yes.

Is this affected by ABNF for NON-US-ASCII? I.e. if we choose to define 
NON-US-ASCII as:
     NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
     ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629.
then should we allow truncation at any octet?




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 9B5027F8FA for <[e-mail]>; Tue, 22 Aug 2006 03:14:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C7CA1422A8 for <[e-mail]>; Tue, 22 Aug 2006 03:14:55 -0700 (PDT)
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 08868-05 for <[e-mail]>; Tue, 22 Aug 2006 03:14:55 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id BBFB2142294 for <[e-mail]>; Tue, 22 Aug 2006 03:14:54 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 11:14:50 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 11:14:24 +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
MIME-Version: 1.0
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.2.10 Language
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 10:14:55 -0000

Bernard Desruisseaux wrote:

> In section 4.2.10 Language of RFC 2445 it says:
>
> > Description: This parameter can be specified on properties with a
> > text value type. The parameter identifies the language of the text in
> > the property or property parameter value. The value of the "language"
> > property parameter is that defined in [RFC 1766].

BTW, RFC 1766 should be replaced with at least RFC 3066.
However LTRU WG was working on RFC 3066 replacement 
(draft-ietf-ltru-registry-14.txt), which is in RFC Editor's queue at the 
moment.



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 ED6F67FB48 for <[e-mail]>; Tue, 22 Aug 2006 03:04:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DEF231422AF for <[e-mail]>; Tue, 22 Aug 2006 03:04:54 -0700 (PDT)
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 05731-07 for <[e-mail]>; Tue, 22 Aug 2006 03:04:54 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id D8F9D1422AE for <[e-mail]>; Tue, 22 Aug 2006 03:04:53 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 11:04:45 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 11:04:18 +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: Mark Crispin <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 10:04:55 -0000

Mark Crispin wrote:

> On Mon, 21 Aug 2006, Bernard Desruisseaux wrote:
>
>> The result is that some iCalendar applications currently output
>> iCalendar objects in ISO-8859-1.
>
> How many of these are there?  Is this widespread?
>
>>    b.3) UTF-8, US-ASCII, and ISO-8859-1 only.
>> At this point I favor option (b.3).
>
> I strongly oppose any proposal that grants special status to ISO-8859-1.
>
> Leaving aside the fundamental wrongness of grantly clemency to lazy 
> European implementors without doing the same for lazy Russian, 
> Chinese, Japanese, Korean, etc. implementors, ISO-8859-1 (Latin-1) is 
> deprecated. As all of us should be well-aware of by now, the approved 
> ISO 8859 variant for use in the EU is ISO-8859-15 (Latin-9 a.k.a. 
> Latin-0).
>
> If ISO-8859-1 were to be exempted, even if just for legacy purposes, 
> sooner or later some ding-dong will complain about "ignorant 
> Americans" whose "broken" specifications "deny" Europe use of several 
> European characters and even the EU currency sign.  Clearly a 
> conspiracy by George Bush, the NRA, Wal-Mart, Coca-Cola, and the Walt 
> Disney company... ;-)
>
> We don't know that there aren't any lazy implementor out there that 
> have done an iCalendar application using KOI8-R, or GBK, or 
> ISO-2022-JP (more likely, Shift-JIS), or KSC.  If we take a firm stand 
> and say "iCalendar is Unicode only", we would have moral authority to 
> stand firm should such lazy implementors complain.  We'd lose it if we 
> had already made a special exception for ISO-8859-1.

I agree.

> We don't always avoid mistakes; but this is one we can definitely 
> recognize now and avoid.
>
> Thus, I believe that our choices are:
>  . prohibit all charsets other than UTF-8 and US-ASCII (and, to be
>    honest, I'd prefer to prohibit US-ASCII as well)
>  . allow any charset

I wouldn't go as far as prohibiting US-ASCII, but I agree otherwise.

> If ISO-8859-1 has truly reared its ugly head into calendar and can't 
> be exterminated, then I regrettably conclude that "allow any charset" 
> is the only viable alternative.




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 CB5017FB30 for <[e-mail]>; Tue, 22 Aug 2006 03:01:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BC8131422AF for <[e-mail]>; Tue, 22 Aug 2006 03:01:57 -0700 (PDT)
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 10428-02 for <[e-mail]>; Tue, 22 Aug 2006 03:01:57 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id E057E1422AE for <[e-mail]>; Tue, 22 Aug 2006 03:01:56 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 11:01:37 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 11:01:12 +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] Section 4.4: "Single iCalendar object" versus "Sequence of iCalendar objects"
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 10:01:57 -0000

Bernard Desruisseaux wrote:

> Section 4.4 iCalendar Object of RFC 2445 says:
>
> > The Calendaring and Scheduling Core Object is a collection of
> > calendaring and scheduling information. Typically, this information
> > will consist of a single iCalendar object. However, multiple
> > iCalendar objects can be sequentially grouped together. The first
> > line and last line of the iCalendar object MUST contain a pair of
> > iCalendar object delimiter strings. The syntax for an iCalendar
> > object is as follows:
> >
> >   icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
> >                icalbody
> >                "END" ":" "VCALENDAR" CRLF)
>
> I would like to modify this section to introduce the notion of an
> "iCalendar stream" to make it explicit when we are refering to a
> "single iCalendar object" or a "sequence of iCalendar objects".
>
> Proposed new text:
>
> > The Calendaring and Scheduling Core Object is a collection of
> > calendaring and scheduling information. Typically, this information
> > will consist of an iCalendar stream with a single iCalendar object.
> > However, multiple iCalendar objects can be sequentially grouped
> > together in an iCalendar stream. The first line and last line of
> > the iCalendar object MUST contain a pair of iCalendar object
> > delimiter strings. The syntax for an iCalendar stream is as follows:
> >
> >   icalstream = 1*icalobject
> >
> >   icalobject = "BEGIN" ":" "VCALENDAR" CRLF
> >                icalbody
> >                "END" ":" "VCALENDAR" CRLF

I like that.



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 A28047F86F for <[e-mail]>; Tue, 22 Aug 2006 02:58:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 948131422A9 for <[e-mail]>; Tue, 22 Aug 2006 02:58:22 -0700 (PDT)
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 30327-09 for <[e-mail]>; Tue, 22 Aug 2006 02:58:20 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE8131422A8 for <[e-mail]>; Tue, 22 Aug 2006 02:58:19 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 10:58:12 +0100
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 10:57:47 +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
MIME-Version: 1.0
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 09:58:22 -0000

Bernard Desruisseaux wrote:

> In section 3.2 Parameters of RFC 2445 it says:
>
> > If the iCalendar object contains more than one calendar component
> > type, then multiple component parameters MUST be specified.
>
> But the specification is silent as what should be done with the
> "method" parameter when the iCalendar object (or iCalendar stream)
> is a sequence of iCalendar objects.
>
> Old text:
>
> > The "method" parameter MUST be the same value as that
> > specified in the "METHOD" component property in the iCalendar object.
> > If one is present, the other MUST also be present.
>
> New text:
>
> > The "method" parameter MUST be specified only for iCalendar
> > stream that contains a single iCalendar object.

No, I think this is not correct. It is Ok to have multiple iCalendar 
objects in an iCalendar stream, as long as they all have the same METHOD 
property.
Otherwise miltipart/mixed containing several text/calendar has to be used.

> The "method"
> > parameter MUST be the same value as that specified in the "METHOD"
> > component property in the iCalendar object. If one is present,
> > the other MUST also be present.




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 E47D67F968 for <[e-mail]>; Tue, 22 Aug 2006 02:03:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D52C01422AB for <[e-mail]>; Tue, 22 Aug 2006 02:03:52 -0700 (PDT)
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 29310-08 for <[e-mail]>; Tue, 22 Aug 2006 02:03:51 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by laweleka.osafoundation.org (Postfix) with ESMTP id 618531422A9 for <[e-mail]>; Tue, 22 Aug 2006 02:03:51 -0700 (PDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 22 Aug 2006 02:03:41 -0700
X-IronPort-AV: i="4.08,154,1154934000";  d="scan'208"; a="441205274:sNHT27949263634"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7M93fH1004686; Tue, 22 Aug 2006 02:03:41 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7M93e1E021946; Tue, 22 Aug 2006 02:03:40 -0700 (PDT)
Received: from [144.254.23.123] (dhcp-data-vlan10-23-123.cisco.com [144.254.23.123]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7M8tAqW020764; Tue, 22 Aug 2006 01:55:11 -0700
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 11:03:38 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: Mark Crispin <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-2.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=715; t=1156237421; x=1157101421; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:Re=3A=20[Issue=201]=20Re=3A=20[Ietf-calsify]=20draft-ietf-calsify-rfc244 5bis-01.txt=0A=20/=20UTF-8; X=v=3Dcisco.com=3B=20h=3Dqs4WFqiA3SuSBZ6SqaWcxI8w4kk=3D; b=tqVmvSVNdgy603+4SPkeUG4eEyHuSIlmF4qUsjX0Qx1wHJH0vXxgs3kgYEEkPqvpFvyzwjpC 6FA1aCxFmcFiXMXRQwy6WZWIQXzVicJ+nYIitCs1LXvcaaiFLN250tf4;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.9 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 09:03:53 -0000

Mark,

> Another +1.
>
> However, before we do this, I want to make sure that we are referring
> to "characters" in the context of "Unicode codepoints"; and thus a
> "multi-octet character" refers to a maximal-length UTF-8
> representation of a Unicode character (4 octets).
>
> If, on the other hand, we are referring to the UTF-8 representation of
> a composite character (that is, one composed of a base character and
> one or more combining characters), we need to back off or at least
> require precomposed forms.  I've seen some decomposed forms that are
> quite lengthy.

Can you please propose the exact alternate text you would like?  This
will help move things along.

Thanks,

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 A3D237FB4A for <[e-mail]>; Mon, 21 Aug 2006 21:25:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 93A7114229F for <[e-mail]>; Mon, 21 Aug 2006 21:25:50 -0700 (PDT)
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 29175-07 for <[e-mail]>; Mon, 21 Aug 2006 21:25:49 -0700 (PDT)
Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C0D5014229C for <[e-mail]>; Mon, 21 Aug 2006 21:25:48 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7M4PZWx020200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Aug 2006 21:25:35 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7M4PSAf030036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Aug 2006 21:25:35 -0700
Date: Mon, 21 Aug 2006 21:25:28 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Sender: [e-mail]
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.21.210943
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 04:25:51 -0000

On Mon, 21 Aug 2006, Bernard Desruisseaux wrote:
> The result is that some iCalendar applications currently output
> iCalendar objects in ISO-8859-1.

How many of these are there?  Is this widespread?

>    b.3) UTF-8, US-ASCII, and ISO-8859-1 only.
> At this point I favor option (b.3).

I strongly oppose any proposal that grants special status to ISO-8859-1.

Leaving aside the fundamental wrongness of grantly clemency to lazy 
European implementors without doing the same for lazy Russian, Chinese, 
Japanese, Korean, etc. implementors, ISO-8859-1 (Latin-1) is deprecated. 
As all of us should be well-aware of by now, the approved ISO 8859 variant 
for use in the EU is ISO-8859-15 (Latin-9 a.k.a. Latin-0).

If ISO-8859-1 were to be exempted, even if just for legacy purposes, 
sooner or later some ding-dong will complain about "ignorant Americans" 
whose "broken" specifications "deny" Europe use of several European 
characters and even the EU currency sign.  Clearly a conspiracy by George 
Bush, the NRA, Wal-Mart, Coca-Cola, and the Walt Disney company... ;-)

We don't know that there aren't any lazy implementor out there that have 
done an iCalendar application using KOI8-R, or GBK, or ISO-2022-JP (more 
likely, Shift-JIS), or KSC.  If we take a firm stand and say "iCalendar is 
Unicode only", we would have moral authority to stand firm should such 
lazy implementors complain.  We'd lose it if we had already made a special 
exception for ISO-8859-1.

We don't always avoid mistakes; but this is one we can definitely 
recognize now and avoid.

Thus, I believe that our choices are:
  . prohibit all charsets other than UTF-8 and US-ASCII (and, to be
    honest, I'd prefer to prohibit US-ASCII as well)
  . allow any charset

If ISO-8859-1 has truly reared its ugly head into calendar and can't be 
exterminated, then I regrettably conclude that "allow any charset" is the 
only viable alternative.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.


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 758A57F892 for <[e-mail]>; Mon, 21 Aug 2006 21:08:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 66E0514225B for <[e-mail]>; Mon, 21 Aug 2006 21:08:47 -0700 (PDT)
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 09509-07 for <[e-mail]>; Mon, 21 Aug 2006 21:08:47 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EFA8A142271 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LI05Zq006198 for <[e-mail]>; Mon, 21 Aug 2006 23:08:46 -0500
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1765764101156219723; Mon, 21 Aug 2006 22:08:43 -0600
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 00:08:44 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.6.4 Free/Busy Component: fbprop
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 04:08:47 -0000

In section 4.6.4 Free/Busy Component of RFC 2445...

The rule fbprop specifies that DTSTAMP, and UID are
OPTIONAL which is in contradiction with section 4.8.7.2
Date/Time Stamp, and section 4.8.4.7 Unique Identifier
which all specify that those two properties are REQUIRED
in VFREEBUSY components.

I propose to change the beginning of "todoprop" as follows:

 >  fbprop = *(
 >
 >         ; the following are both REQUIRED,
 >         ; but MUST NOT occur more than once
 >
 >         dtstamp / uid /
 >
 >         ; the following are optional,
 >         ; but MUST NOT occur more than once
 >
 >         ...

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 861D07F858 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 779C314228E for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
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 22687-02 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0094A14225B for <[e-mail]>; Mon, 21 Aug 2006 21:08:45 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LI05Zo006198 for <[e-mail]>; Mon, 21 Aug 2006 23:08:45 -0500
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1765763991156219714; Mon, 21 Aug 2006 22:08:34 -0600
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 00:08:34 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.6.1 Event Component: eventprop
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 04:08:46 -0000

In section 4.6.1 Event Component of RFC 2445...

The rule eventprop specifies that DTSTAMP, DTSTART and UID
are OPTIONAL which is in contradiction with section 4.8.7.2
Date/Time Stamp, section 4.8.2.4 Date/Time Start, and section
4.8.4.7 Unique Identifier which all specify that those three
properties are REQUIRED in VEVENT components.

I propose to change the beginning of "eventprop" as follows:

 >  eventprop  = *(
 >
 >             ; the following are both REQUIRED,
 >             ; but MUST NOT occur more than once
 >
 >             dtstamp / dtstart / uid /
 >
 >             ; the following are optional,
 >             ; but MUST NOT occur more than once
 >
 >             ...

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 B5BBD7F858 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A5B6414225B for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
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 22463-03 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3E98E142271 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7LGwdIY006292 for <[e-mail]>; Mon, 21 Aug 2006 22:08:45 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1764619601156219717; Mon, 21 Aug 2006 22:08:37 -0600
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 00:08:38 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.6.2 To-do Component: todoprop
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 04:08:46 -0000

In section 4.6.2 To-do Component of RFC 2445...

The rule todoprop specifies that DTSTAMP, and UID are
OPTIONAL which is in contradiction with section 4.8.7.2
Date/Time Stamp, and section 4.8.4.7 Unique Identifier
which all specify that those two properties are REQUIRED
in VTODO components.

I propose to change the beginning of "todoprop" as follows:

 >  todoprop  = *(
 >
 >            ; the following are both REQUIRED,
 >            ; but MUST NOT occur more than once
 >
 >            dtstamp / uid /
 >
 >            ; the following are optional,
 >            ; but MUST NOT occur more than once
 >
 >            ...

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 EBFB37F858 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DD38514225B for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
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 28635-01 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F4AE142289 for <[e-mail]>; Mon, 21 Aug 2006 21:08:46 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7M48j8Z005775 for <[e-mail]>; Mon, 21 Aug 2006 22:08:45 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1765764091156219720; Mon, 21 Aug 2006 22:08:40 -0600
Message-ID: <[e-mail]>
Date: Tue, 22 Aug 2006 00:08:41 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Calsify WG <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.6.3 Journal Component: jourprop
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 04:08:47 -0000

In section 4.6.3 Journal Component of RFC 2445...

The rule jourprop specifies that DTSTAMP, and UID are
OPTIONAL which is in contradiction with section 4.8.7.2
Date/Time Stamp, and section 4.8.4.7 Unique Identifier
which all specify that those two properties are REQUIRED
in VJOURNAL components.

 >  jourprop = *(
 >
 >           ; the following are both REQUIRED,
 >           ; but MUST NOT occur more than once
 >
 >           dtstamp / uid /
 >
 >           ; the following are optional,
 >           ; but MUST NOT occur more than once
 >
 >            ...

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 5B20F7F5C1 for <[e-mail]>; Mon, 21 Aug 2006 20:50:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4B66A142266 for <[e-mail]>; Mon, 21 Aug 2006 20:50:34 -0700 (PDT)
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 26350-02 for <[e-mail]>; Mon, 21 Aug 2006 20:50:34 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EE073142257 for <[e-mail]>; Mon, 21 Aug 2006 20:50:33 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7LIbaJn019237 for <[e-mail]>; Mon, 21 Aug 2006 21:50:32 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1764615661156218536; Mon, 21 Aug 2006 21:48:56 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 23:48:57 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, UPPERCASE_25_50
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.1 Content Lines: NON-US-ASCII
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 03:50:34 -0000

In section 4.1 Content Lines of RFC 2445 it says:

 >     NON-US-ASCII       = %x80-F8
 >     ; Use restricted by charset parameter
 >     ; on outer MIME object (UTF-8 preferred)

Unless I'm mistaken, the characters %xF9 to %xFD are allowed in UTF-8.

At a minimum this should be:

 >     NON-US-ASCII       = %x80-FD
or
 >     NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
 >     ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629.

and if we agree to support ISO-8859-1, then it should be:

 >     NON-US-ASCII       = %x80-FF

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 A9FC17FB7C for <[e-mail]>; Mon, 21 Aug 2006 20:45:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9B73814229C for <[e-mail]>; Mon, 21 Aug 2006 20:45:33 -0700 (PDT)
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 04800-08 for <[e-mail]>; Mon, 21 Aug 2006 20:45:32 -0700 (PDT)
Received: from plumcanary.com (mail.plumcanary.com [216.154.222.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 112D4142266 for <[e-mail]>; Mon, 21 Aug 2006 20:45:32 -0700 (PDT)
Received: from [192.168.1.102] (c-24-63-84-148.hsd1.ma.comcast.net [24.63.84.148]) by plumcanary.com (8.12.11.20060308/8.12.11) with ESMTP id k7M3j0CU018942; Mon, 21 Aug 2006 23:45:01 -0400
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Jay Batson <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: x-name
Date: Mon, 21 Aug 2006 23:45:00 -0400
To: Bernard Desruisseaux <[e-mail]>
X-Mailer: Apple Mail (2.752.2)
Received-SPF: none (plumcanary.com: [e-mail] does not designate permitted sender hosts) receiver=plumcanary.com; client-ip=24.63.84.148; helo=[192.168.1.102]; envelope-from=[e-mail]; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf2-1.0.0; 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 03:45:33 -0000

On Aug 21, 2006, at 11:37 PM, Bernard Desruisseaux wrote:

> In section 4.1 Content Lines of RFC 2445 it says:
>
> > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
> > ; Reservered for experimental use. Not intended for use in
> > ; released products.
>
> The comment for x-name is in contradiction with the text in section
> 4.8.8.1 Non-standard Properties as well as the text in section 7.2
> Registration of New Properties.
>
> New text proposed:
>
> > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
> > ; Reserved for non-standard names. Can be used by bilateral
> > ; agreement.

+1

-------------
Jay Batson
[e-mail]
[phone] (w)
[phone] (m)




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 CED8A7FB86 for <[e-mail]>; Mon, 21 Aug 2006 20:38:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BF5261422A4 for <[e-mail]>; Mon, 21 Aug 2006 20:38:25 -0700 (PDT)
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 15000-02 for <[e-mail]>; Mon, 21 Aug 2006 20:38:25 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5670614229C for <[e-mail]>; Mon, 21 Aug 2006 20:38:25 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LJEUds002741 for <[e-mail]>; Mon, 21 Aug 2006 22:38:24 -0500
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1765734901156217869; Mon, 21 Aug 2006 21:37:49 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 23:37:49 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.1 Content Lines: x-name
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 03:38:26 -0000

In section 4.1 Content Lines of RFC 2445 it says:

 > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
 > ; Reservered for experimental use. Not intended for use in
 > ; released products.

The comment for x-name is in contradiction with the text in section
4.8.8.1 Non-standard Properties as well as the text in section 7.2
Registration of New Properties.

New text proposed:

 > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
 > ; Reserved for non-standard names. Can be used by bilateral
 > ; agreement.

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 1DB9E7FB80 for <[e-mail]>; Mon, 21 Aug 2006 20:32:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0FF25142296 for <[e-mail]>; Mon, 21 Aug 2006 20:32:23 -0700 (PDT)
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 23719-02 for <[e-mail]>; Mon, 21 Aug 2006 20:32:21 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 91CF514225C for <[e-mail]>; Mon, 21 Aug 2006 20:32:21 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7LH4bYV030952 for <[e-mail]>; Mon, 21 Aug 2006 21:32:20 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1765729271156217429; Mon, 21 Aug 2006 21:30:29 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 23:30:29 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.2.10 Language
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 03:32:23 -0000

In section 4.2.10 Language of RFC 2445 it says:

 > Description: This parameter can be specified on properties with a
 > text value type. The parameter identifies the language of the text in
 > the property or property parameter value. The value of the "language"
 > property parameter is that defined in [RFC 1766].

Yet, the ATTENDEE and ORGANIZER properties which have a CAL-ADDRESS
value type both allow the LANGUAGE parameter.

Proposed new text:

 > Description: The parameter identifies the language of the text in
 > the property or property parameter value. The value of the "language"
 > property parameter is that defined in [RFC 1766].

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 851D47FB73 for <[e-mail]>; Mon, 21 Aug 2006 20:06:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 76CEB142264 for <[e-mail]>; Mon, 21 Aug 2006 20:06:04 -0700 (PDT)
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 19858-04 for <[e-mail]>; Mon, 21 Aug 2006 20:06:04 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 11AE414225C for <[e-mail]>; Mon, 21 Aug 2006 20:06:04 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7LGwdI4006292 for <[e-mail]>; Mon, 21 Aug 2006 21:06:02 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1764608861156215962; Mon, 21 Aug 2006 21:06:02 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 23:06:01 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Subject: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 03:06:04 -0000

In section 3.2 Parameters of RFC 2445 it says:

 > If the iCalendar object contains more than one calendar component
 > type, then multiple component parameters MUST be specified.

But the specification is silent as what should be done with the
"method" parameter when the iCalendar object (or iCalendar stream)
is a sequence of iCalendar objects.

Old text:

 > The "method" parameter MUST be the same value as that
 > specified in the "METHOD" component property in the iCalendar object.
 > If one is present, the other MUST also be present.

New text:

 > The "method" parameter MUST be specified only for iCalendar
 > stream that contains a single iCalendar object. The "method"
 > parameter MUST be the same value as that specified in the "METHOD"
 > component property in the iCalendar object. If one is present,
 > the other MUST also be present.

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 DD2B67FB73 for <[e-mail]>; Mon, 21 Aug 2006 20:03:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CF8A91422A9 for <[e-mail]>; Mon, 21 Aug 2006 20:03:38 -0700 (PDT)
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 30630-08 for <[e-mail]>; Mon, 21 Aug 2006 20:03:38 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 24644142264 for <[e-mail]>; Mon, 21 Aug 2006 20:03:37 -0700 (PDT)
Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7M33WDo017855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Aug 2006 23:03:33 -0400
Date: Mon, 21 Aug 2006 23:03:32 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.4: "Single iCalendar object" versus "Sequence of iCalendar objects"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 03:03:39 -0000

Hi Bernard,

--On August 21, 2006 10:46:30 PM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

> Proposed new text:
>
>  > The Calendaring and Scheduling Core Object is a collection of
>  > calendaring and scheduling information. Typically, this information
>  > will consist of an iCalendar stream with a single iCalendar object.
>  > However, multiple iCalendar objects can be sequentially grouped
>  > together in an iCalendar stream. The first line and last line of
>  > the iCalendar object MUST contain a pair of iCalendar object
>  > delimiter strings. The syntax for an iCalendar stream is as follows:
>  >
>  >   icalstream = 1*icalobject
>  >
>  >   icalobject = "BEGIN" ":" "VCALENDAR" CRLF
>  >                icalbody
>  >                "END" ":" "VCALENDAR" CRLF

+1

I definitely like the idea of icalstream as a way of describing multiple 
BEGIN/END:VCALENDAR objects within one mime part etc. Whilst this does not 
appear too frequently in iCalendar data, 2445 does make reference to such 
things.

-- 
Cyrus Daboo



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 359BC7F70E for <[e-mail]>; Mon, 21 Aug 2006 20:02:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 27A171422A9 for <[e-mail]>; Mon, 21 Aug 2006 20:02:17 -0700 (PDT)
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 19356-03 for <[e-mail]>; Mon, 21 Aug 2006 20:02:15 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F524142264 for <[e-mail]>; Mon, 21 Aug 2006 20:02:15 -0700 (PDT)
Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7M31axH017827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Aug 2006 23:01:38 -0400
Date: Mon, 21 Aug 2006 23:01:37 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>, Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255	octets
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 03:02:17 -0000

Hi Bernard,

--On August 21, 2006 10:53:28 PM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

> In section 4.8.4.7 Unique Identifier of RFC 2445 it says:
>
>  > Implementations MUST be able to receive and persist values of at
>  > least 255 characters for this property.
>
> And, in Section 6 Recommended Practices it also says:
>
>  > 6. An implementation can truncate a "SUMMARY" property value to 255
>  >    characters.
>
> In both sections I propose to change "255 characters" to "255 octets".

+1

-- 
Cyrus Daboo



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 9682E7F994 for <[e-mail]>; Mon, 21 Aug 2006 19:53:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8784D1422A6 for <[e-mail]>; Mon, 21 Aug 2006 19:53:56 -0700 (PDT)
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 30320-10 for <[e-mail]>; Mon, 21 Aug 2006 19:53:56 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1974414229B for <[e-mail]>; Mon, 21 Aug 2006 19:53:56 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LHHBdq006367 for <[e-mail]>; Mon, 21 Aug 2006 21:53:54 -0500
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1765696461156215207; Mon, 21 Aug 2006 20:53:27 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 22:53:28 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255 octets
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 02:53:56 -0000

In section 4.8.4.7 Unique Identifier of RFC 2445 it says:

 > Implementations MUST be able to receive and persist values of at
 > least 255 characters for this property.

And, in Section 6 Recommended Practices it also says:

 > 6. An implementation can truncate a "SUMMARY" property value to 255
 >    characters.

In both sections I propose to change "255 characters" to "255 octets".

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 C0BA77F8C9 for <[e-mail]>; Mon, 21 Aug 2006 19:47:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B294A1422A4 for <[e-mail]>; Mon, 21 Aug 2006 19:47:52 -0700 (PDT)
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 17260-04 for <[e-mail]>; Mon, 21 Aug 2006 19:47:52 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 401C214229B for <[e-mail]>; Mon, 21 Aug 2006 19:47:52 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7M2lpdm016048 for <[e-mail]>; Mon, 21 Aug 2006 20:47:51 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1765691141156214789; Mon, 21 Aug 2006 20:46:29 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 22:46:30 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Calsify WG <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Subject: [Ietf-calsify] Section 4.4: "Single iCalendar object" versus "Sequence of iCalendar objects"
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 02:47:52 -0000

Section 4.4 iCalendar Object of RFC 2445 says:

 > The Calendaring and Scheduling Core Object is a collection of
 > calendaring and scheduling information. Typically, this information
 > will consist of a single iCalendar object. However, multiple
 > iCalendar objects can be sequentially grouped together. The first
 > line and last line of the iCalendar object MUST contain a pair of
 > iCalendar object delimiter strings. The syntax for an iCalendar
 > object is as follows:
 >
 >   icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
 >                icalbody
 >                "END" ":" "VCALENDAR" CRLF)

I would like to modify this section to introduce the notion of an
"iCalendar stream" to make it explicit when we are refering to a
"single iCalendar object" or a "sequence of iCalendar objects".

Proposed new text:

 > The Calendaring and Scheduling Core Object is a collection of
 > calendaring and scheduling information. Typically, this information
 > will consist of an iCalendar stream with a single iCalendar object.
 > However, multiple iCalendar objects can be sequentially grouped
 > together in an iCalendar stream. The first line and last line of
 > the iCalendar object MUST contain a pair of iCalendar object
 > delimiter strings. The syntax for an iCalendar stream is as follows:
 >
 >   icalstream = 1*icalobject
 >
 >   icalobject = "BEGIN" ":" "VCALENDAR" CRLF
 >                icalbody
 >                "END" ":" "VCALENDAR" CRLF

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 8DBD87F985 for <[e-mail]>; Mon, 21 Aug 2006 19:29:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E15F1422A4 for <[e-mail]>; Mon, 21 Aug 2006 19:29:43 -0700 (PDT)
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 11537-07 for <[e-mail]>; Mon, 21 Aug 2006 19:29:42 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DDA1814229B for <[e-mail]>; Mon, 21 Aug 2006 19:29:41 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7LMAcJb008943; Mon, 21 Aug 2006 20:29:39 -0600
Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-230.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1765673801156213682; Mon, 21 Aug 2006 20:28:02 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 22:28:00 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Mark Crispin <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 22 Aug 2006 02:29:43 -0000

Hi Mark,

I don't feel that it is important for new work to support any
character set other than UTF-8, but I'm not sure whether rfc2445bis
should be considered as new work though!

In my proposal I only quoted section 4.3.11 which makes clear that
UTF-8 and US-ASCII are the only character sets supported by iCalendar.
I should probably have quoted the other sections where character sets
are discussed, that is, sections 2.3, 3.2, and more importantly 4.1.4:

Section 4.1.4 Character Set

 > The "charset" Content-Type parameter can be used in MIME transports
 > to specify any other IANA registered character set.

Section 4.3.11 says that only UTF-8 and US-ASCII are supported.
While section 4.1.4 says that you can specify any IANA registered
character set in the "charset" parameter...

The result is that some iCalendar applications currently output
iCalendar objects in ISO-8859-1.

I see two options:

a) We modify section 4.3.11 as I proposed. But now I realize
    that we would also need to modify all the ABNF rules that
    makes reference to the numerical value of specific characters
    (e.g., LF = %x0A in US-ASCII but %x25 in EBCDIC). Yuk!

b) We modify sections 3.2, 4.1.4 and 4.3.11 to be in sync and
    clearly specify which character sets are supported by iCalendar:

     b.1) UTF-8 only.
     b.2) UTF-8 and US-ASCII only.
     b.3) UTF-8, US-ASCII, and ISO-8859-1 only.

At this point I favor option (b.3). It looks to me as the easiest
way to clarify the specification without breaking most (if not all)
existing iCalendar applications.

Cheers,
Bernard

Mark Crispin wrote:
> On Mon, 21 Aug 2006, Bernard Desruisseaux wrote:
>> I don't see any reason why it states that only UTF-8 and US-ASCII
>> are supported by this revision. Section "3.2 Parameter" doesn't
>> specify any restriction on the values allowed for the "charset"
>> parameter.
>> I propose to remove this statement from section 4.3.11.
> 
> Can you explain why you feel that it is important for new work to 
> support any character set other than UTF-8?  If any revision is made, it 
> should be to delete US-ASCII and make UTF-8 mandatory.
> 
> -- Mark --
> 
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.




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 5B6877FBA1 for <[e-mail]>; Mon, 21 Aug 2006 15:23:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4D391142296 for <[e-mail]>; Mon, 21 Aug 2006 15:23:21 -0700 (PDT)
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 07443-03 for <[e-mail]>; Mon, 21 Aug 2006 15:23:21 -0700 (PDT)
Received: from natblert.rzone.de (natblert.rzone.de [81.169.145.181]) by laweleka.osafoundation.org (Postfix) with ESMTP id 97C4E14228E for <[e-mail]>; Mon, 21 Aug 2006 15:23:20 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-163-176.pools.arcor-ip.net [84.63.163.176]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7LMNIJd019858 for <[e-mail]>; Tue, 22 Aug 2006 00:23:19 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Date: Tue, 22 Aug 2006 00:22:47 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 22:23:21 -0000

Am Dienstag, 22. August 2006 00:08 schrieb Oliver Block:
> It would be helpful at least to mention that the used character set must
> registered charsets (RFC2978).

Sorry for that English.

-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 124277FB99 for <[e-mail]>; Mon, 21 Aug 2006 15:08:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0338F142297 for <[e-mail]>; Mon, 21 Aug 2006 15:08:43 -0700 (PDT)
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 11014-03 for <[e-mail]>; Mon, 21 Aug 2006 15:08:41 -0700 (PDT)
Received: from natblert.rzone.de (natblert.rzone.de [81.169.145.181]) by laweleka.osafoundation.org (Postfix) with ESMTP id 190C9142294 for <[e-mail]>; Mon, 21 Aug 2006 15:08:40 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-163-176.pools.arcor-ip.net [84.63.163.176]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7LM8YIU029135 for <[e-mail]>; Tue, 22 Aug 2006 00:08:34 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Date: Tue, 22 Aug 2006 00:08:03 +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: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 22:08:43 -0000

Am Montag, 21. August 2006 20:38 schrieb Bernard Desruisseaux:
> In section "4.3.11 Text" of RFC 2445 it says:

3.3.11 of draft-ietf-calsify-rfc2445bis-01

>  > Formal Definition: The character sets supported by this revision of
>  > iCalendar are UTF-8 and US ASCII thereof. The applicability to other
>  > character sets is for future work. The value type is defined by the
>  > following notation.
>
> I propose to remove this statement from section 4.3.11.
>
> Proposed new text:
>  > Formal Definition: The value type is defined by the following notation.

<quote>
   The specification for any future subtypes of "text" must specify
   whether or not they will also utilize a "charset" parameter, and may
   possibly restrict its values as well.  For other subtypes of "text"
   than "text/plain", the semantics of the "charset" parameter should be
   defined to be identical to those specified here for "text/plain",
   i.e., the body consists entirely of characters in the given charset.
   In particular, definers of future "text" subtypes should pay close
   attention to the implications of multioctet character sets for their
   subtype definitions.
</quote>

That might have been the reason for the definition. It continues:

<quote>
   The charset parameter for subtypes of "text" gives a name of a
   character set, as "character set" is defined in RFC 2045.  The rules
   regarding line breaks detailed in the previous section must also be
   observed -- a character set whose definition does not conform to
   these rules cannot be used in a MIME "text" subtype.

   An initial list of predefined character set names can be found at the
   end of this section.  Additional character sets may be registered
   with IANA.
</quote>

(RFC2046, Section 4.1.2, p. 7,8)

It would be helpful at least to mention that the used character set must 
registered charsets (RFC2978).

Best Regards,

Oliver

-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 9C3A87F90D for <[e-mail]>; Mon, 21 Aug 2006 14:28:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E2D514228E for <[e-mail]>; Mon, 21 Aug 2006 14:28:19 -0700 (PDT)
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 00405-09 for <[e-mail]>; Mon, 21 Aug 2006 14:28:17 -0700 (PDT)
Received: from natlemon.rzone.de (natlemon.rzone.de [81.169.145.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id C151314228B for <[e-mail]>; Mon, 21 Aug 2006 14:28:16 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-163-176.pools.arcor-ip.net [84.63.163.176]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7LLSE6v007091 for <[e-mail]>; Mon, 21 Aug 2006 23:28:15 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Section 3.2: "charset" parameter
Date: Mon, 21 Aug 2006 23:27:41 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 21:28:19 -0000

Am Montag, 21. August 2006 20:34 schrieb Bernard Desruisseaux:
> In section "3.2 Parameters" of RFC 2445 it says:
>  > The "charset" parameter is defined in [RFC 2046] for other body
>  > parts. It is used to identify the default character set used within
>  > the body part.

9.1 in draft-ietf-calsify-rfc2445bis-01

> I have two comments:
>
> 1- The "charset" parameter is defined for all "text" _subtypes_
>     (and not "body parts").
>
> 2- Unlike vCalendar, iCalendar doesn't allow one to override
>     the character set used for an individual property value.
>     As such, I believe the text shouldn't talk about the
>     _default_ character set...

I would agree on both. 

Best Regards,

Oliver Block

-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 4F3EF7FB75 for <[e-mail]>; Mon, 21 Aug 2006 14:22:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4074E14229B for <[e-mail]>; Mon, 21 Aug 2006 14:22:57 -0700 (PDT)
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 02178-04 for <[e-mail]>; Mon, 21 Aug 2006 14:22:55 -0700 (PDT)
Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BC13E142256 for <[e-mail]>; Mon, 21 Aug 2006 14:22:55 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LLMqwo016745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Aug 2006 14:22:52 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LLMq1F018770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Aug 2006 14:22:52 -0700
Date: Mon, 21 Aug 2006 14:22:55 -0700 (Pacific Daylight Time)
From: Mark Crispin <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Networks & Distributed Computing
Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.21.140442
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 21:22:57 -0000

Well, then, which is more important; having calendar fall back to 
TEXT/PLAIN behavior (in which case you need CHARSET), or having calendar 
objects be required to be UTF-8?

Another thing that you could do is that TEXT/CALENDAR could require that 
;CHARSET=UTF-8 be present as a parameter.  Declare that a TEXT/CALENDAR 
which omits CHARSET, or has any charset other than UTF-8, is undefined and 
not to be interpreted according to the calendar specification.

By the way, all of these are to be treated as random ideas.  I'm not 
pushing for any of this as a solution, although I believe that it would be 
highly desirable to prevent any new application from getting into the 
multi-charset business.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


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 636EA7FB75 for <[e-mail]>; Mon, 21 Aug 2006 14:18:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 52E4014228E for <[e-mail]>; Mon, 21 Aug 2006 14:18:41 -0700 (PDT)
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 32704-06 for <[e-mail]>; Mon, 21 Aug 2006 14:18:38 -0700 (PDT)
Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CEAF2142256 for <[e-mail]>; Mon, 21 Aug 2006 14:18:38 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LLIZoX002871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Aug 2006 14:18:35 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LLIZc3017309 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Aug 2006 14:18:35 -0700
Date: Mon, 21 Aug 2006 14:18:39 -0700 (Pacific Daylight Time)
From: Mark Crispin <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Networks & Distributed Computing
Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.21.135943
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 21:18:41 -0000

Another +1.

However, before we do this, I want to make sure that we are referring to 
"characters" in the context of "Unicode codepoints"; and thus a 
"multi-octet character" refers to a maximal-length UTF-8 representation of 
a Unicode character (4 octets).

If, on the other hand, we are referring to the UTF-8 representation of a 
composite character (that is, one composed of a base character and one or 
more combining characters), we need to back off or at least require 
precomposed forms.  I've seen some decomposed forms that are quite 
lengthy.

On Mon, 21 Aug 2006, Cyrus Daboo wrote:
> --On August 21, 2006 2:28:17 PM -0400 Bernard Desruisseaux 
> <[e-mail]> wrote:
>> I propose to add the following statement in section 4.1 Content Lines:
>>   A multi-octet character MUST NOT be split across lines.
> +1

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


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 743FC7F928 for <[e-mail]>; Mon, 21 Aug 2006 13:52:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 661D114229B for <[e-mail]>; Mon, 21 Aug 2006 13:52:57 -0700 (PDT)
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 00960-02 for <[e-mail]>; Mon, 21 Aug 2006 13:52:57 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF811142250 for <[e-mail]>; Mon, 21 Aug 2006 13:52:55 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 21:52:38 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 21:52:12 +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: Mark Crispin <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
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="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 20:52:57 -0000

Mark Crispin wrote:

> On Mon, 21 Aug 2006, Alexey Melnikov wrote:
>
>> To clarify, the default charset=US-ASCII comes from MIME specs.
>> I am not sure if text/calendar can change the default character set 
>> used. Somebody with better MIME expertise should clarify this.
>
> If the message is not in email, then the specification can do whatever 
> it wants even if it inherits some syntax from MIME.
>
> Even if it is in email,

I think it is.

> I think that the CALENDAR subtype can define independent semantics 
> from TEXT/PLAIN.  Note that CHARSET is meaningless in TEXT/HTML.

The advantage of not assuming charset=utf-8 for text/calendar is that 
applications that don't recognize text/calendar can still do something 
meaningful with it (like displaying it to the user):
[from RFC 2046]

4.1.4.  Unrecognized Subtypes

   Unrecognized subtypes of "text" should be treated as subtype "plain"
   as long as the MIME implementation knows how to handle the charset.
   Unrecognized subtypes which also specify an unrecognized charset
   should be treated as "application/octet- stream".

> If you're really worried, then use APPLICATION/CALENDAR.




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 337277F928 for <[e-mail]>; Mon, 21 Aug 2006 13:47:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 256C014229B for <[e-mail]>; Mon, 21 Aug 2006 13:47:28 -0700 (PDT)
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 32332-05 for <[e-mail]>; Mon, 21 Aug 2006 13:47:26 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 055BF142250 for <[e-mail]>; Mon, 21 Aug 2006 13:47:26 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 21:47:21 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 21:46:58 +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: [e-mail]
Subject: Re: [Issue 1] Re: [Ietf-calsify]	draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 20:47:28 -0000

Cyrus Daboo wrote:

> Hi Bernard,
>
> --On August 21, 2006 2:28:17 PM -0400 Bernard Desruisseaux 
> <[e-mail]> wrote:
>
>> I propose to add the following statement in section 4.1 Content Lines:
>>
>>   A multi-octet character MUST NOT be split across lines.
>
> +1

+1




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 0DBA97F928 for <[e-mail]>; Mon, 21 Aug 2006 13:46:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F2F0C14229B for <[e-mail]>; Mon, 21 Aug 2006 13:45:59 -0700 (PDT)
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 32526-01 for <[e-mail]>; Mon, 21 Aug 2006 13:45:59 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 44604142250 for <[e-mail]>; Mon, 21 Aug 2006 13:45:59 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7LKjro3014707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 21 Aug 2006 16:45:57 -0400
Date: Mon, 21 Aug 2006 16:45:48 -0400
From: Cyrus Daboo <[e-mail]>
To: Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Section 3.2: "charset" parameter
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 20:46:00 -0000

Hi Bernard,

--On August 21, 2006 2:34:57 PM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

> New text proposed:
>
>  > The "charset" parameter is defined in [RFC 2046] for subtypes of
>  > the "text" media type. It is used to indicate the character set
>  > used in the body part.

+1

-- 
Cyrus Daboo



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 A73FA7F928 for <[e-mail]>; Mon, 21 Aug 2006 13:45:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 948FA14229B for <[e-mail]>; Mon, 21 Aug 2006 13:45:24 -0700 (PDT)
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 22670-09 for <[e-mail]>; Mon, 21 Aug 2006 13:45:23 -0700 (PDT)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B4F83142250 for <[e-mail]>; Mon, 21 Aug 2006 13:45:22 -0700 (PDT)
Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k7LKjFuQ014692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 21 Aug 2006 16:45:19 -0400
Date: Mon, 21 Aug 2006 16:45:10 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt	/ UTF-8
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 20:45:24 -0000

Hi Bernard,

--On August 21, 2006 2:28:17 PM -0400 Bernard Desruisseaux 
<[e-mail]> wrote:

> I propose to add the following statement in section 4.1 Content Lines:
>
>   A multi-octet character MUST NOT be split across lines.

+1

-- 
Cyrus Daboo



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 0384A7F9FE for <[e-mail]>; Mon, 21 Aug 2006 12:44:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E99381422AB for <[e-mail]>; Mon, 21 Aug 2006 12:44:01 -0700 (PDT)
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 22630-06 for <[e-mail]>; Mon, 21 Aug 2006 12:43:59 -0700 (PDT)
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 792191422A4 for <[e-mail]>; Mon, 21 Aug 2006 12:43:59 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LJhtJJ011085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Aug 2006 12:43:56 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LJhqDi017561 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Aug 2006 12:43:54 -0700
Date: Mon, 21 Aug 2006 12:43:51 -0700
From: Mark Crispin <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Networks & Distributed Computing
Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.21.122443
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 19:44:02 -0000

On Mon, 21 Aug 2006, Alexey Melnikov wrote:
> To clarify, the default charset=US-ASCII comes from MIME specs.
> I am not sure if text/calendar can change the default character set used. 
> Somebody with better MIME expertise should clarify this.

If the message is not in email, then the specification can do whatever it 
wants even if it inherits some syntax from MIME.

Even if it is in email, I think that the CALENDAR subtype can define 
independent semantics from TEXT/PLAIN.  Note that CHARSET is meaningless 
in TEXT/HTML.

If you're really worried, then use APPLICATION/CALENDAR.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


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 6B30A7FB4E for <[e-mail]>; Mon, 21 Aug 2006 12:12:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B7B41422A5 for <[e-mail]>; Mon, 21 Aug 2006 12:12:57 -0700 (PDT)
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 04772-09 for <[e-mail]>; Mon, 21 Aug 2006 12:12:57 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1000914229F for <[e-mail]>; Mon, 21 Aug 2006 12:12:53 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 20:12:34 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 20:12:16 +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] Section 3.2: "charset" parameter
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 19:12:57 -0000

Bernard Desruisseaux wrote:

> In section "3.2 Parameters" of RFC 2445 it says:
>
> > The "charset" parameter is defined in [RFC 2046] for other body
> > parts. It is used to identify the default character set used within
> > the body part.
>
> I have two comments:
>
> 1- The "charset" parameter is defined for all "text" _subtypes_
>    (and not "body parts").
>
> 2- Unlike vCalendar, iCalendar doesn't allow one to override
>    the character set used for an individual property value.
>    As such, I believe the text shouldn't talk about the
>    _default_ character set...
>
> New text proposed:
>
> > The "charset" parameter is defined in [RFC 2046] for subtypes of
> > the "text" media type. It is used to indicate the character set
> > used in the body part.

The new text looks good to me.



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 0F5917FB4E for <[e-mail]>; Mon, 21 Aug 2006 12:10:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 00FEA1422A4 for <[e-mail]>; Mon, 21 Aug 2006 12:10:39 -0700 (PDT)
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 11146-02 for <[e-mail]>; Mon, 21 Aug 2006 12:10:38 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id AF9D214229F for <[e-mail]>; Mon, 21 Aug 2006 12:10:37 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 20:10:31 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 20:10:12 +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: Calsify WG <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Mark Crispin <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 19:10:39 -0000

Mark Crispin wrote:

> On Mon, 21 Aug 2006, Alexey Melnikov wrote:
>
>>>   If any revision is made, it should be to delete US-ASCII and make 
>>> UTF-8 mandatory.
>>
>> However we can't do this, as absence of the charset parameter means 
>> US-ASCII.
>> So any iCalendar object in UTF-8 MUST have charset=utf-8.
>
> That's unfortunate.  I admit that I am not up to speed on this 
> specification; is there really no way to fix this problem?

To clarify, the default charset=US-ASCII comes from MIME specs.
I am not sure if text/calendar can change the default character set 
used. Somebody with better MIME expertise should clarify this.

> If there is some way of defining the charset as always being UTF-8, 
> then charset parameters can be removed from the specification as 
> extraneous.

Yes, that would be nice.

On a related note, according to my interpretation of MIME, the following 
text in draft-ietf-calsify-rfc2445bis-01 is not quite correct:

 >3.1.4.  Character Set
 >
 >   There is not a property parameter to declare the character set used
 >   in a property value.  The default character set for an iCalendar
 >   object is UTF-8 as defined in [RFC2279].
 >
 >   The "charset" Content-Type parameter can be used in MIME transports
 >   to specify any other IANA registered character set.

IMHO, charset is required for UTF-8 case.



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 AECA57F8EB for <[e-mail]>; Mon, 21 Aug 2006 11:55:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A04991422AD for <[e-mail]>; Mon, 21 Aug 2006 11:55:58 -0700 (PDT)
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 07159-10 for <[e-mail]>; Mon, 21 Aug 2006 11:55:55 -0700 (PDT)
Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 307D914229F for <[e-mail]>; Mon, 21 Aug 2006 11:55:55 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LItpQd020862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Aug 2006 11:55:51 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LItopJ001643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Aug 2006 11:55:51 -0700
Date: Mon, 21 Aug 2006 11:55:49 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Sender: [e-mail]
To: Alexey Melnikov <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.21.113943
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 18:55:58 -0000

On Mon, 21 Aug 2006, Alexey Melnikov wrote:
>>   If any revision is made, it should be to delete US-ASCII and make UTF-8 
>> mandatory.
> However we can't do this, as absence of the charset parameter means US-ASCII.
> So any iCalendar object in UTF-8 MUST have charset=utf-8.

That's unfortunate.  I admit that I am not up to speed on this 
specification; is there really no way to fix this problem?

If there is some way of defining the charset as always being UTF-8, then 
charset parameters can be removed from the specification as extraneous.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.


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 0CC0A7F89B for <[e-mail]>; Mon, 21 Aug 2006 11:51:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F34F31422A5 for <[e-mail]>; Mon, 21 Aug 2006 11:51:28 -0700 (PDT)
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 23162-10 for <[e-mail]>; Mon, 21 Aug 2006 11:51:25 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id E5F3614229F for <[e-mail]>; Mon, 21 Aug 2006 11:51:24 -0700 (PDT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 21 Aug 2006 19:51:11 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 19:50:53 +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: Mark Crispin <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 18:51:29 -0000

Mark Crispin wrote:

> On Mon, 21 Aug 2006, Bernard Desruisseaux wrote:
>
>> I don't see any reason why it states that only UTF-8 and US-ASCII
>> are supported by this revision. Section "3.2 Parameter" doesn't
>> specify any restriction on the values allowed for the "charset"
>> parameter.
>> I propose to remove this statement from section 4.3.11.
>
> Can you explain why you feel that it is important for new work to 
> support any character set other than UTF-8?

+1

>   If any revision is made, it should be to delete US-ASCII and make 
> UTF-8 mandatory.

However we can't do this, as absence of the charset parameter means 
US-ASCII.
So any iCalendar object in UTF-8 MUST have charset=utf-8.



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 DCE1D7F89B for <[e-mail]>; Mon, 21 Aug 2006 11:47:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CF63A1422A5 for <[e-mail]>; Mon, 21 Aug 2006 11:47:38 -0700 (PDT)
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 10485-06 for <[e-mail]>; Mon, 21 Aug 2006 11:47:35 -0700 (PDT)
Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 40F4214229F for <[e-mail]>; Mon, 21 Aug 2006 11:47:35 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LIlWlj025918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Aug 2006 11:47:33 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7LIlV5c030059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Aug 2006 11:47:32 -0700
Date: Mon, 21 Aug 2006 11:47:31 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Sender: [e-mail]
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.21.112943
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 18:47:39 -0000

On Mon, 21 Aug 2006, Bernard Desruisseaux wrote:
> I don't see any reason why it states that only UTF-8 and US-ASCII
> are supported by this revision. Section "3.2 Parameter" doesn't
> specify any restriction on the values allowed for the "charset"
> parameter.
> I propose to remove this statement from section 4.3.11.

Can you explain why you feel that it is important for new work to support 
any character set other than UTF-8?  If any revision is made, it should be 
to delete US-ASCII and make UTF-8 mandatory.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.


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 B2BED7F9EB for <[e-mail]>; Mon, 21 Aug 2006 11:39:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A52EE1422A9 for <[e-mail]>; Mon, 21 Aug 2006 11:39:46 -0700 (PDT)
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 04484-06 for <[e-mail]>; Mon, 21 Aug 2006 11:39:44 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 301261422A5 for <[e-mail]>; Mon, 21 Aug 2006 11:39:44 -0700 (PDT)
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LIdgGN009596 for <[e-mail]>; Mon, 21 Aug 2006 13:39:43 -0500
Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 1764102491156185504; Mon, 21 Aug 2006 12:38:24 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 14:38:05 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Calsify WG <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Subject: [Ietf-calsify] Character set restriction in section 4.3.11 Text
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 18:39:46 -0000

In section "4.3.11 Text" of RFC 2445 it says:

 > Formal Definition: The character sets supported by this revision of
 > iCalendar are UTF-8 and US ASCII thereof. The applicability to other
 > character sets is for future work. The value type is defined by the
 > following notation.

I don't see any reason why it states that only UTF-8 and US-ASCII
are supported by this revision. Section "3.2 Parameter" doesn't
specify any restriction on the values allowed for the "charset"
parameter.

I propose to remove this statement from section 4.3.11.

Proposed new text:

 > Formal Definition: The value type is defined by the following notation.

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 F03397F9EB for <[e-mail]>; Mon, 21 Aug 2006 11:35:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E12FC1422A9 for <[e-mail]>; Mon, 21 Aug 2006 11:35:33 -0700 (PDT)
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 27872-07 for <[e-mail]>; Mon, 21 Aug 2006 11:35:33 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 739BE1422A5 for <[e-mail]>; Mon, 21 Aug 2006 11:35:33 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LGW06E000501 for <[e-mail]>; Mon, 21 Aug 2006 13:35:32 -0500
Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 1764095341156185315; Mon, 21 Aug 2006 12:35:15 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 14:34:57 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Subject: [Ietf-calsify] Section 3.2: "charset" parameter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 18:35:34 -0000

In section "3.2 Parameters" of RFC 2445 it says:

 > The "charset" parameter is defined in [RFC 2046] for other body
 > parts. It is used to identify the default character set used within
 > the body part.

I have two comments:

1- The "charset" parameter is defined for all "text" _subtypes_
    (and not "body parts").

2- Unlike vCalendar, iCalendar doesn't allow one to override
    the character set used for an individual property value.
    As such, I believe the text shouldn't talk about the
    _default_ character set...

New text proposed:

 > The "charset" parameter is defined in [RFC 2046] for subtypes of
 > the "text" media type. It is used to indicate the character set
 > used in the body part.

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 6760A7F9E2 for <[e-mail]>; Mon, 21 Aug 2006 11:29:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 596421422AD for <[e-mail]>; Mon, 21 Aug 2006 11:29:30 -0700 (PDT)
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 28132-02 for <[e-mail]>; Mon, 21 Aug 2006 11:29:27 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B88741422A9 for <[e-mail]>; Mon, 21 Aug 2006 11:29:27 -0700 (PDT)
Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7LGPrJw023157 for <[e-mail]>; Mon, 21 Aug 2006 13:29:25 -0500
Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 1764079951156184915; Mon, 21 Aug 2006 12:28:35 -0600
Message-ID: <[e-mail]>
Date: Mon, 21 Aug 2006 14:28:17 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: [e-mail]
Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
References: <[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-Whitelist: TRUE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 21 Aug 2006 18:29:30 -0000

I propose to add the following statement in section 4.1 Content Lines:

  A multi-octet character MUST NOT be split across lines.

Old text:

 > Lines of text SHOULD NOT be longer than 75 octets, excluding the line
 > break. Long content lines SHOULD be split into a multiple line
 > representations using a line "folding" technique. That is, a long
 > line can be split between any two characters by inserting a CRLF
 > immediately followed by a single linear white space character (i.e.,
 > SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
 > of CRLF followed immediately by a single linear white space character
 > is ignored (i.e., removed) when processing the content type.

New text:

 > Lines of text SHOULD NOT be longer than 75 octets, excluding the line
 > break. Long content lines SHOULD be split into a multiple line
 > representations using a line "folding" technique. That is, a long
 > line can be split between any two characters by inserting a CRLF
 > immediately followed by a single linear white space character (i.e.,
 > SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9).  A multi-
 > octet character MUST NOT be split across lines.  Any sequence of
 > CRLF followed immediately by a single linear white space character
 > is ignored (i.e., removed) when processing the content type.

Cheers,
Bernard

Oliver Block wrote:
> Am Mittwoch, 16. August 2006 09:29 schrieben Sie:
>> On Tue, 15 Aug 2006, Oliver Block wrote:
>>> draft-ietf-calsify-rfc2445bis-01.txt specifies UTF-8 as default character
>>> set, and implies _valid_ UTF-8, of course. But for the mentioned problems
>>> on folding in that discussion it might be helpful to hint that folding
>>> within UTF-8 byte sequences produces _illegal_ byte sequences which are
>>> no longer UTF-8.
>> Sure, but rfc 2445 says that lines first have to be unfolded and then
>> interpreted as UTF-8.
> 
> Yes. My thought was if this point deserves to be emphasized a bit more. I 
> would agree that RFC2445 already requires valid UTF-8.
> 
> Best Regards,
> 
> Oliver
> 


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 07B177F96F for <[e-mail]>; Thu, 17 Aug 2006 11:15:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EE1331422C6 for <[e-mail]>; Thu, 17 Aug 2006 11:15:24 -0700 (PDT)
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 17295-10 for <[e-mail]>; Thu, 17 Aug 2006 11:15:24 -0700 (PDT)
Received: from fed1rmmtao11.cox.net (fed1rmmtao11.cox.net [68.230.241.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id E673E1422C2 for <[e-mail]>; Thu, 17 Aug 2006 11:15:23 -0700 (PDT)
Received: from [192.168.0.103] (really [70.191.49.25]) by fed1rmmtao11.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060817181521.ZBQI554.fed1rmmtao11.cox.net@[192.168.0.103]>; Thu, 17 Aug 2006 14:15:21 -0400
Message-ID: <[e-mail]>
Date: Thu, 17 Aug 2006 11:15:20 -0700
From: Dave Thewlis <[e-mail]>
Organization: The Calendaring and Scheduling Consortium
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: ietf-calsify list <[e-mail]>
Content-Type: multipart/alternative; boundary="------------040709000900060700030301"
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, HTML_30_40, HTML_MESSAGE
X-Spam-Level: 
Subject: [Ietf-calsify] Registration for CalConnect Roundtable VII and IOP testing event is open
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: 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, 17 Aug 2006 18:15:25 -0000

This is a multi-part message in MIME format.
--------------040709000900060700030301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Registration for Roundtable VII, and for the associated Interoperability 
Testing Event, is now open. The Roundtable and IOP tests will be held 
26-29 September, 2006, in Cupertino, California, hosted by Apple 
Computer. Please see Roundtable VII 
<http://www.calconnect.org/roundtable7.html> for more information. 
Registration for Roundtable VII is at Roundtable Registration 
<http://www.calconnect.org/roundtablereg.html>. Registration for the 
Interoperability Testing Event is at IOP Registration 
<http://www.calconnect.org/iopreg.html>.

Interoperability testing, open to non-members and members alike, will 
comprise multiple scenarios including CalDAV server and client testing, 
Min-IOP testing, and iCalendar, iTIP, iMIP interoperability testing. A 
special series of tests is planned for Extended Daylight Savings Time 
support, to go into effect in March of 2007. We are also planning IOP 
testing around the response to the Open Group's Federated Free/Busy 
Challenge. (See the TC FREEBUSY 
<http://www.calconnect.org/tc-freebusy.html> page for more information 
about this Challenge and CalConnect's involvement.

 In addition to the IOP testing on Wednesday morning, the Consortium 
plans to offer an expanded Federated Free/Busy Demo which will be open 
to the media and other interested parties (by prior arrangement as space 
will be limited).

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
[phone] (voice) · [phone] (mobile)
http://www.calconnect.org · [e-mail] 
<mailto:[e-mail]>

--------------040709000900060700030301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<p>Registration for Roundtable VII, and for the associated
Interoperability Testing Event, is now open. The Roundtable and IOP
tests will be held 26-29 September, 2006, in Cupertino, California,
hosted by Apple Computer. Please see <a
 href="http://www.calconnect.org/roundtable7.html">Roundtable VII</a>
for more information. Registration for Roundtable VII is at <a
 href="http://www.calconnect.org/roundtablereg.html">Roundtable
Registration</a>. Registration for the Interoperability Testing Event
is at <a href="http://www.calconnect.org/iopreg.html">IOP Registration</a>.</p>
<p>Interoperability testing, open to non-members and members
alike,&nbsp;will comprise multiple scenarios including CalDAV server and
client testing, Min-IOP testing, and iCalendar, iTIP, iMIP
interoperability testing. A special series of tests is planned for
Extended Daylight Savings Time support, to go into effect in March of
2007. We are also planning IOP testing around the response to the Open
Group's Federated Free/Busy Challenge. (See the <a
 href="http://www.calconnect.org/tc-freebusy.html">TC FREEBUSY</a> page
for more information about this Challenge and CalConnect's involvement.
</p>
<p>&nbsp;In addition to the IOP testing on Wednesday morning, the Consortium
plans to offer an expanded Federated Free/Busy Demo which will be open
to the media and other interested parties (by prior arrangement as
space will be limited). </p>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
[phone] (voice) &middot; [phone] (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[e-mail]">[e-mail]</a>
</div>
</body>
</html>

--------------040709000900060700030301--


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 965797F87A for <[e-mail]>; Wed, 16 Aug 2006 08:13:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 877E31422AA for <[e-mail]>; Wed, 16 Aug 2006 08:13:29 -0700 (PDT)
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 16401-05 for <[e-mail]>; Wed, 16 Aug 2006 08:13:25 -0700 (PDT)
Received: from natblert.rzone.de (natblert.rzone.de [81.169.145.181]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE22F14226E for <[e-mail]>; Wed, 16 Aug 2006 08:13:24 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-175-150.pools.arcor-ip.net [84.63.175.150]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7GFDCVX000822 for <[e-mail]>; Wed, 16 Aug 2006 17:13:13 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Wed, 16 Aug 2006 17:12:43 +0200
User-Agent: KMail/1.7.1
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 15:13:29 -0000

Am Mittwoch, 16. August 2006 09:29 schrieben Sie:
> On Tue, 15 Aug 2006, Oliver Block wrote:
> > draft-ietf-calsify-rfc2445bis-01.txt specifies UTF-8 as default character
> > set, and implies _valid_ UTF-8, of course. But for the mentioned problems
> > on folding in that discussion it might be helpful to hint that folding
> > within UTF-8 byte sequences produces _illegal_ byte sequences which are
> > no longer UTF-8.
>
> Sure, but rfc 2445 says that lines first have to be unfolded and then
> interpreted as UTF-8.

Yes. My thought was if this point deserves to be emphasized a bit more. I 
would agree that RFC2445 already requires valid UTF-8.

Best Regards,

Oliver

-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 3E0887F892 for <[e-mail]>; Wed, 16 Aug 2006 07:16:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F36B14229C for <[e-mail]>; Wed, 16 Aug 2006 07:16:07 -0700 (PDT)
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 31403-01 for <[e-mail]>; Wed, 16 Aug 2006 07:16:04 -0700 (PDT)
Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A9C47142278 for <[e-mail]>; Wed, 16 Aug 2006 07:16:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 0105B28DFFAB; Wed, 16 Aug 2006 08:16:05 -0600 (MDT)
Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23226-05; Wed, 16 Aug 2006 08:16:04 -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 EFEC6187F7; Wed, 16 Aug 2006 08:16:02 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 08:16:01 -0600
From: George Sexton <[e-mail]>
Organization: MH Software, Inc.
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Reinhold Kainhofer <[e-mail]>
Subject: Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
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-Virus-Scanned: amavisd-new at mhsoftware.com
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 14:16:07 -0000

I think the point is that until it's unfolded, it's not a valid UTF-8 
document which is also required by the spec.

Reinhold Kainhofer wrote:
> On Tue, 15 Aug 2006, Oliver Block wrote:
>> draft-ietf-calsify-rfc2445bis-01.txt specifies UTF-8 as default 
>> character set,
>> and implies _valid_ UTF-8, of course. But for the mentioned problems on
>> folding in that discussion it might be helpful to hint that folding 
>> within
>> UTF-8 byte sequences produces _illegal_ byte sequences which are no 
>> longer
>> UTF-8.
>
> Sure, but rfc 2445 says that lines first have to be unfolded and then 
> interpreted as UTF-8.
>
> Cheers,
> Reinhold
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

-- 
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 87C367F9F3 for <[e-mail]>; Wed, 16 Aug 2006 06:05:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 78E5214228E for <[e-mail]>; Wed, 16 Aug 2006 06:05:21 -0700 (PDT)
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 16401-04 for <[e-mail]>; Wed, 16 Aug 2006 06:05:19 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1DE56142272 for <[e-mail]>; Wed, 16 Aug 2006 06:05:19 -0700 (PDT)
Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 Aug 2006 06:05:18 -0700
X-IronPort-AV: i="4.08,132,1154934000";  d="scan'208"; a="311860265:sNHT30467192"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GD5GrT010818 for <[e-mail]>; Wed, 16 Aug 2006 06:05:16 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7GD5G6W022409 for <[e-mail]>; Wed, 16 Aug 2006 06:05:16 -0700 (PDT)
Received: from [212.254.247.5] (ams3-vpn-dhcp4157.cisco.com [10.61.80.60]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7GCv9eP027734 for <[e-mail]>; Wed, 16 Aug 2006 05:57:09 -0700
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 15:05:15 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-5.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=695; t=1155733516; x=1156597516; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:Issue=2029=3A=20DTSTART=20in=20VTODO=20/=20VJOURNAL; X=v=3Dcisco.com=3B=20h=3DrhltBJDhuALg6UyMU7GdpOh78e0=3D; b=HJN8C0NI6lkH4/NXiNvoz3eCGzbGkpLhggRcq781hj+XDgnFV79RhykqxIhbC3ZcpRlSNBd/ xD03fMtf9lM4qBn3kCbnbQBc0FRsPDmJ41kNU/NxxW52J9J58deId+Ra;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL
X-Spam-Level: 
Subject: [Ietf-calsify] Issue 29: DTSTART in VTODO / VJOURNAL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 13:05:21 -0000

   Is DTSTART required in VTODO and VJOURNAL components when the RRULE
   or EXRULE properties are defined in those components?  

   Cyrus floated another idea that in the case of VTODO, perhaps the
   recurrence could use the DUE property. Bernard suggested that perhaps 
   in the absence of DTSTART, it could default to DUE.

   Lisa pointed out that this needs more discussion beyond the room, because
   different apps behave differently.

   In the end, some agreement that it's enough to clarify that for
   recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even 
   if it's otherwise optional.

   AI: Go forward with above clarification, Bernard to add text.


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 3413C7F9E8 for <[e-mail]>; Wed, 16 Aug 2006 06:02:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 24E6214229A for <[e-mail]>; Wed, 16 Aug 2006 06:02:10 -0700 (PDT)
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 19813-08 for <[e-mail]>; Wed, 16 Aug 2006 06:02:09 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id DEC6D142272 for <[e-mail]>; Wed, 16 Aug 2006 06:02:09 -0700 (PDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Aug 2006 06:02:09 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GD292X002630 for <[e-mail]>; Wed, 16 Aug 2006 06:02:09 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7GD291E000787 for <[e-mail]>; Wed, 16 Aug 2006 06:02:09 -0700 (PDT)
Received: from [212.254.247.5] (ams3-vpn-dhcp4157.cisco.com [10.61.80.60]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7GCs2Lj027665 for <[e-mail]>; Wed, 16 Aug 2006 05:54:02 -0700
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 15:02:08 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=69; t=1155733329; x=1156597329; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:Issue=2028=3A=20In=204.8.5.4=20Is=20RDATE=20required=20even=20when=20the =20recurrence=20instance=0A=20is=20defined=20in=20a=20separate=20component; X=v=3Dcisco.com=3B=20h=3Djfn2Haon8d8gdxQqsDjcHhaSomw=3D; b=GRzVt3rdP3oEwxbZ00lTnbMFeNguqP2v8tlVUqGz0NA5jDSdpoAOCKMmCNiWwDtqxi+jAjHB EBniMqrKiL9FH3UrOwLaYi4Sq98DTUUBwv3FV42ECSnAZASpXrfu+Y6z;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL
X-Spam-Level: 
Subject: [Ietf-calsify] Issue 28: In 4.8.5.4 Is RDATE required even when the recurrence instance is defined in a separate component
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 13:02:10 -0000

Consensus that this can be relaxed.

AI: Bernard to propose text.


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 1FFAB7F9F0 for <[e-mail]>; Wed, 16 Aug 2006 05:59:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EE26514228E for <[e-mail]>; Wed, 16 Aug 2006 05:58:59 -0700 (PDT)
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 23090-03 for <[e-mail]>; Wed, 16 Aug 2006 05:58:58 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id A74A8142272 for <[e-mail]>; Wed, 16 Aug 2006 05:58:58 -0700 (PDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 16 Aug 2006 05:58:58 -0700
X-IronPort-AV: i="4.08,132,1154934000";  d="scan'208"; a="1847567309:sNHT29059432"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GCwwt2025045 for <[e-mail]>; Wed, 16 Aug 2006 05:58:58 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7GCwwQV010581 for <[e-mail]>; Wed, 16 Aug 2006 05:58:58 -0700 (PDT)
Received: from [212.254.247.5] (ams3-vpn-dhcp4157.cisco.com [10.61.80.60]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7GCopNH027575 for <[e-mail]>; Wed, 16 Aug 2006 05:50:51 -0700
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 14:58:56 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-2.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=566; t=1155733138; x=1156597138; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:Issue=2027=3A=20DURATION/DTEND; X=v=3Dcisco.com=3B=20h=3DT2tPd0+wMjLpuZFwa2J2fpDG1yQ=3D; b=trntiaS82Hi97NV4mxMQgCZaDWb7PpIlQv4eAIzuHL5Qm0iHg9Z7hRzAjOZDHfUvX4CEjXdu BYUyzy6YAADLm2W4hDl4CMdYqN1vYa9oHl87cc2UxX2rQ8QluZy41/3G;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL
X-Spam-Level: 
Subject: [Ietf-calsify] Issue 27: DURATION/DTEND
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 12:59:00 -0000

4.8.5.4 rrule: should clarify that it's not whether DTEND or
   DURATION were used in an object.  What matters is the duration fo
   the first occurrence instance.
   
   Cyrus points out that the core problem here is really when an instance 
   in the recurrence set coincides with a DST shift. Proposes that the
   draft should be left as-is, and a note added that implementations
   should inform the user if a DST shift will occur, and ask whether
   duration or end-time is important. Room seemed to agree on the approach.

AI: Cyrus to propose text


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 7B8A27F9E9 for <[e-mail]>; Wed, 16 Aug 2006 05:55:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6B6CA1422A4 for <[e-mail]>; Wed, 16 Aug 2006 05:55:15 -0700 (PDT)
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 19998-04 for <[e-mail]>; Wed, 16 Aug 2006 05:55:13 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2997514228E for <[e-mail]>; Wed, 16 Aug 2006 05:55:13 -0700 (PDT)
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Aug 2006 05:55:13 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GCtCCP015040 for <[e-mail]>; Wed, 16 Aug 2006 05:55:12 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7GCtCQV008679 for <[e-mail]>; Wed, 16 Aug 2006 05:55:12 -0700 (PDT)
Received: from [212.254.247.5] (ams3-vpn-dhcp4157.cisco.com [10.61.80.60]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7GCl5vM027503 for <[e-mail]>; Wed, 16 Aug 2006 05:47:06 -0700
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 14:55:11 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-3.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=74; t=1155732912; x=1156596912; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:Issue=2025=3A=20Is=20the=20first=20recurrence=20instance, =20defined=20by =20DTSTART,=20always=0A=20excluded=20by=20RRULE?; X=v=3Dcisco.com=3B=20h=3D5FBhm1lNGD/zwbccod82l5kH9aA=3D; b=qnki8pDR4F9TFQEdoQKvo3Bm2jE8YwvrsXRDO8HFH/c+k1hZVcyPjOpcYMOXMvdNTxaZIDch bDiQk/vlV6LisCbjWDqtzE+ElCBcfDpp58dxBvdwUhiTs4Id5PmIQRm5;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL
X-Spam-Level: 
Subject: [Ietf-calsify] Issue 25: Is the first recurrence instance, defined by DTSTART, always excluded by RRULE?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 12:55:15 -0000

AI: Cyrus to raise discussion on mailing list and propose text.

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 820D07F9E2 for <[e-mail]>; Wed, 16 Aug 2006 05:53:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 734FA14228E for <[e-mail]>; Wed, 16 Aug 2006 05:53:05 -0700 (PDT)
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 19805-04 for <[e-mail]>; Wed, 16 Aug 2006 05:53:03 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30036142272 for <[e-mail]>; Wed, 16 Aug 2006 05:53:03 -0700 (PDT)
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Aug 2006 05:53:03 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GCr2l3013216 for <[e-mail]>; Wed, 16 Aug 2006 05:53:02 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7GCr2Yp005528 for <[e-mail]>; Wed, 16 Aug 2006 05:53:02 -0700 (PDT)
Received: from [212.254.247.5] (ams3-vpn-dhcp4157.cisco.com [10.61.80.60]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7GCitee027455 for <[e-mail]>; Wed, 16 Aug 2006 05:44:56 -0700
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 14:53:01 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-3.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=154; t=1155732783; x=1156596783; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:Issue=2023=3A=20Contradiction=20between=20UNTIL=20BNF=20rule=20and=20tex t; X=v=3Dcisco.com=3B=20h=3DIb1pDF1EdfejIUBYR9i/oDCBBNY=3D; b=VIH/EzVWb+JKBSoKH5Hz0mfI7V9iJ5XvJVI7CrZoViKFQtJwJzZyhmtcCPEvfIsXq7ghAX5n TFnx9jN1gQ7/XiUtwXGnuo3hTxASXw8AXUG04xiQvKqTJ2a5T1MOo9pG;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL
X-Spam-Level: 
Subject: [Ietf-calsify] Issue 23: Contradiction between UNTIL BNF rule and text
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 12:53:05 -0000

   Room showing agreement that the draft should state that 
   the UNTIL value type MUST match DTSTART value type.

AI: Bernard to add text.

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 EA28A7F5B4 for <[e-mail]>; Wed, 16 Aug 2006 05:50:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D982D142272 for <[e-mail]>; Wed, 16 Aug 2006 05:50:31 -0700 (PDT)
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 00603-08 for <[e-mail]>; Wed, 16 Aug 2006 05:50:29 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8DA3D142271 for <[e-mail]>; Wed, 16 Aug 2006 05:50:29 -0700 (PDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Aug 2006 05:50:29 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GCoTWI025597 for <[e-mail]>; Wed, 16 Aug 2006 05:50:29 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7GCoTQV006124 for <[e-mail]>; Wed, 16 Aug 2006 05:50:29 -0700 (PDT)
Received: from [212.254.247.5] (ams3-vpn-dhcp4157.cisco.com [10.61.80.60]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7GCgLi5027382 for <[e-mail]>; Wed, 16 Aug 2006 05:42:22 -0700
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 14:50:27 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-4.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=142; t=1155732629; x=1156596629; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:BYHOUR, =20BYMINUTE, =20and=20BYSECOND=20recurrence=20rules=20where=20valu e=20type=0A=20is=20DATE; X=v=3Dcisco.com=3B=20h=3DPtkwDty+vpnQDEIR732WOmoZcf0=3D; b=Rkmz97/aO82NU0zBA/fSMjN/c9s2ojHSaGEZVhmPc156vPS6m8aDvsNfzRHXGMjBqx9af1hD Ufag4iPvCkP3dBaFjG6+nujs+2lzLUpQWnbnqmmV85a+t+eoDnrNhW0r;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL, UPPERCASE_25_50
X-Spam-Level: 
Subject: [Ietf-calsify] BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 12:50:32 -0000

Consensus to go with the proposal of "MUST NOT generate such stuff and
MUST ignore any VEVENTs containing this.

AI: Bernard to add text.


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 039BB7F94B for <[e-mail]>; Wed, 16 Aug 2006 05:46:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E8F5C142279 for <[e-mail]>; Wed, 16 Aug 2006 05:46:37 -0700 (PDT)
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 20508-06 for <[e-mail]>; Wed, 16 Aug 2006 05:46:36 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by laweleka.osafoundation.org (Postfix) with ESMTP id A9041142272 for <[e-mail]>; Wed, 16 Aug 2006 05:46:36 -0700 (PDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 16 Aug 2006 05:46:36 -0700
X-IronPort-AV: i="4.08,132,1154934000";  d="scan'208"; a="336550681:sNHT30985760"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7GCkaIm019837 for <[e-mail]>; Wed, 16 Aug 2006 05:46:36 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7GCka1E022462 for <[e-mail]>; Wed, 16 Aug 2006 05:46:36 -0700 (PDT)
Received: from [212.254.247.5] (ams3-vpn-dhcp4157.cisco.com [10.61.80.60]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7GCcTJf027289 for <[e-mail]>; Wed, 16 Aug 2006 05:38:29 -0700
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 14:46:34 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
DKIM-Signature: a=rsa-sha1; q=dns; l=116; t=1155732396; x=1156596396; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Eliot=20Lear=20<[e-mail]> |Subject:Issue=2024=3A=20=20need=20to=20clarify=20number=20of=20recurrence=20inst ances=20generated=0A=20by=20multiple=20RRULEs; X=v=3Dcisco.com=3B=20h=3DblAtxZZohGkdX/7LLy5KESs50y8=3D; b=R7Ko4OkTrYDkM3wvrCGpyAtXJH6Fmzj14qrvIFKhoUdArXOi3iTYYigm0jreRjAoWT+qELLA vWvPp9NUTb5Qm/Q9s4AZCUpiLmC34GYcye4wItycVHnRhrHkoH/r6oii;
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL
X-Spam-Level: 
Subject: [Ietf-calsify] Issue 24: need to clarify number of recurrence instances generated by multiple RRULEs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 12:46:38 -0000

This is from the IETF minutes.

AI: Clarifying text will be added.

Bernard, please specify new text.

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 7706A7F7D9 for <[e-mail]>; Wed, 16 Aug 2006 00:29:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6866E14228A for <[e-mail]>; Wed, 16 Aug 2006 00:29:52 -0700 (PDT)
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 29083-07 for <[e-mail]>; Wed, 16 Aug 2006 00:29:50 -0700 (PDT)
Received: from mailrelay1.tu-graz.ac.at (mailrelay.tu-graz.ac.at [129.27.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id ADCF1142289 for <[e-mail]>; Wed, 16 Aug 2006 00:29:49 -0700 (PDT)
Received: from gauss.math.tu-graz.ac.at ([e-mail] [129.27.148.22]) by mailrelay1.tu-graz.ac.at (8.13.7/8.13.7) with ESMTP id k7G7Tiiw002478; Wed, 16 Aug 2006 09:29:45 +0200 (CEST)
Received: from kainhofer (helo=localhost) by gauss.math.tu-graz.ac.at with local-esmtp (Exim 3.36 #1 (Debian)) id 1GDFqT-0003Aj-00; Wed, 16 Aug 2006 09:29:45 +0200
Date: Wed, 16 Aug 2006 09:29:45 +0200 (CEST)
From: Reinhold Kainhofer <[e-mail]>
X-X-Sender: [e-mail]
To: Oliver Block <[e-mail]>
Subject: Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: Reinhold Kainhofer <[e-mail]>
X-Scanned-By: MIMEDefang 2.56 on 129.27.10.18
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 16 Aug 2006 07:29:52 -0000

On Tue, 15 Aug 2006, Oliver Block wrote:
> draft-ietf-calsify-rfc2445bis-01.txt specifies UTF-8 as default character set,
> and implies _valid_ UTF-8, of course. But for the mentioned problems on
> folding in that discussion it might be helpful to hint that folding within
> UTF-8 byte sequences produces _illegal_ byte sequences which are no longer
> UTF-8.

Sure, but rfc 2445 says that lines first have to be unfolded and then 
interpreted as UTF-8.

Cheers,
Reinhold



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 D69147F909 for <[e-mail]>; Tue, 15 Aug 2006 05:55:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C8C331422A9 for <[e-mail]>; Tue, 15 Aug 2006 05:55:29 -0700 (PDT)
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 20815-02 for <[e-mail]>; Tue, 15 Aug 2006 05:55:27 -0700 (PDT)
Received: from natblert.rzone.de (natblert.rzone.de [81.169.145.181]) by laweleka.osafoundation.org (Postfix) with ESMTP id E946414229B for <[e-mail]>; Tue, 15 Aug 2006 05:55:26 -0700 (PDT)
Received: from ollie.block.home (dslb-084-063-167-035.pools.arcor-ip.net [84.63.167.35]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7FCtMCM016990 for <[e-mail]>; Tue, 15 Aug 2006 14:55:23 +0200 (MEST)
From: Oliver Block <[e-mail]>
To: [e-mail]
Date: Tue, 15 Aug 2006 14:54:50 +0200
User-Agent: KMail/1.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Subject: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 15 Aug 2006 12:55:30 -0000

Hello List,

maybe some of you do remember a "discussion" we had about UTF-8 and folding.

<quote>
3.1.4.  Character Set

   There is not a property parameter to declare the character set used
   in a property value.  The default character set for an iCalendar
   object is UTF-8 as defined in [RFC2279].
</quote src="draft-ietf-calsify-rfc2445bis-01.txt">

I'd like to call your attention to the following paragraph I recently read, 
which is taken from "The Unicode Standard 4.0" and available online.

<quote>
Utility programs are not prevented from operating on "mangled" text. For 
example, a UTF-8 file could have had a CRLF sequences introduced at every 80 
bytes by a bad mailer program. This could result in some UTF-8 byte sequence 
being interrupted by CRLFs, producing illegal byte sequences. This mangled 
text is no longer UTF-8. It is permissible for a conformant program to repair 
such text, recognizing that the mangled text was originally well-formed UTF-8 
byte sequences. However, such repair of mangled data is a special case, and 
it must be not be used in circumstances where it would cause security 
problems.
</quote src="The Unicode Standard 4.0, p. 61">

draft-ietf-calsify-rfc2445bis-01.txt specifies UTF-8 as default character set, 
and implies _valid_ UTF-8, of course. But for the mentioned problems on 
folding in that discussion it might be helpful to hint that folding within  
UTF-8 byte sequences produces _illegal_ byte sequences which are no longer 
UTF-8.

Best Regards,

Oliver Block

-- 
Leben ist mehr als schneller - weiter - höher
http://www.nak-nrw.de/p_6_4.html


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 1BAC57F7E1 for <[e-mail]>; Fri,  4 Aug 2006 00:24:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0C8F41422BB for <[e-mail]>; Fri,  4 Aug 2006 00:24:34 -0700 (PDT)
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 19483-10 for <[e-mail]>; Fri, 4 Aug 2006 00:24:33 -0700 (PDT)
Received: from mgw-ext12.nokia.com (mgw-ext12.nokia.com [131.228.20.171]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9CD701422BA for <[e-mail]>; Fri,  4 Aug 2006 00:24:32 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k747OT6J025004 for <[e-mail]>; Fri, 4 Aug 2006 10:24:30 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 4 Aug 2006 10:24:29 +0300
Received: from essapo-nirac253216.europe.nokia.com ([10.162.253.216]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);  Fri, 4 Aug 2006 10:24:29 +0300
From: Aki Niemi <[e-mail]>
To: Calsify <[e-mail]>
Content-Type: text/plain
Organization: Nokia-NRC/Helsinki
Date: Fri, 04 Aug 2006 10:24:21 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Aug 2006 07:24:29.0182 (UTC) FILETIME=[05CBB9E0:01C6B797]
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level: 
Subject: [Ietf-calsify] Double-checking IETF66 consensus
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 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, 04 Aug 2006 07:24:34 -0000

Folks,

There were a number of items in the IETF66 meeting where we were able to
get consensus among the people in the room (and those participating via
chat and/or audio feed).

However, since physical meetings are not official decision-making, that
consensus needs to be double-checked here on the list. This list is
anyway the primary arena for this work.

Take a look at the issues below, and if you *strongly* disagree with any
of them, send a note. I say strongly, since rough consensus is all we
really need; if you can live with it, great. :)

Cheers,
Aki


RFC 2445 issues:
----------------

Issue#1:

The first issue is about disallowing BYHOUR, BYMINUTE and BYSECOND
recurrence rules when the value type is DATE. There was consensus during
the meeting to disallow generating such rules (MUST NOT), and to ignore
any VEVENT containing such a construct.

Issue #2:

The second issue is with recurrence rules and the UNTIL rule. There was
consensus to mandating that the UNTIL value type MUST always match the
DTSTART value type.

Issue #3:

The third issue is with the end-time of an recurring event instance that
happens to coincide with a DST shift. Proposal is to leave the draft
as-is, but add a note instructing implementations to add some sort of
user indication when such a case is about to happen, namely, choice
should be given to the user whether to keep the duration or the end-time
fixed.

Issue #4:

Is the 1st recurrence instance, defined by DTSTART, always excluded by
EXRULE? There was consensus that the 1st recurrence instance defined by
DTSTART should not be excluded by EXRULE. If the EXRULE property
contains a COUNT rule part, the value specified in DTSTART should not be
considered as part of the count.

Issue #5:

Should clarify whether RDATE is REQUIRED even when the recurrence
instance is redefined in a separate component. There was consensus that
we should relax this MUST requirement, such that if an exception
component is defined to reschedule a specific recurrence instance, the
master component doesn't need to define an RDATE for this instance as
well. We should also specify that the duration of the instance defined
in the exception component has precedence over the duration specified in
the RDATE property.

Issue #6:

Clarify whether DTSTART is required in VTODO and VJOURNAL components
when the RRULE or EXRULE properties are defined in those components.
Consensus to mandate that DTSTART be REQUIRED when the RRULE or EXRULE
properties are defined in those components.

RFC2446-issues:
---------------

Issue #1:

Conflict between 2445bis and 2446bis regarding whether multiple
recurrence-IDs can be sent in a CANCEL. Consensus to remove the option
allowing multiple recurrence-IDs to be sent.

-- 
Aki Niemi
Nokia Research Center