Subject: [Ietf-calsify] rfc 2445 - recurrence set, suggested rewording

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Mon May 29 14:58:51 2006

4.8.5.1 Exception Date/Times  (EXDATE)

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

CORRECTION:  remove 'initial' ('"DTSTART" property') (line 3)
CORRECTION:  remove 'start' ('date and times'/'date-times') x4
  (lines: 9, 11, 11, 13)

SUGGESTED WORDING: (using 'date-times' ONLY)

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

4.8.5.2 Exception Rule  (EXRULE)

   .. The recurrence set is the .. (same as 4.8.5.1)
CORRECTION: (as for 4.8.5.1)

4.8.5.3 Recurrence Date/Times  (RDATE)

   .. The recurrence set is the .. (same as 4.8.5.1)
CORRECTION: (as for 4.8.5.1)

4.8.5.4 Recurrence Rule  (RRULE)

   .. The recurrence set is the .. (same as 4.8.5.1)
CORRECTION: (as for 4.8.5.1)

-- 
_______________________________________________

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 6315, NEW ZEALAND

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Tue May 30 07:25:11 2006

The wording for RDATE and EXDATE is very similar and it's raised a 
question in my mind.

Is it required to have a DTSTART entry for RDATE events? In otherwords, 
if I have 3 events

May 1, May 5, and May 7

Should it be:

DTSTART;VALUE=DATE:20060501
RDATE;VALUE=DATE:20060505,20060507

or is

RDATE;VALUE=DATE:20060501,20060505,20060507

sufficient?

The reason I'm asking is the purpose in 4.8.5.3 states:

Purpose: This property defines the list of date/times for a recurrence set.

"the" seems to say it is sufficient by itself, while the description (as 
in EXDATE) references "the initial "DTSTART"" property.

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

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Tue May 30 14:39:36 2006

George Sexton wrote:
> Is it required to have a DTSTART entry for RDATE events? ..
I have always considered that  DTSTART was used only when necessary ..

  .. This property can appear along with the "RRULE" property
   to define an aggregate set of repeating occurrences. When they both
   appear in an iCalendar object, the recurring events are defined by
   the union of occurrences defined by both the "RDATE" and "RRULE".

(Relevant portions: '.. can appear along with ..', and  'When they both
appear ..')

  SoftDesign Group

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Tue May 30 15:07:58 2006

> Is it required to have a DTSTART entry for RDATE events? ..

Note: spec clearly states that DTSTART must be included for VEVENT.

4.8.2.4 Date/Time Start  (DTSTART)

   .. Within the "VEVENT" calendar component, this property
   defines the start date and time for the event. The property is
   REQUIRED in "VEVENT" calendar components. Events can have a start
   date/time but no end date/time. In that case, the event does not take
   up any time.

  SoftDesign Group

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Wed May 31 06:35:14 2006

Thanks. That information is helpful.

If you're lobbying to improve the language, then it might be nice to 
rephrase 4.8.5.3 from:

to

Purpose: This property defines a set of occurrence date/times in 
addition to the DTSTART value..

Additionally, it might be nice if the samples included the DTSTART entries.

---

From: lear at cisco.com (Eliot Lear)
Date: Wed May 31 08:09:38 2006

Hi George,
> Additionally, it might be nice if the samples included the DTSTART

Again, chair hat off.

I've read a whole lot of documents and written a ew, and I can tell you
that 2445 has a huge number of examples, perhaps too many.  We need to
balance demonstrating the functionality with forcing people to read
through an encyclopedia.  It would be good if we could combine examples
and point out relevant components.

Eliot

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed May 31 08:15:12 2006

Hi Eliot,

> and point out relevant components.

2446 has even more examples than 2445. Those are used to directly 
demonstrate the various scheduling scenarios that can occur. The question 
is are they meant to be 'normative' in the sense that they define the 
'correct' way to so things, or are they only an example of one way to do 
it. One of the problems with 2445/2446 etc is that there are often multiple 
ways to do the same thing (particularly when it comes to recurrences and 
scheduling with multiple people) and that has lead to poor interop. So 
should the new specs try to 'bless' one approach as being the 'correct' way 
to do things, or merely the best way to achieve interop?

-- 
Cyrus Daboo

---

From: lear at cisco.com (Eliot Lear)
Date: Wed May 31 08:18:02 2006

Cyrus,

My preference is that examples NOT be considered normative, and where
they are they should be limited.  Otherwise you're bound to have
differences between both examples and text and perhaps even just the
examples themselves and that just confuses people more.

Eliot

---

From: TimHare at comcast.net (Tim Hare)
Date: Wed May 31 15:07:09 2006

In my opinion, for scheduling to work we need ONE way to exchange scheduling
information (including free/busy) in terms of what 2445 components and
properites are used and their syntax (do I mean semantics here?). That's the
only way to achieve interoperability.  If a particular implementation wants
to use other components and properties within itself, to provide
"competitive advantage", that's OK; even if that occurs inter-server between
two instances of the same vendor's software. But I maintain that _true_
competitive advantage will come to those that can sell us servers that "just
work" with any other entity that we deal with, and that's only going to
happen if we have one simple scheduling protocol.

Tim Hare
Interested Bystander, Non-Inc.
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Wednesday, May 31, 2006 11:15 AM
To: Eliot Lear; George Sexton
Cc: ietf-calsify
Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 -recurrence
set, suggested rewording)

Hi Eliot,

-- 
Cyrus Daboo

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

From: "Tim Hare" <[email-masked]>
To: "'ietf-calsify'" <[email-masked]>
Subject: RE: [Ietf-calsify] Re: RDATE Question was (rfc 2445 -recurrence	set, suggested rewording)
Date: Wed, 31 May 2006 18:06:55 -0400

In my opinion, for scheduling to work we need ONE way to exchange scheduling
information (including free/busy) in terms of what 2445 components and
properites are used and their syntax (do I mean semantics here?). That's the
only way to achieve interoperability.  If a particular implementation wants
to use other components and properties within itself, to provide
"competitive advantage", that's OK; even if that occurs inter-server between
two instances of the same vendor's software. But I maintain that _true_
competitive advantage will come to those that can sell us servers that "just
work" with any other entity that we deal with, and that's only going to
happen if we have one simple scheduling protocol.

Tim Hare
Interested Bystander, Non-Inc.
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Wednesday, May 31, 2006 11:15 AM
To: Eliot Lear; George Sexton
Cc: ietf-calsify
Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 -recurrence
set, suggested rewording)

Hi Eliot,

-- 
Cyrus Daboo

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

Date: Wed, 31 May 2006 14:34:24 -0700
From: Mark Crispin <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: [email-masked]

On Wed, 31 May 2006, Oliver Block wrote:
> The point is: either there are reasons to fold at 75 (or less) or there 
> are no reasons for that. If there are reasons the rule should be kept 
> IMHO.

It is up to the proponents of removing folding to demonstrate that there 
is no reason to fold.

Put another way, it is necessary to prove that nobody depends upon folding 
now; and furthermore that no individual, who is not privy to this 
discussion, will in good faith create an application which depends upon 
folding based upon current documents.

Without such proof, the question is moot.  It seems to me that the 
concensus of experienced protocol implementors is that it is not 
particularly difficult to fold, even when UTF-8 is involved.

> It could be extended that UTF-8 characters SHOULD NOT be folded between
> multibyte characters.

Perhaps you should have meant to say something to the effect against 
folding in the middle of a multi-octet UTF-8 character.  But that isn't 
what you said.

You can always fold between characters; the prohibition is on folding in 
the middle of a character.

Also, character != octet != byte.

-- 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: [Ietf-calsify] Status of simplification work
Date: Wed, 31 May 2006 23:24:12 +0200
Reply-To: [email-masked]

Am Mittwoch, 31. Mai 2006 20:54 schrieb George Sexton:
> Cyrus Daboo wrote:

> How many of the other specs specify UTF-8 as the default encoding?

That is not the point.

The point is: either there are reasons to fold at 75 (or less) or there are no 
reasons for that. If there are reasons the rule should be kept IMHO.

It could be extended that UTF-8 characters SHOULD NOT be folded between 
multibyte characters. Another RFC states that lines should not/must not be 
folded after whitespace.

Best Regards,

Oliver

Date: Wed, 31 May 2006 12:54:28 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: [email-masked]

Cyrus Daboo wrote:
> Hi Sam,
>
> --On May 25, 2006 11:47:47 PM -0700 Sam Roberts 
> <[email-masked]> wrote:
>
>> I do have a problem with it being changed from octets to 'characters',
>> it would make it the only one of the mail/mime/etc. specs that works
>> that way.
How many of the other specs specify UTF-8 as the default encoding?

Date: Wed, 31 May 2006 17:17:58 +0200
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set,	suggested rewording)
Cc: ietf-calsify <[email-masked]>

Cyrus,

Eliot

Date: Wed, 31 May 2006 11:15:05 -0400
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence	set,	suggested rewording)
Cc: ietf-calsify <[email-masked]>

Hi Eliot,

-- 
Cyrus Daboo

Date: Wed, 31 May 2006 17:09:32 +0200
From: Eliot Lear <[email-masked]>
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set,	suggested rewording)
Cc: ietf-calsify <[email-masked]>

Hi George,

Again, chair hat off.

Eliot

Date: Wed, 31 May 2006 10:47:39 -0400
From: Cyrus Daboo <[email-masked]>
To: Sam Roberts <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Status of simplification work

Hi Sam,

--On May 25, 2006 11:47:47 PM -0700 Sam Roberts <[email-masked]> 
wrote:

> I do have a problem with it being changed from octets to 'characters',
> it would make it the only one of the mail/mime/etc. specs that works
> that way.

2445 says a maximum of 75 octets per line and split between two characters. 
As I read it that meant splitting at the utf-8 'character sequence' 
boundary at or below an octet count of 75.

As to the mail/mime etc specs, they only deal with ASCII data when doing 
folding/unfolding (which only occurs for header fields) - so there is no 
problem there. However, the current efforts to allow non-ascii in message 
headers etc will have this problem - I've not checked to see whether they 
have already tried to address that. I might ask on their list about this 
and see what others think...

-- 
Cyrus Daboo

Date: Wed, 31 May 2006 07:35:05 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Andrew N Dowden <[email-masked]>
Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set,	suggested rewording)
Cc: ietf-calsify <[email-masked]>

to

Date: Wed, 31 May 2006 10:07:52 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording)

  SoftDesign Group

Date: Wed, 31 May 2006 09:39:30 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording)

  SoftDesign Group

To: IETF-iCalendar <[email-masked]>, CalDAV DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 30 May 2006 11:38:57 -0700
Subject: [Ietf-calsify] Fwd: Atompub WG meeting at the Montreal IETF

--Apple-Mail-20-1055929559
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

FYI: Calendar format standards and relationship to AtomPub is  
tentatively on the AtomPub WG agenda in Montreal.

Lisa

Begin forwarded message:

> From: Paul Hoffman <[email-masked]>
> Date: May 23, 2006 1:49:20 PM PDT
> To: Atom WG <[email-masked]>, [email-masked]
> Subject: Atompub WG meeting at the Montreal IETF
>
>
> Greetings again. The Atompub WG will have our first (and maybe  
> last!) face-to-face meeting at the upcoming IETF meeting in  
> Montreal at the beginning of July.
>
> The timing of us having our first WG meeting may seem odd, given  
> the fact that we completed the Atom format document long ago, and  
> are making good progress on the publishing protocol. However, there  
> are reasons other than "moving documents forwards" for WGs to meet.  
> Lisa Dusseault, our Area Director, asked us to have a meeting so  
> that people active in the Atompub WG can have more interaction with  
> the IETF, and vice versa. There is interest in the Atom format from  
> other WGs, and there may be interest in the Atom publishing  
> protocol as well.
>
> I propose the following agenda, which should fit well into a one- 
> hour slot:
>
> - Intro: 10 mins
> - Brief overview of protocol status: 10 mins
> - Use of Atom format in other WGs: 30 mins
>   - draft-saintandre-atompub-notify
>   - Overlap with calendar formats
>   - Overlap with mail
>
> Note that we are explicitly *not* going to discuss extensions to  
> the Atom format at this WG meeting because they are not part of the  
> WG charter. Lisa has said that she may help arrange a BoF session  
> on creating a new Working Group for Atom extensions, and having at  
> least a higher-level discussion of what extensions are out there  
> would be appropriate in that BoF. But, to use asterisks again, such  
> discussion is *not* part of the Atompub WG meeting.
>
> See <http://www.ietf.org/meetings/IETF-66.html> for details about  
> the IETF meeting. I will let the WG know when there are preliminary  
> and near-permanent agendas for the meeting. It would be good to  
> meet some of you there!
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

--Apple-Mail-20-1055929559
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">FYI: Calendar format standards =
and relationship to AtomPub is tentatively on the AtomPub WG agenda in =
Montreal.<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa<BR><DIV><BR><DIV>Begin =
forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Paul Hoffman &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT></DIV><DIV=
 style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>Date: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">May 23, 2006 1:49:20 PM PDT</FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>To: </B></FONT><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Atom WG =
&lt;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, =
<A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DI=
V><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>Subject: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica"><B>Atompub WG meeting at the Montreal =
IETF</B></FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
<DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Greetings again. The Atompub WG will have our first (and maybe last!) =
face-to-face meeting at the upcoming IETF meeting in Montreal at the =
beginning of July.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The timing of us having our =
first WG meeting may seem odd, given the fact that we completed the Atom =
format document long ago, and are making good progress on the publishing =
protocol. However, there are reasons other than "moving documents =
forwards" for WGs to meet. Lisa Dusseault, our Area Director, asked us =
to have a meeting so that people active in the Atompub WG can have more =
interaction with the IETF, and vice versa. There is interest in the Atom =
format from other WGs, and there may be interest in the Atom publishing =
protocol as well.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I propose the following agenda, which should fit =
well into a one-hour slot:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">- Intro: 10 mins</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- Brief overview of protocol status: 10 =
mins</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">- Use of Atom format in other =
WGs: 30 mins</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- =
draft-saintandre-atompub-notify</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- Overlap with calendar =
formats</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>- Overlap with mail</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Note =
that we are explicitly *not* going to discuss extensions to the Atom =
format at this WG meeting because they are not part of the WG charter. =
Lisa has said that she may help arrange a BoF session on creating a new =
Working Group for Atom extensions, and having at least a higher-level =
discussion of what extensions are out there would be appropriate in that =
BoF. But, to use asterisks again, such discussion is *not* part of the =
Atompub WG meeting.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">See &lt;<A =
href=3D"http://www.ietf.org/meetings/IETF-66.html">http://www.ietf.org/mee=
tings/IETF-66.html</A>&gt; for details about the IETF meeting. I will =
let the WG know when there are preliminary and near-permanent agendas =
for the meeting. It would be good to meet some of you there!</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">--Paul =
Hoffman, Director</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">--Internet Mail =
Consortium</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-20-1055929559--

Date: Tue, 30 May 2006 08:24:50 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Andrew N Dowden <[email-masked]>
Cc: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] RDATE Question was (rfc 2445 - recurrence set, suggested rewording)

May 1, May 5, and May 7

Should it be:

or is

sufficient?

Date: Mon, 29 May 2006 21:46:34 -0700
From: Sam Roberts <[email-masked]>
To: ietf-calsify <[email-masked]>
Subject: Re: [Ietf-calsify] RFC2445 Correction in rrule examples
Mail-Followup-To: ietf-calsify <[email-masked]>

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

Cheers,
Sam

Date: Tue, 30 May 2006 09:58:44 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] rfc 2445 - recurrence set, suggested rewording

  SoftDesign Group

Date: Mon, 29 May 2006 06:38:29 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] CalConnect problem and recommendations document cited in previous mail
Reply-To: [email-masked]

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

Apologies for not including pointers to the documents I mentioned in my 
previous e-mail.

There's a section on the CalConnect website called "Work Products" and 
the current documents are all listed; go to http://www.calconnect.org 
and select Work Products from the sidebar.  They are all in PDF format. 

Alternatively you can go directly to

http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf

http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf

http://www.calconnect.org/publications/timezoneregistryandservicerecommendationsv1.0.pdf

Dave Thewlis

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------070506060202040201050202
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">
Apologies for not including pointers to the documents I mentioned in my
previous e-mail.<br>
<br>
There's a section on the CalConnect website called "Work Products" and
the current documents are all listed; go to <a
 href="http://www.calconnect.org">http://www.calconnect.org</a> and
select Work Products from the sidebar.&nbsp; They are all in PDF format.&nbsp; <br>
<br>
Alternatively you can go directly to<br>
<br>
<a
 href="http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf">http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf</a><br>
<br>
<br>
<a
 href="http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf">http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf</a><br>
<br>
<br>
<a
 href="http://www.calconnect.org/publications/timezoneregistryandservicerecommendationsv1.0.pdf">http://www.calconnect.org/publications/timezoneregistryandservicerecommendationsv1.0.pdf</a><br>
&nbsp;<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------070506060202040201050202--

Date: Mon, 29 May 2006 06:15:05 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: ietf-calsify <[email-masked]>
Reply-To: [email-masked]

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

Tim,

With respect to the Recurrence and Timezone subjects, CalConnect has 
published problem statements and recommendations in both of those areas 
which are available on our web site.  Whether they will be adopted in 
whole or in part by the Calisfy WG or the draft editors is another 
matter, but the issues have at least been studied and possible 
approaches to them proposed.

Dave Thewlis
CalConnect

Eliot Lear wrote:
> Tim,
>
> [Again, with my chair hat off]
>
> Sorry for my delayed posting (I am on holiday).  In the future, I
> suggest that each such question below or new questions be separated by
> subject so that they don't get lost in the shuffle.  Here is my opinion
> about the below.
>
>   
>> 1. Have the recurrence issues been resolved? If so, what is the simplified
>> support for recurrence rules or were they dropped entirely?
>>   
>>     
> They have not been resolved.
>   
>> 2. At one point there was a discussion about dropping timezones,
>> transmitting all time data in UCT and leaving timezone conversion as a UI
>> issue (but there were some unresolved issues regarding recurring time sets
>> which crossed daylight-savings-time boundaries, I think)
>>   
>>     
>
> This has not been resolved.
>   
>> 3. It's been a while since I saw a notice of a draft posted - what is the
>> latest draft related to this work?
>>   
>>     
> A draft will be posted prior to the Montreal meeting.  Bernard has his
> hands full, but as we are able to close on the above issues they will
> either make that draft or the next.
>   
>> 4. IF any of the developers for major implementations still read this list,
>> or if CalConnect would care to take another survey, can we get a show of
>> hands whether non-folded lines break an implementation?  And conversely, are
>> there known implementations that naively assume that the line-ending
>> sequence always means the end of a component?
>>   
>>     
> I do not know the answer to this question for the calendar clients but
> as someone who has written calendars I didn't think that folding the
> text isn't all that big a deal, and not that hard to test, and I'm not a
> great programmer.  Again, chair hat off. YMMV.
>
> Eliot
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
>   

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------090800060806040001000307
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">
Tim,<br>
<br>
With respect to the Recurrence and Timezone subjects, CalConnect has
published problem statements and recommendations in both of those areas
which are available on our web site.&nbsp; Whether they will be adopted in
whole or in part by the Calisfy WG or the draft editors is another
matter, but the issues have at least been studied and possible
approaches to them proposed.<br>
<br>
Dave Thewlis<br>
CalConnect<br>
<br>
Eliot Lear wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Tim,

[Again, with my chair hat off]

Sorry for my delayed posting (I am on holiday).  In the future, I
suggest that each such question below or new questions be separated by
subject so that they don't get lost in the shuffle.  Here is my opinion
about the below.

  </pre>
  <blockquote type="cite">
    <pre wrap="">1. Have the recurrence issues been resolved? If so, what is the simplified
support for recurrence rules or were they dropped entirely?
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->They have not been resolved.
  </pre>
  <blockquote type="cite">
    <pre wrap="">2. At one point there was a discussion about dropping timezones,
transmitting all time data in UCT and leaving timezone conversion as a UI
issue (but there were some unresolved issues regarding recurring time sets
which crossed daylight-savings-time boundaries, I think)
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This has not been resolved.
  </pre>
  <blockquote type="cite">
    <pre wrap="">3. It's been a while since I saw a notice of a draft posted - what is the
latest draft related to this work?
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->A draft will be posted prior to the Montreal meeting.  Bernard has his
hands full, but as we are able to close on the above issues they will
either make that draft or the next.
  </pre>
  <blockquote type="cite">
    <pre wrap="">4. IF any of the developers for major implementations still read this list,
or if CalConnect would care to take another survey, can we get a show of
hands whether non-folded lines break an implementation?  And conversely, are
there known implementations that naively assume that the line-ending
sequence always means the end of a component?
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->I do not know the answer to this question for the calendar clients but
as someone who has written calendars I didn't think that folding the
text isn't all that big a deal, and not that hard to test, and I'm not a
great programmer.  Again, chair hat off. YMMV.

Eliot
_______________________________________________
Ietf-calsify mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a>

  </pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------090800060806040001000307--

Date: Mon, 29 May 2006 14:49:53 +0200
From: Eliot Lear <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: ietf-calsify <[email-masked]>

Tim,

[Again, with my chair hat off]

Sorry for my delayed posting (I am on holiday).  In the future, I
suggest that each such question below or new questions be separated by
subject so that they don't get lost in the shuffle.  Here is my opinion
about the below.

> 1. Have the recurrence issues been resolved? If so, what is the simplified
> support for recurrence rules or were they dropped entirely?
>   
They have not been resolved.
> 2. At one point there was a discussion about dropping timezones,
> transmitting all time data in UCT and leaving timezone conversion as a UI
> issue (but there were some unresolved issues regarding recurring time sets
> which crossed daylight-savings-time boundaries, I think)
>   

This has not been resolved.
> 3. It's been a while since I saw a notice of a draft posted - what is the
> latest draft related to this work?
>   
A draft will be posted prior to the Montreal meeting.  Bernard has his
hands full, but as we are able to close on the above issues they will
either make that draft or the next.
> 4. IF any of the developers for major implementations still read this list,
> or if CalConnect would care to take another survey, can we get a show of
> hands whether non-folded lines break an implementation?  And conversely, are
> there known implementations that naively assume that the line-ending
> sequence always means the end of a component?
>   
I do not know the answer to this question for the calendar clients but
as someone who has written calendars I didn't think that folding the
text isn't all that big a deal, and not that hard to test, and I'm not a
great programmer.  Again, chair hat off. YMMV.

Eliot

From: Oliver Block <[email-masked]>
To: ietf-calsify <[email-masked]>
Date: Mon, 29 May 2006 14:18:43 +0200
Subject: [Ietf-calsify] RFC2445 Corrections
Reply-To: [email-masked]

Hello,

I'd like to mention some typo corrections to the text of RFC2445:

page 14

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

SHOULD :-) be moved to the next page and appear somewhere after

     QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
     ; Any character except CTLs and DQUOTE

page 17 (paragraph 1)

   Inline binary contact SHOULD only be used in applications
   whose special circumstances demand that an iCalendar object be
   expressed as a single entity.

should be changed to

   Inline binary content SHOULD only be used in applications
   whose special circumstances demand that an iCalendar object be
   expressed as a single entity.

->inline binary content

page 21 (paragraph 1):
  This parameter specifies those calendar uses that have delegated
  their participation in a group scheduled event or to-do to the 
  calendar user specified by the property.

should be changed to:

   This parameter specifies those calendar users that have delegated
   their participation in a group scheduled event or to-do to the 
   calendar user specified by the property.

  ->calendar users

Best regards,

Oliver
--
Sylbacher Str. 241
32107 Bad Salzuflen
Germany

Date: Sun, 28 May 2006 21:43:31 +0100
Subject: Re: [Ietf-calsify] Status of simplification work
From: Dave Cridland <[email-masked]>
To: Helge Hess <[email-masked]>
Cc: [email-masked]

On Sun May 28 03:48:36 2006, Helge Hess wrote:
> Anyway, if the item is sent over a transport which doesn't support  
> longer-than-75-lines (like email) you can still apply content- 
> transfer-encodings?

As an aside, just to clarify, email has no such requirement. It has a 
recommendation for limiting line lengths to 78, which is largely a 
matter of ancient history, although it still applies to a large 
degree for western glyphs, which are more likely to be displayed on 
the non-wrapping 80 column displays that spawned the recommendation, 
and it's been reinforced again by format=flowed, which removes any 
counter-argument.

It does have a requirement for line lengths lower than 1000 octets 
including the CR LF delimiter when sent with DATA, as do the MIME 
encodings 7bit and 8bit. These vanish as well with suitable usage of 
binary MIME (RFC3030, etc). This limit has nothing to do with 
display, this relates to ancient mail gateways, I believe, although 
Mark Crispin can probably shed a lot more light on this than I can, 
having worked with mail at the time this limit was being made.

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: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Date: Sun, 28 May 2006 04:48:36 +0200
To: Calsify <[email-masked]>

On 26. Mai 2006, at 18:11 Uhr, George Sexton wrote:
>> For that matter, if Java uses UTF-16, there is no such thing as an  
>> "array of characters" there either.  Characters outside the BMP in  
>> UTF-16 are represented by surrogates that occupy two array positions.
> This is totally false. Consider a typical Java declaration:
>
> char[] buf=new char[1024];
>
> declares an array of Unicode 16 characters.

Are you aware of the difference between UTF-16 and UCS-2? AFAIK Java  
(like Cocoa) uses the former which makes Mark's statement totally  
correct. A Java character (char basetype) is not the same like a  
Unicode character.
But thats Java/Unicode 101 and doesn't really belong on this list?

> Given what the spec says about wrapping lines on arbitrary byte  
> boundaries, what is the solution?
>
> I haven't heard you argue for removing the wrapping requirement.

I'm kinda confused. Its a SHOULD, not a requirement?

Anyway, if the item is sent over a transport which doesn't support  
longer-than-75-lines (like email) you can still apply content- 
transfer-encodings?

Summary: I think the 75-char requirement should be dropped, its of no  
use? iCalendar is the content type and transport requirements are  
already covered by the transports (eg MIME).

Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Status of simplification work
Date: Fri, 26 May 2006 19:52:27 +0200
Reply-To: [email-masked]

Hi George,

Am Donnerstag, 25. Mai 2006 23:30 schrieben Sie:
> > Changing a spec seems to me as the most comfortable way of not solving a
> > problem one faces.
> I'll ignore the implied insult that I'm actually not clever enough to
> code a correct implementation.

:) (not intended)

> I too am waiting to hear the good reason.

You never ask for the reason! My guess is: the formal reason is that it is a 
registered mime media type. There may be technical or others.

> > Does a change to
> > 75 characters lead to anything, or does it just mislead? What would you
> > say if anybody suggests to change from 75 octets to 75 words (the
> > linguistic unit).
>
> More complexity with no advantage.

If a character can consist of 1, 2 or three bytes/octets and you change from 
octet to character it is the same. Even if exaggerated. The result is: it 
will not be 75 octets.

> My mistake. I thought this list was made up of people who are interested
> in improving interoperability.

interoperability between ...?

> I'm suggesting improving interoperability by increasing the probability
> that an implementer of average skill will get this part right.

OK for me.

> I'm really, really glad that I'm not putting up any money to participate
> in this comedy.

And you can be sure that you will not be charged by me.:)

Best Regards,

Oliver

Date: Fri, 26 May 2006 09:36:11 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: ietf-calsify <[email-masked]>

I decline to waste any more time on this discussion.

I wish you good luck.  You will need it.

-- 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, 26 May 2006 10:25:44 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: ietf-calsify <[email-masked]>

In case you've forgotten your original position:

Mark Crispin wrote:
>
> Consequently, I recommend that the wrap recommendation be retained, 
> and that sample code such as the above be proved for the benefit of 
> those people who have trouble understanding how to determine the octet 
> length of a Unicode character in UTF-8.
>
> -- Mark --

Date: Fri, 26 May 2006 10:11:21 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: [email-masked]

Mark Crispin wrote:
> On Fri, 26 May 2006, George Sexton wrote:
>>>> for (int i=0; i < data.length; ) {
>>>>    stream.write(data[i++]);
>>>>    if ((i%75==0) && (i<data.length))
>>>>       stream.write("\n");
>>>> }
>>> Sorry, but that assumes that your data buffer is 16 bit unicode
>>> characters, which might be true for you in java but isn't true in the
>>> languages I work in.
>> In my example, data is an array of characters. The Java I/O classes 
>> handle the conversion to the appropriate file encoding automatically.
>
> There is no such thing as an "array of characters" when you are 
> talking about UTF-8.

This is true. I've never argued that there was. In fact, other people 
have argued that there was and I have disagreed. Specifically, the 
person who said that you could shove a new-line between UTF-8 bytes of a 
character.

>
> For that matter, if Java uses UTF-16, there is no such thing as an 
> "array of characters" there either.  Characters outside the BMP in 
> UTF-16 are represented by surrogates that occupy two array positions.

This is totally false. Consider a typical Java declaration:

char[] buf=new char[1024];

declares an array of Unicode 16 characters. If you would like to argue 
the mechanics of what the virtual machine does under the hood, that's 
fine. But from the programming language standpoint Java has arrays of 
characters. I can directly index and access any character.

To elaborate a little on the I/O end of things, if I declare an Output 
stream, and set the encoding to be UTF-8 then when I shove a character 
down that stream the encoding issues are taken care of automatically. If 
I set the encoding to ISO-8859-1, and send an accented character down 
it, then I will get the correct encoding.

> The only way in Unicode in which there can be an "array of characters" 
> is if you use UCS-2 (which only allows the characters in the BMP) or 
> UCS-4. However, as I pointed out earlier, even if you use UCS-4 you 
> still can not assume that it is alright to break a Unicode string at a 
> Unicode character boundary since there are combining characters which 
> add to the glyph formed by the previous character.
>
> Given my earlier example of umlaut-a in German; if you insert a break 
> between the "a" and the umlaut in a decomposed character (or worse, 
> truncate at that point!) you have changed the actual glyph (which is 
> what most people mistakenly call "characters").  In some languages, 
> this is more than just a missing diacritical mark -- it is a 
> completely different (and unrelated) letter!
>
> Once you start using Unicode, you have to give up such quaint notions 
> as "array of characters".  I know that this sounds bad to you; it is 
> indeed very bad news to programmers who have relied upon traditional 
> methods of character manipulation for decades.  I sympathize, having 
> gone through this process myself.

Again, my feeling is so what? You really aren't seeing the whole 
picture. Let me try to step you through this:

The current RFC-2445 says that lines SHOULD be wrapped at 75 octets and 
a new-line inserted.

Explicitly wrapping the lines at 75 octets if the data is actually 
multi-byte UTF-8 characters will have negative results. The output may 
not be valid UTF-8 in its folded form. I personally suspect that 
breaking UTF-8 characters may introduce other artifacts (extraneous new 
lines).

My original complaint was that octets was a problem with UTF-8. You've 
pointed this out yourself. If sub-dividing characters is a problem 
sub-dividing bytes is a bigger one.

Your original response was to supply a function that would allow me to 
calculate the length of each individual character so that I could write 
a stream that would output correctly formatted UTF-8 characters and stay 
within the 75 octet limit.

So, again, given what you're saying is true about various accent characters.

Given what the spec says about wrapping lines on arbitrary byte 
boundaries, what is the solution?

I haven't heard you argue for removing the wrapping requirement.

Is this your stand now?

> There is no "simple" way to program Unicode.  The sooner you discard 
> such notions from the past, and get accustomed to doing things the 
> Unicode way, the happier you will be in the long run.
I think I get the "Unicode Way" just fine thank you. The problem is the 
spec has a brain damaged requirement that is a problem when using 
multi-byte characters.

If you could stop arguing both sides of the problem, perhaps we could 
come to a solution.

Date: Fri, 26 May 2006 08:48:09 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: [email-masked]

On Fri, 26 May 2006, George Sexton wrote:
>>> for (int i=0; i < data.length; ) {
>>>    stream.write(data[i++]);
>>>    if ((i%75==0) && (i<data.length))
>>>       stream.write("\n");
>>> }
>> Sorry, but that assumes that your data buffer is 16 bit unicode
>> characters, which might be true for you in java but isn't true in the
>> languages I work in.
> In my example, data is an array of characters. The Java I/O classes handle 
> the conversion to the appropriate file encoding automatically.

There is no such thing as an "array of characters" when you are talking 
about UTF-8.

For that matter, if Java uses UTF-16, there is no such thing as an "array 
of characters" there either.  Characters outside the BMP in UTF-16 are 
represented by surrogates that occupy two array positions.

The only way in Unicode in which there can be an "array of characters" is 
if you use UCS-2 (which only allows the characters in the BMP) or UCS-4. 
However, as I pointed out earlier, even if you use UCS-4 you still can not 
assume that it is alright to break a Unicode string at a Unicode character 
boundary since there are combining characters which add to the glyph 
formed by the previous character.

Given my earlier example of umlaut-a in German; if you insert a break 
between the "a" and the umlaut in a decomposed character (or worse, 
truncate at that point!) you have changed the actual glyph (which is what 
most people mistakenly call "characters").  In some languages, this is 
more than just a missing diacritical mark -- it is a completely different 
(and unrelated) letter!

Once you start using Unicode, you have to give up such quaint notions as 
"array of characters".  I know that this sounds bad to you; it is indeed 
very bad news to programmers who have relied upon traditional methods of 
character manipulation for decades.  I sympathize, having gone through 
this process myself.

Another quaint notion that has to be discarded is that a character is 
representable in a bit-field; that is, that the maximum codepoint value is 
a power of 2 minus one.  That is no longer true in Unicode.  Unicode has 
17 planes of 16-bit codepoints; thus the maximum Unicode codepoint value 
is 0x10ffff.  Insiders say that Unicode values are "20 bits plus 1".

There is no "simple" way to program Unicode.  The sooner you discard such 
notions from the past, and get accustomed to doing things the Unicode way, 
the happier you will be in the long run.

-- 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, 26 May 2006 09:14:00 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] Status of simplification work

Sam Roberts wrote:
> Quoting [email-masked], on Thu, May 25, 2006 at 03:30:59PM -0600:
>   
>> The proposed change simplifies things because programmers can simply write;
>>
>> for (int i=0; i < data.length; ) {
>>    stream.write(data[i++]);
>>    if ((i%75==0) && (i<data.length))
>>       stream.write("\n");
>> }
>>     
>
> Sorry, but that assumes that your data buffer is 16 bit unicode
> characters, which might be true for you in java but isn't true in the
> languages I work in. My library is written with its buffers being in
> utf-8, so when I split at the 75 octet boundary, it really is the 75
> octet boundary, and not necessarily at the 75 character boundary.
>
> If it was changed to 75 characters, the effect would be to complicate my
> code for much the same reasons the current definition complicates your
> code, I'd have to figure out how many "characters" are in the buffer.
>   
In my example, data is an array of characters. The Java I/O classes 
handle the conversion to the appropriate file encoding automatically.

Date: Thu, 25 May 2006 23:57:15 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: RE : [Ietf-calsify] Status of simplification work
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Thu, May 25, 2006 at 09:31:00AM -0400:
> --On May 25, 2006 11:46:22 AM +0200 Arnaud Quillaud 
> <[email-masked]> wrote:
> 
> >So even if you split a 4 bytes UTF8 character by inserting a space+CRLF
> >in the middle, the parser at the other end should remove this space+CRLF
> >even before interpreting the stream as UTF-8.
> 
> But that breaks the utf-8 data stored in a file or sent over the wire. As 
> far as I am concerned that is wrong - i.e. you MUST do line folding such 
> that the resulting data is valid utf-8 (or valid in whatever charset is 
> being used).

Has anybody noted a similar issue with wrapping at escape sequence
boundaries in TEXT values?

I split at exactly 75 octets, and I've recently had reports that if
there is a '\' 'n' sequence (an escaped newline) that happens to fall on
the boundary that some tools will not read in the data correctly.

Are these equivalent:

-----
DESCRIPTION:a newline \
 n just passed
-----

and 

-----
DESCRIPTION:a newline \n
  just passed
-----

Seems to me that they are, and are both valid utf-8, and obey the folding rules!

Sam

Date: Thu, 25 May 2006 23:47:47 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Status of simplification work
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Thu, May 25, 2006 at 03:30:59PM -0600:
> The proposed change simplifies things because programmers can simply write;
> 
> for (int i=0; i < data.length; ) {
>    stream.write(data[i++]);
>    if ((i%75==0) && (i<data.length))
>       stream.write("\n");
> }

Sorry, but that assumes that your data buffer is 16 bit unicode
characters, which might be true for you in java but isn't true in the
languages I work in. My library is written with its buffers being in
utf-8, so when I split at the 75 octet boundary, it really is the 75
octet boundary, and not necessarily at the 75 character boundary.

If it was changed to 75 characters, the effect would be to complicate my
code for much the same reasons the current definition complicates your
code, I'd have to figure out how many "characters" are in the buffer.

Anyhow, I don't have a problem with the SHOULD being removed.

I do have a problem with it being changed from octets to 'characters',
it would make it the only one of the mail/mime/etc. specs that works
that way.

Cheers,
Sam

From: "Tim Hare" <[email-masked]>
To: "ietf-calsify" <[email-masked]>
Subject: RE: [Ietf-calsify] Status of simplification work
Date: Thu, 25 May 2006 20:45:11 -0400

Wow - I guess I wasn't specific enough in my questions, the "answers" became
a discussion on coding solutions in one particular language.

1. Have the recurrence issues been resolved? If so, what is the simplified
support for recurrence rules or were they dropped entirely?

2. At one point there was a discussion about dropping timezones,
transmitting all time data in UCT and leaving timezone conversion as a UI
issue (but there were some unresolved issues regarding recurring time sets
which crossed daylight-savings-time boundaries, I think)

3. It's been a while since I saw a notice of a draft posted - what is the
latest draft related to this work?

4. IF any of the developers for major implementations still read this list,
or if CalConnect would care to take another survey, can we get a show of
hands whether non-folded lines break an implementation?  And conversely, are
there known implementations that naively assume that the line-ending
sequence always means the end of a component?

And to whoever asked the XML question (I've forgotten): I believe the XML
spec ignores whitespace although that doesn't mean that all parsers do. XML
discussions, however, are explicitly not part of the WG's charter.

Tim Hare
Interested Bystander, Non-Inc.

Date: Thu, 25 May 2006 16:29:19 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: [email-masked]

Mark Crispin wrote:
> On Thu, 25 May 2006, George Sexton wrote:
>> I'm suggesting improving interoperability by increasing the 
>> probability that an implementer of average skill will get this part 
>> right. Do you want a standard that only extremely skilled programmers 
>> will have any chance of delivering a correct implementation, or do 
>> you want a standard that most people will be able to do correctly?
>
> This may not be a popular view, but it bears stating:
>
> Given my druthers, I would prefer to have a standard that only an 
> extremely skilled programmer is capable of delivering any 
> implementation at all.  There is a much greater chance of getting 
> multiple quality, interoperable, implementations if the incompetant 
> are completely locked out.

As stated, it's a good idea. Practically speaking though, even skilled 
developers will have a much higher defect rate implementing a complex 
specification.

Date: Thu, 25 May 2006 15:22:17 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: [email-masked]

On Thu, 25 May 2006, George Sexton wrote:
> I'm suggesting improving interoperability by increasing the probability that 
> an implementer of average skill will get this part right. Do you want a 
> standard that only extremely skilled programmers will have any chance of 
> delivering a correct implementation, or do you want a standard that most 
> people will be able to do correctly?

This may not be a popular view, but it bears stating:

Given my druthers, I would prefer to have a standard that only an 
extremely skilled programmer is capable of delivering any implementation 
at all.  There is a much greater chance of getting multiple quality, 
interoperable, implementations if the incompetant are completely locked 
out.

I have been asked, on multiple occasions, effectively to write the 
protocol engine for an application that some cheapskate contracted to the 
lowest bidder...and to do this service for free.  On other occasions, I 
have been asked protocol questions that are so elementary that it is 
painfully clear that the individual never read the specification (or even 
one of the excellent pedagogical texts that describe the protocol). 
Worse, he makes it clear that he has no intention of doing so; he expects 
me to answer the questions that come up when empirical testing won't 
deliver the answer.

-- Mark --

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

Date: Thu, 25 May 2006 15:30:59 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: [email-masked]

Oliver Block wrote:
> Hi, 
>
> I am also new to this list.
>
> Am Donnerstag, 25. Mai 2006 15:59 schrieb George Sexton:
>   
>> The point here is simplification.
>>     
>
> Simplification for whom?
>   

I thought vendors who were producing or consuming iCal files. That's the 
point of this list isn't it?

The proposed change simplifies things because programmers can simply write;

for (int i=0; i < data.length; ) {
    stream.write(data[i++]);
    if ((i%75==0) && (i<data.length))
       stream.write("\n");
}

Research has found that the number one method of reducing the number of 
defects in a program is to reduce the number of lines in that program. 
Doing octets requires:

int iCurrentLine=0,iCharLength;
for (int i=0; i < data.length; i++) {
   iCharLength=ObscureUnicodeToByteLengthConversion(data[i]);
    if (iCurrentLine+iCharLength)>75 {
       stream.write("\n");
       iCurrentLine=0;
    }
    stream.write(data[i]);
    iCurrentLine+=iCharLength;
}

 The second version is about twice as long as the 1st version, requires 
two additional variables, and requires a function call on every 
character. Given a function length for the character to byte length 
converter of 10 lines, that makes the second version almost 3 times longer.

5 lines= simpler

20 lines=more complicated
>   
>> It will result 
>> in a portion of the spec that people either don't comply with, or that
>> they do wrong.
>>     
>
> By which reason are they doing it wrong?
>   
A lot of people don't wrap at all. Of the rest I would bet that over 90% 
who are writing multi-byte UTF-8 are wrapping at 75 characters.
> Changing a spec seems to me as the most comfortable way of not solving a 
> problem one faces.
>   
I'll ignore the implied insult that I'm actually not clever enough to 
code a correct implementation.

> The question should be: Are there good reasons for that rule? 
I too am waiting to hear the good reason. So far, the only winner is it 
makes the file easier to read in a text editor.

> Does a change to 
> 75 characters lead to anything, or does it just mislead? What would you say 
> if anybody suggests to change from 75 octets to 75 words (the linguistic 
> unit).
>   
More complexity with no advantage. An average page of English text is 
500 words. Breaking on 75 words would yield 7 lines. b This would give 
the complexity of the output code having a word counter, without the 
benefit of actually making the text viewable in an editor without 
scrolling. It also assumes that the implementer can write generic code 
for any language that will identify linguistic unit separators. Doubtful.

> Interesting discussion though.:)
>   
My mistake. I thought this list was made up of people who are interested 
in improving interoperability. It appears to be a debating society where 
members compete to prove their cleverness. So far, to sum up the responses:

An obscure function that can be used to implement an algorithm 3 times 
longer than the simpler.
A suggestion that people who want to work with characters are doing so 
in misguided attempts to handle typesetting issues.
An incorrect suggestion that it doesn't matter if you interpose a 
newline character between the bytes of a UTF-8 character.
A suggestion that my desire stems from my inability to correctly 
implement the requirement.
A pointless alternative suggestion offered up in the spirit of debate.

I'm suggesting improving interoperability by increasing the probability 
that an implementer of average skill will get this part right. Do you 
want a standard that only extremely skilled programmers will have any 
chance of delivering a correct implementation, or do you want a standard 
that most people will be able to do correctly?

I'm really, really glad that I'm not putting up any money to participate 
in this comedy.

Date: Fri, 26 May 2006 08:26:09 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] rfc 2445 - typo correction(s)

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

  SoftDesign Group

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Status of simplification work
Date: Thu, 25 May 2006 21:40:00 +0200
Reply-To: [email-masked]

Hi, 

I am also new to this list.

Am Donnerstag, 25. Mai 2006 15:59 schrieb George Sexton:
> The point here is simplification.

Simplification for whom?

> It will result 
> in a portion of the spec that people either don't comply with, or that
> they do wrong.

By which reason are they doing it wrong?

Changing a spec seems to me as the most comfortable way of not solving a 
problem one faces.
The question should be: Are there good reasons for that rule? Does a change to 
75 characters lead to anything, or does it just mislead? What would you say 
if anybody suggests to change from 75 octets to 75 words (the linguistic 
unit).

Interesting discussion though.:)

Best Regards,

Oliver

Date: Thu, 25 May 2006 19:12:58 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-calsify] Status of simplification work
Sender: [email-masked]
To: George Sexton <[email-masked]>, Chuck Norris <[email-masked]>
Cc: [email-masked]

If we really want to change anything regarding this folding (and henc=
e break backward compatibility with older ical parser/generator), I w=
ould vote for simply removing the 75 octets limit, not change it to 7=
5 characters.

The spec itself does not mention why it puts such a limit. It would b=
e interesting to know the historical reason that made it appear.

About the email legacy MTA problem:
The ical spec is supposed to be "formatted as a registration for a MI=
ME media type". MIME is already describing and taking care of the leg=
acy SMTP server problem. If an application is generating emails conta=
ining ical attachments (or ical directly in the body), it should use =
one of the content-transfer-encoding defined by MIME.=20

About ical being more readable:
The fact that ical is text based is great for debugging purpose. But =
do you usually really care about lengthy text fields when debugging ?
What is the real life use case for this readability of long lines ?
Does the XML specification require folding of lines > 75 octets ? If =
not, did its addoption suffer from it ?

That said, Im not sure it would be wise to break backward compatibili=
ty for this.

Arnaud Q

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> George Sexton
> Envoy=E9 : jeudi 25 mai 2006 16:00
> =C0 : Chuck Norris
> Cc : [email-masked]
> Objet : Re: [Ietf-calsify] Status of simplification work
>=20
>=20
> Actually, I think its a pretty reasonable question. The wrap=20
> requirement=20
> only serves one useful purpose. It makes the files readable in a te=
xt=20
> editor.
>=20
> Any suggestion that the 75 octet limit on lines it makes the=20
> I/O easier=20
> is incorrect. First of all, anyone that's doing line I/O using fixe=
d=20
> width buffers is just waiting for a buffer overflow attack.
>=20
> In this time of multi-megabyte attachments, flash, JPGs, and other=
=20
> binary trash floating across the Internet, suggesting that a 75=
=20
> character line limit is going to accommodate some antique piece of=
=20
> communications hardware just seems unlikely.
>=20
> Personally, I'm really back to where I started. Octets should=20
> be changed=20
> to characters. This will simplify writing correct software=20
> and result in=20
> a file that is human readable in a text editor (or Email client...)=
.
>=20
> The point here is simplification. Proving that the exact=20
> language of the=20
> current specification can be met by adding a function, and some err=
or=20
> prone character break/line wrapping logic does nothing. It=20
> will result=20
> in a portion of the spec that people either don't comply=20
> with, or that=20
> they do wrong. Neither of these improves interoperability.
>=20
>=20
>=20
> Chuck Norris wrote:
> > It's a stupid question probably, but is it even possible to consi=
der
> > removing the fixed line-length requirement?  I know our=20
> parser doesn't=20
> > actually care how many octets are in a line, and works fine=20
> no matter=20
> > how long the lines are.
> >
> > Chuck
> >
> > On May 25, 2006, at 9:00 AM, Reinhold Kainhofer wrote:
> >
>=20
> --=20
> George Sexton
> MH Software, Inc.
> Voice: +1 303 438 9585
>=20
> Ietf-calsify mailing list
> [email-masked]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>=20

Date: Thu, 25 May 2006 17:40:55 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : RE : [Ietf-calsify] Status of simplification work
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>, George Sexton <[email-masked]>, Eliot Lear <[email-masked]>
Cc: ietf-calsify <[email-masked]>

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> Cyrus Daboo
> Envoy=E9 : jeudi 25 mai 2006 15:31
> =C0 : Arnaud Quillaud; George Sexton; Eliot Lear
> Cc : ietf-calsify
> Objet : Re: RE : [Ietf-calsify] Status of simplification work
>=20
>=20
> Hi Arnaud,
>=20
> --On May 25, 2006 11:46:22 AM +0200 Arnaud Quillaud=20
> <[email-masked]> wrote:
>=20
> > So even if you split a 4 bytes UTF8 character by inserting a=20
> > space+CRLF in the middle, the parser at the other end should remo=
ve=20
> > this space+CRLF even before interpreting the stream as UTF-8.
>=20
> But that breaks the utf-8 data stored in a file or sent over=20
> the wire. As=20
> far as I am concerned that is wrong - i.e. you MUST do line=20
> folding such=20
> that the resulting data is valid utf-8 (or valid in whatever=20
> charset is=20
> being used).
>=20
> When I wrote a line folder I arranged it so that it tried to=20
> break at 75=20
> octets, but if that was in the middle of a utf-8 character=20
> sequence it=20
> would step back until it found the starting octet of that=20
> sequence and=20
> break before that.
>=20
> The current spec does make some hint to that by referring to=20
> 'octets' and=20
> 'characters': i.e. 'no longer than 75 octets' and 'split between tw=
o=20
> characters'.

You are correct. It makes the distinction (although, as explained by =
Mark Crispin, this won't guarantee that your editor will show the cor=
rect information).

Arnaud Q

PS: for those who care, libical does split correctly (at the characte=
r level, not at the glyph level).

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

Date: Thu, 25 May 2006 07:59:55 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Chuck Norris <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: [email-masked]

Actually, I think its a pretty reasonable question. The wrap requirement 
only serves one useful purpose. It makes the files readable in a text 
editor.

Any suggestion that the 75 octet limit on lines it makes the I/O easier 
is incorrect. First of all, anyone that's doing line I/O using fixed 
width buffers is just waiting for a buffer overflow attack.

In this time of multi-megabyte attachments, flash, JPGs, and other 
binary trash floating across the Internet, suggesting that a 75 
character line limit is going to accommodate some antique piece of 
communications hardware just seems unlikely.

Personally, I'm really back to where I started. Octets should be changed 
to characters. This will simplify writing correct software and result in 
a file that is human readable in a text editor (or Email client...).

The point here is simplification. Proving that the exact language of the 
current specification can be met by adding a function, and some error 
prone character break/line wrapping logic does nothing. It will result 
in a portion of the spec that people either don't comply with, or that 
they do wrong. Neither of these improves interoperability.

Chuck Norris wrote:
> It's a stupid question probably, but is it even possible to consider 
> removing the fixed line-length requirement?  I know our parser doesn't 
> actually care how many octets are in a line, and works fine no matter 
> how long the lines are.
>
> Chuck
>
> On May 25, 2006, at 9:00 AM, Reinhold Kainhofer wrote:
>

Date: Thu, 25 May 2006 07:57:56 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: [email-masked]

Reinhold Kainhofer wrote:
> ics content is also meant to be sent via email (among other means of data 
> exchange), and some applications even send the iCalendar data as the body of 
> the mail (i.e. not as an attachment). In order to prevent problems with some 
> MTAs, the folding of long lines should not be removed.

Good luck. We have problem in our application because Outlook removes 
what it feels are "extra line-breaks". If you actually viewed an ICS 
file that was copied into outlook, you would find that it would wrap 
some lines onto others.

As much as I laud the intent, when the most common corporate MUA in the 
US is totally broken you might as well throw in the towel on that.

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Chuck Norris <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Date: Thu, 25 May 2006 15:52:03 +0200
Cc: [email-masked]

Am Donnerstag, 25. Mai 2006 15:43 schrieb Chuck Norris:
> It's a stupid question probably, but is it even possible to consider
> removing the fixed line-length requirement?

There is no fixed line-length. Lines SHOULD be not longer than 75 bytes, but 
you can fold them anywhere (or not at all, if you have important reasons).

> I know our parser 
> doesn't actually care how many octets are in a line, and works fine
> no matter how long the lines are.

ics content is also meant to be sent via email (among other means of data 
exchange), and some applications even send the iCalendar data as the body of 
the mail (i.e. not as an attachment). In order to prevent problems with some 
MTAs, the folding of long lines should not be removed.

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, 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/

From: Chuck Norris <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Date: Thu, 25 May 2006 09:43:52 -0400
To: Reinhold Kainhofer <[email-masked]>
Cc: [email-masked]

It's a stupid question probably, but is it even possible to consider  
removing the fixed line-length requirement?  I know our parser  
doesn't actually care how many octets are in a line, and works fine  
no matter how long the lines are.

Chuck

On May 25, 2006, at 9:00 AM, Reinhold Kainhofer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Donnerstag, 25. Mai 2006 11:46 schrieb Arnaud Quillaud:
>> So even if you split a 4 bytes UTF8 character by inserting a space 
>> +CRLF in
>> the middle, the parser at the other end should remove this space 
>> +CRLF even
>> before interpreting the stream as UTF-8.
>
> Exactly, however, this makes the files invalid UTF-8 encoded text- 
> files, so
> editing them in a text editor will typically not work and mess up  
> the events.
> In KOrganizer, we try to split the lines at a word boundary (i.e. at a
> whitespace "character") between 70 and 75 bytes and if that's not  
> possible,
> we use the glyph boundary before 75 bytes. This makes the ics files  
> valid
> text files that are easy to read in a text editor.
>
> However, this should not got into a standard definition, but maybe  
> it should
> be included in a "best practices" FAQ?
>
> Cheers,
> Reionhold
>
> - --
> - ------------------------------------------------------------------
> Reinhold Kainhofer, Vienna, 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/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQFEdaqETqjEwhXvPN0RAhn8AJ43goJFF7oFtwV2nilMgKi3/OU4cACgghc9
> +ayCXSOIcQKHsW+U5Chg8Rs=
> =WqyL
> -----END PGP SIGNATURE-----
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Thu, 25 May 2006 09:31:00 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, George Sexton <[email-masked]>, Eliot Lear <[email-masked]>
Subject: Re: RE : [Ietf-calsify] Status of simplification work
Cc: ietf-calsify <[email-masked]>

Hi Arnaud,

--On May 25, 2006 11:46:22 AM +0200 Arnaud Quillaud 
<[email-masked]> wrote:

> So even if you split a 4 bytes UTF8 character by inserting a space+CRLF
> in the middle, the parser at the other end should remove this space+CRLF
> even before interpreting the stream as UTF-8.

But that breaks the utf-8 data stored in a file or sent over the wire. As 
far as I am concerned that is wrong - i.e. you MUST do line folding such 
that the resulting data is valid utf-8 (or valid in whatever charset is 
being used).

When I wrote a line folder I arranged it so that it tried to break at 75 
octets, but if that was in the middle of a utf-8 character sequence it 
would step back until it found the starting octet of that sequence and 
break before that.

The current spec does make some hint to that by referring to 'octets' and 
'characters': i.e. 'no longer than 75 octets' and 'split between two 
characters'.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Status of simplification work
Date: Thu, 25 May 2006 15:00:49 +0200

Am Donnerstag, 25. Mai 2006 11:46 schrieb Arnaud Quillaud:
> So even if you split a 4 bytes UTF8 character by inserting a space+CRLF in
> the middle, the parser at the other end should remove this space+CRLF even
> before interpreting the stream as UTF-8.

Exactly, however, this makes the files invalid UTF-8 encoded text-files, so 
editing them in a text editor will typically not work and mess up the events. 
In KOrganizer, we try to split the lines at a word boundary (i.e. at a 
whitespace "character") between 70 and 75 bytes and if that's not possible, 
we use the glyph boundary before 75 bytes. This makes the ics files valid 
text files that are easy to read in a text editor.

However, this should not got into a standard definition, but maybe it should 
be included in a "best practices" FAQ?

Cheers,
Reionhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, 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: Thu, 25 May 2006 11:46:22 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-calsify] Status of simplification work
Sender: [email-masked]
To: George Sexton <[email-masked]>, Eliot Lear <[email-masked]>
Cc: ietf-calsify <[email-masked]>

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> George Sexton
> Envoy=E9 : mercredi 24 mai 2006 20:58
> =C0 : Eliot Lear
> Cc : ietf-calsify
> Objet : Re: [Ietf-calsify] Status of simplification work
>=20
>=20
> I just joined the list, so I don't know if this has been addressed.
>=20
> Section 4.1 of RFC-2445 states:
>=20
> .. Lines of text SHOULD NOT be longer than 75 octets...
>=20
> Since the preferred character set is UTF-8, this is pretty=20
> difficult to=20
> do. To actually limit lines correctly would require an intrinsic=
=20
> function in the language to determine the length of each=20
> character, and=20
> if the current length + current char length > 75,wrap the line.

I don't think you need to worry about that.

Section 4.1 "Content Lines" specifies a folding technique and also st=
ates that

<<
When parsing a content line, folded lines MUST **first** be unfolded
   according to the unfolding procedure described above.=20

So even if you split a 4 bytes UTF8 character by inserting a space+CR=
LF in the middle, the parser at the other end should remove this spac=
e+CRLF even before interpreting the stream as UTF-8.

Arnaud Q

>=20
> I program mostly in Java, and I don't know any intrinsic=20
> functions that=20
> give you the length in bytes of a specific Unicode character.
>=20
> In the spirit of simplification, if the wrap recommendation=20
> is kept then=20
> it should be revised to say 75 characters.
>=20
>=20
> --=20
> George Sexton
> MH Software, Inc.
> Voice: +1 303 438 9585
>=20
>=20
>=20
>=20
>=20
> Eliot Lear wrote:
> > Hello Tim from the Calconnect Roundtable in Boston,
> >
> > [CHAIR HAT OFF]
> >
> > I believe the authors are working to deliver updates based on=
=20
> > discussions in Dallas.  This having been said I'm curious=20
> as to what=20
> > you believe needs to be simplified.  We've heard here at CalConne=
ct=20
> > some issues relating to floating times and RRULEs.  What=20
> are your pet=20
> > peeves?
> >
> > Eliot
> > Ietf-calsify mailing list
> > [email-masked]=20
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> >
> >  =20
>=20
> --=20
> George Sexton
> MH Software, Inc.
> Voice: +1 303 438 9585
>=20
> Ietf-calsify mailing list
> [email-masked]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>=20

Date: Wed, 24 May 2006 15:49:26 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: ietf-calsify <[email-masked]>

On Wed, 24 May 2006, George Sexton wrote:
> I always tend to think of characters as the smallest atomic part that a 
> string can be broken into. If I'm doing character based I/O, then a character 
> is the smallest component I can write to the stream (all hail recursive 
> definitions). I rarely, if ever concern myself with typesetting issues.

Unicode breaks that assumption.

For example, consider the German glyph commonly known as "umlaut-a". 
That can be either the Unicode character U+00E4 LATIN SMALL LETTER A WITH 
DIAERESIS or it can be *two* Unicode characters: U+0061 LATIN SMALL LETTER 
A and U+0308 COMBINING DIAERESIS.

In UTF-8, the former is the octet string
 	0xc3 0xa4
and the latter is;
 	0x61 0xcc 0x88
(assuming my notepad calculations are correct).  Of course, if you were 
using good old ISO 8859, it would just be
 	0xe4

The point being is that you can't make any sort of assumptions about
characters or bytes.

Some glyphs (which are what most people mean when they say "character") 
weigh in as being more than a dozen Unicode characters!

Thus, you have to think of "octets", "Unicode characters", and "glyphs".

Now, it is true that many people (myself included) make simplifying 
assumptions for the purpose of their application.  But they have to keep 
track of these assumptions since when (not if) the assumption is broken 
they have to know where to go back and fix....  :-(

-- Mark --

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

Date: Wed, 24 May 2006 14:47:00 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: ietf-calsify <[email-masked]>

Thanks for the function. Clearly you know a great deal more than I do 
about UTF-8 as a character set.

 >> "Characters" are not particularly useful to limit in any case; that 
notion
 >> is hopelessly tied to fixed-width fonts and the notion that a 
"character"
 >> corresponds to a fixed-length field of real estate.  You can only go so
 >> far with that notion, even if you accomodate East Asian characters 
being
 >> double-width ("two characters"), and various marks applied to 
characters

I always tend to think of characters as the smallest atomic part that a 
string can be broken into. If I'm doing character based I/O, then a 
character is the smallest component I can write to the stream (all hail 
recursive definitions). I rarely, if ever concern myself with 
typesetting issues.

Mark Crispin wrote:
> On Wed, 24 May 2006, George Sexton wrote:
>> Since the preferred character set is UTF-8, this is pretty difficult 
>> to do. To actually limit lines correctly would require an intrinsic 
>> function in the language to determine the length of each character, 
>> and if the current length + current char length > 75,wrap the line.
>>
>> I program mostly in Java, and I don't know any intrinsic functions 
>> that give you the length in bytes of a specific Unicode character.
>
> Do you really need an intrinsic function, which it is so easy to write 
> your own?
>
> The following small C function translates a UCS-4 codepoint, including 
> those codepoints which are not in Unicode (that is, those with values 
> 0x110000 - 0x8fffffff), into the corresponding number of UTF-8 
> octets.  It returns 0 for a codepoint which is not in UCS-4.
>
> unsigned long utf8_size (unsigned long c)
> {
>   if (c < 0x80) return 1;
>   else if (c < 0x800) return 2;
>   else if (c < 0x10000) return 3;
>   else if (c < 0x200000) return 4;
>   else if (c < 0x4000000) return 5;
>   else if (c < 0x80000000) return 6;
>   return 0;
> }
>
> A simpler version, covering only Unicode codepoints, is:
>
> unsigned long utf8_size (unsigned long c)
> {
>   if (c < 0x80) return 1;
>   else if (c < 0x800) return 2;
>   else if (c < 0x10000) return 3;
>   else if (c < 0x110000) return 4;
>   return 0;
> }
>
>> In the spirit of simplification, if the wrap recommendation is kept 
>> then it should be revised to say 75 characters.
>
> I suspect that the 75 octet length limitation is for buffer purposes 
> in transport (as in certain email gateways which one hopes are long 
> extinct) and not any sort of "character" limitation.
>
> "Characters" are not particularly useful to limit in any case; that 
> notion is hopelessly tied to fixed-width fonts and the notion that a 
> "character" corresponds to a fixed-length field of real estate.  You 
> can only go so far with that notion, even if you accomodate East Asian 
> characters being double-width ("two characters"), and various marks 
> applied to characters being zero-width ("zero characters").
>
> A "glyph" limit might be useful, but even that is tied up with the 
> notion of fixed-width fonts and is invalidated by scripts such as Arabic.
>
> Of course, to do any of this you have to know how text is actually 
> drawn on the screen, which tends not to be something done at the level 
> of protocols.  Octet counts, on the other hand, are.
>
> Consequently, I recommend that the wrap recommendation be retained, 
> and that sample code such as the above be proved for the benefit of 
> those people who have trouble understanding how to determine the octet 
> length of a Unicode character 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.
>

Date: Wed, 24 May 2006 12:27:07 -0700
From: Mark Crispin <[email-masked]>
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: ietf-calsify <[email-masked]>

On Wed, 24 May 2006, George Sexton wrote:
> Since the preferred character set is UTF-8, this is pretty difficult to do. 
> To actually limit lines correctly would require an intrinsic function in the 
> language to determine the length of each character, and if the current length 
> + current char length > 75,wrap the line.
>
> I program mostly in Java, and I don't know any intrinsic functions that give 
> you the length in bytes of a specific Unicode character.

Do you really need an intrinsic function, which it is so easy to write 
your own?

The following small C function translates a UCS-4 codepoint, including 
those codepoints which are not in Unicode (that is, those with values 
0x110000 - 0x8fffffff), into the corresponding number of UTF-8 octets.  It 
returns 0 for a codepoint which is not in UCS-4.

unsigned long utf8_size (unsigned long c)
{
   if (c < 0x80) return 1;
   else if (c < 0x800) return 2;
   else if (c < 0x10000) return 3;
   else if (c < 0x200000) return 4;
   else if (c < 0x4000000) return 5;
   else if (c < 0x80000000) return 6;
   return 0;
}

A simpler version, covering only Unicode codepoints, is:

unsigned long utf8_size (unsigned long c)
{
   if (c < 0x80) return 1;
   else if (c < 0x800) return 2;
   else if (c < 0x10000) return 3;
   else if (c < 0x110000) return 4;
   return 0;
}

> In the spirit of simplification, if the wrap recommendation is kept then it 
> should be revised to say 75 characters.

I suspect that the 75 octet length limitation is for buffer purposes in 
transport (as in certain email gateways which one hopes are long extinct) 
and not any sort of "character" limitation.

"Characters" are not particularly useful to limit in any case; that notion 
is hopelessly tied to fixed-width fonts and the notion that a "character" 
corresponds to a fixed-length field of real estate.  You can only go so 
far with that notion, even if you accomodate East Asian characters being 
double-width ("two characters"), and various marks applied to characters 
being zero-width ("zero characters").

A "glyph" limit might be useful, but even that is tied up with the notion 
of fixed-width fonts and is invalidated by scripts such as Arabic.

Of course, to do any of this you have to know how text is actually drawn 
on the screen, which tends not to be something done at the level of 
protocols.  Octet counts, on the other hand, are.

Consequently, I recommend that the wrap recommendation be retained, and 
that sample code such as the above be proved for the benefit of those 
people who have trouble understanding how to determine the octet length of 
a Unicode character 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.

Date: Wed, 24 May 2006 12:57:34 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: ietf-calsify <[email-masked]>

I just joined the list, so I don't know if this has been addressed.

Section 4.1 of RFC-2445 states:

.. Lines of text SHOULD NOT be longer than 75 octets...

Since the preferred character set is UTF-8, this is pretty difficult to 
do. To actually limit lines correctly would require an intrinsic 
function in the language to determine the length of each character, and 
if the current length + current char length > 75,wrap the line.

I program mostly in Java, and I don't know any intrinsic functions that 
give you the length in bytes of a specific Unicode character.

In the spirit of simplification, if the wrap recommendation is kept then 
it should be revised to say 75 characters.

Eliot Lear wrote:
> Hello Tim from the Calconnect Roundtable in Boston,
>
> [CHAIR HAT OFF]
>
> I believe the authors are working to deliver updates based on
> discussions in Dallas.  This having been said I'm curious as to what you
> believe needs to be simplified.  We've heard here at CalConnect some
> issues relating to floating times and RRULEs.  What are your pet peeves?
>
> Eliot
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>   

Date: Wed, 24 May 2006 16:42:02 +0200
From: Eliot Lear <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Status of simplification work
Cc: ietf-calsify <[email-masked]>

Hello Tim from the Calconnect Roundtable in Boston,

[CHAIR HAT OFF]

I believe the authors are working to deliver updates based on
discussions in Dallas.  This having been said I'm curious as to what you
believe needs to be simplified.  We've heard here at CalConnect some
issues relating to floating times and RRULEs.  What are your pet peeves?

Eliot

From: "Tim Hare" <[email-masked]>
To: "ietf-calsify" <[email-masked]>
Date: Tue, 23 May 2006 21:27:40 -0400
Subject: [Ietf-calsify] Status of simplification work

This is a multi-part message in MIME format.

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

It's been quite a while since I saw any of the simplification topics
addressed on this mailing list. I know some of the work seems to be being
addressed at the Interops hosted by the Calendaring & Scheduling Consortium,
but it's been a while since I've seen notice of a draft, or discussion of
issues here on the mailing list. 

I wonder if someone could post a quick summary of where the work is in
regard to Calsify, which of the substantial issues appear to have some
resolution, etcetera.

Thanks

Tim

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

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>It&#8217;s been quite a while since I saw any of the
simplification topics addressed on this mailing list. I know some of the =
work
seems to be being addressed at the Interops hosted by the Calendaring =
&amp;
Scheduling Consortium, but it&#8217;s been a while since I&#8217;ve seen =
notice
of a draft, or discussion of issues here on the mailing list. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I wonder if someone could post a quick summary of =
where the
work is in regard to Calsify, which of the substantial issues appear to =
have
some resolution, etcetera.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Tim<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0036_01C67EAF.B9050B90--

Date: Fri, 12 May 2006 11:59:22 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] message from the chairs: proposed changes to this group's charter

This is a multi-part message in MIME format.
--------------010504070107020307080603
Content-Type: multipart/alternative;
	boundary="------------080404030001000100010200"

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

Dear all,

We'd like to take a few minutes of your time to update you on the status
of the Calsify working group.  As you may recall, the working group met
in Dallas, and those minutes have been posted to this list.  At that
meeting it was agreed that instead of advancing rfc244[5,6,7] to Draft
we would instead want to recycle the documents to Proposed Standard. 
The chairs and the authors have been working to put together an updated
charter for your consideration that reflects the expressed will of the
group, and it is attached below.

Here are some key differences between this charter and the previous one:

    * We propose to no longer aim for immediately going to draft
      standard.  Instead we will do another round at Proposed. 
    * We propose to remove the interoperability document from our
      charter.  The interoperability draft blocks other work, and while
      there has been ample time for such a draft to proceed, it has
      not.  Furthermore, if we are recycling to PS, such a document is
      not strictly needed.  Instead, we would incorporate reasoning for
      changes into the standards documents themselves, either near the
      normative text or in appendixes.  Please know that the chairs
      understand the breadth with which these standards are deployed and
      understand the need to undertake change deliberately, and that it
      important to clearly document all changes and their reasons.
    * The milestones have been reworked based on author guidance to what
      they believe is an aggressive yet achievable schedule for this
      group to complete its work by the first quarter of next year. 
      They call for sequential WG last calls, but a simultaneous
      submission to the IESG.  The reasoning for this is that while the
      working group should conduct last calls sequentially, there is the
      possibility of interdependencies between documents.

While the draft charter does not get us to draft standard, it retains
wording about providing transition mechanisms and the chairs believe
this group should be conservative about accepting changes that are not
backward compatible.

We ask for your approval and support of these goals.  In addition we
will undertake the following steps to see to the completion of work by
this group:

    * We will set up an issue tracker to track open issues with each
      document that the group should address.
    * We will have author calls about once every two weeks to see how
      things are going.
    * We will request at least a two hour time slot at the Montreal
      meeting.  The principle agenda for that slot is to go through each
      document's open issues.  It is anticipated that a F2F will also be
      held at the next IETF as well.

We hope that these developments meet with your approval, and that you
will benefit from a stronger set of documents as a result.  We kindly
invite discussion about any of the above.

Sincerely,

Aki & Eliot
WG Chairs

--------------080404030001000100010200
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">
Dear all,<br>
<br>
We'd like to take a few minutes of your time to update you on the
status of the Calsify working group.&nbsp; As you may recall, the working
group met in Dallas, and those minutes have been posted to this list.&nbsp;
At that meeting it was agreed that instead of advancing rfc244[5,6,7]
to Draft we would instead want to recycle the
documents to Proposed Standard.&nbsp; The chairs and the authors have been
working to put together an updated charter for your consideration that
reflects the expressed will of the group, and it is attached below.<br>
<br>
Here are some key differences between this charter and the previous one:<br>
<ul>
  <li>We propose to no longer aim for immediately going to draft
standard.&nbsp; Instead we will do another round at Proposed.&nbsp; <br>
  </li>
  <li>We propose to remove the interoperability document from our
charter.&nbsp; The interoperability draft blocks other work, and while there
has been ample time for such a draft to proceed, it has not.&nbsp;
Furthermore, if we are recycling to PS, such a document is not strictly
needed.&nbsp; Instead, we would incorporate reasoning for changes into the
standards documents themselves, either near the normative text or in
appendixes.&nbsp; Please know that the chairs understand the breadth with
which these standards are deployed and understand the need to undertake
change deliberately, and that it important to clearly document all
changes and their reasons.<br>
  </li>
  <li>The milestones have been reworked based on author guidance to
what they believe is an aggressive yet achievable schedule for this
group to complete its work by the first quarter of next year.&nbsp; They
call for sequential WG last calls, but a simultaneous submission to the
IESG.&nbsp; The reasoning for this is that while the working group should
conduct last calls sequentially, there is the possibility of
interdependencies between documents.</li>
</ul>
While the draft charter does not get us to draft standard, it retains
wording about providing transition mechanisms and the chairs believe
this group should be conservative about accepting changes that are not
backward compatible.<br>
<br>
We ask for your approval and support of these goals.&nbsp; In addition we
will undertake the following steps to see to the completion of work by
this group:<br>
<ul>
  <li>We will set up an issue tracker to track open issues with each
document that the group should address.</li>
  <li>We will have author calls about once every two weeks to see how
things are going.</li>
  <li>We will request at least a two hour time slot at the Montreal
meeting.&nbsp; The principle agenda for that slot is to go through each
document's open issues.&nbsp; It is anticipated that a F2F will also be held
at the next IETF as well.<br>
  </li>
</ul>
We hope that these developments meet with your approval, and that you
will benefit from a stronger set of documents as a result.&nbsp; We kindly
invite discussion about any of the above.<br>
<br>
Sincerely,<br>
<br>
Aki &amp; Eliot<br>
WG Chairs<br>
</body>
</html>

--------------080404030001000100010200--

--------------010504070107020307080603
Content-Type: text/html; x-mac-type="0"; x-mac-creator="0";
	name="calsify-charter.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="calsify-charter.html"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>Calendaring and Scheduling Standards Simplification (calsify) Charter</title></head>
<body style="background-color: rgb(255, 255, 255);"><center>
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr>
<td><a href="/home.html"><img src="/images/header/ietflogo_sm.gif" border="0"></a></td><td><a href="/home.html"><img src="/images/header/home11.gif" border="0"></a></td>
<td><img src="/images/header/separator.gif" border="0"></td><td><a href="/html.charters/wg-dir.html"><img src="/images/header/wg11.gif" border="0"></a></td>
<td><img src="/images/header/separator.gif" border="0"></td><td><a href="/meetings/meetings.html"><img src="/images/header/meetings11.gif" border="0"></a></td>
<td><img src="/images/header/separator.gif" border="0"></td><td><a href="/proceedings/directory.html"><img src="/images/header/proceed11.gif" border="0"></a></td>
<td><img src="/images/header/separator.gif" border="0"></td><td><a href="/ID.html"><img src="/images/header/id-index11.gif" border="0"></a></td>
<td><img src="/images/header/separator.gif" border="0"></td><td><a href="/rfc.html"><img src="/images/header/rfc11.gif" border="0"></a></td>
</tr></tbody></table>
</center><hr>
<h1>Calendaring and Scheduling Standards Simplification (calsify)</h1>
<p>Last Modified: 2006-04-25 <br>
</p><h2>Chair(s):</h2>
<li> <a href="mailto:[email-masked]">Eliot Lear
&lt;[email-masked]&gt;</a>
<br><br></li><li> <a href="mailto:[email-masked]">Aki Niemi
&lt;[email-masked]&gt;</a>
<br><br><h2>Applications Area Director(s):</h2>
</li><li> <a href="mailto:[email-masked]">Ted
Hardie &lt;[email-masked]&gt;</a>
<br></li><li> <a href="mailto:[email-masked]">Lisa Dusseault
&lt;[email-masked]&gt;</a>
<br><h2>Applications Area Advisor:</h2>
</li><li> <a href="mailto:[email-masked]">Lisa
Dusseault &lt;[email-masked]&gt;</a>
<br><h2>Mailing Lists:</h2> General Discussion:
[email-masked]<br>
To Subscribe: <a href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a><br>
Archive: <a href="http://lists.osafoundation.org/pipermail/ietf-calsify/">http://lists.osafoundation.org/pipermail/ietf-calsify/</a><br>
</li>
<h2>Description of Working Group:</h2>
The Calendaring and Scheduling standards, defined in RFC's 2445, 2446,<br>and
2447 were released in November 1998, and further described in RFC<br>3283.
They were designed to progress the level of interoperability<br>between
dissimilar calendaring and scheduling systems. The Calendaring<br>and
Scheduling Core Object Specification, iCalendar, succeeded in<br>establishing
itself as the common format for exchanging calendaring<br>information
across the Internet. On the other hand, only basic<br>interoperability
has been achieved between different scheduling systems.<br><br>The
Calsify working group is chartered to:<br><br>(1) Revise the Calendaring
and Scheduling Standards to advance the<br>state of interoperable
calendaring and scheduling by addressing<br>the known
interoperability issues, &nbsp;errata, and problems found based on<br>implementation experience.<br><br>(2) Clarify
the registration process for iCalendar extensions (i.e.,<br>the
current core object specification only provides a template<br>to
register new properties).<br><br>(3) Provide a means to ease transition from, and to co-exist with,<br>the earlier iCalendar standards to the new ones. <br><br>Proposing an XML representation or
transformation of iCalendar<br>objects is out of the scope of
this working group.<br><br>In the future, it is expected that work will continue towards advancing the<br>calendaring and scheduling standards to Draft Standard. However, this is<br>expected to happen only some time after after the current listed set of charter items<br>have successfully been completed.<br><br>
<h2>Goals and Milestones:</h2>
<table><tbody>
<tr align="left" valign="top"><td></td><td valign="top" width="70">Done</td><td>&nbsp;&nbsp;</td><td>Submit
iMIP bis draft 00 </td></tr>
<tr align="left" valign="top"><td></td><td valign="top" width="70">Done</td><td>&nbsp;&nbsp;</td><td>Submit
iCalendar bis draft 00, with formatting changes from RFC2445. </td></tr>
<tr align="left" valign="top"><td></td><td valign="top" width="70">Done</td><td>&nbsp;&nbsp;</td><td>Submit
iTIP bis draft 00 </td></tr>

<tr align="left" valign="top"><td></td><td valign="top" width="70">June 2006</td><td>&nbsp;&nbsp;</td><td>Submit
updated version of rfc2445bis&nbsp; draft </td></tr>
<tr><td></td><td>June 2006</td><td></td><td>Submit updated version of rfc2446bis draft</td></tr><tr><td></td><td>June 2006</td><td></td><td>Submit updated version of rfc2447bis draft</td></tr><tr align="left" valign="top"><td></td><td valign="top" width="70">Sep 2006</td><td>&nbsp;&nbsp;</td><td>Working Group Last Call on rfc2445bis draft </td></tr>
<tr align="left" valign="top"><td></td><td valign="top" width="70">Oct 2006</td><td>&nbsp;&nbsp;</td><td>Working Group Last Call on rfc2447bis draft</td></tr>

<tr align="left" valign="top"><td></td><td valign="top" width="70">Oct 2006</td><td>&nbsp;&nbsp;</td><td>Working Group Last Call on rfc2446bis draft </td></tr>
<tr align="left" valign="top"><td></td><td valign="top" width="70">Jan 2007</td><td>&nbsp;&nbsp;</td><td>Submit rfc2446bis draft to IESG as Proposed Standard </td></tr>
<tr align="left" valign="top"><td></td><td valign="top" width="70">Jan 2007</td><td>&nbsp;&nbsp;</td><td>Submit rfc2445bis to IESG as Proposed Standard </td></tr>
<tr align="left" valign="top"><td></td><td valign="top" width="70">Jan 2007</td><td>&nbsp;&nbsp;</td><td>Submit rfc2447bis to IESG as a Proposed Standard </td></tr>

</tbody></table><h2>Internet-Drafts:</h2>
<a href="/internet-drafts/draft-ietf-calsify-rfc2447bis-01.txt">
iCalendar Message-Based Interoperability Protocol (iMIP) </a>
(34975 bytes)<br>
<a href="/internet-drafts/draft-ietf-calsify-2446bis-01.txt">
iCalendar Transport-Independent Interoperability Protocol (iTIP) </a>
(296391 bytes)<br>
<a href="/internet-drafts/draft-ietf-calsify-rfc2445bis-00.txt">
Internet Calendaring and Scheduling Core Object Specification
(iCalendar) </a> (295173 bytes)<br>
<h2>No Request For Comments</h2>
<hr><i> IETF Secretariat - Please send questions, comments,
and/or
suggestions to </i>
<a href="mailto:[email-masked]">[email-masked]</a>.
<p><a href="/html.charters/wg-dir.html">
<img src="/icons/back.gif"> Return to working group
directory. </a> </p><p>
<a href="/home.html"><img src="/icons/back.gif">
<img src="/icons/back.gif">
Return to IETF home page. </a>
</p></body></html>
--------------010504070107020307080603--

Date: Mon, 8 May 2006 19:04:29 +0600
From: "Mohammad Rubaiyat" <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] request for digest in regular

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

Dear team / Director Membership

i am very much interested to participate and receive calsify digest issue i=
n
regular, would you please add my mailing list and arrange/ permit me to
receive in regular basis and advice me how i participate on comment
discussion .

Thanking & best regards

Islam M. Rubayat

+ 880 187 521396
Email: [email-masked], [email-masked]

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

<div>
<div style=3D"BORDER-RIGHT: white 1.5pt inset; PADDING-RIGHT: 4pt; BORDER-T=
OP: white 1.5pt inset; PADDING-LEFT: 4pt; BACKGROUND: white; PADDING-BOTTOM=
: 4pt; BORDER-LEFT: white 1.5pt inset; PADDING-TOP: 4pt; BORDER-BOTTOM: whi=
te 1.5pt inset">

<p class=3D"MsoNormal" style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0=
in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN=
: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: m=
edium none; TEXT-ALIGN: justify; mso-border-alt: inset white 1.5pt; mso-pad=
ding-alt: 4.0pt 4.0pt 4.0pt 4.0pt">
<span style=3D"FONT-FAMILY: Arial">Dear team / Director Membership </span><=
/p>
<p class=3D"MsoNormal" style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0=
in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN=
: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: m=
edium none; TEXT-ALIGN: justify; mso-border-alt: inset white 1.5pt; mso-pad=
ding-alt: 4.0pt 4.0pt 4.0pt 4.0pt">
<span style=3D"FONT-FAMILY: Arial">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0=
in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN=
: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: m=
edium none; TEXT-ALIGN: justify; mso-border-alt: inset white 1.5pt; mso-pad=
ding-alt: 4.0pt 4.0pt 4.0pt 4.0pt">
<span style=3D"FONT-FAMILY: Arial">i am very much interested to participate=
 and receive calsify digest issue in regular, would you please add my maili=
ng list and arrange/ permit me to receive in regular basis and advice me ho=
w i participate on comment discussion .
</span></p>
<p class=3D"MsoNormal" style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0=
in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN=
: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: m=
edium none; TEXT-ALIGN: justify; mso-border-alt: inset white 1.5pt; mso-pad=
ding-alt: 4.0pt 4.0pt 4.0pt 4.0pt">
<span style=3D"FONT-FAMILY: Arial">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0=
in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN=
: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: m=
edium none; TEXT-ALIGN: justify; mso-border-alt: inset white 1.5pt; mso-pad=
ding-alt: 4.0pt 4.0pt 4.0pt 4.0pt">
<span style=3D"FONT-FAMILY: Arial">Thanking &amp; best regards </span></p>
<p class=3D"MsoNormal" style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0=
in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN=
: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: m=
edium none; TEXT-ALIGN: justify; mso-border-alt: inset white 1.5pt; mso-pad=
ding-alt: 4.0pt 4.0pt 4.0pt 4.0pt">
<span style=3D"FONT-FAMILY: Arial">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0=
in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN=
: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: m=
edium none; TEXT-ALIGN: justify; mso-border-alt: inset white 1.5pt; mso-pad=
ding-alt: 4.0pt 4.0pt 4.0pt 4.0pt">
<span style=3D"FONT-FAMILY: Arial">Islam M. Rubayat </span></p>
<p class=3D"MsoNormal" style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0=
in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN=
: 0in 0in 0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: m=
edium none; TEXT-ALIGN: justify; mso-border-alt: inset white 1.5pt; mso-pad=
ding-alt: 4.0pt 4.0pt 4.0pt 4.0pt">
<span style=3D"FONT-FAMILY: Arial">+ 880 187 521396</span></p><span style=
=3D"FONT-SIZE: 12pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times Ne=
w Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-l=
anguage: AR-SA">
Email: <a href=3D"mailto:[email-masked]">mohammad.rubaiyat@gma=
il.com</a>, <a href=3D"mailto:[email-masked]">[email-masked]</a> =
</span></div></div>

------=_Part_12147_1704447.1147093469311--

Date: Tue, 02 May 2006 13:41:47 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Please complete the IETF meeting survey

Hello everyone,

The IETF Administrative Director, Ray Pelletier, takes very seriously
his responsibility to improve the IETF.  To do that for meetings, he
needs to understand what has gone well and what has not, and he needs to
understand how he can improve them.  I encourage each of you to take a
few minutes do complete the survey at the following URL:

http://www.surveymonkey.com/s.asp?u=649182049947

You need not have attended IETF65 to express your point of view.

And thanks for your support,

Eliot