Re: [EME] Re: transport recovery at the APP layer ?

[Joe Touch <[e-mail]>]

Mark Baker wrote:
> On 11/17/06, Joe Touch <[e-mail]> wrote:
>> > While it's certainly true that applications are free to attribute
>> > application layer semantics to transport layer signals (e.g. HTTP
>> > 1.0), it is not the case that all applications do so (e.g. HTTP 1.1).
>>
>> If you're referring to persistent connections, that predated 1.1 as an
>> add-on to 1.0 (though not in the base 1.0).
> 
> I was referring to how HTTP 1.0 responses were framed, specifically
> the last sentence of this paragraph from sec 7.2.2 of RFC 1945;
> 
>   When an Entity-Body is included with a message, the length of that
>   body may be determined in one of two ways. If a Content-Length header
>   field is present, its value in bytes represents the length of the
>   Entity-Body. Otherwise, the body length is determined by the closing
>   of the connection by the server.
> 
> ... which is a layering problem that HTTP 1.1 fixed by mandating
> persistent connections.

See RFC2616, sec 8.1.1:

 HTTP implementations SHOULD implement persistent connections.

When they don't, the old semantics persist.

>> HTTP isn't the only application around, as you note. Unless this RG is
>> focused on HTTP interactions with middleboxes, it needs to consider the
>> impact on all applications.
> 
> I'm glad to hear you say that, because IMO, doing so requires keeping
> our layers layered and not assuming application semantics to TCP
> signals.

Doing that means keeping TCP semantics, which means that a FIN/ACK means
what a FIN/ACK means - that the -endpoint- got the data, not that a
middlebox somewhere else did.

Joe

_______________________________________________
EME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/eme