Re: John Scudder's No Objection on draft-ietf-httpbis-digest-headers-12: (with COMMENT)

[Roberto Polli <[e-mail]>]

Dear John,

thanks for your feedback.

On Tue, 23 May 2023 at 19:51, John Scudder <[e-mail]> wrote:
> > On May 23, 2023, at 1:41 PM, Lucas Pardue <[e-mail]> wrote:
> >
> > In "Since it is possible for there to be variation within content coding, the
> > checksum conveyed by the integrity field cannot be used to provide a proof of
> > integrity "at rest" unless the whole (e.g., encoded) content is persisted.", do
> > you actually mean "i.e." and not "e.g."?
> >
> > Probably? :-D
> >
> > We can change it and can let the RFC editor be the final arbiter.
>
> OK, though FWIW this is one of those fiddly bits I prefer to not leave to the RFCEd’s discretion since it comes down to what your intent is, it’s not a stylistic question. The simple rule of thumb I use is to read “e.g.” as “for example” and “i.e.” as “in other words”. That expansion usually makes it crystal-clear which one to use, but not knowing your intent, I couldn’t be sure. (For this same reason, I try to eschew using these abbreviations at all in specs I write, although I’m sure there are many examples where I’ve done it anyway).

I agree we can remove this abbreviation.
The original title of this section was "Usage with Encryption":
the text mentions then encoding to highlight the possible relations between
encryption and content coding.

Since the section title is now "Varioations Within Content Encoding",
I think it is ok to remove the `(e.g., encoded)` text.

See https://github.com/httpwg/http-extensions/pull/2554

@[e-mail] WDYT?

Have a nice day,
R.