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

[Lucas Pardue <[e-mail]>]

John, Roberto

On Wed, May 24, 2023 at 9:18 AM Roberto Polli <[e-mail]> wrote:

> 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,
>

Point taken! Roberto's recollection of the history is good so I merged his
editorial suggestion to begone with abbreviations.

Cheers,
Lucas