Bug#509935: decide whether Uploaders is parsed per RFC 5322
I think we've discussed this before, but I didn't see an open bug, so
I'll open one so that we can discuss it in one place.
Policy currently says the following about the Maintainer field, which
applies by reference to the Uploaders field:
The package maintainer's name and email address. The name should come
first, then the email address inside angle brackets <> (in RFC822
If the maintainer's name contains a full stop then the whole field
will not work directly as an email address due to a misfeature in the
syntax specified in RFC822; a program using this field as an address
must check for this and correct the problem if necessary (for example
by putting the name in round brackets and moving it to the end, and
bringing the email address forward).
Most software has taken this to mean that the e-mail address should be
in RFC822 format, not that the whole field should be.
This is primarily posing a problem for people who have commas in their
name. The main example to date is Adam C. Powell, IV, but it can happen
with various other name qualifiers and honorifics. Currently, the only
way to express such a name that works with our existing tools is to drop
the comma, since several programs blindly split on commas when parsing the
The most fully technically correct approach would be to require a full
RFC 5322 parse, but that adds a lot of complexity and raises the problem
that there's no standard canonicalization of RFC 5322 header fields. It
becomes unclear whether one should strip off double quotes, remove
blackslashes, remove portions in parentheses, or other things that would
be logical to do from the RFC 5322 grammar.
Alternatively, we could document the permitted character set for the name
portion of the Maintainer field and exclude commas. It's annoying to do
this since commas have been supported in the past (in Maintainer, they're
unambiguous) and have only become a problem in Uploaders. We could only
restrict them in Uploaders, but the lack of symmetry strikes me as a bad
We could also standardize a simple escaping mechanism of our own (allow
double quotes, for example, but require that, if used, they surround the
entire name and are stripped off by the parsing).
However we resolve this, we should probably also update the referece in
Policy to RFC 822 to refer to RFC 5322 instead, since I doubt we really
want to support source-routed e-mail addresses or similar bizarreness in
Debian control files.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
debian-policy depends on no packages.
debian-policy recommends no packages.
Versions of packages debian-policy suggests:
ii doc-base 0.8.18 utilities to manage online documen
-- no debconf information