From lear at cisco.com Tue May 2 04:41:47 2006 From: lear at cisco.com (Eliot Lear) Date: Tue May 2 04:41:54 2006 Subject: [Ietf-calsify] Please complete the IETF meeting survey Message-ID: <4457457B.3010400@cisco.com> 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 From mohammad.rubaiyat at gmail.com Mon May 8 06:04:29 2006 From: mohammad.rubaiyat at gmail.com (Mohammad Rubaiyat) Date: Mon May 8 06:04:33 2006 Subject: [Ietf-calsify] request for digest in regular Message-ID: Dear team / Director Membership i am very much interested to participate and receive calsify digest issue in 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: mohammad.rubaiyat@gmail.com, mrubaiyat@yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060508/edc3b498/attachment.html From lear at cisco.com Fri May 12 02:59:22 2006 From: lear at cisco.com (Eliot Lear) Date: Fri May 12 02:59:33 2006 Subject: [Ietf-calsify] message from the chairs: proposed changes to this group's charter Message-ID: <44645C7A.2070201@cisco.com> Skipped content of type multipart/alternative-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060512/affe49c8/calsify-charter.html From TimHare at comcast.net Tue May 23 18:27:40 2006 From: TimHare at comcast.net (Tim Hare) Date: Tue May 23 18:27:42 2006 Subject: [Ietf-calsify] Status of simplification work Message-ID: <20060524012740.9C0E0142291@laweleka.osafoundation.org> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060523/cc003448/attachment.htm From lear at cisco.com Wed May 24 07:42:02 2006 From: lear at cisco.com (Eliot Lear) Date: Wed May 24 07:42:03 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <20060524012740.9C0E0142291@laweleka.osafoundation.org> References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> Message-ID: <447470BA.6000805@cisco.com> 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 gsexton at mhsoftware.com Wed May 24 11:57:34 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Wed May 24 11:57:40 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <447470BA.6000805@cisco.com> References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> Message-ID: <4474AC9E.1030903@mhsoftware.com> 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ 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 > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From MRC at CAC.Washington.EDU Wed May 24 12:27:07 2006 From: MRC at CAC.Washington.EDU (Mark Crispin) Date: Wed May 24 12:27:25 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <4474AC9E.1030903@mhsoftware.com> References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> Message-ID: 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. From gsexton at mhsoftware.com Wed May 24 13:47:00 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Wed May 24 13:47:06 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> Message-ID: <4474C644.5020700@mhsoftware.com> 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. > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From MRC at CAC.Washington.EDU Wed May 24 15:49:26 2006 From: MRC at CAC.Washington.EDU (Mark Crispin) Date: Wed May 24 15:49:30 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <4474C644.5020700@mhsoftware.com> References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> <4474C644.5020700@mhsoftware.com> Message-ID: 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 From Arnaud.Quillaud at Sun.COM Thu May 25 02:46:22 2006 From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud) Date: Thu May 25 02:46:38 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <4474AC9E.1030903@mhsoftware.com> Message-ID: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> > -----Message d'origine----- > De : ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] De la part de > George Sexton > Envoy? : mercredi 24 mai 2006 20:58 > ? : Eliot Lear > Cc : ietf-calsify > Objet : Re: [Ietf-calsify] Status of simplification work > > > 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 don't think you need to worry about that. Section 4.1 "Content Lines" specifies a folding technique and also states that << When parsing a content line, folded lines MUST **first** be unfolded according to the unfolding procedure described above. >> 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. Arnaud Q > > 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. > > > -- > George Sexton > MH Software, Inc. > Voice: +1 303 438 9585 > URL: http://www.mhsoftware.com/ > > > > > > 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 > > Ietf-calsify@osafoundation.org > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > -- > George Sexton > MH Software, Inc. > Voice: +1 303 438 9585 > URL: http://www.mhsoftware.com/ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From reinhold at kainhofer.com Thu May 25 06:00:49 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Thu May 25 06:01:58 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> Message-ID: <200605251500.52129.reinhold@kainhofer.com> -----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: reinhold@kainhofer.com, 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----- From cyrus at daboo.name Thu May 25 06:31:00 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu May 25 06:31:09 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> Message-ID: <64115E8409A349C816D438B0@33.78.33.10.in-addr.arpa> Hi Arnaud, --On May 25, 2006 11:46:22 AM +0200 Arnaud Quillaud 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 chuck at evdb.com Thu May 25 06:43:52 2006 From: chuck at evdb.com (Chuck Norris) Date: Thu May 25 06:44:00 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <200605251500.52129.reinhold@kainhofer.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605251500.52129.reinhold@kainhofer.com> Message-ID: 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: reinhold@kainhofer.com, 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 > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From reinhold at kainhofer.com Thu May 25 06:52:03 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Thu May 25 06:53:13 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605251500.52129.reinhold@kainhofer.com> Message-ID: <200605251552.07104.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: reinhold@kainhofer.com, 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) iD8DBQFEdbaHTqjEwhXvPN0RAjcwAJ9c+Jms6QXm2peg4OMjKV5xCcs7PgCgj3N0 QV7TH9yTuIXVxtbRn604ric= =1gIg -----END PGP SIGNATURE----- From gsexton at mhsoftware.com Thu May 25 06:57:56 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Thu May 25 06:58:03 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <200605251552.07104.reinhold@kainhofer.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605251500.52129.reinhold@kainhofer.com> <200605251552.07104.reinhold@kainhofer.com> Message-ID: <4475B7E4.6040908@mhsoftware.com> 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From gsexton at mhsoftware.com Thu May 25 06:59:55 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Thu May 25 06:59:59 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605251500.52129.reinhold@kainhofer.com> Message-ID: <4475B85B.4060006@mhsoftware.com> 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: > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From Arnaud.Quillaud at Sun.COM Thu May 25 08:40:55 2006 From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud) Date: Thu May 25 08:41:16 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <64115E8409A349C816D438B0@33.78.33.10.in-addr.arpa> Message-ID: <0IZT00DV0VKLYQ50@d1-emea-01.sun.com> > -----Message d'origine----- > De : ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] De la part de > Cyrus Daboo > Envoy? : jeudi 25 mai 2006 15:31 > ? : Arnaud Quillaud; George Sexton; Eliot Lear > Cc : ietf-calsify > Objet : Re: RE : [Ietf-calsify] Status of simplification work > > > Hi Arnaud, > > --On May 25, 2006 11:46:22 AM +0200 Arnaud Quillaud > 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'. You are correct. It makes the distinction (although, as explained by Mark Crispin, this won't guarantee that your editor will show the correct information). Arnaud Q PS: for those who care, libical does split correctly (at the character level, not at the glyph level). > > -- > Cyrus Daboo > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From Arnaud.Quillaud at Sun.COM Thu May 25 10:12:58 2006 From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud) Date: Thu May 25 10:13:20 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <4475B85B.4060006@mhsoftware.com> Message-ID: <0IZT005L1ZU0GX70@d1-emea-02.sun.com> If we really want to change anything regarding this folding (and hence break backward compatibility with older ical parser/generator), I would vote for simply removing the 75 octets limit, not change it to 75 characters. The spec itself does not mention why it puts such a limit. It would be 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 MIME media type". MIME is already describing and taking care of the legacy SMTP server problem. If an application is generating emails containing ical attachments (or ical directly in the body), it should use one of the content-transfer-encoding defined by MIME. 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 compatibility for this. Arnaud Q > -----Message d'origine----- > De : ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] De la part de > George Sexton > Envoy? : jeudi 25 mai 2006 16:00 > ? : Chuck Norris > Cc : ietf-calsify@osafoundation.org > Objet : Re: [Ietf-calsify] Status of simplification work > > > 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: > > > > -- > George Sexton > MH Software, Inc. > Voice: +1 303 438 9585 > URL: http://www.mhsoftware.com/ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From lists at block-online.eu Thu May 25 12:40:00 2006 From: lists at block-online.eu (Oliver Block) Date: Thu May 25 12:40:41 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <4475B85B.4060006@mhsoftware.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> Message-ID: <200605252140.00668.lists@block-online.eu> 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 From andrew_dowden at softdesign.net.nz Thu May 25 13:26:09 2006 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Thu May 25 13:26:17 2006 Subject: [Ietf-calsify] rfc 2445 - typo correction(s) Message-ID: <447612E1.1070504@softdesign.net.nz> 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 Dowden Software Associates P O Box 31 132, Lower Hutt 6315, NEW ZEALAND From gsexton at mhsoftware.com Thu May 25 14:30:59 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Thu May 25 14:31:08 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <200605252140.00668.lists@block-online.eu> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> Message-ID: <44762213.4070901@mhsoftware.com> 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) && (i75 { 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From MRC at CAC.Washington.EDU Thu May 25 15:22:17 2006 From: MRC at CAC.Washington.EDU (Mark Crispin) Date: Thu May 25 15:22:25 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <44762213.4070901@mhsoftware.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> Message-ID: 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. From gsexton at mhsoftware.com Thu May 25 15:29:19 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Thu May 25 15:29:26 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> Message-ID: <44762FBF.6050901@mhsoftware.com> 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From TimHare at comcast.net Thu May 25 17:45:11 2006 From: TimHare at comcast.net (Tim Hare) Date: Thu May 25 17:45:13 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <44762FBF.6050901@mhsoftware.com> Message-ID: <20060526004509.E00711422A6@laweleka.osafoundation.org> 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. From sroberts at uniserve.com Thu May 25 23:47:47 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Thu May 25 23:48:22 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <44762213.4070901@mhsoftware.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> Message-ID: <20060526064747.GC657@ensemble.local> Quoting gsexton@mhsoftware.com, 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 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 sroberts at uniserve.com Thu May 25 23:57:15 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Thu May 25 23:57:51 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <64115E8409A349C816D438B0@33.78.33.10.in-addr.arpa> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <64115E8409A349C816D438B0@33.78.33.10.in-addr.arpa> Message-ID: <20060526065715.GD657@ensemble.local> Quoting cyrus@daboo.name, on Thu, May 25, 2006 at 09:31:00AM -0400: > --On May 25, 2006 11:46:22 AM +0200 Arnaud Quillaud > 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 From gsexton at mhsoftware.com Fri May 26 08:14:00 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Fri May 26 08:14:06 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <20060526064747.GC657@ensemble.local> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> Message-ID: <44771B38.3040803@mhsoftware.com> Sam Roberts wrote: > Quoting gsexton@mhsoftware.com, 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> 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From mrc at CAC.Washington.EDU Fri May 26 08:48:09 2006 From: mrc at CAC.Washington.EDU (Mark Crispin) Date: Fri May 26 08:48:22 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <44771B38.3040803@mhsoftware.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> <44771B38.3040803@mhsoftware.com> Message-ID: On Fri, 26 May 2006, George Sexton wrote: >>> for (int i=0; i < data.length; ) { >>> stream.write(data[i++]); >>> if ((i%75==0) && (i>> 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. From gsexton at mhsoftware.com Fri May 26 09:11:21 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Fri May 26 09:11:27 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> <44771B38.3040803@mhsoftware.com> Message-ID: <447728A9.6080001@mhsoftware.com> 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>>> 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From gsexton at mhsoftware.com Fri May 26 09:25:44 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Fri May 26 09:25:49 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> Message-ID: <44772C08.70100@mhsoftware.com> 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 -- -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From mrc at CAC.Washington.EDU Fri May 26 09:36:11 2006 From: mrc at CAC.Washington.EDU (Mark Crispin) Date: Fri May 26 09:36:18 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <44772C08.70100@mhsoftware.com> References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> <44772C08.70100@mhsoftware.com> Message-ID: 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. From lists at block-online.eu Fri May 26 10:52:27 2006 From: lists at block-online.eu (Oliver Block) Date: Fri May 26 10:53:00 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <44762213.4070901@mhsoftware.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> Message-ID: <200605261952.27836.lists@block-online.eu> 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 From helge.hess at opengroupware.org Sat May 27 19:48:36 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Sat May 27 19:51:42 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <447728A9.6080001@mhsoftware.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> <44771B38.3040803@mhsoftware.com> <447728A9.6080001@mhsoftware.com> Message-ID: <6624B0C0-3233-4D56-B48A-F0A7BC9D24EA@opengroupware.org> 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 dave at cridland.net Sun May 28 13:43:31 2006 From: dave at cridland.net (Dave Cridland) Date: Sun May 28 13:43:46 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <6624B0C0-3233-4D56-B48A-F0A7BC9D24EA@opengroupware.org> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> <44771B38.3040803@mhsoftware.com> <447728A9.6080001@mhsoftware.com> <6624B0C0-3233-4D56-B48A-F0A7BC9D24EA@opengroupware.org> Message-ID: <29258.1148849013.925688@peirce.dave.cridland.net> 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:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From lists at block-online.eu Mon May 29 05:18:43 2006 From: lists at block-online.eu (Oliver Block) Date: Mon May 29 05:19:20 2006 Subject: [Ietf-calsify] RFC2445 Corrections Message-ID: <200605291418.44271.lists@block-online.eu> 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 From lear at cisco.com Mon May 29 05:49:53 2006 From: lear at cisco.com (Eliot Lear) Date: Mon May 29 05:49:57 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <20060526004509.E00711422A6@laweleka.osafoundation.org> References: <20060526004509.E00711422A6@laweleka.osafoundation.org> Message-ID: <447AEDF1.5070606@cisco.com> 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 Dave.Thewlis at calconnect.org Mon May 29 06:15:05 2006 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Mon May 29 06:15:10 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <447AEDF1.5070606@cisco.com> References: <20060526004509.E00711422A6@laweleka.osafoundation.org> <447AEDF1.5070606@cisco.com> Message-ID: <447AF3D9.3050602@calconnect.org> 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 > Ietf-calsify@osafoundation.org > 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 ? Dave.Thewlis@calconnect.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060529/05a7dff4/attachment.html From Dave.Thewlis at calconnect.org Mon May 29 06:38:29 2006 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Mon May 29 06:38:35 2006 Subject: [Ietf-calsify] CalConnect problem and recommendations document cited in previous mail In-Reply-To: <447AF69F.3030103@cisco.com> References: <20060526004509.E00711422A6@laweleka.osafoundation.org> <447AEDF1.5070606@cisco.com> <447AF3D9.3050602@calconnect.org> <447AF69F.3030103@cisco.com> Message-ID: <447AF955.40905@calconnect.org> 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 ? Dave.Thewlis@calconnect.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060529/b3bfa751/attachment.htm From andrew_dowden at softdesign.net.nz Mon May 29 14:58:44 2006 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Mon May 29 14:58:51 2006 Subject: [Ietf-calsify] rfc 2445 - recurrence set, suggested rewording Message-ID: <447B6E94.1040902@softdesign.net.nz> 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 sroberts at uniserve.com Mon May 29 21:46:34 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Mon May 29 21:47:11 2006 Subject: [Ietf-calsify] RFC2445 Correction in rrule examples In-Reply-To: <200605291418.44271.lists@block-online.eu> References: <200605291418.44271.lists@block-online.eu> Message-ID: <20060530044633.GA790@ensemble.local> 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 From gsexton at mhsoftware.com Tue May 30 07:24:50 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Tue May 30 07:25:11 2006 Subject: [Ietf-calsify] RDATE Question was (rfc 2445 - recurrence set, suggested rewording) In-Reply-To: <447B6E94.1040902@softdesign.net.nz> References: <447B6E94.1040902@softdesign.net.nz> Message-ID: <447C55B2.4090705@mhsoftware.com> 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. Andrew N Dowden wrote: > 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. > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From lisa at osafoundation.org Tue May 30 11:38:57 2006 From: lisa at osafoundation.org (Lisa Dusseault) Date: Tue May 30 11:39:15 2006 Subject: [Ietf-calsify] Fwd: Atompub WG meeting at the Montreal IETF References: Message-ID: <8AA3DBC2-0F8A-4713-92A3-9EDB86107E12@osafoundation.org> FYI: Calendar format standards and relationship to AtomPub is tentatively on the AtomPub WG agenda in Montreal. Lisa Begin forwarded message: > From: Paul Hoffman > Date: May 23, 2006 1:49:20 PM PDT > To: Atom WG , atom-protocol@imc.org > 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060530/26efe1ca/attachment.htm From andrew_dowden at softdesign.net.nz Tue May 30 14:39:30 2006 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Tue May 30 14:39:36 2006 Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) In-Reply-To: <447C55B2.4090705@mhsoftware.com> References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> Message-ID: <447CBB92.4090801@softdesign.net.nz> George Sexton wrote: > 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? .. I have always considered that DTSTART was used only when necessary .. 4.8.5.3 Recurrence Date/Times (RDATE) .. 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 Dowden Software Associates P O Box 31 132, Lower Hutt 6315, NEW ZEALAND From andrew_dowden at softdesign.net.nz Tue May 30 15:07:52 2006 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Tue May 30 15:07:58 2006 Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) In-Reply-To: <447C55B2.4090705@mhsoftware.com> References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> Message-ID: <447CC238.5070309@softdesign.net.nz> George Sexton wrote: > 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? .. 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 Dowden Software Associates P O Box 31 132, Lower Hutt 6315, NEW ZEALAND From gsexton at mhsoftware.com Wed May 31 06:35:05 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Wed May 31 06:35:14 2006 Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) In-Reply-To: <447CC238.5070309@softdesign.net.nz> References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> <447CC238.5070309@softdesign.net.nz> Message-ID: <447D9B89.40300@mhsoftware.com> 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: Purpose: This property defines the list of date/times for a recurrence set. 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. Andrew N Dowden wrote: > George Sexton wrote: > >> 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? .. >> > > 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. > > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From cyrus at daboo.name Wed May 31 07:47:39 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed May 31 07:47:46 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <20060526064747.GC657@ensemble.local> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> Message-ID: Hi Sam, --On May 25, 2006 11:47:47 PM -0700 Sam Roberts 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 From lear at cisco.com Wed May 31 08:09:32 2006 From: lear at cisco.com (Eliot Lear) Date: Wed May 31 08:09:38 2006 Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) In-Reply-To: <447D9B89.40300@mhsoftware.com> References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> <447CC238.5070309@softdesign.net.nz> <447D9B89.40300@mhsoftware.com> Message-ID: <447DB1AC.1020500@cisco.com> Hi George, > 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: > > Purpose: This property defines the list of date/times for a recurrence > set. > > 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. 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 Wed May 31 08:15:05 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed May 31 08:15:12 2006 Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) In-Reply-To: <447DB1AC.1020500@cisco.com> References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> <447CC238.5070309@softdesign.net.nz> <447D9B89.40300@mhsoftware.com> <447DB1AC.1020500@cisco.com> Message-ID: <9F19EC575518B1A2A7914415@Cyrus-Daboo.local> Hi Eliot, --On May 31, 2006 5:09:32 PM +0200 Eliot Lear wrote: > 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. 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 Wed May 31 08:17:58 2006 From: lear at cisco.com (Eliot Lear) Date: Wed May 31 08:18:02 2006 Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) In-Reply-To: <9F19EC575518B1A2A7914415@Cyrus-Daboo.local> References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> <447CC238.5070309@softdesign.net.nz> <447D9B89.40300@mhsoftware.com> <447DB1AC.1020500@cisco.com> <9F19EC575518B1A2A7914415@Cyrus-Daboo.local> Message-ID: <447DB3A6.9030404@cisco.com> 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 gsexton at mhsoftware.com Wed May 31 11:54:28 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Wed May 31 11:54:36 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> Message-ID: <447DE664.6070504@mhsoftware.com> Cyrus Daboo wrote: > Hi Sam, > > --On May 25, 2006 11:47:47 PM -0700 Sam Roberts > 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? -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From lists at block-online.eu Wed May 31 14:24:12 2006 From: lists at block-online.eu (Oliver Block) Date: Wed May 31 14:24:47 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <447DE664.6070504@mhsoftware.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <447DE664.6070504@mhsoftware.com> Message-ID: <200605312324.13184.lists@block-online.eu> 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 From MRC at CAC.Washington.EDU Wed May 31 14:34:24 2006 From: MRC at CAC.Washington.EDU (Mark Crispin) Date: Wed May 31 14:34:34 2006 Subject: [Ietf-calsify] Status of simplification work In-Reply-To: <200605312324.13184.lists@block-online.eu> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <447DE664.6070504@mhsoftware.com> <200605312324.13184.lists@block-online.eu> Message-ID: 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 TimHare at comcast.net Wed May 31 15:06:55 2006 From: TimHare at comcast.net (Tim Hare) Date: Wed May 31 15:07:09 2006 Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 -recurrence set, suggested rewording) In-Reply-To: <9F19EC575518B1A2A7914415@Cyrus-Daboo.local> Message-ID: <20060531220705.632F814228F@laweleka.osafoundation.org> 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] 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, --On May 31, 2006 5:09:32 PM +0200 Eliot Lear wrote: > 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. 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D261F7F8EA for ; Wed, 31 May 2006 15:07:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C1B68142293 for ; Wed, 31 May 2006 15:07:07 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23866-06 for ; Wed, 31 May 2006 15:07:05 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by laweleka.osafoundation.org (Postfix) with ESMTP id 632F814228F for ; Wed, 31 May 2006 15:07:05 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc14) with SMTP id <20060531220704m14009kt80e>; Wed, 31 May 2006 22:07:04 +0000 From: "Tim Hare" To: "'ietf-calsify'" Subject: RE: [Ietf-calsify] Re: RDATE Question was (rfc 2445 -recurrence set, suggested rewording) Date: Wed, 31 May 2006 18:06:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <9F19EC575518B1A2A7914415@Cyrus-Daboo.local> Thread-Index: AcaExQOSn9+hQsRjSYeei4khm/16bQAOOWUQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <20060531220705.632F814228F@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.9 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID X-Spam-Level: * X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 22:07:07 -0000 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] 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, --On May 31, 2006 5:09:32 PM +0200 Eliot Lear wrote: > 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. 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CBADB7F8D4 for ; Wed, 31 May 2006 14:34:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BCCE1142293 for ; Wed, 31 May 2006 14:34:33 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28848-02 for ; Wed, 31 May 2006 14:34:31 -0700 (PDT) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F63114228E for ; Wed, 31 May 2006 14:34:31 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4VLYSDi010153; Wed, 31 May 2006 14:34:28 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([65.122.177.186]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4VLYQZY013114 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 31 May 2006 14:34:27 -0700 Date: Wed, 31 May 2006 14:34:24 -0700 From: Mark Crispin To: Oliver Block Subject: Re: [Ietf-calsify] Status of simplification work In-Reply-To: <200605312324.13184.lists@block-online.eu> Message-ID: References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <447DE664.6070504@mhsoftware.com> <200605312324.13184.lists@block-online.eu> Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 21:34:33 -0000 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 54EA87F8D2 for ; Wed, 31 May 2006 14:24:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 44DDA142294 for ; Wed, 31 May 2006 14:24:46 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17497-04 for ; Wed, 31 May 2006 14:24:44 -0700 (PDT) Received: from natfrord.rzone.de (natfrord.rzone.de [81.169.145.161]) by laweleka.osafoundation.org (Postfix) with ESMTP id 37A3614228E for ; Wed, 31 May 2006 14:24:43 -0700 (PDT) Received: from ollie.block-gmbh.de (dslb-084-063-163-178.pools.arcor-ip.net [84.63.163.178]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k4VLObOw019553 for ; Wed, 31 May 2006 23:24:40 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Status of simplification work Date: Wed, 31 May 2006 23:24:12 +0200 User-Agent: KMail/1.7.1 References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <447DE664.6070504@mhsoftware.com> In-Reply-To: <447DE664.6070504@mhsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605312324.13184.lists@block-online.eu> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@block-online.eu List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 21:24:46 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 77F487F897 for ; Wed, 31 May 2006 11:54:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A422142293 for ; Wed, 31 May 2006 11:54:33 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04741-07 for ; Wed, 31 May 2006 11:54:31 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DDE17142266 for ; Wed, 31 May 2006 11:54:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 3D0CC1BE90; Wed, 31 May 2006 12:54:30 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11056-04; Wed, 31 May 2006 12:54:29 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 34C7F1BE11; Wed, 31 May 2006 12:54:28 -0600 (MDT) Message-ID: <447DE664.6070504@mhsoftware.com> Date: Wed, 31 May 2006 12:54:28 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Status of simplification work References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 18:54:33 -0000 Cyrus Daboo wrote: > Hi Sam, > > --On May 25, 2006 11:47:47 PM -0700 Sam Roberts > 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? -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AEE137F89E for ; Wed, 31 May 2006 08:18:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A0BBD142296 for ; Wed, 31 May 2006 08:18:01 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27872-07 for ; Wed, 31 May 2006 08:18:00 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by laweleka.osafoundation.org (Postfix) with ESMTP id 40A9B14228C for ; Wed, 31 May 2006 08:18:00 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 31 May 2006 08:18:01 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="323888665:sNHT33521948" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4VFI0kg030814; Wed, 31 May 2006 08:18:00 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4VFHxCU004673; Wed, 31 May 2006 08:17:59 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp307.cisco.com [10.61.65.51]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4VFEbpt015761; Wed, 31 May 2006 08:14:38 -0700 Message-ID: <447DB3A6.9030404@cisco.com> Date: Wed, 31 May 2006 17:17:58 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> <447CC238.5070309@softdesign.net.nz> <447D9B89.40300@mhsoftware.com> <447DB1AC.1020500@cisco.com> <9F19EC575518B1A2A7914415@Cyrus-Daboo.local> In-Reply-To: <9F19EC575518B1A2A7914415@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=283; t=1149088680; x=1149952680; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-calsify]=20Re=3A=20RDATE=20Question=20was=20(rfc=202445=20 -=20recurrence=0A=20set,=09suggested=20rewording); X=v=3Dcisco.com=3B=20h=3DcGkN60a0tpZ8221L2BKTOuXfDN8=3D; b=PHmY7twAvk4szGg7QE4E2D46I9AnX6p2qusgZTSoQq/SeN8XM/4UsQpKBgUX2Vig0uS+NFay EOprVpnMG9XIlqJhBybKVJO8qmoJrz1IVxWXXaZIHUn2exjIwtgCA6SB; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 15:18:01 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6CC5A7F6C2 for ; Wed, 31 May 2006 08:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5EA6E142294 for ; Wed, 31 May 2006 08:15:11 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01345-04 for ; Wed, 31 May 2006 08:15:08 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id D6A1B14228C for ; Wed, 31 May 2006 08:15:08 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id B90FDD68F8A; Wed, 31 May 2006 11:15:07 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 31 May 2006 11:15:08 -0400 X-Sasl-enc: jPPVRxHVwP2kqk5fQLe3As4/j8zjkYqy+5Ve123oj17i 1149088507 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id B58F86F70; Wed, 31 May 2006 11:15:06 -0400 (EDT) Date: Wed, 31 May 2006 11:15:05 -0400 From: Cyrus Daboo To: Eliot Lear , George Sexton Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) Message-ID: <9F19EC575518B1A2A7914415@Cyrus-Daboo.local> In-Reply-To: <447DB1AC.1020500@cisco.com> References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> <447CC238.5070309@softdesign.net.nz> <447D9B89.40300@mhsoftware.com> <447DB1AC.1020500@cisco.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 15:15:11 -0000 Hi Eliot, --On May 31, 2006 5:09:32 PM +0200 Eliot Lear wrote: > 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. 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DE4817F88B for ; Wed, 31 May 2006 08:09:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC02514229C for ; Wed, 31 May 2006 08:09:36 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01379-09 for ; Wed, 31 May 2006 08:09:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by laweleka.osafoundation.org (Postfix) with ESMTP id 60AAB142294 for ; Wed, 31 May 2006 08:09:35 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 08:09:35 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="286134751:sNHT36568324" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4VF9Zw0032197; Wed, 31 May 2006 08:09:35 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4VF9YKP028932; Wed, 31 May 2006 08:09:34 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp307.cisco.com [10.61.65.51]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4VF6Con015545; Wed, 31 May 2006 08:06:13 -0700 Message-ID: <447DB1AC.1020500@cisco.com> Date: Wed, 31 May 2006 17:09:32 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: George Sexton Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> <447CC238.5070309@softdesign.net.nz> <447D9B89.40300@mhsoftware.com> In-Reply-To: <447D9B89.40300@mhsoftware.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=800; t=1149088175; x=1149952175; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-calsify]=20Re=3A=20RDATE=20Question=20was=20(rfc=202445=20 -=20recurrence=0A=20set,=09suggested=20rewording); X=v=3Dcisco.com=3B=20h=3D37WRZGyTKHkoDerJ/nSsr/mknAw=3D; b=X7jqEWUYOR8nMLe6tV/+EFrD0e9V/eZCJQsWTCS9d2ub4mIatvisWo8onqNVXMlMAqg4f1TG Wq57hQjMtYsq+VoIyD4bMLd9mBoMwWRES3pyKm58FjDvaaS/jb/b2Dg3; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 15:09:37 -0000 Hi George, > 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: > > Purpose: This property defines the list of date/times for a recurrence > set. > > 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. 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A8AF27F879 for ; Wed, 31 May 2006 07:47:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 99E9814229C for ; Wed, 31 May 2006 07:47:44 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10718-09 for ; Wed, 31 May 2006 07:47:43 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2468014228E for ; Wed, 31 May 2006 07:47:43 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 9B5DAD692D5; Wed, 31 May 2006 10:47:41 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by frontend3.internal (MEProxy); Wed, 31 May 2006 10:47:42 -0400 X-Sasl-enc: 5+oqaX5o+L8/MzQSen3BHXwzhT+5/W/yQrm9s2XIEpTz 1149086860 Received: from [17.101.35.162] (unknown [17.101.35.162]) by www.fastmail.fm (Postfix) with ESMTP id 15AC111C0; Wed, 31 May 2006 10:47:38 -0400 (EDT) Date: Wed, 31 May 2006 10:47:39 -0400 From: Cyrus Daboo To: Sam Roberts , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Status of simplification work Message-ID: In-Reply-To: <20060526064747.GC657@ensemble.local> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 14:47:44 -0000 Hi Sam, --On May 25, 2006 11:47:47 PM -0700 Sam Roberts 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 294E07F6A1 for ; Wed, 31 May 2006 06:35:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 22F0E14228C for ; Wed, 31 May 2006 06:35:12 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19207-10 for ; Wed, 31 May 2006 06:35:09 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A79E0142260 for ; Wed, 31 May 2006 06:35:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 162711BEA8; Wed, 31 May 2006 07:35:09 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02447-09; Wed, 31 May 2006 07:35:08 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 4A20F1BD8E; Wed, 31 May 2006 07:35:06 -0600 (MDT) Message-ID: <447D9B89.40300@mhsoftware.com> Date: Wed, 31 May 2006 07:35:05 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew N Dowden Subject: Re: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> <447CC238.5070309@softdesign.net.nz> In-Reply-To: <447CC238.5070309@softdesign.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 13:35:13 -0000 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: Purpose: This property defines the list of date/times for a recurrence set. 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. Andrew N Dowden wrote: > George Sexton wrote: > >> 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? .. >> > > 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. > > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D5FE97F78F for ; Tue, 30 May 2006 15:07:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C711E14228E for ; Tue, 30 May 2006 15:07:56 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26306-09 for ; Tue, 30 May 2006 15:07:55 -0700 (PDT) Received: from grunt2.ihug.co.nz (grunt2.ihug.co.nz [203.109.254.42]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F0D714228B for ; Tue, 30 May 2006 15:07:55 -0700 (PDT) Received: from 203-109-180-253.dialup.ihug.co.nz ([127.0.0.1]) [203.109.180.253] by grunt2.ihug.co.nz with asmtp (Exim 3.35 #1 (Debian)) id 1FlCNV-00079K-00; Wed, 31 May 2006 10:07:53 +1200 Message-ID: <447CC238.5070309@softdesign.net.nz> Date: Wed, 31 May 2006 10:07:52 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf-calsify References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> In-Reply-To: <447C55B2.4090705@mhsoftware.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 22:07:56 -0000 George Sexton wrote: > 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? .. 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 Dowden Software Associates P O Box 31 132, Lower Hutt 6315, NEW ZEALAND Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 492247F7A2 for ; Tue, 30 May 2006 14:39:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B12A142286 for ; Tue, 30 May 2006 14:39:35 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03014-02 for ; Tue, 30 May 2006 14:39:33 -0700 (PDT) Received: from grunt15.ihug.co.nz (grunt15.ihug.co.nz [203.109.254.62]) by laweleka.osafoundation.org (Postfix) with ESMTP id B555F142281 for ; Tue, 30 May 2006 14:39:33 -0700 (PDT) Received: from 203-109-180-253.dialup.ihug.co.nz ([127.0.0.1]) [203.109.180.253] by grunt15.ihug.co.nz with asmtp (Exim 3.35 #1 (Debian)) id 1FlBw3-0007xu-00; Wed, 31 May 2006 09:39:32 +1200 Message-ID: <447CBB92.4090801@softdesign.net.nz> Date: Wed, 31 May 2006 09:39:30 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf-calsify References: <447B6E94.1040902@softdesign.net.nz> <447C55B2.4090705@mhsoftware.com> In-Reply-To: <447C55B2.4090705@mhsoftware.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-calsify] Re: RDATE Question was (rfc 2445 - recurrence set, suggested rewording) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 21:39:35 -0000 George Sexton wrote: > 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? .. I have always considered that DTSTART was used only when necessary .. 4.8.5.3 Recurrence Date/Times (RDATE) .. 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 Dowden Software Associates P O Box 31 132, Lower Hutt 6315, NEW ZEALAND Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 358907F72B; Tue, 30 May 2006 11:39:13 -0700 (PDT) Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E479D14228E; Tue, 30 May 2006 11:39:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) To: IETF-iCalendar , CalDAV DevList Message-Id: <8AA3DBC2-0F8A-4713-92A3-9EDB86107E12@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-20-1055929559 References: From: Lisa Dusseault Date: Tue, 30 May 2006 11:38:57 -0700 X-Mailer: Apple Mail (2.749.3) Subject: [Ietf-calsify] Fwd: Atompub WG meeting at the Montreal IETF X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 18:39:13 -0000 --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 > Date: May 23, 2006 1:49:20 PM PDT > To: Atom WG , atom-protocol@imc.org > 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 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 FYI: Calendar format standards = and relationship to AtomPub is tentatively on the AtomPub WG agenda in = Montreal.

Lisa

Begin = forwarded message:

From: = Paul Hoffman <phoffman@imc.org>
Date: = May 23, 2006 1:49:20 PM PDT
To: Atom WG = <atom-syntax@imc.org>, = atom-protocol@imc.org
Subject: = Atompub WG meeting at the Montreal = IETF

=

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
=A0 - = draft-saintandre-atompub-notify
=A0 - Overlap with calendar = formats
=A0 - 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/mee= tings/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-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6C45D7F716 for ; Tue, 30 May 2006 07:25:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5E224142272 for ; Tue, 30 May 2006 07:25:10 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31940-06 for ; Tue, 30 May 2006 07:25:07 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C25C714226B for ; Tue, 30 May 2006 07:25:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 047782914601; Tue, 30 May 2006 08:25:07 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10066-02; Tue, 30 May 2006 08:25:06 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id ADDBA2914324; Tue, 30 May 2006 08:25:02 -0600 (MDT) Message-ID: <447C55B2.4090705@mhsoftware.com> Date: Tue, 30 May 2006 08:24:50 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew N Dowden References: <447B6E94.1040902@softdesign.net.nz> In-Reply-To: <447B6E94.1040902@softdesign.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify Subject: [Ietf-calsify] RDATE Question was (rfc 2445 - recurrence set, suggested rewording) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 14:25:10 -0000 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. Andrew N Dowden wrote: > 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. > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3416F7F744 for ; Mon, 29 May 2006 21:47:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 24E24142272 for ; Mon, 29 May 2006 21:47:10 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28230-01 for ; Mon, 29 May 2006 21:47:07 -0700 (PDT) Received: from priv-edtnes15.telusplanet.net (outbound04.telus.net [199.185.220.223]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6504514226D for ; Mon, 29 May 2006 21:47:07 -0700 (PDT) Received: from priv-edtnaa05.telusplanet.net ([154.20.166.96]) by priv-edtnes15.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060530044706.TTZT11732.priv-edtnes15.telusplanet.net@priv-edtnaa05.telusplanet.net> for ; Mon, 29 May 2006 22:47:06 -0600 Received: from ensemble.local (d154-20-166-96.bchsia.telus.net [154.20.166.96]) by priv-edtnaa05.telusplanet.net (BorderWare MXtreme Infinity Mail Firewall) with ESMTP id 84VU5KM8HM for ; Mon, 29 May 2006 22:47:06 -0600 (MDT) Received: by ensemble.local (Postfix, from userid 501) id 9BE085783CD; Mon, 29 May 2006 21:46:34 -0700 (PDT) Date: Mon, 29 May 2006 21:46:34 -0700 From: Sam Roberts To: ietf-calsify Subject: Re: [Ietf-calsify] RFC2445 Correction in rrule examples Message-ID: <20060530044633.GA790@ensemble.local> Mail-Followup-To: ietf-calsify References: <200605291418.44271.lists@block-online.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605291418.44271.lists@block-online.eu> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.6 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, UPPERCASE_25_50 X-Spam-Level: * X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 04:47:10 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3CE8E7F7F9 for ; Mon, 29 May 2006 14:58:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2E97E142279 for ; Mon, 29 May 2006 14:58:49 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05102-02 for ; Mon, 29 May 2006 14:58:47 -0700 (PDT) Received: from grunt13.ihug.co.nz (grunt13.ihug.co.nz [203.109.254.60]) by laweleka.osafoundation.org (Postfix) with ESMTP id 56AFA142278 for ; Mon, 29 May 2006 14:58:47 -0700 (PDT) Received: from 203-109-177-237.dialup.ihug.co.nz ([127.0.0.1]) [203.109.177.237] by grunt13.ihug.co.nz with asmtp (Exim 3.35 #1 (Debian)) id 1Fkpl7-00082N-00; Tue, 30 May 2006 09:58:45 +1200 Message-ID: <447B6E94.1040902@softdesign.net.nz> Date: Tue, 30 May 2006 09:58:44 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf-calsify Subject: [Ietf-calsify] rfc 2445 - recurrence set, suggested rewording Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 21:58:49 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 86A307F76C for ; Mon, 29 May 2006 06:38:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 778B314228E for ; Mon, 29 May 2006 06:38:34 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02435-02 for ; Mon, 29 May 2006 06:38:31 -0700 (PDT) Received: from fed1rmmtao07.cox.net (fed1rmmtao07.cox.net [68.230.241.32]) by laweleka.osafoundation.org (Postfix) with ESMTP id C03EF14228B for ; Mon, 29 May 2006 06:38:30 -0700 (PDT) Received: from [127.0.0.1] (really [70.191.49.25]) by fed1rmmtao07.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060529133830.UFMN11027.fed1rmmtao07.cox.net@[127.0.0.1]>; Mon, 29 May 2006 09:38:30 -0400 Message-ID: <447AF955.40905@calconnect.org> Date: Mon, 29 May 2006 06:38:29 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf-calsify list References: <20060526004509.E00711422A6@laweleka.osafoundation.org> <447AEDF1.5070606@cisco.com> <447AF3D9.3050602@calconnect.org> <447AF69F.3030103@cisco.com> In-Reply-To: <447AF69F.3030103@cisco.com> Content-Type: multipart/alternative; boundary="------------070506060202040201050202" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, HTML_50_60, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-calsify] CalConnect problem and recommendations document cited in previous mail X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 13:38:34 -0000 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 · Dave.Thewlis@calconnect.org --------------070506060202040201050202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 · Dave.Thewlis@calconnect.org
--------------070506060202040201050202-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E20D17F67F for ; Mon, 29 May 2006 06:15:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CFE0614228B for ; Mon, 29 May 2006 06:15:08 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30007-08 for ; Mon, 29 May 2006 06:15:08 -0700 (PDT) Received: from fed1rmmtao10.cox.net (fed1rmmtao10.cox.net [68.230.241.29]) by laweleka.osafoundation.org (Postfix) with ESMTP id E50FE142278 for ; Mon, 29 May 2006 06:15:07 -0700 (PDT) Received: from [127.0.0.1] (really [70.191.49.25]) by fed1rmmtao10.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060529131507.WTOL18458.fed1rmmtao10.cox.net@[127.0.0.1]>; Mon, 29 May 2006 09:15:07 -0400 Message-ID: <447AF3D9.3050602@calconnect.org> Date: Mon, 29 May 2006 06:15:05 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] Status of simplification work References: <20060526004509.E00711422A6@laweleka.osafoundation.org> <447AEDF1.5070606@cisco.com> In-Reply-To: <447AEDF1.5070606@cisco.com> Content-Type: multipart/alternative; boundary="------------090800060806040001000307" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 13:15:09 -0000 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 > Ietf-calsify@osafoundation.org > 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 · Dave.Thewlis@calconnect.org --------------090800060806040001000307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
Ietf-calsify@osafoundation.org
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 · Dave.Thewlis@calconnect.org
--------------090800060806040001000307-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 750017F76C for ; Mon, 29 May 2006 05:49:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6556414228B for ; Mon, 29 May 2006 05:49:57 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16059-05 for ; Mon, 29 May 2006 05:49:55 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id C6740142287 for ; Mon, 29 May 2006 05:49:55 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 29 May 2006 05:49:47 -0700 X-IronPort-AV: i="4.05,184,1146466800"; d="scan'208"; a="1814695326:sNHT1652955354" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4TCnk5D009501; Mon, 29 May 2006 05:49:46 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4TCnkKP020866; Mon, 29 May 2006 05:49:46 -0700 (PDT) Received: from [192.168.1.103] (che-vpn-cluster-2-184.cisco.com [10.86.242.184]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4TCkWgZ013633; Mon, 29 May 2006 05:46:32 -0700 Message-ID: <447AEDF1.5070606@cisco.com> Date: Mon, 29 May 2006 14:49:53 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Tim Hare Subject: Re: [Ietf-calsify] Status of simplification work References: <20060526004509.E00711422A6@laweleka.osafoundation.org> In-Reply-To: <20060526004509.E00711422A6@laweleka.osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1707; t=1148906986; x=1149770986; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-calsify]=20Status=20of=20simplification=20work; X=v=3Dcisco.com=3B=20h=3DVqcNw6bL/AbABQrqSwJ9QktIyaU=3D; b=a9kEQnXF1zId/hB3WLRua/pj0wRv08txkjOYhK/iG9wruapd4dSNxHPC7/LeurlgdeE3qb5p iP1T4FQ16mMtpQBFCaFCnqljGK/mfE9PZw7isKW83VvqMLkVxA77vP3G; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 12:49:57 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3C3B37F782 for ; Mon, 29 May 2006 05:19:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2AC9F142287 for ; Mon, 29 May 2006 05:19:18 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01651-10 for ; Mon, 29 May 2006 05:19:16 -0700 (PDT) Received: from natsluvver.rzone.de (natsluvver.rzone.de [81.169.145.176]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7941314225C for ; Mon, 29 May 2006 05:19:16 -0700 (PDT) Received: from ollie.block-gmbh.de (dslb-084-063-164-220.pools.arcor-ip.net [84.63.164.220]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k4TCJ9fj010465 for ; Mon, 29 May 2006 14:19:14 +0200 (MEST) From: Oliver Block To: ietf-calsify Date: Mon, 29 May 2006 14:18:43 +0200 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605291418.44271.lists@block-online.eu> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: Subject: [Ietf-calsify] RFC2445 Corrections X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@block-online.eu List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 12:19:18 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4C9687F7A7 for ; Sun, 28 May 2006 13:43:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3E81A142293 for ; Sun, 28 May 2006 13:43:45 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21695-03 for ; Sun, 28 May 2006 13:43:42 -0700 (PDT) Received: from rutherford.zen.co.uk (rutherford.zen.co.uk [212.23.3.142]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6D265142292 for ; Sun, 28 May 2006 13:43:42 -0700 (PDT) Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FkS6u-0006uP-5S; Sun, 28 May 2006 20:43:40 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 9A01C498007; Sun, 28 May 2006 21:46:34 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18597-06; Sun, 28 May 2006 21:46:28 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 9CE2E498006; Sun, 28 May 2006 21:46:28 +0100 (BST) Date: Sun, 28 May 2006 21:43:31 +0100 Subject: Re: [Ietf-calsify] Status of simplification work References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> <44771B38.3040803@mhsoftware.com> <447728A9.6080001@mhsoftware.com> <6624B0C0-3233-4D56-B48A-F0A7BC9D24EA@opengroupware.org> In-Reply-To: <6624B0C0-3233-4D56-B48A-F0A7BC9D24EA@opengroupware.org> MIME-Version: 1.0 Message-Id: <29258.1148849013.925688@peirce.dave.cridland.net> From: Dave Cridland To: Helge Hess Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2006 20:43:45 -0000 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:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F38997F7FD for ; Sat, 27 May 2006 19:51:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E486C142278 for ; Sat, 27 May 2006 19:51:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22938-10 for ; Sat, 27 May 2006 19:51:37 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 01194142281 for ; Sat, 27 May 2006 19:51:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 27C8F3F630F for ; Sun, 28 May 2006 04:49:14 +0200 (CEST) Received: from [192.168.0.233] (unknown [213.187.86.100]) by mail.mdlink.net (Postfix) with ESMTP id 7FC073F6310 for ; Sun, 28 May 2006 04:49:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <447728A9.6080001@mhsoftware.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> <44771B38.3040803@mhsoftware.com> <447728A9.6080001@mhsoftware.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6624B0C0-3233-4D56-B48A-F0A7BC9D24EA@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-calsify] Status of simplification work Date: Sun, 28 May 2006 04:48:36 +0200 To: Calsify X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2006 02:51:41 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 04D1E7F920 for ; Fri, 26 May 2006 10:52:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EAA20142280 for ; Fri, 26 May 2006 10:52:58 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11301-09 for ; Fri, 26 May 2006 10:52:56 -0700 (PDT) Received: from natnoddy.rzone.de (natnoddy.rzone.de [81.169.145.166]) by laweleka.osafoundation.org (Postfix) with ESMTP id EC55714227B for ; Fri, 26 May 2006 10:52:55 -0700 (PDT) Received: from ollie.block-gmbh.de (dslb-084-063-168-192.pools.arcor-ip.net [84.63.168.192]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k4QHqqDj022849 for ; Fri, 26 May 2006 19:52:53 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Status of simplification work Date: Fri, 26 May 2006 19:52:27 +0200 User-Agent: KMail/1.7.1 References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> In-Reply-To: <44762213.4070901@mhsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605261952.27836.lists@block-online.eu> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@block-online.eu List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 17:52:59 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A52C97F92C for ; Fri, 26 May 2006 09:36:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9796E142281 for ; Fri, 26 May 2006 09:36:16 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12699-08 for ; Fri, 26 May 2006 09:36:14 -0700 (PDT) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3466C142280 for ; Fri, 26 May 2006 09:36:14 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4QGaChk032037; Fri, 26 May 2006 09:36:13 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4QGaBEZ024617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 May 2006 09:36:12 -0700 Date: Fri, 26 May 2006 09:36:11 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: George Sexton Subject: Re: [Ietf-calsify] Status of simplification work In-Reply-To: <44772C08.70100@mhsoftware.com> Message-ID: References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> <44772C08.70100@mhsoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 16:36:16 -0000 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7A2177F920 for ; Fri, 26 May 2006 09:25:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6B4D8142281 for ; Fri, 26 May 2006 09:25:48 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24548-04 for ; Fri, 26 May 2006 09:25:47 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 09B34142272 for ; Fri, 26 May 2006 09:25:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 7FC512918C4A; Fri, 26 May 2006 10:25:46 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06591-03; Fri, 26 May 2006 10:25:46 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 8D3522918E01; Fri, 26 May 2006 10:25:45 -0600 (MDT) Message-ID: <44772C08.70100@mhsoftware.com> Date: Fri, 26 May 2006 10:25:44 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mark Crispin Subject: Re: [Ietf-calsify] Status of simplification work References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 16:25:48 -0000 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 -- -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EE0EC7F918 for ; Fri, 26 May 2006 09:11:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE8E3142281 for ; Fri, 26 May 2006 09:11:25 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18448-04 for ; Fri, 26 May 2006 09:11:24 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0DD92142280 for ; Fri, 26 May 2006 09:11:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 8DD262918D78; Fri, 26 May 2006 10:11:23 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06127-06; Fri, 26 May 2006 10:11:23 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id CE7E02902441; Fri, 26 May 2006 10:11:22 -0600 (MDT) Message-ID: <447728A9.6080001@mhsoftware.com> Date: Fri, 26 May 2006 10:11:21 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mark Crispin Subject: Re: [Ietf-calsify] Status of simplification work References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> <44771B38.3040803@mhsoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 16:11:26 -0000 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>>> 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9D9057F558 for ; Fri, 26 May 2006 08:48:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8EDDF14227F for ; Fri, 26 May 2006 08:48:21 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19683-03 for ; Fri, 26 May 2006 08:48:18 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D77CF14225C for ; Fri, 26 May 2006 08:48:18 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4QFmHUO012019; Fri, 26 May 2006 08:48:17 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4QFm90E015918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 May 2006 08:48:16 -0700 Date: Fri, 26 May 2006 08:48:09 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: George Sexton Subject: Re: [Ietf-calsify] Status of simplification work In-Reply-To: <44771B38.3040803@mhsoftware.com> Message-ID: References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> <44771B38.3040803@mhsoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 15:48:21 -0000 On Fri, 26 May 2006, George Sexton wrote: >>> for (int i=0; i < data.length; ) { >>> stream.write(data[i++]); >>> if ((i%75==0) && (i>> 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E9E067F90F for ; Fri, 26 May 2006 08:14:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DC25014228A for ; Fri, 26 May 2006 08:14:04 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00726-10 for ; Fri, 26 May 2006 08:14:02 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 542FB142280 for ; Fri, 26 May 2006 08:14:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id C0CCA2918C48 for ; Fri, 26 May 2006 09:14:01 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04933-05 for ; Fri, 26 May 2006 09:14:01 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 28C1A2917777 for ; Fri, 26 May 2006 09:14:01 -0600 (MDT) Message-ID: <44771B38.3040803@mhsoftware.com> Date: Fri, 26 May 2006 09:14:00 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Status of simplification work References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> <20060526064747.GC657@ensemble.local> In-Reply-To: <20060526064747.GC657@ensemble.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 15:14:05 -0000 Sam Roberts wrote: > Quoting gsexton@mhsoftware.com, 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> 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8E0957F8C4 for ; Thu, 25 May 2006 23:57:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E599142284 for ; Thu, 25 May 2006 23:57:50 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13748-01 for ; Thu, 25 May 2006 23:57:48 -0700 (PDT) Received: from priv-edmwes33.telusplanet.net (defout.telus.net [204.209.205.55]) by laweleka.osafoundation.org (Postfix) with ESMTP id 01D3214228F for ; Thu, 25 May 2006 23:57:47 -0700 (PDT) Received: from priv-edmwaa06.telusplanet.net ([154.20.166.96]) by priv-edmwes33.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060526065747.FKWT17746.priv-edmwes33.telusplanet.net@priv-edmwaa06.telusplanet.net> for ; Fri, 26 May 2006 00:57:47 -0600 Received: from ensemble.local (d154-20-166-96.bchsia.telus.net [154.20.166.96]) by priv-edmwaa06.telusplanet.net (BorderWare MXtreme Infinity Mail Firewall) with ESMTP id F402BPWKCB for ; Fri, 26 May 2006 00:57:46 -0600 (MDT) Received: by ensemble.local (Postfix, from userid 501) id 1E7F8576A1F; Thu, 25 May 2006 23:57:16 -0700 (PDT) Date: Thu, 25 May 2006 23:57:15 -0700 From: Sam Roberts To: ietf-calsify@osafoundation.org Subject: Re: RE : [Ietf-calsify] Status of simplification work Message-ID: <20060526065715.GD657@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <64115E8409A349C816D438B0@33.78.33.10.in-addr.arpa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64115E8409A349C816D438B0@33.78.33.10.in-addr.arpa> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.6 tagged_above=-50.0 required=4.0 tests=DNS_FROM_RFC_POST X-Spam-Level: * X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 06:57:50 -0000 Quoting cyrus@daboo.name, on Thu, May 25, 2006 at 09:31:00AM -0400: > --On May 25, 2006 11:46:22 AM +0200 Arnaud Quillaud > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 51B257F8C3 for ; Thu, 25 May 2006 23:48:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4215814228F for ; Thu, 25 May 2006 23:48:21 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12408-01 for ; Thu, 25 May 2006 23:48:19 -0700 (PDT) Received: from priv-edtnes90.telusplanet.net (defout.telus.net [199.185.220.240]) by laweleka.osafoundation.org (Postfix) with ESMTP id 93803142284 for ; Thu, 25 May 2006 23:48:19 -0700 (PDT) Received: from priv-edtnaa05.telusplanet.net ([154.20.166.96]) by priv-edtnes90.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060526064818.KOFP7546.priv-edtnes90.telusplanet.net@priv-edtnaa05.telusplanet.net> for ; Fri, 26 May 2006 00:48:18 -0600 Received: from ensemble.local (d154-20-166-96.bchsia.telus.net [154.20.166.96]) by priv-edtnaa05.telusplanet.net (BorderWare MXtreme Infinity Mail Firewall) with ESMTP id 87RX2TX2XN for ; Fri, 26 May 2006 00:48:18 -0600 (MDT) Received: by ensemble.local (Postfix, from userid 501) id 379055769C5; Thu, 25 May 2006 23:47:47 -0700 (PDT) Date: Thu, 25 May 2006 23:47:47 -0700 From: Sam Roberts To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Status of simplification work Message-ID: <20060526064747.GC657@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44762213.4070901@mhsoftware.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.6 tagged_above=-50.0 required=4.0 tests=DNS_FROM_RFC_POST X-Spam-Level: * X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 06:48:21 -0000 Quoting gsexton@mhsoftware.com, 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 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5A4FF7F8A3 for ; Thu, 25 May 2006 17:45:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4A0361422A9 for ; Thu, 25 May 2006 17:45:11 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06540-10 for ; Thu, 25 May 2006 17:45:10 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by laweleka.osafoundation.org (Postfix) with ESMTP id E00711422A6 for ; Thu, 25 May 2006 17:45:09 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc14) with SMTP id <20060526004508m1400kodjee>; Fri, 26 May 2006 00:45:08 +0000 From: "Tim Hare" To: "ietf-calsify" Subject: RE: [Ietf-calsify] Status of simplification work Date: Thu, 25 May 2006 20:45:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcaASq3kc0OEXyGKRWKv1urEkVnf2wAEbESA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44762FBF.6050901@mhsoftware.com> Message-Id: <20060526004509.E00711422A6@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.7 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID X-Spam-Level: * X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 00:45:11 -0000 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A45CB7F890 for ; Thu, 25 May 2006 15:29:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 961E51422A9 for ; Thu, 25 May 2006 15:29:22 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08412-05 for ; Thu, 25 May 2006 15:29:21 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2121A1422A6 for ; Thu, 25 May 2006 15:29:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 8D9DB2918B8F; Thu, 25 May 2006 16:29:20 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17669-10; Thu, 25 May 2006 16:29:20 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id D52282918A3E; Thu, 25 May 2006 16:29:19 -0600 (MDT) Message-ID: <44762FBF.6050901@mhsoftware.com> Date: Thu, 25 May 2006 16:29:19 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mark Crispin Subject: Re: [Ietf-calsify] Status of simplification work References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 22:29:22 -0000 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5A1607F87D for ; Thu, 25 May 2006 15:22:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4BD421422A6 for ; Thu, 25 May 2006 15:22:24 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25502-08 for ; Thu, 25 May 2006 15:22:21 -0700 (PDT) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B79541422A5 for ; Thu, 25 May 2006 15:22:21 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4PMMHvi030689; Thu, 25 May 2006 15:22:17 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4PMMFpB032759 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 25 May 2006 15:22:17 -0700 Date: Thu, 25 May 2006 15:22:17 -0700 (Pacific Daylight Time) From: Mark Crispin To: George Sexton Subject: Re: [Ietf-calsify] Status of simplification work In-Reply-To: <44762213.4070901@mhsoftware.com> Message-ID: References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> <44762213.4070901@mhsoftware.com> Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 22:22:24 -0000 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BBEE67F81E for ; Thu, 25 May 2006 14:31:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id ADA941422A6 for ; Thu, 25 May 2006 14:31:05 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03206-03 for ; Thu, 25 May 2006 14:31:03 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D58381422A5 for ; Thu, 25 May 2006 14:31:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 331D22918B59; Thu, 25 May 2006 15:31:02 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16923-07; Thu, 25 May 2006 15:31:01 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 592032918A59; Thu, 25 May 2006 15:31:00 -0600 (MDT) Message-ID: <44762213.4070901@mhsoftware.com> Date: Thu, 25 May 2006 15:30:59 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: lists@block-online.eu Subject: Re: [Ietf-calsify] Status of simplification work References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> <200605252140.00668.lists@block-online.eu> In-Reply-To: <200605252140.00668.lists@block-online.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 21:31:06 -0000 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) && (i75 { 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6D0B47F865 for ; Thu, 25 May 2006 13:26:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5D1331422A5 for ; Thu, 25 May 2006 13:26:15 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19257-07 for ; Thu, 25 May 2006 13:26:14 -0700 (PDT) Received: from grunt6.ihug.co.nz (grunt6.ihug.co.nz [203.109.254.46]) by laweleka.osafoundation.org (Postfix) with ESMTP id CD239142295 for ; Thu, 25 May 2006 13:26:13 -0700 (PDT) Received: from 203-109-176-31.dialup.ihug.co.nz ([127.0.0.1]) [203.109.176.31] by grunt6.ihug.co.nz with asmtp (Exim 3.35 #1 (Debian)) id 1FjMPJ-0000oj-00; Fri, 26 May 2006 08:26:10 +1200 Message-ID: <447612E1.1070504@softdesign.net.nz> Date: Fri, 26 May 2006 08:26:09 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf-calsify Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-calsify] rfc 2445 - typo correction(s) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 20:26:15 -0000 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 Dowden Software Associates P O Box 31 132, Lower Hutt 6315, NEW ZEALAND Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 379AF7F879 for ; Thu, 25 May 2006 12:40:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 26416142293 for ; Thu, 25 May 2006 12:40:41 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10244-09 for ; Thu, 25 May 2006 12:40:39 -0700 (PDT) Received: from nattrymon.rzone.de (nattrymon.rzone.de [81.169.145.178]) by laweleka.osafoundation.org (Postfix) with ESMTP id 870211422A9 for ; Thu, 25 May 2006 12:40:39 -0700 (PDT) Received: from ollie.block-gmbh.de (dslb-084-063-162-059.pools.arcor-ip.net [84.63.162.59]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k4PJeZrf018654 for ; Thu, 25 May 2006 21:40:36 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Status of simplification work Date: Thu, 25 May 2006 21:40:00 +0200 User-Agent: KMail/1.7.1 References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <4475B85B.4060006@mhsoftware.com> In-Reply-To: <4475B85B.4060006@mhsoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605252140.00668.lists@block-online.eu> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.7 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@block-online.eu List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 19:40:41 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A59527F7A6 for ; Thu, 25 May 2006 10:13:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 96DEF1422AF for ; Thu, 25 May 2006 10:13:18 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04312-02 for ; Thu, 25 May 2006 10:13:15 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpea-pix-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id D5B031422AA for ; Thu, 25 May 2006 10:13:14 -0700 (PDT) Received: from d1-emea-02.sun.com (d1-emea-02.sun.com [192.18.2.112] (may be forged)) by gmpea-pix-1.sun.com (8.12.9/8.12.9) with ESMTP id k4PHDDg5016953 for ; Thu, 25 May 2006 18:13:13 +0100 (BST) Received: from conversion-daemon.d1-emea-02.sun.com by d1-emea-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZT00K01XLLIU00@d1-emea-02.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-calsify@osafoundation.org; Thu, 25 May 2006 18:13:13 +0100 (BST) Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.117.223]) by d1-emea-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZT005L0ZTZGX70@d1-emea-02.sun.com>; Thu, 25 May 2006 18:13:13 +0100 (BST) Date: Thu, 25 May 2006 19:12:58 +0200 From: Arnaud Quillaud Subject: RE : [Ietf-calsify] Status of simplification work In-reply-to: <4475B85B.4060006@mhsoftware.com> Sender: Arnaud.Quillaud@Sun.COM To: George Sexton , Chuck Norris Message-id: <0IZT005L1ZU0GX70@d1-emea-02.sun.com> MIME-version: 1.0 X-Mailer: Sun Outlook Connector 7.2.304.0 Content-type: TEXT/PLAIN; CHARSET=Windows-1252 Content-transfer-encoding: QUOTED-PRINTABLE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 17:13:18 -0000 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 : ietf-calsify-bounces@osafoundation.org=20 > [mailto:ietf-calsify-bounces@osafoundation.org] De la part de=20 > George Sexton > Envoy=E9 : jeudi 25 mai 2006 16:00 > =C0 : Chuck Norris > Cc : ietf-calsify@osafoundation.org > 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 > URL: http://www.mhsoftware.com/ >=20 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org=20 > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >=20 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 293B17F7B1 for ; Thu, 25 May 2006 08:41:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1AA0B14228F for ; Thu, 25 May 2006 08:41:14 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13347-08 for ; Thu, 25 May 2006 08:41:12 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpea-pix-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 88B0714229E for ; Thu, 25 May 2006 08:41:11 -0700 (PDT) Received: from d1-emea-01.sun.com ([192.18.2.111]) by gmpea-pix-1.sun.com (8.12.9/8.12.9) with ESMTP id k4PFf94x002040 for ; Thu, 25 May 2006 16:41:10 +0100 (BST) Received: from conversion-daemon.d1-emea-01.sun.com by d1-emea-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZT00201V4SZN00@d1-emea-01.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-calsify@osafoundation.org; Thu, 25 May 2006 16:41:09 +0100 (BST) Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.117.223]) by d1-emea-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZT00DUZVKKYQ50@d1-emea-01.sun.com>; Thu, 25 May 2006 16:41:09 +0100 (BST) Date: Thu, 25 May 2006 17:40:55 +0200 From: Arnaud Quillaud Subject: RE : RE : [Ietf-calsify] Status of simplification work In-reply-to: <64115E8409A349C816D438B0@33.78.33.10.in-addr.arpa> Sender: Arnaud.Quillaud@Sun.COM To: Cyrus Daboo , George Sexton , Eliot Lear Message-id: <0IZT00DV0VKLYQ50@d1-emea-01.sun.com> MIME-version: 1.0 X-Mailer: Sun Outlook Connector 7.2.304.0 Content-type: TEXT/PLAIN; CHARSET=Windows-1252 Content-transfer-encoding: QUOTED-PRINTABLE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 15:41:14 -0000 > -----Message d'origine----- > De : ietf-calsify-bounces@osafoundation.org=20 > [mailto:ietf-calsify-bounces@osafoundation.org] 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 > 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 > Cyrus Daboo >=20 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org=20 > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >=20 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7CDEC7F78A for ; Thu, 25 May 2006 06:59:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6EC1114227E for ; Thu, 25 May 2006 06:59:58 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26389-01 for ; Thu, 25 May 2006 06:59:57 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D47C1142269 for ; Thu, 25 May 2006 06:59:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 5DC9829189E1; Thu, 25 May 2006 07:59:57 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09511-04; Thu, 25 May 2006 07:59:56 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 9B70F2918900; Thu, 25 May 2006 07:59:56 -0600 (MDT) Message-ID: <4475B85B.4060006@mhsoftware.com> Date: Thu, 25 May 2006 07:59:55 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Chuck Norris Subject: Re: [Ietf-calsify] Status of simplification work References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605251500.52129.reinhold@kainhofer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 13:59:58 -0000 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: > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D50767F559 for ; Thu, 25 May 2006 06:58:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BA846142269 for ; Thu, 25 May 2006 06:58:01 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05691-03 for ; Thu, 25 May 2006 06:57:59 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 50833142266 for ; Thu, 25 May 2006 06:57:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id C3350291899C; Thu, 25 May 2006 07:57:58 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09511-03; Thu, 25 May 2006 07:57:58 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id D3D8929189E1; Thu, 25 May 2006 07:57:57 -0600 (MDT) Message-ID: <4475B7E4.6040908@mhsoftware.com> Date: Thu, 25 May 2006 07:57:56 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Reinhold Kainhofer Subject: Re: [Ietf-calsify] Status of simplification work References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605251500.52129.reinhold@kainhofer.com> <200605251552.07104.reinhold@kainhofer.com> In-Reply-To: <200605251552.07104.reinhold@kainhofer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 13:58:01 -0000 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9924D7F78A for ; Thu, 25 May 2006 06:53:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B83F1422B5 for ; Thu, 25 May 2006 06:53:11 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02225-07 for ; Thu, 25 May 2006 06:53:11 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B50751422AF for ; Thu, 25 May 2006 06:53:10 -0700 (PDT) Received: from wiener.fam.tuwien.ac.at (wienernfs [12.0.0.100]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4PDr5Lp010909 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 25 May 2006 15:53:05 +0200 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by wiener.fam.tuwien.ac.at with esmtp (Exim 4.50) id 1FjGGv-0003WO-4E; Thu, 25 May 2006 15:53:05 +0200 From: Reinhold Kainhofer Organization: Vienna University of Technology To: Chuck Norris Subject: Re: [Ietf-calsify] Status of simplification work Date: Thu, 25 May 2006 15:52:03 +0200 User-Agent: KMail/1.9.1 References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605251500.52129.reinhold@kainhofer.com> In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605251552.07104.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.9 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 13:53:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: reinhold@kainhofer.com, 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) iD8DBQFEdbaHTqjEwhXvPN0RAjcwAJ9c+Jms6QXm2peg4OMjKV5xCcs7PgCgj3N0 QV7TH9yTuIXVxtbRn604ric= =1gIg -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 41F177F78A for ; Thu, 25 May 2006 06:43:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30FBD1422B5 for ; Thu, 25 May 2006 06:43:59 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03014-03 for ; Thu, 25 May 2006 06:43:56 -0700 (PDT) Received: from mail.evdb.com (mail.evdb.com [209.126.252.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E8871422AF for ; Thu, 25 May 2006 06:43:56 -0700 (PDT) Received: (qmail 22170 invoked by uid 513); 25 May 2006 06:43:56 -0700 Received: from chuck@evdb.com by mail.evdb.com by uid 511 with qmail-scanner-1.22-st-qms (spamassassin: 2.63. Clear:RC:0(129.42.211.16):SA:0(-4.9/10.0):. Processed in 0.492996 secs); 25 May 2006 13:43:56 -0000 X-Antivirus-MYDOMAIN-Mail-From: chuck@evdb.com via mail.evdb.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(129.42.211.16):SA:0(-4.9/10.0):. Processed in 0.492996 secs Process 22163) Received: from unknown (HELO ?10.33.78.43?) (chuck@evdb.com@129.42.211.16) by mail.evdb.com with RC4-SHA encrypted SMTP; 25 May 2006 06:43:55 -0700 In-Reply-To: <200605251500.52129.reinhold@kainhofer.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> <200605251500.52129.reinhold@kainhofer.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Norris Subject: Re: [Ietf-calsify] Status of simplification work Date: Thu, 25 May 2006 09:43:52 -0400 To: Reinhold Kainhofer X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 13:43:59 -0000 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: reinhold@kainhofer.com, 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 > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0D40E7F784 for ; Thu, 25 May 2006 06:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1EC11422A5 for ; Thu, 25 May 2006 06:31:06 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29093-09 for ; Thu, 25 May 2006 06:31:04 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F1C2142293 for ; Thu, 25 May 2006 06:31:04 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 67EB5D68183; Thu, 25 May 2006 09:31:03 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Thu, 25 May 2006 09:31:03 -0400 X-Sasl-enc: IzJS7Rw2XaZatJ67tNSw41vju68b4sdDxXntMdMqT4oL 1148563863 Received: from [10.33.78.33] (unknown [129.42.211.16]) by www.fastmail.fm (Postfix) with ESMTP id 66F1950A0; Thu, 25 May 2006 09:31:02 -0400 (EDT) Date: Thu, 25 May 2006 09:31:00 -0400 From: Cyrus Daboo To: Arnaud Quillaud , George Sexton , Eliot Lear Subject: Re: RE : [Ietf-calsify] Status of simplification work Message-ID: <64115E8409A349C816D438B0@33.78.33.10.in-addr.arpa> In-Reply-To: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 13:31:07 -0000 Hi Arnaud, --On May 25, 2006 11:46:22 AM +0200 Arnaud Quillaud 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AC6F47F702 for ; Thu, 25 May 2006 06:01:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9E4501422B8 for ; Thu, 25 May 2006 06:01:57 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20921-05 for ; Thu, 25 May 2006 06:01:55 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B12341422B5 for ; Thu, 25 May 2006 06:01:54 -0700 (PDT) Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4PD1ngC003827 for ; Thu, 25 May 2006 15:01:51 +0200 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Status of simplification work Date: Thu, 25 May 2006 15:00:49 +0200 User-Agent: KMail/1.9.1 References: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> In-Reply-To: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605251500.52129.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 13:01:57 -0000 -----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: reinhold@kainhofer.com, 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----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A47FB7F735 for ; Thu, 25 May 2006 02:46:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 960321422A6 for ; Thu, 25 May 2006 02:46:37 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02632-03 for ; Thu, 25 May 2006 02:46:34 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpea-pix-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6B78C14229E for ; Thu, 25 May 2006 02:46:34 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmpea-pix-1.sun.com (8.12.9/8.12.9) with ESMTP id k4P9kWg5006300 for ; Thu, 25 May 2006 10:46:33 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZT00N01F281200@d1-emea-09.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-calsify@osafoundation.org; Thu, 25 May 2006 10:46:32 +0100 (BST) Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.117.9]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZT000SNF5JXRB0@d1-emea-09.sun.com>; Thu, 25 May 2006 10:46:32 +0100 (BST) Date: Thu, 25 May 2006 11:46:22 +0200 From: Arnaud Quillaud Subject: RE : [Ietf-calsify] Status of simplification work In-reply-to: <4474AC9E.1030903@mhsoftware.com> Sender: Arnaud.Quillaud@Sun.COM To: George Sexton , Eliot Lear Message-id: <0IZT000SRF5KXRB0@d1-emea-09.sun.com> MIME-version: 1.0 X-Mailer: Sun Outlook Connector 7.2.304.0 Content-type: TEXT/PLAIN; CHARSET=Windows-1252 Content-transfer-encoding: QUOTED-PRINTABLE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 09:46:37 -0000 > -----Message d'origine----- > De : ietf-calsify-bounces@osafoundation.org=20 > [mailto:ietf-calsify-bounces@osafoundation.org] 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 > URL: http://www.mhsoftware.com/ >=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 > > Ietf-calsify@osafoundation.org=20 > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > =20 >=20 > --=20 > George Sexton > MH Software, Inc. > Voice: +1 303 438 9585 > URL: http://www.mhsoftware.com/ >=20 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org=20 > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >=20 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F2EAB7F708 for ; Wed, 24 May 2006 15:49:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E463F14229A for ; Wed, 24 May 2006 15:49:29 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13445-07 for ; Wed, 24 May 2006 15:49:28 -0700 (PDT) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 59678142293 for ; Wed, 24 May 2006 15:49:28 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4OMnQL3008228; Wed, 24 May 2006 15:49:26 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4OMnPCa005863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 May 2006 15:49:26 -0700 Date: Wed, 24 May 2006 15:49:26 -0700 (Pacific Daylight Time) From: Mark Crispin To: George Sexton Subject: Re: [Ietf-calsify] Status of simplification work In-Reply-To: <4474C644.5020700@mhsoftware.com> Message-ID: References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> <4474C644.5020700@mhsoftware.com> Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, TW_XC X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 22:49:30 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5350A7F707 for ; Wed, 24 May 2006 13:47:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4495114228D for ; Wed, 24 May 2006 13:47:05 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29521-04 for ; Wed, 24 May 2006 13:47:02 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 72E89142289 for ; Wed, 24 May 2006 13:47:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id CD9BA2918710; Wed, 24 May 2006 14:47:01 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21686-07; Wed, 24 May 2006 14:47:01 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id E4CCB290B2F3; Wed, 24 May 2006 14:47:00 -0600 (MDT) Message-ID: <4474C644.5020700@mhsoftware.com> Date: Wed, 24 May 2006 14:47:00 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mark Crispin Subject: Re: [Ietf-calsify] Status of simplification work References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 20:47:05 -0000 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. > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BEA9F7F730 for ; Wed, 24 May 2006 12:27:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B03F5142288 for ; Wed, 24 May 2006 12:27:23 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06560-09 for ; Wed, 24 May 2006 12:27:21 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DD24014227F for ; Wed, 24 May 2006 12:27:20 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4OJRHsX004253; Wed, 24 May 2006 12:27:17 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.6+UW06.03/8.13.6+UW06.03) with ESMTP id k4OJRFNK015415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 May 2006 12:27:17 -0700 Date: Wed, 24 May 2006 12:27:07 -0700 From: Mark Crispin To: George Sexton Subject: Re: [Ietf-calsify] Status of simplification work In-Reply-To: <4474AC9E.1030903@mhsoftware.com> Message-ID: References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> <4474AC9E.1030903@mhsoftware.com> Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 19:27:23 -0000 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. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 77EEF7F6F3 for ; Wed, 24 May 2006 11:57:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6891214228D for ; Wed, 24 May 2006 11:57:39 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13863-04 for ; Wed, 24 May 2006 11:57:36 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C199514227F for ; Wed, 24 May 2006 11:57:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 0C7B429186C3; Wed, 24 May 2006 12:57:36 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14934-07; Wed, 24 May 2006 12:57:35 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 29D3A29184C0; Wed, 24 May 2006 12:57:35 -0600 (MDT) Message-ID: <4474AC9E.1030903@mhsoftware.com> Date: Wed, 24 May 2006 12:57:34 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] Status of simplification work References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> <447470BA.6000805@cisco.com> In-Reply-To: <447470BA.6000805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 18:57:39 -0000 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. -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ 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 > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CE8CF7F6FB for ; Wed, 24 May 2006 07:42:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE03414227F for ; Wed, 24 May 2006 07:42:02 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07197-07 for ; Wed, 24 May 2006 07:42:00 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BDBB14227B for ; Wed, 24 May 2006 07:42:00 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 24 May 2006 07:42:00 -0700 X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="1811983119:sNHT31513560" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4OEfxv1001679; Wed, 24 May 2006 07:41:59 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4OEfxHc010900; Wed, 24 May 2006 07:41:59 -0700 (PDT) Received: from [10.33.78.51] (che-vpn-cluster-1-217.cisco.com [10.86.240.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4OEd3n7015964; Wed, 24 May 2006 07:39:04 -0700 Message-ID: <447470BA.6000805@cisco.com> Date: Wed, 24 May 2006 16:42:02 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Tim Hare Subject: Re: [Ietf-calsify] Status of simplification work References: <20060524012740.9C0E0142291@laweleka.osafoundation.org> In-Reply-To: <20060524012740.9C0E0142291@laweleka.osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=364; t=1148481719; x=1149345719; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-calsify]=20Status=20of=20simplification=20work; X=v=3Dcisco.com=3B=20h=3DEo1AmLGzFTRRjfZyvLnT72Dortg=3D; b=WjczoAg35pbV73ByUP0x+hK/h4co0awXuKtlLXRgBCepN2QdZxp+Irp12Dk9seI/+V4DSsD0 P+Nx0h/AhCyXZ0ndjmHcNcm3VNDSRnX2ieFx2cKcwkfxj+rHXUzVjCoo; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 14:42:02 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 21A3D7F74E for ; Tue, 23 May 2006 18:27:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1338D142292 for ; Tue, 23 May 2006 18:27:41 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29120-03 for ; Tue, 23 May 2006 18:27:40 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9C0E0142291 for ; Tue, 23 May 2006 18:27:40 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc14) with SMTP id <20060524012739m1400dtc1de>; Wed, 24 May 2006 01:27:39 +0000 From: "Tim Hare" To: "ietf-calsify" Date: Tue, 23 May 2006 21:27:40 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C67EAF.B9050B90" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZ+0T82VeeqrjeRQmuFeEW/mjoGSg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <20060524012740.9C0E0142291@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.5 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_MESSAGE, MSGID_FROM_MTA_ID X-Spam-Level: * Subject: [Ietf-calsify] Status of simplification work X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 01:27:41 -0000 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

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-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A01B57F706; Fri, 12 May 2006 02:59:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8A616142290; Fri, 12 May 2006 02:59:31 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15588-08; Fri, 12 May 2006 02:59:28 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4BA2F14228F; Fri, 12 May 2006 02:59:27 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by test-iport-2.cisco.com with ESMTP; 12 May 2006 02:59:27 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4C9xQVQ013584; Fri, 12 May 2006 02:59:26 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4C9xQB7001967; Fri, 12 May 2006 02:59:26 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp675.cisco.com [10.61.66.163]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4C9vEJ6009951; Fri, 12 May 2006 02:57:14 -0700 Message-ID: <44645C7A.2070201@cisco.com> Date: Fri, 12 May 2006 11:59:22 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: multipart/mixed; boundary="------------010504070107020307080603" Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( 56 extraneous bytes; sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=13898; t=1147427966; x=1148291966; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:message=20from=20the=20chairs=3A=20proposed=20changes=20to=20this=20grou p's=20charter; X=v=3Dcisco.com=3B=20h=3DhtmuUkK+ZGn+JV3tSUhI3lgcKdQ=3D; b=Mvylo/7lFjrmmxky70DxJ6EXfoO2uu1+ibfDWBje82mYrRll3bpuITa7HEAubLOSgaMUiyyU F7Vu7hqUN8zCCaTYqeCc99uHAo9ymoDbW0CFgN1M+51bh/vShy+x9C5j; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_50_60, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] message from the chairs: proposed changes to this group's charter X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 09:59:31 -0000 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 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-- --------------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" Calendaring and Scheduling Standards Simplification (calsify) Charter

Calendaring and Scheduling Standards Simplification (calsify)

Last Modified: 2006-04-25

Chair(s):

  • Eliot Lear <lear@cisco.com>

  • Aki Niemi <aki.niemi@nokia.com>

    Applications Area Director(s):

  • Ted Hardie <hardie@qualcomm.com>
  • Lisa Dusseault <lisa@osafoundation.org>

    Applications Area Advisor:

  • Lisa Dusseault <lisa@osafoundation.org>

    Mailing Lists:

    General Discussion: ietf-calsify@osafoundation.org
    To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
    Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/

    • Description of Working Group:

    The Calendaring and Scheduling standards, defined in RFC's 2445, 2446,
    and 2447 were released in November 1998, and further described in RFC
    3283. They were designed to progress the level of interoperability
    between dissimilar calendaring and scheduling systems. The Calendaring
    and Scheduling Core Object Specification, iCalendar, succeeded in
    establishing itself as the common format for exchanging calendaring
    information across the Internet. On the other hand, only basic
    interoperability has been achieved between different scheduling systems.

    The Calsify working group is chartered to:

    (1) Revise the Calendaring and Scheduling Standards to advance the
    state of interoperable calendaring and scheduling by addressing
    the known interoperability issues,  errata, and problems found based on
    implementation experience.

    (2) Clarify the registration process for iCalendar extensions (i.e.,
    the current core object specification only provides a template
    to register new properties).

    (3) Provide a means to ease transition from, and to co-exist with,
    the earlier iCalendar standards to the new ones.

    Proposing an XML representation or transformation of iCalendar
    objects is out of the scope of this working group.

    In the future, it is expected that work will continue towards advancing the
    calendaring and scheduling standards to Draft Standard. However, this is
    expected to happen only some time after after the current listed set of charter items
    have successfully been completed.

    Goals and Milestones:

    Done  Submit iMIP bis draft 00
    Done  Submit iCalendar bis draft 00, with formatting changes from RFC2445.
    Done  Submit iTIP bis draft 00
    June 2006  Submit updated version of rfc2445bis  draft
    June 2006Submit updated version of rfc2446bis draft
    June 2006Submit updated version of rfc2447bis draft
    Sep 2006  Working Group Last Call on rfc2445bis draft
    Oct 2006  Working Group Last Call on rfc2447bis draft
    Oct 2006  Working Group Last Call on rfc2446bis draft
    Jan 2007  Submit rfc2446bis draft to IESG as Proposed Standard
    Jan 2007  Submit rfc2445bis to IESG as Proposed Standard
    Jan 2007  Submit rfc2447bis to IESG as a Proposed Standard

    Internet-Drafts:

    iCalendar Message-Based Interoperability Protocol (iMIP) (34975 bytes)
    iCalendar Transport-Independent Interoperability Protocol (iTIP) (296391 bytes)
    Internet Calendaring and Scheduling Core Object Specification (iCalendar) (295173 bytes)

    No Request For Comments

    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.

    --------------010504070107020307080603-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 19B697F67C for ; Mon, 8 May 2006 06:04:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A1F014228A for ; Mon, 8 May 2006 06:04:31 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32197-01 for ; Mon, 8 May 2006 06:04:30 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by laweleka.osafoundation.org (Postfix) with ESMTP id 45A79142278 for ; Mon, 8 May 2006 06:04:30 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 55so1053534wri for ; Mon, 08 May 2006 06:04:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jnKlwxKsK6rfZ2NrAczDm0PgbW4YCTzRjNNxKycEkMyjFaoOHHctD2SdaZDMI+aVl0o8hRcVvLcyCmLVrVU7dv8mLms58bV/yB46UdWxaRQyh0eUKwufSLqaKj4QjZ+f/pIENSxKxiAdGpJXQ+fBpT+dsJt56Z11DRprgwvz/kw= Received: by 10.54.126.20 with SMTP id y20mr2189565wrc; Mon, 08 May 2006 06:04:29 -0700 (PDT) Received: by 10.54.93.12 with HTTP; Mon, 8 May 2006 06:04:29 -0700 (PDT) Message-ID: Date: Mon, 8 May 2006 19:04:29 +0600 From: "Mohammad Rubaiyat" To: ietf-calsify@osafoundation.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12147_1704447.1147093469311" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=BAYES_20, HTML_90_100, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Subject: [Ietf-calsify] request for digest in regular X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2006 13:04:31 -0000 ------=_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: mohammad.rubaiyat@gmail.com, mrubaiyat@yahoo.com ------=_Part_12147_1704447.1147093469311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

    Dear team / Director Membership <= /p>

     

    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 .

     

    Thanking & best regards

     

    Islam M. Rubayat

    + 880 187 521396

    Email: mohammad.rubaiyat@gma= il.com, mrubaiyat@yahoo.com =
    ------=_Part_12147_1704447.1147093469311-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 04FF77F857 for ; Tue, 2 May 2006 04:41:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E9E90142288 for ; Tue, 2 May 2006 04:41:52 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31124-02 for ; Tue, 2 May 2006 04:41:49 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by laweleka.osafoundation.org (Postfix) with ESMTP id 930F914226C for ; Tue, 2 May 2006 04:41:49 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 02 May 2006 04:41:49 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k42BfnRT014086 for ; Tue, 2 May 2006 04:41:49 -0700 (PDT) Received: from [144.254.22.238] (dhcp-wdata-vlan18-22-238.cisco.com [144.254.22.238]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k42BeFXn018856 for ; Tue, 2 May 2006 04:40:15 -0700 Message-ID: <4457457B.3010400@cisco.com> Date: Tue, 02 May 2006 13:41:47 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=525; t=1146570016; x=1147434016; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Please=20complete=20the=20IETF=20meeting=20survey |To:=22ietf-calsify@osafoundation.org=22=20; X=v=3Dcisco.com=3B=20h=3DsoCXtTNuQXBSpqhp+omhVdND1Wk=3D; b=WABBYxzlTi32C/vJbY1ReGTv91Dfs595PBi25VT0mJcKA5DdOepR6exoeZRQxP7DASordRlU o70KJZubwELvbdslUVHcHLBsxyPkKY00wKwAxrY2d0trzifMo+F9c+Ll; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Please complete the IETF meeting survey X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 11:41:53 -0000 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