W3C home > Mailing lists > Public > uri@w3.org > July 2005

Re: email address in a URI

From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Tue, 12 Jul 2005 08:16:49 +0200
To: uri@w3.org
Message-ID: <42D36051.5D19@xyzzy.claranet.de>

Etan Wexler wrote:
> are you implying that the <NO-WS-CTL> characters are obsolete
> in e-mail addresses?

Not used in practice as far as I can judge it.  Funny escape
sequences causing all kinds of havoc with simple MUAs are a
bad idea, nobody needs or does this.

> Should RFC 2822 get a revision?

IMHO a 2822bis should move NO-WS-CTL to chapter 4 (obsolete).

> Does either answer affect what route the ?tag? scheme should
> take?

It depends on your priorities, if your priority is "any legal
address should be allowed" you need NO-WS-CTL plus the syntax
for this crap plus (maybe) security considerations.  If your
main priority is a readable text without tons of obscure rules
all you need is a statement that you excluded some ugly cases.

> Will software authors screw this up?

PURL is a case where I know that they decode URLs, %25 instead
of % does the trick (e.g. %2520 results in %20, i.e. a space).
> is it proper that the ?tag? scheme flatly ban the use of
> e-mail addresses with ?percent? signs?

Somewhere you draw the line, it's your decision.  Banning a %
only to avoid %25 sounds like a bad decision.

> a lousy programmer can make a security problem out of any
> situation.

True, but if you support encoded NO-WS-CTL you have no reasons
to exclude other syntactically valid addresses, so in that case
just support everything (minus CFWS, modulo obs-, i.e. isolated
CR or LF not included in NO-WS-CTL)

> to me, the question is about the probability of software
> authors screwing it up and about the scale of the screw-up.

"Take local part as is and encode" is simple.  If you start to
explain quoted-string, quoted-pair, and semantical content to
get a shorter and nicer '...'@example it's not so simple, YMMV.

                             Bye, Frank
Received on Tuesday, 12 July 2005 06:19:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:09 UTC