Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> ## Fields giving names and email addresses (entity and email fields)

> The format of the content of all fields naming people including
> Maintainer, and Uploaders are based on IETF RFC 5322 recipient fields
> (e.g., "To:" fields in emails), with some modifications.

> We call these "entity and email fields".

> Informally:

>  * The field is a comma-separated list of `name <email>` where `name`
>    can be quoted `"name"` (and may then contain Unicode), or be
>    unquoted but then has a restriccted character set which excludes
>    Unicode and excludes `,`.

I think this first point is the one that poses the most backward
compatibility issues. The main reason why I have, in the past, looked at
this bug and then decided not to work on it is that I'm not sure how to
reconcile two quite reasonable competing goals:

1. The Maintainer and Uploader control fields should be easily usable as
   email addresses.

2. The Maintainer and Uploader control fields do not have the long history
   of backward compatibility challenges of RFC 5322 and existing practice
   and the current specification are looser. In particular, the current
   specification doesn't require people with non-ASCII names to add extra
   punctuation around their name, which would feel icky, at least to me.

In the past, we had at least one Debian maintainer who had a comma in
their name. The relevant software mostly handled that correctly in the
Maintainer field. I'm not sure if that's still the case.

Before we make changes here, I think we need to understand the blast
radius. Maybe someone can do some work in UDD to figure out how many
packages would be affected if we were to tighten up the syntax here?

Requiring quoting for commas (and any other reserved RFC 5322 punctuation)
makes sense to me, since that's really going to break otherwise if one
attempts to use Maintainer in the To field of an email message. I'm a bit
less willing to require non-ASCII be quoted; all of the control fields are
specified as being UTF-8 at this point, and I feel like most email sending
libraries should be able to cope with UTF-8 in the name even if RFC 5322
still requires weird escaping. But maybe that belief is too optimistic.

-- 
Russ Allbery (r...@debian.org)              <https://www.eyrie.org/~eagle/>

Reply via email to