Subject: RE: keep RST data nonstandardized for the future!

From: Bernie Volz <[email-masked]>
Date: Tue, 1 Aug 2000 18:54:06 -0400

Perhaps an FTP/SMTP/... like response format would be useful - <n> digit
code followed by a delimiter (space) followed by human readable text. That
way, TCP itself and/or application can decode the numeric code and
understand it and the application could also display the returned message
for the human to read.

It would be interesting for Apple, Sun (Solaris), and/or Mentat to perhaps
provide a list of the messages that they currently return so we get an
understanding of what the possible reasons they've captured are?

Some that I could think of are:
- No listener (for a SYN segment)
- Unknown connection
- Receiver discard connection (data received on a connection with no higher
level receiver available)
- Application abort (application requested RST on connection instead of
closing it)

- Bernie Volz

-----Original Message-----
From: Ian Heavens [mailto:[email-masked]]
Sent: Tuesday, August 01, 2000 5:55 PM
To: David L. Nicol
Cc: Ian Heavens; [email-masked]
Subject: Re: keep RST data nonstandardized for the future!

On Tue, Aug 01, 2000 at 04:08:10PM -0500, David L. Nicol wrote:
> 
> 
> That would be the doubletree in Edinburgh?

Pittsburgh:-).  I inadvertently scheduled it for 11.15 tomorrow when 
the morning IETF sessions continue to 11.30.  So 11.30 is fine to meet.

> 
> Here's my contribution to the discussion:
> 
> 
> I think that the fact that a RST can carry data is a built-in
> mechanism for extending TCP.  In my proposal for tcp connections with
> transparently migrating ends, the data portion of the RST is where I
> found to stick the additional information, since the "reserved bits"
> are apparently untouchable, although they would be good too.  (they
> are reserved for the army or something, right, in case they need to
> nationalize sprintlink all of a sudden for some reason, no?)

Excuse me for not having read your proposal - could you post a reference?
 
> 
> So I would be against declaring a STANDARD on what that data can
> be (Apple apparently includes the reset reason in ascii english) unless
> the standard still leaves some room for extension.
> 
>

I think there must be room for "Vendor Extensions", whatever standardisation
is agreed, so that your application will continue to work.  It's interesting
to see this RST data field being used in this way...

Apple, Solaris and any Mentat TCP based stack do already include the
reason for RST as an ASCII string.  This is valuable in that
interoperability
issues have been ironed out already. 

cheers

ian

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 01 Aug 2000 18:43:09 -0700

> Perhaps an FTP/SMTP/... like response format would be useful - <n>
> digit code followed by a delimiter (space) followed by human readable
> text. That way, TCP itself and/or application can decode the numeric
> code and understand it and the application could also display the
> returned message for the human to read.

I think it's pretty unlikely that applications will get the text if TCP
is burning down the connection. Another problem with reverse
standardization around data in the stream is that not everbody who does
it already will be compliant with whatever approach is finished.

Getting explicit errors out of the data stream seems like the best way
to go if there's real interest in this. Maybe a TCP option would be a
better way to handle a standardized format (as opposed to the legacy ad
hoc approach), since that would allow for explicit codes, types and
text, the latter of which could be explicitly passed to the application.
Another benefit of using an option is that it would be ignored by legacy
implementations as a matter of course.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

---

From: Ian Heavens <[email-masked]>
Date: Wed, 2 Aug 2000 16:17:12 +0100

I don't think it's so important that applications get the text
..though useful, it will involve us with socket and other API issues.
tcpdump or on the wire analysis, or syslog, is enough reason to do it.

> it already will be compliant with whatever approach is finished.

I think Mentat-derived TCP stacks are the only ones

> implementations as a matter of course.

Either approach would work (similar API issues I guess).  RST+data
has advantage that there's running code (and we know receivers can
handle it, as opposed to a new option - presumably with the RST,
so the only difference is the TCP header length and a TCP option code.
I think I may have mentioned this in the draft, (better go and read it :-).  
Oh, we'd have to apply for a TCP option whereas RFC 1122 alread pwermits
data in the TCP

ian

ian 

-- 
Ian Heavens, Spider Software Ltd., http://www.spider.com/
8 John's Place, Leith, Edinburgh EH6 7EL. 
Tel +44 131 475 7015 fax. +44 131 475 7001  [email-masked]