|The question which started my search is that our
|requirements ask for a transparent end-to-end
|asynchronous data service. Would transporting
|a break condition be included? and transporting
|strange things like fractional data bits?

There are two types of "transparent" data links: bitwise transparent and
bytewise transparent.

A bitwise transparent link will send all changes in line-state from one end
to the other within certain delay/jitter constraints.  Most antique 300-baud
modems worked this way.  The link doesn't care what baud rate you use, but
if you go too fast timing variations will cause data errors.  A typical 300
baud modem will have no problem running at 275 baud, or 10 baud, or even up
to about 350 baud.

By contrast, a bytewise transparent link will attempt to read each byte that
comes in and then pass it on.  Unlike a bit-transparent link, where signal
timing will be derived from the original source (with some delay/jitter),
a bytewise-transparent link will regenerate the signal timing on the receive
end.

Unlike bitwise-transparent links which don't need to know anything about
data rate or data format, bytewise transparent links need to know both.
The data format of a byte-transparent link needn't necessarily be 8-N-1,
though that form is also compatible with 7-(any parity)-1 or 7-N-2.  It
must be known, however; an 8-N-1 link will fail with 7-N-1, 8-(parity)-1,
or 9-N-1 data.  Preservation and retransmission of most types of framing
errors will not generally be possible, but breaks generally can be det-
ected and preserved.  Some links, when passing through a break, will rep-
lace any break with one of fixed duration; others will measure the app-
roximate length of the break and send it through.  Whether this is nec-
essary will depend upon the application.