3.1.4. Character Set There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is UTF-8 as defined in [RFC2279].I'd like to call your attention to the following paragraph I recently read, which is taken from "The Unicode Standard 4.0" and available online.
Utility programs are not prevented from operating on "mangled" text. For example, a UTF-8 file could have had a CRLF sequences introduced at every 80 bytes by a bad mailer program. This could result in some UTF-8 byte sequence being interrupted by CRLFs, producing illegal byte sequences. This mangled text is no longer UTF-8. It is permissible for a conformant program to repair such text, recognizing that the mangled text was originally well-formed UTF-8 byte sequences. However, such repair of mangled data is a special case, and it must be not be used in circumstances where it would cause security problems.draft-ietf-calsify-rfc2445bis-01.txt specifies UTF-8 as default character set, and implies _valid_ UTF-8, of course. But for the mentioned problems on folding in that discussion it might be helpful to hint that folding within UTF-8 byte sequences produces _illegal_ byte sequences which are no longer UTF-8. Best Regards, Oliver Block -- Leben ist mehr als schneller - weiter - h?her http://www.nak-nrw.de/p_6_4.html From kainhofer at kainhofer.com Wed Aug 16 00:29:45 2006 From: kainhofer at kainhofer.com (Reinhold Kainhofer) Date: Wed Aug 16 00:29:53 2006 Subject: [Ietf-calsify] draft-ietf-calsify-rfc2445bis-01.txt / UTF-8 In-Reply-To: <200608151454.51877.lists@block-online.eu> References: <200608151454.51877.lists@block-online.eu> Message-ID:
The specification for any future subtypes of "text" must specify whether or not they will also utilize a "charset" parameter, and may possibly restrict its values as well. For other subtypes of "text" than "text/plain", the semantics of the "charset" parameter should be defined to be identical to those specified here for "text/plain", i.e., the body consists entirely of characters in the given charset. In particular, definers of future "text" subtypes should pay close attention to the implications of multioctet character sets for their subtype definitions.That might have been the reason for the definition. It continues:
The charset parameter for subtypes of "text" gives a name of a character set, as "character set" is defined in RFC 2045. The rules regarding line breaks detailed in the previous section must also be observed -- a character set whose definition does not conform to these rules cannot be used in a MIME "text" subtype. An initial list of predefined character set names can be found at the end of this section. Additional character sets may be registered with IANA.(RFC2046, Section 4.1.2, p. 7,8) It would be helpful at least to mention that the used character set must registered charsets (RFC2978). Best Regards, Oliver -- Leben ist mehr als schneller - weiter - h?her http://www.nak-nrw.de/p_6_4.html From lists at block-online.eu Mon Aug 21 15:22:47 2006 From: lists at block-online.eu (Oliver Block) Date: Mon Aug 21 15:23:22 2006 Subject: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To: <200608220008.04375.lists@block-online.eu> References: <44E9FD8D.8070904@oracle.com> <200608220008.04375.lists@block-online.eu> Message-ID: <200608220022.48120.lists@block-online.eu> Am Dienstag, 22. August 2006 00:08 schrieb Oliver Block: > It would be helpful at least to mention that the used character set must > registered charsets (RFC2978). Sorry for that English. -- Leben ist mehr als schneller - weiter - h?her http://www.nak-nrw.de/p_6_4.html From bernard.desruisseaux at oracle.com Mon Aug 21 19:28:00 2006 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Aug 21 19:29:45 2006 Subject: [Ietf-calsify] Character set restriction in section 4.3.11 Text In-Reply-To:
Issue Number |
Issue Topic |
Proposed Action |
Consensus State |
1 |
Line length limit and folding issues |
New text:
> Lines of text SHOULD NOT be longer than 75 octets, excluding the line > break. Long content lines SHOULD be split into a multiple line > representations using a line "folding" technique. That is, a long > line can be split between any two characters by inserting a CRLF > immediately followed by a single linear white space character (i.e., > SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). A multi- > octet character MUST NOT be split across lines. Any sequence of > CRLF followed immediately by a single linear white space character > is ignored (i.e., removed) when processing the content type. |
No consensus yet. |
2 |
Typo in VTODO |
4.8.6.3 Trigger If the trigger is set relative to START, then the "DTSTART" property MUST be present in the associated "VEVENT" or "VTODO" calendar component. If an alarm is specified for an event with the trigger set relative to the END, then the "DTEND" property or the "DSTART" and "DURATION' properties MUST be present in the associated "VEVENT" calendar component. If the alarm is specified for a to-do with a trigger set relative to the END, then either the "DUE" property or the "DSTART" and "DURATION' properties MUST be present in the associated "VTODO" calendar component. CORRECTION: replace DSTART with DTSTART (lines 4 & 8) PS. have enjoyed recent discussions, more (contentious) comments / suggestions to follow .. |
no objections |
3 |
Bunch of other typos |
bunch of minor fixes including:> NON-US-ASCII = %x80-FD or > NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4 > ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629. and if we agree to support ISO-8859-1, then it should be: > NON-US-ASCII = %x80-FF |
no objections |
4 |
Example error |
No proposed change yet. |
|
5 |
Andrew Bowden's Proposed changes to
RRULE / EXDATE |
4.8.5.1.. The recurrence set is the complete set of recurrence instances for a calendar component. The recurrence set is generated by considering the "DTSTART" property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within the iCalendar object. The "DTSTART" property defines the first instance in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" properties can also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the date-times generated by any of the specified "RRULE" and "RDATE" properties, and then excluding any date-times which fall within the union of date-times generated by any specified "EXRULE" and "EXDATE" properties. This implies that date-times within exclusion related properties (i.e., "EXDATE" and "EXRULE") take precedence over those specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are generated by the "RRULE" and "RDATE" properties, only one recurrence is considered. Duplicate instances are ignored. |
No consensus and there are other proposed
changes to these properties. |
6 |
duplicate of 3 |
(closed) |
|
7 |
duplicate of 4 |
(closed) |
|
8 |
Deprecate P1D or P24H? |
No suggested text. |
|
9 |
Recurring events: Start / End Time |
No suggested text. |
|
10 |
End Date Not inclusive |
No suggested text |
|
11 |
Possible examples to be included in 2445bis |
Please see
http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11 |
No objections but no consensus either.
Discussion needed. |
12 |
Confusion about when FREQ is applied in RRULE | No suggested text. |
|
13 |
Clarification wording for "if specified" in
DTSTART |
Something close to a textual suggestion:The "if specified" in this context is supposed to mean "if it matches the BY* rules", or "if it would be generated as a recurrence date by the RRULE". It does not mean if it is specified (i.e. exists) in the VEVENT at all. |
No objection but no consensus either. More
discussion needed. |
14 |
DTSTART/DTEND/DURATION clarification of text |
Section 4.8.5.4 Something close to a textual suggestion: Here, "first instance of the recurrence" does NOT mean the recurrence generated by that particular RRULE, but it rather means the whole set of occurences of the event (which is calculated of the DTSTART + RRULE dates + RDATE - EXRULE dates - EXDATE). This is particularly important as otherwise an EXRULE would always exclude the original start date/time. |
No objection but no consensus either. More
discussion needed. |
16 |
BY parts to be ignored clarification |
Section 4.3.10 Something close to a textual suggestion: -) Section 4.3.10 says: "If BYxxx rule part values are found which are beyond the available scope (ie, BYMONTHDAY=30 in February), they are simply ignored." Here an example should be given (what the available scope is and what ignored means here). E.g. DTSTART;TZID=Europe/Vienna: 20050201T120000 RRULE:FREQ=MONTHLY;BYMONTHDAY=30;FREQ=3 results in occurrences on 1 Feb 2006, 30 May 2006, 30 Aug 2006, 30 Nov 2006, 30 May 2006. I.e. "they are simply ignored" means that the whole occurrence is ignored, not the rule part value (which would result in the day being taken from the DTSTART) . |
No objection but no consensus either. More
discussion needed. |
19 |
IANA Considerations |
Text in draft already. |
No objections |
23 |
Contradiction regarding UNTIL BNF. |
Room showing agreement that the draft should state that the UNTIL value type MUST match DTSTART value type. Exact textual change required. |
|
24 |
Clarification required for number of recurrences
generated by multiple RRULEs |
Bernard to add text. |
|
25 |
Is the first recurrence instance, defined by
DTSTART, always excluded by RRULE? |
No text. Mailing list discussion required. |
|
26 |
BYHOUR, BYMINUTE, and BYSECOND recurrence rules
where value type is DATE |
Consensue to add MUST not generate, but specific
text required. |
|
27 |
Clarification of DTEND/DURATION |
Cyrus to propose text in 4.8.5.4. Is this the
same as issue 14? |
|
28 |
In 4.8.5.4 Is RDATE required even when the
recurrence instance is defined in a separate component |
Bernard to propose text. |
|
29 |
Is DTSTART required in VTODO/VJOURNAL? |
Is DTSTART required in VTODO and VJOURNAL components when the RRULE or EXRULE properties are defined in those components? Cyrus floated another idea that in the case of VTODO, perhaps the recurrence could use the DUE property. Bernard suggested that perhaps in the absence of DTSTART, it could default to DUE. Lisa pointed out that this needs more discussion beyond the room, because different apps behave differently. In the end, some agreement that it's enough to clarify that for recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even if it's otherwise optional. AI: Go forward with above clarification |
consensus |
30 |
Section 3.2: "charset" parameter |
New text proposed: > The "charset" parameter is defined in [RFC 2046] for subtypes of > the "text" media type. It is used to indicate the character set > used in the body part. |
consensus |
31 |
Character set restriction in Section 4.3.11 text |
Proposed new text: > Formal Definition: The value type is defined by the following notation. |
No consensus, and substantial opposition. |
32 |
Section 4.4: Single iCalendar Object |
Proposed new text: > The Calendaring and Scheduling Core Object is a collection of > calendaring and scheduling information. Typically, this information > will consist of an iCalendar stream with a single iCalendar object. > However, multiple iCalendar objects can be sequentially grouped > together in an iCalendar stream. The first line and last line of > the iCalendar object MUST contain a pair of iCalendar object > delimiter strings. The syntax for an iCalendar stream is as follows: > > icalstream = 1*icalobject > > icalobject = "BEGIN" ":" "VCALENDAR" CRLF > icalbody > "END" ":" "VCALENDAR" CRLF |
Weak consensus. Would like more discussion. |
33 |
characters v. octets |
In both cases change 255 characters to 255
octets. |
consensus |
34 |
"method" parameter |
New text: > The "method" parameter MUST be specified only for iCalendar > stream that contains a single iCalendar object. The "method" > parameter MUST be the same value as that specified in the "METHOD" > component property in the iCalendar object. If one is present, > the other MUST also be present. |
no consensus / disagreement |
35 |
Section 4.2.10 language / language property |
Proposed new text: > Description: The parameter identifies the language of the text in > the property or property parameter value. The value of the "language" > property parameter is that defined in [RFC 1766]. |
possible consensus. need to update RFC
reference. More discussion needed. |
36 |
X-name |
> x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > ; Reserved for non-standard names. Can be used by bilateral > ; agreement. |
No consensus on what bilateral means in this
context. |
37 |
4.6.1 Event Component: eventprop |
> eventprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / dtstart / uid / > > ; the following are optional, > ; but MUST NOT occur more than once |
No objections. |
38 |
VTODO todoprop |
> todoprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once > > ... |
No objections. |
39 |
VJOURNAL journalprop |
> jourprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once |
No objections. |
40 |
4.6.4 f/b component/ fbprop |
> fbprop = *( > > ; the following are both REQUIRED, > ; but MUST NOT occur more than once > > dtstamp / uid / > > ; the following are optional, > ; but MUST NOT occur more than once > > ... |
No consensus as to what uid means in this
context. |