Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP Urgent Data Handling
Message-ID: 
Date: 28 Sep 89 23:02:17 GMT
References: <4982@omepd.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 20

The urgent bit is sort of odd.  Your questions suggest that you want
to be able to tell exactly what data is urgent and what isn't.  That's
not really what the original intent was, I don't think.  There are no
"messages" in TCP, nor is there any intent in the spec to define where
urgent data begins, only where it ends.  Urgency is intended to
indicate a condition that takes effect immediately.  Its beginning is
not synchronized with the data stream.  Thus urgent should be set in
the next datagram to be sent, even if it is a retransmission and did
not have urgent set last time.  (This may be hard to implement of
course, and as far as I know is not.  But conceptually it would make
sense, and it would improve some aspects of telnet and rlogin
behavior.)  Furthermore, if two sections of "urgency" are adjacent,
they may look like one.  Both of the uses of urgent data that I know
-- telnet and rlogin -- are designed with these concepts in mind.
This means that the concept of "urgent message" is not well defined.
Only the concept of "last urgent byte" makes any sense, and with the
off by one fiasco, even that is ambiguous.  I would suggest that you
*not* try to "clarify" urgent, but stick with the 4.3 semantics.
Anyone who needs urgent "messages" should arrange to delimit the
messages by some sort of marker in the data.