Re: Feedback for draft-ietf-httpbis-bcp56bis-07

Hi Todd, thanks for the input to the bcp56bis draft. Its getting pretty
mature and I appreciate getting a new review.

It is a long review, so I'm going to inline below the bcp56 feedback from
your attachment. That will make it easier for the WG members and the
authors to reply, if they choose, to particular points - it will also make
it easier for the chairs to judge consensus on various parts of the
document.

-Patrick, as co-chair


Todd Hubers Wrote:

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



On Fri, Oct 26, 2018 at 1:27 PM Todd Hubers <todd.hubers@gmail.com> wrote:

> Hi Mark and Team,
>
> I believe this is very important work that you and your team are doing. I
> asked within the DoH and JMAP groups whether a document like this existed,
> and I was directed to you. I currently believe that another broader
> document about leveraging "Web" standards will also be useful, but I would
> like to get involved somehow with this work to learn how to work the IETF
> way.
>
> I think the best way for me to start is to try and make my own
> recommendations for this Internet Draft that you might include. Please see
> attached.
>
>
> I hope you find this to be useful and constructive.. It's great that you
> have taken the time to create this Internet Draft..
>
>
> Thanks,
>
> --
> --
> Todd Hubers
>