Note by Toltec

Tue Jul 13 20:58:59 CEST 2004

Hi David,

Please find attached version 2 of the note.

> OK. No problem. I opened the mail with KMail, and noticed 
> something though:
> The main Content-Type header had a newline in the middle of 
> the boundary, which broke decoding the message. I had to 
> remove that newline for kmail to parse the mail correctly. I 
> hope the newline was added by some tool you used for saving, 
> but wasn't in the original email?

Changed.

> > This avoids encoding issues. Headers must be UTF-7. Since I can not 
> > guarantee that this wall always be the case I quote encode 
> it. When it 
> > is parsed by the MIME library it should strip the quotes.
> 
> Our MIME library doesn't strip such quotes, I see a subject 
> of "1D53F6A800E34252B8BA11398FDE6C73" in kmail. Which makes 
> sense, otherwise actual quotes in the subject (added by 
> users) would be removed !?
> Since it's only letters and numbers, is there really a need 
> to quote-encode it?

Changed. We need to define the legal format of a UID to avoid encoding
issues.

> Now that I can check the XML: it doesn't use the latest 
> version of the tags at 
> http://www.sonofthor.dk/~bo/kolab/kolabformat.ps
> All the tags are mixed-case (like CreationDate) instead of 
> lower-case (like creation-date).

Fixed. Me and old specifications. :-)

> <Body>Kolab Test Note
> </Body>
> This looks like \r\n, where the \r got escaped... I don't 
> remember off-hand but I suppose the XML standard says a 
> newline is enough, i.e. the &#13 shouldn't be there?

The XML library encodes the carriage return. This is present in the body of
the note.

Best regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab-note-2.eml.gz
Type: application/x-gzip
Size: 1859 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20040713/2689fc67/attachment.gz>