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 <nore...@ietf.org> 
> 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/

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to