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

From: Todd Hubers <[email-masked]>
Date: Mon, 12 Nov 2018 10:49:32 +1100

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 <
[email-masked]> wrote:

> Sent to Todd Hubers, [email-masked] and
> [email-masked]
> 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" <[email-masked]>
> 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
>  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>
>
>

-- 
--
Todd Hubers

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Nov 2018 09:30:44 +1100

Hi Todd,

Thanks for the feedback. I looked over it, but incorporating it would require a pretty substantial update to the document, and as you mention, we're pretty far down the path with this document.

Please do continue to participate!

Cheers,

> On 12 Nov 2018, at 10:49 am, Todd Hubers <[email-masked]> wrote:
> 
> 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 <[email-masked]> wrote:
> Sent to Todd Hubers, [email-masked] and [email-masked]
> 
> 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" <[email-masked]> 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
> 
> 	Feedback for_ Building a protocol with HTTP (revision 2018-10-26).txt
> 
> 
> 
> -- 
> --
> Todd Hubers

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

---

From: Todd Hubers <[email-masked]>
Date: Fri, 23 Nov 2018 17:22:55 +1100

Hi Mark,

Not a problem. Thanks for the encouragement.

Whether it's timing, relevance, or both; I don't mind if my ideas are
dismissed. I am still learning the process.

Thanks,

On Thu, 22 Nov 2018 at 09:31, Mark Nottingham <[email-masked]> wrote:

> Hi Todd,
>
> Thanks for the feedback. I looked over it, but incorporating it would
> require a pretty substantial update to the document, and as you mention,
> we're pretty far down the path with this document.
>
> > 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
> > 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.
> >
> >

-- 
--
Todd Hubers