- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 17 Apr 2018 10:54:10 +1000
- To: Ariel Otilibili Anieli <otilibil@eurecom.fr>
- Cc: ietf-http-wg@w3.org
I see - fixed in source. Thanks! > On 16 Apr 2018, at 5:28 pm, Ariel Otilibili Anieli <otilibil@eurecom.fr> wrote: > > Hi Mark, > > Some notes below. > > Regards, > Ariel > > Quoting Mark Nottingham <mnot@mnot.net>: > >> Thanks, Ariel. >> >> Incorporated, with some notes below. >> >>> On 14 Apr 2018, at 10:38 am, Ariel Otilibili Anieli <otilibil@eurecom.fr> wrote: >>> >>> Hi Mark, >>> >>> Here is my review of this draft: >>> >>> 1. "HTTP-based APIs defined by standards need to more carefully..." runs more smoothly than "standards-defined HTTP-based APIs need to more carefully consider...". >>> >>> 2. "At the same time, the IETF has a tradition of protocol reuse..." We could remove the contextual part "At the same time". >>> >>> 3. "These have more freedom to modify protocol operations" instead of "These have more freedom to modify protocol operation". >>> >>> 4. "or stacking the application upon HTTP, instead of using it" captures better the writer's mind than "or making the application be based upon HTTP, instead of using it". >> >> "Based upon HTTP" is a phrase that's introduced in the referenced section; changing it removes the meaning. >> >> >>> 5. The document needs no more to warrant that "Applications using HTTP MAY specify a minimum version to be supported (HTTP/1.1 is suggested)": few lines above, it already >>> said: "When specifying the use of HTTP, an application SHOULD use [RFC7230] as the primary reference". And [RFC7230] does refer to HTTP/1.1. >> >> Created https://github.com/httpwg/http-extensions/issues/587 >> >> >>> 6. "Because URLs occur in and are generated in HTTP artefacts commonly, often without human intervention..." I did not get what you have meant here. >> >> See revision. >> >> >>> 7. "Applications that use HTTP can use the well-known ports...or they can be deployed upon others." stresses better the work of IANA than "Applications that use HTTP can use the applicable default port...or they can be deployed upon other ports." >>> >>> 8. The sentence "This decision can be made at deployment time, or might be encouraged by the application’s specification (e.g., by registering a port for that application)." should be in the same paragraph than "In either case, non-default ports..." >>> >>> 9. Moreover, "The usage of unknown ports can be made at deployment time..." instead of "This decision can be made at deployment time..." and "In either case, unknown ports will need to be reflected..." instead of "In either case, non-default ports will need to be reflected..." speak the same voice than Point 8. >>> >>> 9. Idem "Using an unknown port has privacy implications..." for "Using a port other than the default has privacy implications..." >> >> I don't think that these changes are improvements. > Points 7, 8, & 9 do not improve on the content of text, indeed: they add nothing new. But, I think they separate the concerns of this part: > > * Ports 80 and 443 are default ports, because they are well-known > * In case other ports are chosen (either at deployment time, or at specification), the following paragraph advises they be used so and so. >> >> >>> 10. Some Markdown remained: "also required to be _generic_", " the best approach is to consider the application _as_ a Web application". >>> >>> Regards, >>> Ariel >>> >>> 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-04.txt >>>> Pages : 27 >>>> Date : 2018-04-11 >>>> >>>> Abstract: >>>> HTTP is often used as a substrate for other application protocols >>>> (a.k.a. HTTP-based APIs). 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-04 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-bcp56bis-04 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-bcp56bis-04 >>>> >>>> >>>> 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 > -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 17 April 2018 00:54:43 UTC