Re: [w3ctag/design-reviews] BCP56bis (#232)

> Lack of an explainer

Right. Can you explain how that would be helpful here? Please keep in mind that this is *not* a W3C document, so we don't automatically adopt W3C conventions.

> What has changed between this and bcp56? (see point 1)

See appendix, [Changes from RFC3205](http://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#changes-from-rfc-3205).

> stronger on https? e.g. "any new http-based protocol should be https especially when protocols are using authentication tokens."

Created - https://github.com/httpwg/http-extensions/issues/568

> the language should be simplified to enable this to have a wider audience (Sangwhan to elaborate).

The audience is specifically IETF document authors -- see writeup above and [Introduction](http://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#introduction).

> having a specific section on options might be good. (e.g. "don't use options")

Created - https://github.com/httpwg/http-extensions/issues/567

> There should there be more discussion on other methods - currently only in-depth discussion on GET.

The intent here is to avoid re-stating everything in HTTP; if we have useful things to say about the methods that aren't already in the spec, absolutely. I suspect we'll be talking about at least PATCH as well, and probably POST.

> Section 4.12 "some considerations include" is vague. Whole section needs to contain more concrete advice. More examples needed.

Yes - that section is very active currently. Text welcome (but check the editors' draft first).

> perhaps adding a mention of variants.

Possibly; we're not at a stage where it's a sure thing yet.

> Linkage to data-on-the-web best practices?

Link?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/232#issuecomment-379448358