Ian Jackson 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 ca
Suggested approach.
Gosh there's a lot of decisions to make!
Ian.
## 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 em
On Fri, Jun 13, 2025 at 11:47:08AM +0100, Ian Jackson wrote:
> It was always my intent that this field would in be a subset of
> RFC822/5322 sender/recipient field formt.
>
> We should never have diverged from 822 here. So that we ever
> permitted commas in the name part was an egregious mistake.
Andrey Rakhmatullin writes ("Re: Bug#401452: Standardize syntax of the name in
the Maintainer control field"):
> On Fri, Jun 13, 2025 at 11:47:08AM +0100, Ian Jackson wrote:
> >Furthermore, we have the Uploaders field now. Clearly Maintainer and
> >Uploaders ought
On Fri, Jun 13, 2025 at 11:47:08AM +0100, Ian Jackson wrote:
It was always my intent that this field would in be a subset of
RFC822/5322 sender/recipient field formt.
We should never have diverged from 822 here. So that we ever
permitted commas in the name part was an egregious mistake.
IMO th
It was always my intent that this field would in be a subset of
RFC822/5322 sender/recipient field formt.
We should never have diverged from 822 here. So that we ever
permitted commas in the name part was an egregious mistake.
IMO the only question for this bug is is precisely what subsets of 82
6 matches
Mail list logo
