- From: Ariel Otilibili Anieli <otilibil@eurecom.fr>
- Date: Mon, 09 Apr 2018 09:19:38 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Mark, A comment inline. Regards, Ariel Quoting Mark Nottingham <mnot@mnot.net>: > Hi Ariel, > > Thanks for the review! > > Responses below: > >> On 8 Apr 2018, at 6:27 am, otilibil@eurecom.fr wrote: >> >> Hi Mark, >> >> Here is my review of this draft: >> >> 1. "At the same time, the Internet community has a tradition of >> protocol reuse (e.g., Telnet [RFC0854] as a substrate for FTP >> [RFC0959] and SMTP [RFC2821]), but less experience using HTTP as a >> substrate." >> >> If the "Internet community" means "Internet Engineering Task >> Force", the sentence should plainly state its name, and mention the >> protocols that the IETF has been building upon others, this >> includes at least RESTCONF [RFC8040]; the NETCONF working group has >> built it upon HTTP (the reviewer made them acquainted with this >> draft, >> https://www.ietf.org/mail-archive/web/netconf/current/msg14432.html). Maybe >> a survey to all the Area Directories? > > Yes. This is one of the few phrases from RFC3205 that has made it > through unchanged. That said, this isn't meant to be a complete > listing, just context. > > See: > https://github.com/httpwg/http-extensions/commit/c8b3454b28 > > >> 2. Unless one proves technical terms are legal persons, these >> sentences sound weird to me: >> * these protocols’ use of HTTP >> * HTTP’s URL schemes >> * an application’s specification >> * HTTP’s behaviour >> * the application’s deployment is brittle >> * HTTP server’s name space >> * server’s authority >> * HTTP’s complexity >> * the protocol’s ability to evolve >> * the URL’s origin >> * the Web’s same-origin policy >> * the response’s headers >> * an application’s state. > > I don't think it's confusing to use a colloquial possessive when > talking about the protocol; do you have preferred alternate phrasing > that isn't too awkward? Changing these to "The [object] of HTTP" > and similar seems clunky to me. Also, the RFC Editor tends to weed > out the worst issues of this nature. > > >> 3. "...the HTTP APIs defined by the IETF need to more carefully..." >> emphasizes better the work of the IETF than "...standards-defined >> HTTP APIs need to more carefully...". > > There's a bit of a line being walked here. While the main focus of > the document is IETF-defined protocols, other organisations do > define things based upon HTTP, and we don't want to exclude them if > they choose to adopt this. > > >> 4. Some underscored words come across the document: >> * using HTTP (twice) >> * protocols based upon HTTP >> * generic semantics >> * based upon HTTP >> * generic >> * as. > > Ah, this is an artefact of using Markdown; fixed (please tell me if > I missed any in the next draft). The full list in the current draft: # curl -sL https://tools.ietf.org/id/draft-ietf-httpbis-bcp56bis-03.txt | grep -Pn "_[\w\s]+_" 206: document, we say an application is _using HTTP_ when any of the 232: An application might not be _using HTTP_ according to this 238: Such applications are referred to as _protocols based upon HTTP_ in 294: Much of the value of HTTP is in its _generic semantics_ - that is, 373: [RFC0793] if not), or making the application be _based upon HTTP_, 664: IETF Review (see [RFC7232]), and are also required to be _generic_. 986: consider the application _as_ a Web application, and to follow best > > >> 5. Extra spacing in "e.g,. Cookie" (Section 4.7) > > Thanks. > > >> 6. "When an application is using HTTP, all of the requirements of >> the HTTP protocol suite are in force; the suite does at least >> include [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], >> [RFC7235] and [RFC7540]" >> >> Carries better than, >> >> "When an application is using HTTP, all of the requirements of the >> HTTP protocol suite (including but not limited to [RFC7230], >> [RFC7231], [RFC7232], [RFC7233], [RFC7234], [RFC7235] and >> [RFC7540]) are in force." > > Fixed, thanks. > > >> 7. "What is Important About HTTP", "a limited fashion is not >> appropriate", " it is common to see specifications", " whether it >> is an origin server", and "it is safer to specify behaviours" >> >> Fit better in the document than, >> >> "What's Important About HTTP", "a limited fashion isn't >> appropriate", " it’s common to see specifications", " whether it’s >> an origin server", and "it’s safer to specify behaviours". > > I'm going to leave these for the RFC Editor to decide upon. > > >> Looking forward for these HTTP Best Practices: they are much needed. > > Thanks again! > > >> >> Regards, >> Ariel >> >> [RFC8040] https://tools.ietf.org/html/rfc8040 >> >> Quoting internet-drafts@ietf.org: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Hypertext Transfer Protocol WG of >>> the IETF. >>> >>> Title : On the use of HTTP as a Substrate >>> Author : Mark Nottingham >>> Filename : draft-ietf-httpbis-bcp56bis-03.txt >>> Pages : 25 >>> Date : 2018-04-02 >>> >>> Abstract: >>> HTTP is often used as a substrate for other application protocols. >>> This document specifies best practices for these protocols' use of >>> HTTP. >>> >>> This document obsoletes RFC 3205. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-03 >>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-bcp56bis-03 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-bcp56bis-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> >> >> >> >> ------------------------------------------------------------------------------- >> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr >> > > -- > Mark Nottingham https://www.mnot.net/ > > ------------------------------------------------------------------------------- This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
Received on Monday, 9 April 2018 07:20:12 UTC