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

Hi Patrick,

Thanks for your consideration of my opinions and ideas. I waited until
after the forum in Bangkok to reply. I completely understand if this is too
late. There might be something important which justifies a modification;
I'm happy to simply be heard and to continue learning the standardisation
process.

Regards,

Todd

On Sat, 27 Oct 2018 at 06:00, Patrick McManus <
notifications@transloadit-633fe7ed7a24.intercom-mail.com> wrote:

> Sent to Todd Hubers, draft-ietf-httpbis-bcp56bis.authors@ietf.org and
> ietf-http-wg@w3.org
> Patrick McManus was added to the conversation by Patrick McManus
>
> 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 03:43 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
> [image: Attachments icon] Feedback for_ Building a protocol with HTTP
> (revision 2018-10-26).txt
> <https://transloadit-633fe7ed7a24.intercom-mail.com/i/o/82739127/3edd0f9299a02e169adf5289/Feedback+for_+Building+a+protocol+with+HTTP+%28revision+2018-10-26%29.txt>
>
> [image: intercom]
>


-- 
--
Todd Hubers