Да я читал и RFC1055 и RFC1144. Возможно, это действительно проблема мышления... Я никогда не относился к SLIP как к протоколу передачи "сырых", "пользовательских", "application level" данных.
Да, изначально он предназначался для передачи IP-пакетов через UART, так как UART, в отличие от ethernet-контроллера, сам никакого разделения на пакеты не делает. Вот я и относился к SLIP как к софтовой реализации того уровня, который в ethernet-контроллере сделан аппаратно :-) Причём самого нижнего, соответствующего бит-стаффингу и межпакетным флагам, "нарушающим" бит-стаффинг. Очень легко реализуемый на любой 8-битке прямо в обработчике прерываний, занимает очень мало места.
Обижаться, что SLIP не делает контрольны сумм -- всё равно, что обижаться на неделание контрольных сумм бит-стаффингом.
Итого у меня и для PC есть подпрограммы (давно пора в DLL-ку вытолкать :-), режущие по SLIP поток на пакеты (очень удобно назначить 0300 на event character). И в контроллерах -- отдельно кусочек нарезки на пакеты, отдельно - что я передаю. И что находится выше этого окда - этому коду по барабану. В этой рамке у меня бегает уже лет 6 два протокола, похожих на то, что "всемирный разум" предложил. Один попроще, с 8-битной контр. суммой, другой с crc16. И всё нормально. Найдётся другой способ резать на пакеты -- ЭТИ же пакеты можно будет гонять не через SLIP, а через тот другой способ.