Re: rough sketch of a potential solution

>> I don't know that problem3 is a real problem.  Do users really care 
>> what
>> the on-the-wire encoding looks like?  If so, why?
>
> For avoiding bugs.

Which bugs do you mean - the ones that you trigger when you expose 
existing software to formerly-illegal address formats, or the ones you 
get when encoded headers aren't displayed properly?

> Some things are easier to implement and debug than others. We want the
> simplest ones we can get.

Or maybe we want the least disruptive changes we can get.

> That means using a lot of plain text (printf-friendly, 
> debugger-friendly,
> programmer-readable, what have you) and established formats/encodings 
> such
> as UTF-8, where breakage is both less likely to occur and more likely 
> to
> be fixed than for custom inventions.

disagree.  I can't read UTF-8 if it's in a different script than the 
one I'm familiar with, and I suspect the same is true for most people.  
Having UTF-8 addresses in my log files would be much more difficult 
than having IMAA encoded addresses.

Nor is UTF-8 anywhere nearly universally supported.  If it were, for 
instance, the problem of printing IETF badges in multiple 
languages/scripts would be trivial, all that would be necessary is to do

x1 y1 moveto (Latin-String) show
x2 y2 moveto (UTF-8-String) show

in PostScript.