ietf-http-wg@w3.org
https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/?include_text=1 
draft-ietf-httpbis-bcp56bis.authors@ietf.org
Todd Hubers
2018-10-26


So here are some of my opinions:


1. A broader "Web" scope document similar to this one will be useful. 


I believe this because: 


i) It will help to constrain this document to strictly HTTP standards attributes; 
ii) It will allow the beginning of brainstorming of attributes beyond HTTP as they become apparent during the work on this document; 
iii) HTTP appears to be a core of such a "Web" scope, but there are satellite aspects already in mind { JSON, RESTful, HTTPS/TLS }. 


This “HTTP” scoped document could be referenced by an overall "Web" scoped document, or this work may become part of that broader “Web” scoped document. Given the size of the work for just HTML, it probably justifies a dedicated document, while the remaining aspects could be documented directly in a "Web" scoped document.


2. It is useful to be as exhaustive as possible in lists, such as "reasons" and other “functionality”. 


I believe this because: 


i) It helps the reader identify suitability;
 ii) It works towards completeness; 
iii) Completeness is desirable in one place - this is a single document to capture such information, rather than repeating such analysis and information multiple times in different forms in other standards as a sub-chapter. 


Over time, I would encourage additional content to be added for completeness.


3. Here is a list of edits to the list in section 1 - Introduction.


a) Moving the list of reasons to its own section, or more than one new sections as needed. I think an introduction is better served by seeking higher-level clustering of "reasons", which have their respective specific exhaustive lists to be completed over time.


b) The introduction opening mentions "HTTP-based APIs", this could benefit from some current notable examples. Those examples would add evidence for that statement, and they would also help focus the development of fewer high-level reasons. (Further iterations on the exhaustive “reasons” list will also help, when you stand back and consider the common threads)


There should also be notable examples that were not based on HTTP for advisable reasons.


c) Some notable examples based on HTTP could be: DoH, JMAP, Google Drive API (a proprietary example). 


d) It might be useful to classify these examples { AdHoc solutions, Service Access by paying customers, Longterm standards for public services, maybe more }, but this doesn't appear to offer much value at this point in time.


e) I also believe that the "reasons" section should actually be two lists of reasons "why" and "why not" adjacent to each other, in the same area. This adds more value to the document toward decision making for the reader. In fact, starting with reasons "why not" are probably the least obvious, and therefore the most valuable. Also, the "why not" section tends to yield higher-level context reasons, while "why" tends to yield lower-level reasons. see [3] and [4]


f) I believe the paragraphs following the current “reasons” list that begins with “These protocols are often ad hoc”
can be converted into a reasons items. See [4] below.


g) I believe the two paragraphs starting “However, when such an application has multiple“ in the introduction are quite vague to me. I would benefit from a clearer approach to communicating the point - perhaps some specifics. Otherwise, it might not be the right place to expound the idea, but only to reference it later in the document.


h) I believe the design decisions section could be introduced referencing a comprehensive list of prompts offered for designers in a dedicated section. A list that invites future contributors to expand. This is instead of hosting a smaller list in the Introduction.


3) Reasons why not - an initial list: 


Note this is not an exhaustive list, but is intended to be with continuous improvement over time.


a) Non-web connected device such as a "thing" - that doesn't have a HTTP stack, nor the processing and battery power to support a full HTTP stack - such a device might be connected by bluetooth. 


b) Real-time media - where the underlying connection-oriented TCP protocol isn't compatible, requiring retransmissions and a user-experience that cannot be adequately controlled.


c) Network Latency sensitivity - The larger payloads of HTTP typically extend beyond a single packet/frame and lead to 


d) It's not request/response - not all protocols are request/response in pattern. Although HTTP 2.0 caters for more scenarios, it isn't as prevalent as older HTTP versions, particularly on older hardware/software.


e) Message integrity - HTTP is a transport, so any TLS extensions for certification, encryption, and digital signature; or integrity of information in TCP/IP are transient and lost. Other standards such as SOAP might be necessary because such features can be self-contained in a single message and may be stored for future auditing.


4) Reasons why - 


A lot of these reasons crossover, and are interrelated


a) Features like HTTP are needed in a short amount of time. (Scenario reason)


b) Popularity - HTTP is very popular, and self-perpetuating. 


c) Current Capability - The list of features/capabilities of HTTP are extensive. see (Features) list below.


d) Maturity - Sustained popularity over a long time has led to very mature software implementations of HTTP.


e) Documentation - Being a function of popularity, it's easy to find documentation of standards, implementations, and pitfalls to avoid.


f) Support - Being a function of popularity


g) Future Capability - people continue to contribute new ideas and features/capabilities to HTTP which may or may not automatically flow on to dependent protocols. see (Features) list below, some being known and new, but still maturing.


h) Large Workforce - Due to popularity, many are exposed to at least the use of HTTP, but practically all of the technical workforce is also well versed in at least the basics of HTTP.


i) Minimal dependencies to install


5) The Rich functionality section 3.3 tends to use HTTP specific terms. I believe more general functional names can be used to start each point, with corresponding features within HTTP. Also, the list can generally be expanded:


a) Message Framing with Request/Response groups, and multi-part data sections
b) Meta Fields - Headers
c) Server Redirection - Temporary or Permanent with HTTP Response Codes
d) Success or Error indication - HTTP Response Codes
e) Port Sharing - with varyation of Host and relative URLs
f) Load Balancing - with the correct software
g) Certification and Encryption - of server, via tight TLS integration (this is Web not HTTP)
h) Authentication - of Clients with ...
i) Authorisation - through use of a rich space of URLs, but typically with Application-level mechanisms
j) Short and Long lived Connections - Request Response, Multiplexing, WebSockets
k) Static and Dynamic Resources
j) Content negotiation for length, format, compression, language, and other features
k) Response Caching, Proximity Caching, Content Expiry
l) Traffic Monitoring
m) Content regulation