Not a problem. Thanks for the encouragement.
dismissed. I am still learning the process.
Post by Patrick McManusHi 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,
Post by Todd HubersHi 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.
Post by Todd HubersRegards,
Todd
On Sat, 27 Oct 2018 at 06:00, Patrick McManus <
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.
Post by Todd HubersIt 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.
Post by Todd Hubers-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
Post by Todd HubersHi 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.
Post by Todd HubersI 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.
Post by Todd HubersI hope you find this to be useful and constructive.. It's great that you
have taken the time to create this Internet Draft..
Post by Todd HubersThanks,
--
--
Todd Hubers
Feedback for_ Building a protocol with HTTP (revision
2018-10-26).txt
--
Mark Nottingham https://www.mnot.net/