Thanks for the long-awaited srfi!

I think the author's intention is to describe minimum basic
interface for the portability, instead of covering every possible
features.  So it's better to be emphasized that to what extent
the behavior is 'common', e.g.

- For optional arguments, what's the default behavior when omitted?
  This must be a bit complicated in this ipv4/ipv6 mixed world.
  (e.g. how can I write a portable server that accepts both v4 and
  v6 connections?  Some OS allows that I can wait for both on a single
  socket, while others I need to open one socket for each.
  I don't think we need to stick to one behavior in srfi-level,
  but it will help to write portable code if possible variations
  are explained.)

- What will happen when connection attempt fails, or cannot bind
  socket?
  I assume most implementations raises an error, but then, it's better
  to be said so.
  Whether the type of condition should be specified or not is an
  open question.  If the author's intention is to encode the common
  state of the current implementations, maybe we don't need to say
  the condition type, but again, it'll be helpful to describe what
  kind of conditions is used in existing implementations.

- About call-with-socket: What will happen on socket when PROC returns?
  What will happen on it when PROC does not return?
  (I can guess, but it's better to be explicit).

- About socket-recv: I assume it returns zero-length bytevector when
  the peer shuts down the connection.  It might also be helpful for
  users to say so.