> Dusting off this particular bit of ancient history...
> --On Wednesday, 17 October, 2007 09:46 -0700 Pete Resnick
> <[EMAIL PROTECTED]> wrote:
> >
> > I've copied this conversation over to ietf-822, since I think
> > that will probably be where this issue is addressed.
> >
> > On 10/17/07 at 6:51 AM -0700, [EMAIL PROTECTED] wrote:
> >
> >>> Peter J. Holzer wrote:
> >>>
> >>>> Which reminds me: What is the reason for allowing control
> >>>> characters in email addresses?
> >>>
> >>> Idiocy.
> >>
> >> I try hard to stay out of these sorts of debates, but in this
> >> case I am forced to agree. We are way past the point where
> >> backwards compatibility is an acceptable excuse for
> >> something like this. It should be obvious why allowing
> >> nonprinting control characters in addresses is a bad idea on
> >> many levels.
> >>
> >> And if common sense isn't enough here, how about the fact
> >> that it is pretty clear that these things have obvious and
> >> severe interoperability problems that will make it hard to
> >> meet the criterua for draft standard?
> >
> > Right now, control characters are allowed in the following:
> >
> > - Domain literals on the right hand side of addresses
> This is the one that affects 2821bis. The control characters
> cannot appear in either IPv4 address or IPv6 address domain
> literals. They can, in principle, appear in General Address
> literal, but those require standards track action, etc., and one
> could easily cut them off there. In other words, they are
> permitted in principle, but prohibited in practice and are going
> to stay that way. It is therefore probably safe to let this
> go.
Agreed. The issue is really with 2822. 2821's rules for defining new address
literals offer sufficient protection IMO.
> I'm not going to do any for the version of 2821 that I intend to
> post later tonight, but, if there is consensus that it is time
> to do away with the puppies (and I am very much in agreement
> with Ned that they should go), it may be time to invent a new
> metalanguage rule for, e.g., "pcontent" (for printable) which
> consists of characters in the ASCII range from 20 to 7E (hex).
Seems like a reasonable thing to do to me. The interesting thing is that
this excludes tab, and I actually think that's the right thing to do.
> Looking ahead to i18n issues, it may be desirable to have a
> similar rule for Unicode characters, but the characters can't be
> enumerated (in practice and to preserve version-independence) so
> the rule would have to be defined in terms of character class
> and properties.
I haven't looked at this in much detail but I suspect it's going to be tricky
to get right. For example, the tab issue, if you'll pardon the pun, expands to
include the many other ways of representing whitespace provided by Unicode. Now
think of how this might interact with BIDI rules...
> > - Quoted strings (which can be on the left hand size of
> > addresses as well as lots of other structured header fields)
> The address part of this is a little more problematic than the
> case above, but also easier, under the "you can screw only
> yourself by putting one of those addresses up on your server"
> principle.
> The rest of this is, indeed, a 2822 problem.
Yep, that's where it really needs to be dealt with.
Ned
