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

Re: RFC 2822 email addresses in tag URIs

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 11 Oct 2005 13:01:56 -0400
To: Tim Kindberg <timothy@hpl.hp.com>
Cc: Etan Wexler <ewexler@stickdog.com>, URI Interest Group <uri@w3.org>
Message-Id: <20051011170157.6752C4EF11@homer.w3.org>


> In a nutshell, there are two poitions:
> 
> The position I began with ("simplicity") allows in tag URIs a few=20
> special characters allowed by RFC 2822, but no %-encoding and hence no=20
> quotes or "quoted pairs", among other things.  This position implies=20
> that e.g. "Fred Smith's uncle!"@example.com can't be used to mint tags,=20
> whereas Fred_Smith's_uncle!@example.com can -- without transformation.
> 
> The position I tried following feedback ("inclusivity") allows=20
> %-encoding.  So "Fred Smith's uncle!"@example.com could be used for tags=20
> but it becomes something that 99% of humans wouldn't be able to=20
> formulate correctly unaided: tag:%22Fred%20...
> 
> Maybe my experience is unusual but I never encounter email addresses=20
> using the new freedoms allowed by RFC 2822 -- which has been around=20
> since 2001.  So it's hard to argue strongly for "inclusivity" -- which,=20
> in addition, (a) turned out to add significant complexity to what is=20
> otherwise simple syntax, and (b) is only "inclusive" if you can (operate=20
> a program to) correctly transform your email address.
> 
> On balance, I'm inclined to follow my original advice -- and now Etan's=20
> -- and go for "simplicity".
> 
> Sandro, what do you think of all this?

Given that it's possible to include %-escapes later and not really
possible to remove them later if they are allowed now, I'm inclined to
go with the "simplicity" approach for now.  I have to admit, though,
that I don't really know much about the politics of these extended
e-mail address characters.

     -- sandro
Received on Tuesday, 11 October 2005 17:02:01 UTC

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