John, Roberto On Wed, May 24, 2023 at 9:18 AM Roberto Polli <robipolli@gmail.com> wrote: > Dear John, > > thanks for your feedback. > > On Tue, 23 May 2023 at 19:51, John Scudder <jgs@juniper.net> wrote: > > > On May 23, 2023, at 1:41 PM, Lucas Pardue <lucaspardue.24.7@gmail.com> > 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 > > @lucas.pardue.24.7@gmail.com 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
Received on Wednesday, 24 May 2023 13:42:48 UTC