Subject: simple question about parsing

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 3 Mar 2003 15:01:05 -0500

I'm not clear on where folding whitespace is allowed.

My strict reading of it leads me to believe that

B
 E
 G
	IN:
 VCAL
 ENDAR
END:VCALENDAR

should be parsed the same as

BEGIN:VCALENDAR
END:VCALENDAR

I also don't see any minimum required sizes. Do I have to parse lines
up to 8k long? Longer? Are there any length limits on names or at
least minimums I might be required to preserve?

thanks,
Larry

---

From: "Chris Olds" <[email-masked]>
Date: Mon, 3 Mar 2003 13:26:04 -0800

I was going to disagree, but I reread 2445, and I think your interpretation is
correct.  I know that there are applications (e.g., MS Outlook) that treat the
sequence '\n ' as if it were a single space, but the example (sec 4.1, p 13)
makes it clear that '\n ' or '\n\t' should be removed as part of the folding
process.  I'm not sure what you're asking about wrt length limits on names
(what kind of names?), but as far as I can see, an iCanendar object can, in
theory, be arbitrarily large.

    /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 3 Mar 2003 16:29:56 -0500

From: "Chris Olds" <[email-masked]>
   Date: Mon, 3 Mar 2003 13:26:04 -0800

   I was going to disagree, but I reread 2445, and I think your
   interpretation is correct.  I know that there are applications
   (e.g., MS Outlook) that treat the sequence '\n ' as if it were a
   single space, but the example (sec 4.1, p 13) makes it clear that
   '\n ' or '\n\t' should be removed as part of the folding process.
   I'm not sure what you're asking about wrt length limits on names
   (what kind of names?), but as far as I can see, an iCanendar object
   can, in theory, be arbitrarily large.

In order to guarantee interoperability, many specs would say something
like: 'A "name" can be any size. Implementations MUST handle names at
least 1024 octets long.'

This way implementations can protect against denial-of-service attacks
but there's a guaranteed size that will interoperate.

Larry

---

From: Doug Royer <[email-masked]>
Date: Mon, 03 Mar 2003 15:35:25 -0700

> My strict reading of it leads me to believe that

    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.

Yes - however it is typical to break at the normal CRLF.

> up to 8k long?

You don't have to :-)
However your might get one.

> Longer?

Same as above

> Are there any length limits on names or at

As long as it is syntactically correct it makes no difference.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 3 Mar 2003 18:02:45 -0500

Date: Mon, 03 Mar 2003 15:35:25 -0700
   From: Doug Royer <[email-masked]>
[...]

   You don't have to :-)

I don't _have_ to do anything. However, my goal is to create
interoperable software.

[...]

This is easy for things I generate. If I am writing a calendar store,
I might try to store arbitrary objects generated by other
implementations.

Larry