Re: New Version Notification for draft-nottingham-http-structure-retrofit-00.txt

[Lucas Pardue <[e-mail]>]

On Thu, Oct 7, 2021 at 12:55 AM Mark Nottingham <[e-mail]> wrote:

> On 7 Oct 2021, at 10:48 am, Lucas Pardue <[e-mail]>
> wrote:
> >
> > Interesting!
> >
> > Question: is the intent that this is a one-shot pass or do you intend to
> set a methodology for how other headers can be mapped? For instance, we
> could keep the digest field in ABNF and use a similar methodology to define
> SF-digest alongside it in the digest spec.
>
> That's a good question, and I'm punting on covering it in-spec for now.
>

Make sense.

One approach is to assume that new headers will be defined as SF, so
> there's no need. As long as this spec carves off the top n% (n~80-90), it's
> adequate for most purposes.
>
> Another is to allow further specs to retrofit additional headers in the
> same fashion.
>
> Another is to let specs retrofit themselves, as you suggest for Digest.
>

My question was also loaded towards the segment of people that use HTTP and
never put it in an open spec because they have no need for broad interop.
For example, if x-custom-thing was used between internal services then
there could be benefit in trying to align all header handling towards
structured headers without having to go and think hard about writing a spec
about it. Trying to define some generic framework for those folks is likely
going to fail so the I-D does right to avoid that trap. But a clear
statement along the lines of "the approaches in this document could be
applied to other HTTP fields" might stop a team bickering about the
practicalities of such a switch.

Cheers
Lucas