On Mon, May 4, 2020 at 10:02 PM Mark Nottingham <mnot@xxxxxxxx> wrote:
Hi David,
Thanks for the comments. Responses below; I've committed in <https://github.com/httpwg/http-extensions/commit/001023>.
Thanks for making the changes! That commit looks good to me.
> On 5 May 2020, at 11:18 am, David Schinazi via Datatracker <noreply@xxxxxxxx> wrote:
>
> Nits/editorial comments:
>
> In s1.2 (Notational Conventions), I didn't understand what greedy meant in:
> In some places, the algorithms are "greedy" with
> whitespace, but this should not affect conformance.
Hmm, I think we can remove that sentence.
> In s2 (Defining New Structured Fields), perhaps "Reference this specification."
> should instead be "Normatively reference this specification.." ?
Sounds good.
> In s2, the definition of Foo-Example Header seems to be enclosed in
> "--8<--" and "-->8--" in the TXT version, could be a bug in the tools?
Our AD commented that it was difficult to distinguish the example spec text from the surrounding spec text in the text/plain rendering. These "scissor" marks were intended to serve that purpose; I suppose they're not as common as they used to be. My assumption is that the RFC Editor is going to propose a more suitable way to do this.
Ah! Now I see it :) Happy to let the RFC editor decide what's best here.
> In s3.1.2 and s3.2, in the example, I was confused by "a=?0" and "b=?0" until I
> s3.3.6.
> Perhaps reordering sections or adding a reference would help?
I think a reference.
> Should there be some guidance for defining new integer fields that don't fit in
> 10^15?
> Is a String the recommended approach?
I'm a little wary of giving a single recommendation here; it depends on the use case. It might be that it would be better to use two integers, for example, and add, multiply or otherwise combine them. Or it might make sense to implicitly multiple (e.g., *100) the value. Or it might make sense to yes, use a string -- or binary.
Sounds good. I was mainly curious because I defined a sh-integer in one of my drafts for a value that can in theory go up to 2^62-1, and I wonder if it's worth the added complexity to support values between 10^15 and 2^62...
But we can figure that out in the context of that draft, no need to answer that question in draft-ietf-httpbis-header-structure if there's no easy solution that fits all.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
