[Standards-JIG] Closing idle streams

[Carlo v. Loesch]

Peter Saint-Andre typeth:
| But is idleness the only reason to close a stream without explaining why?

Some applications may want to submit a few things, than back out.
Is it so important why an application closes a link, as long as it
does so in a friendly agreeable way? The need to recycle a socket
is not a reason to consider an "error" - it's more like putting a
pen back to pick up a different one. An everyday gesture. Okay this
is stomach logic again here.. ;)

But I thought about your other idea:

| > | It seems more helpful to inform the other side why the stream is being
| > | closed by sending a stream error, rather than sending </stream:stream>
| > | and leaving the other side to wonder why the stream was closed. If that
| > | is true, then it may make sense to relax the rule in 4.7.1 by decoupling
| > | closing of the XML stream from termination of the TCP connection (i.e.,
| > | I wonder if the text really needs to say "MUST close the XML stream and
| > | SHOULD terminate the TCP connection"). Naturally we would need to think
| > | carefully about the consequences of any such change.

I took a quick glance at the list of error conditions, correct me but
aren't they all pretty fatal and the immediate termination of the
socket is a pretty valid requirement there. <connection-timeout/>
sticks a bit out, but if you change the wording to only mean real
timeout errors like many servers are already doing, then the whole
plan makes sense again.

Why does closing a stream regularely have to be considered an error?