[Ietf-calsify] Issue 1: new proposed text

[Tim Hare]

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 at osafoundation.org
[mailto:ietf-calsify-bounces at 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 <McQuilWP at pobox.com>

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify at osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify