Subject: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE

From: lear at cisco.com (Eliot Lear)
Date: Fri Sep 29 07:25:29 2006

We have consensus that one MUST not generate and MUST ignore VEVENTs
(really any elements) containing something this broken.  We lack
specific wording.  Here is my proposal:

Section 3.3.10

OLD TEXT:

   The BYSECOND rule part specifies a COMMA character (US-ASCII
   decimal 44) separated list of seconds within a minute.  Valid
   values are 0 to 59.  The BYMINUTE rule part specifies a COMMA
   character (US-ASCII decimal 44) separated list of minutes within
   an hour.  Valid values are 0 to 59.  The BYHOUR rule part
   specifies a COMMA character (US- ASCII decimal 44) separated list
   of hours of the day.  Valid values are 0 to 23.

NEW TEXT:

   The BYSECOND rule part specifies a COMMA character (US-ASCII
   decimal 44) separated list of seconds within a minute.  Valid
   values are 0 to 59.  The BYMINUTE rule part specifies a COMMA
   character (US-ASCII decimal 44) separated list of minutes within
   an hour.  Valid values are 0 to 59.  The BYHOUR rule part
   specifies a COMMA character (US- ASCII decimal 44) separated list
   of hours of the day.  Valid values are 0 to 23.  Implementations
   MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated
   DTSTART uses VALUE=DATE.  Similarly, Implementations MUST ignore
   such constructs when see, optionally logging an error.

Eliot

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Fri Sep 29 10:39:09 2006

I would rephrase the NEW TEXT as follows :

The BYSECOND rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of seconds within a minute.  Valid
values are 0 to 59.  The BYMINUTE rule part specifies a COMMA
character (US-ASCII decimal 44) separated list of minutes within
an hour.  Valid values are 0 to 59.  The BYHOUR rule part
specifies a COMMA character (US-ASCII decimal 44) separated list
of hours of the day.  Valid values are 0 to 23.
The BYSECOND, BYMINUTE and BYHOUR rule parts MUST NOT be
specified when the associated DTSTART property has a DATE
value type. These rule parts MUST be ignored in RECUR value
that violate the above requirement (e.g., generated by
applications that pre-date this revision of iCalendar).

Cheers,
Bernard

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

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Fri Sep 29 15:12:18 2006

>    such constructs when see, optionally logging an error.

Are you sure you want to tell people that they MUST accept as valid
files that were generated in violation of a MUST? Seems odd to me to be
in the business of telling people what to do with invalid data, its
hard enough to specify what to do with valid data.

Anyhow, its not clear to me what it means to ignore the "construct". Is
it the entire calendar, the VEVENT, the RRULE, the "BYMINUTE=..." that
shouldn't be there?

If there is concern about apps out there generating data like this,
maybe say "Some implementations are known to generate these fields when
DTSTART uses VALUE=DATE, implementations SHOULD treat any BYHOUR,
BYMINUTE, or BYSECOND as not being present in this case."

Cheers,
Sam

---

From: dave at cridland.net (Dave Cridland)
Date: Sat Sep 30 01:15:03 2006

> hard enough to specify what to do with valid data.

Just to pick up on this, the constructions of "MUST NOT generate x, 
but MUST ignore x", or "MUST NOT generate x, but SHOULD accept x", 
are quite common practise. It's a codification of when to apply 
Postel's Principle - "Be conservative in what you sent, but be 
liberal in what you accept".

It's all the more useful when a specification is being revised, and 
we know there's bad data (or clients, or servers) in actual 
deployment. Another particularly useful time is when it concerns an 
invalid combination of two somewhat distinct elements. In this case, 
at least the latter applies, and possibly the former.

Let's pretend you have a CUA written which has the feature of copying 
a recurrence rule from one event to a new one, so for complex rules, 
the user can just say "Like this one", instead of re-entering a 
possibly complex rule. This text (or your replacement) gives your CUA 
a clear mandate to drop BYHOUR, BYMINUTE, and BYSECOND from the 
recurrence rule you're copying if it's a DATE value for DTSTART.

(As for which text, as someone merely tracking this WG, I understood 
what the text meant, and took "such constructs" to mean "BYHOUR, 
BYMINUTE, or BYSECOND". I don't think that "OR" should be 
capitalized, though.)

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: lear at cisco.com (Eliot Lear)
Date: Sat Sep 30 03:09:09 2006

> hard enough to specify what to do with valid data.

See Dave's not about the history of the combo.  Host Requirements (RFC
1122 / RFC 1123) made use of it first, as I recall.
To remind people the current text is based on the group's consensus.  In
this case the intentions of the sender are almost completely
unfathomable as it's a bit of a non-sequitor.
> it the entire calendar, the VEVENT, the RRULE, the "BYMINUTE=..." that

You're right.  I believe Bernard actually has better wording to address
this concern.

Eliot

Date: Sat, 30 Sep 2006 12:09:00 +0200
From: Eliot Lear <[email-masked]>
To: Sam Roberts <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 26:  BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE
Cc: [email-masked]

> hard enough to specify what to do with valid data.

See Dave's not about the history of the combo.  Host Requirements (RFC
1122 / RFC 1123) made use of it first, as I recall.
To remind people the current text is based on the group's consensus.  In
this case the intentions of the sender are almost completely
unfathomable as it's a bit of a non-sequitor.
> it the entire calendar, the VEVENT, the RRULE, the "BYMINUTE=..." that

You're right.  I believe Bernard actually has better wording to address
this concern.

Eliot

Date: Sat, 30 Sep 2006 09:14:48 +0100
Subject: Re: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE
From: Dave Cridland <[email-masked]>
To: Sam Roberts <[email-masked]>
Cc: [email-masked]

Dave.

Date: Fri, 29 Sep 2006 15:12:10 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 26:  BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE

Cheers,
Sam

Date: Fri, 29 Sep 2006 12:17:31 -0700
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Modifications to instances in a recurrence chain

Hi Folks,

Thanks, Bobby, for leaping in with your questions.  You've reminded me 
that I've been delinquent in discussing confusion I've experience (or 
seen other people experience) about recurrence in iCalendar.

For all of these issues I've experienced ambiguity, so I think we should 
really try to clarify them:

A) I'd like to see a clearer link in rfc2445 (or 2445bis) to rfc2446, 
explaining that there's more complexity to serializing recurring events 
with modifications, would be helpful.  I've noticed that a variety of 
smart people have missed that they need to read 2446 to understand 
modifications to recurring events.

B) In both rfc2445 and rfc2445bis-01, the VEVENT component's definition 
says that all properties are optional, but both UID and DTSTART's 
explanations say they are in fact required in VEVENTs.

C) What is the RECURRENCE-ID for an occurrence if an earlier 
modification that applies to THISANDFUTURE has changed the start time? 
My memory is that Cyrus and I had different ideas of how this should 
work.  In practice, both Apple iCal and Chandler create an entirely new 
event (with a new UID) if the user makes a THISANDFUTURE change to 
anything but the first occurrence, so I haven't experienced issues with 
this, but that's only because we don't do iTIP. :)

D) Similarly to C), if there is one or more THIS modifications to a 
particular RECURRENCE-ID, one of which changes the DTSTART, is the 
RECURRENCE-ID changed?  For this I'd say no, the DTSTART and 
RECURRENCE-ID don't match, but the RECURRENCE-ID stays the same.

E) Finally, the more meaty topic, do modification VEVENTs (a VEVENT with 
a particular UID/RECURRENCE-ID pair) represent diffs to the pre-existing 
rule, or an entire self-contained description of the most up-to-date 
information about that particular occurrence?

In past discussions with Cyrus about this, I was swayed by his argument 
that we need a way to delete ATTENDEEs.  But every time I discuss this 
with people it's unsatisfying.

Quick background, I think there are three main ways applications might 
model THISANDFUTURE changes that effect events that are already modified:

1) Don't detach individually modified occurrences, later THISANDFUTURE 
changes effect all occurrences, even if the property being changed was 
already changed
2) Completely detach changes to individual occurrences (THISANDFUTURE 
changes never again effect them)
3) Detach specific properties, so a change to one occurrence's SUMMARY 
won't prevent a change to all DTSTARTs from effecting that occurrence, 
but changes to all SUMMARYs *won't* effect that detached occurrence.

When I've surveyed users, 1) is considered really bad almost universally 
(it's seems too easy to erase important information), 2) is acceptable 
but annoying, and 3) is ideal.  Currently, Chandler and Apple iCal do 
2), I'd be curious to hear about other clients.  In the near future 
Chandler will move to doing 3).

If, when serialized as iCalendar, modifications are required to express 
the full and complete state of the modification (not just diffs to the 
master), then it's impossible to semantically express the concept of a 
particular detached property, it's all or nothing.

In practice, I think that many clients (at least iCal and Chandler) 
*when parsing an icalendar stream* already interpret the absence of many 
properties as implying that the property is inherited from it's parent.

So, back to the ATTENDEE case.  It seems to me that clients could 
interpret the absence of a property as implying that it's inherited, but 
if even one instance of that property is present in the modification, 
it's a change.  I think this would solve the ATTENDEE case.  The main 
thing I can think of that wouldn't work would be deleting a VALARM, 
which I would find preferable to not being able to express

If we interpreted modifications as working this way, I think we'd want 
to allow VEVENTs to not have a DTSTART if they had a RECURRENCE-ID, and 
of course, either way, we should specify the behavior clearly in the 
relevant specs.

Sincerely,
Jeffrey

Date: Fri, 29 Sep 2006 13:56:18 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 32: Charset parameter

Please ignore my previous message.

We already have proposed text which has been reviewed by Mark
and Alexey.

Cheers,
Bernard

Bernard Desruisseaux wrote:
> Here's some proposed text for this issue.
> 
> Section 3.2 Parameters
> 
> OLD TEXT:
> 
>  > 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.
> 
> NEW TEXT:
> 
>  > 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 "charset" values supported by this
>  > revision of iCalendar are UTF-8 and US-ASCII. Applications are
>  > REQUIRED to accept iCalendar streams using the UTF-8 or US-ASCII
>  > charsets, and SHOULD generate iCalendar streams with the UTF-8
>  > charset.
> 
> Section 4.1.4 Character Set
> 
> OLD TEXT:
> 
>  > 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 [RFC 2279].
>  >
>  > The "charset" Content-Type parameter can be used in MIME transports
>  > to specify any other IANA registered character set.
> 
> NEW TEXT:
> 
>  > There is not a property parameter to declare the character set used
>  > in a property value. The default character set for an iCalendar
>  > stream is UTF-8 as defined in [RFC 3629].
>  >
>  > The "charset" Content-Type parameter can be used in MIME transports
>  > to specify the character set being used.
> 
> Section 4.3.11 Text
> 
> OLD TEXT:
> 
>  > 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.
> 
> NEW TEXT:
> 
>  > Formal Definition: The value type is defined by the following notation:
> 
> Cheers,
> Bernard
> 
> 
> Cyrus Daboo wrote:
>> Hi Eliot,
>>
>> --On September 29, 2006 4:09:21 PM +0200 Eliot Lear <[email-masked]> 
>> wrote:
>>
>>> I believe this may already be addressed, but I believe we agreed, MUST
>>> accept US-ASCII, UTF-8, SHOULD generate UTF-8.  Correct?
>>
>> I think so.
>>

Date: Fri, 29 Sep 2006 13:37:11 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 26:  BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE

Cheers,
Bernard

>    such constructs when see, optionally logging an error.

Date: Fri, 29 Sep 2006 13:26:17 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 32: Charset parameter

Here's some proposed text for this issue.

Section 3.2 Parameters

OLD TEXT:

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

NEW TEXT:

 > 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 "charset" values supported by this
 > revision of iCalendar are UTF-8 and US-ASCII. Applications are
 > REQUIRED to accept iCalendar streams using the UTF-8 or US-ASCII
 > charsets, and SHOULD generate iCalendar streams with the UTF-8
 > charset.

Section 4.1.4 Character Set

OLD TEXT:

 > 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 [RFC 2279].
 >
 > The "charset" Content-Type parameter can be used in MIME transports
 > to specify any other IANA registered character set.

NEW TEXT:

 > There is not a property parameter to declare the character set used
 > in a property value. The default character set for an iCalendar
 > stream is UTF-8 as defined in [RFC 3629].
 >
 > The "charset" Content-Type parameter can be used in MIME transports
 > to specify the character set being used.

Section 4.3.11 Text

OLD TEXT:

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

NEW TEXT:

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

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Eliot,
> 
> --On September 29, 2006 4:09:21 PM +0200 Eliot Lear <[email-masked]> wrote:
> 
>> I believe this may already be addressed, but I believe we agreed, MUST
>> accept US-ASCII, UTF-8, SHOULD generate UTF-8.  Correct?
> 
> I think so.
> 

Date: Fri, 29 Sep 2006 07:42:50 -0700
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Issue 32: Charset parameter

Hi Eliot,

--On September 29, 2006 4:09:21 PM +0200 Eliot Lear <[email-masked]> wrote:

> I believe this may already be addressed, but I believe we agreed, MUST
> accept US-ASCII, UTF-8, SHOULD generate UTF-8.  Correct?

I think so.

-- 
Cyrus Daboo

Date: Fri, 29 Sep 2006 16:28:36 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Help! Volutneers needed! Issue 25: Is the first recurrence instance, defined by DTSTART, always excluded by RRULE?

All,

This issue has had no discussion on the mailing list since Montreal.  We
need some proposed text to try and drive consensus.  Are there any
volunteers?

Eliot

Date: Fri, 29 Sep 2006 16:25:21 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 26:  BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE

Section 3.3.10

OLD TEXT:

NEW TEXT:

Eliot

Date: Fri, 29 Sep 2006 16:09:21 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 32: Charset parameter

I believe this may already be addressed, but I believe we agreed, MUST
accept US-ASCII, UTF-8, SHOULD generate UTF-8.  Correct?

Eliot

Date: Thu, 28 Sep 2006 17:35:06 -0700
From: Cyrus Daboo <[email-masked]>
To: Bobby Rullo <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Modifications to instances in a recurrence chain

Hi Bobby,

--On September 28, 2006 5:28:04 PM -0700 Bobby Rullo <[email-masked]> 
wrote:

> I am trying to property implement icalendar recurrence and there are some
> things that are not clear to me.
>
> I was told by a colleague that the way to make changes to an individual
> instance in a chain of recurring events is to create within the same
> calendar an additional VEVENT with the same UID as the 'master' event and
> a RECURRENCE-ID whose value is the normal start date of that instance and
> then any properties that you would like to override for that particular
> instance.
>
> So here are my questions:
>
> 	1) The above seems relatively clear to me, but I can't find it
> explicitly explained in rfc2445. Is there another spec which covers this?
>
> 	2) Is DTSTART a required property for recurrence instances? I would not
> think so, except that iCal automatically inserts a DTSTART into
> recurrence instances even when the only thing I changes was the SUMMARY.
> Just to see what would happen, I exported that calendar, got rid of the
> offending DTSTART and reimported. To my consternation, it reinserted the
> DTSTART with a seemingly random value - until I realized that it was the
> timestamp of when I imported the file.
>
> 	3) Is there any other required properties in an overriding VEVENT
> instance?
>
> 	4) Any (preferably Mac OS X and free/cheap) clients which handle this
> properly that I should be looking to as a reference implementation (at
> least for recurrence) ?

The overridden component must be a full component in its own right - i.e. 
it must satisfy all the requirements of vevents - dtstart/dtend or duration 
etc.

At one point in time I also thought that overridden instances only needed 
to include those properties that were different from the original - but the 
problem with that is that you cannot tell if a property was removed. e.g. I 
have five attendees in the 'master' instance and I want to remove one from 
the overridden instance. In that case a 'diff' cannot work because you 
cannot indicate that one was removed. So the rule is the overridden 
component has to be complete - not a diff from the master.

-- 
Cyrus Daboo

To: Bobby Rullo <[email-masked]>
Subject: Re: [Ietf-calsify] Modifications to instances in a recurrence chain
From: Pat R Egen <[email-masked]>
Date: Thu, 28 Sep 2006 20:34:20 -0400
Cc: [email-masked], [email-masked]

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

RFC2446 covers the VEVENT stuff.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Bobby Rullo <[email-masked]> 
Sent by: [email-masked]
09/28/2006 08:28 PM

To
[email-masked]
cc

Subject
[Ietf-calsify] Modifications to instances in a recurrence chain

Hi all,

I am trying to property implement icalendar recurrence and there are 
some things that are not clear to me.

I was told by a colleague that the way to make changes to an 
individual instance in a chain of recurring events is to create 
within the same calendar an additional VEVENT with the same UID as 
the 'master' event and a RECURRENCE-ID whose value is the normal 
start date of that instance and then any properties that you would 
like to override for that particular instance.

So here are my questions:

                 1) The above seems relatively clear to me, but I can't 
find it 
explicitly explained in rfc2445. Is there another spec which covers 
this?

                 2) Is DTSTART a required property for recurrence 
instances? I would 
not think so, except that iCal automatically inserts a DTSTART into 
recurrence instances even when the only thing I changes was the 
SUMMARY. Just to see what would happen, I exported that calendar, got 
rid of the offending DTSTART and reimported. To my consternation, it 
reinserted the DTSTART with a seemingly random value - until I 
realized that it was the timestamp of when I imported the file.

                 3) Is there any other required properties in an 
overriding VEVENT 
instance?

                 4) Any (preferably Mac OS X and free/cheap) clients which 
handle 
this properly that I should be looking to as a reference 
implementation (at least for recurrence) ?

Thanks all,

bobby rullo

--=_alternative 00032841852571F8_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">RFC2446 covers the VEVENT stuff.</font>
<br><font size=2 face="sans-serif">___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Bobby Rullo &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">09/28/2006 08:28 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">[email-masked]</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[Ietf-calsify] Modifications to instances
in a recurrence chain</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Hi all,<br>
<br>
I am trying to property implement icalendar recurrence and there are &nbsp;<br>
some things that are not clear to me.<br>
<br>
I was told by a colleague that the way to make changes to an &nbsp;<br>
individual instance in a chain of recurring events is to create &nbsp;<br>
within the same calendar an additional VEVENT with the same UID as &nbsp;<br>
the 'master' event and a RECURRENCE-ID whose value is the normal &nbsp;<br>
start date of that instance and then any properties that you would &nbsp;<br>
like to override for that particular instance.<br>
<br>
So here are my questions:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
1) The above seems relatively clear to me, but I can't find it &nbsp;<br>
explicitly explained in rfc2445. Is there another spec which covers &nbsp;<br>
this?<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
2) Is DTSTART a required property for recurrence instances? I would &nbsp;<br>
not think so, except that iCal automatically inserts a DTSTART into &nbsp;<br>
recurrence instances even when the only thing I changes was the &nbsp;<br>
SUMMARY. Just to see what would happen, I exported that calendar, got &nbsp;<br>
rid of the offending DTSTART and reimported. To my consternation, it &nbsp;<br>
reinserted the DTSTART with a seemingly random value - until I &nbsp;<br>
realized that it was the timestamp of when I imported the file.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
3) Is there any other required properties in an overriding VEVENT &nbsp;<br>
instance?<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
4) Any (preferably Mac OS X and free/cheap) clients which handle &nbsp;<br>
this properly that I should be looking to as a reference &nbsp;<br>
implementation (at least for recurrence) ?<br>
<br>
Thanks all,<br>
<br>
bobby rullo<br>
<br>
_______________________________________________<br>
Ietf-calsify mailing list<br>
[email-masked]<br>
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify<br>
</font></tt>
<br>
--=_alternative 00032841852571F8_=--

From: Bobby Rullo <[email-masked]>
Date: Thu, 28 Sep 2006 17:28:04 -0700
To: [email-masked]
Subject: [Ietf-calsify] Modifications to instances in a recurrence chain

Hi all,

I am trying to property implement icalendar recurrence and there are  
some things that are not clear to me.

I was told by a colleague that the way to make changes to an  
individual instance in a chain of recurring events is to create  
within the same calendar an additional VEVENT with the same UID as  
the 'master' event and a RECURRENCE-ID whose value is the normal  
start date of that instance and then any properties that you would  
like to override for that particular instance.

So here are my questions:

	1) The above seems relatively clear to me, but I can't find it  
explicitly explained in rfc2445. Is there another spec which covers  
this?

	2) Is DTSTART a required property for recurrence instances? I would  
not think so, except that iCal automatically inserts a DTSTART into  
recurrence instances even when the only thing I changes was the  
SUMMARY. Just to see what would happen, I exported that calendar, got  
rid of the offending DTSTART and reimported. To my consternation, it  
reinserted the DTSTART with a seemingly random value - until I  
realized that it was the timestamp of when I imported the file.

	3) Is there any other required properties in an overriding VEVENT  
instance?

	4) Any (preferably Mac OS X and free/cheap) clients which handle  
this properly that I should be looking to as a reference  
implementation (at least for recurrence) ?

Thanks all,

bobby rullo

Date: Thu, 28 Sep 2006 16:07:43 +0300
From: Aki Niemi <[email-masked]>
Organization: Nokia-NRC/Helsinki
To: ext Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] jabber session next week?
Cc: "[email-masked]" <[email-masked]>

Folks,

We're getting closer to WGLC every day and it's not that far away
anymore. We really, really need to close these issues, hence the jabber
session.

Yet, you are being awfully quiet on this. Please, plan to attend if at
all possible, and indicate the day you prefer. We need you to participate.

Cheers,
Aki (as chair)

ext Eliot Lear kirjoitti:
> <chair hat on>
> 
> All,
> 
> We have a lot of open issues that we would like to close soon.  Aki and
> I would like to understand whether or not there would be interest in a
> jabber session to try to come to consensus on open issues.  We would
> propose either Tuesday or Wednesday at 5:00pm CEST (8:00am PDT).  If you
> are interested, could you send an email indicating which day you
> prefer.  I will follow up in a day or two with a real invitation in
> appropriate format (of course!).
> 
> Thanks for your participation,
> 
> Eliot

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type
Date: Thu, 28 Sep 2006 12:08:12 +0200

Am Mittwoch, 27. September 2006 21:38 schrieben Sie:
> Isn't the purpose of the DATE value type to allow its value to be
> interpreted differently by different people depending on their time
> zone? Else, why would iCalendar bother defining this value type? :-)

I forgot. And by defining a locally interpreted DATE value type it eliminates 
the existance of a universally interpreted DATE value type - as long as the 
DATE value type has nor further format specification, e.g. like DATE-TIME. :)

Regards,

Oliver

-- 

Leben ist mehr als ...
http://www.nak-nrw.de/p_6_4.html

Date: Wed, 27 Sep 2006 15:38:57 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type
Cc: [email-masked]

Oliver,

Isn't the purpose of the DATE value type to allow its value to be
interpreted differently by different people depending on their time
zone? Else, why would iCalendar bother defining this value type? :-)

The exact start and end time of events such as "Christmas",
"New Year's Day", "Canada Day" etc. depends on the time zone
of the user.

Cheers,
Bernard

Oliver Block wrote:
> Am Dienstag, 26. September 2006 17:41 schrieb Bernard Desruisseaux:
>>>> In section 4.8.6.3 Trigger of RFC 2445 it says:
>>>>> Alarms specified in an event or to-do which is defined in terms of a
>>>>> DATE value type will be triggered relative to 00:00:00 UTC on the
>>>>> specified date. For example, if "DTSTART:19980205, then the duration
>>>>> trigger will be relative to19980205T000000Z.
> 
>>>> In my opinion, applications should trigger the alarm relative to
>>>> 00:00:00 of the time zone configured on the calendar that contains
>>>> the event or to-do, or the current user's preferred time zone. UTC
>>>> should only be used when no specific time zone can be found in the
>>>> current context.
> 
> In my view every application is free to do that. It would just not define the 
> value for DTSTART as DATE but as DATE-TIME.
> In other words: I find your opinion more intuitive than the standard and 
> that's what a user will expect. On the other hand the standard will assure 
> that every application will interpret a DATE value in the same way. 
> 
> Regards,
> 
> Oliver 
> 

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type
Date: Tue, 26 Sep 2006 21:29:13 +0200

Am Dienstag, 26. September 2006 17:41 schrieb Bernard Desruisseaux:
> >> In section 4.8.6.3 Trigger of RFC 2445 it says:
> >>> Alarms specified in an event or to-do which is defined in terms of a
> >>> DATE value type will be triggered relative to 00:00:00 UTC on the
> >>> specified date. For example, if "DTSTART:19980205, then the duration
> >>> trigger will be relative to19980205T000000Z.

> >> In my opinion, applications should trigger the alarm relative to
> >> 00:00:00 of the time zone configured on the calendar that contains
> >> the event or to-do, or the current user's preferred time zone. UTC
> >> should only be used when no specific time zone can be found in the
> >> current context.

In my view every application is free to do that. It would just not define the 
value for DTSTART as DATE but as DATE-TIME.
In other words: I find your opinion more intuitive than the standard and 
that's what a user will expect. On the other hand the standard will assure 
that every application will interpret a DATE value in the same way. 

Regards,

Oliver 

-- 
Leben ist mehr als ...
http://www.nak-nrw.de/p_6_4.html

Date: Tue, 26 Sep 2006 11:41:07 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type
Cc: Calsify WG <[email-masked]>

Hi Eliot,

Eliot Lear wrote:
> Bernard,
>> In section 4.8.6.3 Trigger of RFC 2445 it says:
>>
>>> Alarms specified in an event or to-do which is defined in terms of a
>>> DATE value type will be triggered relative to 00:00:00 UTC on the
>>> specified date. For example, if "DTSTART:19980205, then the duration
>>> trigger will be relative to19980205T000000Z.
>> In my opinion, applications should trigger the alarm relative to
>> 00:00:00 of the time zone configured on the calendar that contains
>> the event or to-do, or the current user's preferred time zone. UTC
>> should only be used when no specific time zone can be found in the
>> current context.
> 
> 
> I agree in principle.  However, I am concerned about existing
> implementations.  Alarms are used, and if we make this change then how
> many implementations immediately become non-compliant?

The only thing that matter is whether users will receive their alarm at
the time they expect to receive them. People using applications that
implement what the RFC says will most likely not get their alarm at the
time they expect. In my case, I would receive them 5 hours in advance
during Eastern Standard Time, and 4 hours in advance when in Eastern
Daylight Time. I doubt there's any implementation that do this.

Currently, the text doesn't specify any clear requirement level (i.e.,
MAY, SHOULD, MUST). I think it should.

Thanks,
Bernard

> Eliot

Date: Tue, 26 Sep 2006 09:54:50 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber session next week?

<chair hat on>

All,

We have a lot of open issues that we would like to close soon.  Aki and
I would like to understand whether or not there would be interest in a
jabber session to try to come to consensus on open issues.  We would
propose either Tuesday or Wednesday at 5:00pm CEST (8:00am PDT).  If you
are interested, could you send an email indicating which day you
prefer.  I will follow up in a day or two with a real invitation in
appropriate format (of course!).

Thanks for your participation,

Eliot

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Issue 33: characters v. octets
Date: Mon, 25 Sep 2006 20:41:00 -0400

Section 6 should also say 'MUST not truncate', it needs to be the same in
both places,  other than that I agree with the proposed change.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Monday, September 25, 2006 6:28 AM
To: [email-masked]
Subject: [Ietf-calsify] Issue 33: characters v. octets

<CHAIR HAT OFF>

After a long drawn out discussion on Issue 1 regarding breaking of lines, I
would also like to close on Issue 33, which reads:

> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/0010
> 78.html
>
> 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".

I propose the following alternative wording:

In section 4.8.4.7:

 > Implementations MUST be able to receive and persist values of at  > least
255 octets for this property, but MUST not truncate values  > in the middle
of a character.

In section 6:

 > 6. An implementation can truncate a "SUMMARY" property value to 255
 >    octets, but should not truncate the property value in the middle
 >    of a character.

If someone has appropriate wording to perhaps replace the word
"character" with code point, that would be fine too.

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type
Date: Mon, 25 Sep 2006 21:26:34 +0100

On Monday 25 September 2006 19:47, Eliot Lear wrote:
> Bernard,
>
> > In section 4.8.6.3 Trigger of RFC 2445 it says:
> > > Alarms specified in an event or to-do which is defined in terms of a
> > > DATE value type will be triggered relative to 00:00:00 UTC on the
> > > specified date. For example, if "DTSTART:19980205, then the duration
> > > trigger will be relative to19980205T000000Z.
> >
> > In my opinion, applications should trigger the alarm relative to
> > 00:00:00 of the time zone configured on the calendar that contains
> > the event or to-do, or the current user's preferred time zone. UTC
> > should only be used when no specific time zone can be found in the
> > current context.
>
> I agree in principle.  However, I am concerned about existing
> implementations.  Alarms are used, and if we make this change then how
> many implementations immediately become non-compliant?

On the other hand, how many implementations violated the RFC so far and would 
be compliant after the change?

Cheers,
Reinhold

Date: Mon, 25 Sep 2006 20:47:43 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type
Cc: Calsify WG <[email-masked]>

Bernard,
> In section 4.8.6.3 Trigger of RFC 2445 it says:
>
> > Alarms specified in an event or to-do which is defined in terms of a
> > DATE value type will be triggered relative to 00:00:00 UTC on the
> > specified date. For example, if "DTSTART:19980205, then the duration
> > trigger will be relative to19980205T000000Z.
>
> In my opinion, applications should trigger the alarm relative to
> 00:00:00 of the time zone configured on the calendar that contains
> the event or to-do, or the current user's preferred time zone. UTC
> should only be used when no specific time zone can be found in the
> current context.

I agree in principle.  However, I am concerned about existing
implementations.  Alarms are used, and if we make this change then how
many implementations immediately become non-compliant?

Eliot

Date: Mon, 25 Sep 2006 14:16:41 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type

In section 4.8.6.3 Trigger of RFC 2445 it says:

 > Alarms specified in an event or to-do which is defined in terms of a
 > DATE value type will be triggered relative to 00:00:00 UTC on the
 > specified date. For example, if "DTSTART:19980205, then the duration
 > trigger will be relative to19980205T000000Z.

In my opinion, applications should trigger the alarm relative to
00:00:00 of the time zone configured on the calendar that contains
the event or to-do, or the current user's preferred time zone. UTC
should only be used when no specific time zone can be found in the
current context.

Cheers,
Bernard

Date: Mon, 25 Sep 2006 19:57:58 +0200
From: Eliot Lear <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] ABNF
Cc: [email-masked]

Alexey Melnikov wrote:
>>>
>>> calprops   =  prodid version [calscale] [method] *x-prop
>>>             ; can appear in any order
>>>
>>> I do think that is better than having comments indicating the
>>> frequency of occurrence of each element as we have now.
>>>   
>>
>> We have to be extremely careful about these changes, but I believe the
>> above text is actually more clear than what is there.  Does anyone
>> object to this change?
>>  
>>
> I don't have any objections, however many people don't bother reading
> ABNF. So this comment should also appear in the text.
>

Right.  Similar to the one that there now ;-)

Date: Mon, 25 Sep 2006 18:54:25 +0100
From: Alexey Melnikov <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] ABNF
Cc: [email-masked]

Eliot Lear wrote:

>Cyrus,
>  
>
>>Unfortunately ABNF itself does not have the concept of an 'unordered'
>>list of items. However, the last time I discussed this with ABNF
>>folks, I think the general consensus was that it was OK to add a
>>comment to the ABNF stating that all items in that element were
>>'unordered'. So we could have:
>>
>>calprops   =  prodid version [calscale] [method] *x-prop
>>             ; can appear in any order
>>
>>I do think that is better than having comments indicating the
>>frequency of occurrence of each element as we have now.
>>    
>>
>
>We have to be extremely careful about these changes, but I believe the
>above text is actually more clear than what is there.  Does anyone
>object to this change?
>  
>
I don't have any objections, however many people don't bother reading 
ABNF. So this comment should also appear in the text.

Date: Mon, 25 Sep 2006 17:07:29 +0100
From: Alexey Melnikov <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 19: IANA considerations for RFC2445bis
Cc: "[email-masked]" <[email-masked]>

Eliot Lear wrote:

>[Chair hat off again]
>
>All,
>
>Our charter calls for us to clarify IANA considerations for new
>components / tokens.  In my opinion interoperability demands that new
>components be documented.  My preference is by RFC.  A procedure,
>however, for the content of the RFC would smooth things along.  How
>would people like to proceed?  Think about how DHCP options are handled,
>for instance.  There's a template and people use it, and eventually an
>option is assigned by IANA.
>
>In case you're wondering just how this relates to the price of tea in
>China, at the last Calconnect (as opposed to the one going on now),
>there was a proposal to include some sort of venue information, like
>telephone number or number of seats or the like.  Having something along
>these lines would be useful.  There's a lot of meta information out
>there about things like meeting rooms that we don't want to duplicate
>from people's LDAP directories, of course.  But the common example of
>this might be telephone information relating to conferencing.
>
>We don't want to make additions like this too difficult, but I think
>they should still be subject to some sort of review.
>
>Now, from my reading of the current draft the only thing that IANA needs
>to keep track of is iana-token.  Is that correct?  If so, I propose the
>following text:
>
>The IANA is requested to maintain a database of tokens.  Each token
>should be associated with an RFC that has undergone review by the IETF. 
>  
>
If this procedure is not to be enforced on vendor specific tokens, than 
this is Ok.
(Your template looks fine.)

Date: Mon, 25 Sep 2006 15:02:40 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 19: IANA considerations for RFC2445bis

[Chair hat off again]

All,

Our charter calls for us to clarify IANA considerations for new
components / tokens.  In my opinion interoperability demands that new
components be documented.  My preference is by RFC.  A procedure,
however, for the content of the RFC would smooth things along.  How
would people like to proceed?  Think about how DHCP options are handled,
for instance.  There's a template and people use it, and eventually an
option is assigned by IANA.

In case you're wondering just how this relates to the price of tea in
China, at the last Calconnect (as opposed to the one going on now),
there was a proposal to include some sort of venue information, like
telephone number or number of seats or the like.  Having something along
these lines would be useful.  There's a lot of meta information out
there about things like meeting rooms that we don't want to duplicate
from people's LDAP directories, of course.  But the common example of
this might be telephone information relating to conferencing.

We don't want to make additions like this too difficult, but I think
they should still be subject to some sort of review.

Now, from my reading of the current draft the only thing that IANA needs
to keep track of is iana-token.  Is that correct?  If so, I propose the
following text:

The IANA is requested to maintain a database of tokens.  Each token
should be associated with an RFC that has undergone review by the IETF. 
Each such RFC shall make use of the following template to register tokens:

1.  Token Name
2.  Context in which the token is valid (vevent / vprop / vtodo / ... )
3.  ABNF description of the token, using the context of this memo
4.  How many of these may appear in one context?
5.  Semantic specification of the token or a reference thereto.

(Contrived) Example:

1.  Token Name: VENUE
2.  Valid Context: VEVENT
3.  ABNF: 

venui = "VENUE" ":" 1*( rconfinfo /  confroominfo )
rconfinfo =  "REMOTE" ( "/" ( vconfurl ) / ( confnum  ["+" confpass] ))
...

Comments?

Eliot

Date: Mon, 25 Sep 2006 14:01:43 +0200
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] ABNF
Cc: [email-masked]

Cyrus,

>
> Unfortunately ABNF itself does not have the concept of an 'unordered'
> list of items. However, the last time I discussed this with ABNF
> folks, I think the general consensus was that it was OK to add a
> comment to the ABNF stating that all items in that element were
> 'unordered'. So we could have:
>
> calprops   =  prodid version [calscale] [method] *x-prop
>              ; can appear in any order
>
> I do think that is better than having comments indicating the
> frequency of occurrence of each element as we have now.
>

We have to be extremely careful about these changes, but I believe the
above text is actually more clear than what is there.  Does anyone
object to this change?

Eliot

Date: Mon, 25 Sep 2006 12:27:58 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 33: characters v. octets

<CHAIR HAT OFF>

After a long drawn out discussion on Issue 1 regarding breaking of
lines, I would also like to close on Issue 33, which reads:

> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/001078.html
>
> 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".

I propose the following alternative wording:

In section 4.8.4.7:

 > Implementations MUST be able to receive and persist values of at
 > least 255 octets for this property, but MUST not truncate values 
 > in the middle of a character.

In section 6:

 > 6. An implementation can truncate a "SUMMARY" property value to 255
 >    octets, but should not truncate the property value in the middle
 >    of a character.

If someone has appropriate wording to perhaps replace the word
"character" with code point, that would be fine too.

Date: Sat, 23 Sep 2006 10:46:53 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] ABNF
Cc: [email-masked]

Hi Bernard,

--On September 22, 2006 8:31:17 PM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> The notation you are proposing would dictate a specific
> ordering of the properties.

Unfortunately ABNF itself does not have the concept of an 'unordered' list 
of items. However, the last time I discussed this with ABNF folks, I think 
the general consensus was that it was OK to add a comment to the ABNF 
stating that all items in that element were 'unordered'. So we could have:

calprops   =  prodid version [calscale] [method] *x-prop
              ; can appear in any order

I do think that is better than having comments indicating the frequency of 
occurrence of each element as we have now.

-- 
Cyrus Daboo

Date: Fri, 22 Sep 2006 20:31:17 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] ABNF
Cc: [email-masked]

Hi Oliver,

The notation you are proposing would dictate a specific
ordering of the properties.

Cheers,
Bernard

Oliver Block wrote:
> Hello list,
> 
> The ABNF notation could be spared.
> 
> As an example (page 51/52):
> 
>      calprops   = 2*(
> 
>                 ; 'prodid' and 'version' are both REQUIRED,
>                 ; but MUST NOT occur more than once
> 
>                 prodid /version /
> 
>                 ; 'calscale' and 'method' are optional,
>                 ; but MUST NOT occur more than once
> 
>                 calscale        /
>                 method          /
> 
>                 x-prop
> 
>                 )
> 
> Could be noted as follows:
> 
> calprops   =  prodid version  *1calscale *1method *x-prop
> 
> or:
> 
> calprops   =  prodid version  [calscale] [method] *x-prop
> 
> Regards,
> 
> Oliver
> 

From: Oliver Block <[email-masked]>
To: [email-masked]
Date: Sat, 23 Sep 2006 01:04:07 +0200
Subject: [Ietf-calsify] ABNF

Hello list,

The ABNF notation could be spared.

As an example (page 51/52):

     calprops   = 2*(

                ; 'prodid' and 'version' are both REQUIRED,
                ; but MUST NOT occur more than once

                prodid /version /

                ; 'calscale' and 'method' are optional,
                ; but MUST NOT occur more than once

                calscale        /
                method          /

                x-prop

                )

Could be noted as follows:

calprops   =  prodid version  *1calscale *1method *x-prop

or:

calprops   =  prodid version  [calscale] [method] *x-prop

Regards,

Oliver

-- 
Leben ist mehr als ... 
http://www.nak-nrw.de/p_6_4.html

Date: Fri, 22 Sep 2006 09:24:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: "[email-masked]" <[email-masked]>

On Fri, 22 Sep 2006, Eliot Lear wrote:
> That sounds like consensus wording to me if ever I heard some.  Can we
> move along?

Sold!

-- 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: Fri, 22 Sep 2006 13:45:29 +0200
From: Eliot Lear <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: Mark Crispin <[email-masked]>, "[email-masked]" <[email-masked]>

Alexey Melnikov wrote:
> Mark Crispin wrote:
>
>> On Thu, 21 Sep 2006, Alexey Melnikov wrote:
>>
>>>>>    2. Add a sentence as follows: "It is possible for very simple
>>>>>       implementations to have improperly folded lines in the
>>>>> middle of
>>>>>       UTF-8 characters.  In such cases, implementations SHOULD unfold
>>>>>       lines in such a way to properly restore the character.
>>>>
>>>> I would make that a "Note", I would replace "UTF-8 characters" by
>>>> "character" and I would lowercase the SHOULD.
>>>
>> Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear
>> what we are talking about.  Other charsets have multi-octet sequences
>> too, but we've deprecated the use of these.
>>
>> Suggest using "need to" instead of "should", to indicate that this is
>> a corrolary technical requirement as opposed to something
>> specifically required by the protocol.
>>
>>>> That is:
>>>> >    Note: It is possible for very simple implementations to have
>>>> >    improperly folded lines in the middle of a character. In such
>>>> >    cases, implementations should unfold lines in such a way to
>>>> >    properly restore the character.
>>>
>>> I would also delete "In such cases". A receiving client has no other
>>> choice.
>>
>> Another good point.
>>
>> In conclusion, suggest:
>>
>>     Note: It is possible for very simple implementations to generate
>>     improperly folded lines in the middle of a UTF-8 multi-octet
>>     sequence. For this reason, implementations need to unfold lines
>>     in such a way to properly restore the unbroken sequence.
>
> I like that, but "unbroken" reads strangely hear (the sender might
> have broken it).
> Maybe "restore the original sequence"?
>
That sounds like consensus wording to me if ever I heard some.  Can we
move along?

Eliot

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Date: Fri, 22 Sep 2006 13:23:04 +0200

Am Donnerstag, 21. September 2006 21:42 schrieb Eliot Lear:
> Are there any objections to the below?  Oliver?

None, that I'd like to express in this stage of decision making.

Best Regards,

Oliver

-- 
Leben ist mehr als ...
http://www.nak-nrw.de/p_6_4.html

Date: Fri, 22 Sep 2006 10:58:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: "[email-masked]" <[email-masked]>

Mark Crispin wrote:

> On Thu, 21 Sep 2006, Alexey Melnikov wrote:
>
>>>>    2. Add a sentence as follows: "It is possible for very simple
>>>>       implementations to have improperly folded lines in the middle of
>>>>       UTF-8 characters.  In such cases, implementations SHOULD unfold
>>>>       lines in such a way to properly restore the character.
>>>
>>> I would make that a "Note", I would replace "UTF-8 characters" by
>>> "character" and I would lowercase the SHOULD.
>>
> Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear what 
> we are talking about.  Other charsets have multi-octet sequences too, 
> but we've deprecated the use of these.
>
> Suggest using "need to" instead of "should", to indicate that this is 
> a corrolary technical requirement as opposed to something specifically 
> required by the protocol.
>
>>> That is:
>>> >    Note: It is possible for very simple implementations to have
>>> >    improperly folded lines in the middle of a character. In such
>>> >    cases, implementations should unfold lines in such a way to
>>> >    properly restore the character.
>>
>> I would also delete "In such cases". A receiving client has no other 
>> choice.
>
> Another good point.
>
> In conclusion, suggest:
>
>     Note: It is possible for very simple implementations to generate
>     improperly folded lines in the middle of a UTF-8 multi-octet
>     sequence. For this reason, implementations need to unfold lines
>     in such a way to properly restore the unbroken sequence.

I like that, but "unbroken" reads strangely hear (the sender might have 
broken it).
Maybe "restore the original sequence"?

Date: Thu, 21 Sep 2006 14:21:28 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: "[email-masked]" <[email-masked]>

On Thu, 21 Sep 2006, Alexey Melnikov wrote:
>>>    2. Add a sentence as follows: "It is possible for very simple
>>>       implementations to have improperly folded lines in the middle of
>>>       UTF-8 characters.  In such cases, implementations SHOULD unfold
>>>       lines in such a way to properly restore the character.
>> I would make that a "Note", I would replace "UTF-8 characters" by
>> "character" and I would lowercase the SHOULD.

Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear what we 
are talking about.  Other charsets have multi-octet sequences too, but 
we've deprecated the use of these.

Suggest using "need to" instead of "should", to indicate that this is 
a corrolary technical requirement as opposed to something specifically 
required by the protocol.

>> That is:
>> >    Note: It is possible for very simple implementations to have
>> >    improperly folded lines in the middle of a character. In such
>> >    cases, implementations should unfold lines in such a way to
>> >    properly restore the character.
> I would also delete "In such cases". A receiving client has no other choice.

Another good point.

In conclusion, suggest:

     Note: It is possible for very simple implementations to generate
     improperly folded lines in the middle of a UTF-8 multi-octet
     sequence. For this reason, implementations need to unfold lines
     in such a way to properly restore the unbroken sequence.

-- Mark --

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

Date: Thu, 21 Sep 2006 21:44:21 +0200
From: Eliot Lear <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in	section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

Are there objections to Mark's proposed wording?

Eliot

Mark Crispin wrote:
> On Thu, 21 Sep 2006, Bernard Desruisseaux wrote:
>> - The use of other character set is not forbidden.
>
> Can it be deprecated though?
>
> US-ASCII, UTF-8, etc. are charsets, not character sets.  This is
> particularly important with UTF-8; the character set is Unicode, not
> UTF-8.
>
> Finally, since you already state that UTF-8 SHOULD be generated, there
> is no reason that US-ASCII be listed as a supported charset.  It
> sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted.
>
> Suggested wording:
>
>     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 charset supported by this revision of
>     iCalendar is UTF-8. The use of any other charset is deprecated by
>     this revision of iCalendar; however note that this revision
>     requires that compliant applications MUST accept iCalendar objects
>     using either the UTF-8 or US-ASCII charset.
>
> Also change other occurances of "character set" to "charset".
>
> -- 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: Thu, 21 Sep 2006 21:42:05 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: "[email-masked]" <[email-masked]>

Are there any objections to the below?  Oliver?

Bernard Desruisseaux wrote:
> Eliot Lear wrote:
>> <Chair Hat Off>
>>
> > [...]
> >
>> I  have two recommendations for textual changes to RFC 2445:
>>
>>    1. Delete the second sentence in the 2nd paragraph after the example
>>       in 4.1 as redundant (it says the exact same thing in the first
>>       paragraph);
>
> +1
>
>>    2. Add a sentence as follows: "It is possible for very simple
>>       implementations to have improperly folded lines in the middle of
>>       UTF-8 characters.  In such cases, implementations SHOULD unfold
>>       lines in such a way to properly restore the character.
>
> I would make that a "Note", I would replace "UTF-8 characters" by
> "character" and I would lowercase the SHOULD.  That is:
>
> >    Note: It is possible for very simple implementations to have
> >    improperly folded lines in the middle of a character. In such
> >    cases, implementations should unfold lines in such a way to
> >    properly restore the character.
>
> Thanks,
> Bernard
>
>>
>> Eliot
>>

Date: Thu, 21 Sep 2006 20:09:08 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: "[email-masked]" <[email-masked]>

Bernard Desruisseaux wrote:

> Eliot Lear wrote:
>
>> <Chair Hat Off>
>
> > [...]
>
>> I  have two recommendations for textual changes to RFC 2445:
>>
>>    1. Delete the second sentence in the 2nd paragraph after the example
>>       in 4.1 as redundant (it says the exact same thing in the first
>>       paragraph);
>
> +1

+1

>>    2. Add a sentence as follows: "It is possible for very simple
>>       implementations to have improperly folded lines in the middle of
>>       UTF-8 characters.  In such cases, implementations SHOULD unfold
>>       lines in such a way to properly restore the character.
>
> I would make that a "Note", I would replace "UTF-8 characters" by
> "character" and I would lowercase the SHOULD.  That is:
>
> >    Note: It is possible for very simple implementations to have
> >    improperly folded lines in the middle of a character. In such
> >    cases, implementations should unfold lines in such a way to
> >    properly restore the character.

I would also delete "In such cases". A receiving client has no other choice.

Date: Thu, 21 Sep 2006 20:01:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in	section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

Mark Crispin wrote:

> On Thu, 21 Sep 2006, Bernard Desruisseaux wrote:
>
>> - The use of other character set is not forbidden.
>
> Can it be deprecated though?
>
> US-ASCII, UTF-8, etc. are charsets, not character sets.  This is 
> particularly important with UTF-8; the character set is Unicode, not 
> UTF-8.
>
> Finally, since you already state that UTF-8 SHOULD be generated, there 
> is no reason that US-ASCII be listed as a supported charset.  It 
> sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted.
>
> Suggested wording:
>
>     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 charset supported by this revision of
>     iCalendar is UTF-8. The use of any other charset is deprecated by
>     this revision of iCalendar; however note that this revision
>     requires that compliant applications MUST accept iCalendar objects
>     using either the UTF-8 or US-ASCII charset.

I can live with this alternative text as well.

> Also change other occurances of "character set" to "charset".

Date: Thu, 21 Sep 2006 19:59:50 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Calsify WG <[email-masked]>

Bernard Desruisseaux wrote:

> Folks, I would like to close issue 31 with a new proposal:
>
> - UTF-8 and US-ASCII are the only character set supported by iCalendar.
> - The use of other character set is not forbidden.
> - Compliant applications are REQUIRED to accept UTF-8 and US-ASCII.
> - Compliant applications SHOULD generate iCalendar objects in UTF-8.
>
> Here's the proposed text changes:
>
> Section 3.2 Parameters
>
> OLD TEXT:
>
>> 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.
>
> NEW TEXT:
>
>> 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 character sets supported by this revision
>
As per Mark's comment: replace "character set" with "charset"

>> of iCalendar are UTF-8 and US-ASCII.
>
>
> Section 4.1.4 Character Set
>
> OLD TEXT:
>
>> 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 [RFC 2279].
>>
>> The "charset" Content-Type parameter can be used in MIME transports
>> to specify any other IANA registered character set.
>
> NEW TEXT:
>
>> There is not a property parameter to declare the character set used
>
s/character set/charset

>> in a property value. The default character set for an iCalendar
>
s/character set/charset

>> object is UTF-8 as defined in [RFC 3629].
>>
>> The character sets supported by this revision of iCalendar are UTF-8
>
s/character sets/charsets

>> and US-ASCII. Compliant applications MUST accept iCalendar objects
>> using the UTF-8 or US-ASCII character set and SHOULD generate
>> iCalendar object using the UTF-8 character set.
>>
>> The "charset" Content-Type parameter can be used in MIME transports
>> to specify the character set being used.
>
I would change the last sentence to become normative:

The "charset" Content-Type parameter MUST be used in MIME transports
to specify the charset being used.

(this MUST is irrelevant for US-ASCII case, but I can't think of any 
better way of saying that)

> Section 4.3.11 Text
>
> OLD TEXT:
>
>> 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.
>
> NEW TEXT:
>
>> Formal Definition: The value type is defined by the following notation:
>
Otherwise I am fine with this proposal.

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

On Thu, 21 Sep 2006, Bernard Desruisseaux wrote:
> - The use of other character set is not forbidden.

Can it be deprecated though?

US-ASCII, UTF-8, etc. are charsets, not character sets.  This is 
particularly important with UTF-8; the character set is Unicode, not 
UTF-8.

Finally, since you already state that UTF-8 SHOULD be generated, there 
is no reason that US-ASCII be listed as a supported charset.  It 
sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted.

Suggested wording:

 	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 charset supported by this revision of
 	iCalendar is UTF-8. The use of any other charset is deprecated by
 	this revision of iCalendar; however note that this revision
 	requires that compliant applications MUST accept iCalendar objects
 	using either the UTF-8 or US-ASCII charset.

Also change other occurances of "character set" to "charset".

-- 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: Thu, 21 Sep 2006 14:21:52 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in section	4.3.11 Text

Hi Bernard,

--On September 21, 2006 2:11:49 PM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

+1 to your new text on charset.

-- 
Cyrus Daboo

Date: Thu, 21 Sep 2006 14:20:45 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: "[email-masked]" <[email-masked]>

Eliot Lear wrote:
> <Chair Hat Off>
> 
 > [...]
 >
> I  have two recommendations for textual changes to RFC 2445:
> 
>    1. Delete the second sentence in the 2nd paragraph after the example
>       in 4.1 as redundant (it says the exact same thing in the first
>       paragraph);

+1

>    2. Add a sentence as follows: "It is possible for very simple
>       implementations to have improperly folded lines in the middle of
>       UTF-8 characters.  In such cases, implementations SHOULD unfold
>       lines in such a way to properly restore the character.

I would make that a "Note", I would replace "UTF-8 characters" by
"character" and I would lowercase the SHOULD.  That is:

 >    Note: It is possible for very simple implementations to have
 >    improperly folded lines in the middle of a character. In such
 >    cases, implementations should unfold lines in such a way to
 >    properly restore the character.

Thanks,
Bernard

> Eliot

Date: Thu, 21 Sep 2006 14:11:49 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text

Folks, I would like to close issue 31 with a new proposal:

- UTF-8 and US-ASCII are the only character set supported by iCalendar.
- The use of other character set is not forbidden.
- Compliant applications are REQUIRED to accept UTF-8 and US-ASCII.
- Compliant applications SHOULD generate iCalendar objects in UTF-8.

Here's the proposed text changes:

Section 3.2 Parameters

OLD TEXT:

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

NEW TEXT:

> 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 character sets supported by this revision
> of iCalendar are UTF-8 and US-ASCII.

Section 4.1.4 Character Set

OLD TEXT:

> 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 [RFC 2279].
>
> The "charset" Content-Type parameter can be used in MIME transports
> to specify any other IANA registered character set.

NEW TEXT:

> 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 [RFC 3629].
>
> The character sets supported by this revision of iCalendar are UTF-8
> and US-ASCII. Compliant applications MUST accept iCalendar objects
> using the UTF-8 or US-ASCII character set and SHOULD generate
> iCalendar object using the UTF-8 character set.
>
> The "charset" Content-Type parameter can be used in MIME transports
> to specify the character set being used.

Section 4.3.11 Text

OLD TEXT:

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

NEW TEXT:

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

Cheers,
Bernard

Bernard Desruisseaux wrote:
> 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.
> 
> 

Date: Thu, 21 Sep 2006 12:11:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.8.1 Non-standard Properties: Parameters allowed on x-prop
Cc: Calsify WG <[email-masked]>

Bernard Desruisseaux wrote:

> In section 4.8.8.1 Non-standard Properties of RFC 2445 it says:
>
> > The data type for this property
> > is TEXT. Optionally, the data type can be any of the other valid data
> > types.
> >
> > Format Definition: The property is defined by the following notation:
> >
> >  x-prop     = x-name *(";" xparam) [";" languageparam] ":" text CRLF
> >     ; Lines longer than 75 octets should be folded
>
> In my opinion x-prop should allow any parameter defined by iCalendar
> as well as any iana-param.  There is no reason to invent an xparam
> if there already exists a parameter that can be used.

This make sense.

> While "the data type [of an x-prop] can be any of the other valid data
> type", one would currently not be allowed to specify the VALUE parameter
> to specify the value type of the property. Here's an example, found on
> the web, that I believe should be valid:
>
>   X-WD-NEXT-ALARM;VALUE=DATE-TIME:20040927T153000
>
> [ Actually, this example would still be invalid since WinDate didn't use
> a "vendor identification" of at least 3 characters. See the vendorid
> rule in section 4.1 Content Lines. ]

From: "Tim Hare" <[email-masked]>
To: "'Calsify List'" <[email-masked]>
Subject: RE: [Ietf-calsify] Issue 1: new proposed text
Date: Wed, 20 Sep 2006 23:24:14 -0400

I don't claim to be a UTF-anything expert, but the current text does require
white space (SP or TAB) after the CRLF for folding.  However - what do we
break if we eliminate the folding altogether as in my proposed text below?

Old Text:
----------------------------------------------------------------------------
4.1 Content Lines

   The iCalendar object is organized into individual lines of text,
   called content lines. Content lines are delimited by a line break,
   which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
   decimal 10).

   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.

   For example the line:

     DESCRIPTION:This is a long description that exists on a long line.

   Can be represented as:

     DESCRIPTION:This is a lo
      ng description
       that exists on a long line.

   The process of moving from this folded multiple line representation
   to its single line representation is called "unfolding". Unfolding is
   accomplished by removing the CRLF character and the linear white
   space character that immediately follows.

   When parsing a content line, folded lines MUST first be unfolded
   according to the unfolding procedure described above. When generating
   a content line, lines longer than 75 octets SHOULD be folded
   according to the folding procedure described above.
  The content information associated with an iCalendar object is
   formatted using a syntax similar to that defined by [RFC 2425]. That
   is, the content information consists of CRLF-separated content lines.

   The following notation defines the lines of content in an iCalendar
   object:

     contentline        = name *(";" param ) ":" value CRLF
        ; This ABNF is just a general definition for an initial parsing
        ; of the content line into its property name, parameter list,
        ; and value string

     ; When parsing a content line, folded lines MUST first
        ; be unfolded according to the unfolding procedure
        ; described above. When generating a content line, lines
        ; longer than 75 octets SHOULD be folded according to
        ; the folding procedure described above.
----------------------------------------------------------------------------
---------------------------------

Proposed new text (feel free to make modifications as necessary for Unicode
purposes)
----------------------------------------------------------------------------
---------------------------------
4.1 Content Lines

   The iCalendar object is organized into individual lines of text,
   called content lines. Content lines are delimited by a line break,
   which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
   decimal 10).

   Lines of text may be of arbitrary length. It is up to the CUA
implementation
   to present the text to the user in a manner consistent with the current
user
   interface in use, which may include wrapping the text within margins or
other
   forms of presentation changes. The originator of calendar object text
should
   not expect its display to be limited to any arbitrary length.

   Older implementations of [RFC 2445] may be encountered which have
performed a 
   "folding" acton on longer lines of text by inserting a CRLF sequence
followed by 
   a single linear white space character (SPACE, US-ASCII decimal 32; or
HTAB 
   US-ASCII decimal 09) at logical folding points. This is usually done in
e-mail
   implementations to improve compatibility with some mailing programs.
Implementations
   MAY choose to "unfold" these lines by replacing the CRLF-whitespace
sequence with 
   a single space.

   For example the line:

     DESCRIPTION:This is a lo
      ng description
       that exists on a long line.

   May be presented to the interface as is, or may be unfolded to read:

     DESCRIPTION: This is a long descripton that exists on a long line.

  The content information associated with an iCalendar object is
   formatted using a syntax similar to that defined by [RFC 2425]. That
   is, the content information consists of CRLF-separated content lines.

   The following notation defines the lines of content in an iCalendar
   object:

     contentline        = name *(";" param ) ":" value CRLF
        ; This ABNF is just a general definition for an initial parsing
        ; of the content line into its property name, parameter list,
        ; and value string

     ; When parsing a content line, folded lines MAY first
        ; be unfolded according to the unfolding procedure
        ; described above. 

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

Since TEXT property values MUST represent intentional line breaks via "\n"
or "\N" (4.3.11) anyone desiring to
Format the content of a long line may include those formatting sequences.
The most likely use case for folding is the
DESCRIPTION: property,  "\n" is completely appropriate to use there and is
already seen in implementations. I also
believe that most current implementations "wrap" text within some UI limit
(margins, window size, etcetera) so the
human factor of folding is already handled in the UI anyway.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bill McQuillan
Sent: Wednesday, September 20, 2006 12:57 PM
To: Calsify List
Subject: Re: [Ietf-calsify] Issue 1: new proposed text

On Wed, 2006-09-20, I wrote:

> A further issue is that the definition of "folding" in RFC 2822 
> explicitly states (sect.2.2.3) that the unfolded text includes the SP 
> following the CRLF. Thus, a UTF-8 sequence of any sort would be 
> interrupted by a SP character unless an idiosyncratic unfolding operation
is employed.

Sorry, I'm afraid I had a temporary brain glitch. The folding technique is
NOT modeled on RFC2822 headers and the issue of the SP does not exist.

Never mind!

--
Bill McQuillan <[email-masked]>

Date: Wed, 20 Sep 2006 09:57:20 -0700
From: Bill McQuillan <[email-masked]>
To: Calsify List <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text

On Wed, 2006-09-20, I wrote:

> A further issue is that the definition of "folding" in RFC 2822 explicitly
> states (sect.2.2.3) that the unfolded text includes the SP following the
> CRLF. Thus, a UTF-8 sequence of any sort would be interrupted by a SP
> character unless an idiosyncratic unfolding operation is employed.

Sorry, I'm afraid I had a temporary brain glitch. The folding technique is NOT modeled on RFC2822 headers and the issue of the SP does not exist.

Never mind!

-- 
Bill McQuillan <[email-masked]>

Date: Wed, 20 Sep 2006 09:14:12 -0700
From: Bill McQuillan <[email-masked]>
To: Calsify List <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text

On Wed, 2006-09-20, Cyrus Daboo wrote:
> --On September 20, 2006 5:30:13 PM +0200 Eliot Lear <[email-masked]> wrote:

>>> Actually it is for everybody who wants to produce well-formed UTF-8.
>>>
>>
>> But nobody will care unless they're looking at the raw message.  Yes,
>> it's malformed, but then it's not really meant to be represented.  What
>> really should be happening is that implementations should use MIME
>> multipart/alternative and not put a text/calendar message in front of a
>> user.

> The issue is that it is not out of the realm of possibility that a spam 
> filter or some other 'integrity' checker in email will reject an iMIP 
> message because it contains invalid utf-8 (utf-8 multi-octet sequence 
> broken across two lines). Another example might be reading the utf-8 byte
> stream into a unicode string object BEFORE doing the iCal processing on the
> unicode string data - that will likely fail if there is invalid utf-8. 
> That's been my primary concern rather than whether it will be viewable in a
> text editor.

A further issue is that the definition of "folding" in RFC 2822 explicitly
states (sect.2.2.3) that the unfolded text includes the SP following the
CRLF. Thus, a UTF-8 sequence of any sort would be interrupted by a SP
character unless an idiosyncratic unfolding operation is employed.

-- 
Bill McQuillan <[email-masked]>

Date: Wed, 20 Sep 2006 17:57:39 +0200
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: [email-masked]

Hi Cyrus,
> The issue is that it is not out of the realm of possibility that a
> spam filter or some other 'integrity' checker in email will reject an
> iMIP message because it contains invalid utf-8 (utf-8 multi-octet
> sequence broken across two lines). Another example might be reading
> the utf-8 byte stream into a unicode string object BEFORE doing the
> iCal processing on the unicode string data - that will likely fail if
> there is invalid utf-8. That's been my primary concern rather than
> whether it will be viewable in a text editor.

Sorry- to be clear RFC 2445 already requires that you not split lines in
the middle of characters.  This implies valid UTF-8 when used, IMHO.

Eliot

Date: Wed, 20 Sep 2006 11:49:36 -0400
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: [email-masked]

Hi Eliot,

--On September 20, 2006 5:30:13 PM +0200 Eliot Lear <[email-masked]> wrote:

>> Actually it is for everybody who wants to produce well-formed UTF-8.
>>
>
> But nobody will care unless they're looking at the raw message.  Yes,
> it's malformed, but then it's not really meant to be represented.  What
> really should be happening is that implementations should use MIME
> multipart/alternative and not put a text/calendar message in front of a
> user.

The issue is that it is not out of the realm of possibility that a spam 
filter or some other 'integrity' checker in email will reject an iMIP 
message because it contains invalid utf-8 (utf-8 multi-octet sequence 
broken across two lines). Another example might be reading the utf-8 byte 
stream into a unicode string object BEFORE doing the iCal processing on the 
unicode string data - that will likely fail if there is invalid utf-8. 
That's been my primary concern rather than whether it will be viewable in a 
text editor.

-- 
Cyrus Daboo

Date: Wed, 20 Sep 2006 08:49:33 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: [email-masked]

On Wed, 20 Sep 2006, Eliot Lear wrote:
>> Actually it is for everybody who wants to produce well-formed UTF-8.
> But nobody will care unless they're looking at the raw message.  Yes,
> it's malformed, but then it's not really meant to be represented.  What
> really should be happening is that implementations should use MIME
> multipart/alternative and not put a text/calendar message in front of a
> user.

I support Eliot's position.

My position can best be summarized as being "do it right or don't do it at 
all."

That is, we should choose between either "only fold at a point that 
represents a complete glyph" or "it doesn't matter where folding takes 
place, since the text will always be unfolded prior to processing."

It is pointless to talk about "well-formed UTF-8" and say that is "good 
enough."  Yes, you can break a UTF-8 string such that the two substrings 
are both independently interpretable by a UTF-8 decoder.  The problem is 
that if the break is before a combining character codepoint, the string 
after the break is NOT a valid UTF-8 string since it begins with a 
combining character.  Put another way, it's valid UTF-8 encoding of an 
invalid string.

I believe that a half-solution is the worst possible choice, since it 
creates the illusion of viability for a primitive tool that uses the raw 
message without doing proper folding.

If we punt, and say that folding can occur anywhere, then primitive tools 
are broken; they will attempt to deal with dangling UTF-8 strings which 
end in the middle of a codepoint sequence, and with strings that start in 
the middle of a codepoint sequence.

If we go all the way, and say that folding can only occur at a glyph 
point, then primitive tools will be fine.  That is a lot of work to 
undertake just to make it easier for some lazy programmer to foist a 
primitive tool as being acceptable.

In my opinion, we should choose between supporting primitive tools, or 
declaring primitive tools to be totally broken.

-- 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: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Date: Wed, 20 Sep 2006 17:48:24 +0200

Am Mittwoch, 20. September 2006 17:30 schrieb Eliot Lear:
> > �
> >
> >> � � * The concern is only for those who are attempting to read the
> >> � � � calendar information in a text based mailer,
> >> � �
> >
> > Actually it is for everybody who wants to produce well-formed UTF-8.
> > �
>
> But nobody will care unless they're looking at the raw message. �Yes,
> it's malformed, but then it's not really meant to be represented. �What
> really should be happening is that implementations should use MIME
> multipart/alternative and not put a text/calendar message in front of a
> user.

Actually, who knows what mail processors (e.g. recoding done by several mail 
servers!) will do if they encounter broken UTF-8 bytes, because line folding 
happened in between the bytes of a multi-byte character? If they try to "fix" 
the UTF-8, they actually mess up the calendar attachment.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Wed, 20 Sep 2006 17:30:13 +0200
From: Eliot Lear <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Cc: [email-masked]

Again, chair hat off.

Oliver Block wrote:
> Am Dienstag, 19. September 2006 11:22 schrieb Eliot Lear:
>   
>> <Chair Hat Off>
>>     
>
>   
>>     * The concern is only for those who are attempting to read the
>>       calendar information in a text based mailer,
>>     
>
> Actually it is for everybody who wants to produce well-formed UTF-8.
>   

But nobody will care unless they're looking at the raw message.  Yes,
it's malformed, but then it's not really meant to be represented.  What
really should be happening is that implementations should use MIME
multipart/alternative and not put a text/calendar message in front of a
user.

>   
>> Hence, relaxing of folding is perhaps not advisable.
>>     
>
>   
>>    2. Add a sentence as follows: "It is possible for very simple
>>       implementations to have improperly folded lines in the middle of
>>       UTF-8 characters.  In such cases, implementations SHOULD unfold
>>       lines in such a way to properly restore the character.
>>     
>
> Would you want to add this to the old text or to one of the new proposals?
>   
Old text.

Ok, WG chair hat on:

Don't forget that if you have an alternative please present it.  If I
missed it I apologize in advance.

Eliot

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 1: new proposed text
Date: Wed, 20 Sep 2006 17:22:31 +0200

Am Dienstag, 19. September 2006 11:22 schrieb Eliot Lear:
> <Chair Hat Off>

>     * The concern is only for those who are attempting to read the
>       calendar information in a text based mailer,

Actually it is for everybody who wants to produce well-formed UTF-8.

> Hence, relaxing of folding is perhaps not advisable.

>    2. Add a sentence as follows: "It is possible for very simple
>       implementations to have improperly folded lines in the middle of
>       UTF-8 characters.  In such cases, implementations SHOULD unfold
>       lines in such a way to properly restore the character.

Would you want to add this to the old text or to one of the new proposals?

Best Regards,

Oliver

-- 
Leben ist mehr als ...
http://www.nak-nrw.de/p_6_4.html

Date: Tue, 19 Sep 2006 12:24:25 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Should all iCalendar tokens be considered as	iana-token?

Actually, section 4.6.6 Alarm Component explicitly states:

 > The "VALARM" calendar component MUST only appear within either a
 > "VEVENT" or "VTODO" calendar component.

Sorry!

Cheers,
Bernard

Bernard Desruisseaux wrote:
> Should the tokens defined in the iCalendar specification be
> considered as iana-token?
> 
> If yes, that would imply that VALARM components can be specified
> within VCALENDAR objects given that VCALENDAR objects can specify
> iana-comp.
> 
> One could argue that as long as the VALARM component defines a
> TRIGGER with an absolute date/time value there is no issue, but
> is that something we want to allow?
> 
> Cheers,
> Bernard

Date: Tue, 19 Sep 2006 11:47:52 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Sections 4.2.6, 4.8.4.1, 4.8.4.2, and 4.8.4.3: Bad LDAP URL in examples

The LDAP URLs specified in the examples of section 4.2.6, 4.8.4.1,
4.8.4.2, and 4.8.4.3 are all broken.  They are missing a '?' character
and they partially escape the '=' character in quoted-printable...

For instance, the LDAP URL in section 4.2.6 should be change from:

    ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS??
     (cn=3DBJim%20Dolittle)":MAILTO:[email-masked]

to:

    ORGANIZER;DIR="ldap://host.com:6666/o=ABC%20Industries,c=US???
     (cn=Jim%20Dolittle)":MAILTO:[email-masked]

Cheers,
Bernard

Date: Tue, 19 Sep 2006 11:31:36 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Should all iCalendar tokens be considered as iana-token?

Should the tokens defined in the iCalendar specification be
considered as iana-token?

If yes, that would imply that VALARM components can be specified
within VCALENDAR objects given that VCALENDAR objects can specify
iana-comp.

One could argue that as long as the VALARM component defines a
TRIGGER with an absolute date/time value there is no issue, but
is that something we want to allow?

Cheers,
Bernard

Date: Tue, 19 Sep 2006 11:21:25 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.8.1 Non-standard Properties: Parameters allowed on x-prop

In section 4.8.8.1 Non-standard Properties of RFC 2445 it says:

 > The data type for this property
 > is TEXT. Optionally, the data type can be any of the other valid data
 > types.
 >
 > Format Definition: The property is defined by the following notation:
 >
 >  x-prop     = x-name *(";" xparam) [";" languageparam] ":" text CRLF
 >     ; Lines longer than 75 octets should be folded

In my opinion x-prop should allow any parameter defined by iCalendar
as well as any iana-param.  There is no reason to invent an xparam
if there already exists a parameter that can be used.

While "the data type [of an x-prop] can be any of the other valid data
type", one would currently not be allowed to specify the VALUE parameter
to specify the value type of the property. Here's an example, found on
the web, that I believe should be valid:

   X-WD-NEXT-ALARM;VALUE=DATE-TIME:20040927T153000

[ Actually, this example would still be invalid since WinDate didn't use
a "vendor identification" of at least 3 characters. See the vendorid
rule in section 4.1 Content Lines. ]

Cheers,
Bernard

Date: Tue, 19 Sep 2006 10:31:22 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.6 Alarm Component: Restriction over the value of the ACTION property

According to section 4.8.6.1 Action of RFC 2445, the ACTION property
can take the following values:

 > actionvalue        = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
 >                    / iana-token / x-name

On the other hand, section 4.6.6 Alarm Component restricts the values
that the ACTION property can take when used in a VALARM component to
the following: AUDIO, DISPLAY, EMAIL, and PROCEDURE. Check the last
sentence of the following paragraph:

 > The "ACTION" property is used within the "VALARM" calendar component
 > to specify the type of action invoked when the alarm is triggered.
 > The "VALARM" properties provide enough information for a specific
 > action to be invoked. It is typically the responsibility of a
 > "Calendar User Agent" (CUA) to deliver the alarm in the specified
 > fashion. An "ACTION" property value of AUDIO specifies an alarm that
 > causes a sound to be played to alert the user; DISPLAY specifies an
 > alarm that causes a text message to be displayed to the user; EMAIL
 > specifies an alarm that causes an electronic email message to be
 > delivered to one or more email addresses; and PROCEDURE specifies an
 > alarm that causes a procedure to be executed. The "ACTION" property
 > MUST specify one and only one of these values.

In my opinion, one should be allowed to specify an ACTION property
with a "iana-token" or "x-name" value in a VALARM component.

A vendor might want to use "x-name" values (or register iana-token)
for alarms that should be delivered by SMS, XMPP, Fax, Voice, etc.

Cheers,
Bernard

Date: Tue, 19 Sep 2006 09:00:06 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.8.5.4 Recurrence Rule: Allowed value type of DTSTART and DTEND

Section 4.3.5 Date-Time of RFC 2445 defines 3 forms for DATE-TIME
values, that is:

   FORM #1: DATE WITH LOCAL TIME

   FORM #2: DATE WITH UTC TIME

   FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE

In section 4.8.5.4 Recurrence Rule of RFC 2445 it says:

 > The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
 > property pair, specified within the iCalendar object defines the
 > first instance of the recurrence. When used with a recurrence rule,
 > the "DTSTART" and "DTEND" properties MUST be specified in local time
 > and the appropriate set of "VTIMEZONE" calendar components MUST be
 > included. For detail on the usage of the "VTIMEZONE" calendar
 > component, see the "VTIMEZONE" calendar component definition.

My understanding is:

- The DTSTART property in a STANDARD or DAYLIGHT sub-component of
   a VTIMEZONE component MUST be of FORM #1 (DATE WITH LOCAL TIME)
   [See section 4.6.5 Time Zone Component];

- The DTSTART property in a VEVENT, VTODO or VJOURNAL component
   MUST be either a DATE value or a DATE-TIME value of FORM #1
   (DATE WITH LOCAL TIME) or FORM #3 (DATE WITH LOCAL TIME AND
   TIME ZONE REFERENCE).

As such, the text should be clarified to specify that DTSTART and
DTEND MUST be specified as a DATE or as a DATE-TIME of FORM #1
(DATE WITH LOCAL TIME) or FORM #3 (DATE WITH LOCAL TIME AND TIME
ZONE REFERENCE).

All that being said, I would like to point out that in section 4.4.2
Modify A Recurring Instance of RFC 2446 (iTIP) there is an example
of a DTSTART value specified in FORM #2 (DATE WITH UTC TIME) used
with a recurrence rule. My understanding is that this is not valid.

Cheers,
Bernard

Date: Tue, 19 Sep 2006 11:22:30 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 1: new proposed text

<Chair Hat Off>

Having tried to understand the value of any change to the text, I have
the following observations:

    * The concern is only for those who are attempting to read the
      calendar information in a text based mailer, and impacts
      approximately one glyph.  This is a very limited constituency and
      of very limited impact.
    * The text ALREADY says that folding occur between any two
      characters.  That means you should continue to emit legal UTF-8 if
      you are emitting UTF-8 at all.
    * However, my own (admittedly braindamaged) code implements folding
      at a very low level, as folding is one of the last operations to
      take place.
    * I suspect I'm not the only one who has written such brain damaged
      code.
    * After *unfolding* any potential damage should be undone.
    * The amount of code required to fold or unfold text is pretty darn
      minimal.
    * Much of it is already written.

Hence, relaxing of folding is perhaps not advisable.

I  have two recommendations for textual changes to RFC 2445:

   1. Delete the second sentence in the 2nd paragraph after the example
      in 4.1 as redundant (it says the exact same thing in the first
      paragraph);
   2. Add a sentence as follows: "It is possible for very simple
      implementations to have improperly folded lines in the middle of
      UTF-8 characters.  In such cases, implementations SHOULD unfold
      lines in such a way to properly restore the character.

Eliot

Date: Fri, 15 Sep 2006 14:23:14 -0400
From: Simon Pilette <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Section 4.6.4 Free/Busy Component, bad example 

In section 4.6.4 Free/Busy Component of RFC 2445, there
is an example that makes use of the VALUE parameter on
the FREEBUSY property:

 > FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M,
 >  19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M

According to the ABNF specified in section 4.8.2.6 Free/Busy
Time, the FREEBUSY property does not allow the VALUE parameter.

The example should be fixed.

Simon Pilette

Date: Fri, 15 Sep 2006 09:36:28 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Paterson <[email-masked]>
Subject: Re: [Ietf-calsify] Overlapping reschedule
Cc: [email-masked]

Hi Mark,

--On September 15, 2006 9:25:48 AM -0400 Mark Paterson 
<[email-masked]> wrote:

> 3) certainly seems like an interesting possibility.

>>
>> 3) Extend iTIP to allow the organizer to specify a list of UIDs of
>> events that should be excluded from any busy time results returned in
>> the reply. The organizer could then supply the original event UID and
>> the attendees' clients would exclude that from busy. This would work
>> for any attendee state and recurring meetings (though we would
>> probably have to send UID + list of Recurrence-IDs to handle
>> reschedule of exceptions). However it is an extension to iTIP.

Having thought about this some more I realize that there is a security 
concern with this. At the very least the 'ignored UIDs' list must refer to 
components whose ORGANIZER property is the same as the ORGANIZER in the 
free-busy request. So the entity doing the free-busy lookup MUST check the 
ORGANIZER properties before ignoring an event.

-- 
Cyrus Daboo

Date: Fri, 15 Sep 2006 09:25:48 -0400
From: Mark Paterson <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Overlapping reschedule
Cc: [email-masked]

3) certainly seems like an interesting possibility.

Cyrus Daboo wrote:
> Hi folks,
> Lets assume an organizer has booked an event with one or more 
> attendees for 12:00 pm to 1:00 pm. The organizer then wants to 
> reschedule that to 12:30 pm to 1:30 pm. If the organizer does an iTIP 
> VFREEBUSY REQUEST for the new time range the attendees will show up as 
> busy for the first half hour because of the existing booked event. 
> There are several solutions to this:
>
> 1) The organizer needs to 'subtract' the original event's time from 
> any busy time it gets back from the iTIP request (i.e. effectively 
> overriding when the attendees report as being busy). This seems 
> reasonable if the attendee had previous accepted the meeting (and had 
> not deliberately double-booked), but if they had not accepted it may 
> be wrong to do. This method would work for recurring events.
>
> 2) The organizer only issues the free-busy request for the second half 
> hour period of the new meeting. Well that would work in this case, but 
> if the new meeting had been 11 am - 2 pm (i.e. new time required both 
> before and after the original) then two requests would have to be 
> done. Plus it gets worse for recurring events. The same issue with 
> accepted attendees would apply.
>
> 3) Extend iTIP to allow the organizer to specify a list of UIDs of 
> events that should be excluded from any busy time results returned in 
> the reply. The organizer could then supply the original event UID and 
> the attendees' clients would exclude that from busy. This would work 
> for any attendee state and recurring meetings (though we would 
> probably have to send UID + list of Recurrence-IDs to handle 
> reschedule of exceptions). However it is an extension to iTIP.
>
> 4) Organizer first cancels the original meeting and then does free 
> busy lookup. This is not good as the cancel operation may require the 
> attendees' manual intervention to accept, whereas the free-busy lookup 
> may complete faster (c.f. CalDAV where free busy iTIP operations 
> execute immediately, whereas others require explicit acceptance from 
> the attendee).
>
> Any thoughts on this?
>

-- 
MARK PATERSON
Product Manager, OCS Mobility
Oracle Corporation - Server Technologies

Phone:  514.905.8649
Mobile: 514.862.8505
mailto: [email-masked]
http:   www.oracle.com

Date: Thu, 14 Sep 2006 14:08:27 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Overlapping reschedule

Hi folks,
Lets assume an organizer has booked an event with one or more attendees for 
12:00 pm to 1:00 pm. The organizer then wants to reschedule that to 12:30 
pm to 1:30 pm. If the organizer does an iTIP VFREEBUSY REQUEST for the new 
time range the attendees will show up as busy for the first half hour 
because of the existing booked event. There are several solutions to this:

1) The organizer needs to 'subtract' the original event's time from any 
busy time it gets back from the iTIP request (i.e. effectively overriding 
when the attendees report as being busy). This seems reasonable if the 
attendee had previous accepted the meeting (and had not deliberately 
double-booked), but if they had not accepted it may be wrong to do. This 
method would work for recurring events.

2) The organizer only issues the free-busy request for the second half hour 
period of the new meeting. Well that would work in this case, but if the 
new meeting had been 11 am - 2 pm (i.e. new time required both before and 
after the original) then two requests would have to be done. Plus it gets 
worse for recurring events. The same issue with accepted attendees would 
apply.

3) Extend iTIP to allow the organizer to specify a list of UIDs of events 
that should be excluded from any busy time results returned in the reply. 
The organizer could then supply the original event UID and the attendees' 
clients would exclude that from busy. This would work for any attendee 
state and recurring meetings (though we would probably have to send UID + 
list of Recurrence-IDs to handle reschedule of exceptions). However it is 
an extension to iTIP.

4) Organizer first cancels the original meeting and then does free busy 
lookup. This is not good as the cancel operation may require the attendees' 
manual intervention to accept, whereas the free-busy lookup may complete 
faster (c.f. CalDAV where free busy iTIP operations execute immediately, 
whereas others require explicit acceptance from the attendee).

Any thoughts on this?

-- 
Cyrus Daboo

Date: Thu, 14 Sep 2006 07:48:28 +0200
From: Eliot Lear <[email-masked]>
To: Michiel van Leeuwen <[email-masked]>
Subject: Re: [Ietf-calsify] Re: Propose to close issues 37, 38, 39
Cc: [email-masked]

Michiel van Leeuwen wrote:
> Eliot Lear wrote:
>>     4.6.1 Event Component: eventprop
>>     
>>
>>  >  eventprop  = *(
>>  >
>>  >             ; the following are both REQUIRED,
>>  >             ; but MUST NOT occur more than once
>>  >
>>  >             dtstamp / dtstart / uid /
>
> The text speaks of 'both', while there are three items. Shouldn't that
> be 'all three' then?
>
> Michiel

Yes, this seems to be more appropriate.

Eliot

Date: Wed, 13 Sep 2006 16:38:18 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: Propose to close issues 37, 38, 39

On Wed, Sep 13, 2006 at 05:10:25PM -0400, Sandy Wills wrote:
> >>    4.6.1 Event Component: eventprop
> >>
> >> >  eventprop  = *(
> >> >
> >> >             ; the following are both REQUIRED,
> >> >             ; but MUST NOT occur more than once
> >> >
> >> >             dtstamp / dtstart / uid /
> The "both" refers to having two requirements, not to how many items are 
> on the list.

I thought the phrasing was a bit confusing, too. It might even be
ungrammatical, usually people say "both this AND that".

Anyhow, the "both" and the "but" are unncessary, may I suggest:

  "the following are REQUIRED and MUST NOT occur more than once"

This kind of text show up a lot, isn't it the same wording everywhere?

Cheers,
Sam

Date: Wed, 13 Sep 2006 17:10:25 -0400
From: Sandy Wills <[email-masked]>
Subject: Re: [Ietf-calsify] Re: Propose to close issues 37, 38, 39
To: [email-masked]
Cc: Michiel van Leeuwen <[email-masked]>

Michiel van Leeuwen wrote:

> Eliot Lear wrote:
> 
>>     4.6.1 Event Component: eventprop
>>     
>>
>>  >  eventprop  = *(
>>  >
>>  >             ; the following are both REQUIRED,
>>  >             ; but MUST NOT occur more than once
>>  >
>>  >             dtstamp / dtstart / uid /
> 
> 
> The text speaks of 'both', while there are three items. Shouldn't that 
> be 'all three' then?

The "both" refers to having two requirements, not to how many items are 
on the list.

<expansion>
The following list (no matter how long) has both of these requirements:
   A) all items in the list are REQUIRED, and
   B) each item MUST NOT occur more than once.
List items: dtstamp, dtstart, uid
</expansion>

-- 
Unable to locate coffee.
Operator halted.

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Wed, 13 Sep 2006 22:57:16 +0200
Lines: 15
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: Propose to close issues 37, 38, 39

Eliot Lear wrote:
> 	4.6.1 Event Component: eventprop
> 	
> 
>  >  eventprop  = *(
>  >
>  >             ; the following are both REQUIRED,
>  >             ; but MUST NOT occur more than once
>  >
>  >             dtstamp / dtstart / uid /

The text speaks of 'both', while there are three items. Shouldn't that 
be 'all three' then?

Michiel

Subject: Proposal for closing issue #4 (was: Re: [Ietf-calsify] RFC2445 Correction in rrule examples)
From: Aki Niemi <[email-masked]>
To: ext Sam Roberts <[email-masked]>
Organization: Nokia-NRC/Helsinki
Date: Tue, 12 Sep 2006 17:46:50 +0300
Cc: ietf-calsify <[email-masked]>

ma, 2006-05-29 kello 21:46 -0700, ext Sam Roberts kirjoitti:
> I found this in my notes:
> 
>    Everyday in January, for 3 years:
> 
>      DTSTART;TZID=US-Eastern:19980101T090000
>      RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z;
>       BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
>      or
>      RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1
> 
>      ==> (1998 9:00 AM EDT)January 1-31
>          (1999 9:00 AM EDT)January 1-31
>          (2000 9:00 AM EDT)January 1-31
> 
> !! (2000 9:00 AM EDT)January 31 is AFTER the until day (2000 9:00 am UTC) January 31

BTW, isn't EDT only supposed to be used during summer?

AFAICS, this example needs to be changed so that either the DTSTART or
the UNTIL needs to be adjusted, or the DTSTART be represented in UTC as
well. Let me take a stab at this:

       DTSTART;TZID=US-Eastern:19980101T090000
       RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z;
       BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
       or
       RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1

       ==> (1998 9:00 AM EST)January 1-31
           (1999 9:00 AM EST)January 1-31
           (2000 9:00 AM EST)January 1-31

With this, I'd like to propose closing this issue (#4 in the tracker).

Comments?

Cheers,
Aki

-- 
Aki Niemi
Nokia Research Center

Subject: Proposal to close issue #2 (was: Re: [Ietf-calsify] rfc 2445 - typo correction(s))
From: Aki Niemi <[email-masked]>
To: ext Bernard Desruisseaux <[email-masked]>
Organization: Nokia-NRC/Helsinki
Date: Tue, 12 Sep 2006 13:54:12 +0300
Cc: ietf-calsify <[email-masked]>

I believe we can close this issue (#2 in the tracker).

Cheers,
Aki

ti, 2006-08-29 kello 13:32 -0400, ext Bernard Desruisseaux kirjoitti:
> +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: Mon, 11 Sep 2006 17:21:06 -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, 12 Sep 2006, Oliver Block wrote:
> Am Montag, 11. September 2006 18:46 schrieb Mark Crispin:
>> This is a matter under discussion.
>> The text is in a [] pair since its
>> inclusion depends upon the decision of the WG.
> I would forget that. You can convert from charsets (e.g. ISO-8859) to UTF-8
> with acceptable effort. But adding the part in [] would multiply the effort.

Huh?  Any conversion from ISO 8859 to UTF-8 would not have any combining 
characters, since all ISO 8859 characters have precomposed equivalents in 
UTF-8.

-- 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, 12 Sep 2006 02:15:59 +0200

Am Montag, 11. September 2006 18:46 schrieb Mark Crispin:

> This is a matter under discussion.  
> The text is in a [] pair since its 
> inclusion depends upon the decision of the WG.

I would forget that. You can convert from charsets (e.g. ISO-8859) to UTF-8 
with acceptable effort. But adding the part in [] would multiply the effort. 

iCalendar requires valid UTF-8 and with the two texts that were proposed, it  
makes that clear enough. 

I would even prefer Bernards Version with 'charset' instead of 'character set' 
because it leaves some terms out, which make it better readable in my view. 
Marks Version is ahead of the times:) so it should be kept for the next 
iCal-WG. Or in other words: If you want to introduce new terms to this RFC, 
you should do with more than five sentences.

That's what I think.

Best Regards,

Oliver

-- 
Leben ist mehr ...
http://www.nak-nrw.de/p_6_4.html

Date: Mon, 11 Sep 2006 13:04:39 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Re: [Issue 1] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Sep 11, 2006 at 12:20:07PM -0700, Sam Roberts wrote:
> characters... or does it? Would a sequence of
> 
>   CAPITAL-A, LINE-FEED, SPACE, COMBINING TILDE, ...

Oops, attached utf-8, but don't know if attachments make it through to
the list.

% xxd __.out
0000000: 410a 20cc 802e 2e2e 0a                   A. ......

xxd -r will get it back.

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="__.out"
Content-Transfer-Encoding: 8bit

A
 ̀...

--+QahgC5+KEYLbs62--

Date: Mon, 11 Sep 2006 12:21:15 -0700
To: Reinhold Kainhofer <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP 		being optional(in the grammar)
Cc: [email-masked]

--============_-1054119635==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12:25 PM +0200 9/8/06, Reinhold Kainhofer wrote:
>If you now tomorrow publish that event to some other group of people or so
>(i.e. send a mail with METHOD:PUBLISH), the calendar that you send out will
>have the above CREATED and DATE-MODIFIED (provided that you didn't modify it
>meanwhile in the calendar store), but as that particular invitation will be
>created tomorrow, it will have
>DTSTAMP:20060910...
>
>So, these three settings are in deed different. The CREATED will never change
>once the event is by the organizer, the DATE-MODIFIED is only changed when
>you modify the event, and the DTSTAMP is the time when you create that
>particular invitation or export from the calendar server.

I'll grant it's possible for DTSTAMP and CREATED to differ.  I've 
just never seen it. :-)
The essential question I'm asking, are both attributes necessary?  I 
can see an argument for DTSTAMP (despite the way I began this 
thread), as it's useful for determining the order in which changes to 
an event should be applied.  However, no other attribute depends on 
CREATED.  In the interest of simplifying the protocol, 4.8.7.1 should 
be eliminated (and references to it, of course).  However I'd be 
happy if the text in 4.8.7.1 where changed from:

    Conformance: The property can be specified once in "VEVENT", "VTODO"
    or "VJOURNAL" calendar components.

to

Conformance: The property MAY be specified once in "VEVENT", "VTODO"
or "VJOURNAL" calendar components.  Absence of this parameter MUST 
NOT cause a CUA or CS (Calendar Service) to reject the calendar 
component specification.

That would make it clear the parameter is optional.
-- 

john noerenberg
   ----------------------------------------------------------------------
   It is treason to sacrifice love of truth, intellectual honesty,
   loyalty to the laws and methods of the mind, to any other interests,
   including those of one's country.
   -- Herman Hesse, The Glass Bead Game, 1943
   ----------------------------------------------------------------------
--============_-1054119635==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Ietf-calsify] Error in RFC 2445 regarding
DTSTAMP 		b</title></head><body>
<div>At 12:25 PM +0200 9/8/06, Reinhold Kainhofer wrote:</div>
<blockquote type="cite" cite>If you now tomorrow publish that event to
some other group of people or so<br>
(i.e. send a mail with METHOD:PUBLISH), the calendar that you send out
will<br>
have the above CREATED and DATE-MODIFIED (provided that you didn't
modify it<br>
meanwhile in the calendar store), but as that particular invitation
will be<br>
created tomorrow, it will have<br>
DTSTAMP:20060910...<br>
</blockquote>
<blockquote type="cite" cite>So, these three settings are in deed
different. The CREATED will never change<br>
once the event is by the organizer, the DATE-MODIFIED is only changed
when<br>
you modify the event, and the DTSTAMP is the time when you create
that</blockquote>
<blockquote type="cite" cite>particular invitation or export from the
calendar server.</blockquote>
<div><br></div>
<div>I'll grant it's possible for DTSTAMP and CREATED to differ.&nbsp;
I've just never seen it. :-)</div>
<div>The essential question I'm asking, are both attributes
necessary?&nbsp; I can see an argument for DTSTAMP (despite the way I
began this thread), as it's useful for determining the order in which
changes to an event should be applied.&nbsp; However, no other
attribute depends on CREATED.&nbsp; In the interest of simplifying the
protocol, 4.8.7.1 should be eliminated (and references to it, of
course).&nbsp; However I'd be happy if the text in 4.8.7.1 where
changed from:</div>
<div><br></div>
<blockquote>&nbsp;&nbsp; Conformance: The property can be specified
once in &quot;VEVENT&quot;, &quot;VTODO&quot;</blockquote>
<blockquote>&nbsp;&nbsp; or &quot;VJOURNAL&quot; calendar
components.</blockquote>
<blockquote><br></blockquote>
<div>to</div>
<blockquote><br></blockquote>
<blockquote>Conformance: The property MAY be specified once in
&quot;VEVENT&quot;, &quot;VTODO&quot;</blockquote>
<blockquote>or &quot;VJOURNAL&quot; calendar components.&nbsp; Absence
of this parameter MUST NOT cause a CUA or CS (Calendar Service) to
reject the calendar component specification.</blockquote>
<blockquote><br></blockquote>
<div>That would make it clear the parameter is optional.</div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div><br>
john noerenberg<br>
&nbsp;
----------------------------------------------------------------------<br
&nbsp; It is treason to sacrifice love of truth, intellectual
honesty,<br>
&nbsp; loyalty to the laws and methods of the mind, to any other
interests,<br>
&nbsp; including those of one's country.<br>
&nbsp; -- Herman Hesse, The Glass Bead Game, 1943<br>
&nbsp;
----------------------------------------------------------------------</div
</body>
</html>
--============_-1054119635==_ma============--

Date: Mon, 11 Sep 2006 12:20:07 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Re: [Issue 1] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8

On Mon, Sep 11, 2006 at 09:46:38AM -0700, Mark Crispin wrote:
> On Mon, 11 Sep 2006, Sam Roberts wrote:
> >Quoting [email-masked], on Sat, Sep 02, 2006 at 12:29:25PM +0200:
> >>Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin:
> >>>Therefore, a better wording is:
> >>>----------------------------------------------------------------------
> >>>Folded lines MUST be well-formed according to the character set specified
> >>>for the iCalendar object.  Folding MUST NOT occur between octets that
> >>>define a single codepoint in a character set that uses multiple octets to
> >>>define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian
> >>>character sets).  [Furthermore, folding MUST NOT occur prior to a
> >>>codepoints that defines a combining character.]  This may require
> >>>folding a line at less than the recommended 75 octet limit.
> >>>----------------------------------------------------------------------
> >Is the "[Furthermore,...combining character.]" text supposed to be part
> >of the the wording?
> 
> This is a matter under discussion.  The text is in a [] pair since its 
> inclusion depends upon the decision of the WG.

Ok.

> >It appears that there are combining characters defined in many blocks of
> >unicode characters.
> > http://www.unicode.org/faq/char_combmark.html
> >How do I determine that a code point defines a combining character? Is
> >there a list of such code-points?
> 
> You don't determine combining character by codepoint value.  You determine 
> it by the codepoint's Canonical Combining Class value, as defined in the 
> UnicodeData.txt file.  Characters with a Canonical Combining Class value 
> of 0 are not combining characters.

Thanks.

An application would probably not include the 1038607 byte
UnicodeData.txt file [1], it could just have knowledge of the current
(418, by my count) combining characters.

Would that application then become non-conformant with the MUST NOT
under discussion when a new combining character is added to Unicode and
the application isn't updated? Or would we pin iCalendar to a particular
Unicode version? (or whatever they call the currently defined codepoints
and combining classes, if they don't call it a "unicode version")

I think its worth clarifying why folding in the middle of multi-byte
sequences for either a "character" or a "grapheme" may not be
desireable. As I understand it, one reason that has been mentioned is if
the data is folded it can no longer be called valid "utf-8" (for
example). This doesn't matter to an iCalendar application which will
unfold before processing, but would matter to, for example, a mail
application which didn't know how to process the calendar, and was
trying to display it to the user as plain text.

I think the bigger issue is that in order to unfold, you need to find
the line endings. The line endings themselves are encoded as a
"character", possibly multi-byte (in UTF-16, for example). So, a certain
amount of well-formedness is necessary in order to unfold a calendar.
If a long line in UCS-16 was broken in the middle of a UTF-16 codepoint,
and a LINE-FEED, SPACE was added in UTF-16, it would probably be
difficult or impossible to parse.

The necessity of being well-formed enough to unfold the data doesn't
seem to mean that we need to forbid folding between combining
characters... or does it? Would a sequence of

  CAPITAL-A, LINE-FEED, SPACE, COMBINING TILDE, ...

make the SPACE appear to be a "space with a tilde over it" (!) with
some programming languages, thus making it not possible to find the
LINE-FEED, SPACE sequence which needs to be removed during unfolding?

In the languages I work in, finding "codepoints" is no trouble, and
wrapping between codepoints that are part of combining sequences is no
trouble, and the wrapped calendar might have a few "odd" looking bits
when sequences like my example above are viewed in a unicode supporting
terminal (see attached), but thats not a problem for unfolding.

Are there iCalendar implementations out there (real or suspected) that
will fail to interoperate when lines are wrapped between combining
codepoints?

If the goal here is to tighten up the spec to improve interop, and its
not an interop issue, I'd say document that:

- line wrapping SHOULD (MUST?) occur before XX bytes,
- wrapping MUST NOT break a codepoint (if the character set being used
  represents a code-point as more than one byte), and
- that wrapping MAY occur between combining codepoints, and
  move on.

Also, unless I misunderstand, pathological unicode (or maybe not
pathological, just a complex musical score, they use combining
characters a lot) could contain a grapheme consisting of an abitrarily
long sequence of codepoints, so a MUST NOT break between combining
characters rule might be mutually exclusive with a rule that lines MUST
NOT be over a particular byte-length.

Cheers,
Sam

[1]   http://www.unicode.org/Public/UNIDATA/UnicodeData.txt 

Date: Mon, 11 Sep 2006 09:46:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Sam Roberts <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: [email-masked]

On Mon, 11 Sep 2006, Sam Roberts wrote:
> Quoting [email-masked], on Sat, Sep 02, 2006 at 12:29:25PM +0200:
>> Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin:
>>> Therefore, a better wording is:
>>> ----------------------------------------------------------------------
>>> Folded lines MUST be well-formed according to the character set specified
>>> for the iCalendar object.  Folding MUST NOT occur between octets that
>>> define a single codepoint in a character set that uses multiple octets to
>>> define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian
>>> character sets).  [Furthermore, folding MUST NOT occur prior to a
>>> codepoints that defines a combining character.]  This may require
>>> folding a line at less than the recommended 75 octet limit.
>>> ----------------------------------------------------------------------
> Is the "[Furthermore,...combining character.]" text supposed to be part
> of the the wording?

This is a matter under discussion.  The text is in a [] pair since its 
inclusion depends upon the decision of the WG.

> It appears that there are combining characters defined in many blocks of
> unicode characters.
>  http://www.unicode.org/faq/char_combmark.html
> How do I determine that a code point defines a combining character? Is
> there a list of such code-points?

You don't determine combining character by codepoint value.  You determine 
it by the codepoint's Canonical Combining Class value, as defined in the 
UnicodeData.txt file.  Characters with a Canonical Combining Class value 
of 0 are not combining characters.

-- 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, 11 Sep 2006 09:38:48 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Sat, Sep 02, 2006 at 12:29:25PM +0200:
> Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin:
> > Therefore, a better wording is:
> > ----------------------------------------------------------------------
> > Folded lines MUST be well-formed according to the character set specified
> > for the iCalendar object.  Folding MUST NOT occur between octets that
> > define a single codepoint in a character set that uses multiple octets to
> > define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian
> > character sets).  [Furthermore, folding MUST NOT occur prior to a
> > codepoints that defines a combining character.]  This may require
> > folding a line at less than the recommended 75 octet limit.
> > ----------------------------------------------------------------------

Is the "[Furthermore,...combining character.]" text supposed to be part
of the the wording?

It appears that there are combining characters defined in many blocks of
unicode characters.

  http://www.unicode.org/faq/char_combmark.html

How do I determine that a code point defines a combining character? Is
there a list of such code-points?

Cheers,
Sam

Date: Fri, 8 Sep 2006 09:45:46 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Propose to close issue 36 - X-Name / bilateral agreements

On Fri, Sep 08, 2006 at 12:15:12PM +0200, Eliot Lear wrote:
> No consensus for change as of now.
> 
> Barring more discussion, the text will remain unchanged, without
> reference to bilateral agreements.

What X- fields mean and whether to allow them was beat to a bloody death
during rfc2822, but they got rid of X- fields, so iCal can't copy their
text!

I don't want to keep the issue open if the consensus is that te text is
fine, but I think including recommendations on use of a feature is
helpful for interoperability, so can I propose:

  Vendor-defined names may appear in iCalendar by using a naming pattern
  guaranteed not to conflict with any names that may be standardized in
  the future. There is no registry for vendorid, so there is no
  guarantee names defined by one vendor won't conflict with names
  defined by another.

I think that describes why it's here, and you/we could perhaps add some
guidance:

  Vendors SHOULD NOT use vendor-defined names in iTIP, it discourages
  inter-operability. If a vendor finds it necessary to extend iCal with
  vendor-defined names, it is recommended to submit a <RFC? how do you
  say this?> to the <IETF??> to standardize this usage with a non-vendor
  defined name. Some vendors use iCalendar as a internal storage
  format, and vendor-defined names are useful in this context, but
  SHOULD be removed before exchanging the calendars with other
  implementations.

I think the above is the "well-known understanding" of X- fields, if the
list agrees, I'd like to see it written down.

I don't like the use of "vendor", btw, what if the implementation
isn't vended? :-) How about s/vendor/implementation/g?

Cheers,
Sam

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

Date: Fri, 08 Sep 2006 13:20:19 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Propose Close Issue 35: 4.2.10 language tag

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

This issue has proposed text and there has been no objection.

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.

--------------020200060709050909030508
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">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
This issue has proposed text and there has been no objection.<br>
<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
  <tbody>
    <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.</td>
    </tr>
  </tbody>
</table>
<br>
</body>
</html>

--------------020200060709050909030508--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP =?iso-8859-1?q?=09being?= optional(in the grammar)
Date: Fri, 8 Sep 2006 12:25:36 +0200

Am Freitag, 8. September 2006 02:52 schrieb John W Noerenberg II:
> At 7:31 PM -0400 9/7/06, Tim Hare wrote:
> >RFC2445 has this to say about DTSTAMP, and about its use  vs.
> >CREATED and DATE-MODIFIED
>
> I know what the RFC says. :-)  My point is the definitions (despite
> the RFC's claim to the contrary) are indistinguishable.  In practice
> both CREATED and DTSTAMP invariably have the same value.  

Sorry, but that's not true. If I created an event yesterdayday, sent out an 
invitation and today get some confirmations back, the event will have 
CREATED:20060908....
DATE-MODIFIED:20060909...
(Explanation: The event was created yesterday in the storage (which might 
either be a flat file, a groupware server or something else), and it was 
modified today, which does not create a new event.)

If you now tomorrow publish that event to some other group of people or so 
(i.e. send a mail with METHOD:PUBLISH), the calendar that you send out will 
have the above CREATED and DATE-MODIFIED (provided that you didn't modify it 
meanwhile in the calendar store), but as that particular invitation will be 
created tomorrow, it will have
DTSTAMP:20060910...

So, these three settings are in deed different. The CREATED will never change 
once the event is by the organizer, the DATE-MODIFIED is only changed when 
you modify the event, and the DTSTAMP is the time when you create that 
particular invitation or export from the calendar server.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Fri, 08 Sep 2006 12:15:12 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Propose to close issue 36 - X-Name / bilateral agreements

No consensus for change as of now.

Barring more discussion, the text will remain unchanged, without
reference to bilateral agreements.

Eliot

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.

Date: Fri, 08 Sep 2006 12:12:54 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] request for more discussion on issue 40

At this time the issue is open and there is no consensus on text.  If no
discussion occurs we will close the issue without changes to text.

Eliot

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.

Date: Fri, 08 Sep 2006 12:11:30 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Propose to close issues 37, 38, 39

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

Each of these issues has proposed text and there has been no objection
to it.

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.

--------------060603060300080503050306
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">
Each of these issues has proposed text and there has been no objection
to it.<br>
<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
  <tbody>
    <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>
  </tbody>
</table>
<br>
</body>
</html>

--------------060603060300080503050306--

Date: Fri, 08 Sep 2006 12:06:26 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] a message from the chairs

Hello everyone,

I would like to again direct your attention to
http://www.ofcourseimright.com/cgi-bin/roundup/calsify.  These are the
open issues for RFC2445bis.  To move things along, Aki and I are going
to sift through each issue to see what is needed to resolve them.  Aki
will start at the top issue (number 1) and I will start at the bottom
(currently #40) and we will work our way towards each other.

Depending on mailing list content, we will take one of several actions:

   1. Close the issue because Bernard has dealt with it;
   2. Propose the issue be closed if there is no text;
   3. Propose the issue be closed if there is text but no discussion; or
   4. Encourage conclusion of discussion so we can close an issue that
      has both text and discussion.

Any issue can be moved to state (4) with proposal of text, based on a
reply to our messages.  If there is no text to discuss then it is
pointless to argue the issue.  Anyone can open a new issue - FOR NOW. 
We would like WGLC to not be too far away.

There are some overlapping issues in the tracker.  I beg your indulgence
to help me find these and to suggest an appropriate action.

On behalf of Aki, thanks for your participation!

Eliot

Date: Thu, 7 Sep 2006 17:52:01 -0700
To: "Tim Hare" <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: RE: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP 	being optional(in the grammar)
Cc: 'CALSIFY Mailinglist' <[email-masked]>

At 7:31 PM -0400 9/7/06, Tim Hare wrote:
>
>RFC2445 has this to say about DTSTAMP, and about its use  vs. 
>CREATED and DATE-MODIFIED

I know what the RFC says. :-)  My point is the definitions (despite 
the RFC's claim to the contrary) are indistinguishable.  In practice 
both CREATED and DTSTAMP invariably have the same value.  It's 
pointless redundancy.  One or the other should go.

If DTSTAMP is needed for backward compatibility then keep that 
instead and deprecate CREATED.

From: "Tim Hare" <[email-masked]>
To: "'CALSIFY Mailinglist'" <[email-masked]>
Subject: RE: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being	optional(in the grammar)
Date: Thu, 7 Sep 2006 19:31:42 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C6D2B4.3FDC5B70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

RFC2445 has this to say about DTSTAMP, and about its use  vs. CREATED and
DATE-MODIFIED
 
-------------------------------------------------------- snip
--------------------------------------------------------------------
Conformance: This property MUST be included in the "VEVENT", "VTODO",

   "VJOURNAL" or "VFREEBUSY" calendar components.

   Description: The value MUST be specified in the UTC time format.

   This property is also useful to protocols such as [IMIP] that have

   inherent latency issues with the delivery of content. This property

   will assist in the proper sequencing of messages containing iCalendar

   objects.

   This property is different than the "CREATED" and "LAST-MODIFIED"

   properties. These two properties are used to specify when the

   particular calendar data in the calendar store was created and last

   modified. This is different than when the iCalendar object

   representation of the calendar service information was created or

   last modified.
-------------------------------------------------------- snip
--------------------------------------------------------------------
 
Also I seem to remember that DTSTAMP is used in iMIP and iTIP to determine
the winner in a multiple-updates-received-not-necessarily-in-order scenario.
I don't think it can be deprecated without understanding its use in those
areas.
 
Tim Hare
Interested Bystander, Non-Inc.

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Robert Ransdell
Sent: Thursday, September 07, 2006 7:18 PM
To: John W Noerenberg II
Cc: CALSIFY Mailinglist; [email-masked]
Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being
optional(in the grammar)

you will break backward compatibility if you remove DTSTAMP.  Its equivalent
to Posted Date. 

John W Noerenberg II <[email-masked]> 
Sent by: [email-masked] 

09/07/2006 07:08 PM 

To
Jeffrey Harris <[email-masked]> 

cc
CALSIFY Mailinglist <[email-masked]> 

Subject
Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being        optional
(in the grammar)

At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote:
>Given that the RFC was confused, I'd like to put in a vote in favor of
>choosing optional for DTSTAMP, not MUST.  Lots of iCalendar in the wild
>doesn't have a DTSTAMP, and I don't see a compelling reason for
>requiring it (although I'd be happy to be informed of compelling reasons).

Heck, I'd love to see DTSTAMP's use deprecated.  I don't buy there's 
sufficient difference between CREATED and DTSTAMP to necessitate two 
different attributes.
-- 

john noerenberg
  ----------------------------------------------------------------------
  It is treason to sacrifice love of truth, intellectual honesty,
  loyalty to the laws and methods of the mind, to any other interests,
  including those of one's country.
  -- Herman Hesse, The Glass Bead Game, 1943
  ----------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

------=_NextPart_000_0028_01C6D2B4.3FDC5B70
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>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D805252523-07092006>RFC2445 has this to say about DTSTAMP, and =
about its=20
use &nbsp;vs. CREATED and DATE-MODIFIED</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D805252523-07092006><FONT face=3DArial=20
size=3D2>-------------------------------------------------------- snip=20
--------------------------------------------------------------------</FON=
T></SPAN></DIV>
<DIV><SPAN class=3D805252523-07092006><FONT face=3DArial =
size=3D2><PRE>Conformance: This property MUST be included in the =
"VEVENT", "VTODO",
   "VJOURNAL" or "VFREEBUSY" calendar components.

   Description: The value MUST be specified in the UTC time format.

   This property is also useful to protocols such as [IMIP] that have
   inherent latency issues with the delivery of content. This property
   will assist in the proper sequencing of messages containing iCalendar
   objects.

   This property is different than the "CREATED" and "LAST-MODIFIED"
   properties. These two properties are used to specify when the
   particular calendar data in the calendar store was created and last
   modified. This is different than when the iCalendar object
   representation of the calendar service information was created or
   last modified.</PRE></FONT></SPAN></DIV>
<DIV align=3Dleft><SPAN class=3D805252523-07092006><FONT face=3DArial=20
size=3D2>-------------------------------------------------------- snip=20
--------------------------------------------------------------------</FON=
T></SPAN></DIV>
<DIV align=3Dleft><SPAN class=3D805252523-07092006><FONT=20
face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV align=3Dleft><SPAN class=3D805252523-07092006><FONT =
face=3DArial><FONT=20
size=3D2>Also I seem to remember that DTSTAMP is used in iMIP and iTIP =
to=20
determine the winner in a =
multiple-updates-received-not-necessarily-in-order=20
scenario</FONT>.</FONT></SPAN></DIV>
<DIV align=3Dleft><SPAN class=3D805252523-07092006><FONT face=3DArial =
size=3D2>I don't=20
think it can be deprecated without understanding its use in those=20
areas.</FONT></SPAN></DIV>
<DIV align=3Dleft><FONT face=3DArial 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>
<DIV>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of =
</B>Robert=20
Ransdell<BR><B>Sent:</B> Thursday, September 07, 2006 7:18 =
PM<BR><B>To:</B> John=20
W Noerenberg II<BR><B>Cc:</B> CALSIFY Mailinglist;=20
[email-masked]<BR><B>Subject:</B> Re: =
[Ietf-calsify]=20
Error in RFC 2445 regarding DTSTAMP being optional(in the=20
grammar)<BR></FONT><BR></DIV>
<DIV></DIV><BR><FONT face=3Dsans-serif size=3D2>you will break backward=20
compatibility if you remove DTSTAMP. &nbsp;Its equivalent to Posted =
Date.</FONT>=20
<BR><BR><BR><BR>
<TABLE width=3D"100%">
  <TBODY>
  <TR vAlign=3Dtop>
    <TD width=3D"40%"><FONT face=3Dsans-serif size=3D1><B>John W =
Noerenberg II=20
      &lt;[email-masked]&gt;</B> </FONT><BR><FONT face=3Dsans-serif =
size=3D1>Sent=20
      by: [email-masked]</FONT>=20
      <P><FONT face=3Dsans-serif size=3D1>09/07/2006 07:08 PM</FONT> =
</P>
    <TD width=3D"59%">
      <TABLE width=3D"100%">
        <TBODY>
        <TR vAlign=3Dtop>
          <TD>
            <DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>To</FONT></DIV>
          <TD><FONT face=3Dsans-serif size=3D1>Jeffrey Harris=20
            &lt;[email-masked]&gt;</FONT>=20
        <TR vAlign=3Dtop>
          <TD>
            <DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>cc</FONT></DIV>
          <TD><FONT face=3Dsans-serif size=3D1>CALSIFY Mailinglist=20
            &lt;[email-masked]&gt;</FONT>=20
        <TR vAlign=3Dtop>
          <TD>
            <DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>Subject</FONT></DIV>
          <TD><FONT face=3Dsans-serif size=3D1>Re: [Ietf-calsify] Error =
in RFC=20
            2445 regarding DTSTAMP being &nbsp; &nbsp; &nbsp; =
&nbsp;optional=20
            &nbsp; &nbsp; &nbsp; &nbsp; (in the=20
      grammar)</FONT></TR></TBODY></TABLE><BR>
      <TABLE>
        <TBODY>
        <TR vAlign=3Dtop>
          <TD>
          =
<TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><TT><FONT=20
size=3D2>At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote:<BR>&gt;Given =
that the RFC=20
was confused, I'd like to put in a vote in favor of<BR>&gt;choosing =
optional for=20
DTSTAMP, not MUST. &nbsp;Lots of iCalendar in the wild<BR>&gt;doesn't =
have a=20
DTSTAMP, and I don't see a compelling reason for<BR>&gt;requiring it =
(although=20
I'd be happy to be informed of compelling reasons).<BR><BR>Heck, I'd =
love to see=20
DTSTAMP's use deprecated. &nbsp;I don't buy there's <BR>sufficient =
difference=20
between CREATED and DTSTAMP to necessitate two <BR>different =
attributes.<BR>--=20
<BR><BR>john noerenberg<BR>&nbsp;=20
----------------------------------------------------------------------<BR=
>&nbsp;=20
It is treason to sacrifice love of truth, intellectual =
honesty,<BR>&nbsp;=20
loyalty to the laws and methods of the mind, to any other =
interests,<BR>&nbsp;=20
including those of one's country.<BR>&nbsp; -- Herman Hesse, The Glass =
Bead=20
Game, 1943<BR>&nbsp;=20
----------------------------------------------------------------------<BR=
>_______________________________________________<BR>Ietf-calsify=20
mailing=20
list<BR>[email-masked]<BR>http://lists.osafoundation.org/=
mailman/listinfo/ietf-calsify<BR></FONT></TT><BR></BODY></HTML>

------=_NextPart_000_0028_01C6D2B4.3FDC5B70--

To: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being	optional (in the grammar)
Date: Thu, 7 Sep 2006 19:18:21 -0400
From: "Robert Ransdell" <[email-masked]>
Cc: CALSIFY Mailinglist <[email-masked]>, [email-masked]

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

you will break backward compatibility if you remove DTSTAMP.  Its 
equivalent to Posted Date.

John W Noerenberg II <[email-masked]> 
Sent by: [email-masked]
09/07/2006 07:08 PM

To
Jeffrey Harris <[email-masked]>
cc
CALSIFY Mailinglist <[email-masked]>
Subject
Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being    optional 
(in the grammar)

At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote:
>Given that the RFC was confused, I'd like to put in a vote in favor of
>choosing optional for DTSTAMP, not MUST.  Lots of iCalendar in the wild
>doesn't have a DTSTAMP, and I don't see a compelling reason for
>requiring it (although I'd be happy to be informed of compelling 
reasons).

Heck, I'd love to see DTSTAMP's use deprecated.  I don't buy there's 
sufficient difference between CREATED and DTSTAMP to necessitate two 
different attributes.
-- 

john noerenberg
   ----------------------------------------------------------------------
   It is treason to sacrifice love of truth, intellectual honesty,
   loyalty to the laws and methods of the mind, to any other interests,
   including those of one's country.
   -- Herman Hesse, The Glass Bead Game, 1943
   ----------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--=_alternative 007FAAD6852571E2_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">you will break backward compatibility
if you remove DTSTAMP. &nbsp;Its equivalent to Posted Date.</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>John W Noerenberg II &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">09/07/2006 07:08 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">Jeffrey Harris &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 Mailinglist &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] Error in RFC 2445
regarding DTSTAMP being &nbsp; &nbsp; &nbsp; &nbsp;optional &nbsp;
&nbsp; &nbsp; &nbsp; (in the grammar)</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote:<br>
&gt;Given that the RFC was confused, I'd like to put in a vote in favor
of<br>
&gt;choosing optional for DTSTAMP, not MUST. &nbsp;Lots of iCalendar in
the wild<br>
&gt;doesn't have a DTSTAMP, and I don't see a compelling reason for<br>
&gt;requiring it (although I'd be happy to be informed of compelling reasons).<br>
<br>
Heck, I'd love to see DTSTAMP's use deprecated. &nbsp;I don't buy there's
<br>
sufficient difference between CREATED and DTSTAMP to necessitate two <br>
different attributes.<br>
-- <br>
<br>
john noerenberg<br>
 &nbsp; ----------------------------------------------------------------------<br>
 &nbsp; It is treason to sacrifice love of truth, intellectual honesty,<br>
 &nbsp; loyalty to the laws and methods of the mind, to any other interests,<br>
 &nbsp; including those of one's country.<br>
 &nbsp; -- Herman Hesse, The Glass Bead Game, 1943<br>
 &nbsp; ----------------------------------------------------------------------<br>
_______________________________________________<br>
Ietf-calsify mailing list<br>
[email-masked]<br>
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify<br>
</font></tt>
<br>
--=_alternative 007FAAD6852571E2_=--

Date: Thu, 7 Sep 2006 15:56:51 -0700
To: Jeffrey Harris <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional 	(in the grammar)
Cc: CALSIFY Mailinglist <[email-masked]>

At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote:
>Given that the RFC was confused, I'd like to put in a vote in favor of
>choosing optional for DTSTAMP, not MUST.  Lots of iCalendar in the wild
>doesn't have a DTSTAMP, and I don't see a compelling reason for
>requiring it (although I'd be happy to be informed of compelling reasons).

Heck, I'd love to see DTSTAMP's use deprecated.  I don't buy there's 
sufficient difference between CREATED and DTSTAMP to necessitate two 
different attributes.
-- 

john noerenberg
   ----------------------------------------------------------------------
   It is treason to sacrifice love of truth, intellectual honesty,
   loyalty to the laws and methods of the mind, to any other interests,
   including those of one's country.
   -- Herman Hesse, The Glass Bead Game, 1943
   ----------------------------------------------------------------------

To: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Sep 2006 11:59:07 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text
Cc: Mark Crispin <[email-masked]>, Calsify WG <[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.

This is a tricky point in MIME. The idea behind the text top-level type was in
part to support fallback display of textual material even when the specific
type isn't understood. To this end, text types are required to use the charset
parameter in a manner that's compatible with text/plain. text/plain uses the
charset parameter to specify the charset (duh) and has a default of US-ASCII.
See RFC 2046 section 4.1.2 for specifics.

In any case, RFC 2046 recommands but does not actually require that all text
types have the same default of US-ASCII. And pretty much the first other
text subtype, text/html, opted for iso-8859-1 as it's default. In retrospect
UTF-8 would have been a better choice for both text/plain and text/html, but
please remember that UTF-8 didn't even exist at the time this stuff was
defined.

So what's the right course of action? I think the right thing to do is
make the default UTF-8 but strongly recommend that the charset parameter
be present.

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

Nice but not really possible. See above.

				Ned

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Date: Sat, 2 Sep 2006 12:29:25 +0200

Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin:

> Therefore, a better wording is:
> ----------------------------------------------------------------------
> Folded lines MUST be well-formed according to the character set specified
> for the iCalendar object.  Folding MUST NOT occur between octets that
> define a single codepoint in a character set that uses multiple octets to
> define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian
> character sets).  [Furthermore, folding MUST NOT occur prior to a
> codepoints that defines a combining character.]  This may require
> folding a line at less than the recommended 75 octet limit.
> ----------------------------------------------------------------------
>
> The text in [] is used for interpretation (2) but not for interpretation
> (3).

This is quite elaborated. But it should IMHO talk of "charset" (RFC2978, Sect. 
1.3) not "character set". Unfortunately just replacing "characters set" with 
"charset" doesn't work as it is used in two different contexts.

Best Regards,

Oliver

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

Date: Fri, 1 Sep 2006 09:32:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8
Cc: Calsify List <[email-masked]>

On Fri, 1 Sep 2006, Bernard Desruisseaux wrote:
> Folded lines MUST be well-formed according to the character set
> specified for the iCalendar object. For instance, a UTF-8 multi-octet
> sequence MUST not be split across lines when UTF-8 is used as
> the character set. This may require folding a line at less than
> the recommended 75 octet limit.

"UTF-8 multi-octet sequence" is neither a technically accurate nor 
unambiguous term.  It can describe:

1) An entire UTF-8 string, comprised of multiple codepoints (Unicode 
characters) and multiple glyphs (printed characters).

2) A sequence of octets, interpreted as UTF-8, that comprise a single 
glyph, but may comprise multiple codepoints.

3) A sequence of octets, interpreted as UTF-8, that comprise a single 
codepoint.

Interpretation (1) is absurd in the context, but it is not precluded by 
"UTF-8 multi-octet sequence".  No matter how absurd a misinterpretation 
may be, someone someday will use it unless it is precluded.

The difference between interpretation (2) and (3) depends upon which 
criteria is used for "well-formed".  Splitting between a character and 
combining characters is well-formed UTF-8 encoding, but is NOT well-formed 
Unicode.

Many people fail to understand that UTF-8 is NOT a character set; it is an 
encoding.  The character set is Unicode.

Therefore, a better wording is:
----------------------------------------------------------------------
Folded lines MUST be well-formed according to the character set specified 
for the iCalendar object.  Folding MUST NOT occur between octets that 
define a single codepoint in a character set that uses multiple octets to 
define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian 
character sets).  [Furthermore, folding MUST NOT occur prior to a
codepoints that defines a combining character.]  This may require
folding a line at less than the recommended 75 octet limit.
----------------------------------------------------------------------

The text in [] is used for interpretation (2) but not for interpretation 
(3).

If this working group chooses to use interpretation (3), I question the 
need for this rule at all.  Under interpretation (3), folded text CAN NOT 
interpreted correctly without first applying unfolding.  The two folded 
strings would be well formed UTF-8 encoding, but it is NOT well formed 
Unicode.

On the other hand, there is a possibility that it may not be possible to 
fit a well-formed Unicode string, encoded in UTF-8, in 75 octets.  This 
would happen if a single glyph consumes more than 75 octets when encoded 
in UTF-8.  As far as I recall, the record is a glyph that consumes 18 
codepoints (all in the BMP, so a maximum of 3 octets/codepoint), and that 
glyph has a precomposed codepoint in the BMP.  So this currently is not a 
problem.

If the sense of the group is that it wants to use interpretion (3) to 
avoid this (as-yet theoretical problem), and that it is "good enough" to 
require just well-formed UTF-8 encoding without requiring well-formed 
Unicode, then I request that there be some text to state this rationale.

For example:
----------------------------------------------------------------------
Note: folding is permitted between a character and a combining character. 
The result of such folding in UTF-8 is well-formed UTF-8; however it is 
not well-formed Unicode.  The string prior to the folding will end with a 
printed glyph that is not correct (it misses some combining character) and 
the string subsequent to the folding will start with a combining character 
which is meaningless in Unicode.

Therefore, these strings MUST BE unfolded before displaying them to the 
user.  These foldings are for transport in the iCalendar object, and to 
keep all strings in the iCalendar object as well-formed transport 
encodings (e.g., well-formed UTF-8).  There is NO guarantee that a folded 
string is well-formed in the character set; and thus these foldings MUST 
NOT be used as display foldings. 
----------------------------------------------------------------------

-- 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: Fri, 01 Sep 2006 11:39:58 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify List <[email-masked]>
Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8

Folks, I would like to close this issue with a new proposal.

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

  Folded lines MUST be well-formed according to the character set
  specified for the iCalendar object. For instance, a UTF-8 multi-octet
  sequence MUST not be split across lines when UTF-8 is used as
  the character set. This may require folding a line at less than
  the recommended 75 octet limit.

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). Folded lines
MUST be well-formed according to the character set  specified for
the iCalendar object. For instance, a UTF-8 multi-octet sequence
MUST not be split across lines when UTF-8 is used as the character set.
This may require folding a line at less than the recommended 75 octet
limit. 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

Cyrus Daboo wrote:
> 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.
>