Subject: [Ietf-calsify] current summary of issues

From: lear at cisco.com (Eliot Lear)
Date: Thu Aug 24 07:16:21 2006

<ChairHatOn>

[this message is hopefully best viewed as HTML]

Hello everyone,

What follows is a summary of where I think we are for each issue with
2445bis.  I ask that if you are going to comment about a particular
issue, PLEASE indicate which issue in the subject and keep it to one
issue per message.  This covers ALL issues with 2445bis with the
exception of Lisa's proposal, but I am mindful of that requiring
attention.  It would otherwise be the elephant in the living room. 
Please note the following:

    * If an issue indicates either "consensus" or "no objection" without
      additional annotation, the co-chair believes the issue is resolved.
    * If there is no entry in consensus state, that means there is no
      text to gain consensus around yet.
    * Feel free to discuss anything where more discussion is indicated ;-)

Finally, please take note of the amount of work Bernard has.  You can
help by proposing textual changes for open issues that have no text or
no consensus.

Here goes:

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.

That is all for now.

<ChairHatOff>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060824/418873a0/attachment.html