The wildmat problem is a red herring. Wildmat implementations need to be
cognizant of Unicode in far more substantial ways than merely overcoming
punycode issues. A well-thought-out stringprep requirement will help
some, but then the stringprep has to be implemented.
This last point of Mark's is worth noting. Regardless of whether you end up
with UTF-8, punycode, UTF-7, or some other encoding of Unicode, a stringprep
profile is going to be required in order to move forward. It can either be
specified directly or indirectly as part of the underlying encoding, but it has
to be there.
Part of the problem with having a group take so long to complete its work is
that what's minimally acceptable to the IETF/IESG changes over time. It used to
be that protocol could just use some encoding of Unicode, end of story. No
more. Now that stringprep exists the IESG requires it be used when Unicode
protocol elements are involved. Several recent specifications have been
returned to their respective working groups because they didn't do this.
I note in passing that while the current News Article Format Draft talks about
normalization of group names, it does so without reference to stringprep. This
would need to change: Stringprep covers stuff besides normalization, and more
generally provides a checklist for Unicode usage each protocol needs to
consider.
I also note that Dan Kohn's alternative News Article Format draft uses
punycode, which already includes a stringprep profile.
Ned