Extra Header field

[David Faure]

On Monday 12 July 2004 14:40, Joon Radley wrote:
> Hi Martin,
> 
> > > > I like the idea because it speeds up the common case. But I think 
> > > > that the header should only be a hint for efficiency but not a 
> > > > requirement.
> > >
> > > Well if there is no header it is treated as a RFC2822/non-Kolab 
> > > message, so the XML format will be lost. It should be a requirement.
> > 
> > Putting a requirement in a mail header is dangerious on one 
> > hand (preserving headers is sometimes not guaranteed) and on 
> > the other I don't understand why in the case of the missing 
> > extra header the XML format gets lost.
> 
> Three storage use cases:
> 1) Single body part mail, where content-type is set to
> application/x-vnd.kolab.*.
Is this even supposed to work? The storage format document says the kolab-xml 
data should be an _attachment_. Which means the mail is multipart/mixed, doesn't it?



> Case (2) is the problem. Here you have to parse the entire message, look if
> any one of the body parts are application/x-vnd.kolab.* type and only then
> can you decide on the course of action. This can lead to double parsing of
> the same message. 
> 
> By adding a X-KOLAB-OBJECT header field to the header all use cases are
> satisfied by looking only at the header of the message. This header will
> only be stored on the IMAP4 server for kolab formatted messages and should
> never pass through a SMTP/LMTP gateway. 
> 
> By making the header optional you will have to parse all messages anyway
> before you can make the final decision, which totally negates the purpose of
> adding the header to the specification in the first place.
[I agree with this reasoning]

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions