Re: Bug reported regarding Unicode handling in email address

[Ralph Corderoy]

Hi Ken,

> > But my point stands.  nmh should know from the context where the
> > email address appears what encoding the bytes use when trying to
> > parse it.
> > 
> > - mail/inbox/42 was written by us; it's our choice.
> > - mail/draft is the process's locale.
> > - /var/spool/$LOGNAME is in UTF-8.
>
> Right, but ... reality rears it's ugly head.
>
> The address parser is a bunch of layers down.  And it's used for a lot
> of things.  For example, stuff from .mh_profile can end up being
> parsed by it.  We'd have to change the internal API to indicate where
> an address is coming from and I think we'd have to change it almost
> everywhere.

I quite agree the current code greatly hinders doing anything about
this.

> And then, to get back to my original point ... if we see an 8-bit
> character that is not valid in the current character set, what,
> exactly, should we do about it?

Complain precisely, e.g. pathname, line number, column, encoding
expected, byte(s) seen.  I'd expect an nmh user to want to understand
how the parts of their system work and where something has gone wrong
and a good error message will help diagnose problems rather than just
passing duff data on so it causes problems further away from the origin.

-- 
Cheers, Ralph.