Re: subject decoding

[Frederic Gobry]

> This would be a good way, as long as it takes more than a word, I
> think it needs to take an entire header field value.
> 
> So, you can call header_aget_field_value(), then, if you need to
> display it, you could call:
> 
> rfc2047_decode_field () on the value.

Sure. The function name is misleading, but this seemed to be the
official term in the RFC. It will decode / encode a complete string of
course.

> As far as I can see, it is not possible for header_aget_field_value() to
> do it internally, because it involves converting from the MIME character
> set that the field value is encoded in to the character set used by
> whatever display device the application is using, and how is it supposed
> to know that? If it was sieve, for example, it shouldn't be converted
> to the terminal's character set, but to utf-8, because all sieve
> field comparisons are supposed to be made against headers that have
> been canonicalized to utf-8.

I intended only to manage the _transfer_ encoding (this reminds me that
the function should also return the content encoding). To do it in the
header_aget_field_value() would only require to check if the mail uses
MIME or not (so that non-RFC2047 mails won't be corrupted).

> Also, only some headers are allowed to have MIME encoded multi-lingual
> tokens, but people can add headers and define them as being in that 
> set. The header_() API would have to know not only the character
> encoding you want, but also whether each specific header field is
> allowed to be 2047 encoded.

For fields having a defined syntax (like those containing addresses),
decoding could be performed transparently when one accesses the
address_t structure for instance. But are all those fields mapped to
structures ?

Frédéric

pgpKGbfQvclQe.pgp
Description: PGP signature