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/>