- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 26 May 2023 06:50:34 +0000
- To: Mark Nottingham <mnot@mnot.net>
- cc: "Julian F. Reschke" <julian.reschke@gmx.de>, ietf-http-wg@w3.org
-------- Mark Nottingham writes: > PHK, you could make this argument for *any* of the types already in SF > -- we don't need Integers when you can just stuff them in binary, after > all. Mark, that is a disingenious argument, and you know it better than any. I designed SF, and later you helped, make SF the largest possible union of current HTTP header definitions, while still trying to impose some kind of order. I did not encounter a single RFC which defined a field where integers were transmitted as anything but a sequence of ASCII digits. The information in HTTP fields is almost exclusively for machine-machine communication, and SF is an attempt to make that safer, saner and more resource efficient. There are a few occational "Show this to the human" bits of information at the HTTP field level, and there, and /only/ there, it makes sense to allow UniCode. But those fields have no semantic meaning at the HTTP level, they are not interpreted at the HTTP level, and therefore they should be transferred as opaque data, and the validation of them left to the upper layers of application software. Ie: sf-binary. Adding a "sort-of-human-readable" string encoding of UniCode fields makes things more complex, less safe and adds overhead for everybody, while adding no new functionality. This is a bad idea, and the PR is a bad execution of that bad ide. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Friday, 26 May 2023 06:50:42 UTC