Bug#509935: decide whether Uploaders is parsed per RFC 5322
On Mon, Jan 19, 2009 at 12:36:56PM -0800, Russ Allbery wrote:
> Adeodato Simó <dato@net.com.org.es> writes:
>
> > I think we should *consider* do without commas at all, if losing them is
> > something we could live with. I realize that would be annoying for
> > people that have a comma in their name, so I'm not right away saying we
> > should forbid them. But I really think we should consider it, because
> > even if commas have to be quoted, you've already lost the ability to
> > parse the Uploaders field with split /\s*,\s*/, which I think would be a
> > loss, since that works for all other fields.
> >
> > (Oh, and if we do without commas, we should do without quoting as well
> > IMHO.)
>
> It would certainly make it easier for software.
>
> I have to admit to a personal bias (speaking as someone who goes by his
> middle name rather than his first name) in favor of fixing software to
> accurately recognize people's names rather than the other way around. I
> personally find software that refuses to recognize my name the way that I
> spell it to be quite obnoxious, so I'm sympathetic to people who have
> commas in their name. But yes, allowing commas, even quoted, does
> complicate Uploaders parsing quite a bit over the current simple state.
In any case, if commas are allowed, policy should spellout the
correct regexp to parse the Uploaders field.
> Bill mentioned the possibility of a Unicode comma other than the ASCII
> comma. Does such a thing exist? It's kind of a hack, but it's also an
> interesting compromise. I'm not sure why there would be such a thing,
> though, given that there's a perfectly good comma in the ASCII range and
> Unicode normally doesn't duplicate code points to no purpose.
I have the exact opposite experience with unicode :)
U+FF0C FULLWIDTH COMMA should do the trick.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: