While waiting for it to appear on srfi.schemers.org, you can get the
latest version at http://synthcode.com/scheme/srfi-56.tar.bz2.

I'll go into more detail about the rationale here.

The only significant change is the addition of the binary/character
port distinction.  There are several reasons why a Scheme may wish to
make this distinction:

  1) Java and other non-systems languages may have limited support for
     intermixing binary and character operations on the same port.

  2) Windows distinguishes between text and binary mode, and though
     this is easy to workaround by always using binary ports, some
     Schemes may wish to preserve the distinction.

  3) Schemes may wish to disallow using binary operations on
     string-ports for simplicity and performance reasons.

In the interest of greater portability, we first acknowledge that
there may be a distinction, and provide the binary-port? and
character-port? predicates, which are not necessarily mutually
exclusive (they may both be tautologies).

Testing alone does not help portability, other than to possibly
display more informative error messages:

  (call-with-input-file my-database
    (lambda (p)
      (if (binary-port? p)
        (load-database p)
        (error "shucks, files aren't opened in binary mode by default"))))

Indeed, providing this distinction without specifying how to open
files in binary mode would hurt portability more than help, as people
would simply use the native Scheme's method for opening binary files,
and not bother to test the results of these predicates since they know
how they opened the file anyway.

So we provide a means of ensuring files are opened in binary (but not
necessarily character) mode with six new procedures:

    * OPEN-BINARY-INPUT-FILE path
    * OPEN-BINARY-OUTPUT-FILE path
    * CALL-WITH-BINARY-INPUT-FILE path proc
    * CALL-WITH-BINARY-OUTPUT-FILE path proc
    * WITH-INPUT-FROM-BINARY-FILE path thunk
    * WITH-OUTPUT-TO-BINARY-FILE path thunk

All of these return #t for BINARY-PORT?  The corresponding R5RS
procedures are guaranteed to return #t for CHARACTER-PORT?

The reason for using new procedures instead of extending the existing
procedures with optional arguments is to avoid clashing with already
existing extensions to those procedures.  In particular, a common
extension is to make the port encoding an optional argument.  In the
Java model, which tries to limit mixing of binary and character I/O,
"binary" itself is considered an encoding, but in the more general
case the ability to perform binary I/O is orthogonal to the port's
character encoding.

Existing R5RS (character) I/O procedures are then defined to all be
guaranteed when CHARACTER-PORT? returns #t, and the binary procedures
defined in the rest of SRFI-56 are guaranteed when BINARY-PORT?
returns #t.  It is an error to use a character/binary operation on a
port for which the corresponding predicate returns #f.

--
Alex