On Jan 29, 2013, at 2:02 PM, Johnny Billquist wrote: ... Protocol wise, you could (I guess) just decide to append a CR+LF to each record sent, and then strip those off at the receiving side before processing the data. But that is a protocol change, as these would need to be explicitly added and removed inside the packets sent in DECnet. Also, I guess each packet would be a full line, although doing data merging of packets on the receiving side to get lines could also be done. Well, actually, http already specifies the CF+LF on each record. The issue is the implicit extra information received by doing packets instead of a stream, but you could just ignore the record metadata, and look at it as a stream of bytes. It does, however, still force you to define that this is how http should be done on top of DECnet, which today is not "defined". I think you're making this more complicated than it needs to be. DECnet has SDU (message) boundaries, TCP does not. So TCP based protocols do not use message boundaries, they are byte streams. If you want to carry a TCP-origin protocol over DECnet, put the stream into DECnet messages without any regard to message boundaries (other than any size limits). For received messages, ignore the message boundaries. I think that's basically what a stream mode DECnet socket on Ultrix is defined to do. So I'm basically saying that the mapping of http onto DECnet is "use stream mode, object number 80" -- that's basically the whole description. paul