[Ietf-calsify] Status of simplification work

[Arnaud Quillaud]

If we really want to change anything regarding this folding (and hence break backward compatibility with older ical parser/generator), I would vote for simply removing the 75 octets limit, not change it to 75 characters.

The spec itself does not mention why it puts such a limit. It would be interesting to know the historical reason that made it appear.

About the email legacy MTA problem:
The ical spec is supposed to be "formatted as a registration for a MIME media type". MIME is already describing and taking care of the legacy SMTP server problem. If an application is generating emails containing ical attachments (or ical directly in the body), it should use one of the content-transfer-encoding defined by MIME. 

About ical being more readable:
The fact that ical is text based is great for debugging purpose. But do you usually really care about lengthy text fields when debugging ?
What is the real life use case for this readability of long lines ?
Does the XML specification require folding of lines > 75 octets ? If not, did its addoption suffer from it ?

That said, Im not sure it would be wise to break backward compatibility for this.

Arnaud Q

> -----Message d'origine-----
> De : ietf-calsify-bounces at osafoundation.org 
> [mailto:ietf-calsify-bounces at osafoundation.org] De la part de 
> George Sexton
> Envoyé : jeudi 25 mai 2006 16:00
> À : Chuck Norris
> Cc : ietf-calsify at osafoundation.org
> Objet : Re: [Ietf-calsify] Status of simplification work
> 
> 
> Actually, I think its a pretty reasonable question. The wrap 
> requirement 
> only serves one useful purpose. It makes the files readable in a text 
> editor.
> 
> Any suggestion that the 75 octet limit on lines it makes the 
> I/O easier 
> is incorrect. First of all, anyone that's doing line I/O using fixed 
> width buffers is just waiting for a buffer overflow attack.
> 
> In this time of multi-megabyte attachments, flash, JPGs, and other 
> binary trash floating across the Internet, suggesting that a 75 
> character line limit is going to accommodate some antique piece of 
> communications hardware just seems unlikely.
> 
> Personally, I'm really back to where I started. Octets should 
> be changed 
> to characters. This will simplify writing correct software 
> and result in 
> a file that is human readable in a text editor (or Email client...).
> 
> The point here is simplification. Proving that the exact 
> language of the 
> current specification can be met by adding a function, and some error 
> prone character break/line wrapping logic does nothing. It 
> will result 
> in a portion of the spec that people either don't comply 
> with, or that 
> they do wrong. Neither of these improves interoperability.
> 
> 
> 
> Chuck Norris wrote:
> > It's a stupid question probably, but is it even possible to consider
> > removing the fixed line-length requirement?  I know our 
> parser doesn't 
> > actually care how many octets are in a line, and works fine 
> no matter 
> > how long the lines are.
> >
> > Chuck
> >
> > On May 25, 2006, at 9:00 AM, Reinhold Kainhofer wrote:
> >
> 
> -- 
> George Sexton
> MH Software, Inc.
> Voice: +1 303 438 9585
> URL:   http://www.mhsoftware.com/
> 
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org 
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>