273039 - iCalendar data has line breaks that do not conform to RFC2445

Status: RESOLVED WORKSFORME

(Calendar :: Internal Components, defect)

Description

[Brad BARCLAY]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0 (PowerBook)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0 (PowerBook)

The iCalendar data generated my Mozilla Calendar is out-of-spec.  It includes a
line break between the tag name and the value separator (':') which should not
be there, according to ss4.1 of RFC2445.  An example of this output is:

  BEGIN:VEVENT
UID
 :959420326
SUMMARY
 :Valentine's Day
DESCRIPTION
 :The day we show our loved ones how much we care.
LOCATION
 :In our hearts
CLASS
 :PRIVATE
X
 ;MEMBER=AllDay
 :TRUE
X
 ;MEMBER=AlarmUnits
 :minutes
X
 ;MEMBER=AlarmLength
 :15
X
 ;MEMBER=RecurUnits
 :years
X
 ;MEMBER=RecurInterval
 :1
RRULE
 :FREQ=YEARLY;INTERVAL=1;BYMONTH=2
DTSTART
 :20020214T000000
DTEND
 :20020214T235900
END:VEVENT

  The correct output should be, according to the spec:

BEGIN:VEVENT
UID:959420326
SUMMARY:Valentine's Day
DESCRIPTION:The day we show our loved ones how much we care.
LOCATION:In our hearts
CLASS:PRIVATE
X;MEMBER=AllDay:TRUE
X;MEMBER=AlarmUnits:minutes
X;MEMBER=AlarmLength:15
X;MEMBER=RecurUnits:years
X;MEMBER=RecurInterval:1
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=2
DTSTART:20020214T000000
DTEND:20020214T235900
END:VEVENT

While line folding is permitted by the spec, it is only after 75 octets of data,
and with line breaks _after_ the tag-value separator (':'), not before.  The
production rule for content lines is:

     contentline        = name *(";" param ) ":" value CRLF

This is causing parse errors in at least one iCalendar parser library I'm
working with.  It would appear that the line folding algorithm is in error, and
is improperly folding lines.

Reproducible: Always
Steps to Reproduce:
1. Generate an iCalendar file from Mozilla Calendar
2. Look at it with an editor, and compare it with the spec.


Actual Results:  
The generated data is incorrect, and contains extraneous line feeds and spaces
where they do not belong.

Expected Results:  
Generated iCalendar data that conforms to specs.

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

> While line folding is permitted by the spec, it is only after 75 octets of
> data, and with line breaks _after_ the tag-value separator (':'), not before.
No, it should fold before 70 chars, not after.

i'm not sure if the second part is correct:

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

So first unfold, then apply the bnf. (which must be the case, otherwise you
can't use newlines at all. they can't be part of 'value')

the folding procedure doesn't limit the place of the newline:
   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

note the _any two characters_

Comment 2

[Brad BARCLAY]

(In reply to comment #1)

> No, it should fold before 70 chars, not after.

  Actually, according to the RFC, it's 75 octets, not 70.

> So first unfold, then apply the bnf. (which must be the case, otherwise you
> can't use newlines at all. they can't be part of 'value')

  The assumption that you can fold anywhere you want appears to violate the
spirit of the specification.  If this were the case, you could put a fold right
in the middle of a tag, ie:

DESC
 RIPTION
 :The day we show our loved
  ones how much we care.

It seems obvious to me that this is not what the specification intended. 
Indeed, the specification only requires line folding if the line would otherwise
extend beyond 75 octets.  Mozilla Calendar is folding even when it's completely
unnecessary.  All of the RFC's examples only show folding within the value
portion of a content line, and not _prior_ to the name-param-value separator.

In the end, Mozilla Calendar shouldn't be needlessly folding lines when it isn't
necessary.  Doing so goes against the spirit of the RFC IMO, and I'd like to see
this fixed.

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #2)
> > No, it should fold before 70 chars, not after.
>   Actually, according to the RFC, it's 75 octets, not 70.
Sorry, typo. You are right.

>   The assumption that you can fold anywhere you want appears to violate the
> spirit of the specification.

Maybe, but not the actual spec. I don't think the current way to fold is wrong.
It may not be the best way, but i don't see a real problem with it.

Comment 4

[gekacheka]

If the troublesome parser is really a vCalendar 1.0 parser, you may be able to
work around it until the parser is fixed by exporting to vCalendar 1.0 format via 
  File | Export selected events
    Save as type: vCalendar Files

Comment 5

[Brad BARCLAY]

(In reply to comment #4)
> If the troublesome parser is really a vCalendar 1.0 parser, you may be able to
> work around it until the parser is fixed by exporting to vCalendar 1.0 format 

No, the parser is an iCalendar parser.

For now I'm going to write a stream handler to unfold the file prior to
processing.  However, I'm still of the opinion that Mozilla Calendar is in abuse
of the specification and needs to be fixed to meet the intent of the
specification, and not add folds where they aren't necessary or required.

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

The latest libical from cvs indeed seems to create non-wrapped lines. Setting as
depending on the bug to upgrade libical

Comment 7

[Joey Minta]

Trunk doesn't seem to break the lines in this way anymore.  Resolving WFM, since
there's no specific bug/patch to point to.

Comment 8

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!