Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

FWIW, I agree with David's position here, and appreciate his raising the
distinction between implementation and specification.

Whether the app or the OS decides to terminate via the existing TCP API
ABORT call, that's an implementation issue.

I'd have opinions as to which is more correctly *implemented*, but
that's an implementation issue, not a protocol issue.

When resources are starved, I think good implementations inform the app
and let the app decide what to do. I don't think they have the OS run
down things it *thinks* aren't useful and free them. Again, however,
that's an implementation issue. I'll argue it, but it's not relevant to
the key question of whether we need a new protocol mechanism.

One final point:

David Borman wrote:
> 
> On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote:
...
>> A protocol is a contract between the sender and receiver here, and the
>> contract defines the wire
>> behaviour.
> 
> The TCP protocol is what is defined in RFC 793/1122, and any other RFCs
> that are applicable.  It is more than just the wire behavior.

This is as I have stated on multiple lists.

If there is a strong need for an RFC to explain concepts that are
ambiguous, this is MUCH more important than any other raised in this
entire thread.

Joe

Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

Attachment: signature.asc