- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 16 May 2018 10:40:44 +1000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, May 15, 2018 at 3:16 PM Mark Nottingham <mnot@mnot.net> wrote: > > You retain the hard upper limit on identifiers though. Is that really > > necessary? Or is this to preserve interoperability somehow? > I struggled with this; since it's used for dict and parameter names, it seemed reasonable to be a bit more constraining here. Happy to open it up if that causes discomfort. Yeah, not sure if it needs action, but it stands out a little. There's two competing concerns, in my view. If these identifiers are just implemented as pointers to the receive buffer, there is no real cost in allowing longer values. The concerns about string encoding don't really apply given the restrictive grammar you define. On the other hand, it is helpful to have some constraints on identifiers. But perhaps the most effective constraint we have is that people don't like insanely long identifiers for many other reasons. I'm leaning slightly toward removing the cap here too, and establishing a lower expectation for minimum supported length (say 64 octets).
Received on Wednesday, 16 May 2018 00:41:19 UTC