Subject: I-D Action: draft-ietf-httpbis-bcp56bis-04.txt

From: [email-masked]
Date: Wed, 11 Apr 2018 17:29:29 -0700

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/

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Sat, 14 Apr 2018 02:38:22 +0200

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".

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.

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.

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..."

10. Some Markdown remained: "also required to be _generic_", " the  
best approach is to consider the application _as_ a Web application".

Regards,
Ariel

> ftp://ftp.ietf.org/internet-drafts/

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Apr 2018 10:19:38 +1000

Thanks, Ariel.

Incorporated, with some notes below.

> On 14 Apr 2018, at 10:38 am, Ariel Otilibili Anieli <[email-masked]> wrote:
> 
> Hi Mark,
> 
> 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.

> 10. Some Markdown remained: "also required to be _generic_", " the best approach is to consider the application _as_ a Web application".
> 
> Regards,
> Ariel
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Mon, 16 Apr 2018 09:28:33 +0200

Hi Mark,

Some notes below.

Regards,
Ariel

Quoting Mark Nottingham <[email-masked]>:

>> 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".
>>
>> 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.
>
>> 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."
>>
>> 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..."
>
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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Apr 2018 10:54:10 +1000

I see - fixed in source. Thanks!

> On 16 Apr 2018, at 5:28 pm, Ariel Otilibili Anieli <[email-masked]> wrote:
> 
> Hi Mark,
> 
> Some notes below.
> 
> Regards,
> Ariel
> 
> 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:
> 
> * In case other ports are chosen (either at deployment time, or at specification), the following paragraph advises they be used so and so.
>> 
>>