- From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Date: Fri, 26 May 2023 02:40:16 -0400
- To: Mark Nottingham <mnot@mnot.net>
- Cc: ietf-http-wg@w3.org
> > On 26 May 2023, at 3:47 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > > > -------- > > Julian Reschke writes: > > > >> At the end of the day what matters is that we have that capability, as > >> opposed to not having at all. > > > > We /already/ have that capability: Put the UTF8 safely in a sf-binary field. > > > > If you want to "label" it, put a parameter on it saying what it is. On Fri, May 26, 2023 at 04:15:22PM +1000, Mark Nottingham wrote: > 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. For the sake of security and robustness, is every SF field parseable, able to be validated, and canonicalizable, with the exception of sf-binary? I would like to see sf-binary as the sole exception, there to provide extensibility when no other SF field is a better choice. After all, structured fields should be well-defined and well-structured. If SF-display is SF-binary but with type info 'display', then is 'display' really a "fundamental" type? I can more easily see that "integer" is a fundamental type. Cheers, Glenn
Received on Friday, 26 May 2023 06:40:29 UTC