From bernard.desruisseaux at oracle.com Fri Sep 1 08:39:58 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Fri Sep 1 08:41:36 2006 Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <8D4D9535660C5B200535BF99@Cyrus-Daboo.local> References: <200608151454.51877.lists@block-online.eu> <200608222104.25563.lists@block-online.eu> <200608230048.47607.lists@block-online.eu> <44EBB9CE.1050800@oracle.com> <1263927117.20060823015902@pobox.com> <44EC6EE5.209@oracle.com> <8D4D9535660C5B200535BF99@Cyrus-Daboo.local> Message-ID: <44F8544E.6090006@oracle.com> Folks, I would like to close this issue with a new proposal. I propose to add the following statement in section 4.1 Content Lines: Folded lines MUST be well-formed according to the character set specified for the iCalendar object. For instance, a UTF-8 multi-octet sequence MUST not be split across lines when UTF-8 is used as the character set. This may require folding a line at less than the recommended 75 octet limit. Old text: > Lines of text SHOULD NOT be longer than 75 octets, excluding the line > break. Long content lines SHOULD be split into a multiple line > representations using a line "folding" technique. That is, a long > line can be split between any two characters by inserting a CRLF > immediately followed by a single linear white space character (i.e., > SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence > of CRLF followed immediately by a single linear white space character > is ignored (i.e., removed) when processing the content type. New text: Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. Long content lines SHOULD be split into a multiple line representations using a line "folding" technique. That is, a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white space character (i.e., SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Folded lines MUST be well-formed according to the character set specified for the iCalendar object. For instance, a UTF-8 multi-octet sequence MUST not be split across lines when UTF-8 is used as the character set. This may require folding a line at less than the recommended 75 octet limit. Any sequence of CRLF followed immediately by a single linear white space character is ignored (i.e., removed) when processing the content type. Cheers, Bernard Cyrus Daboo wrote: > Hi Bernard, > > --On August 23, 2006 11:06:13 AM -0400 Bernard Desruisseaux > wrote: > >> The question is "Do we actually care?". >> >> I would say that as long as the iCalendar stream is a valid >> UTF-8 document we are ok. > > Agreed - my main concern is ensuring that the stream conforms to UTF-8 > abnf - i.e. the characters are all valid. I don't really care whether > the 'raw' unfolded text displays well or not in a text editor. After > all, even in the absence of combining characters, the folding can occur > in the middle of a word and the result may be nonsensical or even worse > appear to be two valid words giving a different meaning to what was meant. > From mrc at CAC.Washington.EDU Fri Sep 1 09:32:29 2006 From: mrc at CAC.Washington.EDU (Mark Crispin) Date: Fri Sep 1 09:32:37 2006 Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <44F8544E.6090006@oracle.com> References: <200608151454.51877.lists@block-online.eu> <200608222104.25563.lists@block-online.eu> <200608230048.47607.lists@block-online.eu> <44EBB9CE.1050800@oracle.com> <1263927117.20060823015902@pobox.com> <44EC6EE5.209@oracle.com> <8D4D9535660C5B200535BF99@Cyrus-Daboo.local> <44F8544E.6090006@oracle.com> Message-ID: On Fri, 1 Sep 2006, Bernard Desruisseaux wrote: > Folded lines MUST be well-formed according to the character set > specified for the iCalendar object. For instance, a UTF-8 multi-octet > sequence MUST not be split across lines when UTF-8 is used as > the character set. This may require folding a line at less than > the recommended 75 octet limit. "UTF-8 multi-octet sequence" is neither a technically accurate nor unambiguous term. It can describe: 1) An entire UTF-8 string, comprised of multiple codepoints (Unicode characters) and multiple glyphs (printed characters). 2) A sequence of octets, interpreted as UTF-8, that comprise a single glyph, but may comprise multiple codepoints. 3) A sequence of octets, interpreted as UTF-8, that comprise a single codepoint. Interpretation (1) is absurd in the context, but it is not precluded by "UTF-8 multi-octet sequence". No matter how absurd a misinterpretation may be, someone someday will use it unless it is precluded. The difference between interpretation (2) and (3) depends upon which criteria is used for "well-formed". Splitting between a character and combining characters is well-formed UTF-8 encoding, but is NOT well-formed Unicode. Many people fail to understand that UTF-8 is NOT a character set; it is an encoding. The character set is Unicode. Therefore, a better wording is: ---------------------------------------------------------------------- Folded lines MUST be well-formed according to the character set specified for the iCalendar object. Folding MUST NOT occur between octets that define a single codepoint in a character set that uses multiple octets to define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian character sets). [Furthermore, folding MUST NOT occur prior to a codepoints that defines a combining character.] This may require folding a line at less than the recommended 75 octet limit. ---------------------------------------------------------------------- The text in [] is used for interpretation (2) but not for interpretation (3). If this working group chooses to use interpretation (3), I question the need for this rule at all. Under interpretation (3), folded text CAN NOT interpreted correctly without first applying unfolding. The two folded strings would be well formed UTF-8 encoding, but it is NOT well formed Unicode. On the other hand, there is a possibility that it may not be possible to fit a well-formed Unicode string, encoded in UTF-8, in 75 octets. This would happen if a single glyph consumes more than 75 octets when encoded in UTF-8. As far as I recall, the record is a glyph that consumes 18 codepoints (all in the BMP, so a maximum of 3 octets/codepoint), and that glyph has a precomposed codepoint in the BMP. So this currently is not a problem. If the sense of the group is that it wants to use interpretion (3) to avoid this (as-yet theoretical problem), and that it is "good enough" to require just well-formed UTF-8 encoding without requiring well-formed Unicode, then I request that there be some text to state this rationale. For example: ---------------------------------------------------------------------- Note: folding is permitted between a character and a combining character. The result of such folding in UTF-8 is well-formed UTF-8; however it is not well-formed Unicode. The string prior to the folding will end with a printed glyph that is not correct (it misses some combining character) and the string subsequent to the folding will start with a combining character which is meaningless in Unicode. Therefore, these strings MUST BE unfolded before displaying them to the user. These foldings are for transport in the iCalendar object, and to keep all strings in the iCalendar object as well-formed transport encodings (e.g., well-formed UTF-8). There is NO guarantee that a folded string is well-formed in the character set; and thus these foldings MUST NOT be used as display foldings. ---------------------------------------------------------------------- -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From lists at block-online.eu Sat Sep 2 03:29:25 2006 From: lists at block-online.eu (Oliver Block) Date: Sat Sep 2 03:30:01 2006 Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> Message-ID: <200609021229.26322.lists@block-online.eu> Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin: > Therefore, a better wording is: > ---------------------------------------------------------------------- > Folded lines MUST be well-formed according to the character set specified > for the iCalendar object. Folding MUST NOT occur between octets that > define a single codepoint in a character set that uses multiple octets to > define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian > character sets). [Furthermore, folding MUST NOT occur prior to a > codepoints that defines a combining character.] This may require > folding a line at less than the recommended 75 octet limit. > ---------------------------------------------------------------------- > > The text in [] is used for interpretation (2) but not for interpretation > (3). This is quite elaborated. But it should IMHO talk of "charset" (RFC2978, Sect. 1.3) not "character set". Unfortunately just replacing "characters set" with "charset" doesn't work as it is used in two different contexts. Best Regards, Oliver -- Leben ist mehr als schneller - weiter - h?her http://www.nak-nrw.de/p_6_4.html From jwn2 at qualcomm.com Thu Sep 7 15:56:51 2006 From: jwn2 at qualcomm.com (John W Noerenberg II) Date: Thu Sep 7 16:07:49 2006 Subject: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional (in the grammar) In-Reply-To: <448DCE85.1020702@osafoundation.org> References: <200606092314.21663.reinhold@kainhofer.com> <448D6A6E.1090006@oracle.com> <448DCE85.1020702@osafoundation.org> Message-ID: At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote: >Given that the RFC was confused, I'd like to put in a vote in favor of >choosing optional for DTSTAMP, not MUST. Lots of iCalendar in the wild >doesn't have a DTSTAMP, and I don't see a compelling reason for >requiring it (although I'd be happy to be informed of compelling reasons). Heck, I'd love to see DTSTAMP's use deprecated. I don't buy there's sufficient difference between CREATED and DTSTAMP to necessitate two different attributes. -- john noerenberg ---------------------------------------------------------------------- It is treason to sacrifice love of truth, intellectual honesty, loyalty to the laws and methods of the mind, to any other interests, including those of one's country. -- Herman Hesse, The Glass Bead Game, 1943 ---------------------------------------------------------------------- From Robert_Ransdell at notesdev.ibm.com Thu Sep 7 16:18:21 2006 From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell) Date: Thu Sep 7 16:18:39 2006 Subject: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional (in the grammar) In-Reply-To: References: <200606092314.21663.reinhold@kainhofer.com> <448D6A6E.1090006@oracle.com> <448DCE85.1020702@osafoundation.org> Message-ID: you will break backward compatibility if you remove DTSTAMP. Its equivalent to Posted Date. John W Noerenberg II Sent by: ietf-calsify-bounces@osafoundation.org 09/07/2006 07:08 PM To Jeffrey Harris cc CALSIFY Mailinglist Subject Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional (in the grammar) At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote: >Given that the RFC was confused, I'd like to put in a vote in favor of >choosing optional for DTSTAMP, not MUST. Lots of iCalendar in the wild >doesn't have a DTSTAMP, and I don't see a compelling reason for >requiring it (although I'd be happy to be informed of compelling reasons). Heck, I'd love to see DTSTAMP's use deprecated. I don't buy there's sufficient difference between CREATED and DTSTAMP to necessitate two different attributes. -- john noerenberg ---------------------------------------------------------------------- It is treason to sacrifice love of truth, intellectual honesty, loyalty to the laws and methods of the mind, to any other interests, including those of one's country. -- Herman Hesse, The Glass Bead Game, 1943 ---------------------------------------------------------------------- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060907/2e21ab28/attachment.htm From TimHare at comcast.net Thu Sep 7 16:31:42 2006 From: TimHare at comcast.net (Tim Hare) Date: Thu Sep 7 16:33:56 2006 Subject: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar) In-Reply-To: Message-ID: <20060907233353.CDEC4142276@laweleka.osafoundation.org> RFC2445 has this to say about DTSTAMP, and about its use vs. CREATED and DATE-MODIFIED -------------------------------------------------------- snip -------------------------------------------------------------------- Conformance: This property MUST be included in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. Description: The value MUST be specified in the UTC time format. This property is also useful to protocols such as [IMIP] that have inherent latency issues with the delivery of content. This property will assist in the proper sequencing of messages containing iCalendar objects. This property is different than the "CREATED" and "LAST-MODIFIED" properties. These two properties are used to specify when the particular calendar data in the calendar store was created and last modified. This is different than when the iCalendar object representation of the calendar service information was created or last modified. -------------------------------------------------------- snip -------------------------------------------------------------------- Also I seem to remember that DTSTAMP is used in iMIP and iTIP to determine the winner in a multiple-updates-received-not-necessarily-in-order scenario. I don't think it can be deprecated without understanding its use in those areas. Tim Hare Interested Bystander, Non-Inc. _____ From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Robert Ransdell Sent: Thursday, September 07, 2006 7:18 PM To: John W Noerenberg II Cc: CALSIFY Mailinglist; ietf-calsify-bounces@osafoundation.org Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar) you will break backward compatibility if you remove DTSTAMP. Its equivalent to Posted Date. John W Noerenberg II Sent by: ietf-calsify-bounces@osafoundation.org 09/07/2006 07:08 PM To Jeffrey Harris cc CALSIFY Mailinglist Subject Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional (in the grammar) At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote: >Given that the RFC was confused, I'd like to put in a vote in favor of >choosing optional for DTSTAMP, not MUST. Lots of iCalendar in the wild >doesn't have a DTSTAMP, and I don't see a compelling reason for >requiring it (although I'd be happy to be informed of compelling reasons). Heck, I'd love to see DTSTAMP's use deprecated. I don't buy there's sufficient difference between CREATED and DTSTAMP to necessitate two different attributes. -- john noerenberg ---------------------------------------------------------------------- It is treason to sacrifice love of truth, intellectual honesty, loyalty to the laws and methods of the mind, to any other interests, including those of one's country. -- Herman Hesse, The Glass Bead Game, 1943 ---------------------------------------------------------------------- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060907/7b81a24b/attachment.htm From jwn2 at qualcomm.com Thu Sep 7 17:52:01 2006 From: jwn2 at qualcomm.com (John W Noerenberg II) Date: Thu Sep 7 17:52:45 2006 Subject: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar) In-Reply-To: <20060907233353.CDEC4142276@laweleka.osafoundation.org> References: <20060907233353.CDEC4142276@laweleka.osafoundation.org> Message-ID: At 7:31 PM -0400 9/7/06, Tim Hare wrote: > >RFC2445 has this to say about DTSTAMP, and about its use vs. >CREATED and DATE-MODIFIED I know what the RFC says. :-) My point is the definitions (despite the RFC's claim to the contrary) are indistinguishable. In practice both CREATED and DTSTAMP invariably have the same value. It's pointless redundancy. One or the other should go. If DTSTAMP is needed for backward compatibility then keep that instead and deprecate CREATED. From lear at cisco.com Fri Sep 8 03:06:26 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 8 03:06:39 2006 Subject: [Ietf-calsify] a message from the chairs Message-ID: <450140A2.70405@cisco.com> Hello everyone, I would like to again direct your attention to http://www.ofcourseimright.com/cgi-bin/roundup/calsify. These are the open issues for RFC2445bis. To move things along, Aki and I are going to sift through each issue to see what is needed to resolve them. Aki will start at the top issue (number 1) and I will start at the bottom (currently #40) and we will work our way towards each other. Depending on mailing list content, we will take one of several actions: 1. Close the issue because Bernard has dealt with it; 2. Propose the issue be closed if there is no text; 3. Propose the issue be closed if there is text but no discussion; or 4. Encourage conclusion of discussion so we can close an issue that has both text and discussion. Any issue can be moved to state (4) with proposal of text, based on a reply to our messages. If there is no text to discuss then it is pointless to argue the issue. Anyone can open a new issue - FOR NOW. We would like WGLC to not be too far away. There are some overlapping issues in the tracker. I beg your indulgence to help me find these and to suggest an appropriate action. On behalf of Aki, thanks for your participation! Eliot From lear at cisco.com Fri Sep 8 03:11:30 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 8 03:11:36 2006 Subject: [Ietf-calsify] Propose to close issues 37, 38, 39 Message-ID: <450141D2.9040601@cisco.com> Each of these issues has proposed text and there has been no objection to it. 37 4.6.1 Event Component: eventprop > eventprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / dtstart / uid / > > ; the following are optional, > ; but MUST NOT occur more than once No objections. 38 VTODO todoprop > todoprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once > > ... No objections. 39 VJOURNAL journalprop > jourprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once No objections. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060908/c751c620/attachment.htm From lear at cisco.com Fri Sep 8 03:12:54 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 8 03:13:04 2006 Subject: [Ietf-calsify] request for more discussion on issue 40 Message-ID: <45014226.2040704@cisco.com> At this time the issue is open and there is no consensus on text. If no discussion occurs we will close the issue without changes to text. Eliot 40 4.6.4 f/b component/ fbprop > fbprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once > > ... No consensus as to what uid means in this context. From lear at cisco.com Fri Sep 8 03:15:12 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 8 03:15:22 2006 Subject: [Ietf-calsify] Propose to close issue 36 - X-Name / bilateral agreements Message-ID: <450142B0.5020208@cisco.com> No consensus for change as of now. Barring more discussion, the text will remain unchanged, without reference to bilateral agreements. Eliot 36 X-name > x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > ; Reserved for non-standard names. Can be used by bilateral > ; agreement. No consensus on what bilateral means in this context. From reinhold at kainhofer.com Fri Sep 8 03:25:36 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Fri Sep 8 03:25:46 2006 Subject: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP =?iso-8859-1?q?=09being?= optional(in the grammar) In-Reply-To: References: <20060907233353.CDEC4142276@laweleka.osafoundation.org> Message-ID: <200609081225.37154.reinhold@kainhofer.com> Am Freitag, 8. September 2006 02:52 schrieb John W Noerenberg II: > At 7:31 PM -0400 9/7/06, Tim Hare wrote: > >RFC2445 has this to say about DTSTAMP, and about its use vs. > >CREATED and DATE-MODIFIED > > I know what the RFC says. :-) My point is the definitions (despite > the RFC's claim to the contrary) are indistinguishable. In practice > both CREATED and DTSTAMP invariably have the same value. Sorry, but that's not true. If I created an event yesterdayday, sent out an invitation and today get some confirmations back, the event will have CREATED:20060908.... DATE-MODIFIED:20060909... (Explanation: The event was created yesterday in the storage (which might either be a flat file, a groupware server or something else), and it was modified today, which does not create a new event.) If you now tomorrow publish that event to some other group of people or so (i.e. send a mail with METHOD:PUBLISH), the calendar that you send out will have the above CREATED and DATE-MODIFIED (provided that you didn't modify it meanwhile in the calendar store), but as that particular invitation will be created tomorrow, it will have DTSTAMP:20060910... So, these three settings are in deed different. The CREATED will never change once the event is by the organizer, the DATE-MODIFIED is only changed when you modify the event, and the DTSTAMP is the time when you create that particular invitation or export from the calendar server. Cheers, Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: 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/ From lear at cisco.com Fri Sep 8 04:20:19 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 8 04:20:26 2006 Subject: [Ietf-calsify] Propose Close Issue 35: 4.2.10 language tag Message-ID: <450151F3.5070106@cisco.com> This issue has proposed text and there has been no objection. 35 Section 4.2.10 language / language property Proposed new text: > Description: The parameter identifies the language of the text in > the property or property parameter value. The value of the "language" > property parameter is that defined in [RFC 1766]. possible consensus. need to update RFC reference. More discussion needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060908/be7791b1/attachment.html From sroberts at uniserve.com Fri Sep 8 09:45:46 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Fri Sep 8 09:45:51 2006 Subject: [Ietf-calsify] Propose to close issue 36 - X-Name / bilateral agreements In-Reply-To: <450142B0.5020208@cisco.com> References: <450142B0.5020208@cisco.com> Message-ID: <20060908164546.GA1369@pebble> On Fri, Sep 08, 2006 at 12:15:12PM +0200, Eliot Lear wrote: > No consensus for change as of now. > > Barring more discussion, the text will remain unchanged, without > reference to bilateral agreements. What X- fields mean and whether to allow them was beat to a bloody death during rfc2822, but they got rid of X- fields, so iCal can't copy their text! I don't want to keep the issue open if the consensus is that te text is fine, but I think including recommendations on use of a feature is helpful for interoperability, so can I propose: Vendor-defined names may appear in iCalendar by using a naming pattern guaranteed not to conflict with any names that may be standardized in the future. There is no registry for vendorid, so there is no guarantee names defined by one vendor won't conflict with names defined by another. I think that describes why it's here, and you/we could perhaps add some guidance: Vendors SHOULD NOT use vendor-defined names in iTIP, it discourages inter-operability. If a vendor finds it necessary to extend iCal with vendor-defined names, it is recommended to submit a to the to standardize this usage with a non-vendor defined name. Some vendors use iCalendar as a internal storage format, and vendor-defined names are useful in this context, but SHOULD be removed before exchanging the calendars with other implementations. I think the above is the "well-known understanding" of X- fields, if the list agrees, I'd like to see it written down. I don't like the use of "vendor", btw, what if the implementation isn't vended? :-) How about s/vendor/implementation/g? Cheers, Sam > Eliot > > 36 > X-name > > > > x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > > ; Reserved for non-standard names. Can be used by bilateral > > ; agreement. > > > No consensus on what bilateral means in this context. From ned.freed at mrochek.com Tue Sep 5 11:59:07 2006 From: ned.freed at mrochek.com (Ned Freed) Date: Mon Sep 11 09:20:46 2006 Subject: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: "Your message dated Mon, 21 Aug 2006 20:10:12 +0100" <44EA0514.609@isode.com> References: <44E9FD8D.8070904@oracle.com> <44EA008D.5060909@isode.com> <44EA0514.609@isode.com> Message-ID: <01M6UGLIKKDG0008CX@mauve.mrochek.com> > Mark Crispin wrote: > > On Mon, 21 Aug 2006, Alexey Melnikov wrote: > > > >>> If any revision is made, it should be to delete US-ASCII and make > >>> UTF-8 mandatory. > >> > >> However we can't do this, as absence of the charset parameter means > >> US-ASCII. > >> So any iCalendar object in UTF-8 MUST have charset=utf-8. > > > > That's unfortunate. I admit that I am not up to speed on this > > specification; is there really no way to fix this problem? > To clarify, the default charset=US-ASCII comes from MIME specs. > I am not sure if text/calendar can change the default character set > used. Somebody with better MIME expertise should clarify this. This is a tricky point in MIME. The idea behind the text top-level type was in part to support fallback display of textual material even when the specific type isn't understood. To this end, text types are required to use the charset parameter in a manner that's compatible with text/plain. text/plain uses the charset parameter to specify the charset (duh) and has a default of US-ASCII. See RFC 2046 section 4.1.2 for specifics. In any case, RFC 2046 recommands but does not actually require that all text types have the same default of US-ASCII. And pretty much the first other text subtype, text/html, opted for iso-8859-1 as it's default. In retrospect UTF-8 would have been a better choice for both text/plain and text/html, but please remember that UTF-8 didn't even exist at the time this stuff was defined. So what's the right course of action? I think the right thing to do is make the default UTF-8 but strongly recommend that the charset parameter be present. > > If there is some way of defining the charset as always being UTF-8, > > then charset parameters can be removed from the specification as > > extraneous. > Yes, that would be nice. Nice but not really possible. See above. Ned From sroberts at uniserve.com Mon Sep 11 09:38:48 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Mon Sep 11 09:39:35 2006 Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <200609021229.26322.lists@block-online.eu> References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> <200609021229.26322.lists@block-online.eu> Message-ID: <20060911163847.GA443@ensemble.local> Quoting lists@block-online.eu, on Sat, Sep 02, 2006 at 12:29:25PM +0200: > Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin: > > Therefore, a better wording is: > > ---------------------------------------------------------------------- > > Folded lines MUST be well-formed according to the character set specified > > for the iCalendar object. Folding MUST NOT occur between octets that > > define a single codepoint in a character set that uses multiple octets to > > define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian > > character sets). [Furthermore, folding MUST NOT occur prior to a > > codepoints that defines a combining character.] This may require > > folding a line at less than the recommended 75 octet limit. > > ---------------------------------------------------------------------- Is the "[Furthermore,...combining character.]" text supposed to be part of the the wording? It appears that there are combining characters defined in many blocks of unicode characters. http://www.unicode.org/faq/char_combmark.html How do I determine that a code point defines a combining character? Is there a list of such code-points? Cheers, Sam From mrc at CAC.Washington.EDU Mon Sep 11 09:46:38 2006 From: mrc at CAC.Washington.EDU (Mark Crispin) Date: Mon Sep 11 09:46:44 2006 Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <20060911163847.GA443@ensemble.local> References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> <200609021229.26322.lists@block-online.eu> <20060911163847.GA443@ensemble.local> Message-ID: On Mon, 11 Sep 2006, Sam Roberts wrote: > Quoting lists@block-online.eu, on Sat, Sep 02, 2006 at 12:29:25PM +0200: >> Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin: >>> Therefore, a better wording is: >>> ---------------------------------------------------------------------- >>> Folded lines MUST be well-formed according to the character set specified >>> for the iCalendar object. Folding MUST NOT occur between octets that >>> define a single codepoint in a character set that uses multiple octets to >>> define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian >>> character sets). [Furthermore, folding MUST NOT occur prior to a >>> codepoints that defines a combining character.] This may require >>> folding a line at less than the recommended 75 octet limit. >>> ---------------------------------------------------------------------- > Is the "[Furthermore,...combining character.]" text supposed to be part > of the the wording? This is a matter under discussion. The text is in a [] pair since its inclusion depends upon the decision of the WG. > It appears that there are combining characters defined in many blocks of > unicode characters. > http://www.unicode.org/faq/char_combmark.html > How do I determine that a code point defines a combining character? Is > there a list of such code-points? You don't determine combining character by codepoint value. You determine it by the codepoint's Canonical Combining Class value, as defined in the UnicodeData.txt file. Characters with a Canonical Combining Class value of 0 are not combining characters. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From sroberts at uniserve.com Mon Sep 11 12:20:07 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Mon Sep 11 12:20:13 2006 Subject: [Ietf-calsify] Re: [Issue 1] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> <200609021229.26322.lists@block-online.eu> <20060911163847.GA443@ensemble.local> Message-ID: <20060911192007.GA18081@pebble> On Mon, Sep 11, 2006 at 09:46:38AM -0700, Mark Crispin wrote: > On Mon, 11 Sep 2006, Sam Roberts wrote: > >Quoting lists@block-online.eu, on Sat, Sep 02, 2006 at 12:29:25PM +0200: > >>Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin: > >>>Therefore, a better wording is: > >>>---------------------------------------------------------------------- > >>>Folded lines MUST be well-formed according to the character set specified > >>>for the iCalendar object. Folding MUST NOT occur between octets that > >>>define a single codepoint in a character set that uses multiple octets to > >>>define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian > >>>character sets). [Furthermore, folding MUST NOT occur prior to a > >>>codepoints that defines a combining character.] This may require > >>>folding a line at less than the recommended 75 octet limit. > >>>---------------------------------------------------------------------- > >Is the "[Furthermore,...combining character.]" text supposed to be part > >of the the wording? > > This is a matter under discussion. The text is in a [] pair since its > inclusion depends upon the decision of the WG. Ok. > >It appears that there are combining characters defined in many blocks of > >unicode characters. > > http://www.unicode.org/faq/char_combmark.html > >How do I determine that a code point defines a combining character? Is > >there a list of such code-points? > > You don't determine combining character by codepoint value. You determine > it by the codepoint's Canonical Combining Class value, as defined in the > UnicodeData.txt file. Characters with a Canonical Combining Class value > of 0 are not combining characters. Thanks. An application would probably not include the 1038607 byte UnicodeData.txt file [1], it could just have knowledge of the current (418, by my count) combining characters. Would that application then become non-conformant with the MUST NOT under discussion when a new combining character is added to Unicode and the application isn't updated? Or would we pin iCalendar to a particular Unicode version? (or whatever they call the currently defined codepoints and combining classes, if they don't call it a "unicode version") I think its worth clarifying why folding in the middle of multi-byte sequences for either a "character" or a "grapheme" may not be desireable. As I understand it, one reason that has been mentioned is if the data is folded it can no longer be called valid "utf-8" (for example). This doesn't matter to an iCalendar application which will unfold before processing, but would matter to, for example, a mail application which didn't know how to process the calendar, and was trying to display it to the user as plain text. I think the bigger issue is that in order to unfold, you need to find the line endings. The line endings themselves are encoded as a "character", possibly multi-byte (in UTF-16, for example). So, a certain amount of well-formedness is necessary in order to unfold a calendar. If a long line in UCS-16 was broken in the middle of a UTF-16 codepoint, and a LINE-FEED, SPACE was added in UTF-16, it would probably be difficult or impossible to parse. The necessity of being well-formed enough to unfold the data doesn't seem to mean that we need to forbid folding between combining characters... or does it? Would a sequence of CAPITAL-A, LINE-FEED, SPACE, COMBINING TILDE, ... make the SPACE appear to be a "space with a tilde over it" (!) with some programming languages, thus making it not possible to find the LINE-FEED, SPACE sequence which needs to be removed during unfolding? In the languages I work in, finding "codepoints" is no trouble, and wrapping between codepoints that are part of combining sequences is no trouble, and the wrapped calendar might have a few "odd" looking bits when sequences like my example above are viewed in a unicode supporting terminal (see attached), but thats not a problem for unfolding. Are there iCalendar implementations out there (real or suspected) that will fail to interoperate when lines are wrapped between combining codepoints? If the goal here is to tighten up the spec to improve interop, and its not an interop issue, I'd say document that: - line wrapping SHOULD (MUST?) occur before XX bytes, - wrapping MUST NOT break a codepoint (if the character set being used represents a code-point as more than one byte), and - that wrapping MAY occur between combining codepoints, and move on. Also, unless I misunderstand, pathological unicode (or maybe not pathological, just a complex musical score, they use combining characters a lot) could contain a grapheme consisting of an abitrarily long sequence of codepoints, so a MUST NOT break between combining characters rule might be mutually exclusive with a rule that lines MUST NOT be over a particular byte-length. Cheers, Sam [1] http://www.unicode.org/Public/UNIDATA/UnicodeData.txt From jwn2 at qualcomm.com Mon Sep 11 12:21:15 2006 From: jwn2 at qualcomm.com (John W Noerenberg II) Date: Mon Sep 11 12:27:46 2006 Subject: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar) In-Reply-To: <200609081225.37154.reinhold@kainhofer.com> References: <20060907233353.CDEC4142276@laweleka.osafoundation.org> <200609081225.37154.reinhold@kainhofer.com> Message-ID: At 12:25 PM +0200 9/8/06, Reinhold Kainhofer wrote: >If you now tomorrow publish that event to some other group of people or so >(i.e. send a mail with METHOD:PUBLISH), the calendar that you send out will >have the above CREATED and DATE-MODIFIED (provided that you didn't modify it >meanwhile in the calendar store), but as that particular invitation will be >created tomorrow, it will have >DTSTAMP:20060910... > >So, these three settings are in deed different. The CREATED will never change >once the event is by the organizer, the DATE-MODIFIED is only changed when >you modify the event, and the DTSTAMP is the time when you create that >particular invitation or export from the calendar server. I'll grant it's possible for DTSTAMP and CREATED to differ. I've just never seen it. :-) The essential question I'm asking, are both attributes necessary? I can see an argument for DTSTAMP (despite the way I began this thread), as it's useful for determining the order in which changes to an event should be applied. However, no other attribute depends on CREATED. In the interest of simplifying the protocol, 4.8.7.1 should be eliminated (and references to it, of course). However I'd be happy if the text in 4.8.7.1 where changed from: Conformance: The property can be specified once in "VEVENT", "VTODO" or "VJOURNAL" calendar components. to Conformance: The property MAY be specified once in "VEVENT", "VTODO" or "VJOURNAL" calendar components. Absence of this parameter MUST NOT cause a CUA or CS (Calendar Service) to reject the calendar component specification. That would make it clear the parameter is optional. -- john noerenberg ---------------------------------------------------------------------- It is treason to sacrifice love of truth, intellectual honesty, loyalty to the laws and methods of the mind, to any other interests, including those of one's country. -- Herman Hesse, The Glass Bead Game, 1943 ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060911/34282fbc/attachment.htm From sroberts at uniserve.com Mon Sep 11 13:04:39 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Mon Sep 11 13:04:42 2006 Subject: [Ietf-calsify] Re: [Issue 1] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <20060911192007.GA18081@pebble> References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> <200609021229.26322.lists@block-online.eu> <20060911163847.GA443@ensemble.local> <20060911192007.GA18081@pebble> Message-ID: <20060911200439.GE26643@pebble> On Mon, Sep 11, 2006 at 12:20:07PM -0700, Sam Roberts wrote: > characters... or does it? Would a sequence of > > CAPITAL-A, LINE-FEED, SPACE, COMBINING TILDE, ... Oops, attached utf-8, but don't know if attachments make it through to the list. % xxd __.out 0000000: 410a 20cc 802e 2e2e 0a A. ...... xxd -r will get it back. -------------- next part -------------- A ?... From lists at block-online.eu Mon Sep 11 17:15:59 2006 From: lists at block-online.eu (Oliver Block) Date: Mon Sep 11 17:16:40 2006 Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: References: <200608151454.51877.lists@block-online.eu> <20060911163847.GA443@ensemble.local> Message-ID: <200609120215.59926.lists@block-online.eu> Am Montag, 11. September 2006 18:46 schrieb Mark Crispin: > This is a matter under discussion. > The text is in a [] pair since its > inclusion depends upon the decision of the WG. I would forget that. You can convert from charsets (e.g. ISO-8859) to UTF-8 with acceptable effort. But adding the part in [] would multiply the effort. iCalendar requires valid UTF-8 and with the two texts that were proposed, it makes that clear enough. I would even prefer Bernards Version with 'charset' instead of 'character set' because it leaves some terms out, which make it better readable in my view. Marks Version is ahead of the times:) so it should be kept for the next iCal-WG. Or in other words: If you want to introduce new terms to this RFC, you should do with more than five sentences. That's what I think. Best Regards, Oliver -- Leben ist mehr ... http://www.nak-nrw.de/p_6_4.html From MRC at CAC.Washington.EDU Mon Sep 11 17:21:06 2006 From: MRC at CAC.Washington.EDU (Mark Crispin) Date: Mon Sep 11 17:19:08 2006 Subject: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <200609120215.59926.lists@block-online.eu> References: <200608151454.51877.lists@block-online.eu> <20060911163847.GA443@ensemble.local> <200609120215.59926.lists@block-online.eu> Message-ID: On Tue, 12 Sep 2006, Oliver Block wrote: > Am Montag, 11. September 2006 18:46 schrieb Mark Crispin: >> This is a matter under discussion. >> The text is in a [] pair since its >> inclusion depends upon the decision of the WG. > I would forget that. You can convert from charsets (e.g. ISO-8859) to UTF-8 > with acceptable effort. But adding the part in [] would multiply the effort. Huh? Any conversion from ISO 8859 to UTF-8 would not have any combining characters, since all ISO 8859 characters have precomposed equivalents in UTF-8. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From aki.niemi at nokia.com Tue Sep 12 03:54:12 2006 From: aki.niemi at nokia.com (Aki Niemi) Date: Tue Sep 12 03:54:23 2006 Subject: Proposal to close issue #2 (was: Re: [Ietf-calsify] rfc 2445 - typo correction(s)) In-Reply-To: <44F47A11.1010302@oracle.com> References: <447612E1.1070504@softdesign.net.nz> <44F47A11.1010302@oracle.com> Message-ID: <1158058453.26676.10.camel@macbuster.research.nokia.com> I believe we can close this issue (#2 in the tracker). Cheers, Aki ti, 2006-08-29 kello 13:32 -0400, ext Bernard Desruisseaux kirjoitti: > +1 > > Andrew N Dowden wrote: > > 4.8.6.3 Trigger > > > > If the trigger is set relative to START, then the "DTSTART" property > > MUST be present in the associated "VEVENT" or "VTODO" calendar > > component. If an alarm is specified for an event with the trigger set > > relative to the END, then the "DTEND" property or the "DSTART" and > > "DURATION' properties MUST be present in the associated "VEVENT" > > calendar component. If the alarm is specified for a to-do with a > > trigger set relative to the END, then either the "DUE" property or > > the "DSTART" and "DURATION' properties MUST be present in the > > associated "VTODO" calendar component. > > > > CORRECTION: replace DSTART with DTSTART (lines 4 & 8) > > > > PS. have enjoyed recent discussions, more (contentious) comments / > > suggestions to follow .. > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From aki.niemi at nokia.com Tue Sep 12 07:46:50 2006 From: aki.niemi at nokia.com (Aki Niemi) Date: Tue Sep 12 07:47:00 2006 Subject: Proposal for closing issue #4 (was: Re: [Ietf-calsify] RFC2445 Correction in rrule examples) In-Reply-To: <20060530044633.GA790@ensemble.local> References: <200605291418.44271.lists@block-online.eu> <20060530044633.GA790@ensemble.local> Message-ID: <1158072410.26676.42.camel@macbuster.research.nokia.com> ma, 2006-05-29 kello 21:46 -0700, ext Sam Roberts kirjoitti: > I found this in my notes: > > Everyday in January, for 3 years: > > DTSTART;TZID=US-Eastern:19980101T090000 > RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; > BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA > or > RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 > > ==> (1998 9:00 AM EDT)January 1-31 > (1999 9:00 AM EDT)January 1-31 > (2000 9:00 AM EDT)January 1-31 > > !! (2000 9:00 AM EDT)January 31 is AFTER the until day (2000 9:00 am UTC) January 31 BTW, isn't EDT only supposed to be used during summer? AFAICS, this example needs to be changed so that either the DTSTART or the UNTIL needs to be adjusted, or the DTSTART be represented in UTC as well. Let me take a stab at this: DTSTART;TZID=US-Eastern:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 ==> (1998 9:00 AM EST)January 1-31 (1999 9:00 AM EST)January 1-31 (2000 9:00 AM EST)January 1-31 With this, I'd like to propose closing this issue (#4 in the tracker). Comments? Cheers, Aki -- Aki Niemi Nokia Research Center From mvl at exedo.nl Wed Sep 13 13:57:16 2006 From: mvl at exedo.nl (Michiel van Leeuwen) Date: Wed Sep 13 13:58:02 2006 Subject: [Ietf-calsify] Re: Propose to close issues 37, 38, 39 In-Reply-To: <450141D2.9040601@cisco.com> References: <450141D2.9040601@cisco.com> Message-ID: Eliot Lear wrote: > 4.6.1 Event Component: eventprop > > > > eventprop = *( > > > > ; the following are both REQUIRED, > > ; but MUST NOT occur more than once > > > > dtstamp / dtstart / uid / The text speaks of 'both', while there are three items. Shouldn't that be 'all three' then? Michiel From sandy at WEIJax.com Wed Sep 13 14:10:25 2006 From: sandy at WEIJax.com (Sandy Wills) Date: Wed Sep 13 14:10:37 2006 Subject: [Ietf-calsify] Re: Propose to close issues 37, 38, 39 In-Reply-To: References: <450141D2.9040601@cisco.com> Message-ID: <450873C1.1080105@WEIJax.com> Michiel van Leeuwen wrote: > Eliot Lear wrote: > >> 4.6.1 Event Component: eventprop >> >> >> > eventprop = *( >> > >> > ; the following are both REQUIRED, >> > ; but MUST NOT occur more than once >> > >> > dtstamp / dtstart / uid / > > > The text speaks of 'both', while there are three items. Shouldn't that > be 'all three' then? The "both" refers to having two requirements, not to how many items are on the list. The following list (no matter how long) has both of these requirements: A) all items in the list are REQUIRED, and B) each item MUST NOT occur more than once. List items: dtstamp, dtstart, uid -- Unable to locate coffee. Operator halted. From sroberts at uniserve.com Wed Sep 13 16:38:18 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Wed Sep 13 16:38:25 2006 Subject: [Ietf-calsify] Re: Propose to close issues 37, 38, 39 In-Reply-To: <450873C1.1080105@WEIJax.com> References: <450141D2.9040601@cisco.com> <450873C1.1080105@WEIJax.com> Message-ID: <20060913233817.GA4535@pebble> On Wed, Sep 13, 2006 at 05:10:25PM -0400, Sandy Wills wrote: > >> 4.6.1 Event Component: eventprop > >> > >> > eventprop = *( > >> > > >> > ; the following are both REQUIRED, > >> > ; but MUST NOT occur more than once > >> > > >> > dtstamp / dtstart / uid / > The "both" refers to having two requirements, not to how many items are > on the list. I thought the phrasing was a bit confusing, too. It might even be ungrammatical, usually people say "both this AND that". Anyhow, the "both" and the "but" are unncessary, may I suggest: "the following are REQUIRED and MUST NOT occur more than once" This kind of text show up a lot, isn't it the same wording everywhere? Cheers, Sam From lear at cisco.com Wed Sep 13 22:48:28 2006 From: lear at cisco.com (Eliot Lear) Date: Wed Sep 13 22:48:34 2006 Subject: [Ietf-calsify] Re: Propose to close issues 37, 38, 39 In-Reply-To: References: <450141D2.9040601@cisco.com> Message-ID: <4508ED2C.1000201@cisco.com> Michiel van Leeuwen wrote: > Eliot Lear wrote: >> 4.6.1 Event Component: eventprop >> >> >> > eventprop = *( >> > >> > ; the following are both REQUIRED, >> > ; but MUST NOT occur more than once >> > >> > dtstamp / dtstart / uid / > > The text speaks of 'both', while there are three items. Shouldn't that > be 'all three' then? > > Michiel Yes, this seems to be more appropriate. Eliot From cyrus at daboo.name Thu Sep 14 11:08:27 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Sep 14 11:08:44 2006 Subject: [Ietf-calsify] Overlapping reschedule Message-ID: Hi folks, Lets assume an organizer has booked an event with one or more attendees for 12:00 pm to 1:00 pm. The organizer then wants to reschedule that to 12:30 pm to 1:30 pm. If the organizer does an iTIP VFREEBUSY REQUEST for the new time range the attendees will show up as busy for the first half hour because of the existing booked event. There are several solutions to this: 1) The organizer needs to 'subtract' the original event's time from any busy time it gets back from the iTIP request (i.e. effectively overriding when the attendees report as being busy). This seems reasonable if the attendee had previous accepted the meeting (and had not deliberately double-booked), but if they had not accepted it may be wrong to do. This method would work for recurring events. 2) The organizer only issues the free-busy request for the second half hour period of the new meeting. Well that would work in this case, but if the new meeting had been 11 am - 2 pm (i.e. new time required both before and after the original) then two requests would have to be done. Plus it gets worse for recurring events. The same issue with accepted attendees would apply. 3) Extend iTIP to allow the organizer to specify a list of UIDs of events that should be excluded from any busy time results returned in the reply. The organizer could then supply the original event UID and the attendees' clients would exclude that from busy. This would work for any attendee state and recurring meetings (though we would probably have to send UID + list of Recurrence-IDs to handle reschedule of exceptions). However it is an extension to iTIP. 4) Organizer first cancels the original meeting and then does free busy lookup. This is not good as the cancel operation may require the attendees' manual intervention to accept, whereas the free-busy lookup may complete faster (c.f. CalDAV where free busy iTIP operations execute immediately, whereas others require explicit acceptance from the attendee). Any thoughts on this? -- Cyrus Daboo From mark.paterson at oracle.com Fri Sep 15 06:25:48 2006 From: mark.paterson at oracle.com (Mark Paterson) Date: Fri Sep 15 06:27:59 2006 Subject: [Ietf-calsify] Overlapping reschedule In-Reply-To: References: Message-ID: <450AA9DC.2070604@oracle.com> 3) certainly seems like an interesting possibility. Cyrus Daboo wrote: > Hi folks, > Lets assume an organizer has booked an event with one or more > attendees for 12:00 pm to 1:00 pm. The organizer then wants to > reschedule that to 12:30 pm to 1:30 pm. If the organizer does an iTIP > VFREEBUSY REQUEST for the new time range the attendees will show up as > busy for the first half hour because of the existing booked event. > There are several solutions to this: > > 1) The organizer needs to 'subtract' the original event's time from > any busy time it gets back from the iTIP request (i.e. effectively > overriding when the attendees report as being busy). This seems > reasonable if the attendee had previous accepted the meeting (and had > not deliberately double-booked), but if they had not accepted it may > be wrong to do. This method would work for recurring events. > > 2) The organizer only issues the free-busy request for the second half > hour period of the new meeting. Well that would work in this case, but > if the new meeting had been 11 am - 2 pm (i.e. new time required both > before and after the original) then two requests would have to be > done. Plus it gets worse for recurring events. The same issue with > accepted attendees would apply. > > 3) Extend iTIP to allow the organizer to specify a list of UIDs of > events that should be excluded from any busy time results returned in > the reply. The organizer could then supply the original event UID and > the attendees' clients would exclude that from busy. This would work > for any attendee state and recurring meetings (though we would > probably have to send UID + list of Recurrence-IDs to handle > reschedule of exceptions). However it is an extension to iTIP. > > 4) Organizer first cancels the original meeting and then does free > busy lookup. This is not good as the cancel operation may require the > attendees' manual intervention to accept, whereas the free-busy lookup > may complete faster (c.f. CalDAV where free busy iTIP operations > execute immediately, whereas others require explicit acceptance from > the attendee). > > Any thoughts on this? > -- MARK PATERSON Product Manager, OCS Mobility Oracle Corporation - Server Technologies Phone: 514.905.8649 Mobile: 514.862.8505 mailto: mark.paterson@oracle.com http: www.oracle.com From cyrus at daboo.name Fri Sep 15 06:36:28 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Fri Sep 15 06:36:46 2006 Subject: [Ietf-calsify] Overlapping reschedule In-Reply-To: <450AA9DC.2070604@oracle.com> References: <450AA9DC.2070604@oracle.com> Message-ID: <63A6E991CC80D6C8DD995872@Cyrus-Daboo-G5.local> Hi Mark, --On September 15, 2006 9:25:48 AM -0400 Mark Paterson wrote: > 3) certainly seems like an interesting possibility. >> >> 3) Extend iTIP to allow the organizer to specify a list of UIDs of >> events that should be excluded from any busy time results returned in >> the reply. The organizer could then supply the original event UID and >> the attendees' clients would exclude that from busy. This would work >> for any attendee state and recurring meetings (though we would >> probably have to send UID + list of Recurrence-IDs to handle >> reschedule of exceptions). However it is an extension to iTIP. Having thought about this some more I realize that there is a security concern with this. At the very least the 'ignored UIDs' list must refer to components whose ORGANIZER property is the same as the ORGANIZER in the free-busy request. So the entity doing the free-busy lookup MUST check the ORGANIZER properties before ignoring an event. -- Cyrus Daboo From simon.pilette at oracle.com Fri Sep 15 11:23:14 2006 From: simon.pilette at oracle.com (Simon Pilette) Date: Fri Sep 15 11:26:18 2006 Subject: [Ietf-calsify] Section 4.6.4 Free/Busy Component, bad example Message-ID: <450AEF92.90204@oracle.com> In section 4.6.4 Free/Busy Component of RFC 2445, there is an example that makes use of the VALUE parameter on the FREEBUSY property: > FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, > 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M According to the ABNF specified in section 4.8.2.6 Free/Busy Time, the FREEBUSY property does not allow the VALUE parameter. The example should be fixed. Simon Pilette From lear at cisco.com Tue Sep 19 02:22:30 2006 From: lear at cisco.com (Eliot Lear) Date: Tue Sep 19 02:22:39 2006 Subject: [Ietf-calsify] Issue 1: new proposed text Message-ID: <450FB6D6.6000601@cisco.com> Having tried to understand the value of any change to the text, I have the following observations: * The concern is only for those who are attempting to read the calendar information in a text based mailer, and impacts approximately one glyph. This is a very limited constituency and of very limited impact. * The text ALREADY says that folding occur between any two characters. That means you should continue to emit legal UTF-8 if you are emitting UTF-8 at all. * However, my own (admittedly braindamaged) code implements folding at a very low level, as folding is one of the last operations to take place. * I suspect I'm not the only one who has written such brain damaged code. * After *unfolding* any potential damage should be undone. * The amount of code required to fold or unfold text is pretty darn minimal. * Much of it is already written. Hence, relaxing of folding is perhaps not advisable. I have two recommendations for textual changes to RFC 2445: 1. Delete the second sentence in the 2nd paragraph after the example in 4.1 as redundant (it says the exact same thing in the first paragraph); 2. Add a sentence as follows: "It is possible for very simple implementations to have improperly folded lines in the middle of UTF-8 characters. In such cases, implementations SHOULD unfold lines in such a way to properly restore the character. Eliot From bernard.desruisseaux at oracle.com Tue Sep 19 06:00:06 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue Sep 19 06:00:53 2006 Subject: [Ietf-calsify] Section 4.8.5.4 Recurrence Rule: Allowed value type of DTSTART and DTEND Message-ID: <450FE9D6.90505@oracle.com> Section 4.3.5 Date-Time of RFC 2445 defines 3 forms for DATE-TIME values, that is: FORM #1: DATE WITH LOCAL TIME FORM #2: DATE WITH UTC TIME FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE In section 4.8.5.4 Recurrence Rule of RFC 2445 it says: > The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION" > property pair, specified within the iCalendar object defines the > first instance of the recurrence. When used with a recurrence rule, > the "DTSTART" and "DTEND" properties MUST be specified in local time > and the appropriate set of "VTIMEZONE" calendar components MUST be > included. For detail on the usage of the "VTIMEZONE" calendar > component, see the "VTIMEZONE" calendar component definition. My understanding is: - The DTSTART property in a STANDARD or DAYLIGHT sub-component of a VTIMEZONE component MUST be of FORM #1 (DATE WITH LOCAL TIME) [See section 4.6.5 Time Zone Component]; - The DTSTART property in a VEVENT, VTODO or VJOURNAL component MUST be either a DATE value or a DATE-TIME value of FORM #1 (DATE WITH LOCAL TIME) or FORM #3 (DATE WITH LOCAL TIME AND TIME ZONE REFERENCE). As such, the text should be clarified to specify that DTSTART and DTEND MUST be specified as a DATE or as a DATE-TIME of FORM #1 (DATE WITH LOCAL TIME) or FORM #3 (DATE WITH LOCAL TIME AND TIME ZONE REFERENCE). All that being said, I would like to point out that in section 4.4.2 Modify A Recurring Instance of RFC 2446 (iTIP) there is an example of a DTSTART value specified in FORM #2 (DATE WITH UTC TIME) used with a recurrence rule. My understanding is that this is not valid. Cheers, Bernard From bernard.desruisseaux at oracle.com Tue Sep 19 07:31:22 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue Sep 19 07:32:38 2006 Subject: [Ietf-calsify] Section 4.6.6 Alarm Component: Restriction over the value of the ACTION property Message-ID: <450FFF3A.2040408@oracle.com> According to section 4.8.6.1 Action of RFC 2445, the ACTION property can take the following values: > actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" > / iana-token / x-name On the other hand, section 4.6.6 Alarm Component restricts the values that the ACTION property can take when used in a VALARM component to the following: AUDIO, DISPLAY, EMAIL, and PROCEDURE. Check the last sentence of the following paragraph: > The "ACTION" property is used within the "VALARM" calendar component > to specify the type of action invoked when the alarm is triggered. > The "VALARM" properties provide enough information for a specific > action to be invoked. It is typically the responsibility of a > "Calendar User Agent" (CUA) to deliver the alarm in the specified > fashion. An "ACTION" property value of AUDIO specifies an alarm that > causes a sound to be played to alert the user; DISPLAY specifies an > alarm that causes a text message to be displayed to the user; EMAIL > specifies an alarm that causes an electronic email message to be > delivered to one or more email addresses; and PROCEDURE specifies an > alarm that causes a procedure to be executed. The "ACTION" property > MUST specify one and only one of these values. In my opinion, one should be allowed to specify an ACTION property with a "iana-token" or "x-name" value in a VALARM component. A vendor might want to use "x-name" values (or register iana-token) for alarms that should be delivered by SMS, XMPP, Fax, Voice, etc. Cheers, Bernard From bernard.desruisseaux at oracle.com Tue Sep 19 08:21:25 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue Sep 19 08:23:35 2006 Subject: [Ietf-calsify] Section 4.8.8.1 Non-standard Properties: Parameters allowed on x-prop Message-ID: <45100AF5.9060808@oracle.com> In section 4.8.8.1 Non-standard Properties of RFC 2445 it says: > The data type for this property > is TEXT. Optionally, the data type can be any of the other valid data > types. > > Format Definition: The property is defined by the following notation: > > x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF > ; Lines longer than 75 octets should be folded In my opinion x-prop should allow any parameter defined by iCalendar as well as any iana-param. There is no reason to invent an xparam if there already exists a parameter that can be used. While "the data type [of an x-prop] can be any of the other valid data type", one would currently not be allowed to specify the VALUE parameter to specify the value type of the property. Here's an example, found on the web, that I believe should be valid: X-WD-NEXT-ALARM;VALUE=DATE-TIME:20040927T153000 [ Actually, this example would still be invalid since WinDate didn't use a "vendor identification" of at least 3 characters. See the vendorid rule in section 4.1 Content Lines. ] Cheers, Bernard From bernard.desruisseaux at oracle.com Tue Sep 19 08:31:36 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue Sep 19 08:33:50 2006 Subject: [Ietf-calsify] Should all iCalendar tokens be considered as iana-token? Message-ID: <45100D58.20802@oracle.com> Should the tokens defined in the iCalendar specification be considered as iana-token? If yes, that would imply that VALARM components can be specified within VCALENDAR objects given that VCALENDAR objects can specify iana-comp. One could argue that as long as the VALARM component defines a TRIGGER with an absolute date/time value there is no issue, but is that something we want to allow? Cheers, Bernard From bernard.desruisseaux at oracle.com Tue Sep 19 08:47:52 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue Sep 19 08:50:10 2006 Subject: [Ietf-calsify] Sections 4.2.6, 4.8.4.1, 4.8.4.2, and 4.8.4.3: Bad LDAP URL in examples Message-ID: <45101128.5030203@oracle.com> The LDAP URLs specified in the examples of section 4.2.6, 4.8.4.1, 4.8.4.2, and 4.8.4.3 are all broken. They are missing a '?' character and they partially escape the '=' character in quoted-printable... For instance, the LDAP URL in section 4.2.6 should be change from: ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS?? (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com to: ORGANIZER;DIR="ldap://host.com:6666/o=ABC%20Industries,c=US??? (cn=Jim%20Dolittle)":MAILTO:jimdo@host1.com Cheers, Bernard From bernard.desruisseaux at oracle.com Tue Sep 19 09:24:25 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue Sep 19 09:25:08 2006 Subject: [Ietf-calsify] Should all iCalendar tokens be considered as iana-token? In-Reply-To: <45100D58.20802@oracle.com> References: <45100D58.20802@oracle.com> Message-ID: <451019B9.9040506@oracle.com> Actually, section 4.6.6 Alarm Component explicitly states: > The "VALARM" calendar component MUST only appear within either a > "VEVENT" or "VTODO" calendar component. Sorry! Cheers, Bernard Bernard Desruisseaux wrote: > Should the tokens defined in the iCalendar specification be > considered as iana-token? > > If yes, that would imply that VALARM components can be specified > within VCALENDAR objects given that VCALENDAR objects can specify > iana-comp. > > One could argue that as long as the VALARM component defines a > TRIGGER with an absolute date/time value there is no issue, but > is that something we want to allow? > > Cheers, > Bernard > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From lists at block-online.eu Wed Sep 20 08:22:31 2006 From: lists at block-online.eu (Oliver Block) Date: Wed Sep 20 08:23:12 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <450FB6D6.6000601@cisco.com> References: <450FB6D6.6000601@cisco.com> Message-ID: <200609201722.31921.lists@block-online.eu> Am Dienstag, 19. September 2006 11:22 schrieb Eliot Lear: > > * The concern is only for those who are attempting to read the > calendar information in a text based mailer, Actually it is for everybody who wants to produce well-formed UTF-8. > Hence, relaxing of folding is perhaps not advisable. > 2. Add a sentence as follows: "It is possible for very simple > implementations to have improperly folded lines in the middle of > UTF-8 characters. In such cases, implementations SHOULD unfold > lines in such a way to properly restore the character. Would you want to add this to the old text or to one of the new proposals? Best Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html From lear at cisco.com Wed Sep 20 08:30:13 2006 From: lear at cisco.com (Eliot Lear) Date: Wed Sep 20 08:30:22 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <200609201722.31921.lists@block-online.eu> References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> Message-ID: <45115E85.4010300@cisco.com> Again, chair hat off. Oliver Block wrote: > Am Dienstag, 19. September 2006 11:22 schrieb Eliot Lear: > >> >> > > >> * The concern is only for those who are attempting to read the >> calendar information in a text based mailer, >> > > Actually it is for everybody who wants to produce well-formed UTF-8. > But nobody will care unless they're looking at the raw message. Yes, it's malformed, but then it's not really meant to be represented. What really should be happening is that implementations should use MIME multipart/alternative and not put a text/calendar message in front of a user. > >> Hence, relaxing of folding is perhaps not advisable. >> > > >> 2. Add a sentence as follows: "It is possible for very simple >> implementations to have improperly folded lines in the middle of >> UTF-8 characters. In such cases, implementations SHOULD unfold >> lines in such a way to properly restore the character. >> > > Would you want to add this to the old text or to one of the new proposals? > Old text. Ok, WG chair hat on: Don't forget that if you have an alternative please present it. If I missed it I apologize in advance. Eliot From reinhold at kainhofer.com Wed Sep 20 08:48:24 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Wed Sep 20 08:48:57 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <45115E85.4010300@cisco.com> References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> Message-ID: <200609201748.43856.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 20. September 2006 17:30 schrieb Eliot Lear: > > ? > > > >> ? ? * The concern is only for those who are attempting to read the > >> ? ? ? calendar information in a text based mailer, > >> ? ? > > > > Actually it is for everybody who wants to produce well-formed UTF-8. > > ? > > But nobody will care unless they're looking at the raw message. ?Yes, > it's malformed, but then it's not really meant to be represented. ?What > really should be happening is that implementations should use MIME > multipart/alternative and not put a text/calendar message in front of a > user. Actually, who knows what mail processors (e.g. recoding done by several mail servers!) will do if they encounter broken UTF-8 bytes, because line folding happened in between the bytes of a multi-byte character? If they try to "fix" the UTF-8, they actually mess up the calendar attachment. Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: 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.5 (GNU/Linux) iD8DBQFFEWLbTqjEwhXvPN0RAlEiAJ0drHF3kkbSyW3oLvCqxrvzP9Zb5ACgzDFH 2ZW8tNG8RPrWR3ZkK76WqZM= =dNhh -----END PGP SIGNATURE----- From mrc at CAC.Washington.EDU Wed Sep 20 08:49:33 2006 From: mrc at CAC.Washington.EDU (Mark Crispin) Date: Wed Sep 20 08:49:39 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <45115E85.4010300@cisco.com> References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> Message-ID: On Wed, 20 Sep 2006, Eliot Lear wrote: >> Actually it is for everybody who wants to produce well-formed UTF-8. > But nobody will care unless they're looking at the raw message. Yes, > it's malformed, but then it's not really meant to be represented. What > really should be happening is that implementations should use MIME > multipart/alternative and not put a text/calendar message in front of a > user. I support Eliot's position. My position can best be summarized as being "do it right or don't do it at all." That is, we should choose between either "only fold at a point that represents a complete glyph" or "it doesn't matter where folding takes place, since the text will always be unfolded prior to processing." It is pointless to talk about "well-formed UTF-8" and say that is "good enough." Yes, you can break a UTF-8 string such that the two substrings are both independently interpretable by a UTF-8 decoder. The problem is that if the break is before a combining character codepoint, the string after the break is NOT a valid UTF-8 string since it begins with a combining character. Put another way, it's valid UTF-8 encoding of an invalid string. I believe that a half-solution is the worst possible choice, since it creates the illusion of viability for a primitive tool that uses the raw message without doing proper folding. If we punt, and say that folding can occur anywhere, then primitive tools are broken; they will attempt to deal with dangling UTF-8 strings which end in the middle of a codepoint sequence, and with strings that start in the middle of a codepoint sequence. If we go all the way, and say that folding can only occur at a glyph point, then primitive tools will be fine. That is a lot of work to undertake just to make it easier for some lazy programmer to foist a primitive tool as being acceptable. In my opinion, we should choose between supporting primitive tools, or declaring primitive tools to be totally broken. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From cyrus at daboo.name Wed Sep 20 08:49:36 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed Sep 20 08:50:01 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <45115E85.4010300@cisco.com> References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> Message-ID: Hi Eliot, --On September 20, 2006 5:30:13 PM +0200 Eliot Lear wrote: >> Actually it is for everybody who wants to produce well-formed UTF-8. >> > > But nobody will care unless they're looking at the raw message. Yes, > it's malformed, but then it's not really meant to be represented. What > really should be happening is that implementations should use MIME > multipart/alternative and not put a text/calendar message in front of a > user. The issue is that it is not out of the realm of possibility that a spam filter or some other 'integrity' checker in email will reject an iMIP message because it contains invalid utf-8 (utf-8 multi-octet sequence broken across two lines). Another example might be reading the utf-8 byte stream into a unicode string object BEFORE doing the iCal processing on the unicode string data - that will likely fail if there is invalid utf-8. That's been my primary concern rather than whether it will be viewable in a text editor. -- Cyrus Daboo From lear at cisco.com Wed Sep 20 08:57:39 2006 From: lear at cisco.com (Eliot Lear) Date: Wed Sep 20 08:58:08 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> Message-ID: <451164F3.7000407@cisco.com> Hi Cyrus, > The issue is that it is not out of the realm of possibility that a > spam filter or some other 'integrity' checker in email will reject an > iMIP message because it contains invalid utf-8 (utf-8 multi-octet > sequence broken across two lines). Another example might be reading > the utf-8 byte stream into a unicode string object BEFORE doing the > iCal processing on the unicode string data - that will likely fail if > there is invalid utf-8. That's been my primary concern rather than > whether it will be viewable in a text editor. Sorry- to be clear RFC 2445 already requires that you not split lines in the middle of characters. This implies valid UTF-8 when used, IMHO. Eliot From McQuilWP at pobox.com Wed Sep 20 09:14:12 2006 From: McQuilWP at pobox.com (Bill McQuillan) Date: Wed Sep 20 09:14:24 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> Message-ID: <1903786649.20060920091412@pobox.com> On Wed, 2006-09-20, Cyrus Daboo wrote: > --On September 20, 2006 5:30:13 PM +0200 Eliot Lear wrote: >>> Actually it is for everybody who wants to produce well-formed UTF-8. >>> >> >> But nobody will care unless they're looking at the raw message. Yes, >> it's malformed, but then it's not really meant to be represented. What >> really should be happening is that implementations should use MIME >> multipart/alternative and not put a text/calendar message in front of a >> user. > The issue is that it is not out of the realm of possibility that a spam > filter or some other 'integrity' checker in email will reject an iMIP > message because it contains invalid utf-8 (utf-8 multi-octet sequence > broken across two lines). Another example might be reading the utf-8 byte > stream into a unicode string object BEFORE doing the iCal processing on the > unicode string data - that will likely fail if there is invalid utf-8. > That's been my primary concern rather than whether it will be viewable in a > text editor. A further issue is that the definition of "folding" in RFC 2822 explicitly states (sect.2.2.3) that the unfolded text includes the SP following the CRLF. Thus, a UTF-8 sequence of any sort would be interrupted by a SP character unless an idiosyncratic unfolding operation is employed. -- Bill McQuillan From McQuilWP at pobox.com Wed Sep 20 09:57:20 2006 From: McQuilWP at pobox.com (Bill McQuillan) Date: Wed Sep 20 09:57:26 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <1903786649.20060920091412@pobox.com> References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> <1903786649.20060920091412@pobox.com> Message-ID: <541798243.20060920095720@pobox.com> On Wed, 2006-09-20, I wrote: > A further issue is that the definition of "folding" in RFC 2822 explicitly > states (sect.2.2.3) that the unfolded text includes the SP following the > CRLF. Thus, a UTF-8 sequence of any sort would be interrupted by a SP > character unless an idiosyncratic unfolding operation is employed. Sorry, I'm afraid I had a temporary brain glitch. The folding technique is NOT modeled on RFC2822 headers and the issue of the SP does not exist. Never mind! -- Bill McQuillan From TimHare at comcast.net Wed Sep 20 20:24:14 2006 From: TimHare at comcast.net (Tim Hare) Date: Wed Sep 20 20:24:24 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <541798243.20060920095720@pobox.com> Message-ID: <20060921032421.4F51C142276@laweleka.osafoundation.org> I don't claim to be a UTF-anything expert, but the current text does require white space (SP or TAB) after the CRLF for folding. However - what do we break if we eliminate the folding altogether as in my proposed text below? Old Text: ---------------------------------------------------------------------------- 4.1 Content Lines The iCalendar object is organized into individual lines of text, called content lines. Content lines are delimited by a line break, which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII decimal 10). Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. Long content lines SHOULD be split into a multiple line representations using a line "folding" technique. That is, a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white space character (i.e., SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence of CRLF followed immediately by a single linear white space character is ignored (i.e., removed) when processing the content type. For example the line: DESCRIPTION:This is a long description that exists on a long line. Can be represented as: DESCRIPTION:This is a lo ng description that exists on a long line. The process of moving from this folded multiple line representation to its single line representation is called "unfolding". Unfolding is accomplished by removing the CRLF character and the linear white space character that immediately follows. When parsing a content line, folded lines MUST first be unfolded according to the unfolding procedure described above. When generating a content line, lines longer than 75 octets SHOULD be folded according to the folding procedure described above. The content information associated with an iCalendar object is formatted using a syntax similar to that defined by [RFC 2425]. That is, the content information consists of CRLF-separated content lines. The following notation defines the lines of content in an iCalendar object: contentline = name *(";" param ) ":" value CRLF ; This ABNF is just a general definition for an initial parsing ; of the content line into its property name, parameter list, ; and value string ; When parsing a content line, folded lines MUST first ; be unfolded according to the unfolding procedure ; described above. When generating a content line, lines ; longer than 75 octets SHOULD be folded according to ; the folding procedure described above. ---------------------------------------------------------------------------- --------------------------------- Proposed new text (feel free to make modifications as necessary for Unicode purposes) ---------------------------------------------------------------------------- --------------------------------- 4.1 Content Lines The iCalendar object is organized into individual lines of text, called content lines. Content lines are delimited by a line break, which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII decimal 10). Lines of text may be of arbitrary length. It is up to the CUA implementation to present the text to the user in a manner consistent with the current user interface in use, which may include wrapping the text within margins or other forms of presentation changes. The originator of calendar object text should not expect its display to be limited to any arbitrary length. Older implementations of [RFC 2445] may be encountered which have performed a "folding" acton on longer lines of text by inserting a CRLF sequence followed by a single linear white space character (SPACE, US-ASCII decimal 32; or HTAB US-ASCII decimal 09) at logical folding points. This is usually done in e-mail implementations to improve compatibility with some mailing programs. Implementations MAY choose to "unfold" these lines by replacing the CRLF-whitespace sequence with a single space. For example the line: DESCRIPTION:This is a lo ng description that exists on a long line. May be presented to the interface as is, or may be unfolded to read: DESCRIPTION: This is a long descripton that exists on a long line. The content information associated with an iCalendar object is formatted using a syntax similar to that defined by [RFC 2425]. That is, the content information consists of CRLF-separated content lines. The following notation defines the lines of content in an iCalendar object: contentline = name *(";" param ) ":" value CRLF ; This ABNF is just a general definition for an initial parsing ; of the content line into its property name, parameter list, ; and value string ; When parsing a content line, folded lines MAY first ; be unfolded according to the unfolding procedure ; described above. ---------------------------------------------------------------------------- --------------------------------- Since TEXT property values MUST represent intentional line breaks via "\n" or "\N" (4.3.11) anyone desiring to Format the content of a long line may include those formatting sequences. The most likely use case for folding is the DESCRIPTION: property, "\n" is completely appropriate to use there and is already seen in implementations. I also believe that most current implementations "wrap" text within some UI limit (margins, window size, etcetera) so the human factor of folding is already handled in the UI anyway. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Bill McQuillan Sent: Wednesday, September 20, 2006 12:57 PM To: Calsify List Subject: Re: [Ietf-calsify] Issue 1: new proposed text On Wed, 2006-09-20, I wrote: > A further issue is that the definition of "folding" in RFC 2822 > explicitly states (sect.2.2.3) that the unfolded text includes the SP > following the CRLF. Thus, a UTF-8 sequence of any sort would be > interrupted by a SP character unless an idiosyncratic unfolding operation is employed. Sorry, I'm afraid I had a temporary brain glitch. The folding technique is NOT modeled on RFC2822 headers and the issue of the SP does not exist. Never mind! -- Bill McQuillan _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From alexey.melnikov at isode.com Thu Sep 21 04:11:40 2006 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Sep 21 04:12:07 2006 Subject: [Ietf-calsify] Section 4.8.8.1 Non-standard Properties: Parameters allowed on x-prop In-Reply-To: <45100AF5.9060808@oracle.com> References: <45100AF5.9060808@oracle.com> Message-ID: <4512736C.1050402@isode.com> Bernard Desruisseaux wrote: > In section 4.8.8.1 Non-standard Properties of RFC 2445 it says: > > > The data type for this property > > is TEXT. Optionally, the data type can be any of the other valid data > > types. > > > > Format Definition: The property is defined by the following notation: > > > > x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF > > ; Lines longer than 75 octets should be folded > > In my opinion x-prop should allow any parameter defined by iCalendar > as well as any iana-param. There is no reason to invent an xparam > if there already exists a parameter that can be used. This make sense. > While "the data type [of an x-prop] can be any of the other valid data > type", one would currently not be allowed to specify the VALUE parameter > to specify the value type of the property. Here's an example, found on > the web, that I believe should be valid: > > X-WD-NEXT-ALARM;VALUE=DATE-TIME:20040927T153000 > > [ Actually, this example would still be invalid since WinDate didn't use > a "vendor identification" of at least 3 characters. See the vendorid > rule in section 4.1 Content Lines. ] From bernard.desruisseaux at oracle.com Thu Sep 21 11:11:49 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Sep 21 11:13:26 2006 Subject: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: <44EA6BB0.7070108@oracle.com> References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> Message-ID: <4512D5E5.6090400@oracle.com> Folks, I would like to close issue 31 with a new proposal: - UTF-8 and US-ASCII are the only character set supported by iCalendar. - The use of other character set is not forbidden. - Compliant applications are REQUIRED to accept UTF-8 and US-ASCII. - Compliant applications SHOULD generate iCalendar objects in UTF-8. Here's the proposed text changes: Section 3.2 Parameters OLD TEXT: > The "charset" parameter is defined in [RFC 2046] for other body > parts. It is used to identify the default character set used within > the body part. NEW TEXT: > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. The character sets supported by this revision > of iCalendar are UTF-8 and US-ASCII. Section 4.1.4 Character Set OLD TEXT: > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > object is UTF-8 as defined in [RFC 2279]. > > The "charset" Content-Type parameter can be used in MIME transports > to specify any other IANA registered character set. NEW TEXT: > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > object is UTF-8 as defined in [RFC 3629]. > > The character sets supported by this revision of iCalendar are UTF-8 > and US-ASCII. Compliant applications MUST accept iCalendar objects > using the UTF-8 or US-ASCII character set and SHOULD generate > iCalendar object using the UTF-8 character set. > > The "charset" Content-Type parameter can be used in MIME transports > to specify the character set being used. Section 4.3.11 Text OLD TEXT: > Formal Definition: The character sets supported by this revision of > iCalendar are UTF-8 and US ASCII thereof. The applicability to other > character sets is for future work. The value type is defined by the > following notation. NEW TEXT: > Formal Definition: The value type is defined by the following notation: Cheers, Bernard Bernard Desruisseaux wrote: > Hi Mark, > > I don't feel that it is important for new work to support any > character set other than UTF-8, but I'm not sure whether rfc2445bis > should be considered as new work though! > > In my proposal I only quoted section 4.3.11 which makes clear that > UTF-8 and US-ASCII are the only character sets supported by iCalendar. > I should probably have quoted the other sections where character sets > are discussed, that is, sections 2.3, 3.2, and more importantly 4.1.4: > > Section 4.1.4 Character Set > > > The "charset" Content-Type parameter can be used in MIME transports > > to specify any other IANA registered character set. > > Section 4.3.11 says that only UTF-8 and US-ASCII are supported. > While section 4.1.4 says that you can specify any IANA registered > character set in the "charset" parameter... > > The result is that some iCalendar applications currently output > iCalendar objects in ISO-8859-1. > > I see two options: > > a) We modify section 4.3.11 as I proposed. But now I realize > that we would also need to modify all the ABNF rules that > makes reference to the numerical value of specific characters > (e.g., LF = %x0A in US-ASCII but %x25 in EBCDIC). Yuk! > > b) We modify sections 3.2, 4.1.4 and 4.3.11 to be in sync and > clearly specify which character sets are supported by iCalendar: > > b.1) UTF-8 only. > b.2) UTF-8 and US-ASCII only. > b.3) UTF-8, US-ASCII, and ISO-8859-1 only. > > At this point I favor option (b.3). It looks to me as the easiest > way to clarify the specification without breaking most (if not all) > existing iCalendar applications. > > Cheers, > Bernard > > Mark Crispin wrote: >> On Mon, 21 Aug 2006, Bernard Desruisseaux wrote: >>> I don't see any reason why it states that only UTF-8 and US-ASCII >>> are supported by this revision. Section "3.2 Parameter" doesn't >>> specify any restriction on the values allowed for the "charset" >>> parameter. >>> I propose to remove this statement from section 4.3.11. >> >> Can you explain why you feel that it is important for new work to >> support any character set other than UTF-8? If any revision is made, >> it should be to delete US-ASCII and make UTF-8 mandatory. >> >> -- Mark -- >> >> http://panda.com/mrc >> Democracy is two wolves and a sheep deciding what to eat for lunch. >> Liberty is a well-armed sheep contesting the vote. > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From bernard.desruisseaux at oracle.com Thu Sep 21 11:20:45 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Sep 21 11:21:43 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <450FB6D6.6000601@cisco.com> References: <450FB6D6.6000601@cisco.com> Message-ID: <4512D7FD.4070805@oracle.com> Eliot Lear wrote: > > > [...] > > I have two recommendations for textual changes to RFC 2445: > > 1. Delete the second sentence in the 2nd paragraph after the example > in 4.1 as redundant (it says the exact same thing in the first > paragraph); +1 > 2. Add a sentence as follows: "It is possible for very simple > implementations to have improperly folded lines in the middle of > UTF-8 characters. In such cases, implementations SHOULD unfold > lines in such a way to properly restore the character. I would make that a "Note", I would replace "UTF-8 characters" by "character" and I would lowercase the SHOULD. That is: > Note: It is possible for very simple implementations to have > improperly folded lines in the middle of a character. In such > cases, implementations should unfold lines in such a way to > properly restore the character. Thanks, Bernard > > Eliot > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From cyrus at daboo.name Thu Sep 21 11:21:52 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Sep 21 11:22:09 2006 Subject: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: <4512D5E5.6090400@oracle.com> References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> Message-ID: <520F1DFF22E934D043E7D4B7@Cyrus-Daboo-G5.local> Hi Bernard, --On September 21, 2006 2:11:49 PM -0400 Bernard Desruisseaux wrote: +1 to your new text on charset. -- Cyrus Daboo From mrc at CAC.Washington.EDU Thu Sep 21 11:32:55 2006 From: mrc at CAC.Washington.EDU (Mark Crispin) Date: Thu Sep 21 11:33:02 2006 Subject: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: <4512D5E5.6090400@oracle.com> References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> Message-ID: On Thu, 21 Sep 2006, Bernard Desruisseaux wrote: > - The use of other character set is not forbidden. Can it be deprecated though? US-ASCII, UTF-8, etc. are charsets, not character sets. This is particularly important with UTF-8; the character set is Unicode, not UTF-8. Finally, since you already state that UTF-8 SHOULD be generated, there is no reason that US-ASCII be listed as a supported charset. It sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted. Suggested wording: The "charset" parameter is defined in [RFC 2046] for subtypes of the "text" media type. It is used to indicate the character set used in the body part. The charset supported by this revision of iCalendar is UTF-8. The use of any other charset is deprecated by this revision of iCalendar; however note that this revision requires that compliant applications MUST accept iCalendar objects using either the UTF-8 or US-ASCII charset. Also change other occurances of "character set" to "charset". -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From alexey.melnikov at isode.com Thu Sep 21 11:59:50 2006 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Sep 21 12:00:17 2006 Subject: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: <4512D5E5.6090400@oracle.com> References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> Message-ID: <4512E126.1070302@isode.com> Bernard Desruisseaux wrote: > Folks, I would like to close issue 31 with a new proposal: > > - UTF-8 and US-ASCII are the only character set supported by iCalendar. > - The use of other character set is not forbidden. > - Compliant applications are REQUIRED to accept UTF-8 and US-ASCII. > - Compliant applications SHOULD generate iCalendar objects in UTF-8. > > Here's the proposed text changes: > > Section 3.2 Parameters > > OLD TEXT: > >> The "charset" parameter is defined in [RFC 2046] for other body >> parts. It is used to identify the default character set used within >> the body part. > > NEW TEXT: > >> The "charset" parameter is defined in [RFC 2046] for subtypes of >> the "text" media type. It is used to indicate the character set > >> used in the body part. The character sets supported by this revision > As per Mark's comment: replace "character set" with "charset" >> of iCalendar are UTF-8 and US-ASCII. > > > Section 4.1.4 Character Set > > OLD TEXT: > >> There is not a property parameter to declare the character set used >> in a property value. The default character set for an iCalendar >> object is UTF-8 as defined in [RFC 2279]. >> >> The "charset" Content-Type parameter can be used in MIME transports >> to specify any other IANA registered character set. > > NEW TEXT: > >> There is not a property parameter to declare the character set used > s/character set/charset >> in a property value. The default character set for an iCalendar > s/character set/charset >> object is UTF-8 as defined in [RFC 3629]. >> >> The character sets supported by this revision of iCalendar are UTF-8 > s/character sets/charsets >> and US-ASCII. Compliant applications MUST accept iCalendar objects >> using the UTF-8 or US-ASCII character set and SHOULD generate >> iCalendar object using the UTF-8 character set. >> >> The "charset" Content-Type parameter can be used in MIME transports >> to specify the character set being used. > I would change the last sentence to become normative: The "charset" Content-Type parameter MUST be used in MIME transports to specify the charset being used. (this MUST is irrelevant for US-ASCII case, but I can't think of any better way of saying that) > Section 4.3.11 Text > > OLD TEXT: > >> Formal Definition: The character sets supported by this revision of >> iCalendar are UTF-8 and US ASCII thereof. The applicability to other >> character sets is for future work. The value type is defined by the >> following notation. > > NEW TEXT: > >> Formal Definition: The value type is defined by the following notation: > Otherwise I am fine with this proposal. From alexey.melnikov at isode.com Thu Sep 21 12:01:40 2006 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Sep 21 12:02:07 2006 Subject: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> Message-ID: <4512E194.2090009@isode.com> Mark Crispin wrote: > On Thu, 21 Sep 2006, Bernard Desruisseaux wrote: > >> - The use of other character set is not forbidden. > > Can it be deprecated though? > > US-ASCII, UTF-8, etc. are charsets, not character sets. This is > particularly important with UTF-8; the character set is Unicode, not > UTF-8. > > Finally, since you already state that UTF-8 SHOULD be generated, there > is no reason that US-ASCII be listed as a supported charset. It > sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted. > > Suggested wording: > > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. The charset supported by this revision of > iCalendar is UTF-8. The use of any other charset is deprecated by > this revision of iCalendar; however note that this revision > requires that compliant applications MUST accept iCalendar objects > using either the UTF-8 or US-ASCII charset. I can live with this alternative text as well. > Also change other occurances of "character set" to "charset". From alexey.melnikov at isode.com Thu Sep 21 12:09:08 2006 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Thu Sep 21 12:09:35 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <4512D7FD.4070805@oracle.com> References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> Message-ID: <4512E354.7050208@isode.com> Bernard Desruisseaux wrote: > Eliot Lear wrote: > >> > > > [...] > >> I have two recommendations for textual changes to RFC 2445: >> >> 1. Delete the second sentence in the 2nd paragraph after the example >> in 4.1 as redundant (it says the exact same thing in the first >> paragraph); > > +1 +1 >> 2. Add a sentence as follows: "It is possible for very simple >> implementations to have improperly folded lines in the middle of >> UTF-8 characters. In such cases, implementations SHOULD unfold >> lines in such a way to properly restore the character. > > I would make that a "Note", I would replace "UTF-8 characters" by > "character" and I would lowercase the SHOULD. That is: > > > Note: It is possible for very simple implementations to have > > improperly folded lines in the middle of a character. In such > > cases, implementations should unfold lines in such a way to > > properly restore the character. I would also delete "In such cases". A receiving client has no other choice. From lear at cisco.com Thu Sep 21 12:42:05 2006 From: lear at cisco.com (Eliot Lear) Date: Thu Sep 21 12:42:13 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <4512D7FD.4070805@oracle.com> References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> Message-ID: <4512EB0D.4060302@cisco.com> Are there any objections to the below? Oliver? Bernard Desruisseaux wrote: > Eliot Lear wrote: >> >> > > [...] > > >> I have two recommendations for textual changes to RFC 2445: >> >> 1. Delete the second sentence in the 2nd paragraph after the example >> in 4.1 as redundant (it says the exact same thing in the first >> paragraph); > > +1 > >> 2. Add a sentence as follows: "It is possible for very simple >> implementations to have improperly folded lines in the middle of >> UTF-8 characters. In such cases, implementations SHOULD unfold >> lines in such a way to properly restore the character. > > I would make that a "Note", I would replace "UTF-8 characters" by > "character" and I would lowercase the SHOULD. That is: > > > Note: It is possible for very simple implementations to have > > improperly folded lines in the middle of a character. In such > > cases, implementations should unfold lines in such a way to > > properly restore the character. > > Thanks, > Bernard > >> >> Eliot >> >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From lear at cisco.com Thu Sep 21 12:44:21 2006 From: lear at cisco.com (Eliot Lear) Date: Thu Sep 21 12:44:30 2006 Subject: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> Message-ID: <4512EB95.3050603@cisco.com> Are there objections to Mark's proposed wording? Eliot Mark Crispin wrote: > On Thu, 21 Sep 2006, Bernard Desruisseaux wrote: >> - The use of other character set is not forbidden. > > Can it be deprecated though? > > US-ASCII, UTF-8, etc. are charsets, not character sets. This is > particularly important with UTF-8; the character set is Unicode, not > UTF-8. > > Finally, since you already state that UTF-8 SHOULD be generated, there > is no reason that US-ASCII be listed as a supported charset. It > sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted. > > Suggested wording: > > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. The charset supported by this revision of > iCalendar is UTF-8. The use of any other charset is deprecated by > this revision of iCalendar; however note that this revision > requires that compliant applications MUST accept iCalendar objects > using either the UTF-8 or US-ASCII charset. > > Also change other occurances of "character set" to "charset". > > -- Mark -- > > http://panda.com/mrc > Democracy is two wolves and a sheep deciding what to eat for lunch. > Liberty is a well-armed sheep contesting the vote. > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From MRC at CAC.Washington.EDU Thu Sep 21 14:21:28 2006 From: MRC at CAC.Washington.EDU (Mark Crispin) Date: Thu Sep 21 14:23:59 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <4512E354.7050208@isode.com> References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512E354.7050208@isode.com> Message-ID: On Thu, 21 Sep 2006, Alexey Melnikov wrote: >>> 2. Add a sentence as follows: "It is possible for very simple >>> implementations to have improperly folded lines in the middle of >>> UTF-8 characters. In such cases, implementations SHOULD unfold >>> lines in such a way to properly restore the character. >> I would make that a "Note", I would replace "UTF-8 characters" by >> "character" and I would lowercase the SHOULD. Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear what we are talking about. Other charsets have multi-octet sequences too, but we've deprecated the use of these. Suggest using "need to" instead of "should", to indicate that this is a corrolary technical requirement as opposed to something specifically required by the protocol. >> That is: >> > Note: It is possible for very simple implementations to have >> > improperly folded lines in the middle of a character. In such >> > cases, implementations should unfold lines in such a way to >> > properly restore the character. > I would also delete "In such cases". A receiving client has no other choice. Another good point. In conclusion, suggest: Note: It is possible for very simple implementations to generate improperly folded lines in the middle of a UTF-8 multi-octet sequence. For this reason, implementations need to unfold lines in such a way to properly restore the unbroken sequence. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From alexey.melnikov at isode.com Fri Sep 22 02:58:14 2006 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Fri Sep 22 02:58:44 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512E354.7050208@isode.com> Message-ID: <4513B3B6.5030503@isode.com> Mark Crispin wrote: > On Thu, 21 Sep 2006, Alexey Melnikov wrote: > >>>> 2. Add a sentence as follows: "It is possible for very simple >>>> implementations to have improperly folded lines in the middle of >>>> UTF-8 characters. In such cases, implementations SHOULD unfold >>>> lines in such a way to properly restore the character. >>> >>> I would make that a "Note", I would replace "UTF-8 characters" by >>> "character" and I would lowercase the SHOULD. >> > Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear what > we are talking about. Other charsets have multi-octet sequences too, > but we've deprecated the use of these. > > Suggest using "need to" instead of "should", to indicate that this is > a corrolary technical requirement as opposed to something specifically > required by the protocol. > >>> That is: >>> > Note: It is possible for very simple implementations to have >>> > improperly folded lines in the middle of a character. In such >>> > cases, implementations should unfold lines in such a way to >>> > properly restore the character. >> >> I would also delete "In such cases". A receiving client has no other >> choice. > > Another good point. > > In conclusion, suggest: > > Note: It is possible for very simple implementations to generate > improperly folded lines in the middle of a UTF-8 multi-octet > sequence. For this reason, implementations need to unfold lines > in such a way to properly restore the unbroken sequence. I like that, but "unbroken" reads strangely hear (the sender might have broken it). Maybe "restore the original sequence"? From lists at block-online.eu Fri Sep 22 04:23:04 2006 From: lists at block-online.eu (Oliver Block) Date: Fri Sep 22 04:23:38 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <4512EB0D.4060302@cisco.com> References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512EB0D.4060302@cisco.com> Message-ID: <200609221323.04606.lists@block-online.eu> Am Donnerstag, 21. September 2006 21:42 schrieb Eliot Lear: > Are there any objections to the below? Oliver? None, that I'd like to express in this stage of decision making. Best Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html From lear at cisco.com Fri Sep 22 04:45:29 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 22 04:45:35 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <4513B3B6.5030503@isode.com> References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512E354.7050208@isode.com> <4513B3B6.5030503@isode.com> Message-ID: <4513CCD9.7070904@cisco.com> Alexey Melnikov wrote: > Mark Crispin wrote: > >> On Thu, 21 Sep 2006, Alexey Melnikov wrote: >> >>>>> 2. Add a sentence as follows: "It is possible for very simple >>>>> implementations to have improperly folded lines in the >>>>> middle of >>>>> UTF-8 characters. In such cases, implementations SHOULD unfold >>>>> lines in such a way to properly restore the character. >>>> >>>> I would make that a "Note", I would replace "UTF-8 characters" by >>>> "character" and I would lowercase the SHOULD. >>> >> Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear >> what we are talking about. Other charsets have multi-octet sequences >> too, but we've deprecated the use of these. >> >> Suggest using "need to" instead of "should", to indicate that this is >> a corrolary technical requirement as opposed to something >> specifically required by the protocol. >> >>>> That is: >>>> > Note: It is possible for very simple implementations to have >>>> > improperly folded lines in the middle of a character. In such >>>> > cases, implementations should unfold lines in such a way to >>>> > properly restore the character. >>> >>> I would also delete "In such cases". A receiving client has no other >>> choice. >> >> Another good point. >> >> In conclusion, suggest: >> >> Note: It is possible for very simple implementations to generate >> improperly folded lines in the middle of a UTF-8 multi-octet >> sequence. For this reason, implementations need to unfold lines >> in such a way to properly restore the unbroken sequence. > > I like that, but "unbroken" reads strangely hear (the sender might > have broken it). > Maybe "restore the original sequence"? > That sounds like consensus wording to me if ever I heard some. Can we move along? Eliot From mrc at CAC.Washington.EDU Fri Sep 22 09:24:40 2006 From: mrc at CAC.Washington.EDU (Mark Crispin) Date: Fri Sep 22 09:24:59 2006 Subject: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <4513CCD9.7070904@cisco.com> References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512E354.7050208@isode.com> <4513B3B6.5030503@isode.com> <4513CCD9.7070904@cisco.com> Message-ID: On Fri, 22 Sep 2006, Eliot Lear wrote: > That sounds like consensus wording to me if ever I heard some. Can we > move along? Sold! -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From lists at block-online.eu Fri Sep 22 16:04:07 2006 From: lists at block-online.eu (Oliver Block) Date: Fri Sep 22 16:04:37 2006 Subject: [Ietf-calsify] ABNF Message-ID: <200609230104.08779.lists@block-online.eu> Hello list, The ABNF notation could be spared. As an example (page 51/52): calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once prodid /version / ; 'calscale' and 'method' are optional, ; but MUST NOT occur more than once calscale / method / x-prop ) Could be noted as follows: calprops = prodid version *1calscale *1method *x-prop or: calprops = prodid version [calscale] [method] *x-prop Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html From bernard.desruisseaux at oracle.com Fri Sep 22 17:31:17 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Fri Sep 22 17:35:12 2006 Subject: [Ietf-calsify] ABNF In-Reply-To: <200609230104.08779.lists@block-online.eu> References: <200609230104.08779.lists@block-online.eu> Message-ID: <45148055.30006@oracle.com> Hi Oliver, The notation you are proposing would dictate a specific ordering of the properties. Cheers, Bernard Oliver Block wrote: > Hello list, > > The ABNF notation could be spared. > > As an example (page 51/52): > > calprops = 2*( > > ; 'prodid' and 'version' are both REQUIRED, > ; but MUST NOT occur more than once > > prodid /version / > > ; 'calscale' and 'method' are optional, > ; but MUST NOT occur more than once > > calscale / > method / > > x-prop > > ) > > Could be noted as follows: > > calprops = prodid version *1calscale *1method *x-prop > > or: > > calprops = prodid version [calscale] [method] *x-prop > > Regards, > > Oliver > From cyrus at daboo.name Sat Sep 23 07:46:53 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Sat Sep 23 07:47:03 2006 Subject: [Ietf-calsify] ABNF In-Reply-To: <45148055.30006@oracle.com> References: <200609230104.08779.lists@block-online.eu> <45148055.30006@oracle.com> Message-ID: <905D630229904F49EB559429@ninevah.local> Hi Bernard, --On September 22, 2006 8:31:17 PM -0400 Bernard Desruisseaux wrote: > The notation you are proposing would dictate a specific > ordering of the properties. Unfortunately ABNF itself does not have the concept of an 'unordered' list of items. However, the last time I discussed this with ABNF folks, I think the general consensus was that it was OK to add a comment to the ABNF stating that all items in that element were 'unordered'. So we could have: calprops = prodid version [calscale] [method] *x-prop ; can appear in any order I do think that is better than having comments indicating the frequency of occurrence of each element as we have now. -- Cyrus Daboo From lear at cisco.com Mon Sep 25 03:27:58 2006 From: lear at cisco.com (Eliot Lear) Date: Mon Sep 25 03:28:02 2006 Subject: [Ietf-calsify] Issue 33: characters v. octets Message-ID: <4517AF2E.5040407@cisco.com> After a long drawn out discussion on Issue 1 regarding breaking of lines, I would also like to close on Issue 33, which reads: > http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/001078.html > > In section 4.8.4.7 Unique Identifier of RFC 2445 it says: > > > Implementations MUST be able to receive and persist values of at > > least 255 characters for this property. > > And, in Section 6 Recommended Practices it also says: > > > 6. An implementation can truncate a "SUMMARY" property value to 255 > > characters. > > In both sections I propose to change "255 characters" to "255 octets". I propose the following alternative wording: In section 4.8.4.7: > Implementations MUST be able to receive and persist values of at > least 255 octets for this property, but MUST not truncate values > in the middle of a character. In section 6: > 6. An implementation can truncate a "SUMMARY" property value to 255 > octets, but should not truncate the property value in the middle > of a character. If someone has appropriate wording to perhaps replace the word "character" with code point, that would be fine too. From lear at cisco.com Mon Sep 25 05:01:43 2006 From: lear at cisco.com (Eliot Lear) Date: Mon Sep 25 05:01:47 2006 Subject: [Ietf-calsify] ABNF In-Reply-To: <905D630229904F49EB559429@ninevah.local> References: <200609230104.08779.lists@block-online.eu> <45148055.30006@oracle.com> <905D630229904F49EB559429@ninevah.local> Message-ID: <4517C527.7050509@cisco.com> Cyrus, > > Unfortunately ABNF itself does not have the concept of an 'unordered' > list of items. However, the last time I discussed this with ABNF > folks, I think the general consensus was that it was OK to add a > comment to the ABNF stating that all items in that element were > 'unordered'. So we could have: > > calprops = prodid version [calscale] [method] *x-prop > ; can appear in any order > > I do think that is better than having comments indicating the > frequency of occurrence of each element as we have now. > We have to be extremely careful about these changes, but I believe the above text is actually more clear than what is there. Does anyone object to this change? Eliot From lear at cisco.com Mon Sep 25 06:02:40 2006 From: lear at cisco.com (Eliot Lear) Date: Mon Sep 25 06:02:44 2006 Subject: [Ietf-calsify] Issue 19: IANA considerations for RFC2445bis Message-ID: <4517D370.7050806@cisco.com> [Chair hat off again] All, Our charter calls for us to clarify IANA considerations for new components / tokens. In my opinion interoperability demands that new components be documented. My preference is by RFC. A procedure, however, for the content of the RFC would smooth things along. How would people like to proceed? Think about how DHCP options are handled, for instance. There's a template and people use it, and eventually an option is assigned by IANA. In case you're wondering just how this relates to the price of tea in China, at the last Calconnect (as opposed to the one going on now), there was a proposal to include some sort of venue information, like telephone number or number of seats or the like. Having something along these lines would be useful. There's a lot of meta information out there about things like meeting rooms that we don't want to duplicate from people's LDAP directories, of course. But the common example of this might be telephone information relating to conferencing. We don't want to make additions like this too difficult, but I think they should still be subject to some sort of review. Now, from my reading of the current draft the only thing that IANA needs to keep track of is iana-token. Is that correct? If so, I propose the following text: The IANA is requested to maintain a database of tokens. Each token should be associated with an RFC that has undergone review by the IETF. Each such RFC shall make use of the following template to register tokens: 1. Token Name 2. Context in which the token is valid (vevent / vprop / vtodo / ... ) 3. ABNF description of the token, using the context of this memo 4. How many of these may appear in one context? 5. Semantic specification of the token or a reference thereto. (Contrived) Example: 1. Token Name: VENUE 2. Valid Context: VEVENT 3. ABNF: venui = "VENUE" ":" 1*( rconfinfo / confroominfo ) rconfinfo = "REMOTE" ( "/" ( vconfurl ) / ( confnum ["+" confpass] )) ... Comments? Eliot From alexey.melnikov at isode.com Mon Sep 25 09:07:29 2006 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Mon Sep 25 09:08:22 2006 Subject: [Ietf-calsify] Issue 19: IANA considerations for RFC2445bis In-Reply-To: <4517D370.7050806@cisco.com> References: <4517D370.7050806@cisco.com> Message-ID: <4517FEC1.1060300@isode.com> Eliot Lear wrote: >[Chair hat off again] > >All, > >Our charter calls for us to clarify IANA considerations for new >components / tokens. In my opinion interoperability demands that new >components be documented. My preference is by RFC. A procedure, >however, for the content of the RFC would smooth things along. How >would people like to proceed? Think about how DHCP options are handled, >for instance. There's a template and people use it, and eventually an >option is assigned by IANA. > >In case you're wondering just how this relates to the price of tea in >China, at the last Calconnect (as opposed to the one going on now), >there was a proposal to include some sort of venue information, like >telephone number or number of seats or the like. Having something along >these lines would be useful. There's a lot of meta information out >there about things like meeting rooms that we don't want to duplicate >from people's LDAP directories, of course. But the common example of >this might be telephone information relating to conferencing. > >We don't want to make additions like this too difficult, but I think >they should still be subject to some sort of review. > >Now, from my reading of the current draft the only thing that IANA needs >to keep track of is iana-token. Is that correct? If so, I propose the >following text: > >The IANA is requested to maintain a database of tokens. Each token >should be associated with an RFC that has undergone review by the IETF. > > If this procedure is not to be enforced on vendor specific tokens, than this is Ok. (Your template looks fine.) From alexey.melnikov at isode.com Mon Sep 25 10:54:25 2006 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Mon Sep 25 10:55:22 2006 Subject: [Ietf-calsify] ABNF In-Reply-To: <4517C527.7050509@cisco.com> References: <200609230104.08779.lists@block-online.eu> <45148055.30006@oracle.com> <905D630229904F49EB559429@ninevah.local> <4517C527.7050509@cisco.com> Message-ID: <451817D1.1050601@isode.com> Eliot Lear wrote: >Cyrus, > > >>Unfortunately ABNF itself does not have the concept of an 'unordered' >>list of items. However, the last time I discussed this with ABNF >>folks, I think the general consensus was that it was OK to add a >>comment to the ABNF stating that all items in that element were >>'unordered'. So we could have: >> >>calprops = prodid version [calscale] [method] *x-prop >> ; can appear in any order >> >>I do think that is better than having comments indicating the >>frequency of occurrence of each element as we have now. >> >> > >We have to be extremely careful about these changes, but I believe the >above text is actually more clear than what is there. Does anyone >object to this change? > > I don't have any objections, however many people don't bother reading ABNF. So this comment should also appear in the text. From lear at cisco.com Mon Sep 25 10:57:58 2006 From: lear at cisco.com (Eliot Lear) Date: Mon Sep 25 10:58:04 2006 Subject: [Ietf-calsify] ABNF In-Reply-To: <451817D1.1050601@isode.com> References: <200609230104.08779.lists@block-online.eu> <45148055.30006@oracle.com> <905D630229904F49EB559429@ninevah.local> <4517C527.7050509@cisco.com> <451817D1.1050601@isode.com> Message-ID: <451818A6.9010206@cisco.com> Alexey Melnikov wrote: >>> >>> calprops = prodid version [calscale] [method] *x-prop >>> ; can appear in any order >>> >>> I do think that is better than having comments indicating the >>> frequency of occurrence of each element as we have now. >>> >> >> We have to be extremely careful about these changes, but I believe the >> above text is actually more clear than what is there. Does anyone >> object to this change? >> >> > I don't have any objections, however many people don't bother reading > ABNF. So this comment should also appear in the text. > Right. Similar to the one that there now ;-) From bernard.desruisseaux at oracle.com Mon Sep 25 11:16:41 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Sep 25 11:17:30 2006 Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type Message-ID: <45181D09.5030007@oracle.com> In section 4.8.6.3 Trigger of RFC 2445 it says: > Alarms specified in an event or to-do which is defined in terms of a > DATE value type will be triggered relative to 00:00:00 UTC on the > specified date. For example, if "DTSTART:19980205, then the duration > trigger will be relative to19980205T000000Z. In my opinion, applications should trigger the alarm relative to 00:00:00 of the time zone configured on the calendar that contains the event or to-do, or the current user's preferred time zone. UTC should only be used when no specific time zone can be found in the current context. Cheers, Bernard From lear at cisco.com Mon Sep 25 11:47:43 2006 From: lear at cisco.com (Eliot Lear) Date: Mon Sep 25 11:47:48 2006 Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type In-Reply-To: <45181D09.5030007@oracle.com> References: <45181D09.5030007@oracle.com> Message-ID: <4518244F.8090808@cisco.com> Bernard, > In section 4.8.6.3 Trigger of RFC 2445 it says: > > > Alarms specified in an event or to-do which is defined in terms of a > > DATE value type will be triggered relative to 00:00:00 UTC on the > > specified date. For example, if "DTSTART:19980205, then the duration > > trigger will be relative to19980205T000000Z. > > In my opinion, applications should trigger the alarm relative to > 00:00:00 of the time zone configured on the calendar that contains > the event or to-do, or the current user's preferred time zone. UTC > should only be used when no specific time zone can be found in the > current context. I agree in principle. However, I am concerned about existing implementations. Alarms are used, and if we make this change then how many implementations immediately become non-compliant? Eliot From reinhold at kainhofer.com Mon Sep 25 13:26:34 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Mon Sep 25 13:29:15 2006 Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type In-Reply-To: <4518244F.8090808@cisco.com> References: <45181D09.5030007@oracle.com> <4518244F.8090808@cisco.com> Message-ID: <200609252126.34650.reinhold@kainhofer.com> On Monday 25 September 2006 19:47, Eliot Lear wrote: > Bernard, > > > In section 4.8.6.3 Trigger of RFC 2445 it says: > > > Alarms specified in an event or to-do which is defined in terms of a > > > DATE value type will be triggered relative to 00:00:00 UTC on the > > > specified date. For example, if "DTSTART:19980205, then the duration > > > trigger will be relative to19980205T000000Z. > > > > In my opinion, applications should trigger the alarm relative to > > 00:00:00 of the time zone configured on the calendar that contains > > the event or to-do, or the current user's preferred time zone. UTC > > should only be used when no specific time zone can be found in the > > current context. > > I agree in principle. However, I am concerned about existing > implementations. Alarms are used, and if we make this change then how > many implementations immediately become non-compliant? On the other hand, how many implementations violated the RFC so far and would be compliant after the change? Cheers, Reinhold From TimHare at comcast.net Mon Sep 25 17:41:00 2006 From: TimHare at comcast.net (Tim Hare) Date: Mon Sep 25 17:41:10 2006 Subject: [Ietf-calsify] Issue 33: characters v. octets In-Reply-To: <4517AF2E.5040407@cisco.com> Message-ID: <20060926004108.B39BE14229F@laweleka.osafoundation.org> Section 6 should also say 'MUST not truncate', it needs to be the same in both places, other than that I agree with the proposed change. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Eliot Lear Sent: Monday, September 25, 2006 6:28 AM To: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Issue 33: characters v. octets After a long drawn out discussion on Issue 1 regarding breaking of lines, I would also like to close on Issue 33, which reads: > http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/0010 > 78.html > > In section 4.8.4.7 Unique Identifier of RFC 2445 it says: > > > Implementations MUST be able to receive and persist values of at > > least 255 characters for this property. > > And, in Section 6 Recommended Practices it also says: > > > 6. An implementation can truncate a "SUMMARY" property value to 255 > > characters. > > In both sections I propose to change "255 characters" to "255 octets". I propose the following alternative wording: In section 4.8.4.7: > Implementations MUST be able to receive and persist values of at > least 255 octets for this property, but MUST not truncate values > in the middle of a character. In section 6: > 6. An implementation can truncate a "SUMMARY" property value to 255 > octets, but should not truncate the property value in the middle > of a character. If someone has appropriate wording to perhaps replace the word "character" with code point, that would be fine too. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From lear at cisco.com Tue Sep 26 00:54:50 2006 From: lear at cisco.com (Eliot Lear) Date: Tue Sep 26 00:54:55 2006 Subject: [Ietf-calsify] jabber session next week? Message-ID: <4518DCCA.5010808@cisco.com> All, We have a lot of open issues that we would like to close soon. Aki and I would like to understand whether or not there would be interest in a jabber session to try to come to consensus on open issues. We would propose either Tuesday or Wednesday at 5:00pm CEST (8:00am PDT). If you are interested, could you send an email indicating which day you prefer. I will follow up in a day or two with a real invitation in appropriate format (of course!). Thanks for your participation, Eliot From bernard.desruisseaux at oracle.com Tue Sep 26 08:41:07 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Tue Sep 26 08:42:58 2006 Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type In-Reply-To: <4518244F.8090808@cisco.com> References: <45181D09.5030007@oracle.com> <4518244F.8090808@cisco.com> Message-ID: <45194A13.5050201@oracle.com> Hi Eliot, Eliot Lear wrote: > Bernard, >> In section 4.8.6.3 Trigger of RFC 2445 it says: >> >>> Alarms specified in an event or to-do which is defined in terms of a >>> DATE value type will be triggered relative to 00:00:00 UTC on the >>> specified date. For example, if "DTSTART:19980205, then the duration >>> trigger will be relative to19980205T000000Z. >> In my opinion, applications should trigger the alarm relative to >> 00:00:00 of the time zone configured on the calendar that contains >> the event or to-do, or the current user's preferred time zone. UTC >> should only be used when no specific time zone can be found in the >> current context. > > > I agree in principle. However, I am concerned about existing > implementations. Alarms are used, and if we make this change then how > many implementations immediately become non-compliant? The only thing that matter is whether users will receive their alarm at the time they expect to receive them. People using applications that implement what the RFC says will most likely not get their alarm at the time they expect. In my case, I would receive them 5 hours in advance during Eastern Standard Time, and 4 hours in advance when in Eastern Daylight Time. I doubt there's any implementation that do this. Currently, the text doesn't specify any clear requirement level (i.e., MAY, SHOULD, MUST). I think it should. Thanks, Bernard > > Eliot From lists at block-online.eu Tue Sep 26 12:29:13 2006 From: lists at block-online.eu (Oliver Block) Date: Tue Sep 26 12:29:46 2006 Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type In-Reply-To: <45194A13.5050201@oracle.com> References: <45181D09.5030007@oracle.com> <4518244F.8090808@cisco.com> <45194A13.5050201@oracle.com> Message-ID: <200609262129.14170.lists@block-online.eu> Am Dienstag, 26. September 2006 17:41 schrieb Bernard Desruisseaux: > >> In section 4.8.6.3 Trigger of RFC 2445 it says: > >>> Alarms specified in an event or to-do which is defined in terms of a > >>> DATE value type will be triggered relative to 00:00:00 UTC on the > >>> specified date. For example, if "DTSTART:19980205, then the duration > >>> trigger will be relative to19980205T000000Z. > >> In my opinion, applications should trigger the alarm relative to > >> 00:00:00 of the time zone configured on the calendar that contains > >> the event or to-do, or the current user's preferred time zone. UTC > >> should only be used when no specific time zone can be found in the > >> current context. In my view every application is free to do that. It would just not define the value for DTSTART as DATE but as DATE-TIME. In other words: I find your opinion more intuitive than the standard and that's what a user will expect. On the other hand the standard will assure that every application will interpret a DATE value in the same way. Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html From bernard.desruisseaux at oracle.com Wed Sep 27 12:38:57 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Wed Sep 27 12:40:32 2006 Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type In-Reply-To: <200609262129.14170.lists@block-online.eu> References: <45181D09.5030007@oracle.com> <4518244F.8090808@cisco.com> <45194A13.5050201@oracle.com> <200609262129.14170.lists@block-online.eu> Message-ID: <451AD351.4050008@oracle.com> Oliver, Isn't the purpose of the DATE value type to allow its value to be interpreted differently by different people depending on their time zone? Else, why would iCalendar bother defining this value type? :-) The exact start and end time of events such as "Christmas", "New Year's Day", "Canada Day" etc. depends on the time zone of the user. Cheers, Bernard Oliver Block wrote: > Am Dienstag, 26. September 2006 17:41 schrieb Bernard Desruisseaux: >>>> In section 4.8.6.3 Trigger of RFC 2445 it says: >>>>> Alarms specified in an event or to-do which is defined in terms of a >>>>> DATE value type will be triggered relative to 00:00:00 UTC on the >>>>> specified date. For example, if "DTSTART:19980205, then the duration >>>>> trigger will be relative to19980205T000000Z. > >>>> In my opinion, applications should trigger the alarm relative to >>>> 00:00:00 of the time zone configured on the calendar that contains >>>> the event or to-do, or the current user's preferred time zone. UTC >>>> should only be used when no specific time zone can be found in the >>>> current context. > > In my view every application is free to do that. It would just not define the > value for DTSTART as DATE but as DATE-TIME. > In other words: I find your opinion more intuitive than the standard and > that's what a user will expect. On the other hand the standard will assure > that every application will interpret a DATE value in the same way. > > Regards, > > Oliver > From lists at block-online.eu Thu Sep 28 03:08:12 2006 From: lists at block-online.eu (Oliver Block) Date: Thu Sep 28 03:08:43 2006 Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type Message-ID: <200609281208.13107.lists@block-online.eu> Am Mittwoch, 27. September 2006 21:38 schrieben Sie: > Isn't the purpose of the DATE value type to allow its value to be > interpreted differently by different people depending on their time > zone? Else, why would iCalendar bother defining this value type? :-) I forgot. And by defining a locally interpreted DATE value type it eliminates the existance of a universally interpreted DATE value type - as long as the DATE value type has nor further format specification, e.g. like DATE-TIME. :) Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html From aki.niemi at nokia.com Thu Sep 28 06:07:43 2006 From: aki.niemi at nokia.com (Aki Niemi) Date: Thu Sep 28 06:07:53 2006 Subject: [Ietf-calsify] jabber session next week? In-Reply-To: <4518DCCA.5010808@cisco.com> References: <4518DCCA.5010808@cisco.com> Message-ID: <451BC91F.6050907@nokia.com> Folks, We're getting closer to WGLC every day and it's not that far away anymore. We really, really need to close these issues, hence the jabber session. Yet, you are being awfully quiet on this. Please, plan to attend if at all possible, and indicate the day you prefer. We need you to participate. Cheers, Aki (as chair) ext Eliot Lear kirjoitti: > > > All, > > We have a lot of open issues that we would like to close soon. Aki and > I would like to understand whether or not there would be interest in a > jabber session to try to come to consensus on open issues. We would > propose either Tuesday or Wednesday at 5:00pm CEST (8:00am PDT). If you > are interested, could you send an email indicating which day you > prefer. I will follow up in a day or two with a real invitation in > appropriate format (of course!). > > Thanks for your participation, > > Eliot > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From br at osafoundation.org Thu Sep 28 17:28:04 2006 From: br at osafoundation.org (Bobby Rullo) Date: Thu Sep 28 17:24:05 2006 Subject: [Ietf-calsify] Modifications to instances in a recurrence chain Message-ID: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> Hi all, I am trying to property implement icalendar recurrence and there are some things that are not clear to me. I was told by a colleague that the way to make changes to an individual instance in a chain of recurring events is to create within the same calendar an additional VEVENT with the same UID as the 'master' event and a RECURRENCE-ID whose value is the normal start date of that instance and then any properties that you would like to override for that particular instance. So here are my questions: 1) The above seems relatively clear to me, but I can't find it explicitly explained in rfc2445. Is there another spec which covers this? 2) Is DTSTART a required property for recurrence instances? I would not think so, except that iCal automatically inserts a DTSTART into recurrence instances even when the only thing I changes was the SUMMARY. Just to see what would happen, I exported that calendar, got rid of the offending DTSTART and reimported. To my consternation, it reinserted the DTSTART with a seemingly random value - until I realized that it was the timestamp of when I imported the file. 3) Is there any other required properties in an overriding VEVENT instance? 4) Any (preferably Mac OS X and free/cheap) clients which handle this properly that I should be looking to as a reference implementation (at least for recurrence) ? Thanks all, bobby rullo From pregen at egenconsulting.com Thu Sep 28 17:34:20 2006 From: pregen at egenconsulting.com (Pat R Egen) Date: Thu Sep 28 17:34:28 2006 Subject: [Ietf-calsify] Modifications to instances in a recurrence chain In-Reply-To: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> Message-ID: RFC2446 covers the VEVENT stuff. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bobby Rullo Sent by: ietf-calsify-bounces@osafoundation.org 09/28/2006 08:28 PM To ietf-calsify@osafoundation.org cc Subject [Ietf-calsify] Modifications to instances in a recurrence chain Hi all, I am trying to property implement icalendar recurrence and there are some things that are not clear to me. I was told by a colleague that the way to make changes to an individual instance in a chain of recurring events is to create within the same calendar an additional VEVENT with the same UID as the 'master' event and a RECURRENCE-ID whose value is the normal start date of that instance and then any properties that you would like to override for that particular instance. So here are my questions: 1) The above seems relatively clear to me, but I can't find it explicitly explained in rfc2445. Is there another spec which covers this? 2) Is DTSTART a required property for recurrence instances? I would not think so, except that iCal automatically inserts a DTSTART into recurrence instances even when the only thing I changes was the SUMMARY. Just to see what would happen, I exported that calendar, got rid of the offending DTSTART and reimported. To my consternation, it reinserted the DTSTART with a seemingly random value - until I realized that it was the timestamp of when I imported the file. 3) Is there any other required properties in an overriding VEVENT instance? 4) Any (preferably Mac OS X and free/cheap) clients which handle this properly that I should be looking to as a reference implementation (at least for recurrence) ? Thanks all, bobby rullo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060928/448b9be3/attachment.htm From cyrus at daboo.name Thu Sep 28 17:35:06 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Sep 28 17:35:18 2006 Subject: [Ietf-calsify] Modifications to instances in a recurrence chain In-Reply-To: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> References: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> Message-ID: Hi Bobby, --On September 28, 2006 5:28:04 PM -0700 Bobby Rullo wrote: > I am trying to property implement icalendar recurrence and there are some > things that are not clear to me. > > I was told by a colleague that the way to make changes to an individual > instance in a chain of recurring events is to create within the same > calendar an additional VEVENT with the same UID as the 'master' event and > a RECURRENCE-ID whose value is the normal start date of that instance and > then any properties that you would like to override for that particular > instance. > > So here are my questions: > > 1) The above seems relatively clear to me, but I can't find it > explicitly explained in rfc2445. Is there another spec which covers this? > > 2) Is DTSTART a required property for recurrence instances? I would not > think so, except that iCal automatically inserts a DTSTART into > recurrence instances even when the only thing I changes was the SUMMARY. > Just to see what would happen, I exported that calendar, got rid of the > offending DTSTART and reimported. To my consternation, it reinserted the > DTSTART with a seemingly random value - until I realized that it was the > timestamp of when I imported the file. > > 3) Is there any other required properties in an overriding VEVENT > instance? > > 4) Any (preferably Mac OS X and free/cheap) clients which handle this > properly that I should be looking to as a reference implementation (at > least for recurrence) ? The overridden component must be a full component in its own right - i.e. it must satisfy all the requirements of vevents - dtstart/dtend or duration etc. At one point in time I also thought that overridden instances only needed to include those properties that were different from the original - but the problem with that is that you cannot tell if a property was removed. e.g. I have five attendees in the 'master' instance and I want to remove one from the overridden instance. In that case a 'diff' cannot work because you cannot indicate that one was removed. So the rule is the overridden component has to be complete - not a diff from the master. -- Cyrus Daboo From lear at cisco.com Fri Sep 29 07:09:21 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 29 07:09:29 2006 Subject: [Ietf-calsify] Issue 32: Charset parameter Message-ID: <451D2911.1010905@cisco.com> I believe this may already be addressed, but I believe we agreed, MUST accept US-ASCII, UTF-8, SHOULD generate UTF-8. Correct? Eliot From lear at cisco.com Fri Sep 29 07:25:21 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 29 07:25:29 2006 Subject: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE Message-ID: <451D2CD1.2070700@cisco.com> We have consensus that one MUST not generate and MUST ignore VEVENTs (really any elements) containing something this broken. We lack specific wording. Here is my proposal: Section 3.3.10 OLD TEXT: The BYSECOND rule part specifies a COMMA character (US-ASCII decimal 44) separated list of seconds within a minute. Valid values are 0 to 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII decimal 44) separated list of minutes within an hour. Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- ASCII decimal 44) separated list of hours of the day. Valid values are 0 to 23. NEW TEXT: The BYSECOND rule part specifies a COMMA character (US-ASCII decimal 44) separated list of seconds within a minute. Valid values are 0 to 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII decimal 44) separated list of minutes within an hour. Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- ASCII decimal 44) separated list of hours of the day. Valid values are 0 to 23. Implementations MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated DTSTART uses VALUE=DATE. Similarly, Implementations MUST ignore such constructs when see, optionally logging an error. Eliot From lear at cisco.com Fri Sep 29 07:28:36 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Sep 29 07:28:42 2006 Subject: [Ietf-calsify] Help! Volutneers needed! Issue 25: Is the first recurrence instance, defined by DTSTART, always excluded by RRULE? Message-ID: <451D2D94.4080208@cisco.com> All, This issue has had no discussion on the mailing list since Montreal. We need some proposed text to try and drive consensus. Are there any volunteers? Eliot From cyrus at daboo.name Fri Sep 29 07:42:50 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Fri Sep 29 07:43:20 2006 Subject: [Ietf-calsify] Issue 32: Charset parameter In-Reply-To: <451D2911.1010905@cisco.com> References: <451D2911.1010905@cisco.com> Message-ID: <9E49E441C295322B8DAB05D2@ap0101q-dhcp186.apple.com> Hi Eliot, --On September 29, 2006 4:09:21 PM +0200 Eliot Lear wrote: > I believe this may already be addressed, but I believe we agreed, MUST > accept US-ASCII, UTF-8, SHOULD generate UTF-8. Correct? I think so. -- Cyrus Daboo From bernard.desruisseaux at oracle.com Fri Sep 29 10:26:17 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Fri Sep 29 10:26:50 2006 Subject: [Ietf-calsify] Issue 32: Charset parameter In-Reply-To: <9E49E441C295322B8DAB05D2@ap0101q-dhcp186.apple.com> References: <451D2911.1010905@cisco.com> <9E49E441C295322B8DAB05D2@ap0101q-dhcp186.apple.com> Message-ID: <451D5739.8070206@oracle.com> Here's some proposed text for this issue. Section 3.2 Parameters OLD TEXT: > The "charset" parameter is defined in [RFC 2046] for other body > parts. It is used to identify the default character set used within > the body part. NEW TEXT: > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. The "charset" values supported by this > revision of iCalendar are UTF-8 and US-ASCII. Applications are > REQUIRED to accept iCalendar streams using the UTF-8 or US-ASCII > charsets, and SHOULD generate iCalendar streams with the UTF-8 > charset. Section 4.1.4 Character Set OLD TEXT: > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > object is UTF-8 as defined in [RFC 2279]. > > The "charset" Content-Type parameter can be used in MIME transports > to specify any other IANA registered character set. NEW TEXT: > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > stream is UTF-8 as defined in [RFC 3629]. > > The "charset" Content-Type parameter can be used in MIME transports > to specify the character set being used. Section 4.3.11 Text OLD TEXT: > Formal Definition: The character sets supported by this revision of > iCalendar are UTF-8 and US ASCII thereof. The applicability to other > character sets is for future work. The value type is defined by the > following notation. NEW TEXT: > Formal Definition: The value type is defined by the following notation: Cheers, Bernard Cyrus Daboo wrote: > Hi Eliot, > > --On September 29, 2006 4:09:21 PM +0200 Eliot Lear wrote: > >> I believe this may already be addressed, but I believe we agreed, MUST >> accept US-ASCII, UTF-8, SHOULD generate UTF-8. Correct? > > I think so. > From bernard.desruisseaux at oracle.com Fri Sep 29 10:37:11 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Fri Sep 29 10:39:09 2006 Subject: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE In-Reply-To: <451D2CD1.2070700@cisco.com> References: <451D2CD1.2070700@cisco.com> Message-ID: <451D59C7.6090505@oracle.com> I would rephrase the NEW TEXT as follows : The BYSECOND rule part specifies a COMMA character (US-ASCII decimal 44) separated list of seconds within a minute. Valid values are 0 to 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII decimal 44) separated list of minutes within an hour. Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA character (US-ASCII decimal 44) separated list of hours of the day. Valid values are 0 to 23. The BYSECOND, BYMINUTE and BYHOUR rule parts MUST NOT be specified when the associated DTSTART property has a DATE value type. These rule parts MUST be ignored in RECUR value that violate the above requirement (e.g., generated by applications that pre-date this revision of iCalendar). Cheers, Bernard Eliot Lear wrote: > We have consensus that one MUST not generate and MUST ignore VEVENTs > (really any elements) containing something this broken. We lack > specific wording. Here is my proposal: > > Section 3.3.10 > > OLD TEXT: > > The BYSECOND rule part specifies a COMMA character (US-ASCII > decimal 44) separated list of seconds within a minute. Valid > values are 0 to 59. The BYMINUTE rule part specifies a COMMA > character (US-ASCII decimal 44) separated list of minutes within > an hour. Valid values are 0 to 59. The BYHOUR rule part > specifies a COMMA character (US- ASCII decimal 44) separated list > of hours of the day. Valid values are 0 to 23. > > > NEW TEXT: > > The BYSECOND rule part specifies a COMMA character (US-ASCII > decimal 44) separated list of seconds within a minute. Valid > values are 0 to 59. The BYMINUTE rule part specifies a COMMA > character (US-ASCII decimal 44) separated list of minutes within > an hour. Valid values are 0 to 59. The BYHOUR rule part > specifies a COMMA character (US- ASCII decimal 44) separated list > of hours of the day. Valid values are 0 to 23. Implementations > MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated > DTSTART uses VALUE=DATE. Similarly, Implementations MUST ignore > such constructs when see, optionally logging an error. > > Eliot > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From bernard.desruisseaux at oracle.com Fri Sep 29 10:56:18 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Fri Sep 29 10:57:30 2006 Subject: [Ietf-calsify] Issue 32: Charset parameter In-Reply-To: <451D5739.8070206@oracle.com> References: <451D2911.1010905@cisco.com> <9E49E441C295322B8DAB05D2@ap0101q-dhcp186.apple.com> <451D5739.8070206@oracle.com> Message-ID: <451D5E42.8000300@oracle.com> Please ignore my previous message. We already have proposed text which has been reviewed by Mark and Alexey. Cheers, Bernard Bernard Desruisseaux wrote: > Here's some proposed text for this issue. > > Section 3.2 Parameters > > OLD TEXT: > > > The "charset" parameter is defined in [RFC 2046] for other body > > parts. It is used to identify the default character set used within > > the body part. > > NEW TEXT: > > > The "charset" parameter is defined in [RFC 2046] for subtypes of > > the "text" media type. It is used to indicate the character set > > used in the body part. The "charset" values supported by this > > revision of iCalendar are UTF-8 and US-ASCII. Applications are > > REQUIRED to accept iCalendar streams using the UTF-8 or US-ASCII > > charsets, and SHOULD generate iCalendar streams with the UTF-8 > > charset. > > Section 4.1.4 Character Set > > OLD TEXT: > > > There is not a property parameter to declare the character set used > > in a property value. The default character set for an iCalendar > > object is UTF-8 as defined in [RFC 2279]. > > > > The "charset" Content-Type parameter can be used in MIME transports > > to specify any other IANA registered character set. > > NEW TEXT: > > > There is not a property parameter to declare the character set used > > in a property value. The default character set for an iCalendar > > stream is UTF-8 as defined in [RFC 3629]. > > > > The "charset" Content-Type parameter can be used in MIME transports > > to specify the character set being used. > > Section 4.3.11 Text > > OLD TEXT: > > > Formal Definition: The character sets supported by this revision of > > iCalendar are UTF-8 and US ASCII thereof. The applicability to other > > character sets is for future work. The value type is defined by the > > following notation. > > NEW TEXT: > > > Formal Definition: The value type is defined by the following notation: > > Cheers, > Bernard > > > Cyrus Daboo wrote: >> Hi Eliot, >> >> --On September 29, 2006 4:09:21 PM +0200 Eliot Lear >> wrote: >> >>> I believe this may already be addressed, but I believe we agreed, MUST >>> accept US-ASCII, UTF-8, SHOULD generate UTF-8. Correct? >> >> I think so. >> > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From jeffrey at osafoundation.org Fri Sep 29 12:17:31 2006 From: jeffrey at osafoundation.org (Jeffrey Harris) Date: Fri Sep 29 12:17:34 2006 Subject: [Ietf-calsify] Modifications to instances in a recurrence chain In-Reply-To: References: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> Message-ID: <451D714B.9070309@osafoundation.org> Hi Folks, Thanks, Bobby, for leaping in with your questions. You've reminded me that I've been delinquent in discussing confusion I've experience (or seen other people experience) about recurrence in iCalendar. For all of these issues I've experienced ambiguity, so I think we should really try to clarify them: A) I'd like to see a clearer link in rfc2445 (or 2445bis) to rfc2446, explaining that there's more complexity to serializing recurring events with modifications, would be helpful. I've noticed that a variety of smart people have missed that they need to read 2446 to understand modifications to recurring events. B) In both rfc2445 and rfc2445bis-01, the VEVENT component's definition says that all properties are optional, but both UID and DTSTART's explanations say they are in fact required in VEVENTs. C) What is the RECURRENCE-ID for an occurrence if an earlier modification that applies to THISANDFUTURE has changed the start time? My memory is that Cyrus and I had different ideas of how this should work. In practice, both Apple iCal and Chandler create an entirely new event (with a new UID) if the user makes a THISANDFUTURE change to anything but the first occurrence, so I haven't experienced issues with this, but that's only because we don't do iTIP. :) D) Similarly to C), if there is one or more THIS modifications to a particular RECURRENCE-ID, one of which changes the DTSTART, is the RECURRENCE-ID changed? For this I'd say no, the DTSTART and RECURRENCE-ID don't match, but the RECURRENCE-ID stays the same. E) Finally, the more meaty topic, do modification VEVENTs (a VEVENT with a particular UID/RECURRENCE-ID pair) represent diffs to the pre-existing rule, or an entire self-contained description of the most up-to-date information about that particular occurrence? In past discussions with Cyrus about this, I was swayed by his argument that we need a way to delete ATTENDEEs. But every time I discuss this with people it's unsatisfying. Quick background, I think there are three main ways applications might model THISANDFUTURE changes that effect events that are already modified: 1) Don't detach individually modified occurrences, later THISANDFUTURE changes effect all occurrences, even if the property being changed was already changed 2) Completely detach changes to individual occurrences (THISANDFUTURE changes never again effect them) 3) Detach specific properties, so a change to one occurrence's SUMMARY won't prevent a change to all DTSTARTs from effecting that occurrence, but changes to all SUMMARYs *won't* effect that detached occurrence. When I've surveyed users, 1) is considered really bad almost universally (it's seems too easy to erase important information), 2) is acceptable but annoying, and 3) is ideal. Currently, Chandler and Apple iCal do 2), I'd be curious to hear about other clients. In the near future Chandler will move to doing 3). If, when serialized as iCalendar, modifications are required to express the full and complete state of the modification (not just diffs to the master), then it's impossible to semantically express the concept of a particular detached property, it's all or nothing. In practice, I think that many clients (at least iCal and Chandler) *when parsing an icalendar stream* already interpret the absence of many properties as implying that the property is inherited from it's parent. So, back to the ATTENDEE case. It seems to me that clients could interpret the absence of a property as implying that it's inherited, but if even one instance of that property is present in the modification, it's a change. I think this would solve the ATTENDEE case. The main thing I can think of that wouldn't work would be deleting a VALARM, which I would find preferable to not being able to express If we interpreted modifications as working this way, I think we'd want to allow VEVENTs to not have a DTSTART if they had a RECURRENCE-ID, and of course, either way, we should specify the behavior clearly in the relevant specs. Sincerely, Jeffrey From sroberts at uniserve.com Fri Sep 29 15:12:10 2006 From: sroberts at uniserve.com (Sam Roberts) Date: Fri Sep 29 15:12:18 2006 Subject: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE In-Reply-To: <451D2CD1.2070700@cisco.com> References: <451D2CD1.2070700@cisco.com> Message-ID: <20060929221210.GA24863@pebble> On Fri, Sep 29, 2006 at 04:25:21PM +0200, Eliot Lear wrote: > NEW TEXT: > of hours of the day. Valid values are 0 to 23. Implementations > MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated > DTSTART uses VALUE=DATE. Similarly, Implementations MUST ignore > such constructs when see, optionally logging an error. Are you sure you want to tell people that they MUST accept as valid files that were generated in violation of a MUST? Seems odd to me to be in the business of telling people what to do with invalid data, its hard enough to specify what to do with valid data. Anyhow, its not clear to me what it means to ignore the "construct". Is it the entire calendar, the VEVENT, the RRULE, the "BYMINUTE=..." that shouldn't be there? If there is concern about apps out there generating data like this, maybe say "Some implementations are known to generate these fields when DTSTART uses VALUE=DATE, implementations SHOULD treat any BYHOUR, BYMINUTE, or BYSECOND as not being present in this case." Cheers, Sam From dave at cridland.net Sat Sep 30 01:14:48 2006 From: dave at cridland.net (Dave Cridland) Date: Sat Sep 30 01:15:03 2006 Subject: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE In-Reply-To: <20060929221210.GA24863@pebble> References: <451D2CD1.2070700@cisco.com> <20060929221210.GA24863@pebble> Message-ID: <25845.1159604089.766371@peirce.dave.cridland.net> On Fri Sep 29 23:12:10 2006, Sam Roberts wrote: > Are you sure you want to tell people that they MUST accept as valid > files that were generated in violation of a MUST? Seems odd to me > to be > in the business of telling people what to do with invalid data, its > hard enough to specify what to do with valid data. Just to pick up on this, the constructions of "MUST NOT generate x, but MUST ignore x", or "MUST NOT generate x, but SHOULD accept x", are quite common practise. It's a codification of when to apply Postel's Principle - "Be conservative in what you sent, but be liberal in what you accept". It's all the more useful when a specification is being revised, and we know there's bad data (or clients, or servers) in actual deployment. Another particularly useful time is when it concerns an invalid combination of two somewhat distinct elements. In this case, at least the latter applies, and possibly the former. Let's pretend you have a CUA written which has the feature of copying a recurrence rule from one event to a new one, so for complex rules, the user can just say "Like this one", instead of re-entering a possibly complex rule. This text (or your replacement) gives your CUA a clear mandate to drop BYHOUR, BYMINUTE, and BYSECOND from the recurrence rule you're copying if it's a DATE value for DTSTART. (As for which text, as someone merely tracking this WG, I understood what the text meant, and took "such constructs" to mean "BYHOUR, BYMINUTE, or BYSECOND". I don't think that "OR" should be capitalized, though.) Dave. -- Dave Cridland - mailto: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 lear at cisco.com Sat Sep 30 03:09:00 2006 From: lear at cisco.com (Eliot Lear) Date: Sat Sep 30 03:09:09 2006 Subject: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE In-Reply-To: <20060929221210.GA24863@pebble> References: <451D2CD1.2070700@cisco.com> <20060929221210.GA24863@pebble> Message-ID: <451E423C.3090809@cisco.com> Sam Roberts wrote: > On Fri, Sep 29, 2006 at 04:25:21PM +0200, Eliot Lear wrote: > >> NEW TEXT: >> of hours of the day. Valid values are 0 to 23. Implementations >> MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated >> DTSTART uses VALUE=DATE. Similarly, Implementations MUST ignore >> such constructs when see, optionally logging an error. >> > > Are you sure you want to tell people that they MUST accept as valid > files that were generated in violation of a MUST? Seems odd to me to be > in the business of telling people what to do with invalid data, its > hard enough to specify what to do with valid data. > See Dave's not about the history of the combo. Host Requirements (RFC 1122 / RFC 1123) made use of it first, as I recall. To remind people the current text is based on the group's consensus. In this case the intentions of the sender are almost completely unfathomable as it's a bit of a non-sequitor. > Anyhow, its not clear to me what it means to ignore the "construct". Is > it the entire calendar, the VEVENT, the RRULE, the "BYMINUTE=..." that > shouldn't be there? > You're right. I believe Bernard actually has better wording to address this concern. 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 851EC7F97A for ; Sat, 30 Sep 2006 03:09:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 76F741422F1 for ; Sat, 30 Sep 2006 03:09:07 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11144-07 for ; Sat, 30 Sep 2006 03:09:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id F35511422CD for ; Sat, 30 Sep 2006 03:09:05 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Sep 2006 03:09:05 -0700 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.20060308/8.12.11) with ESMTP id k8UA95xe015149; Sat, 30 Sep 2006 03:09:05 -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 k8UA951E025053; Sat, 30 Sep 2006 03:09:05 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp125.cisco.com [10.61.64.125]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8U9wBAP012650; Sat, 30 Sep 2006 02:58:12 -0700 Message-ID: <451E423C.3090809@cisco.com> Date: Sat, 30 Sep 2006 12:09:00 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Sam Roberts Subject: Re: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE References: <451D2CD1.2070700@cisco.com> <20060929221210.GA24863@pebble> In-Reply-To: <20060929221210.GA24863@pebble> Content-Type: text/plain; charset=UTF-8 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=1260; t=1159610945; x=1160474945; c=relaxed/simple; s=sjdkim3002; 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]=20Issue=2026=3A=20=20BYHOUR, =20BYMINUTE, =09and=20 BYSECOND=20recurrence=0A=20rules=20where=20value=20type=20is=20DATE; X=v=3Dcisco.com=3B=20h=3DFcpEmNwMvAZhR2lby7jPCd0d64U=3D; b=guaK0m3CBKRbF9Vs/mjawSTgfyloT4QddyuoOuFq+7jwyaq6vkOHirKiz4EbCWmQHQaFoWGl 7VbGXWlE9gv27NFUkOwbTPScGRI8VhKd+LPRImL3Q5i4IkLHEHy+nfIK; 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: Sat, 30 Sep 2006 10:09:07 -0000 Sam Roberts wrote: > On Fri, Sep 29, 2006 at 04:25:21PM +0200, Eliot Lear wrote: > >> NEW TEXT: >> of hours of the day. Valid values are 0 to 23. Implementations >> MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated >> DTSTART uses VALUE=DATE. Similarly, Implementations MUST ignore >> such constructs when see, optionally logging an error. >> > > Are you sure you want to tell people that they MUST accept as valid > files that were generated in violation of a MUST? Seems odd to me to be > in the business of telling people what to do with invalid data, its > hard enough to specify what to do with valid data. > See Dave's not about the history of the combo. Host Requirements (RFC 1122 / RFC 1123) made use of it first, as I recall. To remind people the current text is based on the group's consensus. In this case the intentions of the sender are almost completely unfathomable as it's a bit of a non-sequitor. > Anyhow, its not clear to me what it means to ignore the "construct". Is > it the entire calendar, the VEVENT, the RRULE, the "BYMINUTE=..." that > shouldn't be there? > You're right. I believe Bernard actually has better wording to address this concern. 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 8DDFA7F9DF for ; Sat, 30 Sep 2006 01:15:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E9AE14230F for ; Sat, 30 Sep 2006 01:15: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 04182-01 for ; Sat, 30 Sep 2006 01:15:01 -0700 (PDT) Received: from pythagoras.zen.co.uk (pythagoras.zen.co.uk [212.23.3.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9F64514231B for ; Sat, 30 Sep 2006 01:15:01 -0700 (PDT) Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1GTZzw-0004qU-D1; Sat, 30 Sep 2006 08:15:00 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 68335498005; Sat, 30 Sep 2006 09:18:49 +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 30508-03; Sat, 30 Sep 2006 09:18:39 +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 A632B498004; Sat, 30 Sep 2006 09:18:39 +0100 (BST) Date: Sat, 30 Sep 2006 09:14:48 +0100 Subject: Re: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE References: <451D2CD1.2070700@cisco.com> <20060929221210.GA24863@pebble> In-Reply-To: <20060929221210.GA24863@pebble> MIME-Version: 1.0 Message-Id: <25845.1159604089.766371@peirce.dave.cridland.net> From: Dave Cridland To: Sam Roberts Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] 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@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: Sat, 30 Sep 2006 08:15:02 -0000 On Fri Sep 29 23:12:10 2006, Sam Roberts wrote: > Are you sure you want to tell people that they MUST accept as valid > files that were generated in violation of a MUST? Seems odd to me > to be > in the business of telling people what to do with invalid data, its > hard enough to specify what to do with valid data. Just to pick up on this, the constructions of "MUST NOT generate x, but MUST ignore x", or "MUST NOT generate x, but SHOULD accept x", are quite common practise. It's a codification of when to apply Postel's Principle - "Be conservative in what you sent, but be liberal in what you accept". It's all the more useful when a specification is being revised, and we know there's bad data (or clients, or servers) in actual deployment. Another particularly useful time is when it concerns an invalid combination of two somewhat distinct elements. In this case, at least the latter applies, and possibly the former. Let's pretend you have a CUA written which has the feature of copying a recurrence rule from one event to a new one, so for complex rules, the user can just say "Like this one", instead of re-entering a possibly complex rule. This text (or your replacement) gives your CUA a clear mandate to drop BYHOUR, BYMINUTE, and BYSECOND from the recurrence rule you're copying if it's a DATE value for DTSTART. (As for which text, as someone merely tracking this WG, I understood what the text meant, and took "such constructs" to mean "BYHOUR, BYMINUTE, or BYSECOND". I don't think that "OR" should be capitalized, though.) Dave. -- Dave Cridland - mailto: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 9E9157F9AA for ; Fri, 29 Sep 2006 15:12:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8F61D1422E1 for ; Fri, 29 Sep 2006 15:12: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 08381-08 for ; Fri, 29 Sep 2006 15:12:15 -0700 (PDT) Received: from bycast.com (bycast.com [207.61.255.252]) by laweleka.osafoundation.org (Postfix) with ESMTP id AC96D1422C3 for ; Fri, 29 Sep 2006 15:12:14 -0700 (PDT) Received: from [192.168.110.126] (HELO localhost.localdomain) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTP id 1126713 for ietf-calsify@osafoundation.org; Fri, 29 Sep 2006 15:12:06 -0700 Received: by localhost.localdomain (Postfix, from userid 2122) id 057F5510520; Fri, 29 Sep 2006 15:12:10 -0700 (PDT) Date: Fri, 29 Sep 2006 15:12:10 -0700 From: Sam Roberts To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE Message-ID: <20060929221210.GA24863@pebble> References: <451D2CD1.2070700@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451D2CD1.2070700@cisco.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST X-Spam-Level: X-BeenThere: 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, 29 Sep 2006 22:12:17 -0000 On Fri, Sep 29, 2006 at 04:25:21PM +0200, Eliot Lear wrote: > NEW TEXT: > of hours of the day. Valid values are 0 to 23. Implementations > MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated > DTSTART uses VALUE=DATE. Similarly, Implementations MUST ignore > such constructs when see, optionally logging an error. Are you sure you want to tell people that they MUST accept as valid files that were generated in violation of a MUST? Seems odd to me to be in the business of telling people what to do with invalid data, its hard enough to specify what to do with valid data. Anyhow, its not clear to me what it means to ignore the "construct". Is it the entire calendar, the VEVENT, the RRULE, the "BYMINUTE=..." that shouldn't be there? If there is concern about apps out there generating data like this, maybe say "Some implementations are known to generate these fields when DTSTART uses VALUE=DATE, implementations SHOULD treat any BYHOUR, BYMINUTE, or BYSECOND as not being present in this case." Cheers, Sam 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 47D867F786 for ; Fri, 29 Sep 2006 12:17:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 32BCF142315 for ; Fri, 29 Sep 2006 12:17: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 16687-08 for ; Fri, 29 Sep 2006 12:17:32 -0700 (PDT) Received: from [192.168.1.50] (c-24-5-198-210.hsd1.ca.comcast.net [24.5.198.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8EF4A142313 for ; Fri, 29 Sep 2006 12:17:32 -0700 (PDT) Message-ID: <451D714B.9070309@osafoundation.org> Date: Fri, 29 Sep 2006 12:17:31 -0700 From: Jeffrey Harris User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Modifications to instances in a recurrence chain References: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.0 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL 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, 29 Sep 2006 19:17:33 -0000 Hi Folks, Thanks, Bobby, for leaping in with your questions. You've reminded me that I've been delinquent in discussing confusion I've experience (or seen other people experience) about recurrence in iCalendar. For all of these issues I've experienced ambiguity, so I think we should really try to clarify them: A) I'd like to see a clearer link in rfc2445 (or 2445bis) to rfc2446, explaining that there's more complexity to serializing recurring events with modifications, would be helpful. I've noticed that a variety of smart people have missed that they need to read 2446 to understand modifications to recurring events. B) In both rfc2445 and rfc2445bis-01, the VEVENT component's definition says that all properties are optional, but both UID and DTSTART's explanations say they are in fact required in VEVENTs. C) What is the RECURRENCE-ID for an occurrence if an earlier modification that applies to THISANDFUTURE has changed the start time? My memory is that Cyrus and I had different ideas of how this should work. In practice, both Apple iCal and Chandler create an entirely new event (with a new UID) if the user makes a THISANDFUTURE change to anything but the first occurrence, so I haven't experienced issues with this, but that's only because we don't do iTIP. :) D) Similarly to C), if there is one or more THIS modifications to a particular RECURRENCE-ID, one of which changes the DTSTART, is the RECURRENCE-ID changed? For this I'd say no, the DTSTART and RECURRENCE-ID don't match, but the RECURRENCE-ID stays the same. E) Finally, the more meaty topic, do modification VEVENTs (a VEVENT with a particular UID/RECURRENCE-ID pair) represent diffs to the pre-existing rule, or an entire self-contained description of the most up-to-date information about that particular occurrence? In past discussions with Cyrus about this, I was swayed by his argument that we need a way to delete ATTENDEEs. But every time I discuss this with people it's unsatisfying. Quick background, I think there are three main ways applications might model THISANDFUTURE changes that effect events that are already modified: 1) Don't detach individually modified occurrences, later THISANDFUTURE changes effect all occurrences, even if the property being changed was already changed 2) Completely detach changes to individual occurrences (THISANDFUTURE changes never again effect them) 3) Detach specific properties, so a change to one occurrence's SUMMARY won't prevent a change to all DTSTARTs from effecting that occurrence, but changes to all SUMMARYs *won't* effect that detached occurrence. When I've surveyed users, 1) is considered really bad almost universally (it's seems too easy to erase important information), 2) is acceptable but annoying, and 3) is ideal. Currently, Chandler and Apple iCal do 2), I'd be curious to hear about other clients. In the near future Chandler will move to doing 3). If, when serialized as iCalendar, modifications are required to express the full and complete state of the modification (not just diffs to the master), then it's impossible to semantically express the concept of a particular detached property, it's all or nothing. In practice, I think that many clients (at least iCal and Chandler) *when parsing an icalendar stream* already interpret the absence of many properties as implying that the property is inherited from it's parent. So, back to the ATTENDEE case. It seems to me that clients could interpret the absence of a property as implying that it's inherited, but if even one instance of that property is present in the modification, it's a change. I think this would solve the ATTENDEE case. The main thing I can think of that wouldn't work would be deleting a VALARM, which I would find preferable to not being able to express If we interpreted modifications as working this way, I think we'd want to allow VEVENTs to not have a DTSTART if they had a RECURRENCE-ID, and of course, either way, we should specify the behavior clearly in the relevant specs. Sincerely, Jeffrey 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 27E507FC34 for ; Fri, 29 Sep 2006 10:57:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 18FFF142315 for ; Fri, 29 Sep 2006 10:57:30 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13127-01 for ; Fri, 29 Sep 2006 10:57:29 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6DD85142304 for ; Fri, 29 Sep 2006 10:57:29 -0700 (PDT) Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k8RAEGRo028766 for ; Fri, 29 Sep 2006 12:57:28 -0500 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2046913581159552584; Fri, 29 Sep 2006 11:56:24 -0600 Message-ID: <451D5E42.8000300@oracle.com> Date: Fri, 29 Sep 2006 13:56:18 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 32: Charset parameter References: <451D2911.1010905@cisco.com> <9E49E441C295322B8DAB05D2@ap0101q-dhcp186.apple.com> <451D5739.8070206@oracle.com> In-Reply-To: <451D5739.8070206@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: 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, 29 Sep 2006 17:57:30 -0000 Please ignore my previous message. We already have proposed text which has been reviewed by Mark and Alexey. Cheers, Bernard Bernard Desruisseaux wrote: > Here's some proposed text for this issue. > > Section 3.2 Parameters > > OLD TEXT: > > > The "charset" parameter is defined in [RFC 2046] for other body > > parts. It is used to identify the default character set used within > > the body part. > > NEW TEXT: > > > The "charset" parameter is defined in [RFC 2046] for subtypes of > > the "text" media type. It is used to indicate the character set > > used in the body part. The "charset" values supported by this > > revision of iCalendar are UTF-8 and US-ASCII. Applications are > > REQUIRED to accept iCalendar streams using the UTF-8 or US-ASCII > > charsets, and SHOULD generate iCalendar streams with the UTF-8 > > charset. > > Section 4.1.4 Character Set > > OLD TEXT: > > > There is not a property parameter to declare the character set used > > in a property value. The default character set for an iCalendar > > object is UTF-8 as defined in [RFC 2279]. > > > > The "charset" Content-Type parameter can be used in MIME transports > > to specify any other IANA registered character set. > > NEW TEXT: > > > There is not a property parameter to declare the character set used > > in a property value. The default character set for an iCalendar > > stream is UTF-8 as defined in [RFC 3629]. > > > > The "charset" Content-Type parameter can be used in MIME transports > > to specify the character set being used. > > Section 4.3.11 Text > > OLD TEXT: > > > Formal Definition: The character sets supported by this revision of > > iCalendar are UTF-8 and US ASCII thereof. The applicability to other > > character sets is for future work. The value type is defined by the > > following notation. > > NEW TEXT: > > > Formal Definition: The value type is defined by the following notation: > > Cheers, > Bernard > > > Cyrus Daboo wrote: >> Hi Eliot, >> >> --On September 29, 2006 4:09:21 PM +0200 Eliot Lear >> wrote: >> >>> I believe this may already be addressed, but I believe we agreed, MUST >>> accept US-ASCII, UTF-8, SHOULD generate UTF-8. Correct? >> >> I think so. >> > _______________________________________________ > 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 637C37FACA for ; Fri, 29 Sep 2006 10:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F7041422D8 for ; Fri, 29 Sep 2006 10:39: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 08610-03 for ; Fri, 29 Sep 2006 10:39:06 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 92BFF1422D5 for ; Fri, 29 Sep 2006 10:39:06 -0700 (PDT) Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k8SAbdY1005946; Fri, 29 Sep 2006 12:39:02 -0500 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2046509561159551437; Fri, 29 Sep 2006 11:37:17 -0600 Message-ID: <451D59C7.6090505@oracle.com> Date: Fri, 29 Sep 2006 13:37:11 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Subject: Re: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE References: <451D2CD1.2070700@cisco.com> In-Reply-To: <451D2CD1.2070700@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: 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, 29 Sep 2006 17:39:07 -0000 I would rephrase the NEW TEXT as follows : The BYSECOND rule part specifies a COMMA character (US-ASCII decimal 44) separated list of seconds within a minute. Valid values are 0 to 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII decimal 44) separated list of minutes within an hour. Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA character (US-ASCII decimal 44) separated list of hours of the day. Valid values are 0 to 23. The BYSECOND, BYMINUTE and BYHOUR rule parts MUST NOT be specified when the associated DTSTART property has a DATE value type. These rule parts MUST be ignored in RECUR value that violate the above requirement (e.g., generated by applications that pre-date this revision of iCalendar). Cheers, Bernard Eliot Lear wrote: > We have consensus that one MUST not generate and MUST ignore VEVENTs > (really any elements) containing something this broken. We lack > specific wording. Here is my proposal: > > Section 3.3.10 > > OLD TEXT: > > The BYSECOND rule part specifies a COMMA character (US-ASCII > decimal 44) separated list of seconds within a minute. Valid > values are 0 to 59. The BYMINUTE rule part specifies a COMMA > character (US-ASCII decimal 44) separated list of minutes within > an hour. Valid values are 0 to 59. The BYHOUR rule part > specifies a COMMA character (US- ASCII decimal 44) separated list > of hours of the day. Valid values are 0 to 23. > > > NEW TEXT: > > The BYSECOND rule part specifies a COMMA character (US-ASCII > decimal 44) separated list of seconds within a minute. Valid > values are 0 to 59. The BYMINUTE rule part specifies a COMMA > character (US-ASCII decimal 44) separated list of minutes within > an hour. Valid values are 0 to 59. The BYHOUR rule part > specifies a COMMA character (US- ASCII decimal 44) separated list > of hours of the day. Valid values are 0 to 23. Implementations > MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated > DTSTART uses VALUE=DATE. Similarly, Implementations MUST ignore > such constructs when see, optionally logging an error. > > Eliot > _______________________________________________ > 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 266FD7F72D for ; Fri, 29 Sep 2006 10:26:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 18497142315 for ; Fri, 29 Sep 2006 10:26: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 05870-04 for ; Fri, 29 Sep 2006 10:26:46 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 889B9142304 for ; Fri, 29 Sep 2006 10:26:46 -0700 (PDT) Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8RLgqhg012684 for ; Fri, 29 Sep 2006 11:26:44 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2045569331159550783; Fri, 29 Sep 2006 11:26:23 -0600 Message-ID: <451D5739.8070206@oracle.com> Date: Fri, 29 Sep 2006 13:26:17 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 32: Charset parameter References: <451D2911.1010905@cisco.com> <9E49E441C295322B8DAB05D2@ap0101q-dhcp186.apple.com> In-Reply-To: <9E49E441C295322B8DAB05D2@ap0101q-dhcp186.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: 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, 29 Sep 2006 17:26:48 -0000 Here's some proposed text for this issue. Section 3.2 Parameters OLD TEXT: > The "charset" parameter is defined in [RFC 2046] for other body > parts. It is used to identify the default character set used within > the body part. NEW TEXT: > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. The "charset" values supported by this > revision of iCalendar are UTF-8 and US-ASCII. Applications are > REQUIRED to accept iCalendar streams using the UTF-8 or US-ASCII > charsets, and SHOULD generate iCalendar streams with the UTF-8 > charset. Section 4.1.4 Character Set OLD TEXT: > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > object is UTF-8 as defined in [RFC 2279]. > > The "charset" Content-Type parameter can be used in MIME transports > to specify any other IANA registered character set. NEW TEXT: > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > stream is UTF-8 as defined in [RFC 3629]. > > The "charset" Content-Type parameter can be used in MIME transports > to specify the character set being used. Section 4.3.11 Text OLD TEXT: > Formal Definition: The character sets supported by this revision of > iCalendar are UTF-8 and US ASCII thereof. The applicability to other > character sets is for future work. The value type is defined by the > following notation. NEW TEXT: > Formal Definition: The value type is defined by the following notation: Cheers, Bernard Cyrus Daboo wrote: > Hi Eliot, > > --On September 29, 2006 4:09:21 PM +0200 Eliot Lear wrote: > >> I believe this may already be addressed, but I believe we agreed, MUST >> accept US-ASCII, UTF-8, SHOULD generate UTF-8. Correct? > > I think so. > 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 9EFDE8082A for ; Fri, 29 Sep 2006 07:43:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 907AF142332 for ; Fri, 29 Sep 2006 07:43:19 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17239-05 for ; Fri, 29 Sep 2006 07:43:17 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C158142333 for ; Fri, 29 Sep 2006 07:43:17 -0700 (PDT) Received: from ap0101q-dhcp186.apple.com ([12.36.112.3]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k8TEhC7u025288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Sep 2006 10:43:14 -0400 Date: Fri, 29 Sep 2006 07:42:50 -0700 From: Cyrus Daboo To: Eliot Lear , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 32: Charset parameter Message-ID: <9E49E441C295322B8DAB05D2@ap0101q-dhcp186.apple.com> In-Reply-To: <451D2911.1010905@cisco.com> References: <451D2911.1010905@cisco.com> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED X-Spam-Level: X-BeenThere: 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, 29 Sep 2006 14:43:19 -0000 Hi Eliot, --On September 29, 2006 4:09:21 PM +0200 Eliot Lear wrote: > I believe this may already be addressed, but I believe we agreed, MUST > accept US-ASCII, UTF-8, SHOULD generate UTF-8. Correct? I think so. -- Cyrus Daboo 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 8FAC6807EB for ; Fri, 29 Sep 2006 07:28:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 81A3314232D for ; Fri, 29 Sep 2006 07:28: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 24972-08 for ; Fri, 29 Sep 2006 07:28:41 -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 3286214231F for ; Fri, 29 Sep 2006 07:28:41 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2006 07:28:41 -0700 X-IronPort-AV: i="4.09,238,1157353200"; d="scan'208"; a="326603885:sNHT52983964" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TESfOU021027 for ; Fri, 29 Sep 2006 07:28:41 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8TESeid007929 for ; Fri, 29 Sep 2006 07:28:40 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp499.cisco.com [10.61.65.243]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8TEHoYk019230 for ; Fri, 29 Sep 2006 07:17:50 -0700 Message-ID: <451D2D94.4080208@cisco.com> Date: Fri, 29 Sep 2006 16:28:36 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-5.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=172; t=1159540121; x=1160404121; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Help!=20=20Volutneers=20needed!=20=20Issue=2025=3A=20Is=20the=20first=20 recurrence=20instance, =0A=20defined=20by=20DTSTART, =20always=20excluded=20b y=20RRULE?; X=v=3Dcisco.com=3B=20h=3DxuLY8MGRgM849a6vEd5Mc4u/oRA=3D; b=ha5PHyJ/RjcrZW5uenAQQFiDyKLqxlTPOCuUYW3Hacyo9DBRSzN8ZSCyH9uKuCmg+nCBAy/q KqbdUyFUYXHr6K5lT5LC+RWhHrtLQOLIYKumn4vOGSAkXEz3KFS0z98I; 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, MANY_EXCLAMATIONS, PLING_QUERY, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Help! Volutneers needed! Issue 25: Is the first recurrence instance, defined by DTSTART, always excluded by RRULE? 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, 29 Sep 2006 14:28:41 -0000 All, This issue has had no discussion on the mailing list since Montreal. We need some proposed text to try and drive consensus. Are there any volunteers? Eliot 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 8D5AD7F723 for ; Fri, 29 Sep 2006 07:25:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E2751422CA for ; Fri, 29 Sep 2006 07:25:27 -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 04651-09 for ; Fri, 29 Sep 2006 07:25:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1CCD41422B3 for ; Fri, 29 Sep 2006 07:25:27 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 07:25:26 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TEPQl4005333 for ; Fri, 29 Sep 2006 07:25:26 -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 k8TEPQ1E013768 for ; Fri, 29 Sep 2006 07:25:26 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp499.cisco.com [10.61.65.243]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8TEEZCT019157 for ; Fri, 29 Sep 2006 07:14:36 -0700 Message-ID: <451D2CD1.2070700@cisco.com> Date: Fri, 29 Sep 2006 16:25:21 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1353; t=1159539926; x=1160403926; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Issue=2026=3A=20=20BYHOUR, =20BYMINUTE, =20and=20BYSECOND=20recurrence=20r ules=20where=0A=20value=20type=20is=20DATE; X=v=3Dcisco.com=3B=20h=3DHylircog5pO2EJhDvHt0iXFYQ3E=3D; b=aELgvsB0Mt7CxnOQ++Py2SfAyshqfExaGau6fuznVuXYCVzqeqW+1A1MyPLqyxPzG5RBhp3K l3xlh8GaTGh/Mz4OCndNh5sCeilbTIR8rtBsVABJZ4L2x4hGdIens+Hy; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 26: BYHOUR, BYMINUTE, and BYSECOND recurrence rules where value type is DATE 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, 29 Sep 2006 14:25:27 -0000 We have consensus that one MUST not generate and MUST ignore VEVENTs (really any elements) containing something this broken. We lack specific wording. Here is my proposal: Section 3.3.10 OLD TEXT: The BYSECOND rule part specifies a COMMA character (US-ASCII decimal 44) separated list of seconds within a minute. Valid values are 0 to 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII decimal 44) separated list of minutes within an hour. Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- ASCII decimal 44) separated list of hours of the day. Valid values are 0 to 23. NEW TEXT: The BYSECOND rule part specifies a COMMA character (US-ASCII decimal 44) separated list of seconds within a minute. Valid values are 0 to 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII decimal 44) separated list of minutes within an hour. Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- ASCII decimal 44) separated list of hours of the day. Valid values are 0 to 23. Implementations MUST NOT generate BYHOUR, BYMINUTE, OR BYSECOND when the associated DTSTART uses VALUE=DATE. Similarly, Implementations MUST ignore such constructs when see, optionally logging an error. Eliot 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 1602E807F3 for ; Fri, 29 Sep 2006 07:09:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 06AB714232F for ; Fri, 29 Sep 2006 07:09:28 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11904-01 for ; Fri, 29 Sep 2006 07:09:26 -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 B80D1142332 for ; Fri, 29 Sep 2006 07:09:26 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2006 07:09:26 -0700 X-IronPort-AV: i="4.09,237,1157353200"; d="scan'208"; a="326595655:sNHT43426084" 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.20060308/8.12.11) with ESMTP id k8TE9Q6O032750 for ; Fri, 29 Sep 2006 07:09:26 -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 k8TE9PYp011618 for ; Fri, 29 Sep 2006 07:09:25 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp499.cisco.com [10.61.65.243]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8TDwZ8M018808 for ; Fri, 29 Sep 2006 06:58:36 -0700 Message-ID: <451D2911.1010905@cisco.com> Date: Fri, 29 Sep 2006 16:09:21 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8 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=139; t=1159538966; x=1160402966; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Issue=2032=3A=20Charset=20parameter; X=v=3Dcisco.com=3B=20h=3DzK+vdRvCqvEGRLglOHul9hbUOiU=3D; b=r/Zk4PZqynCWDrJTBpDMEqTKUa6UtniVzo2CvXtVeaHXcRDrNN4URUcZmfacTOW6VcQDjpxb 5U3yuQfWZXFpsxyDhII10v1NNM48NXgP8934doCb0XyKBSenFZQB5szi; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 32: Charset parameter 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, 29 Sep 2006 14:09:28 -0000 I believe this may already be addressed, but I believe we agreed, MUST accept US-ASCII, UTF-8, SHOULD generate UTF-8. Correct? 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 9061E80396; Thu, 28 Sep 2006 17:35:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 76585142325; Thu, 28 Sep 2006 17:35:17 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27399-05; Thu, 28 Sep 2006 17:35:16 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E5F3142327; Thu, 28 Sep 2006 17:35:16 -0700 (PDT) Received: from ap0101q-dhcp186.apple.com (A17-255-104-186.apple.com [17.255.104.186]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k8T0ZClr023331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Sep 2006 20:35:14 -0400 Date: Thu, 28 Sep 2006 17:35:06 -0700 From: Cyrus Daboo To: Bobby Rullo , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Modifications to instances in a recurrence chain Message-ID: In-Reply-To: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> References: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> X-Mailer: Mulberry/4.0.6 (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=-2.5 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, 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: Fri, 29 Sep 2006 00:35:17 -0000 Hi Bobby, --On September 28, 2006 5:28:04 PM -0700 Bobby Rullo wrote: > I am trying to property implement icalendar recurrence and there are some > things that are not clear to me. > > I was told by a colleague that the way to make changes to an individual > instance in a chain of recurring events is to create within the same > calendar an additional VEVENT with the same UID as the 'master' event and > a RECURRENCE-ID whose value is the normal start date of that instance and > then any properties that you would like to override for that particular > instance. > > So here are my questions: > > 1) The above seems relatively clear to me, but I can't find it > explicitly explained in rfc2445. Is there another spec which covers this? > > 2) Is DTSTART a required property for recurrence instances? I would not > think so, except that iCal automatically inserts a DTSTART into > recurrence instances even when the only thing I changes was the SUMMARY. > Just to see what would happen, I exported that calendar, got rid of the > offending DTSTART and reimported. To my consternation, it reinserted the > DTSTART with a seemingly random value - until I realized that it was the > timestamp of when I imported the file. > > 3) Is there any other required properties in an overriding VEVENT > instance? > > 4) Any (preferably Mac OS X and free/cheap) clients which handle this > properly that I should be looking to as a reference implementation (at > least for recurrence) ? The overridden component must be a full component in its own right - i.e. it must satisfy all the requirements of vevents - dtstart/dtend or duration etc. At one point in time I also thought that overridden instances only needed to include those properties that were different from the original - but the problem with that is that you cannot tell if a property was removed. e.g. I have five attendees in the 'master' instance and I want to remove one from the overridden instance. In that case a 'diff' cannot work because you cannot indicate that one was removed. So the rule is the overridden component has to be complete - not a diff from the master. -- Cyrus Daboo 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 EBE9480369; Thu, 28 Sep 2006 17:34:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DD537142323; Thu, 28 Sep 2006 17:34: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 18254-07; Thu, 28 Sep 2006 17:34:24 -0700 (PDT) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by laweleka.osafoundation.org (Postfix) with ESMTP id 544EB142322; Thu, 28 Sep 2006 17:34:23 -0700 (PDT) In-Reply-To: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> To: Bobby Rullo Subject: Re: [Ietf-calsify] Modifications to instances in a recurrence chain MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Pat R Egen Date: Thu, 28 Sep 2006 20:34:20 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 7.0.1|January 17, 2006) at 09/28/2006 08:34:23 PM, Serialize complete at 09/28/2006 08:34:23 PM Content-Type: multipart/alternative; boundary="=_alternative 00032841852571F8_=" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, HTML_40_50, HTML_MESSAGE X-Spam-Level: Cc: ietf-calsify@osafoundation.org, ietf-calsify-bounces@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, 29 Sep 2006 00:34:26 -0000 This is a multipart message in MIME format. --=_alternative 00032841852571F8_= Content-Type: text/plain; charset="US-ASCII" RFC2446 covers the VEVENT stuff. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bobby Rullo Sent by: ietf-calsify-bounces@osafoundation.org 09/28/2006 08:28 PM To ietf-calsify@osafoundation.org cc Subject [Ietf-calsify] Modifications to instances in a recurrence chain Hi all, I am trying to property implement icalendar recurrence and there are some things that are not clear to me. I was told by a colleague that the way to make changes to an individual instance in a chain of recurring events is to create within the same calendar an additional VEVENT with the same UID as the 'master' event and a RECURRENCE-ID whose value is the normal start date of that instance and then any properties that you would like to override for that particular instance. So here are my questions: 1) The above seems relatively clear to me, but I can't find it explicitly explained in rfc2445. Is there another spec which covers this? 2) Is DTSTART a required property for recurrence instances? I would not think so, except that iCal automatically inserts a DTSTART into recurrence instances even when the only thing I changes was the SUMMARY. Just to see what would happen, I exported that calendar, got rid of the offending DTSTART and reimported. To my consternation, it reinserted the DTSTART with a seemingly random value - until I realized that it was the timestamp of when I imported the file. 3) Is there any other required properties in an overriding VEVENT instance? 4) Any (preferably Mac OS X and free/cheap) clients which handle this properly that I should be looking to as a reference implementation (at least for recurrence) ? Thanks all, bobby rullo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --=_alternative 00032841852571F8_= Content-Type: text/html; charset="US-ASCII"
RFC2446 covers the VEVENT stuff.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Bobby Rullo <br@osafoundation.org>
Sent by: ietf-calsify-bounces@osafoundation.org

09/28/2006 08:28 PM

To
ietf-calsify@osafoundation.org
cc
Subject
[Ietf-calsify] Modifications to instances in a recurrence chain





Hi all,

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

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

So here are my questions:

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

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

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

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

Thanks all,

bobby rullo

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
--=_alternative 00032841852571F8_=-- 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 1305780375; Thu, 28 Sep 2006 17:24:04 -0700 (PDT) Received: from [192.168.103.137] (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 E54AA142323; Thu, 28 Sep 2006 17:24:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16023CB7-F74F-4DD2-B865-29DB50A624E3@osafoundation.org> Content-Transfer-Encoding: 7bit From: Bobby Rullo Date: Thu, 28 Sep 2006 17:28:04 -0700 To: ietf-calsify@osafoundation.org X-Mailer: Apple Mail (2.752.2) Subject: [Ietf-calsify] Modifications to instances in a recurrence chain 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, 29 Sep 2006 00:24:04 -0000 Hi all, I am trying to property implement icalendar recurrence and there are some things that are not clear to me. I was told by a colleague that the way to make changes to an individual instance in a chain of recurring events is to create within the same calendar an additional VEVENT with the same UID as the 'master' event and a RECURRENCE-ID whose value is the normal start date of that instance and then any properties that you would like to override for that particular instance. So here are my questions: 1) The above seems relatively clear to me, but I can't find it explicitly explained in rfc2445. Is there another spec which covers this? 2) Is DTSTART a required property for recurrence instances? I would not think so, except that iCal automatically inserts a DTSTART into recurrence instances even when the only thing I changes was the SUMMARY. Just to see what would happen, I exported that calendar, got rid of the offending DTSTART and reimported. To my consternation, it reinserted the DTSTART with a seemingly random value - until I realized that it was the timestamp of when I imported the file. 3) Is there any other required properties in an overriding VEVENT instance? 4) Any (preferably Mac OS X and free/cheap) clients which handle this properly that I should be looking to as a reference implementation (at least for recurrence) ? Thanks all, bobby rullo 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 166278010D for ; Thu, 28 Sep 2006 06:07:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0886A1422FA for ; Thu, 28 Sep 2006 06:07: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 22417-06 for ; Thu, 28 Sep 2006 06:07:50 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 379C71422EA for ; Thu, 28 Sep 2006 06:07:50 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8SD7iNw012382; Thu, 28 Sep 2006 16:07:45 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 16:07:46 +0300 Received: from [172.21.36.67] ([172.21.36.67]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Sep 2006 16:07:45 +0300 Message-ID: <451BC91F.6050907@nokia.com> Date: Thu, 28 Sep 2006 16:07:43 +0300 From: Aki Niemi Organization: Nokia-NRC/Helsinki User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: ext Eliot Lear Subject: Re: [Ietf-calsify] jabber session next week? References: <4518DCCA.5010808@cisco.com> In-Reply-To: <4518DCCA.5010808@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2006 13:07:45.0140 (UTC) FILETIME=[16A9C340:01C6E2FF] 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@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, 28 Sep 2006 13:07:52 -0000 Folks, We're getting closer to WGLC every day and it's not that far away anymore. We really, really need to close these issues, hence the jabber session. Yet, you are being awfully quiet on this. Please, plan to attend if at all possible, and indicate the day you prefer. We need you to participate. Cheers, Aki (as chair) ext Eliot Lear kirjoitti: > > > All, > > We have a lot of open issues that we would like to close soon. Aki and > I would like to understand whether or not there would be interest in a > jabber session to try to come to consensus on open issues. We would > propose either Tuesday or Wednesday at 5:00pm CEST (8:00am PDT). If you > are interested, could you send an email indicating which day you > prefer. I will follow up in a day or two with a real invitation in > appropriate format (of course!). > > Thanks for your participation, > > Eliot > _______________________________________________ > 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 5B79D801DA for ; Thu, 28 Sep 2006 03:08:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4D2BF1422FB for ; Thu, 28 Sep 2006 03:08:43 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32233-04 for ; Thu, 28 Sep 2006 03:08:40 -0700 (PDT) Received: from natklopstock.rzone.de (natklopstock.rzone.de [81.169.145.174]) by laweleka.osafoundation.org (Postfix) with ESMTP id 804EB1422F7 for ; Thu, 28 Sep 2006 03:08:40 -0700 (PDT) Received: from ollie.block.home (dslb-084-063-165-091.pools.arcor-ip.net [84.63.165.91]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8SA8aRl014131 for ; Thu, 28 Sep 2006 12:08:37 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type Date: Thu, 28 Sep 2006 12:08:12 +0200 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: <200609281208.13107.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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 10:08:43 -0000 Am Mittwoch, 27. September 2006 21:38 schrieben Sie: > Isn't the purpose of the DATE value type to allow its value to be > interpreted differently by different people depending on their time > zone? Else, why would iCalendar bother defining this value type? :-) I forgot. And by defining a locally interpreted DATE value type it eliminates the existance of a universally interpreted DATE value type - as long as the DATE value type has nor further format specification, e.g. like DATE-TIME. :) Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html 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 56E4D7FDEE for ; Wed, 27 Sep 2006 12:40:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 47F5E1422E8 for ; Wed, 27 Sep 2006 12:40:28 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09349-09 for ; Wed, 27 Sep 2006 12:40:25 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BB8B91422E4 for ; Wed, 27 Sep 2006 12:40:25 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8OMrXUH001077; Wed, 27 Sep 2006 13:40:22 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2039295251159385941; Wed, 27 Sep 2006 13:39:01 -0600 Message-ID: <451AD351.4050008@oracle.com> Date: Wed, 27 Sep 2006 15:38:57 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Oliver Block Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type References: <45181D09.5030007@oracle.com> <4518244F.8090808@cisco.com> <45194A13.5050201@oracle.com> <200609262129.14170.lists@block-online.eu> In-Reply-To: <200609262129.14170.lists@block-online.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@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, 27 Sep 2006 19:40:30 -0000 Oliver, Isn't the purpose of the DATE value type to allow its value to be interpreted differently by different people depending on their time zone? Else, why would iCalendar bother defining this value type? :-) The exact start and end time of events such as "Christmas", "New Year's Day", "Canada Day" etc. depends on the time zone of the user. Cheers, Bernard Oliver Block wrote: > Am Dienstag, 26. September 2006 17:41 schrieb Bernard Desruisseaux: >>>> In section 4.8.6.3 Trigger of RFC 2445 it says: >>>>> Alarms specified in an event or to-do which is defined in terms of a >>>>> DATE value type will be triggered relative to 00:00:00 UTC on the >>>>> specified date. For example, if "DTSTART:19980205, then the duration >>>>> trigger will be relative to19980205T000000Z. > >>>> In my opinion, applications should trigger the alarm relative to >>>> 00:00:00 of the time zone configured on the calendar that contains >>>> the event or to-do, or the current user's preferred time zone. UTC >>>> should only be used when no specific time zone can be found in the >>>> current context. > > In my view every application is free to do that. It would just not define the > value for DTSTART as DATE but as DATE-TIME. > In other words: I find your opinion more intuitive than the standard and > that's what a user will expect. On the other hand the standard will assure > that every application will interpret a DATE value in the same way. > > Regards, > > Oliver > 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 EC4157FFBE for ; Tue, 26 Sep 2006 12:29:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DDFAB1422BD for ; Tue, 26 Sep 2006 12:29: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 24240-01 for ; Tue, 26 Sep 2006 12:29:41 -0700 (PDT) Received: from natlemon.rzone.de (natlemon.rzone.de [81.169.145.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0720B1422AA for ; Tue, 26 Sep 2006 12:29:40 -0700 (PDT) Received: from ollie.block.home (dslb-084-063-181-071.pools.arcor-ip.net [84.63.181.71]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8QJTbU7000858 for ; Tue, 26 Sep 2006 21:29:38 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type Date: Tue, 26 Sep 2006 21:29:13 +0200 User-Agent: KMail/1.7.1 References: <45181D09.5030007@oracle.com> <4518244F.8090808@cisco.com> <45194A13.5050201@oracle.com> In-Reply-To: <45194A13.5050201@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609262129.14170.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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 19:29:45 -0000 Am Dienstag, 26. September 2006 17:41 schrieb Bernard Desruisseaux: > >> In section 4.8.6.3 Trigger of RFC 2445 it says: > >>> Alarms specified in an event or to-do which is defined in terms of a > >>> DATE value type will be triggered relative to 00:00:00 UTC on the > >>> specified date. For example, if "DTSTART:19980205, then the duration > >>> trigger will be relative to19980205T000000Z. > >> In my opinion, applications should trigger the alarm relative to > >> 00:00:00 of the time zone configured on the calendar that contains > >> the event or to-do, or the current user's preferred time zone. UTC > >> should only be used when no specific time zone can be found in the > >> current context. In my view every application is free to do that. It would just not define the value for DTSTART as DATE but as DATE-TIME. In other words: I find your opinion more intuitive than the standard and that's what a user will expect. On the other hand the standard will assure that every application will interpret a DATE value in the same way. Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html 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 95AD17FBE1 for ; Tue, 26 Sep 2006 08:42:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8624A1422B8 for ; Tue, 26 Sep 2006 08:42: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 20912-04 for ; Tue, 26 Sep 2006 08:42:55 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A8481422BE for ; Tue, 26 Sep 2006 08:42:55 -0700 (PDT) Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8QF1wAC003154; Tue, 26 Sep 2006 09:42:50 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2034862891159285278; Tue, 26 Sep 2006 09:41:18 -0600 Message-ID: <45194A13.5050201@oracle.com> Date: Tue, 26 Sep 2006 11:41:07 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type References: <45181D09.5030007@oracle.com> <4518244F.8090808@cisco.com> In-Reply-To: <4518244F.8090808@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Calsify WG 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, 26 Sep 2006 15:42:57 -0000 Hi Eliot, Eliot Lear wrote: > Bernard, >> In section 4.8.6.3 Trigger of RFC 2445 it says: >> >>> Alarms specified in an event or to-do which is defined in terms of a >>> DATE value type will be triggered relative to 00:00:00 UTC on the >>> specified date. For example, if "DTSTART:19980205, then the duration >>> trigger will be relative to19980205T000000Z. >> In my opinion, applications should trigger the alarm relative to >> 00:00:00 of the time zone configured on the calendar that contains >> the event or to-do, or the current user's preferred time zone. UTC >> should only be used when no specific time zone can be found in the >> current context. > > > I agree in principle. However, I am concerned about existing > implementations. Alarms are used, and if we make this change then how > many implementations immediately become non-compliant? The only thing that matter is whether users will receive their alarm at the time they expect to receive them. People using applications that implement what the RFC says will most likely not get their alarm at the time they expect. In my case, I would receive them 5 hours in advance during Eastern Standard Time, and 4 hours in advance when in Eastern Daylight Time. I doubt there's any implementation that do this. Currently, the text doesn't specify any clear requirement level (i.e., MAY, SHOULD, MUST). I think it should. Thanks, Bernard > > Eliot 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 DDB457FFD9 for ; Tue, 26 Sep 2006 00:54:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CEE721422A5 for ; Tue, 26 Sep 2006 00:54:53 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25220-02 for ; Tue, 26 Sep 2006 00:54:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C43B142299 for ; Tue, 26 Sep 2006 00:54:52 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Sep 2006 00:54:52 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8Q7sqgs004204 for ; Tue, 26 Sep 2006 00:54:52 -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 k8Q7sqQV009908 for ; Tue, 26 Sep 2006 00:54:52 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp467.cisco.com [10.61.65.211]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8Q7iDr9011956 for ; Tue, 26 Sep 2006 00:44:14 -0700 Message-ID: <4518DCCA.5010808@cisco.com> Date: Tue, 26 Sep 2006 09:54:50 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8 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=527; t=1159257292; x=1160121292; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:jabber=20session=20next=20week?; X=v=3Dcisco.com=3B=20h=3DFmXo4AJkwtqBtmCA+gzsx8qfUv4=3D; b=pH5BF1EXAZ3grtrXdhrMkQfJbvMGaYhwdiJ7de/JWyAEIWm4Ka2EI/7ADgUqWCPOh/pJa74M ht3ZdLNII2xOQWADXqM2d7x5QfmBdg6GqaJ7mDdhMJqcRDjzHQwAVlxD; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] jabber session next week? 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, 26 Sep 2006 07:54:54 -0000 All, We have a lot of open issues that we would like to close soon. Aki and I would like to understand whether or not there would be interest in a jabber session to try to come to consensus on open issues. We would propose either Tuesday or Wednesday at 5:00pm CEST (8:00am PDT). If you are interested, could you send an email indicating which day you prefer. I will follow up in a day or two with a real invitation in appropriate format (of course!). Thanks for your participation, Eliot 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 23A047FF7F for ; Mon, 25 Sep 2006 17:41:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0FA951422A1 for ; Mon, 25 Sep 2006 17:41:09 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29029-03 for ; Mon, 25 Sep 2006 17:41:08 -0700 (PDT) Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [216.148.227.155]) by laweleka.osafoundation.org (Postfix) with ESMTP id B39BE14229F for ; Mon, 25 Sep 2006 17:41:08 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc15) with SMTP id <20060926004108m1500ldmuke>; Tue, 26 Sep 2006 00:41:08 +0000 From: "Tim Hare" To: Subject: RE: [Ietf-calsify] Issue 33: characters v. octets Date: Mon, 25 Sep 2006 20:41:00 -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: <4517AF2E.5040407@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbgjUgFEtX7uESeQVeKwA7aWkzPvAAdwMyw Message-Id: <20060926004108.B39BE14229F@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.5 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: Tue, 26 Sep 2006 00:41:09 -0000 Section 6 should also say 'MUST not truncate', it needs to be the same in both places, other than that I agree with the proposed change. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Eliot Lear Sent: Monday, September 25, 2006 6:28 AM To: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Issue 33: characters v. octets After a long drawn out discussion on Issue 1 regarding breaking of lines, I would also like to close on Issue 33, which reads: > http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/0010 > 78.html > > In section 4.8.4.7 Unique Identifier of RFC 2445 it says: > > > Implementations MUST be able to receive and persist values of at > > least 255 characters for this property. > > And, in Section 6 Recommended Practices it also says: > > > 6. An implementation can truncate a "SUMMARY" property value to 255 > > characters. > > In both sections I propose to change "255 characters" to "255 octets". I propose the following alternative wording: In section 4.8.4.7: > Implementations MUST be able to receive and persist values of at > least 255 octets for this property, but MUST not truncate values > in the middle of a character. In section 6: > 6. An implementation can truncate a "SUMMARY" property value to 255 > octets, but should not truncate the property value in the middle > of a character. If someone has appropriate wording to perhaps replace the word "character" with code point, that would be fine too. _______________________________________________ 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 747F67FEFC for ; Mon, 25 Sep 2006 13:29:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 66C9D142296 for ; Mon, 25 Sep 2006 13:29:13 -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 06916-09 for ; Mon, 25 Sep 2006 13:29:12 -0700 (PDT) Received: from ktown.kde.org (ktown.kde.org [131.246.120.250]) by laweleka.osafoundation.org (Postfix) with SMTP id 76E86142295 for ; Mon, 25 Sep 2006 13:29:11 -0700 (PDT) Received: (qmail 17226 invoked from network); 25 Sep 2006 20:29:09 -0000 Received: from localhost (HELO kool.tcd.ie) (127.0.0.1) by localhost with SMTP; 25 Sep 2006 20:29:09 -0000 Received: from [10.71.0.150] (unknown [10.71.0.150]) by kool.tcd.ie (Postfix) with ESMTP id 8F85C93B for ; Mon, 25 Sep 2006 21:28:49 +0100 (IST) From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type Date: Mon, 25 Sep 2006 21:26:34 +0100 User-Agent: KMail/1.9.1 References: <45181D09.5030007@oracle.com> <4518244F.8090808@cisco.com> In-Reply-To: <4518244F.8090808@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609252126.34650.reinhold@kainhofer.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: Mon, 25 Sep 2006 20:29:13 -0000 On Monday 25 September 2006 19:47, Eliot Lear wrote: > Bernard, > > > In section 4.8.6.3 Trigger of RFC 2445 it says: > > > Alarms specified in an event or to-do which is defined in terms of a > > > DATE value type will be triggered relative to 00:00:00 UTC on the > > > specified date. For example, if "DTSTART:19980205, then the duration > > > trigger will be relative to19980205T000000Z. > > > > In my opinion, applications should trigger the alarm relative to > > 00:00:00 of the time zone configured on the calendar that contains > > the event or to-do, or the current user's preferred time zone. UTC > > should only be used when no specific time zone can be found in the > > current context. > > I agree in principle. However, I am concerned about existing > implementations. Alarms are used, and if we make this change then how > many implementations immediately become non-compliant? On the other hand, how many implementations violated the RFC so far and would be compliant after the change? Cheers, Reinhold 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 11F817FC3D for ; Mon, 25 Sep 2006 11:47:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F252D14228F for ; Mon, 25 Sep 2006 11:47: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 13277-01 for ; Mon, 25 Sep 2006 11:47:45 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 817E214228C for ; Mon, 25 Sep 2006 11:47:45 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Sep 2006 11:47:45 -0700 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.20060308/8.12.11) with ESMTP id k8PIljRi006775; Mon, 25 Sep 2006 11:47:45 -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 k8PIlj1E012803; Mon, 25 Sep 2006 11:47:45 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp467.cisco.com [10.61.65.211]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8PIb8Tp027190; Mon, 25 Sep 2006 11:37:09 -0700 Message-ID: <4518244F.8090808@cisco.com> Date: Mon, 25 Sep 2006 20:47:43 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type References: <45181D09.5030007@oracle.com> In-Reply-To: <45181D09.5030007@oracle.com> Content-Type: text/plain; charset=UTF-8 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=838; t=1159210065; x=1160074065; c=relaxed/simple; s=sjdkim3002; 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]=20Section=204.8.6.3=20Trigger=3A=20Trigger=20rela tive=20to=20DATE=0A=20value=20type; X=v=3Dcisco.com=3B=20h=3Dpi73hqxaGQ2oVCw3G3vKrOchDIM=3D; b=QdI6wqLWRAET3UDksA1PLNFrKzB8AzZitbKeT8NpZHjW5UVqtlKTpfeIzbLxOC2efsc5Nw0R /w/5d35jZt/IMYm7ocsSzVNy1+yudA2W6mfXrTqlkbf8Rtqr/m7mnIRH; 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: Calsify WG 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, 25 Sep 2006 18:47:46 -0000 Bernard, > In section 4.8.6.3 Trigger of RFC 2445 it says: > > > Alarms specified in an event or to-do which is defined in terms of a > > DATE value type will be triggered relative to 00:00:00 UTC on the > > specified date. For example, if "DTSTART:19980205, then the duration > > trigger will be relative to19980205T000000Z. > > In my opinion, applications should trigger the alarm relative to > 00:00:00 of the time zone configured on the calendar that contains > the event or to-do, or the current user's preferred time zone. UTC > should only be used when no specific time zone can be found in the > current context. I agree in principle. However, I am concerned about existing implementations. Alarms are used, and if we make this change then how many implementations immediately become non-compliant? Eliot 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 D1BA77FE78 for ; Mon, 25 Sep 2006 11:17:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C2DF514228C for ; Mon, 25 Sep 2006 11:17:28 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01919-04 for ; Mon, 25 Sep 2006 11:17:27 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 436BA14228A for ; Mon, 25 Sep 2006 11:17:27 -0700 (PDT) Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8PBsX27020637 for ; Mon, 25 Sep 2006 12:17:25 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2031091691159208220; Mon, 25 Sep 2006 12:17:00 -0600 Message-ID: <45181D09.5030007@oracle.com> Date: Mon, 25 Sep 2006 14:16:41 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type 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, 25 Sep 2006 18:17:28 -0000 In section 4.8.6.3 Trigger of RFC 2445 it says: > Alarms specified in an event or to-do which is defined in terms of a > DATE value type will be triggered relative to 00:00:00 UTC on the > specified date. For example, if "DTSTART:19980205, then the duration > trigger will be relative to19980205T000000Z. In my opinion, applications should trigger the alarm relative to 00:00:00 of the time zone configured on the calendar that contains the event or to-do, or the current user's preferred time zone. UTC should only be used when no specific time zone can be found in the current context. Cheers, Bernard 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 974EC7FACC for ; Mon, 25 Sep 2006 10:58:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8813314228A for ; Mon, 25 Sep 2006 10:58: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 05946-01 for ; Mon, 25 Sep 2006 10:58:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by laweleka.osafoundation.org (Postfix) with ESMTP id 193E6142289 for ; Mon, 25 Sep 2006 10:58:01 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 25 Sep 2006 10:58:01 -0700 X-IronPort-AV: i="4.09,215,1157353200"; d="scan'208"; a="444138459:sNHT39485516" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8PHw0wc010344; Mon, 25 Sep 2006 10:58: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 k8PHw01E007424; Mon, 25 Sep 2006 10:58:00 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp467.cisco.com [10.61.65.211]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8PHlNDu026079; Mon, 25 Sep 2006 10:47:24 -0700 Message-ID: <451818A6.9010206@cisco.com> Date: Mon, 25 Sep 2006 19:57:58 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: [Ietf-calsify] ABNF References: <200609230104.08779.lists@block-online.eu> <45148055.30006@oracle.com> <905D630229904F49EB559429@ninevah.local> <4517C527.7050509@cisco.com> <451817D1.1050601@isode.com> In-Reply-To: <451817D1.1050601@isode.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=644; t=1159207080; x=1160071080; c=relaxed/simple; s=sjdkim2002; 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]=20ABNF; X=v=3Dcisco.com=3B=20h=3D3s/V0W5ePFxjMuCa+swdX2/qDyI=3D; b=j9hVGC7IIrilOshueaI4XZehDGhVc/ZWBLU5IXRczBtxXd+OiVpTHs3YZS3UUDqnzcJM6mPa iMSilvxDQhRm2Xw0WOx+DBuAZdbPADc+twJdHCcysZwjq0h8Hht7Ka36; 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: Mon, 25 Sep 2006 17:58:02 -0000 Alexey Melnikov wrote: >>> >>> calprops = prodid version [calscale] [method] *x-prop >>> ; can appear in any order >>> >>> I do think that is better than having comments indicating the >>> frequency of occurrence of each element as we have now. >>> >> >> We have to be extremely careful about these changes, but I believe the >> above text is actually more clear than what is there. Does anyone >> object to this change? >> >> > I don't have any objections, however many people don't bother reading > ABNF. So this comment should also appear in the text. > Right. Similar to the one that there now ;-) 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 C11177FA95 for ; Mon, 25 Sep 2006 10:55:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B2CA5142289 for ; Mon, 25 Sep 2006 10:55:20 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05894-03 for ; Mon, 25 Sep 2006 10:55:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id F07AC142257 for ; Mon, 25 Sep 2006 10:55:18 -0700 (PDT) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 25 Sep 2006 18:55:17 +0100 Message-ID: <451817D1.1050601@isode.com> Date: Mon, 25 Sep 2006 18:54:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] ABNF References: <200609230104.08779.lists@block-online.eu> <45148055.30006@oracle.com> <905D630229904F49EB559429@ninevah.local> <4517C527.7050509@cisco.com> In-Reply-To: <4517C527.7050509@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.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: Mon, 25 Sep 2006 17:55:20 -0000 Eliot Lear wrote: >Cyrus, > > >>Unfortunately ABNF itself does not have the concept of an 'unordered' >>list of items. However, the last time I discussed this with ABNF >>folks, I think the general consensus was that it was OK to add a >>comment to the ABNF stating that all items in that element were >>'unordered'. So we could have: >> >>calprops = prodid version [calscale] [method] *x-prop >> ; can appear in any order >> >>I do think that is better than having comments indicating the >>frequency of occurrence of each element as we have now. >> >> > >We have to be extremely careful about these changes, but I believe the >above text is actually more clear than what is there. Does anyone >object to this change? > > I don't have any objections, however many people don't bother reading ABNF. So this comment should also appear in the text. 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 137AF7F9F5 for ; Mon, 25 Sep 2006 09:08:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 05C4614227B for ; Mon, 25 Sep 2006 09:08:19 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22379-06 for ; Mon, 25 Sep 2006 09:08:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D9EB14227E for ; Mon, 25 Sep 2006 09:08:17 -0700 (PDT) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 25 Sep 2006 17:08:15 +0100 Message-ID: <4517FEC1.1060300@isode.com> Date: Mon, 25 Sep 2006 17:07:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] Issue 19: IANA considerations for RFC2445bis References: <4517D370.7050806@cisco.com> In-Reply-To: <4517D370.7050806@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.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: Mon, 25 Sep 2006 16:08:20 -0000 Eliot Lear wrote: >[Chair hat off again] > >All, > >Our charter calls for us to clarify IANA considerations for new >components / tokens. In my opinion interoperability demands that new >components be documented. My preference is by RFC. A procedure, >however, for the content of the RFC would smooth things along. How >would people like to proceed? Think about how DHCP options are handled, >for instance. There's a template and people use it, and eventually an >option is assigned by IANA. > >In case you're wondering just how this relates to the price of tea in >China, at the last Calconnect (as opposed to the one going on now), >there was a proposal to include some sort of venue information, like >telephone number or number of seats or the like. Having something along >these lines would be useful. There's a lot of meta information out >there about things like meeting rooms that we don't want to duplicate >from people's LDAP directories, of course. But the common example of >this might be telephone information relating to conferencing. > >We don't want to make additions like this too difficult, but I think >they should still be subject to some sort of review. > >Now, from my reading of the current draft the only thing that IANA needs >to keep track of is iana-token. Is that correct? If so, I propose the >following text: > >The IANA is requested to maintain a database of tokens. Each token >should be associated with an RFC that has undergone review by the IETF. > > If this procedure is not to be enforced on vendor specific tokens, than this is Ok. (Your template looks fine.) 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 4F01D7FE6B for ; Mon, 25 Sep 2006 06:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 34EA514227B for ; Mon, 25 Sep 2006 06:02:42 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07670-10 for ; Mon, 25 Sep 2006 06:02:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id C788014226E for ; Mon, 25 Sep 2006 06:02:41 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Sep 2006 06:02:41 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8PD2ffU028282 for ; Mon, 25 Sep 2006 06:02:41 -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 k8PD2fYp012200 for ; Mon, 25 Sep 2006 06:02:41 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp321.cisco.com [10.61.65.65]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8PCq5kh019472 for ; Mon, 25 Sep 2006 05:52:06 -0700 Message-ID: <4517D370.7050806@cisco.com> Date: Mon, 25 Sep 2006 15:02:40 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2073; t=1159189361; x=1160053361; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Issue=2019=3A=20IANA=20considerations=20for=20RFC2445bis; X=v=3Dcisco.com=3B=20h=3D6mniMDWD7OjBiilBLIrXQk9LOmo=3D; b=UGh2E+h7RTo81Iuk8IvEy6PJ3dUJhdnXcUKTapOtjUb2ZljIf1X7Prd7MO4k8ydmNOoUeWKI 3PP96Lla+gcgIttihE1gCSOzbjHRWnq/oFkmIS6rNagL05QAClBY1cI6; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 19: IANA considerations for RFC2445bis 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, 25 Sep 2006 13:02:42 -0000 [Chair hat off again] All, Our charter calls for us to clarify IANA considerations for new components / tokens. In my opinion interoperability demands that new components be documented. My preference is by RFC. A procedure, however, for the content of the RFC would smooth things along. How would people like to proceed? Think about how DHCP options are handled, for instance. There's a template and people use it, and eventually an option is assigned by IANA. In case you're wondering just how this relates to the price of tea in China, at the last Calconnect (as opposed to the one going on now), there was a proposal to include some sort of venue information, like telephone number or number of seats or the like. Having something along these lines would be useful. There's a lot of meta information out there about things like meeting rooms that we don't want to duplicate from people's LDAP directories, of course. But the common example of this might be telephone information relating to conferencing. We don't want to make additions like this too difficult, but I think they should still be subject to some sort of review. Now, from my reading of the current draft the only thing that IANA needs to keep track of is iana-token. Is that correct? If so, I propose the following text: The IANA is requested to maintain a database of tokens. Each token should be associated with an RFC that has undergone review by the IETF. Each such RFC shall make use of the following template to register tokens: 1. Token Name 2. Context in which the token is valid (vevent / vprop / vtodo / ... ) 3. ABNF description of the token, using the context of this memo 4. How many of these may appear in one context? 5. Semantic specification of the token or a reference thereto. (Contrived) Example: 1. Token Name: VENUE 2. Valid Context: VEVENT 3. ABNF: venui = "VENUE" ":" 1*( rconfinfo / confroominfo ) rconfinfo = "REMOTE" ( "/" ( vconfurl ) / ( confnum ["+" confpass] )) ... Comments? Eliot 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 6433E7FCF3 for ; Mon, 25 Sep 2006 05:01:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 55AE1142271 for ; Mon, 25 Sep 2006 05:01:47 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13630-09 for ; Mon, 25 Sep 2006 05:01:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id E4112142257 for ; Mon, 25 Sep 2006 05:01:46 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Sep 2006 05:01:46 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8PC1kw5020285; Mon, 25 Sep 2006 05:01: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 k8PC1kYp008760; Mon, 25 Sep 2006 05:01:46 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp321.cisco.com [10.61.65.65]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8PBp9WT018091; Mon, 25 Sep 2006 04:51:10 -0700 Message-ID: <4517C527.7050509@cisco.com> Date: Mon, 25 Sep 2006 14:01:43 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] ABNF References: <200609230104.08779.lists@block-online.eu> <45148055.30006@oracle.com> <905D630229904F49EB559429@ninevah.local> In-Reply-To: <905D630229904F49EB559429@ninevah.local> Content-Type: text/plain; charset=UTF-8 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=733; t=1159185706; x=1160049706; c=relaxed/simple; s=sjdkim1002; 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]=20ABNF; X=v=3Dcisco.com=3B=20h=3DYr7gs6pX0NLcpcOpOfzudRBJngM=3D; b=r9ONNEWHN8lhNXBVsygCEI72H/2KjCZZA8vLKbul9KV6ASjc/88vYQ3QBLdj2+BHTD58UF8Z zrfMyn5EuPdr63JGchkoQGglh06c5iqbBL7Ju/9NB/uueapBxQdYtrrd; 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: Mon, 25 Sep 2006 12:01:47 -0000 Cyrus, > > Unfortunately ABNF itself does not have the concept of an 'unordered' > list of items. However, the last time I discussed this with ABNF > folks, I think the general consensus was that it was OK to add a > comment to the ABNF stating that all items in that element were > 'unordered'. So we could have: > > calprops = prodid version [calscale] [method] *x-prop > ; can appear in any order > > I do think that is better than having comments indicating the > frequency of occurrence of each element as we have now. > We have to be extremely careful about these changes, but I believe the above text is actually more clear than what is there. Does anyone object to this change? Eliot 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 689387F903 for ; Mon, 25 Sep 2006 03:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 59D2E142264 for ; Mon, 25 Sep 2006 03:28: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 08811-02 for ; Mon, 25 Sep 2006 03:28:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 023C714226E for ; Mon, 25 Sep 2006 03:27:59 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Sep 2006 03:27:59 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8PARxFt011159 for ; Mon, 25 Sep 2006 03:27:59 -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 k8PARxYp018803 for ; Mon, 25 Sep 2006 03:27:59 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp321.cisco.com [10.61.65.65]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8PAHOPl015807 for ; Mon, 25 Sep 2006 03:17:25 -0700 Message-ID: <4517AF2E.5040407@cisco.com> Date: Mon, 25 Sep 2006 12:27:58 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "ietf-calsify@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=1212; t=1159180079; x=1160044079; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Issue=2033=3A=20characters=20v.=20octets; X=v=3Dcisco.com=3B=20h=3Dc6r7d/k/vBVqT1aUIn+wyvyhbNk=3D; b=Beb7lI9YFKuMak6Mp4xsSlJI5cVUVh9E4TTC11t5fIijDrLwc0Pcpj7YBYMr8EOaoAS2O9zs Tmn7zab6IPaMmGcttUouDTd/j9e/gMTW6pQHLglWR09qUzvyc3xDhgsR; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 33: characters v. octets 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, 25 Sep 2006 10:28:01 -0000 After a long drawn out discussion on Issue 1 regarding breaking of lines, I would also like to close on Issue 33, which reads: > http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/001078.html > > In section 4.8.4.7 Unique Identifier of RFC 2445 it says: > > > Implementations MUST be able to receive and persist values of at > > least 255 characters for this property. > > And, in Section 6 Recommended Practices it also says: > > > 6. An implementation can truncate a "SUMMARY" property value to 255 > > characters. > > In both sections I propose to change "255 characters" to "255 octets". I propose the following alternative wording: In section 4.8.4.7: > Implementations MUST be able to receive and persist values of at > least 255 octets for this property, but MUST not truncate values > in the middle of a character. In section 6: > 6. An implementation can truncate a "SUMMARY" property value to 255 > octets, but should not truncate the property value in the middle > of a character. If someone has appropriate wording to perhaps replace the word "character" with code point, that would be fine too. 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 4CBB07FBB7 for ; Sat, 23 Sep 2006 07:47:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3D3A5142295 for ; Sat, 23 Sep 2006 07:47: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 09991-02 for ; Sat, 23 Sep 2006 07:47:00 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 73136142294 for ; Sat, 23 Sep 2006 07:47:00 -0700 (PDT) Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k8NEkqfp014419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Sep 2006 10:46:53 -0400 Date: Sat, 23 Sep 2006 10:46:53 -0400 From: Cyrus Daboo To: Bernard Desruisseaux , Oliver Block Subject: Re: [Ietf-calsify] ABNF Message-ID: <905D630229904F49EB559429@ninevah.local> In-Reply-To: <45148055.30006@oracle.com> References: <200609230104.08779.lists@block-online.eu> <45148055.30006@oracle.com> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED X-Spam-Level: Cc: 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: Sat, 23 Sep 2006 14:47:02 -0000 Hi Bernard, --On September 22, 2006 8:31:17 PM -0400 Bernard Desruisseaux wrote: > The notation you are proposing would dictate a specific > ordering of the properties. Unfortunately ABNF itself does not have the concept of an 'unordered' list of items. However, the last time I discussed this with ABNF folks, I think the general consensus was that it was OK to add a comment to the ABNF stating that all items in that element were 'unordered'. So we could have: calprops = prodid version [calscale] [method] *x-prop ; can appear in any order I do think that is better than having comments indicating the frequency of occurrence of each element as we have now. -- Cyrus Daboo 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 90E787F9D1 for ; Fri, 22 Sep 2006 17:35:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 81DF9142272 for ; Fri, 22 Sep 2006 17:35: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 24743-03 for ; Fri, 22 Sep 2006 17:35:09 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 146E4142262 for ; Fri, 22 Sep 2006 17:35:09 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8M0d6J0024319; Fri, 22 Sep 2006 18:35:05 -0600 Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-96-18.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 2025651261158971599; Fri, 22 Sep 2006 18:33:19 -0600 Message-ID: <45148055.30006@oracle.com> Date: Fri, 22 Sep 2006 20:31:17 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Oliver Block Subject: Re: [Ietf-calsify] ABNF References: <200609230104.08779.lists@block-online.eu> In-Reply-To: <200609230104.08779.lists@block-online.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@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: Sat, 23 Sep 2006 00:35:10 -0000 Hi Oliver, The notation you are proposing would dictate a specific ordering of the properties. Cheers, Bernard Oliver Block wrote: > Hello list, > > The ABNF notation could be spared. > > As an example (page 51/52): > > calprops = 2*( > > ; 'prodid' and 'version' are both REQUIRED, > ; but MUST NOT occur more than once > > prodid /version / > > ; 'calscale' and 'method' are optional, > ; but MUST NOT occur more than once > > calscale / > method / > > x-prop > > ) > > Could be noted as follows: > > calprops = prodid version *1calscale *1method *x-prop > > or: > > calprops = prodid version [calscale] [method] *x-prop > > Regards, > > Oliver > 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 1E6BA7F5E0 for ; Fri, 22 Sep 2006 16:04:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E263714227C for ; Fri, 22 Sep 2006 16:04: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 30447-08 for ; Fri, 22 Sep 2006 16:04:34 -0700 (PDT) Received: from natlemon.rzone.de (natlemon.rzone.de [81.169.145.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id 49FB2142273 for ; Fri, 22 Sep 2006 16:04:34 -0700 (PDT) Received: from ollie.block.home (dslb-084-063-169-025.pools.arcor-ip.net [84.63.169.25]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8MN4VaS014645 for ; Sat, 23 Sep 2006 01:04:32 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Date: Sat, 23 Sep 2006 01:04:07 +0200 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609230104.08779.lists@block-online.eu> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: Subject: [Ietf-calsify] ABNF 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, 22 Sep 2006 23:04:36 -0000 Hello list, The ABNF notation could be spared. As an example (page 51/52): calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once prodid /version / ; 'calscale' and 'method' are optional, ; but MUST NOT occur more than once calscale / method / x-prop ) Could be noted as follows: calprops = prodid version *1calscale *1method *x-prop or: calprops = prodid version [calscale] [method] *x-prop Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html 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 B22D47F64C for ; Fri, 22 Sep 2006 09:24:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A3A94142272 for ; Fri, 22 Sep 2006 09:24: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 18862-02 for ; Fri, 22 Sep 2006 09:24:55 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 36710142273 for ; Fri, 22 Sep 2006 09:24:55 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8MGOpaE027781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Sep 2006 09:24:51 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8MGOejI011952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Sep 2006 09:24:50 -0700 Date: Fri, 22 Sep 2006 09:24:40 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Eliot Lear Subject: Re: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <4513CCD9.7070904@cisco.com> Message-ID: References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512E354.7050208@isode.com> <4513B3B6.5030503@isode.com> <4513CCD9.7070904@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.22.85943 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: "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, 22 Sep 2006 16:24:57 -0000 On Fri, 22 Sep 2006, Eliot Lear wrote: > That sounds like consensus wording to me if ever I heard some. Can we > move along? Sold! -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. 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 2C5A07FA4D for ; Fri, 22 Sep 2006 04:45:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1E1B214228D for ; Fri, 22 Sep 2006 04:45: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 12344-05 for ; Fri, 22 Sep 2006 04:45:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8A315142280 for ; Fri, 22 Sep 2006 04:45:32 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2006 04:45:32 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8MBjWaZ016355; Fri, 22 Sep 2006 04:45:32 -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 k8MBjVQV006266; Fri, 22 Sep 2006 04:45:31 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp245.cisco.com [10.61.64.245]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8MBZ6Qx016544; Fri, 22 Sep 2006 04:35:07 -0700 Message-ID: <4513CCD9.7070904@cisco.com> Date: Fri, 22 Sep 2006 13:45:29 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: [Ietf-calsify] Issue 1: new proposed text References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512E354.7050208@isode.com> <4513B3B6.5030503@isode.com> In-Reply-To: <4513B3B6.5030503@isode.com> 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=1859; t=1158925532; x=1159789532; c=relaxed/simple; s=sjdkim4002; 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]=20Issue=201=3A=20new=20proposed=20text; X=v=3Dcisco.com=3B=20h=3DXjuxBjQaG6wIm6wiTfhysBsWyyw=3D; b=Zj9ElgPqMDTSSun5HS5WcbyESGitdskAnFeQf8yzv5ABaLQ2OdIehAmtd8IuFJUNT+Ibk2Ve o4VztoMkN04Ih0DFInG3HOOxSUuxfokLrpecbsKHLl5OtWeLwZn94jMp; 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: Mark Crispin , "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, 22 Sep 2006 11:45:34 -0000 Alexey Melnikov wrote: > Mark Crispin wrote: > >> On Thu, 21 Sep 2006, Alexey Melnikov wrote: >> >>>>> 2. Add a sentence as follows: "It is possible for very simple >>>>> implementations to have improperly folded lines in the >>>>> middle of >>>>> UTF-8 characters. In such cases, implementations SHOULD unfold >>>>> lines in such a way to properly restore the character. >>>> >>>> I would make that a "Note", I would replace "UTF-8 characters" by >>>> "character" and I would lowercase the SHOULD. >>> >> Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear >> what we are talking about. Other charsets have multi-octet sequences >> too, but we've deprecated the use of these. >> >> Suggest using "need to" instead of "should", to indicate that this is >> a corrolary technical requirement as opposed to something >> specifically required by the protocol. >> >>>> That is: >>>> > Note: It is possible for very simple implementations to have >>>> > improperly folded lines in the middle of a character. In such >>>> > cases, implementations should unfold lines in such a way to >>>> > properly restore the character. >>> >>> I would also delete "In such cases". A receiving client has no other >>> choice. >> >> Another good point. >> >> In conclusion, suggest: >> >> Note: It is possible for very simple implementations to generate >> improperly folded lines in the middle of a UTF-8 multi-octet >> sequence. For this reason, implementations need to unfold lines >> in such a way to properly restore the unbroken sequence. > > I like that, but "unbroken" reads strangely hear (the sender might > have broken it). > Maybe "restore the original sequence"? > That sounds like consensus wording to me if ever I heard some. Can we move along? Eliot 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 34CC57FB69 for ; Fri, 22 Sep 2006 04:23:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2638A142280 for ; Fri, 22 Sep 2006 04:23: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 04409-07 for ; Fri, 22 Sep 2006 04:23:34 -0700 (PDT) Received: from natblert.rzone.de (natblert.rzone.de [81.169.145.181]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6B898142273 for ; Fri, 22 Sep 2006 04:23:34 -0700 (PDT) Received: from ollie.block.home (dslb-084-063-169-025.pools.arcor-ip.net [84.63.169.25]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8MBNQoZ020996 for ; Fri, 22 Sep 2006 13:23:27 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 1: new proposed text Date: Fri, 22 Sep 2006 13:23:04 +0200 User-Agent: KMail/1.7.1 References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512EB0D.4060302@cisco.com> In-Reply-To: <4512EB0D.4060302@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609221323.04606.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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2006 11:23:37 -0000 Am Donnerstag, 21. September 2006 21:42 schrieb Eliot Lear: > Are there any objections to the below? Oliver? None, that I'd like to express in this stage of decision making. Best Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html 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 EC72E7FDB4 for ; Fri, 22 Sep 2006 02:58:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE06A142280 for ; Fri, 22 Sep 2006 02:58:42 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28290-07 for ; Fri, 22 Sep 2006 02:58:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0C5E814225A for ; Fri, 22 Sep 2006 02:58:41 -0700 (PDT) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 22 Sep 2006 10:58:39 +0100 Message-ID: <4513B3B6.5030503@isode.com> Date: Fri, 22 Sep 2006 10:58:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [Ietf-calsify] Issue 1: new proposed text References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512E354.7050208@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.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: Fri, 22 Sep 2006 09:58:43 -0000 Mark Crispin wrote: > On Thu, 21 Sep 2006, Alexey Melnikov wrote: > >>>> 2. Add a sentence as follows: "It is possible for very simple >>>> implementations to have improperly folded lines in the middle of >>>> UTF-8 characters. In such cases, implementations SHOULD unfold >>>> lines in such a way to properly restore the character. >>> >>> I would make that a "Note", I would replace "UTF-8 characters" by >>> "character" and I would lowercase the SHOULD. >> > Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear what > we are talking about. Other charsets have multi-octet sequences too, > but we've deprecated the use of these. > > Suggest using "need to" instead of "should", to indicate that this is > a corrolary technical requirement as opposed to something specifically > required by the protocol. > >>> That is: >>> > Note: It is possible for very simple implementations to have >>> > improperly folded lines in the middle of a character. In such >>> > cases, implementations should unfold lines in such a way to >>> > properly restore the character. >> >> I would also delete "In such cases". A receiving client has no other >> choice. > > Another good point. > > In conclusion, suggest: > > Note: It is possible for very simple implementations to generate > improperly folded lines in the middle of a UTF-8 multi-octet > sequence. For this reason, implementations need to unfold lines > in such a way to properly restore the unbroken sequence. I like that, but "unbroken" reads strangely hear (the sender might have broken it). Maybe "restore the original sequence"? 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 BBF597FDAD for ; Thu, 21 Sep 2006 14:23:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AE197142272 for ; Thu, 21 Sep 2006 14:23: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 24486-01 for ; Thu, 21 Sep 2006 14:23:55 -0700 (PDT) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1FA3814226D for ; Thu, 21 Sep 2006 14:23:55 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8LLNWEc030567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Sep 2006 14:23:32 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8LLNVIg026240 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Sep 2006 14:23:31 -0700 Date: Thu, 21 Sep 2006 14:21:28 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov Subject: Re: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <4512E354.7050208@isode.com> Message-ID: References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> <4512E354.7050208@isode.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-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.21.134943 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: "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, 21 Sep 2006 21:23:57 -0000 On Thu, 21 Sep 2006, Alexey Melnikov wrote: >>> 2. Add a sentence as follows: "It is possible for very simple >>> implementations to have improperly folded lines in the middle of >>> UTF-8 characters. In such cases, implementations SHOULD unfold >>> lines in such a way to properly restore the character. >> I would make that a "Note", I would replace "UTF-8 characters" by >> "character" and I would lowercase the SHOULD. Suggest "a UTF-8 multi-octet sequence" to make it perfectly clear what we are talking about. Other charsets have multi-octet sequences too, but we've deprecated the use of these. Suggest using "need to" instead of "should", to indicate that this is a corrolary technical requirement as opposed to something specifically required by the protocol. >> That is: >> > Note: It is possible for very simple implementations to have >> > improperly folded lines in the middle of a character. In such >> > cases, implementations should unfold lines in such a way to >> > properly restore the character. > I would also delete "In such cases". A receiving client has no other choice. Another good point. In conclusion, suggest: Note: It is possible for very simple implementations to generate improperly folded lines in the middle of a UTF-8 multi-octet sequence. For this reason, implementations need to unfold lines in such a way to properly restore the unbroken sequence. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. 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 6AF8B7FD94 for ; Thu, 21 Sep 2006 12:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C51C142272 for ; Thu, 21 Sep 2006 12:44:28 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09159-07 for ; Thu, 21 Sep 2006 12:44:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id CFBF714226E for ; Thu, 21 Sep 2006 12:44:26 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2006 12:44:26 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8LJiQTZ029191; Thu, 21 Sep 2006 12:44: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 k8LJiQQV001903; Thu, 21 Sep 2006 12:44:26 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp217.cisco.com [10.61.64.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8LJY4mn027736; Thu, 21 Sep 2006 12:34:05 -0700 Message-ID: <4512EB95.3050603@cisco.com> Date: Thu, 21 Sep 2006 21:44:21 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Mark Crispin Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> In-Reply-To: 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=1521; t=1158867866; x=1159731866; c=relaxed/simple; s=sjdkim4002; 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[Issue=2031]=20Re=3A=20[Ietf-calsify]=20Character=20set=20restri ction=20in=09section=0A=204.3.11=20Text; X=v=3Dcisco.com=3B=20h=3DGWakw1p7V87yvgUQvy9noDKsvt0=3D; b=r432eG1Dthg/YZpTAv7kzPOBi1YJos7ad57BNlZXXP76wGutpCMFgysSMJjWl2LfFbogHbgT O9GE8dN84PkHagopci0B0sVM/vkzAWqVbLmITUwjP2zuIrwVCHjbFaz0; 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: Calsify WG 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, 21 Sep 2006 19:44:28 -0000 Are there objections to Mark's proposed wording? Eliot Mark Crispin wrote: > On Thu, 21 Sep 2006, Bernard Desruisseaux wrote: >> - The use of other character set is not forbidden. > > Can it be deprecated though? > > US-ASCII, UTF-8, etc. are charsets, not character sets. This is > particularly important with UTF-8; the character set is Unicode, not > UTF-8. > > Finally, since you already state that UTF-8 SHOULD be generated, there > is no reason that US-ASCII be listed as a supported charset. It > sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted. > > Suggested wording: > > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. The charset supported by this revision of > iCalendar is UTF-8. The use of any other charset is deprecated by > this revision of iCalendar; however note that this revision > requires that compliant applications MUST accept iCalendar objects > using either the UTF-8 or US-ASCII charset. > > Also change other occurances of "character set" to "charset". > > -- Mark -- > > http://panda.com/mrc > Democracy is two wolves and a sheep deciding what to eat for lunch. > Liberty is a well-armed sheep contesting the vote. > _______________________________________________ > 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 52AA77FD94 for ; Thu, 21 Sep 2006 12:42:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 44C36142273 for ; Thu, 21 Sep 2006 12:42: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 09531-06 for ; Thu, 21 Sep 2006 12:42:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id C2EBE142272 for ; Thu, 21 Sep 2006 12:42:10 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2006 12:42:10 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8LJgAnn015148; Thu, 21 Sep 2006 12:42:10 -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 k8LJgAQV000523; Thu, 21 Sep 2006 12:42:10 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp217.cisco.com [10.61.64.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8LJVmTh027663; Thu, 21 Sep 2006 12:31:49 -0700 Message-ID: <4512EB0D.4060302@cisco.com> Date: Thu, 21 Sep 2006 21:42:05 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-calsify] Issue 1: new proposed text References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> In-Reply-To: <4512D7FD.4070805@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1288; t=1158867730; x=1159731730; c=relaxed/simple; s=sjdkim2002; 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]=20Issue=201=3A=20new=20proposed=20text; X=v=3Dcisco.com=3B=20h=3DXjuxBjQaG6wIm6wiTfhysBsWyyw=3D; b=B51SiXJMn18kejP8tlCXp7JJ0bRSc6odxzMZIuw/ZLTiNACascPJm/9AozJKgWuslVzYA2rX qdN9+s3faFMC19n+cZsiUIiN7vVZja+XB2eebHeyjkhz9KLASj+tRRTU; 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, 21 Sep 2006 19:42:12 -0000 Are there any objections to the below? Oliver? Bernard Desruisseaux wrote: > Eliot Lear wrote: >> >> > > [...] > > >> I have two recommendations for textual changes to RFC 2445: >> >> 1. Delete the second sentence in the 2nd paragraph after the example >> in 4.1 as redundant (it says the exact same thing in the first >> paragraph); > > +1 > >> 2. Add a sentence as follows: "It is possible for very simple >> implementations to have improperly folded lines in the middle of >> UTF-8 characters. In such cases, implementations SHOULD unfold >> lines in such a way to properly restore the character. > > I would make that a "Note", I would replace "UTF-8 characters" by > "character" and I would lowercase the SHOULD. That is: > > > Note: It is possible for very simple implementations to have > > improperly folded lines in the middle of a character. In such > > cases, implementations should unfold lines in such a way to > > properly restore the character. > > Thanks, > Bernard > >> >> Eliot >> >> _______________________________________________ >> 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 49B377FA70 for ; Thu, 21 Sep 2006 12:09:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B35214226B for ; Thu, 21 Sep 2006 12:09: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 00860-04 for ; Thu, 21 Sep 2006 12:09:32 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 659E414226E for ; Thu, 21 Sep 2006 12:09:32 -0700 (PDT) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 21 Sep 2006 20:09:31 +0100 Message-ID: <4512E354.7050208@isode.com> Date: Thu, 21 Sep 2006 20:09:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Bernard Desruisseaux Subject: Re: [Ietf-calsify] Issue 1: new proposed text References: <450FB6D6.6000601@cisco.com> <4512D7FD.4070805@oracle.com> In-Reply-To: <4512D7FD.4070805@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.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, 21 Sep 2006 19:09:33 -0000 Bernard Desruisseaux wrote: > Eliot Lear wrote: > >> > > > [...] > >> I have two recommendations for textual changes to RFC 2445: >> >> 1. Delete the second sentence in the 2nd paragraph after the example >> in 4.1 as redundant (it says the exact same thing in the first >> paragraph); > > +1 +1 >> 2. Add a sentence as follows: "It is possible for very simple >> implementations to have improperly folded lines in the middle of >> UTF-8 characters. In such cases, implementations SHOULD unfold >> lines in such a way to properly restore the character. > > I would make that a "Note", I would replace "UTF-8 characters" by > "character" and I would lowercase the SHOULD. That is: > > > Note: It is possible for very simple implementations to have > > improperly folded lines in the middle of a character. In such > > cases, implementations should unfold lines in such a way to > > properly restore the character. I would also delete "In such cases". A receiving client has no other choice. 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 487ED7F92B for ; Thu, 21 Sep 2006 12:02:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3AAFF142270 for ; Thu, 21 Sep 2006 12:02: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 31514-06 for ; Thu, 21 Sep 2006 12:02:04 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3159814226E for ; Thu, 21 Sep 2006 12:02:04 -0700 (PDT) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 21 Sep 2006 20:02:02 +0100 Message-ID: <4512E194.2090009@isode.com> Date: Thu, 21 Sep 2006 20:01:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Calsify WG 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, 21 Sep 2006 19:02:05 -0000 Mark Crispin wrote: > On Thu, 21 Sep 2006, Bernard Desruisseaux wrote: > >> - The use of other character set is not forbidden. > > Can it be deprecated though? > > US-ASCII, UTF-8, etc. are charsets, not character sets. This is > particularly important with UTF-8; the character set is Unicode, not > UTF-8. > > Finally, since you already state that UTF-8 SHOULD be generated, there > is no reason that US-ASCII be listed as a supported charset. It > sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted. > > Suggested wording: > > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. The charset supported by this revision of > iCalendar is UTF-8. The use of any other charset is deprecated by > this revision of iCalendar; however note that this revision > requires that compliant applications MUST accept iCalendar objects > using either the UTF-8 or US-ASCII charset. I can live with this alternative text as well. > Also change other occurances of "character set" to "charset". 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 37FCC7FD8D for ; Thu, 21 Sep 2006 12:00:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 295C7142270 for ; Thu, 21 Sep 2006 12:00: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 17504-08 for ; Thu, 21 Sep 2006 12:00:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 00B1E14226B for ; Thu, 21 Sep 2006 12:00:14 -0700 (PDT) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 21 Sep 2006 20:00:12 +0100 Message-ID: <4512E126.1070302@isode.com> Date: Thu, 21 Sep 2006 19:59:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> In-Reply-To: <4512D5E5.6090400@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Calsify WG 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, 21 Sep 2006 19:00:15 -0000 Bernard Desruisseaux wrote: > Folks, I would like to close issue 31 with a new proposal: > > - UTF-8 and US-ASCII are the only character set supported by iCalendar. > - The use of other character set is not forbidden. > - Compliant applications are REQUIRED to accept UTF-8 and US-ASCII. > - Compliant applications SHOULD generate iCalendar objects in UTF-8. > > Here's the proposed text changes: > > Section 3.2 Parameters > > OLD TEXT: > >> The "charset" parameter is defined in [RFC 2046] for other body >> parts. It is used to identify the default character set used within >> the body part. > > NEW TEXT: > >> The "charset" parameter is defined in [RFC 2046] for subtypes of >> the "text" media type. It is used to indicate the character set > >> used in the body part. The character sets supported by this revision > As per Mark's comment: replace "character set" with "charset" >> of iCalendar are UTF-8 and US-ASCII. > > > Section 4.1.4 Character Set > > OLD TEXT: > >> There is not a property parameter to declare the character set used >> in a property value. The default character set for an iCalendar >> object is UTF-8 as defined in [RFC 2279]. >> >> The "charset" Content-Type parameter can be used in MIME transports >> to specify any other IANA registered character set. > > NEW TEXT: > >> There is not a property parameter to declare the character set used > s/character set/charset >> in a property value. The default character set for an iCalendar > s/character set/charset >> object is UTF-8 as defined in [RFC 3629]. >> >> The character sets supported by this revision of iCalendar are UTF-8 > s/character sets/charsets >> and US-ASCII. Compliant applications MUST accept iCalendar objects >> using the UTF-8 or US-ASCII character set and SHOULD generate >> iCalendar object using the UTF-8 character set. >> >> The "charset" Content-Type parameter can be used in MIME transports >> to specify the character set being used. > I would change the last sentence to become normative: The "charset" Content-Type parameter MUST be used in MIME transports to specify the charset being used. (this MUST is irrelevant for US-ASCII case, but I can't think of any better way of saying that) > Section 4.3.11 Text > > OLD TEXT: > >> Formal Definition: The character sets supported by this revision of >> iCalendar are UTF-8 and US ASCII thereof. The applicability to other >> character sets is for future work. The value type is defined by the >> following notation. > > NEW TEXT: > >> Formal Definition: The value type is defined by the following notation: > Otherwise I am fine with this proposal. 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 3792C7FB2C for ; Thu, 21 Sep 2006 11:33:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 28E32142270 for ; Thu, 21 Sep 2006 11:33: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 15213-09 for ; Thu, 21 Sep 2006 11:32:59 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A07C9142269 for ; Thu, 21 Sep 2006 11:32:59 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8LIWuO7031822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Sep 2006 11:32:57 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8LIWtGh022491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Sep 2006 11:32:56 -0700 Date: Thu, 21 Sep 2006 11:32:55 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Bernard Desruisseaux Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: <4512D5E5.6090400@oracle.com> Message-ID: References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.21.105442 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Calsify WG 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, 21 Sep 2006 18:33:01 -0000 On Thu, 21 Sep 2006, Bernard Desruisseaux wrote: > - The use of other character set is not forbidden. Can it be deprecated though? US-ASCII, UTF-8, etc. are charsets, not character sets. This is particularly important with UTF-8; the character set is Unicode, not UTF-8. Finally, since you already state that UTF-8 SHOULD be generated, there is no reason that US-ASCII be listed as a supported charset. It sufficies to say, as you do in 4.1.4, that US-ASCII must be accepted. Suggested wording: The "charset" parameter is defined in [RFC 2046] for subtypes of the "text" media type. It is used to indicate the character set used in the body part. The charset supported by this revision of iCalendar is UTF-8. The use of any other charset is deprecated by this revision of iCalendar; however note that this revision requires that compliant applications MUST accept iCalendar objects using either the UTF-8 or US-ASCII charset. Also change other occurances of "character set" to "charset". -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. 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 EE9697FD27 for ; Thu, 21 Sep 2006 11:22:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E0340142269 for ; Thu, 21 Sep 2006 11:22: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 31514-03 for ; Thu, 21 Sep 2006 11:22:06 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3D727142262 for ; Thu, 21 Sep 2006 11:22:06 -0700 (PDT) Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k8LILwap008608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Sep 2006 14:22:00 -0400 Date: Thu, 21 Sep 2006 14:21:52 -0400 From: Cyrus Daboo To: Bernard Desruisseaux , Calsify WG Subject: Re: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text Message-ID: <520F1DFF22E934D043E7D4B7@Cyrus-Daboo-G5.local> In-Reply-To: <4512D5E5.6090400@oracle.com> References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> <4512D5E5.6090400@oracle.com> X-Mailer: Mulberry/4.0.6 (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=-2.6 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, 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, 21 Sep 2006 18:22:08 -0000 Hi Bernard, --On September 21, 2006 2:11:49 PM -0400 Bernard Desruisseaux wrote: +1 to your new text on charset. -- 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 D0FA77FD27 for ; Thu, 21 Sep 2006 11:21:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C2E24142270 for ; Thu, 21 Sep 2006 11:21:42 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31514-02 for ; Thu, 21 Sep 2006 11:21:42 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 57448142269 for ; Thu, 21 Sep 2006 11:21:42 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8L6Pt9o021876; Thu, 21 Sep 2006 12:21:37 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2021720161158862848; Thu, 21 Sep 2006 12:20:48 -0600 Message-ID: <4512D7FD.4070805@oracle.com> Date: Thu, 21 Sep 2006 14:20:45 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Ietf-calsify] Issue 1: new proposed text References: <450FB6D6.6000601@cisco.com> In-Reply-To: <450FB6D6.6000601@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: "ietf-calsify@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, 21 Sep 2006 18:21:42 -0000 Eliot Lear wrote: > > > [...] > > I have two recommendations for textual changes to RFC 2445: > > 1. Delete the second sentence in the 2nd paragraph after the example > in 4.1 as redundant (it says the exact same thing in the first > paragraph); +1 > 2. Add a sentence as follows: "It is possible for very simple > implementations to have improperly folded lines in the middle of > UTF-8 characters. In such cases, implementations SHOULD unfold > lines in such a way to properly restore the character. I would make that a "Note", I would replace "UTF-8 characters" by "character" and I would lowercase the SHOULD. That is: > Note: It is possible for very simple implementations to have > improperly folded lines in the middle of a character. In such > cases, implementations should unfold lines in such a way to > properly restore the character. Thanks, Bernard > > Eliot > > _______________________________________________ > 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 70C987FA00 for ; Thu, 21 Sep 2006 11:13:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 62204142272 for ; Thu, 21 Sep 2006 11:13: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 25379-06 for ; Thu, 21 Sep 2006 11:13:22 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 88E23142269 for ; Thu, 21 Sep 2006 11:13:22 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8JIIimC024319 for ; Thu, 21 Sep 2006 12:13:20 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2021385351158862311; Thu, 21 Sep 2006 12:11:51 -0600 Message-ID: <4512D5E5.6090400@oracle.com> Date: Thu, 21 Sep 2006 14:11:49 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Subject: [Issue 31] Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text References: <44E9FD8D.8070904@oracle.com> <44EA6BB0.7070108@oracle.com> In-Reply-To: <44EA6BB0.7070108@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: 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, 21 Sep 2006 18:13:24 -0000 Folks, I would like to close issue 31 with a new proposal: - UTF-8 and US-ASCII are the only character set supported by iCalendar. - The use of other character set is not forbidden. - Compliant applications are REQUIRED to accept UTF-8 and US-ASCII. - Compliant applications SHOULD generate iCalendar objects in UTF-8. Here's the proposed text changes: Section 3.2 Parameters OLD TEXT: > The "charset" parameter is defined in [RFC 2046] for other body > parts. It is used to identify the default character set used within > the body part. NEW TEXT: > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. The character sets supported by this revision > of iCalendar are UTF-8 and US-ASCII. Section 4.1.4 Character Set OLD TEXT: > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > object is UTF-8 as defined in [RFC 2279]. > > The "charset" Content-Type parameter can be used in MIME transports > to specify any other IANA registered character set. NEW TEXT: > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > object is UTF-8 as defined in [RFC 3629]. > > The character sets supported by this revision of iCalendar are UTF-8 > and US-ASCII. Compliant applications MUST accept iCalendar objects > using the UTF-8 or US-ASCII character set and SHOULD generate > iCalendar object using the UTF-8 character set. > > The "charset" Content-Type parameter can be used in MIME transports > to specify the character set being used. Section 4.3.11 Text OLD TEXT: > Formal Definition: The character sets supported by this revision of > iCalendar are UTF-8 and US ASCII thereof. The applicability to other > character sets is for future work. The value type is defined by the > following notation. NEW TEXT: > Formal Definition: The value type is defined by the following notation: Cheers, Bernard Bernard Desruisseaux wrote: > Hi Mark, > > I don't feel that it is important for new work to support any > character set other than UTF-8, but I'm not sure whether rfc2445bis > should be considered as new work though! > > In my proposal I only quoted section 4.3.11 which makes clear that > UTF-8 and US-ASCII are the only character sets supported by iCalendar. > I should probably have quoted the other sections where character sets > are discussed, that is, sections 2.3, 3.2, and more importantly 4.1.4: > > Section 4.1.4 Character Set > > > The "charset" Content-Type parameter can be used in MIME transports > > to specify any other IANA registered character set. > > Section 4.3.11 says that only UTF-8 and US-ASCII are supported. > While section 4.1.4 says that you can specify any IANA registered > character set in the "charset" parameter... > > The result is that some iCalendar applications currently output > iCalendar objects in ISO-8859-1. > > I see two options: > > a) We modify section 4.3.11 as I proposed. But now I realize > that we would also need to modify all the ABNF rules that > makes reference to the numerical value of specific characters > (e.g., LF = %x0A in US-ASCII but %x25 in EBCDIC). Yuk! > > b) We modify sections 3.2, 4.1.4 and 4.3.11 to be in sync and > clearly specify which character sets are supported by iCalendar: > > b.1) UTF-8 only. > b.2) UTF-8 and US-ASCII only. > b.3) UTF-8, US-ASCII, and ISO-8859-1 only. > > At this point I favor option (b.3). It looks to me as the easiest > way to clarify the specification without breaking most (if not all) > existing iCalendar applications. > > Cheers, > Bernard > > Mark Crispin wrote: >> On Mon, 21 Aug 2006, Bernard Desruisseaux wrote: >>> I don't see any reason why it states that only UTF-8 and US-ASCII >>> are supported by this revision. Section "3.2 Parameter" doesn't >>> specify any restriction on the values allowed for the "charset" >>> parameter. >>> I propose to remove this statement from section 4.3.11. >> >> Can you explain why you feel that it is important for new work to >> support any character set other than UTF-8? If any revision is made, >> it should be to delete US-ASCII and make UTF-8 mandatory. >> >> -- Mark -- >> >> http://panda.com/mrc >> Democracy is two wolves and a sheep deciding what to eat for lunch. >> Liberty is a well-armed sheep contesting the vote. > > > _______________________________________________ > 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 1516E7F9C1 for ; Thu, 21 Sep 2006 04:12:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 06FA3142282 for ; Thu, 21 Sep 2006 04:12: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 31675-09 for ; Thu, 21 Sep 2006 04:12:03 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30440142278 for ; Thu, 21 Sep 2006 04:12:03 -0700 (PDT) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 21 Sep 2006 12:12:00 +0100 Message-ID: <4512736C.1050402@isode.com> Date: Thu, 21 Sep 2006 12:11:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Bernard Desruisseaux Subject: Re: [Ietf-calsify] Section 4.8.8.1 Non-standard Properties: Parameters allowed on x-prop References: <45100AF5.9060808@oracle.com> In-Reply-To: <45100AF5.9060808@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Calsify WG 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, 21 Sep 2006 11:12:05 -0000 Bernard Desruisseaux wrote: > In section 4.8.8.1 Non-standard Properties of RFC 2445 it says: > > > The data type for this property > > is TEXT. Optionally, the data type can be any of the other valid data > > types. > > > > Format Definition: The property is defined by the following notation: > > > > x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF > > ; Lines longer than 75 octets should be folded > > In my opinion x-prop should allow any parameter defined by iCalendar > as well as any iana-param. There is no reason to invent an xparam > if there already exists a parameter that can be used. This make sense. > While "the data type [of an x-prop] can be any of the other valid data > type", one would currently not be allowed to specify the VALUE parameter > to specify the value type of the property. Here's an example, found on > the web, that I believe should be valid: > > X-WD-NEXT-ALARM;VALUE=DATE-TIME:20040927T153000 > > [ Actually, this example would still be invalid since WinDate didn't use > a "vendor identification" of at least 3 characters. See the vendorid > rule in section 4.1 Content Lines. ] 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 0B8D97FD3F for ; Wed, 20 Sep 2006 20:24:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 298B6142277 for ; Wed, 20 Sep 2006 20:24: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 12476-07 for ; Wed, 20 Sep 2006 20:24:21 -0700 (PDT) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [63.240.77.85]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F51C142276 for ; Wed, 20 Sep 2006 20:24:21 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (sccrmhc15) with SMTP id <2006092103242001500immvbe>; Thu, 21 Sep 2006 03:24:20 +0000 From: "Tim Hare" To: "'Calsify List'" Subject: RE: [Ietf-calsify] Issue 1: new proposed text Date: Wed, 20 Sep 2006 23:24:14 -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: <541798243.20060920095720@pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbc1dlkscJlMejbTPKrC9z9SfRkCQAVIbmA Message-Id: <20060921032421.4F51C142276@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.5 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: Thu, 21 Sep 2006 03:24:23 -0000 I don't claim to be a UTF-anything expert, but the current text does require white space (SP or TAB) after the CRLF for folding. However - what do we break if we eliminate the folding altogether as in my proposed text below? Old Text: ---------------------------------------------------------------------------- 4.1 Content Lines The iCalendar object is organized into individual lines of text, called content lines. Content lines are delimited by a line break, which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII decimal 10). Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. Long content lines SHOULD be split into a multiple line representations using a line "folding" technique. That is, a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white space character (i.e., SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence of CRLF followed immediately by a single linear white space character is ignored (i.e., removed) when processing the content type. For example the line: DESCRIPTION:This is a long description that exists on a long line. Can be represented as: DESCRIPTION:This is a lo ng description that exists on a long line. The process of moving from this folded multiple line representation to its single line representation is called "unfolding". Unfolding is accomplished by removing the CRLF character and the linear white space character that immediately follows. When parsing a content line, folded lines MUST first be unfolded according to the unfolding procedure described above. When generating a content line, lines longer than 75 octets SHOULD be folded according to the folding procedure described above. The content information associated with an iCalendar object is formatted using a syntax similar to that defined by [RFC 2425]. That is, the content information consists of CRLF-separated content lines. The following notation defines the lines of content in an iCalendar object: contentline = name *(";" param ) ":" value CRLF ; This ABNF is just a general definition for an initial parsing ; of the content line into its property name, parameter list, ; and value string ; When parsing a content line, folded lines MUST first ; be unfolded according to the unfolding procedure ; described above. When generating a content line, lines ; longer than 75 octets SHOULD be folded according to ; the folding procedure described above. ---------------------------------------------------------------------------- --------------------------------- Proposed new text (feel free to make modifications as necessary for Unicode purposes) ---------------------------------------------------------------------------- --------------------------------- 4.1 Content Lines The iCalendar object is organized into individual lines of text, called content lines. Content lines are delimited by a line break, which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII decimal 10). Lines of text may be of arbitrary length. It is up to the CUA implementation to present the text to the user in a manner consistent with the current user interface in use, which may include wrapping the text within margins or other forms of presentation changes. The originator of calendar object text should not expect its display to be limited to any arbitrary length. Older implementations of [RFC 2445] may be encountered which have performed a "folding" acton on longer lines of text by inserting a CRLF sequence followed by a single linear white space character (SPACE, US-ASCII decimal 32; or HTAB US-ASCII decimal 09) at logical folding points. This is usually done in e-mail implementations to improve compatibility with some mailing programs. Implementations MAY choose to "unfold" these lines by replacing the CRLF-whitespace sequence with a single space. For example the line: DESCRIPTION:This is a lo ng description that exists on a long line. May be presented to the interface as is, or may be unfolded to read: DESCRIPTION: This is a long descripton that exists on a long line. The content information associated with an iCalendar object is formatted using a syntax similar to that defined by [RFC 2425]. That is, the content information consists of CRLF-separated content lines. The following notation defines the lines of content in an iCalendar object: contentline = name *(";" param ) ":" value CRLF ; This ABNF is just a general definition for an initial parsing ; of the content line into its property name, parameter list, ; and value string ; When parsing a content line, folded lines MAY first ; be unfolded according to the unfolding procedure ; described above. ---------------------------------------------------------------------------- --------------------------------- Since TEXT property values MUST represent intentional line breaks via "\n" or "\N" (4.3.11) anyone desiring to Format the content of a long line may include those formatting sequences. The most likely use case for folding is the DESCRIPTION: property, "\n" is completely appropriate to use there and is already seen in implementations. I also believe that most current implementations "wrap" text within some UI limit (margins, window size, etcetera) so the human factor of folding is already handled in the UI anyway. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Bill McQuillan Sent: Wednesday, September 20, 2006 12:57 PM To: Calsify List Subject: Re: [Ietf-calsify] Issue 1: new proposed text On Wed, 2006-09-20, I wrote: > A further issue is that the definition of "folding" in RFC 2822 > explicitly states (sect.2.2.3) that the unfolded text includes the SP > following the CRLF. Thus, a UTF-8 sequence of any sort would be > interrupted by a SP character unless an idiosyncratic unfolding operation is employed. Sorry, I'm afraid I had a temporary brain glitch. The folding technique is NOT modeled on RFC2822 headers and the issue of the SP does not exist. Never mind! -- Bill McQuillan _______________________________________________ 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 05E6B7F8FC for ; Wed, 20 Sep 2006 09:57:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CD95414226E for ; Wed, 20 Sep 2006 09:57: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 24755-08 for ; Wed, 20 Sep 2006 09:57:23 -0700 (PDT) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7FD0A14224B for ; Wed, 20 Sep 2006 09:57:23 -0700 (PDT) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 180BD29D52; Wed, 20 Sep 2006 12:57:45 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id AB77F76279; Wed, 20 Sep 2006 12:57:43 -0400 (EDT) Date: Wed, 20 Sep 2006 09:57:20 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <541798243.20060920095720@pobox.com> To: Calsify List Subject: Re: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <1903786649.20060920091412@pobox.com> References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> <1903786649.20060920091412@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, PRIORITY_NO_NAME 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, 20 Sep 2006 16:57:24 -0000 On Wed, 2006-09-20, I wrote: > A further issue is that the definition of "folding" in RFC 2822 explicitly > states (sect.2.2.3) that the unfolded text includes the SP following the > CRLF. Thus, a UTF-8 sequence of any sort would be interrupted by a SP > character unless an idiosyncratic unfolding operation is employed. Sorry, I'm afraid I had a temporary brain glitch. The folding technique is NOT modeled on RFC2822 headers and the issue of the SP does not exist. Never mind! -- Bill McQuillan 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 1082B7FB14 for ; Wed, 20 Sep 2006 09:14:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D70FF142280 for ; Wed, 20 Sep 2006 09:14: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 08007-02 for ; Wed, 20 Sep 2006 09:14:21 -0700 (PDT) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C2EC142277 for ; Wed, 20 Sep 2006 09:14:21 -0700 (PDT) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id A2A6E27541; Wed, 20 Sep 2006 12:14:42 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 0636171D91; Wed, 20 Sep 2006 12:14:40 -0400 (EDT) Date: Wed, 20 Sep 2006 09:14:12 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1903786649.20060920091412@pobox.com> To: Calsify List Subject: Re: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, PRIORITY_NO_NAME 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, 20 Sep 2006 16:14:23 -0000 On Wed, 2006-09-20, Cyrus Daboo wrote: > --On September 20, 2006 5:30:13 PM +0200 Eliot Lear wrote: >>> Actually it is for everybody who wants to produce well-formed UTF-8. >>> >> >> But nobody will care unless they're looking at the raw message. Yes, >> it's malformed, but then it's not really meant to be represented. What >> really should be happening is that implementations should use MIME >> multipart/alternative and not put a text/calendar message in front of a >> user. > The issue is that it is not out of the realm of possibility that a spam > filter or some other 'integrity' checker in email will reject an iMIP > message because it contains invalid utf-8 (utf-8 multi-octet sequence > broken across two lines). Another example might be reading the utf-8 byte > stream into a unicode string object BEFORE doing the iCal processing on the > unicode string data - that will likely fail if there is invalid utf-8. > That's been my primary concern rather than whether it will be viewable in a > text editor. A further issue is that the definition of "folding" in RFC 2822 explicitly states (sect.2.2.3) that the unfolded text includes the SP following the CRLF. Thus, a UTF-8 sequence of any sort would be interrupted by a SP character unless an idiosyncratic unfolding operation is employed. -- Bill McQuillan 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 3CFAC7FB29 for ; Wed, 20 Sep 2006 08:58:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2015E14228D for ; Wed, 20 Sep 2006 08:58: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 16477-10 for ; Wed, 20 Sep 2006 08:58:06 -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 97727142277 for ; Wed, 20 Sep 2006 08:58:06 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 20 Sep 2006 08:57:46 -0700 X-IronPort-AV: i="4.09,192,1157353200"; d="scan'208"; a="323296290:sNHT2246782698" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KFvjRb009671; Wed, 20 Sep 2006 08:57:45 -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 k8KFvjQV008653; Wed, 20 Sep 2006 08:57:45 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp281.cisco.com [10.61.65.25]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8KFlR9P023323; Wed, 20 Sep 2006 08:47:28 -0700 Message-ID: <451164F3.7000407@cisco.com> Date: Wed, 20 Sep 2006 17:57:39 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Issue 1: new proposed text References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=712; t=1158767865; x=1159631865; c=relaxed/simple; s=sjdkim2002; 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]=20Issue=201=3A=20new=20proposed=20text; X=v=3Dcisco.com=3B=20h=3DXjuxBjQaG6wIm6wiTfhysBsWyyw=3D; b=UWSIYzW2m3b5vfuJ8QOyfQMONThULGNSa4hL84onkYZ0RZ2vvnPQOwHgL/sKvrkbmVqcEKpJ Ti6zLZvpbAfcvR4X4izhSMWO5CobiE/ytPUfOTtw0WVLgZOBgYIjclTU; 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: Wed, 20 Sep 2006 15:58:07 -0000 Hi Cyrus, > The issue is that it is not out of the realm of possibility that a > spam filter or some other 'integrity' checker in email will reject an > iMIP message because it contains invalid utf-8 (utf-8 multi-octet > sequence broken across two lines). Another example might be reading > the utf-8 byte stream into a unicode string object BEFORE doing the > iCal processing on the unicode string data - that will likely fail if > there is invalid utf-8. That's been my primary concern rather than > whether it will be viewable in a text editor. Sorry- to be clear RFC 2445 already requires that you not split lines in the middle of characters. This implies valid UTF-8 when used, IMHO. Eliot 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 DEC067F840 for ; Wed, 20 Sep 2006 08:49:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D0DAB142277 for ; Wed, 20 Sep 2006 08:49: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 03622-08 for ; Wed, 20 Sep 2006 08:49:58 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 05181142292 for ; Wed, 20 Sep 2006 08:49:57 -0700 (PDT) Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k8KFnfnT004572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Sep 2006 11:49:48 -0400 Date: Wed, 20 Sep 2006 11:49:36 -0400 From: Cyrus Daboo To: Eliot Lear , Oliver Block Subject: Re: [Ietf-calsify] Issue 1: new proposed text Message-ID: In-Reply-To: <45115E85.4010300@cisco.com> References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> X-Mailer: Mulberry/4.0.6 (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=-2.6 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, 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, 20 Sep 2006 15:50:00 -0000 Hi Eliot, --On September 20, 2006 5:30:13 PM +0200 Eliot Lear wrote: >> Actually it is for everybody who wants to produce well-formed UTF-8. >> > > But nobody will care unless they're looking at the raw message. Yes, > it's malformed, but then it's not really meant to be represented. What > really should be happening is that implementations should use MIME > multipart/alternative and not put a text/calendar message in front of a > user. The issue is that it is not out of the realm of possibility that a spam filter or some other 'integrity' checker in email will reject an iMIP message because it contains invalid utf-8 (utf-8 multi-octet sequence broken across two lines). Another example might be reading the utf-8 byte stream into a unicode string object BEFORE doing the iCal processing on the unicode string data - that will likely fail if there is invalid utf-8. That's been my primary concern rather than whether it will be viewable in a text editor. -- Cyrus Daboo 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 AC4DE7FB1A for ; Wed, 20 Sep 2006 08:49:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9DFD714228D for ; Wed, 20 Sep 2006 08:49: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 01408-02 for ; Wed, 20 Sep 2006 08:49:36 -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 06524142277 for ; Wed, 20 Sep 2006 08:49:36 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8KFnYtf005885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Sep 2006 08:49:35 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8KFnXhp010563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Sep 2006 08:49:34 -0700 Date: Wed, 20 Sep 2006 08:49:33 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Eliot Lear Subject: Re: [Ietf-calsify] Issue 1: new proposed text In-Reply-To: <45115E85.4010300@cisco.com> Message-ID: References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.20.82443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: 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, 20 Sep 2006 15:49:37 -0000 On Wed, 20 Sep 2006, Eliot Lear wrote: >> Actually it is for everybody who wants to produce well-formed UTF-8. > But nobody will care unless they're looking at the raw message. Yes, > it's malformed, but then it's not really meant to be represented. What > really should be happening is that implementations should use MIME > multipart/alternative and not put a text/calendar message in front of a > user. I support Eliot's position. My position can best be summarized as being "do it right or don't do it at all." That is, we should choose between either "only fold at a point that represents a complete glyph" or "it doesn't matter where folding takes place, since the text will always be unfolded prior to processing." It is pointless to talk about "well-formed UTF-8" and say that is "good enough." Yes, you can break a UTF-8 string such that the two substrings are both independently interpretable by a UTF-8 decoder. The problem is that if the break is before a combining character codepoint, the string after the break is NOT a valid UTF-8 string since it begins with a combining character. Put another way, it's valid UTF-8 encoding of an invalid string. I believe that a half-solution is the worst possible choice, since it creates the illusion of viability for a primitive tool that uses the raw message without doing proper folding. If we punt, and say that folding can occur anywhere, then primitive tools are broken; they will attempt to deal with dangling UTF-8 strings which end in the middle of a codepoint sequence, and with strings that start in the middle of a codepoint sequence. If we go all the way, and say that folding can only occur at a glyph point, then primitive tools will be fine. That is a lot of work to undertake just to make it easier for some lazy programmer to foist a primitive tool as being acceptable. In my opinion, we should choose between supporting primitive tools, or declaring primitive tools to be totally broken. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. 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 D2B347F83D for ; Wed, 20 Sep 2006 08:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C47D9142280 for ; Wed, 20 Sep 2006 08:48:55 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05934-02 for ; Wed, 20 Sep 2006 08:48:53 -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 DBBBC142277 for ; Wed, 20 Sep 2006 08:48:52 -0700 (PDT) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k8KFmjWD016885 for ; Wed, 20 Sep 2006 17:48:49 +0200 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 1: new proposed text Date: Wed, 20 Sep 2006 17:48:24 +0200 User-Agent: KMail/1.9.3 References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> <45115E85.4010300@cisco.com> In-Reply-To: <45115E85.4010300@cisco.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609201748.43856.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: 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, 20 Sep 2006 15:48:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 20. September 2006 17:30 schrieb Eliot Lear: > >   > > > >>     * The concern is only for those who are attempting to read the > >>       calendar information in a text based mailer, > >>     > > > > Actually it is for everybody who wants to produce well-formed UTF-8. > >   > > But nobody will care unless they're looking at the raw message.  Yes, > it's malformed, but then it's not really meant to be represented.  What > really should be happening is that implementations should use MIME > multipart/alternative and not put a text/calendar message in front of a > user. Actually, who knows what mail processors (e.g. recoding done by several mail servers!) will do if they encounter broken UTF-8 bytes, because line folding happened in between the bytes of a multi-byte character? If they try to "fix" the UTF-8, they actually mess up the calendar attachment. Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: 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.5 (GNU/Linux) iD8DBQFFEWLbTqjEwhXvPN0RAlEiAJ0drHF3kkbSyW3oLvCqxrvzP9Zb5ACgzDFH 2ZW8tNG8RPrWR3ZkK76WqZM= =dNhh -----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 696267FADA for ; Wed, 20 Sep 2006 08:30:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5AC0E142262 for ; Wed, 20 Sep 2006 08:30:20 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26357-07 for ; Wed, 20 Sep 2006 08:30:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by laweleka.osafoundation.org (Postfix) with ESMTP id D5F5F14225C for ; Wed, 20 Sep 2006 08:30:18 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2006 08:30:18 -0700 X-IronPort-AV: i="4.09,192,1157353200"; d="scan'208"; a="443749740:sNHT31595280" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KFUIL3021718; Wed, 20 Sep 2006 08:30:18 -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 k8KFUIQV016781; Wed, 20 Sep 2006 08:30:18 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp281.cisco.com [10.61.65.25]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8KFK0Q9022716; Wed, 20 Sep 2006 08:20:01 -0700 Message-ID: <45115E85.4010300@cisco.com> Date: Wed, 20 Sep 2006 17:30:13 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Oliver Block Subject: Re: [Ietf-calsify] Issue 1: new proposed text References: <450FB6D6.6000601@cisco.com> <200609201722.31921.lists@block-online.eu> In-Reply-To: <200609201722.31921.lists@block-online.eu> 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=1275; t=1158766218; x=1159630218; c=relaxed/simple; s=sjdkim1002; 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]=20Issue=201=3A=20new=20proposed=20text; X=v=3Dcisco.com=3B=20h=3DXjuxBjQaG6wIm6wiTfhysBsWyyw=3D; b=HEnenbf7oEbRV5vA03KFOZNngcrQl4Ly2OV42rh+JZxia14YvFEY2kuxG91Sreu7nss4tnD3 Zea5hxtIPr8Mpg7jeNiZ0hcgyeamzJM4f+wZiMFiqfnMqNJIM5MbxukQ; 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: Wed, 20 Sep 2006 15:30:20 -0000 Again, chair hat off. Oliver Block wrote: > Am Dienstag, 19. September 2006 11:22 schrieb Eliot Lear: > >> >> > > >> * The concern is only for those who are attempting to read the >> calendar information in a text based mailer, >> > > Actually it is for everybody who wants to produce well-formed UTF-8. > But nobody will care unless they're looking at the raw message. Yes, it's malformed, but then it's not really meant to be represented. What really should be happening is that implementations should use MIME multipart/alternative and not put a text/calendar message in front of a user. > >> Hence, relaxing of folding is perhaps not advisable. >> > > >> 2. Add a sentence as follows: "It is possible for very simple >> implementations to have improperly folded lines in the middle of >> UTF-8 characters. In such cases, implementations SHOULD unfold >> lines in such a way to properly restore the character. >> > > Would you want to add this to the old text or to one of the new proposals? > Old text. Ok, WG chair hat on: Don't forget that if you have an alternative please present it. If I missed it I apologize in advance. Eliot 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 83C897FA9C for ; Wed, 20 Sep 2006 08:23:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 758C314228D for ; Wed, 20 Sep 2006 08:23: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 18942-10 for ; Wed, 20 Sep 2006 08:23:09 -0700 (PDT) Received: from natlemon.rzone.de (natlemon.rzone.de [81.169.145.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id BAB83142262 for ; Wed, 20 Sep 2006 08:23:08 -0700 (PDT) Received: from ollie.block.home (dslb-084-063-189-032.pools.arcor-ip.net [84.63.189.32]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8KFN51H025440 for ; Wed, 20 Sep 2006 17:23:06 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Issue 1: new proposed text Date: Wed, 20 Sep 2006 17:22:31 +0200 User-Agent: KMail/1.7.1 References: <450FB6D6.6000601@cisco.com> In-Reply-To: <450FB6D6.6000601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609201722.31921.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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2006 15:23:11 -0000 Am Dienstag, 19. September 2006 11:22 schrieb Eliot Lear: > > * The concern is only for those who are attempting to read the > calendar information in a text based mailer, Actually it is for everybody who wants to produce well-formed UTF-8. > Hence, relaxing of folding is perhaps not advisable. > 2. Add a sentence as follows: "It is possible for very simple > implementations to have improperly folded lines in the middle of > UTF-8 characters. In such cases, implementations SHOULD unfold > lines in such a way to properly restore the character. Would you want to add this to the old text or to one of the new proposals? Best Regards, Oliver -- Leben ist mehr als ... http://www.nak-nrw.de/p_6_4.html 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 039177FA95 for ; Tue, 19 Sep 2006 09:25:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E92A2142279 for ; Tue, 19 Sep 2006 09:25: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 32090-07 for ; Tue, 19 Sep 2006 09:25:06 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7AEC314225A for ; Tue, 19 Sep 2006 09:25:06 -0700 (PDT) Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8J7ijmo011636 for ; Tue, 19 Sep 2006 10:25:03 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2013325411158683078; Tue, 19 Sep 2006 10:24:38 -0600 Message-ID: <451019B9.9040506@oracle.com> Date: Tue, 19 Sep 2006 12:24:25 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Subject: Re: [Ietf-calsify] Should all iCalendar tokens be considered as iana-token? References: <45100D58.20802@oracle.com> In-Reply-To: <45100D58.20802@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: 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, 19 Sep 2006 16:25:07 -0000 Actually, section 4.6.6 Alarm Component explicitly states: > The "VALARM" calendar component MUST only appear within either a > "VEVENT" or "VTODO" calendar component. Sorry! Cheers, Bernard Bernard Desruisseaux wrote: > Should the tokens defined in the iCalendar specification be > considered as iana-token? > > If yes, that would imply that VALARM components can be specified > within VCALENDAR objects given that VCALENDAR objects can specify > iana-comp. > > One could argue that as long as the VALARM component defines a > TRIGGER with an absolute date/time value there is no issue, but > is that something we want to allow? > > Cheers, > Bernard > _______________________________________________ > 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 CB9127FAE1 for ; Tue, 19 Sep 2006 08:50:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BD3BB142288 for ; Tue, 19 Sep 2006 08:50: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 01060-01 for ; Tue, 19 Sep 2006 08:50:08 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E251142278 for ; Tue, 19 Sep 2006 08:50:08 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8HN2oPc016018 for ; Tue, 19 Sep 2006 09:50:06 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2012952261158680885; Tue, 19 Sep 2006 09:48:05 -0600 Message-ID: <45101128.5030203@oracle.com> Date: Tue, 19 Sep 2006 11:47:52 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Sections 4.2.6, 4.8.4.1, 4.8.4.2, and 4.8.4.3: Bad LDAP URL in examples 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, 19 Sep 2006 15:50:08 -0000 The LDAP URLs specified in the examples of section 4.2.6, 4.8.4.1, 4.8.4.2, and 4.8.4.3 are all broken. They are missing a '?' character and they partially escape the '=' character in quoted-printable... For instance, the LDAP URL in section 4.2.6 should be change from: ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS?? (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com to: ORGANIZER;DIR="ldap://host.com:6666/o=ABC%20Industries,c=US??? (cn=Jim%20Dolittle)":MAILTO:jimdo@host1.com Cheers, Bernard 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 9F4AB7FA83 for ; Tue, 19 Sep 2006 08:33:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9112114225E for ; Tue, 19 Sep 2006 08:33: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 29723-03 for ; Tue, 19 Sep 2006 08:33:47 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 20F4914225D for ; Tue, 19 Sep 2006 08:33:47 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8HMO9gp007891 for ; Tue, 19 Sep 2006 09:33:44 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2012938501158679909; Tue, 19 Sep 2006 09:31:49 -0600 Message-ID: <45100D58.20802@oracle.com> Date: Tue, 19 Sep 2006 11:31:36 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Should all iCalendar tokens be considered as iana-token? 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, 19 Sep 2006 15:33:49 -0000 Should the tokens defined in the iCalendar specification be considered as iana-token? If yes, that would imply that VALARM components can be specified within VCALENDAR objects given that VCALENDAR objects can specify iana-comp. One could argue that as long as the VALARM component defines a TRIGGER with an absolute date/time value there is no issue, but is that something we want to allow? Cheers, Bernard 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 7F61E7F9EB for ; Tue, 19 Sep 2006 08:23:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 71FCB14228C for ; Tue, 19 Sep 2006 08:23: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 29173-02 for ; Tue, 19 Sep 2006 08:23:34 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EE96C14228B for ; Tue, 19 Sep 2006 08:23:33 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8HN2oP2016018 for ; Tue, 19 Sep 2006 09:23:32 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2013258221158679299; Tue, 19 Sep 2006 09:21:39 -0600 Message-ID: <45100AF5.9060808@oracle.com> Date: Tue, 19 Sep 2006 11:21:25 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Section 4.8.8.1 Non-standard Properties: Parameters allowed on x-prop 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, 19 Sep 2006 15:23:34 -0000 In section 4.8.8.1 Non-standard Properties of RFC 2445 it says: > The data type for this property > is TEXT. Optionally, the data type can be any of the other valid data > types. > > Format Definition: The property is defined by the following notation: > > x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF > ; Lines longer than 75 octets should be folded In my opinion x-prop should allow any parameter defined by iCalendar as well as any iana-param. There is no reason to invent an xparam if there already exists a parameter that can be used. While "the data type [of an x-prop] can be any of the other valid data type", one would currently not be allowed to specify the VALUE parameter to specify the value type of the property. Here's an example, found on the web, that I believe should be valid: X-WD-NEXT-ALARM;VALUE=DATE-TIME:20040927T153000 [ Actually, this example would still be invalid since WinDate didn't use a "vendor identification" of at least 3 characters. See the vendorid rule in section 4.1 Content Lines. ] Cheers, Bernard 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 94AB07F7C8 for ; Tue, 19 Sep 2006 07:32:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 868D6142289 for ; Tue, 19 Sep 2006 07:32: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 22328-05 for ; Tue, 19 Sep 2006 07:32:34 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0D3A3142278 for ; Tue, 19 Sep 2006 07:32:34 -0700 (PDT) Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8J3BBWQ002613 for ; Tue, 19 Sep 2006 08:32:32 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2011573761158676295; Tue, 19 Sep 2006 08:31:35 -0600 Message-ID: <450FFF3A.2040408@oracle.com> Date: Tue, 19 Sep 2006 10:31:22 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Section 4.6.6 Alarm Component: Restriction over the value of the ACTION property 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, 19 Sep 2006 14:32:36 -0000 According to section 4.8.6.1 Action of RFC 2445, the ACTION property can take the following values: > actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" > / iana-token / x-name On the other hand, section 4.6.6 Alarm Component restricts the values that the ACTION property can take when used in a VALARM component to the following: AUDIO, DISPLAY, EMAIL, and PROCEDURE. Check the last sentence of the following paragraph: > The "ACTION" property is used within the "VALARM" calendar component > to specify the type of action invoked when the alarm is triggered. > The "VALARM" properties provide enough information for a specific > action to be invoked. It is typically the responsibility of a > "Calendar User Agent" (CUA) to deliver the alarm in the specified > fashion. An "ACTION" property value of AUDIO specifies an alarm that > causes a sound to be played to alert the user; DISPLAY specifies an > alarm that causes a text message to be displayed to the user; EMAIL > specifies an alarm that causes an electronic email message to be > delivered to one or more email addresses; and PROCEDURE specifies an > alarm that causes a procedure to be executed. The "ACTION" property > MUST specify one and only one of these values. In my opinion, one should be allowed to specify an ACTION property with a "iana-token" or "x-name" value in a VALARM component. A vendor might want to use "x-name" values (or register iana-token) for alarms that should be delivered by SMS, XMPP, Fax, Voice, etc. Cheers, Bernard 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 EB1EA7FC49 for ; Tue, 19 Sep 2006 06:00:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DC1FE142287 for ; Tue, 19 Sep 2006 06:00:51 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31603-03 for ; Tue, 19 Sep 2006 06:00:50 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7AD22142278 for ; Tue, 19 Sep 2006 06:00:50 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8I0vhO7027486 for ; Tue, 19 Sep 2006 07:00:48 -0600 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2012478771158670820; Tue, 19 Sep 2006 07:00:20 -0600 Message-ID: <450FE9D6.90505@oracle.com> Date: Tue, 19 Sep 2006 09:00:06 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, UPPERCASE_25_50 X-Spam-Level: Subject: [Ietf-calsify] Section 4.8.5.4 Recurrence Rule: Allowed value type of DTSTART and DTEND 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, 19 Sep 2006 13:00:52 -0000 Section 4.3.5 Date-Time of RFC 2445 defines 3 forms for DATE-TIME values, that is: FORM #1: DATE WITH LOCAL TIME FORM #2: DATE WITH UTC TIME FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE In section 4.8.5.4 Recurrence Rule of RFC 2445 it says: > The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION" > property pair, specified within the iCalendar object defines the > first instance of the recurrence. When used with a recurrence rule, > the "DTSTART" and "DTEND" properties MUST be specified in local time > and the appropriate set of "VTIMEZONE" calendar components MUST be > included. For detail on the usage of the "VTIMEZONE" calendar > component, see the "VTIMEZONE" calendar component definition. My understanding is: - The DTSTART property in a STANDARD or DAYLIGHT sub-component of a VTIMEZONE component MUST be of FORM #1 (DATE WITH LOCAL TIME) [See section 4.6.5 Time Zone Component]; - The DTSTART property in a VEVENT, VTODO or VJOURNAL component MUST be either a DATE value or a DATE-TIME value of FORM #1 (DATE WITH LOCAL TIME) or FORM #3 (DATE WITH LOCAL TIME AND TIME ZONE REFERENCE). As such, the text should be clarified to specify that DTSTART and DTEND MUST be specified as a DATE or as a DATE-TIME of FORM #1 (DATE WITH LOCAL TIME) or FORM #3 (DATE WITH LOCAL TIME AND TIME ZONE REFERENCE). All that being said, I would like to point out that in section 4.4.2 Modify A Recurring Instance of RFC 2446 (iTIP) there is an example of a DTSTART value specified in FORM #2 (DATE WITH UTC TIME) used with a recurrence rule. My understanding is that this is not valid. Cheers, Bernard 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 AC7DF7FC39 for ; Tue, 19 Sep 2006 02:22:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9D0EC142287 for ; Tue, 19 Sep 2006 02:22:38 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07570-06 for ; Tue, 19 Sep 2006 02:22:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4A1D7142282 for ; Tue, 19 Sep 2006 02:22:37 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 19 Sep 2006 02:22:37 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8J9Majm031682 for ; Tue, 19 Sep 2006 02:22:36 -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 k8J9MaYp015712 for ; Tue, 19 Sep 2006 02:22:36 -0700 (PDT) Received: from [144.254.23.104] (dhcp-data-vlan10-23-104.cisco.com [144.254.23.104]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8J9CN8s014819 for ; Tue, 19 Sep 2006 02:12:24 -0700 Message-ID: <450FB6D6.6000601@cisco.com> Date: Tue, 19 Sep 2006 11:22:30 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1539; t=1158657757; x=1159521757; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Issue=201=3A=20new=20proposed=20text; X=v=3Dcisco.com=3B=20h=3D2gi79T+Cj+XKWHzxsRoogHFRMv8=3D; b=d8pxpIBIlgi7UjmYAGerYfCjEBo48ZXU8j+HF7U1U6wb5Jiww9IX1ZFyUTtlw1OG5C99xiUS gK23DfRO9PZzEQdjZiQercgC2vOkECOAw9S8ur17HCDDulSDcWLjabAH; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Issue 1: new proposed text 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, 19 Sep 2006 09:22:38 -0000 Having tried to understand the value of any change to the text, I have the following observations: * The concern is only for those who are attempting to read the calendar information in a text based mailer, and impacts approximately one glyph. This is a very limited constituency and of very limited impact. * The text ALREADY says that folding occur between any two characters. That means you should continue to emit legal UTF-8 if you are emitting UTF-8 at all. * However, my own (admittedly braindamaged) code implements folding at a very low level, as folding is one of the last operations to take place. * I suspect I'm not the only one who has written such brain damaged code. * After *unfolding* any potential damage should be undone. * The amount of code required to fold or unfold text is pretty darn minimal. * Much of it is already written. Hence, relaxing of folding is perhaps not advisable. I have two recommendations for textual changes to RFC 2445: 1. Delete the second sentence in the 2nd paragraph after the example in 4.1 as redundant (it says the exact same thing in the first paragraph); 2. Add a sentence as follows: "It is possible for very simple implementations to have improperly folded lines in the middle of UTF-8 characters. In such cases, implementations SHOULD unfold lines in such a way to properly restore the character. Eliot 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 43EC37FB5A for ; Fri, 15 Sep 2006 11:26:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 349F01422C5 for ; Fri, 15 Sep 2006 11:26:17 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11231-04 for ; Fri, 15 Sep 2006 11:26:15 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B5F321422C0 for ; Fri, 15 Sep 2006 11:26:15 -0700 (PDT) Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k8E2a3XC014171 for ; Fri, 15 Sep 2006 13:26:10 -0500 Received: from dhcp-montreal-17fl-utilca-10-156-42-213.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2003109351158344664; Fri, 15 Sep 2006 12:24:24 -0600 Message-ID: <450AEF92.90204@oracle.com> Date: Fri, 15 Sep 2006 14:23:14 -0400 From: Simon Pilette User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-calsify] Section 4.6.4 Free/Busy Component, bad example 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, 15 Sep 2006 18:26:17 -0000 In section 4.6.4 Free/Busy Component of RFC 2445, there is an example that makes use of the VALUE parameter on the FREEBUSY property: > FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, > 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M According to the ABNF specified in section 4.8.2.6 Free/Busy Time, the FREEBUSY property does not allow the VALUE parameter. The example should be fixed. Simon Pilette 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 041027FA13 for ; Fri, 15 Sep 2006 06:36:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E8EFB1422B7 for ; Fri, 15 Sep 2006 06:36: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 26945-10 for ; Fri, 15 Sep 2006 06:36:43 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 29FCA1422B6 for ; Fri, 15 Sep 2006 06:36:43 -0700 (PDT) Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k8FDaXvv029469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Sep 2006 09:36:36 -0400 Date: Fri, 15 Sep 2006 09:36:28 -0400 From: Cyrus Daboo To: Mark Paterson Subject: Re: [Ietf-calsify] Overlapping reschedule Message-ID: <63A6E991CC80D6C8DD995872@Cyrus-Daboo-G5.local> In-Reply-To: <450AA9DC.2070604@oracle.com> References: <450AA9DC.2070604@oracle.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=-2.8 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, 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, 15 Sep 2006 13:36:45 -0000 Hi Mark, --On September 15, 2006 9:25:48 AM -0400 Mark Paterson wrote: > 3) certainly seems like an interesting possibility. >> >> 3) Extend iTIP to allow the organizer to specify a list of UIDs of >> events that should be excluded from any busy time results returned in >> the reply. The organizer could then supply the original event UID and >> the attendees' clients would exclude that from busy. This would work >> for any attendee state and recurring meetings (though we would >> probably have to send UID + list of Recurrence-IDs to handle >> reschedule of exceptions). However it is an extension to iTIP. Having thought about this some more I realize that there is a security concern with this. At the very least the 'ignored UIDs' list must refer to components whose ORGANIZER property is the same as the ORGANIZER in the free-busy request. So the entity doing the free-busy lookup MUST check the ORGANIZER properties before ignoring an event. -- Cyrus Daboo 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 A72F97FA05 for ; Fri, 15 Sep 2006 06:27:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 990171422B3 for ; Fri, 15 Sep 2006 06:27: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 28859-05 for ; Fri, 15 Sep 2006 06:27:56 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 04A651422A4 for ; Fri, 15 Sep 2006 06:27:55 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k8EA3Sis029484; Fri, 15 Sep 2006 07:27:43 -0600 Received: from dhcp-montreal-18fl-utilca-10-156-45-91.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 2002888681158326753; Fri, 15 Sep 2006 07:25:53 -0600 Message-ID: <450AA9DC.2070604@oracle.com> Date: Fri, 15 Sep 2006 09:25:48 -0400 From: Mark Paterson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Overlapping reschedule References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 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, 15 Sep 2006 13:27:58 -0000 3) certainly seems like an interesting possibility. Cyrus Daboo wrote: > Hi folks, > Lets assume an organizer has booked an event with one or more > attendees for 12:00 pm to 1:00 pm. The organizer then wants to > reschedule that to 12:30 pm to 1:30 pm. If the organizer does an iTIP > VFREEBUSY REQUEST for the new time range the attendees will show up as > busy for the first half hour because of the existing booked event. > There are several solutions to this: > > 1) The organizer needs to 'subtract' the original event's time from > any busy time it gets back from the iTIP request (i.e. effectively > overriding when the attendees report as being busy). This seems > reasonable if the attendee had previous accepted the meeting (and had > not deliberately double-booked), but if they had not accepted it may > be wrong to do. This method would work for recurring events. > > 2) The organizer only issues the free-busy request for the second half > hour period of the new meeting. Well that would work in this case, but > if the new meeting had been 11 am - 2 pm (i.e. new time required both > before and after the original) then two requests would have to be > done. Plus it gets worse for recurring events. The same issue with > accepted attendees would apply. > > 3) Extend iTIP to allow the organizer to specify a list of UIDs of > events that should be excluded from any busy time results returned in > the reply. The organizer could then supply the original event UID and > the attendees' clients would exclude that from busy. This would work > for any attendee state and recurring meetings (though we would > probably have to send UID + list of Recurrence-IDs to handle > reschedule of exceptions). However it is an extension to iTIP. > > 4) Organizer first cancels the original meeting and then does free > busy lookup. This is not good as the cancel operation may require the > attendees' manual intervention to accept, whereas the free-busy lookup > may complete faster (c.f. CalDAV where free busy iTIP operations > execute immediately, whereas others require explicit acceptance from > the attendee). > > Any thoughts on this? > -- MARK PATERSON Product Manager, OCS Mobility Oracle Corporation - Server Technologies Phone: 514.905.8649 Mobile: 514.862.8505 mailto: mark.paterson@oracle.com http: www.oracle.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 64E607FAF0 for ; Thu, 14 Sep 2006 11:08:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 56B1D1422AF for ; Thu, 14 Sep 2006 11:08: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 25576-06 for ; Thu, 14 Sep 2006 11:08:39 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 738E41422AC for ; Thu, 14 Sep 2006 11:08:39 -0700 (PDT) Received: from [17.101.34.128] ([17.101.34.128]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k8EI8Wn8026395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Sep 2006 14:08:35 -0400 Date: Thu, 14 Sep 2006 14:08:27 -0400 From: Cyrus Daboo To: Ietf-calsify@osafoundation.org Message-ID: 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=-2.8 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: Subject: [Ietf-calsify] Overlapping reschedule 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, 14 Sep 2006 18:08:41 -0000 Hi folks, Lets assume an organizer has booked an event with one or more attendees for 12:00 pm to 1:00 pm. The organizer then wants to reschedule that to 12:30 pm to 1:30 pm. If the organizer does an iTIP VFREEBUSY REQUEST for the new time range the attendees will show up as busy for the first half hour because of the existing booked event. There are several solutions to this: 1) The organizer needs to 'subtract' the original event's time from any busy time it gets back from the iTIP request (i.e. effectively overriding when the attendees report as being busy). This seems reasonable if the attendee had previous accepted the meeting (and had not deliberately double-booked), but if they had not accepted it may be wrong to do. This method would work for recurring events. 2) The organizer only issues the free-busy request for the second half hour period of the new meeting. Well that would work in this case, but if the new meeting had been 11 am - 2 pm (i.e. new time required both before and after the original) then two requests would have to be done. Plus it gets worse for recurring events. The same issue with accepted attendees would apply. 3) Extend iTIP to allow the organizer to specify a list of UIDs of events that should be excluded from any busy time results returned in the reply. The organizer could then supply the original event UID and the attendees' clients would exclude that from busy. This would work for any attendee state and recurring meetings (though we would probably have to send UID + list of Recurrence-IDs to handle reschedule of exceptions). However it is an extension to iTIP. 4) Organizer first cancels the original meeting and then does free busy lookup. This is not good as the cancel operation may require the attendees' manual intervention to accept, whereas the free-busy lookup may complete faster (c.f. CalDAV where free busy iTIP operations execute immediately, whereas others require explicit acceptance from the attendee). Any thoughts on this? -- Cyrus Daboo 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 8D8947F8DA for ; Wed, 13 Sep 2006 22:48:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F5001422AF for ; Wed, 13 Sep 2006 22:48:32 -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 18887-10 for ; Wed, 13 Sep 2006 22:48:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1CEA81422AA for ; Wed, 13 Sep 2006 22:48:31 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 13 Sep 2006 22:48:31 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8E5mU4H020722; Wed, 13 Sep 2006 22:48:30 -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 k8E5mU1E027500; Wed, 13 Sep 2006 22:48:30 -0700 (PDT) Received: from [212.254.247.5] (rtp-vpn2-144.cisco.com [10.82.240.144]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8E5ca9U009908; Wed, 13 Sep 2006 22:38:37 -0700 Message-ID: <4508ED2C.1000201@cisco.com> Date: Thu, 14 Sep 2006 07:48:28 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Michiel van Leeuwen Subject: Re: [Ietf-calsify] Re: Propose to close issues 37, 38, 39 References: <450141D2.9040601@cisco.com> In-Reply-To: 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=462; t=1158212910; x=1159076910; c=relaxed/simple; s=sjdkim1002; 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=20Propose=20to=20close=20issues=2037, =203 8,=2039; X=v=3Dcisco.com=3B=20h=3DXv7Mcjw24SAVzn9Njcxbm9IeJfo=3D; b=PfuQ+SYpMJkj5hSghElN6ER2DxSbiQoZPzbEQHzYI4RNqq59bnh+SvqySzlW+oOCVMFA1pFy 1Q8fD2N4VCUjYg3p9PzNt+Rj8QBdYsTFFPeiv1+RXyyJcSg4lTmjcE2x; 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, 14 Sep 2006 05:48:32 -0000 Michiel van Leeuwen wrote: > Eliot Lear wrote: >> 4.6.1 Event Component: eventprop >> >> >> > eventprop = *( >> > >> > ; the following are both REQUIRED, >> > ; but MUST NOT occur more than once >> > >> > dtstamp / dtstart / uid / > > The text speaks of 'both', while there are three items. Shouldn't that > be 'all three' then? > > Michiel Yes, this seems to be more appropriate. Eliot 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 7393C7FA77 for ; Wed, 13 Sep 2006 16:38:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 641FF1422AA for ; Wed, 13 Sep 2006 16:38: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 08589-06 for ; Wed, 13 Sep 2006 16:38:22 -0700 (PDT) Received: from bycast.com (bycast.com [207.61.255.252]) by laweleka.osafoundation.org (Postfix) with ESMTP id A0D0D1422AC for ; Wed, 13 Sep 2006 16:38:21 -0700 (PDT) Received: from [192.168.110.126] (HELO localhost.localdomain) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTP id 1072916 for ietf-calsify@osafoundation.org; Wed, 13 Sep 2006 16:38:18 -0700 Received: by localhost.localdomain (Postfix, from userid 2122) id 134A0510285; Wed, 13 Sep 2006 16:38:18 -0700 (PDT) Date: Wed, 13 Sep 2006 16:38:18 -0700 From: Sam Roberts To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: Propose to close issues 37, 38, 39 Message-ID: <20060913233817.GA4535@pebble> References: <450141D2.9040601@cisco.com> <450873C1.1080105@WEIJax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450873C1.1080105@WEIJax.com> User-Agent: Mutt/1.5.11 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, 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: Wed, 13 Sep 2006 23:38:23 -0000 On Wed, Sep 13, 2006 at 05:10:25PM -0400, Sandy Wills wrote: > >> 4.6.1 Event Component: eventprop > >> > >> > eventprop = *( > >> > > >> > ; the following are both REQUIRED, > >> > ; but MUST NOT occur more than once > >> > > >> > dtstamp / dtstart / uid / > The "both" refers to having two requirements, not to how many items are > on the list. I thought the phrasing was a bit confusing, too. It might even be ungrammatical, usually people say "both this AND that". Anyhow, the "both" and the "but" are unncessary, may I suggest: "the following are REQUIRED and MUST NOT occur more than once" This kind of text show up a lot, isn't it the same wording everywhere? Cheers, Sam 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 489E57FB26 for ; Wed, 13 Sep 2006 14:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3AC141422C7 for ; Wed, 13 Sep 2006 14:10: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 01031-03 for ; Wed, 13 Sep 2006 14:10:34 -0700 (PDT) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by laweleka.osafoundation.org (Postfix) with ESMTP id C7B0F1422CE for ; Wed, 13 Sep 2006 14:10:34 -0700 (PDT) Received: from WEIJax.com ([71.251.116.101]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J5J00FKSUT9WWO8@vms040.mailsrvcs.net> for ietf-calsify@osafoundation.org; Wed, 13 Sep 2006 16:10:26 -0500 (CDT) Date: Wed, 13 Sep 2006 17:10:25 -0400 From: Sandy Wills Subject: Re: [Ietf-calsify] Re: Propose to close issues 37, 38, 39 In-reply-to: To: ietf-calsify@osafoundation.org Message-id: <450873C1.1080105@WEIJax.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <450141D2.9040601@cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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: Michiel van Leeuwen 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, 13 Sep 2006 21:10:36 -0000 Michiel van Leeuwen wrote: > Eliot Lear wrote: > >> 4.6.1 Event Component: eventprop >> >> >> > eventprop = *( >> > >> > ; the following are both REQUIRED, >> > ; but MUST NOT occur more than once >> > >> > dtstamp / dtstart / uid / > > > The text speaks of 'both', while there are three items. Shouldn't that > be 'all three' then? The "both" refers to having two requirements, not to how many items are on the list. The following list (no matter how long) has both of these requirements: A) all items in the list are REQUIRED, and B) each item MUST NOT occur more than once. List items: dtstamp, dtstart, uid -- Unable to locate coffee. Operator halted. 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 150267FC9C for ; Wed, 13 Sep 2006 13:58:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 06ADD1422CD for ; Wed, 13 Sep 2006 13: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 02609-07 for ; Wed, 13 Sep 2006 13:57:59 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 171481422C7 for ; Wed, 13 Sep 2006 13:57:59 -0700 (PDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GNbng-0005KN-GD for ietf-calsify@osafoundation.org; Wed, 13 Sep 2006 22:57:40 +0200 Received: from ip5451a2fe.direct-adsl.nl ([84.81.162.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 22:57:40 +0200 Received: from mvl by ip5451a2fe.direct-adsl.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Sep 2006 22:57:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen Date: Wed, 13 Sep 2006 22:57:16 +0200 Lines: 15 Message-ID: References: <450141D2.9040601@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip5451a2fe.direct-adsl.nl User-Agent: Thunderbird 2.0a1 (X11/20060419) In-Reply-To: <450141D2.9040601@cisco.com> Sender: news 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: Propose to close issues 37, 38, 39 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, 13 Sep 2006 20:58:01 -0000 Eliot Lear wrote: > 4.6.1 Event Component: eventprop > > > > eventprop = *( > > > > ; the following are both REQUIRED, > > ; but MUST NOT occur more than once > > > > dtstamp / dtstart / uid / The text speaks of 'both', while there are three items. Shouldn't that be 'all three' then? Michiel 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 239027F8C8 for ; Tue, 12 Sep 2006 07:46:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F2C7014228D for ; Tue, 12 Sep 2006 07:46: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 17720-07 for ; Tue, 12 Sep 2006 07:46:57 -0700 (PDT) Received: from mgw-ext12.nokia.com (mgw-ext12.nokia.com [131.228.20.171]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4CAD814227E for ; Tue, 12 Sep 2006 07:46:57 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k8CEkmva004660; Tue, 12 Sep 2006 17:46:54 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Sep 2006 17:46:50 +0300 Received: from esdhcp03667.research.nokia.com ([172.21.36.67]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Sep 2006 17:46:50 +0300 Subject: Proposal for closing issue #4 (was: Re: [Ietf-calsify] RFC2445 Correction in rrule examples) From: Aki Niemi To: ext Sam Roberts In-Reply-To: <20060530044633.GA790@ensemble.local> References: <200605291418.44271.lists@block-online.eu> <20060530044633.GA790@ensemble.local> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Tue, 12 Sep 2006 17:46:50 +0300 Message-Id: <1158072410.26676.42.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Sep 2006 14:46:50.0901 (UTC) FILETIME=[4800E450:01C6D67A] 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, UPPERCASE_25_50 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: Tue, 12 Sep 2006 14:46:59 -0000 ma, 2006-05-29 kello 21:46 -0700, ext Sam Roberts kirjoitti: > I found this in my notes: > > Everyday in January, for 3 years: > > DTSTART;TZID=US-Eastern:19980101T090000 > RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; > BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA > or > RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 > > ==> (1998 9:00 AM EDT)January 1-31 > (1999 9:00 AM EDT)January 1-31 > (2000 9:00 AM EDT)January 1-31 > > !! (2000 9:00 AM EDT)January 31 is AFTER the until day (2000 9:00 am UTC) January 31 BTW, isn't EDT only supposed to be used during summer? AFAICS, this example needs to be changed so that either the DTSTART or the UNTIL needs to be adjusted, or the DTSTART be represented in UTC as well. Let me take a stab at this: DTSTART;TZID=US-Eastern:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 ==> (1998 9:00 AM EST)January 1-31 (1999 9:00 AM EST)January 1-31 (2000 9:00 AM EST)January 1-31 With this, I'd like to propose closing this issue (#4 in the tracker). Comments? Cheers, Aki -- Aki Niemi Nokia Research Center 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 0F95B7F89D for ; Tue, 12 Sep 2006 03:54:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0184D14225C for ; Tue, 12 Sep 2006 03:54: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 31178-10 for ; Tue, 12 Sep 2006 03:54:19 -0700 (PDT) Received: from mgw-ext14.nokia.com (mgw-ext14.nokia.com [131.228.20.173]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2BB2414225A for ; Tue, 12 Sep 2006 03:54:18 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k8CAsCno019409; Tue, 12 Sep 2006 13:54:13 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Sep 2006 13:54:12 +0300 Received: from esdhcp03667.research.nokia.com ([172.21.36.67]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Sep 2006 13:54:12 +0300 Subject: Proposal to close issue #2 (was: Re: [Ietf-calsify] rfc 2445 - typo correction(s)) From: Aki Niemi To: ext Bernard Desruisseaux In-Reply-To: <44F47A11.1010302@oracle.com> References: <447612E1.1070504@softdesign.net.nz> <44F47A11.1010302@oracle.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Tue, 12 Sep 2006 13:54:12 +0300 Message-Id: <1158058453.26676.10.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Sep 2006 10:54:12.0531 (UTC) FILETIME=[C82AA830:01C6D659] 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: Tue, 12 Sep 2006 10:54:21 -0000 I believe we can close this issue (#2 in the tracker). Cheers, Aki ti, 2006-08-29 kello 13:32 -0400, ext Bernard Desruisseaux kirjoitti: > +1 > > Andrew N Dowden wrote: > > 4.8.6.3 Trigger > > > > If the trigger is set relative to START, then the "DTSTART" property > > MUST be present in the associated "VEVENT" or "VTODO" calendar > > component. If an alarm is specified for an event with the trigger set > > relative to the END, then the "DTEND" property or the "DSTART" and > > "DURATION' properties MUST be present in the associated "VEVENT" > > calendar component. If the alarm is specified for a to-do with a > > trigger set relative to the END, then either the "DUE" property or > > the "DSTART" and "DURATION' properties MUST be present in the > > associated "VTODO" calendar component. > > > > CORRECTION: replace DSTART with DTSTART (lines 4 & 8) > > > > PS. have enjoyed recent discussions, more (contentious) comments / > > suggestions to follow .. > > > _______________________________________________ > 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 0FF427FBDF for ; Mon, 11 Sep 2006 17:19:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 002FB142292 for ; Mon, 11 Sep 2006 17:19: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 22509-08 for ; Mon, 11 Sep 2006 17:19:05 -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 803B514227E for ; Mon, 11 Sep 2006 17:19:05 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8C0J2DJ000938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Sep 2006 17:19:02 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8C0J1Qf006503 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Sep 2006 17:19:01 -0700 Date: Mon, 11 Sep 2006 17:21:06 -0700 (Pacific Daylight Time) From: Mark Crispin To: Oliver Block Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <200609120215.59926.lists@block-online.eu> Message-ID: References: <200608151454.51877.lists@block-online.eu> <20060911163847.GA443@ensemble.local> <200609120215.59926.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-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.11.165944 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: 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: Tue, 12 Sep 2006 00:19:07 -0000 On Tue, 12 Sep 2006, Oliver Block wrote: > Am Montag, 11. September 2006 18:46 schrieb Mark Crispin: >> This is a matter under discussion. >> The text is in a [] pair since its >> inclusion depends upon the decision of the WG. > I would forget that. You can convert from charsets (e.g. ISO-8859) to UTF-8 > with acceptable effort. But adding the part in [] would multiply the effort. Huh? Any conversion from ISO 8859 to UTF-8 would not have any combining characters, since all ISO 8859 characters have precomposed equivalents in UTF-8. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. 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 192D87FBC4 for ; Mon, 11 Sep 2006 17:16:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 06C23142292 for ; Mon, 11 Sep 2006 17:16:38 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03996-01 for ; Mon, 11 Sep 2006 17:16:35 -0700 (PDT) Received: from natlemon.rzone.de (natlemon.rzone.de [81.169.145.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F44A14227E for ; Mon, 11 Sep 2006 17:16:35 -0700 (PDT) Received: from ollie.block.home (dslb-084-063-163-141.pools.arcor-ip.net [84.63.163.141]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8C0GWPv021316 for ; Tue, 12 Sep 2006 02:16:33 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 Date: Tue, 12 Sep 2006 02:15:59 +0200 User-Agent: KMail/1.7.1 References: <200608151454.51877.lists@block-online.eu> <20060911163847.GA443@ensemble.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609120215.59926.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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2006 00:16:38 -0000 Am Montag, 11. September 2006 18:46 schrieb Mark Crispin: > This is a matter under discussion. > The text is in a [] pair since its > inclusion depends upon the decision of the WG. I would forget that. You can convert from charsets (e.g. ISO-8859) to UTF-8 with acceptable effort. But adding the part in [] would multiply the effort. iCalendar requires valid UTF-8 and with the two texts that were proposed, it makes that clear enough. I would even prefer Bernards Version with 'charset' instead of 'character set' because it leaves some terms out, which make it better readable in my view. Marks Version is ahead of the times:) so it should be kept for the next iCal-WG. Or in other words: If you want to introduce new terms to this RFC, you should do with more than five sentences. That's what I think. Best Regards, Oliver -- Leben ist mehr ... http://www.nak-nrw.de/p_6_4.html 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 B51C37FC01 for ; Mon, 11 Sep 2006 13:04:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A5755142290 for ; Mon, 11 Sep 2006 13:04: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 17050-07 for ; Mon, 11 Sep 2006 13:04:40 -0700 (PDT) Received: from bycast.com (bycast.com [207.61.255.252]) by laweleka.osafoundation.org (Postfix) with ESMTP id 39BAB14225B for ; Mon, 11 Sep 2006 13:04:40 -0700 (PDT) Received: from [192.168.110.126] (HELO localhost.localdomain) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTP id 1064109 for ietf-calsify@osafoundation.org; Mon, 11 Sep 2006 13:04:39 -0700 Received: by localhost.localdomain (Postfix, from userid 2122) id 8234B51038C; Mon, 11 Sep 2006 13:04:39 -0700 (PDT) Date: Mon, 11 Sep 2006 13:04:39 -0700 From: Sam Roberts To: ietf-calsify@osafoundation.org Message-ID: <20060911200439.GE26643@pebble> References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> <200609021229.26322.lists@block-online.eu> <20060911163847.GA443@ensemble.local> <20060911192007.GA18081@pebble> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20060911192007.GA18081@pebble> User-Agent: Mutt/1.5.11 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, DNS_FROM_RFC_POST, TW_XX X-Spam-Level: Subject: [Ietf-calsify] Re: [Issue 1] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 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, 11 Sep 2006 20:04:41 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 11, 2006 at 12:20:07PM -0700, Sam Roberts wrote: > characters... or does it? Would a sequence of > > CAPITAL-A, LINE-FEED, SPACE, COMBINING TILDE, ... Oops, attached utf-8, but don't know if attachments make it through to the list. % xxd __.out 0000000: 410a 20cc 802e 2e2e 0a A. ...... xxd -r will get it back. --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="__.out" Content-Transfer-Encoding: 8bit A Ì€... --+QahgC5+KEYLbs62-- 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 768CB7F9C6 for ; Mon, 11 Sep 2006 12:27:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 677AA14228D for ; Mon, 11 Sep 2006 12:27: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 28145-01 for ; Mon, 11 Sep 2006 12:27:44 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CC496142262 for ; Mon, 11 Sep 2006 12:27:44 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8BJRgQR013350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2006 12:27:43 -0700 Received: from [129.46.76.39] (valinor.qualcomm.com [129.46.76.39]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8BJRajk006589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Sep 2006 12:27:42 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200609081225.37154.reinhold@kainhofer.com> References: <20060907233353.CDEC4142276@laweleka.osafoundation.org> <200609081225.37154.reinhold@kainhofer.com> User-Agent: eudora6.3a0carbon-0822061540 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Mon, 11 Sep 2006 12:21:15 -0700 To: Reinhold Kainhofer From: John W Noerenberg II Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar) Content-Type: multipart/alternative; boundary="============_-1054119635==_ma============" 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, HTML_20_30, HTML_MESSAGE, SUBJ_HAS_SPACES 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: Mon, 11 Sep 2006 19:27:45 -0000 --============_-1054119635==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:25 PM +0200 9/8/06, Reinhold Kainhofer wrote: >If you now tomorrow publish that event to some other group of people or so >(i.e. send a mail with METHOD:PUBLISH), the calendar that you send out will >have the above CREATED and DATE-MODIFIED (provided that you didn't modify it >meanwhile in the calendar store), but as that particular invitation will be >created tomorrow, it will have >DTSTAMP:20060910... > >So, these three settings are in deed different. The CREATED will never change >once the event is by the organizer, the DATE-MODIFIED is only changed when >you modify the event, and the DTSTAMP is the time when you create that >particular invitation or export from the calendar server. I'll grant it's possible for DTSTAMP and CREATED to differ. I've just never seen it. :-) The essential question I'm asking, are both attributes necessary? I can see an argument for DTSTAMP (despite the way I began this thread), as it's useful for determining the order in which changes to an event should be applied. However, no other attribute depends on CREATED. In the interest of simplifying the protocol, 4.8.7.1 should be eliminated (and references to it, of course). However I'd be happy if the text in 4.8.7.1 where changed from: Conformance: The property can be specified once in "VEVENT", "VTODO" or "VJOURNAL" calendar components. to Conformance: The property MAY be specified once in "VEVENT", "VTODO" or "VJOURNAL" calendar components. Absence of this parameter MUST NOT cause a CUA or CS (Calendar Service) to reject the calendar component specification. That would make it clear the parameter is optional. -- john noerenberg ---------------------------------------------------------------------- It is treason to sacrifice love of truth, intellectual honesty, loyalty to the laws and methods of the mind, to any other interests, including those of one's country. -- Herman Hesse, The Glass Bead Game, 1943 ---------------------------------------------------------------------- --============_-1054119635==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP b
At 12:25 PM +0200 9/8/06, Reinhold Kainhofer wrote:
If you now tomorrow publish that event to some other group of people or so
(i.e. send a mail with METHOD:PUBLISH), the calendar that you send out will
have the above CREATED and DATE-MODIFIED (provided that you didn't modify it
meanwhile in the calendar store), but as that particular invitation will be
created tomorrow, it will have
DTSTAMP:20060910...
So, these three settings are in deed different. The CREATED will never change
once the event is by the organizer, the DATE-MODIFIED is only changed when
you modify the event, and the DTSTAMP is the time when you create that
particular invitation or export from the calendar server.

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

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

to

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

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

john noerenberg
  ----------------------------------------------------------------------
  It is treason to sacrifice love of truth, intellectual honesty,
  loyalty to the laws and methods of the mind, to any other interests,
  including those of one's country.
  -- Herman Hesse, The Glass Bead Game, 1943
  ----------------------------------------------------------------------
--============_-1054119635==_ma============-- 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 9BC657FC0E for ; Mon, 11 Sep 2006 12:20:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C25B142288 for ; Mon, 11 Sep 2006 12:20: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 14453-08 for ; Mon, 11 Sep 2006 12:20:10 -0700 (PDT) Received: from bycast.com (bycast.com [207.61.255.252]) by laweleka.osafoundation.org (Postfix) with ESMTP id 906B814227E for ; Mon, 11 Sep 2006 12:20:09 -0700 (PDT) Received: from [192.168.110.126] (HELO localhost.localdomain) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTP id 1063768 for ietf-calsify@osafoundation.org; Mon, 11 Sep 2006 12:20:07 -0700 Received: by localhost.localdomain (Postfix, from userid 2122) id A1DA651038C; Mon, 11 Sep 2006 12:20:07 -0700 (PDT) Date: Mon, 11 Sep 2006 12:20:07 -0700 From: Sam Roberts To: ietf-calsify@osafoundation.org Message-ID: <20060911192007.GA18081@pebble> References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> <200609021229.26322.lists@block-online.eu> <20060911163847.GA443@ensemble.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 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, DNS_FROM_RFC_POST X-Spam-Level: Subject: [Ietf-calsify] Re: [Issue 1] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 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, 11 Sep 2006 19:20:11 -0000 On Mon, Sep 11, 2006 at 09:46:38AM -0700, Mark Crispin wrote: > On Mon, 11 Sep 2006, Sam Roberts wrote: > >Quoting lists@block-online.eu, on Sat, Sep 02, 2006 at 12:29:25PM +0200: > >>Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin: > >>>Therefore, a better wording is: > >>>---------------------------------------------------------------------- > >>>Folded lines MUST be well-formed according to the character set specified > >>>for the iCalendar object. Folding MUST NOT occur between octets that > >>>define a single codepoint in a character set that uses multiple octets to > >>>define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian > >>>character sets). [Furthermore, folding MUST NOT occur prior to a > >>>codepoints that defines a combining character.] This may require > >>>folding a line at less than the recommended 75 octet limit. > >>>---------------------------------------------------------------------- > >Is the "[Furthermore,...combining character.]" text supposed to be part > >of the the wording? > > This is a matter under discussion. The text is in a [] pair since its > inclusion depends upon the decision of the WG. Ok. > >It appears that there are combining characters defined in many blocks of > >unicode characters. > > http://www.unicode.org/faq/char_combmark.html > >How do I determine that a code point defines a combining character? Is > >there a list of such code-points? > > You don't determine combining character by codepoint value. You determine > it by the codepoint's Canonical Combining Class value, as defined in the > UnicodeData.txt file. Characters with a Canonical Combining Class value > of 0 are not combining characters. Thanks. An application would probably not include the 1038607 byte UnicodeData.txt file [1], it could just have knowledge of the current (418, by my count) combining characters. Would that application then become non-conformant with the MUST NOT under discussion when a new combining character is added to Unicode and the application isn't updated? Or would we pin iCalendar to a particular Unicode version? (or whatever they call the currently defined codepoints and combining classes, if they don't call it a "unicode version") I think its worth clarifying why folding in the middle of multi-byte sequences for either a "character" or a "grapheme" may not be desireable. As I understand it, one reason that has been mentioned is if the data is folded it can no longer be called valid "utf-8" (for example). This doesn't matter to an iCalendar application which will unfold before processing, but would matter to, for example, a mail application which didn't know how to process the calendar, and was trying to display it to the user as plain text. I think the bigger issue is that in order to unfold, you need to find the line endings. The line endings themselves are encoded as a "character", possibly multi-byte (in UTF-16, for example). So, a certain amount of well-formedness is necessary in order to unfold a calendar. If a long line in UCS-16 was broken in the middle of a UTF-16 codepoint, and a LINE-FEED, SPACE was added in UTF-16, it would probably be difficult or impossible to parse. The necessity of being well-formed enough to unfold the data doesn't seem to mean that we need to forbid folding between combining characters... or does it? Would a sequence of CAPITAL-A, LINE-FEED, SPACE, COMBINING TILDE, ... make the SPACE appear to be a "space with a tilde over it" (!) with some programming languages, thus making it not possible to find the LINE-FEED, SPACE sequence which needs to be removed during unfolding? In the languages I work in, finding "codepoints" is no trouble, and wrapping between codepoints that are part of combining sequences is no trouble, and the wrapped calendar might have a few "odd" looking bits when sequences like my example above are viewed in a unicode supporting terminal (see attached), but thats not a problem for unfolding. Are there iCalendar implementations out there (real or suspected) that will fail to interoperate when lines are wrapped between combining codepoints? If the goal here is to tighten up the spec to improve interop, and its not an interop issue, I'd say document that: - line wrapping SHOULD (MUST?) occur before XX bytes, - wrapping MUST NOT break a codepoint (if the character set being used represents a code-point as more than one byte), and - that wrapping MAY occur between combining codepoints, and move on. Also, unless I misunderstand, pathological unicode (or maybe not pathological, just a complex musical score, they use combining characters a lot) could contain a grapheme consisting of an abitrarily long sequence of codepoints, so a MUST NOT break between combining characters rule might be mutually exclusive with a rule that lines MUST NOT be over a particular byte-length. Cheers, Sam [1] http://www.unicode.org/Public/UNIDATA/UnicodeData.txt 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 6216F7FBCF for ; Mon, 11 Sep 2006 09:46:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 546CF142289 for ; Mon, 11 Sep 2006 09:46:43 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05806-03 for ; Mon, 11 Sep 2006 09:46:41 -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 B8485142269 for ; Mon, 11 Sep 2006 09:46:41 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8BGkeRx005760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Sep 2006 09:46:41 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8BGkdnb010553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Sep 2006 09:46:40 -0700 Date: Mon, 11 Sep 2006 09:46:38 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Sam Roberts Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <20060911163847.GA443@ensemble.local> Message-ID: References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> <200609021229.26322.lists@block-online.eu> <20060911163847.GA443@ensemble.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.11.92943 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, __STOCK_CRUFT 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: 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: Mon, 11 Sep 2006 16:46:43 -0000 On Mon, 11 Sep 2006, Sam Roberts wrote: > Quoting lists@block-online.eu, on Sat, Sep 02, 2006 at 12:29:25PM +0200: >> Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin: >>> Therefore, a better wording is: >>> ---------------------------------------------------------------------- >>> Folded lines MUST be well-formed according to the character set specified >>> for the iCalendar object. Folding MUST NOT occur between octets that >>> define a single codepoint in a character set that uses multiple octets to >>> define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian >>> character sets). [Furthermore, folding MUST NOT occur prior to a >>> codepoints that defines a combining character.] This may require >>> folding a line at less than the recommended 75 octet limit. >>> ---------------------------------------------------------------------- > Is the "[Furthermore,...combining character.]" text supposed to be part > of the the wording? This is a matter under discussion. The text is in a [] pair since its inclusion depends upon the decision of the WG. > It appears that there are combining characters defined in many blocks of > unicode characters. > http://www.unicode.org/faq/char_combmark.html > How do I determine that a code point defines a combining character? Is > there a list of such code-points? You don't determine combining character by codepoint value. You determine it by the codepoint's Canonical Combining Class value, as defined in the UnicodeData.txt file. Characters with a Canonical Combining Class value of 0 are not combining characters. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. 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 D95667F79E for ; Mon, 11 Sep 2006 09:39:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CAD4C14224D for ; Mon, 11 Sep 2006 09:39: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 32631-08 for ; Mon, 11 Sep 2006 09:39:31 -0700 (PDT) Received: from defout.telus.net (defout.telus.net [199.185.220.240]) by laweleka.osafoundation.org (Postfix) with ESMTP id 238BB14224C for ; Mon, 11 Sep 2006 09:39:31 -0700 (PDT) Received: from priv-edtnaa05.telusplanet.net ([154.20.166.96]) by priv-edtnes87.telusplanet.net (InterMail vM.7.05.01.01 201-2174-106-103-20060222) with ESMTP id <20060911163930.QEMD16555.priv-edtnes87.telusplanet.net@priv-edtnaa05.telusplanet.net> for ; Mon, 11 Sep 2006 10:39:30 -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 4BSN9SX2MX for ; Mon, 11 Sep 2006 10:39:25 -0600 (MDT) Received: by ensemble.local (Postfix, from userid 501) id A383559F537; Mon, 11 Sep 2006 09:38:48 -0700 (PDT) Date: Mon, 11 Sep 2006 09:38:48 -0700 From: Sam Roberts To: ietf-calsify@osafoundation.org Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 Message-ID: <20060911163847.GA443@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> <200609021229.26322.lists@block-online.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609021229.26322.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 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, 11 Sep 2006 16:39:34 -0000 Quoting lists@block-online.eu, on Sat, Sep 02, 2006 at 12:29:25PM +0200: > Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin: > > Therefore, a better wording is: > > ---------------------------------------------------------------------- > > Folded lines MUST be well-formed according to the character set specified > > for the iCalendar object. Folding MUST NOT occur between octets that > > define a single codepoint in a character set that uses multiple octets to > > define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian > > character sets). [Furthermore, folding MUST NOT occur prior to a > > codepoints that defines a combining character.] This may require > > folding a line at less than the recommended 75 octet limit. > > ---------------------------------------------------------------------- Is the "[Furthermore,...combining character.]" text supposed to be part of the the wording? It appears that there are combining characters defined in many blocks of unicode characters. http://www.unicode.org/faq/char_combmark.html How do I determine that a code point defines a combining character? Is there a list of such code-points? Cheers, Sam 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 D6EA77FB1E for ; Fri, 8 Sep 2006 09:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C84E4142289 for ; Fri, 8 Sep 2006 09:45: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 23458-04 for ; Fri, 8 Sep 2006 09:45:49 -0700 (PDT) Received: from bycast.com (bycast.com [207.61.255.252]) by laweleka.osafoundation.org (Postfix) with ESMTP id B11E2142286 for ; Fri, 8 Sep 2006 09:45:48 -0700 (PDT) Received: from [192.168.110.126] (HELO localhost.localdomain) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTP id 1058619 for ietf-calsify@osafoundation.org; Fri, 08 Sep 2006 09:45:46 -0700 Received: by localhost.localdomain (Postfix, from userid 2122) id 778B05102CF; Fri, 8 Sep 2006 09:45:46 -0700 (PDT) Date: Fri, 8 Sep 2006 09:45:46 -0700 From: Sam Roberts To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Propose to close issue 36 - X-Name / bilateral agreements Message-ID: <20060908164546.GA1369@pebble> References: <450142B0.5020208@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450142B0.5020208@cisco.com> User-Agent: Mutt/1.5.11 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, 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, 08 Sep 2006 16:45:51 -0000 On Fri, Sep 08, 2006 at 12:15:12PM +0200, Eliot Lear wrote: > No consensus for change as of now. > > Barring more discussion, the text will remain unchanged, without > reference to bilateral agreements. What X- fields mean and whether to allow them was beat to a bloody death during rfc2822, but they got rid of X- fields, so iCal can't copy their text! I don't want to keep the issue open if the consensus is that te text is fine, but I think including recommendations on use of a feature is helpful for interoperability, so can I propose: Vendor-defined names may appear in iCalendar by using a naming pattern guaranteed not to conflict with any names that may be standardized in the future. There is no registry for vendorid, so there is no guarantee names defined by one vendor won't conflict with names defined by another. I think that describes why it's here, and you/we could perhaps add some guidance: Vendors SHOULD NOT use vendor-defined names in iTIP, it discourages inter-operability. If a vendor finds it necessary to extend iCal with vendor-defined names, it is recommended to submit a to the to standardize this usage with a non-vendor defined name. Some vendors use iCalendar as a internal storage format, and vendor-defined names are useful in this context, but SHOULD be removed before exchanging the calendars with other implementations. I think the above is the "well-known understanding" of X- fields, if the list agrees, I'd like to see it written down. I don't like the use of "vendor", btw, what if the implementation isn't vended? :-) How about s/vendor/implementation/g? Cheers, Sam > Eliot > > 36 > X-name > > > > x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > > ; Reserved for non-standard names. Can be used by bilateral > > ; agreement. > > > No consensus on what bilateral means in this context. 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 E9F157FADF for ; Fri, 8 Sep 2006 04:20:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DAA7214228C for ; Fri, 8 Sep 2006 04:20: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 16244-10 for ; Fri, 8 Sep 2006 04:20:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7DE78142289 for ; Fri, 8 Sep 2006 04:20:24 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2006 04:20:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88BKOIr017811 for ; Fri, 8 Sep 2006 04:20:24 -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 k88BKOQV020540 for ; Fri, 8 Sep 2006 04:20:24 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4479.cisco.com [10.61.81.126]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k88BApAg018403 for ; Fri, 8 Sep 2006 04:10:52 -0700 Message-ID: <450151F3.5070106@cisco.com> Date: Fri, 08 Sep 2006 13:20:19 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: multipart/alternative; boundary="------------020200060709050909030508" Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( 60 extraneous bytes; sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1674; t=1157714424; x=1158578424; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Propose=20Close=20Issue=2035=3A=204.2.10=20language=20tag; X=v=3Dcisco.com=3B=20h=3DQNFco8nu2o71FroWo/BRjCuUDHM=3D; b=d3U9pDz1Ih0lAzjz1bAB33CophDxPumuqYzHeAocC4k9hlgt2MFWj2ydASzSAu6qT+xLMBG5 DLqn8a5qX4k086BQPQzr8ZN071z6wVTvdkcqWg7UqgwnlrYACcVBVEfX; 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, HTML_TAG_EXIST_TBODY, HTML_TITLE_EMPTY, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Propose Close Issue 35: 4.2.10 language tag 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, 08 Sep 2006 11:20:25 -0000 This is a multi-part message in MIME format. --------------020200060709050909030508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This issue has proposed text and there has been no objection. 35 Section 4.2.10 language / language property Proposed new text: > Description: The parameter identifies the language of the text in > the property or property parameter value. The value of the "language" > property parameter is that defined in [RFC 1766]. possible consensus. need to update RFC reference. More discussion needed. --------------020200060709050909030508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This issue has proposed text and there has been no objection.


35
 Section 4.2.10 language / language property
 
Proposed new text:

 > Description: The parameter identifies the language of the text in
 > the property or property parameter value. The value of the "language"
 > property parameter is that defined in [RFC 1766].
 possible consensus.  need to update RFC reference.  More discussion needed.

--------------020200060709050909030508-- 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 4DC707FABE for ; Fri, 8 Sep 2006 03:25:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 38F2414227E for ; Fri, 8 Sep 2006 03:25: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 16244-04 for ; Fri, 8 Sep 2006 03:25:42 -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 80BD514224C for ; Fri, 8 Sep 2006 03:25:42 -0700 (PDT) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k88APbEo016151 for ; Fri, 8 Sep 2006 12:25:39 +0200 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP =?iso-8859-1?q?=09being?= optional(in the grammar) Date: Fri, 8 Sep 2006 12:25:36 +0200 User-Agent: KMail/1.9.3 References: <20060907233353.CDEC4142276@laweleka.osafoundation.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609081225.37154.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, SUBJ_HAS_SPACES 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, 08 Sep 2006 10:25:45 -0000 Am Freitag, 8. September 2006 02:52 schrieb John W Noerenberg II: > At 7:31 PM -0400 9/7/06, Tim Hare wrote: > >RFC2445 has this to say about DTSTAMP, and about its use vs. > >CREATED and DATE-MODIFIED > > I know what the RFC says. :-) My point is the definitions (despite > the RFC's claim to the contrary) are indistinguishable. In practice > both CREATED and DTSTAMP invariably have the same value. Sorry, but that's not true. If I created an event yesterdayday, sent out an invitation and today get some confirmations back, the event will have CREATED:20060908.... DATE-MODIFIED:20060909... (Explanation: The event was created yesterday in the storage (which might either be a flat file, a groupware server or something else), and it was modified today, which does not create a new event.) If you now tomorrow publish that event to some other group of people or so (i.e. send a mail with METHOD:PUBLISH), the calendar that you send out will have the above CREATED and DATE-MODIFIED (provided that you didn't modify it meanwhile in the calendar store), but as that particular invitation will be created tomorrow, it will have DTSTAMP:20060910... So, these three settings are in deed different. The CREATED will never change once the event is by the organizer, the DATE-MODIFIED is only changed when you modify the event, and the DTSTAMP is the time when you create that particular invitation or export from the calendar server. Cheers, Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: 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/ 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 5D54C7FABC for ; Fri, 8 Sep 2006 03:15:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4CE9C142289 for ; Fri, 8 Sep 2006 03:15: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 12293-03 for ; Fri, 8 Sep 2006 03:15:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0D6E4142286 for ; Fri, 8 Sep 2006 03:15:20 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2006 03:15:20 -0700 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.20060308/8.12.11) with ESMTP id k88AFJPI012833 for ; Fri, 8 Sep 2006 03:15:19 -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 k88AFJ1E021457 for ; Fri, 8 Sep 2006 03:15:19 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4479.cisco.com [10.61.81.126]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k88A5iJp016726 for ; Fri, 8 Sep 2006 03:05:45 -0700 Message-ID: <450142B0.5020208@cisco.com> Date: Fri, 08 Sep 2006 12:15:12 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" 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=389; t=1157710519; x=1158574519; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Propose=20to=20close=20issue=2036=20-=20X-Name=20/=20bilateral=20agreeme nts; X=v=3Dcisco.com=3B=20h=3DkvqGRoviq7bIjUxa6ZWvTRv8MWc=3D; b=VRntb+BGiiQKA7qxNj5J+UDCpZ/9vzXHi7UC2QKGgdg7/gPxHxst+fbkLaQEz+nSL5VkNo3C pDXGJ+IUoM37h4O/7AwIUE8zgcOyLbWARHIwMmLc4kbdyQK8NOSFevKZ; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Propose to close issue 36 - X-Name / bilateral agreements 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, 08 Sep 2006 10:15:21 -0000 No consensus for change as of now. Barring more discussion, the text will remain unchanged, without reference to bilateral agreements. Eliot 36 X-name > x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > ; Reserved for non-standard names. Can be used by bilateral > ; agreement. No consensus on what bilateral means in this context. 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 B90D37FAC7 for ; Fri, 8 Sep 2006 03:13:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AA7AE142289 for ; Fri, 8 Sep 2006 03:13:03 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08973-07 for ; Fri, 8 Sep 2006 03:13:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 525D3142286 for ; Fri, 8 Sep 2006 03:13:01 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2006 03:13:01 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88AD1Rj031852 for ; Fri, 8 Sep 2006 03:13:01 -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 k88AD0Yp016170 for ; Fri, 8 Sep 2006 03:13:00 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4479.cisco.com [10.61.81.126]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k88A3QIR016678 for ; Fri, 8 Sep 2006 03:03:27 -0700 Message-ID: <45014226.2040704@cisco.com> Date: Fri, 08 Sep 2006 12:12:54 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "ietf-calsify@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=513; t=1157710381; x=1158574381; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:request=20for=20more=20discussion=20on=20issue=2040; X=v=3Dcisco.com=3B=20h=3DNRdHKzTJvC6QVFIB3POb+A+zJQA=3D; b=IE5zdb6MvYXMnHpKrJGFCyzfQDIk0HkQQS08w9No4kg2GIjYPDvyq5xplu0ZIjgZ1kZhe/qM Af71ritAovmVjZRV+yEqHWePEEH5V+JjG6q5/vE7kfdE2gU3exeVNH/9; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] request for more discussion on issue 40 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, 08 Sep 2006 10:13:03 -0000 At this time the issue is open and there is no consensus on text. If no discussion occurs we will close the issue without changes to text. Eliot 40 4.6.4 f/b component/ fbprop > fbprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once > > ... No consensus as to what uid means in this context. 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 926277FAC6 for ; Fri, 8 Sep 2006 03:11:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8302D142286 for ; Fri, 8 Sep 2006 03:11: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 08973-05 for ; Fri, 8 Sep 2006 03:11: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 0CA39142289 for ; Fri, 8 Sep 2006 03:11:35 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 08 Sep 2006 03:11:35 -0700 X-IronPort-AV: i="4.08,229,1154934000"; d="scan'208,217"; a="319084278:sNHT61147554" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88ABYge023484 for ; Fri, 8 Sep 2006 03:11:34 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k88ABY6W029253 for ; Fri, 8 Sep 2006 03:11:34 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4479.cisco.com [10.61.81.126]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k88A22Il016626 for ; Fri, 8 Sep 2006 03:02:03 -0700 Message-ID: <450141D2.9040601@cisco.com> Date: Fri, 08 Sep 2006 12:11:30 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: multipart/alternative; boundary="------------060603060300080503050306" Authentication-Results: sj-dkim-5.cisco.com; header.From=lear@cisco.com; dkim=pass ( 60 extraneous bytes; sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3395; t=1157710294; x=1158574294; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Propose=20to=20close=20issues=2037,=2038,=2039; X=v=3Dcisco.com=3B=20h=3Dsm59a4pMdNmlnhWPql3aqcdnGh0=3D; b=EHecnIFnEtgZ72bIUVQDnlzSWURIIUqh550wZnNlf/6rQ5UP0mrznpiBGi04WAq5zSmaYYnc dPQ68yvH7mv/Ja/Eq1DKCHEITT3DSI4cCKeNTHc9C4oAh5+7BTscrXfc; 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_50_60, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] Propose to close issues 37, 38, 39 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, 08 Sep 2006 10:11:35 -0000 This is a multi-part message in MIME format. --------------060603060300080503050306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Each of these issues has proposed text and there has been no objection to it. 37 4.6.1 Event Component: eventprop > eventprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / dtstart / uid / > > ; the following are optional, > ; but MUST NOT occur more than once No objections. 38 VTODO todoprop > todoprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once > > ... No objections. 39 VJOURNAL journalprop > jourprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once No objections. --------------060603060300080503050306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Each of these issues has proposed text and there has been no objection to it.


37
 4.6.1 Event Component: eventprop
 
 >  eventprop  = *(
 >
 >             ; the following are both REQUIRED,
 >             ; but MUST NOT occur more than once
 >
 >             dtstamp / dtstart / uid /
 >
 >             ; the following are optional,
 >             ; but MUST NOT occur more than once
 No objections.
38
 VTODO todoprop
 
 >  todoprop  = *(
 >
 >            ; the following are both REQUIRED,
 >            ; but MUST NOT occur more than once
 >
 >            dtstamp / uid /
 >
 >            ; the following are optional,
 >            ; but MUST NOT occur more than once
 >
 >            ...
No objections.
39
 VJOURNAL journalprop
 
 >  jourprop = *(
 >
 >           ; the following are both REQUIRED,
 >           ; but MUST NOT occur more than once
 >
 >           dtstamp / uid /
 >
 >           ; the following are optional,
 >           ; but MUST NOT occur more than once
 No objections.

--------------060603060300080503050306-- 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 A1A787FAB8 for ; Fri, 8 Sep 2006 03:06:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9285614228A for ; Fri, 8 Sep 2006 03:06: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 10934-04 for ; Fri, 8 Sep 2006 03:06:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 42C06142286 for ; Fri, 8 Sep 2006 03:06:35 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 Sep 2006 03:06:34 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88A6YDq006042 for ; Fri, 8 Sep 2006 03:06:34 -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 k88A6YQV007162 for ; Fri, 8 Sep 2006 03:06:34 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4479.cisco.com [10.61.81.126]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k889uxH8016506 for ; Fri, 8 Sep 2006 02:57:03 -0700 Message-ID: <450140A2.70405@cisco.com> Date: Fri, 08 Sep 2006 12:06:26 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" 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=1246; t=1157709994; x=1158573994; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:a=20message=20from=20the=20chairs; X=v=3Dcisco.com=3B=20h=3DsS0makxmJtHB5+gTH0Aj9Zwcnjc=3D; b=qxJ9EIiK8JzZToRVPXeyiEFGKklXpsezCdsVO+JXdeta3RUdvGhHsEai89oLkq2SZqdh/dmB xqRpeyJ2MO7+3xS+nMCGhm0tpktWWjGPpU3YswlefNNsGvUasVcxsSZf; 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, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] a message from the chairs 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, 08 Sep 2006 10:06:37 -0000 Hello everyone, I would like to again direct your attention to http://www.ofcourseimright.com/cgi-bin/roundup/calsify. These are the open issues for RFC2445bis. To move things along, Aki and I are going to sift through each issue to see what is needed to resolve them. Aki will start at the top issue (number 1) and I will start at the bottom (currently #40) and we will work our way towards each other. Depending on mailing list content, we will take one of several actions: 1. Close the issue because Bernard has dealt with it; 2. Propose the issue be closed if there is no text; 3. Propose the issue be closed if there is text but no discussion; or 4. Encourage conclusion of discussion so we can close an issue that has both text and discussion. Any issue can be moved to state (4) with proposal of text, based on a reply to our messages. If there is no text to discuss then it is pointless to argue the issue. Anyone can open a new issue - FOR NOW. We would like WGLC to not be too far away. There are some overlapping issues in the tracker. I beg your indulgence to help me find these and to suggest an appropriate action. On behalf of Aki, thanks for your participation! Eliot 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 7E43B7F8D4 for ; Thu, 7 Sep 2006 17:52:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F5AB142281 for ; Thu, 7 Sep 2006 17:52: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 01241-02 for ; Thu, 7 Sep 2006 17:52:42 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2445614226F for ; Thu, 7 Sep 2006 17:52:42 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k880qeA2003201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Sep 2006 17:52:41 -0700 Received: from [129.46.76.39] (valinor.qualcomm.com [129.46.76.39]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k880qc3V002691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Sep 2006 17:52:39 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060907233353.CDEC4142276@laweleka.osafoundation.org> References: <20060907233353.CDEC4142276@laweleka.osafoundation.org> User-Agent: eudora6.3a0carbon-0822061540 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 7 Sep 2006 17:52:01 -0700 To: "Tim Hare" From: John W Noerenberg II Subject: RE: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar) Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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, SUBJ_HAS_SPACES X-Spam-Level: Cc: 'CALSIFY Mailinglist' 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, 08 Sep 2006 00:52:44 -0000 At 7:31 PM -0400 9/7/06, Tim Hare wrote: > >RFC2445 has this to say about DTSTAMP, and about its use vs. >CREATED and DATE-MODIFIED I know what the RFC says. :-) My point is the definitions (despite the RFC's claim to the contrary) are indistinguishable. In practice both CREATED and DTSTAMP invariably have the same value. It's pointless redundancy. One or the other should go. If DTSTAMP is needed for backward compatibility then keep that instead and deprecate CREATED. 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 C5A5D7F8E9 for ; Thu, 7 Sep 2006 16:33:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B615C14227E for ; Thu, 7 Sep 2006 16:33:54 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13526-10 for ; Thu, 7 Sep 2006 16:33:54 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.77.81]) by laweleka.osafoundation.org (Postfix) with ESMTP id CDEC4142276 for ; Thu, 7 Sep 2006 16:33:53 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (sccrmhc11) with SMTP id <2006090723335201100ca9kue>; Thu, 7 Sep 2006 23:33:52 +0000 From: "Tim Hare" To: "'CALSIFY Mailinglist'" Subject: RE: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar) Date: Thu, 7 Sep 2006 19:31:42 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C6D2B4.3FDC5B70" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcbS0/P8MyQSSc3+RiO7HPfRiUSQIQAAPHZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Message-Id: <20060907233353.CDEC4142276@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.5 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_40_50, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, 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: Thu, 07 Sep 2006 23:33:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C6D2B4.3FDC5B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RFC2445 has this to say about DTSTAMP, and about its use vs. CREATED and DATE-MODIFIED -------------------------------------------------------- snip -------------------------------------------------------------------- Conformance: This property MUST be included in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. Description: The value MUST be specified in the UTC time format. This property is also useful to protocols such as [IMIP] that have inherent latency issues with the delivery of content. This property will assist in the proper sequencing of messages containing iCalendar objects. This property is different than the "CREATED" and "LAST-MODIFIED" properties. These two properties are used to specify when the particular calendar data in the calendar store was created and last modified. This is different than when the iCalendar object representation of the calendar service information was created or last modified. -------------------------------------------------------- snip -------------------------------------------------------------------- Also I seem to remember that DTSTAMP is used in iMIP and iTIP to determine the winner in a multiple-updates-received-not-necessarily-in-order scenario. I don't think it can be deprecated without understanding its use in those areas. Tim Hare Interested Bystander, Non-Inc. _____ From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Robert Ransdell Sent: Thursday, September 07, 2006 7:18 PM To: John W Noerenberg II Cc: CALSIFY Mailinglist; ietf-calsify-bounces@osafoundation.org Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar) you will break backward compatibility if you remove DTSTAMP. Its equivalent to Posted Date. John W Noerenberg II Sent by: ietf-calsify-bounces@osafoundation.org 09/07/2006 07:08 PM To Jeffrey Harris cc CALSIFY Mailinglist Subject Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional (in the grammar) At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote: >Given that the RFC was confused, I'd like to put in a vote in favor of >choosing optional for DTSTAMP, not MUST. Lots of iCalendar in the wild >doesn't have a DTSTAMP, and I don't see a compelling reason for >requiring it (although I'd be happy to be informed of compelling reasons). Heck, I'd love to see DTSTAMP's use deprecated. I don't buy there's sufficient difference between CREATED and DTSTAMP to necessitate two different attributes. -- john noerenberg ---------------------------------------------------------------------- It is treason to sacrifice love of truth, intellectual honesty, loyalty to the laws and methods of the mind, to any other interests, including those of one's country. -- Herman Hesse, The Glass Bead Game, 1943 ---------------------------------------------------------------------- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify ------=_NextPart_000_0028_01C6D2B4.3FDC5B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
RFC2445 has this to say about DTSTAMP, and = about its=20 use  vs. CREATED and DATE-MODIFIED
 
-------------------------------------------------------- snip=20 --------------------------------------------------------------------
Conformance: This property MUST be included in the =
"VEVENT", "VTODO",
   "VJOURNAL" or "VFREEBUSY" calendar components.

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

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

   This property is different than the "CREATED" and "LAST-MODIFIED"
   properties. These two properties are used to specify when the
   particular calendar data in the calendar store was created and last
   modified. This is different than when the iCalendar object
   representation of the calendar service information was created or
   last modified.
-------------------------------------------------------- snip=20 --------------------------------------------------------------------
 
Also I seem to remember that DTSTAMP is used in iMIP and iTIP = to=20 determine the winner in a = multiple-updates-received-not-necessarily-in-order=20 scenario.
I don't=20 think it can be deprecated without understanding its use in those=20 areas.
 
Tim Hare
Interested Bystander,=20 Non-Inc.
 

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


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



John W = Noerenberg II=20 <jwn2@qualcomm.com>
Sent=20 by: ietf-calsify-bounces@osafoundation.org=20

09/07/2006 07:08 PM =

To
Jeffrey Harris=20 <jeffrey@osafoundation.org>=20
cc
CALSIFY Mailinglist=20 <Ietf-calsify@osafoundation.org>=20
Subject
Re: [Ietf-calsify] Error = in RFC=20 2445 regarding DTSTAMP being       =  optional=20         (in the=20 grammar)

=




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

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

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

------=_NextPart_000_0028_01C6D2B4.3FDC5B70-- 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 4591E7F998; Thu, 7 Sep 2006 16:18:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30C4914227E; Thu, 7 Sep 2006 16:18: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 10438-08; Thu, 7 Sep 2006 16:18:38 -0700 (PDT) Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8A87114225C; Thu, 7 Sep 2006 16:18:38 -0700 (PDT) In-Reply-To: References: <200606092314.21663.reinhold@kainhofer.com> <448D6A6E.1090006@oracle.com> <448DCE85.1020702@osafoundation.org> To: John W Noerenberg II Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional (in the grammar) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V80_09062006NP September 06, 2006 Message-ID: Date: Thu, 7 Sep 2006 19:18:21 -0400 From: "Robert Ransdell" X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 7.0.1|January 17, 2006) at 09/07/2006 07:09:35 PM, Serialize complete at 09/07/2006 07:09:35 PM Content-Type: multipart/alternative; boundary="=_alternative 007FAAD6852571E2_=" 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, HTML_40_50, HTML_MESSAGE, SUBJ_HAS_SPACES X-Spam-Level: Cc: CALSIFY Mailinglist , ietf-calsify-bounces@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, 07 Sep 2006 23:18:39 -0000 This is a multipart message in MIME format. --=_alternative 007FAAD6852571E2_= Content-Type: text/plain; charset="US-ASCII" you will break backward compatibility if you remove DTSTAMP. Its equivalent to Posted Date. John W Noerenberg II Sent by: ietf-calsify-bounces@osafoundation.org 09/07/2006 07:08 PM To Jeffrey Harris cc CALSIFY Mailinglist Subject Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional (in the grammar) At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote: >Given that the RFC was confused, I'd like to put in a vote in favor of >choosing optional for DTSTAMP, not MUST. Lots of iCalendar in the wild >doesn't have a DTSTAMP, and I don't see a compelling reason for >requiring it (although I'd be happy to be informed of compelling reasons). Heck, I'd love to see DTSTAMP's use deprecated. I don't buy there's sufficient difference between CREATED and DTSTAMP to necessitate two different attributes. -- john noerenberg ---------------------------------------------------------------------- It is treason to sacrifice love of truth, intellectual honesty, loyalty to the laws and methods of the mind, to any other interests, including those of one's country. -- Herman Hesse, The Glass Bead Game, 1943 ---------------------------------------------------------------------- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --=_alternative 007FAAD6852571E2_= Content-Type: text/html; charset="US-ASCII"
you will break backward compatibility if you remove DTSTAMP.  Its equivalent to Posted Date.



John W Noerenberg II <jwn2@qualcomm.com>
Sent by: ietf-calsify-bounces@osafoundation.org

09/07/2006 07:08 PM

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





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

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

john noerenberg
  ----------------------------------------------------------------------
  It is treason to sacrifice love of truth, intellectual honesty,
  loyalty to the laws and methods of the mind, to any other interests,
  including those of one's country.
  -- Herman Hesse, The Glass Bead Game, 1943
  ----------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
--=_alternative 007FAAD6852571E2_=-- 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 5FC5F7F8BF; Thu, 7 Sep 2006 16:07:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F83E142281; Thu, 7 Sep 2006 16:07: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 15363-06; Thu, 7 Sep 2006 16:07:47 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 031B414225A; Thu, 7 Sep 2006 16:07:46 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k87N7hGb020500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Sep 2006 16:07:44 -0700 Received: from [129.46.76.39] (valinor.qualcomm.com [129.46.76.39]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k87N7ZYQ028257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Sep 2006 16:07:42 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <448DCE85.1020702@osafoundation.org> References: <200606092314.21663.reinhold@kainhofer.com> <448D6A6E.1090006@oracle.com> <448DCE85.1020702@osafoundation.org> User-Agent: eudora6.3a0carbon-0822061540 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 7 Sep 2006 15:56:51 -0700 To: Jeffrey Harris From: John W Noerenberg II Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional (in the grammar) Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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, SUBJ_HAS_SPACES X-Spam-Level: Cc: CALSIFY Mailinglist 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, 07 Sep 2006 23:07:48 -0000 At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote: >Given that the RFC was confused, I'd like to put in a vote in favor of >choosing optional for DTSTAMP, not MUST. Lots of iCalendar in the wild >doesn't have a DTSTAMP, and I don't see a compelling reason for >requiring it (although I'd be happy to be informed of compelling reasons). Heck, I'd love to see DTSTAMP's use deprecated. I don't buy there's sufficient difference between CREATED and DTSTAMP to necessitate two different attributes. -- john noerenberg ---------------------------------------------------------------------- It is treason to sacrifice love of truth, intellectual honesty, loyalty to the laws and methods of the mind, to any other interests, including those of one's country. -- Herman Hesse, The Glass Bead Game, 1943 ---------------------------------------------------------------------- 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 5F6247FA1A for ; Tue, 5 Sep 2006 18:34:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 506791422A4 for ; Tue, 5 Sep 2006 18:34: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 27629-07 for ; Tue, 5 Sep 2006 18:34:54 -0700 (PDT) Received: from mauve.mrochek.com (unknown [206.117.180.234]) by laweleka.osafoundation.org (Postfix) with ESMTP id BA2E71422A2 for ; Tue, 5 Sep 2006 18:34:54 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6UGLJP1TS00I9LR@mauve.mrochek.com> for ietf-calsify@osafoundation.org; Tue, 5 Sep 2006 18:34:48 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6U1NCY9M80008CX@mauve.mrochek.com>; Tue, 05 Sep 2006 18:34:45 -0700 (PDT) To: Alexey Melnikov Message-id: <01M6UGLIKKDG0008CX@mauve.mrochek.com> Date: Tue, 05 Sep 2006 11:59:07 -0700 (PDT) From: Ned Freed Subject: Re: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-reply-to: "Your message dated Mon, 21 Aug 2006 20:10:12 +0100" <44EA0514.609@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <44E9FD8D.8070904@oracle.com> <44EA008D.5060909@isode.com> <44EA0514.609@isode.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-Mailman-Approved-At: Mon, 11 Sep 2006 09:20:46 -0700 Cc: Mark Crispin , Calsify WG 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, 06 Sep 2006 01:34:56 -0000 > Mark Crispin wrote: > > On Mon, 21 Aug 2006, Alexey Melnikov wrote: > > > >>> If any revision is made, it should be to delete US-ASCII and make > >>> UTF-8 mandatory. > >> > >> However we can't do this, as absence of the charset parameter means > >> US-ASCII. > >> So any iCalendar object in UTF-8 MUST have charset=utf-8. > > > > That's unfortunate. I admit that I am not up to speed on this > > specification; is there really no way to fix this problem? > To clarify, the default charset=US-ASCII comes from MIME specs. > I am not sure if text/calendar can change the default character set > used. Somebody with better MIME expertise should clarify this. This is a tricky point in MIME. The idea behind the text top-level type was in part to support fallback display of textual material even when the specific type isn't understood. To this end, text types are required to use the charset parameter in a manner that's compatible with text/plain. text/plain uses the charset parameter to specify the charset (duh) and has a default of US-ASCII. See RFC 2046 section 4.1.2 for specifics. In any case, RFC 2046 recommands but does not actually require that all text types have the same default of US-ASCII. And pretty much the first other text subtype, text/html, opted for iso-8859-1 as it's default. In retrospect UTF-8 would have been a better choice for both text/plain and text/html, but please remember that UTF-8 didn't even exist at the time this stuff was defined. So what's the right course of action? I think the right thing to do is make the default UTF-8 but strongly recommend that the charset parameter be present. > > If there is some way of defining the charset as always being UTF-8, > > then charset parameters can be removed from the specification as > > extraneous. > Yes, that would be nice. Nice but not really possible. See above. Ned 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 68EE07F94C for ; Sat, 2 Sep 2006 03:29:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 58A30142279 for ; Sat, 2 Sep 2006 03:29: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 02273-03 for ; Sat, 2 Sep 2006 03:29:56 -0700 (PDT) Received: from natlemon.rzone.de (natlemon.rzone.de [81.169.145.170]) by laweleka.osafoundation.org (Postfix) with ESMTP id 84F8F142278 for ; Sat, 2 Sep 2006 03:29:56 -0700 (PDT) Received: from ollie.block.home (dslb-084-063-173-146.pools.arcor-ip.net [84.63.173.146]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k82ATr7i000779 for ; Sat, 2 Sep 2006 12:29:54 +0200 (MEST) From: Oliver Block To: ietf-calsify@osafoundation.org Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 Date: Sat, 2 Sep 2006 12:29:25 +0200 User-Agent: KMail/1.7.1 References: <200608151454.51877.lists@block-online.eu> <44F8544E.6090006@oracle.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200609021229.26322.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 List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2006 10:29:59 -0000 Am Freitag, 1. September 2006 18:32 schrieb Mark Crispin: > Therefore, a better wording is: > ---------------------------------------------------------------------- > Folded lines MUST be well-formed according to the character set specified > for the iCalendar object. Folding MUST NOT occur between octets that > define a single codepoint in a character set that uses multiple octets to > define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian > character sets). [Furthermore, folding MUST NOT occur prior to a > codepoints that defines a combining character.] This may require > folding a line at less than the recommended 75 octet limit. > ---------------------------------------------------------------------- > > The text in [] is used for interpretation (2) but not for interpretation > (3). This is quite elaborated. But it should IMHO talk of "charset" (RFC2978, Sect. 1.3) not "character set". Unfortunately just replacing "characters set" with "charset" doesn't work as it is used in two different contexts. Best Regards, Oliver -- Leben ist mehr als schneller - weiter - höher http://www.nak-nrw.de/p_6_4.html 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 8C9D97FA4F for ; Fri, 1 Sep 2006 09:32:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7AA5B142286 for ; Fri, 1 Sep 2006 09:32: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 17152-01 for ; Fri, 1 Sep 2006 09:32:34 -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 632BB14227C for ; Fri, 1 Sep 2006 09:32:34 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k81GWVZr027733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Sep 2006 09:32:31 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k81GWTO8030799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Sep 2006 09:32:31 -0700 Date: Fri, 1 Sep 2006 09:32:29 -0700 (PDT) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Bernard Desruisseaux Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <44F8544E.6090006@oracle.com> Message-ID: References: <200608151454.51877.lists@block-online.eu> <200608222104.25563.lists@block-online.eu> <200608230048.47607.lists@block-online.eu> <44EBB9CE.1050800@oracle.com> <1263927117.20060823015902@pobox.com> <44EC6EE5.209@oracle.com> <8D4D9535660C5B200535BF99@Cyrus-Daboo.local> <44F8544E.6090006@oracle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.1.91442 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, __STOCK_CRUFT 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Calsify List 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, 01 Sep 2006 16:32:36 -0000 On Fri, 1 Sep 2006, Bernard Desruisseaux wrote: > Folded lines MUST be well-formed according to the character set > specified for the iCalendar object. For instance, a UTF-8 multi-octet > sequence MUST not be split across lines when UTF-8 is used as > the character set. This may require folding a line at less than > the recommended 75 octet limit. "UTF-8 multi-octet sequence" is neither a technically accurate nor unambiguous term. It can describe: 1) An entire UTF-8 string, comprised of multiple codepoints (Unicode characters) and multiple glyphs (printed characters). 2) A sequence of octets, interpreted as UTF-8, that comprise a single glyph, but may comprise multiple codepoints. 3) A sequence of octets, interpreted as UTF-8, that comprise a single codepoint. Interpretation (1) is absurd in the context, but it is not precluded by "UTF-8 multi-octet sequence". No matter how absurd a misinterpretation may be, someone someday will use it unless it is precluded. The difference between interpretation (2) and (3) depends upon which criteria is used for "well-formed". Splitting between a character and combining characters is well-formed UTF-8 encoding, but is NOT well-formed Unicode. Many people fail to understand that UTF-8 is NOT a character set; it is an encoding. The character set is Unicode. Therefore, a better wording is: ---------------------------------------------------------------------- Folded lines MUST be well-formed according to the character set specified for the iCalendar object. Folding MUST NOT occur between octets that define a single codepoint in a character set that uses multiple octets to define a codepoint (e.g., non-ASCII codepoints in UTF-8, East Asian character sets). [Furthermore, folding MUST NOT occur prior to a codepoints that defines a combining character.] This may require folding a line at less than the recommended 75 octet limit. ---------------------------------------------------------------------- The text in [] is used for interpretation (2) but not for interpretation (3). If this working group chooses to use interpretation (3), I question the need for this rule at all. Under interpretation (3), folded text CAN NOT interpreted correctly without first applying unfolding. The two folded strings would be well formed UTF-8 encoding, but it is NOT well formed Unicode. On the other hand, there is a possibility that it may not be possible to fit a well-formed Unicode string, encoded in UTF-8, in 75 octets. This would happen if a single glyph consumes more than 75 octets when encoded in UTF-8. As far as I recall, the record is a glyph that consumes 18 codepoints (all in the BMP, so a maximum of 3 octets/codepoint), and that glyph has a precomposed codepoint in the BMP. So this currently is not a problem. If the sense of the group is that it wants to use interpretion (3) to avoid this (as-yet theoretical problem), and that it is "good enough" to require just well-formed UTF-8 encoding without requiring well-formed Unicode, then I request that there be some text to state this rationale. For example: ---------------------------------------------------------------------- Note: folding is permitted between a character and a combining character. The result of such folding in UTF-8 is well-formed UTF-8; however it is not well-formed Unicode. The string prior to the folding will end with a printed glyph that is not correct (it misses some combining character) and the string subsequent to the folding will start with a combining character which is meaningless in Unicode. Therefore, these strings MUST BE unfolded before displaying them to the user. These foldings are for transport in the iCalendar object, and to keep all strings in the iCalendar object as well-formed transport encodings (e.g., well-formed UTF-8). There is NO guarantee that a folded string is well-formed in the character set; and thus these foldings MUST NOT be used as display foldings. ---------------------------------------------------------------------- -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. 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 0B98C7F932 for ; Fri, 1 Sep 2006 08:41:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EFEC9142286 for ; Fri, 1 Sep 2006 08:41: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 25926-10 for ; Fri, 1 Sep 2006 08:41:34 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 002D8142285 for ; Fri, 1 Sep 2006 08:41:33 -0700 (PDT) Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k81FUl98032529 for ; Fri, 1 Sep 2006 10:41:32 -0500 Received: from bdesruis-ca.ca.oracle.com by rcsmt250.oracle.com with ESMTP id 1919001751157125203; Fri, 01 Sep 2006 09:40:03 -0600 Message-ID: <44F8544E.6090006@oracle.com> Date: Fri, 01 Sep 2006 11:39:58 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Calsify List Subject: Re: [Issue 1] Re: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 References: <200608151454.51877.lists@block-online.eu> <200608222104.25563.lists@block-online.eu> <200608230048.47607.lists@block-online.eu> <44EBB9CE.1050800@oracle.com> <1263927117.20060823015902@pobox.com> <44EC6EE5.209@oracle.com> <8D4D9535660C5B200535BF99@Cyrus-Daboo.local> In-Reply-To: <8D4D9535660C5B200535BF99@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: 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, 01 Sep 2006 15:41:35 -0000 Folks, I would like to close this issue with a new proposal. I propose to add the following statement in section 4.1 Content Lines: Folded lines MUST be well-formed according to the character set specified for the iCalendar object. For instance, a UTF-8 multi-octet sequence MUST not be split across lines when UTF-8 is used as the character set. This may require folding a line at less than the recommended 75 octet limit. Old text: > Lines of text SHOULD NOT be longer than 75 octets, excluding the line > break. Long content lines SHOULD be split into a multiple line > representations using a line "folding" technique. That is, a long > line can be split between any two characters by inserting a CRLF > immediately followed by a single linear white space character (i.e., > SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence > of CRLF followed immediately by a single linear white space character > is ignored (i.e., removed) when processing the content type. New text: Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. Long content lines SHOULD be split into a multiple line representations using a line "folding" technique. That is, a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white space character (i.e., SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Folded lines MUST be well-formed according to the character set specified for the iCalendar object. For instance, a UTF-8 multi-octet sequence MUST not be split across lines when UTF-8 is used as the character set. This may require folding a line at less than the recommended 75 octet limit. Any sequence of CRLF followed immediately by a single linear white space character is ignored (i.e., removed) when processing the content type. Cheers, Bernard Cyrus Daboo wrote: > Hi Bernard, > > --On August 23, 2006 11:06:13 AM -0400 Bernard Desruisseaux > wrote: > >> The question is "Do we actually care?". >> >> I would say that as long as the iCalendar stream is a valid >> UTF-8 document we are ok. > > Agreed - my main concern is ensuring that the stream conforms to UTF-8 > abnf - i.e. the characters are all valid. I don't really care whether > the 'raw' unfolded text displays well or not in a text editor. After > all, even in the absence of combining characters, the folding can occur > in the middle of a word and the result may be nonsensical or even worse > appear to be two valid words giving a different meaning to what was meant. >