Re: Working Group Last Call: draft-ietf-httpbis-safe-method-w-body-10

Hi Julian, 


Thanks for looking into my comments. A few residual fixes/comments:

* In B.11, it should say:
    * Martin Thomson instead of martinthomson to be consistent with other names
    * Address most *of* Rahul Gupta's additional feedback (https://github.com/httpwg/http-extensions/issues/3101) (link is to a GitHub Issue not PR "/pull/")

Some other observations interleaved: 



On Sunday, May 18th, 2025 at 1:52 AM, Julian Reschke <julian.reschke@gmx.de> wrote:

> Rahul,
> 

> thanks a lot - it's good to fix these things early (for some value of
> "early").
> 

> -> https://github.com/httpwg/http-extensions/issues/3101
> 

> 

> Am 16.05.2025 um 15:05 schrieb Rahul Gupta:
> 

> > * In section 3, para 2, it says, "Parameters, if any, are mapped to Parameters of type String." Later in para 7 it says, "The only allowed format for parameters is String".
> 

> 

> Fixed.

Unless I am misunderstanding the context, I was pointing out the repetition between para 2 and 7, which still remains. Now, with the change, the two statements are inconsistent about String and Token.

Now that I am reading it again, I feel paragraph 2 can be rephrased to be more clear: "... containing the media range value without parameters. Parameters, if any, are mapped to Parameters of type String." The impression it created (when I was not reading carefully) is that media ranges value are without parameters, and then immediately later it can have parameters. I had to reread the text a few times to understand!

> 

> > * Some instances of Accept-Query in section 3 are quoted and others are not. The practice, say, in RFC9110 is to quote the first instance of a term in the first paragraph under a heading and no others. My own instinct would be to wrap all instances as <tt>Accept-Query</tt> as this reads better in HTML, but certainly it is not the practice.
> 

> 

> The last part is a matter of taste, but I'm ready to be convinced
> otherwise (feedback appreciated).
> 

> > * I would also prefer not to write "Accept-Query's value" but say "Value of the Accept-Query field" instead, but again, it is not really a nit.
> 

> 

> Fixed.
> 

> > * In Section 2, last paragraph and Section 2.2, Status Codes are not referenced, unlike most other places in the document.
> 

> 

> Fixed.
> 

> > * You might like to cross-reference "safe" and "idempotent" with RFC9110, say, in section 2.
> 


I was thinking along the lines of linking to safe and idempotent sections individually. Idempotent is something that particularly seems to trip up people who are not familiar with RFC9110 and the crossref could be beneficial to readers. But I understand if you find that too noisy.

> 

> Fixed.
> 

> > * The document has almost no internal cross-linking of terms. I use kramdown-rfc, so I get it almost for free. Not sure at what stage this is done?
> 

> 

> This can get very noisy and somewhat interrupts the flow; so I would not
> want to do it too much.
> 

> > * Shouldn't the new examples in the appendix demonstrating a specific feature also have links back to the relevant sections?
> 

> 

> Done in some cases.
> 

> > * Is it intentional that in most examples in the appendix, you do not set an Accept-Query response header? I understand it is optional, but it might signal a good practice to be seen setting it.
> 

> 

> Well, there's one. The idea is not to distract from what the example is
> about.

Maybe you can say something to the effect of "The Content-Length and Accept-Query (except in A.3) fields have been omitted for brevity".

> 

> Best regards, Julian

BR/Rahul