Bug#521810: debian-policy: Document user defined fields starting with X-
Raphael Hertzog <hertzog@debian.org> writes:
> On Mon, 30 Mar 2009, Manoj Srivastava wrote:
>> If so, that seems like a bad design; I wonder if we can just fix that
>> instead.
Sorry, I withdraw this completely -- I didn't think it through. This
creates the same problem in a different way.
> Unknown fields are ignored (and warned) unless you prefix them with some
> X[BCS] to precise your intent (you indicate that those are unknown fields
> that you want).
> Keeping the X- prefix when copying fields would mean we could never
> invent new fields without forcing a mass rename of fields once they are
> official. Or we could not add official fields if we use an old dpkg-dev.
Indeed, that's a serious problem.
I believe this patch should be rejected and behavior left as-is, with
users not told to add an extra X- to their fields. Conflicts can be dealt
with as they come up.
RFC 822 used this same X- convention. It is now widely recognized in the
e-mail standards community that it was a horrible idea that never should
have been introduced. I'm fairly sure that if the IETF had it to do over
again, they would not introduce X- fields. They turn out to cause way
more problems than they solve, force mass-renamings of fields once they
become official, and result in X-* headers persisting as quasi-standards
without ever being fully standardized because they can't be standardized
with the X-* prefix.
The general feeling in the e-mail community is that it's better to deal
with the occasional collisions with user-defined fields and force everyone
into the same namespace, possibly with a supporting registry so that
people running experiments can reserve the header and there's some
documentation for what people have used the header for in the past. The
use of a separate namespace for experimental or user-defined fields just
confuses matters without much benefit.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: