Subject: [Ietf-calsify] rfc 2445 - typo correction(s)

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Tue Aug 29 10:33:04 2006

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

Date: Tue, 29 Aug 2006 13:32:01 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Andrew N Dowden <[email-masked]>
Subject: Re: [Ietf-calsify] rfc 2445 - typo correction(s)
Cc: ietf-calsify <[email-masked]>

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

Date: Sat, 26 Aug 2006 08:33:01 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>, Bernard Desruisseaux <[email-masked]>
Subject: [Ietf-calsify] [Fwd: Issue 37 - minor typo/grammatical error]

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"

From: "Tim Hare" <[email-masked]>
To: "'Eliot Lear'" <[email-masked]>
Subject: Issue 37 - minor typo/grammatical error
Date: Thu, 24 Aug 2006 21:04:52 -0400

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

Date: Fri, 25 Aug 2006 07:11:14 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.4: "Single iCalendar object"	versus"Sequence of iCalendar objects"
Cc: 'Calsify WG' <[email-masked]>

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: [email-masked]
> [mailto:[email-masked]] 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
> <[email-masked]> 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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Thu, 24 Aug 2006 16:51:32 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
Cc: Calsify WG <[email-masked]>

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?

Date: Thu, 24 Aug 2006 16:16:09 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] current summary of issues

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

Date: Thu, 24 Aug 2006 13:12:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

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.

From: "Tim Hare" <[email-masked]>
To: "'Calsify WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.1 Content Lines: x-name
Date: Wed, 23 Aug 2006 21:39:52 -0400

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: [email-masked]
[mailto:[email-masked]] 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
<[email-masked]> 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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: "Tim Hare" <[email-masked]>
To: "'Calsify WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.4: "Single iCalendar object" versus"Sequence of iCalendar objects"
Date: Wed, 23 Aug 2006 21:27:11 -0400

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: [email-masked]
[mailto:[email-masked]] 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
<[email-masked]> 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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.1 Content Lines: x-name
Date: Wed, 23 Aug 2006 21:21:54 -0400

Bilateral agreement between which two parties? 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 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
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Wed, 23 Aug 2006 12:50:38 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] RFC 2445: Updated references

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

Date: Wed, 23 Aug 2006 11:14:19 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Bill McQuillan <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt	/ UTF-8
Cc: Calsify List <[email-masked]>

Hi Bernard,

--On August 23, 2006 11:06:13 AM -0400 Bernard Desruisseaux 
<[email-masked]> 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

Date: Wed, 23 Aug 2006 11:06:13 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Bill McQuillan <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: Calsify List <[email-masked]>

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

From: Oliver Block <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Wed, 23 Aug 2006 13:45:51 +0200
Cc: Mark Crispin <[email-masked]>, [email-masked]

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

Date: Wed, 23 Aug 2006 01:59:02 -0700
From: Bill McQuillan <[email-masked]>
To: Calsify List <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8

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 <[email-masked]>

Date: Tue, 22 Aug 2006 22:13:34 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: [email-masked]

[
   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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Tue, 22 Aug 2006 21:16:52 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: NON-US-ASCII

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Tue, 22 Aug 2006 16:27:58 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: [email-masked]

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.

From: Oliver Block <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Wed, 23 Aug 2006 00:48:46 +0200
Cc: [email-masked]

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

Date: Tue, 22 Aug 2006 16:20:22 -0400
From: Cyrus Daboo <[email-masked]>
To: Robert Ransdell <[email-masked]>, Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of	iCalendar objects
Cc: Calsify WG <[email-masked]>

Hi Robert,

--On August 22, 2006 4:03:50 PM -0400 Robert Ransdell 
<[email-masked]> 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

To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
Date: Tue, 22 Aug 2006 16:03:50 -0400
From: "Robert Ransdell" <[email-masked]>
Cc: Calsify WG <[email-masked]>, [email-masked]

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 <[email-masked]> 
Sent by: [email-masked]
08/22/2006 04:00 PM

To
Alexey Melnikov <[email-masked]>
cc
Calsify WG <[email-masked]>
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
[email-masked]
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;[email-masked]&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</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;[email-masked]&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;[email-masked]&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>
[email-masked]<br>
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify<br>
</font></tt>
<br>
--=_alternative 006DE4A1852571D2_=--

Date: Tue, 22 Aug 2006 15:57:41 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
Cc: Calsify WG <[email-masked]>

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

Date: Tue, 22 Aug 2006 12:32:53 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: [email-masked]

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.

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Tue, 22 Aug 2006 21:04:25 +0200

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

Date: Tue, 22 Aug 2006 11:56:18 -0700
From: Mark Crispin <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: [email-masked]

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.

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Tue, 22 Aug 2006 20:50:39 +0200

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

Date: Tue, 22 Aug 2006 11:00:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: [email-masked]

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.

Date: Tue, 22 Aug 2006 10:44:42 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255	octets

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

Date: Tue, 22 Aug 2006 12:08:04 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Eliot Lear <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt	/ UTF-8
Cc: [email-masked]

Hi Mark,

--On August 22, 2006 8:52:03 AM -0700 Mark Crispin <[email-masked]> 
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

Date: Tue, 22 Aug 2006 08:52:03 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Eliot Lear <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: [email-masked]

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.

Date: Tue, 22 Aug 2006 08:09:00 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Oliver Block <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: [email-masked]

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.

Date: Tue, 22 Aug 2006 10:39:01 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.6.4 Free/Busy Component: fbprop

Hi Arnaud,

--On August 22, 2006 4:23:09 PM +0200 Arnaud Quillaud 
<[email-masked]> 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

Content-return: prohibited
Date: Tue, 22 Aug 2006 16:23:09 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.6.4 Free/Busy Component: fbprop
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

Date: Tue, 22 Aug 2006 09:56:56 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.4 Free/Busy Component: fbprop

Hi Bernard,

--On August 22, 2006 12:08:44 AM -0400 Bernard Desruisseaux 
<[email-masked]> 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

Date: Tue, 22 Aug 2006 09:56:25 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.3 Journal Component: jourprop

Hi Bernard,

--On August 22, 2006 12:08:41 AM -0400 Bernard Desruisseaux 
<[email-masked]> 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

Date: Tue, 22 Aug 2006 09:55:56 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.2 To-do Component: todoprop

Hi Bernard,

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

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

+1 with similar changes as per VEVENT.

-- 
Cyrus Daboo

Date: Tue, 22 Aug 2006 09:55:08 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: eventprop

Hi Bernard,
+1 with minor corrections:

--On August 22, 2006 12:08:34 AM -0400 Bernard Desruisseaux 
<[email-masked]> 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

From: "Chris Bryant" <[email-masked]>
To: "Calsify WG" <[email-masked]>
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
Z-USANET-MsgId: XID829kHVN3W0038X36

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" <[email-masked]>

> Hi Mark,
>
> --On August 21, 2006 9:25:28 PM -0700 Mark Crispin 
> <[email-masked]> 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

Date: Tue, 22 Aug 2006 09:46:43 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: x-name

Hi Bernard,

--On August 21, 2006 11:37:49 PM -0400 Bernard Desruisseaux 
<[email-masked]> 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

Date: Tue, 22 Aug 2006 09:37:05 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255	octets
Cc: Calsify WG <[email-masked]>

Hi Alexey,

--On August 22, 2006 11:36:14 AM +0100 Alexey Melnikov 
<[email-masked]> 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

Date: Tue, 22 Aug 2006 09:31:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

Hi Mark,

--On August 21, 2006 9:25:28 PM -0700 Mark Crispin <[email-masked]> 
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

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Tue, 22 Aug 2006 14:07:40 +0200

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

Date: Tue, 22 Aug 2006 11:39:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: [email-masked]

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.

Date: Tue, 22 Aug 2006 11:36:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255 octets
Cc: Calsify WG <[email-masked]>

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?

Date: Tue, 22 Aug 2006 11:14:24 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.2.10 Language
Cc: Calsify WG <[email-masked]>

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.

Date: Tue, 22 Aug 2006 11:04:18 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

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.

Date: Tue, 22 Aug 2006 11:01:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.4: "Single iCalendar object" versus "Sequence of iCalendar objects"
Cc: Calsify WG <[email-masked]>

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.

Date: Tue, 22 Aug 2006 10:57:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
Cc: Calsify WG <[email-masked]>

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.

Date: Tue, 22 Aug 2006 11:03:38 +0200
From: Eliot Lear <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: [email-masked]

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

Date: Mon, 21 Aug 2006 21:25:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

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.

Date: Tue, 22 Aug 2006 00:08:44 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
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.

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

Date: Tue, 22 Aug 2006 00:08:34 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.1 Event Component: eventprop

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

Date: Tue, 22 Aug 2006 00:08:38 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.2 To-do Component: todoprop

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

Date: Tue, 22 Aug 2006 00:08:41 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.3 Journal Component: jourprop

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

Date: Mon, 21 Aug 2006 23:48:57 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.1 Content Lines: NON-US-ASCII

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

From: Jay Batson <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: x-name
Date: Mon, 21 Aug 2006 23:45:00 -0400
To: Bernard Desruisseaux <[email-masked]>
Cc: Calsify WG <[email-masked]>

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
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

Date: Mon, 21 Aug 2006 23:37:49 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.1 Content Lines: x-name

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

Date: Mon, 21 Aug 2006 23:30:29 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.2.10 Language

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

Date: Mon, 21 Aug 2006 23:06:01 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects

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

Date: Mon, 21 Aug 2006 23:03:32 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
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 
<[email-masked]> 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

Date: Mon, 21 Aug 2006 23:01:37 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255	octets

Hi Bernard,

--On August 21, 2006 10:53:28 PM -0400 Bernard Desruisseaux 
<[email-masked]> 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

Date: Mon, 21 Aug 2006 22:53:28 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255 octets

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

Date: Mon, 21 Aug 2006 22:46:30 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.4: "Single iCalendar object" versus "Sequence of iCalendar objects"

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

Date: Mon, 21 Aug 2006 22:28:00 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

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.

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Date: Tue, 22 Aug 2006 00:22:47 +0200

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

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Date: Tue, 22 Aug 2006 00:08:03 +0200

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

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 3.2: "charset" parameter
Date: Mon, 21 Aug 2006 23:27:41 +0200

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

Date: Mon, 21 Aug 2006 14:22:55 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: Calsify WG <[email-masked]>

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.

Date: Mon, 21 Aug 2006 14:18:39 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: [email-masked]

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 
> <[email-masked]> 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.

Date: Mon, 21 Aug 2006 21:52:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

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.

Date: Mon, 21 Aug 2006 21:46:58 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 1] Re: [Ietf-calsify]	draft-ietf-calsify-rfc2445bis-01.txt / UTF-8

Cyrus Daboo wrote:

> Hi Bernard,
>
> --On August 21, 2006 2:28:17 PM -0400 Bernard Desruisseaux 
> <[email-masked]> 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

Date: Mon, 21 Aug 2006 16:45:48 -0400
From: Cyrus Daboo <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "charset" parameter

Hi Bernard,

--On August 21, 2006 2:34:57 PM -0400 Bernard Desruisseaux 
<[email-masked]> 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

Date: Mon, 21 Aug 2006 16:45:10 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt	/ UTF-8

Hi Bernard,

--On August 21, 2006 2:28:17 PM -0400 Bernard Desruisseaux 
<[email-masked]> 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

Date: Mon, 21 Aug 2006 12:43:51 -0700
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: Calsify WG <[email-masked]>

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.

Date: Mon, 21 Aug 2006 20:12:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "charset" parameter
Cc: Calsify WG <[email-masked]>

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.

Date: Mon, 21 Aug 2006 20:10:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Mark Crispin <[email-masked]>

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.

Date: Mon, 21 Aug 2006 11:55:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

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.

Date: Mon, 21 Aug 2006 19:50:53 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

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.

Date: Mon, 21 Aug 2006 11:47:31 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

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.

Date: Mon, 21 Aug 2006 14:38:05 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Character set restriction in section 4.3.11 Text

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

Date: Mon, 21 Aug 2006 14:34:57 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 3.2: "charset" parameter

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

Date: Mon, 21 Aug 2006 14:28:17 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8

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
> 

Date: Thu, 17 Aug 2006 11:15:20 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Registration for CalConnect Roundtable VII and IOP testing event is open
Reply-To: [email-masked]

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*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

--------------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>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

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

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Wed, 16 Aug 2006 17:12:43 +0200

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

Date: Wed, 16 Aug 2006 08:16:01 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: [email-masked]

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

-- 
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/

Date: Wed, 16 Aug 2006 15:05:15 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 29: DTSTART 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, Bernard to add text.

Date: Wed, 16 Aug 2006 15:02:08 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 28: In 4.8.5.4 Is RDATE required even when the recurrence instance is defined in a separate component

Consensus that this can be relaxed.

AI: Bernard to propose text.

Date: Wed, 16 Aug 2006 14:58:56 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 27: DURATION/DTEND

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

Date: Wed, 16 Aug 2006 14:55:11 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 25: Is the first recurrence instance, defined by DTSTART, always excluded by RRULE?

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

Eliot

Date: Wed, 16 Aug 2006 14:53:01 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 23: Contradiction between UNTIL BNF rule and text

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

AI: Bernard to add text.

Eliot

Date: Wed, 16 Aug 2006 14:50:27 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE

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

AI: Bernard to add text.

Date: Wed, 16 Aug 2006 14:46:34 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 24: need to clarify number of recurrence instances generated by multiple RRULEs

This is from the IETF minutes.

AI: Clarifying text will be added.

Bernard, please specify new text.

Eliot

Date: Wed, 16 Aug 2006 09:29:45 +0200 (CEST)
From: Reinhold Kainhofer <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Sender: Reinhold Kainhofer <[email-masked]>
Cc: [email-masked]

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

From: Oliver Block <[email-masked]>
To: [email-masked]
Date: Tue, 15 Aug 2006 14:54:50 +0200
Subject: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8

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

From: Aki Niemi <[email-masked]>
To: Calsify <[email-masked]>
Organization: Nokia-NRC/Helsinki
Date: Fri, 04 Aug 2006 10:24:21 +0300
Subject: [Ietf-calsify] Double-checking IETF66 consensus

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