Re: [tsvwg] The List (of application-layer desired features)

I understand the points you make, and am sympathetic. I feel the same way
when I see people abusing HTTP to provide async notifications, etc.
The fact is, however, if it isn't deployed, no matter how nice it would
theoretically be when it is, it isn't useful and people WILL work around
the problem.
That is true regardless of whether the problem is at the application layer
(e.g. HTTP), or at the transport layer (e.g. TCP), or elsewhere.
The primary motivation is to get things working, and making things that
lack redundancy, or are elegant comes in at a distant second.

Deployed is the most important feature, thus things which quickly move
protocols and protocol changes from theoretical to deployed are by far the
most important things.
The longer this takes, the more likely that the work-around becomes
standard practice, at which point we've all "lost" the game.
-=R


On Tue, Sep 3, 2013 at 5:00 PM, Joe Touch <touch@isi.edu> wrote:

> Hmmm.
>
>  On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com
>> <mailto:grmocg@gmail.com>> wrote:
>>
>>     For those of you who missed it, at the HTTPBis/TSVG joint session, a
>>     question about what applications want from the transport (I really
>>     want to put quotes around that) came up.
>>
>>     Here is a rendition of what was on the note that I jotted down in
>>     response to this question, and which I passed to people at the mic.
>>
>>     (Apps-folks want the following) Deployed in 1996:
>>
>
> Here's what at least one transport person wants from apps-folks:
>
> - don't reinvent the wheel (muxing exists at IP, vs. wanting to support it
> inside HTTP)
>
> - don't claim an existing protocol won't work because of your *current*
> assumptions (Berners-Lee's famous words claimed that he didn't want FTP
> because it was heavyweight for retrieving just one file, and that's what
> he'd want most of the time)
>
> - when you use an existing protocol, use it correctly (HTTP should have
> Nagle *OFF* because it's a multi-byte interactive protocol, and TCP "CLOSE"
> shouldn't be the only/preferred way to signal EOF)
>
> - if you want the benefits of a protocol extension, support its
> development (TCP-AO isn't available in host OSes yet, but I also don't see
> the web folks clamoring to implement it)
>
> Joe
>
>
>
>