Re: Consensus call to include Display Strings in draft-ietf-httpbis-sfbis

[Poul-Henning Kamp <[e-mail]>]

--------
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
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.