[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#509935: decide whether Uploaders is parsed per RFC 5322



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.

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.

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



Reply to: