[comp.protocols.tcp-ip] TCP Urgent Pointer *Standard*

Ed Sale (02/12/91)

After reading the sections of the TCP and Host Requirements RFC's (included
below), it is still unclear to me how a standard TCP should set the
Urgent Pointer field of the TCP header in segments with the URG control
bit set.  My problems with the descriptions in the RFC's are:

	What does "positive offset" mean, precisely?
	What does "points to" mean, precisely?

My question boils down to this:

	If a TCP segment is carrying just one byte of data, and that
	one byte is urgent data, what value should the TCP header's
	Urgent Pointer field contain, 0 or 1? (In a *STANDARD* TCP.)

Also, in my experience with many TCP implementations, there is
apparently confusion about the value that the Urgent Pointer should
have, as they do not appear to all be setting this field the same way.
I guess even if I choose to implement *STANDARD* Urgent Pointer
processing I'm still not going to be able to converse effectively
with every TCP implementation out there :-(.

Thanks in advance for any insight you may provide into this problem.
My apologies if this question has been asked and answered here previously.
Please reply to me by mail, and I will post a summary of the responses I
get.

rfc793 (TCP), page 17,  lines 1204-10

"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 (sic) interpreted in segments
 with the URG control bit set."


rfc793 (TCP), page 56,  lines 3523-4

"If the urgent flag is set, then SND.UP <- SND.NXT - 1 and set the
 urgent pointer in the outgoing segments"


rfc1122 (Host Requirements), page 84, lines 4917-22

"4.2.2.4  Urgent Pointer: RFC-793 Section 3.1

 The second sentence is in error: the urgent pointer points
 to the sequence number of the LAST octet (not LAST+1) in a
 sequence of urgent data.  The description on page 56 (last
 sentence) is correct."

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     Ed Sale  Intergraph Corp.  Huntsville, AL 35894-0001  (205)730-2000
			     b11!ed!sale@ingr.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

tasman@CS.WISC.EDU (02/13/91)

Ed Sale writes:

> My question boils down to this:
>
>	If a TCP segment is carrying just one byte of data, and that
>	one byte is urgent data, what value should the TCP header's
>	Urgent Pointer field contain, 0 or 1? (In a *STANDARD* TCP.)
> 
> Also, in my experience with many TCP implementations, there is
> apparently confusion about the value that the Urgent Pointer should
> have, as they do not appear to all be setting this field the same way.
> I guess even if I choose to implement *STANDARD* Urgent Pointer
> processing I'm still not going to be able to converse effectively
> with every TCP implementation out there :-(.


     A brief answer to Ed's question is that the Urgent Pointer field should
contain 0.

     For a more detailed treatment of the philosophy and implementation of TCP
Urgent, you may wish to read an article that I wrote last summer:

	Tasman, M., "Telnet Output Discard Processing,"
	ConneXions: The Interoperability Report, Volume 4, No. 6, June 1990.

     A footnote to the article addresses the compatibility issue.  Due to
the specification confusion concerning TCP Urgent, some early implementations
contained an "off by one" calculation error.  Rather than alter the behavior
of their TCP implementation, at least one supplier chose instead to compensate
in the application programs.  The preceding will make more sense if you
read the article.

					Mitchell Tasman
					UW-Madison Computer Sciences Dept.