Re: Genart last call review of draft-ietf-httpbis-bcp56bis-13

Thanks Mark!

Your explanation of the interaction with MASQUE makes sense to me and
addresses my minor issue, and your commit fully addresses my nits.

My GenART review result is now "Ready" with no further comments.

David

On Thu, Aug 12, 2021 at 5:23 PM Mark Nottingham <mnot@mnot.net> wrote:

> Hi David,
>
> Thanks for the feedback. Responses below.
>
> > On 13 Aug 2021, at 4:36 am, David Schinazi via Datatracker <
> noreply@ietf.org> wrote:
> >
> > Minor issues:
> > * s4.5 seems to prohibit defining new non-generic HTTP methods. How do we
> > reconcile that with the work happening in MASQUE? I know that CONNECT is
> its
> > own special-case, but should we have a carveout here? (Though MASQUE
> might end
> > up using extended CONNECT which side steps the issue). Or is it the case
> that
> > MASQUE is modifying HTTP itself instead of building an application over
> HTTP?
>
> That is only restating the requirements of HTTP:
>
> 'Unlike distributed objects, the standardized request methods in HTTP are
> not resource-specific, since uniform interfaces provide for better
> visibility and reuse in network-based systems [REST]. Once defined, a
> standardized method ought to have the same semantics when applied to any
> resource, though each resource determines for itself whether those
> semantics are implemented or allowed.' --
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#method.overview
>
> 'Standardized methods are generic; that is, they are potentially
> applicable to any resource, not just one particular media type, kind of
> resource, or application. As such, it is preferred that new methods be
> registered in a document that isn't specific to a single application or
> data format, since orthogonal technologies deserve orthogonal
> specification.' --
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#considerations.for.new.methods
>
> That said, I don't see MASQUE as an application of HTTP; it's a generic
> extension.
>
>
> > Nits/editorial comments:
> > * s3.2 uses the term "link" without explaining what it is. Perhaps a
> reference
> > to RFC 8288 if that's what is meant here? * s4.11 mentions HTTP/3 without
> > referencing its specification
>
> See:
>   https://github.com/httpwg/http-extensions/commit/70c3ee4dde
>
> Cheers and thanks again,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>