Re: RFC1122 urgent data conformance question

[Bob Braden <[e-mail]>]

Kurt,

I am cc'ing this to the still-extant mailing list of the WG that
created RFC-1122.  I will give my opinion; others may differ.
> 
> 
> Bob,
> 
> In RFC1122 section 4.2.2.4 page 84, it states that "A TCP MUST inform the
> application layer asynchronously whenever it receives an Urgent pointer and 
> there was .....".
> 
> Given: An implementation where an application has one activity/process to 
> handle all input for all connections to the application and one or more 
> activities/processes for output for all connections. All input for all 
> connections for the application are queued to the same queue by TCP. Also, the
> input activity is always sitting on a blocked read when it is not processing an
> input. The host is a multiprocessor machine so that the various activities are
> running in parallel.
> 
> Question: If the TCP receives an urgent input and queues the urgent input with
> an indication that it is urgent on the application's input queue, does this, in
> your opinion, conform to the above excerpt from RFC1122?
> 

In my opinion, no.  The Urgent interface to the application layer is
intended to solve the problem of the application NOT reading its input,
eg because it is looping or otherwise mis-behaving.  Urgent is intended
to activate an asynchronous thread (in practice, in the Telnet under-
belly of the application layer) to unstick things.

From your description of the host operating system environment, I gather
that this is not a general-purpose host, which is the intended domain of
RFC-1122.  There was a subsequent effort to write another version of
Host Requirements for categories of special-purpose hosts (in particular
terminal servers), but this effort did not work out.  So you may be left
with the necessity of selectively ignoring areas of RFC-1122 that are
not relevant.  (But what happens if the application DOES go into a
loop and stop reading its input?)

> Since, as I understand it, you are on the IETF, I thought that you would be a
> good person to send this question to.  If not, or if I should also send it to
> someone else, please let me know.
> 
> Thanks in advance
> 
> Kurt Matthys
> Unisys Corp
> [e-mail]
>  
> 

Hope this helps,

Bob Braden
{A card-carrying member of the IETF, among other things}