Hi, Toerless,
The TAPSters are scurrying madly in preparation for the TAPS BOF on
Monday, and I'm expecting them to review all IETF WG Review comments
made up to that point (keeping in mind that the date on the request for
comments is 7-31, to allow more people to provide input), but I should
reply to this part of your review comments.
On 07/18/2014 01:44 PM, Toerless Eckert wrote:
Let me comment in this email on the paragraph about BCP 56, i think
it is wrong and inflammatory.
You could be right :p
Most of the TAPS charter that's up for review now was pretty carefully
written and discussed on the TAPS mailing list, but the BCP 56 reference
was not. I wrote it.
When the paragraph then says ... it is assuming "...." ..., it is putting
words into the BCPs mouth that are not in evidence in that BCP. Then that
assumption is singling out one aspect of the BCP, that firewalls/proxies are
likely to pass HTTP/port 80 when other traffic is blocked, and make it
sound as if that is then the reason, why there are "many issues with this
strategy".
In fact, that aspect is just half a page in the BCP, and not even
a particularily good half page because it is not speaking out positively
about the accused in the face issues where really the network path is
at fault. Ultimately, 90% of that BCP are about other problems than the
network path.
I scribbled something quickly in response to internal review comments
about the previous version of the charter focusing on IETF transport
protocols.
What I intended to say was that while the IESG didn't come out with a
ringing endorsement of HTTP as a transport substrate when they produced
BCP56, the working group charter being approved in 2014 should allow the
working group to think about HTTP, in addition to the usual TCP, UDP, etc.
If that's not what people read, that's my fault.
And then this TAPS paragraph claims that the IESG has expressed
the paragraphs view (blaming programmers, making BCP 56 primarily about FW
bypass, etc..), and has called out the negatives of BCP 56 against
WebSockets. I do not know what the IESG has really said (the paragraph
provides no reference), but BCP 56 predates WebSockets by many years
AFAIK, and 90% of that BCP are not applicable to WebSockets.
I can not believe that WebSockets is seen as a bad but unavoidable
protocol approach. I rather think a lot of APP area folks in the IETF
would state exactly the opposite: It is a pretty good coalescion of
higher layer needed functionality (during conn setup), fits snugly into
the web centric app layer framework (browsers, http), and manages to minimize
messy network layer midpoint problems (eg: flow state problems in midpoints).
And WebSocket effectively is also meant to kill a lot of the protocols
that where really badly built on top of HTTP, aka: it solves a lot more
BCP 56 problems than that negatives of BCP 56 apply to it.
It was not my intention to say anything about WebSockets, and if I
managed to accomplish that without trying, that's my fault.
It's also worth mentioning that I'm hoping to have one co-chair with
significant APP or RAI background, if I can identify the right person,
so the perspective you shared in your final paragraph should not fall on
deaf ears.
And thank you for providing WG Review comments.
Spencer