The problem, as I've come to understand it (and posted about in
  comp.protocols.kerberos where that message first appeared) is that
  the concept of "urgent data pointer" is documented in the RFC's, and
  BSD corrupted that into an "out of band data" mark.  [I'd appreciate
  it if someone could disabuse me of this notion *with references to
  standards*...]

Mark,

  I can't disabuse you of your notion; you are entirely correct that
the BSD OOB mechanism is a corruption of the urgent data pointer
specified in RFC793.

>From RFC793:

  TCP also provides a means to communicate to the receiver of data that
  at some point further along in the data stream than the receiver is
  currently reading there is urgent data.  TCP does not attempt to
  define what the user specifically does upon being notified of pending
  urgent data, but the general notion is that the receiving process will
  take action to process the urgent data quickly.

Note that this does not say that the urgent data is OOB.  Just that
the data which is there is urgent and should be processed quickly.

  Urgent Pointer:  16 bits

  This field communicates the current value of the urgent pointer as a
  positive offset from the sequence number in this segment.  The
  urgent pointer points to the sequence number of the octet following
  the urgent data.  This field is only be interpreted in segments with
  the URG control bit set.


  The Communication of Urgent Information

  The objective of the TCP urgent mechanism is to allow the sending user
  to stimulate the receiving user to accept some urgent data and to
  permit the receiving TCP to indicate to the receiving user when all
  the currently known urgent data has been received by the user.

Note that this does not make it OOB either.  Just that some of the
data is urgent.

  This mechanism permits a point in the data stream to be designated as
  the end of urgent information.  Whenever this point is in advance of
  the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
  must tell the user to go into "urgent mode"; when the receive sequence
  number catches up to the urgent pointer, the TCP must tell user to go
  into "normal mode".  If the urgent pointer is updated while the user
  is in "urgent mode", the update will be invisible to the user.

Note that this specifically contradicts any notion of OOB data; it
says that two urgent pointers in successive packets will NOT both be
visible to the user.  It also states that the user is only told about
which mode.

  The method employs a urgent field which is carried in all segments
  transmitted.  The URG control flag indicates that the urgent field is
  meaningful and must be added to the segment sequence number to yield
  the urgent pointer.  The absence of this flag indicates that there is
  no urgent data outstanding.

  To send an urgent indication the user must also send at least one data
  octet.  If the sending user also indicates a push, timely delivery of
  the urgent information to the destination process is enhanced.

This is probably the root of the trouble.  This doesn't imply that
that byte or all of the bytes sent are 'OOB', but it could lead
someone to think this.

  If the URGENT flag is set, segments sent to the destination TCP
  will have the urgent pointer set.  The receiving TCP will signal
  the urgent condition to the receiving process if the urgent
  pointer indicates that data preceding the urgent pointer has not
  been consumed by the receiving process.  The purpose of urgent
  is to stimulate the receiver to process the urgent data and to
  indicate to the receiver when all the currently known urgent
  data has been received.  The number of times the sending user's
  TCP signals urgent will not necessarily be equal to the number
  of times the receiving user will be notified of the presence of
  urgent data.

This is the nail in the coffin of "OOB data", in my opinion.


  If there is urgent data the user will have been informed as soon
  as it arrived via a TCP-to-user signal.  The receiving user
  should thus be in "urgent mode".  If the URGENT flag is on,
  additional urgent data remains.  If the URGENT flag is off, this
  call to RECEIVE has returned all the urgent data, and the user
  may now leave "urgent mode".  Note that data following the
  urgent pointer (non-urgent data) cannot be delivered to the user
  in the same buffer with preceeding urgent data unless the
  boundary is clearly marked for the user.

Again, this doesn't indicate OOB, but I can see how it could cause
confusion.

It is clearly the intent of the RFC author that successive urgent
indications MAY be collapsed into a single one, and that all that is
intended is for the sender to declare "It's important to read up to
byte xyz", and the receiver to be told "The sender said it's important
to read further than you have read; read more now!".

It's quite a stretch to convert this to a notion where some of the
data has special semantics by virtue of having been marked urgent.
And, as many have pointed out, such mechanisms simply don't work
because individual urgent notifications are not carried reliably,
since the second subsumes the first according to the TCP standard.

        Greg Troxel <gdt@bbn.com>