Hi David, Thanks for the comments. Responses below; I've committed in <https://github.com/httpwg/http-extensions/commit/001023>. > 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. > 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. Cheers and thanks again, -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call