YAW x 3

[Simon Bowring]

[Yet Another Wish - actually 3 of them]

1. User's charsets

It'd be nice if we could configure a default charset encoding against
individual users in the address-book, so that if their emails lack 
charset="..." lines, then we could still say that "this guy" uses 
ISO-Latin-1, and this other guy uses Latin-2, Win1252, CP850, CP437 
or whatever.  The default should be US-ASCII (I think!)

I've just been speaking to a swedish guy who is evaluating PMMail/2 
("Ulf" for the benefit of Trever - I think he's been in touch).  He's 
receiving swedish  emails with no charset specified, and he was 
getting incorrect glyphs. These messages look ok in NS, which I guess 
defaults to Latin-1, since that's what the HTML spec says.

I believe he's happy now, having got the latest (v.cunning) filter to
leave HTML mail on the server!!!

I've been checking the RFCs, and I *think* in this case the charset 
assumed by the reader should be ASCII (but I could easily be wrong).


2. Support for the Win1252 charset (for encoding and decoding)

This is the Windows so-called ANSI charset (they call it the ANSI
charset because it is *not* ANSI (why else?), but it is a 
slight/near superset of ISO-Latin-1).

There are two reasons for supporting this (on OS/2).

1. There are so many Windows weanies and dodgy mailers out there
2. It would allow us to transmit the Euro currency symbol in a 
   "deterministic" and standards compliant way!

[I assume if you run PMMail for Windows, and turn char set translation 
off (possible selecting ASCII encoding as well?), you effectively get 
the Win1252 encoding, however on OS/2, I think you will get whatever 
codepage you have set.  In either case I think extended 8-bit glyphs 
will only be represented as intended in the recieving PMMail, if all 
parties have the same settings (and codepages)].


3. MIME's in-line content disposition

I *may* have requested this once before (albeit with slightly different
emphasis).  I'd like tin-line content disposition to be obeyed (at
least for textual mime parts, if not for others).

I get a lot of email from lotus notes users ("my comments are in 
blue" ;-), and one of the many unusual but legal things it does, is 
change charset half-way through a message to allow alternative glyphs 
to be specified, in this case it has done it just for an apostrophe 
(but one slanting like an acute accent - the "opposite" of "`"):


>Mime-Version: 1.0
>Content-type: multipart/mixed; 
>	Boundary="0__=y1vpW9kABJuql75p96VtHj0Wva953nElYRnSqcUEJi3LbtZR6TTuG858"
>Content-Disposition: inline
>Status:   
>
>--0__=y1vpW9kABJuql75p96VtHj0Wva953nElYRnSqcUEJi3LbtZR6TTuG858
>Content-type: text/plain; charset=us-ascii
>Content-Disposition: inline
>
>Hello Simon,

... much deleted, but note we started in ASCII above, and now
    we switch to Latin-1 for the slanty apostrophe (=B4)...

>second situation: a) inability of the administrators (error, typo etc.)
>                  b) limit of number of DN ranges reached for this switch
>                     by splitting DN ranges into smaller one
>--0__=y1vpW9kABJuql75p96VtHj0Wva953nElYRnSqcUEJi3LbtZR6TTuG858
>Content-type: text/plain; charset=iso-8859-1
>Content-Disposition: inline
>Content-transfer-encoding: quoted-printable
>=B4s and the 
>                        other x thousend lines are the unimportent shabby r=
>est ;-)

The above should have been simply displayed something like:

>Hello Simon,

... much deleted...

>second situation: a) inability of the administrators (error, typo etc.)
>                  b) limit of number of DN ranges reached for this switch
>                     by splitting DN ranges into smaller one's and the 
>                     other x thousend lines are the unimportent shabby r=
>est ;-)

PMMail makes the message appear truncated before the apostrophe in "one's"
and the rest of the message (most of it in this case) appears in an 
"Unnamed Attachment.ATT" in the attachment area!

It'd be real nice if non-text in-line mime types were represented "in-line"
(somehow) too!

Simon