Remote protocol and 7-bit links

Remote protocol and 7-bit links

[Daniel Jacobowitz]

Now that we've shaken the branches a little and found that there are at
least a couple users of the remote protocol on this list...

Are any of you using links to targets which are not 8-bit clean?  The remote
protocol, as currently defined, is strictly 7-bit with the exception of the
optional 'X' packet.  I have two projects which I'll be submitting in the
near future which involve transmission of large amounts of data:

1.  Self-describing targets return hefty XML blobs.

2.  Remote file upload/download transfer, well, files.

And I don't really want to hex encode all of this stuff if I don't have to.
A lot of remote protocol users use TCP or UDP, which obviously can handle
8-bit data.  Many also use serial devices; all the ones I've used (over the
last ~ six years) have been eight bit clean, even when terminal servers were
involved.

If this is going to be a problem, I could implement binary and non-binary
variants, or use some other mechanism to switch between.  But I think that
eight bits per byte and a clean link layer which won't get too upset by
NULs are reasonable things to assume in the 21st century.  And even in the
previous decade; any terminal server that can't handle eight bits can't
handle PPP...

I'm not suggesting to change the format of any existing packet, and the new
packets I'll be adding are optional.  So this wouldn't impact simplistic
stubs that don't need the new functionality (and even most descriptions for
the self-describing targets won't have 8-bit data in them).  But 8-bit
support would be necessary if you wanted to support the new features.

Any opinions, or counterexamples?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Remote protocol and 7-bit links

[Steven Johnson]

As a remote protocol user I say:

Bring on 8 bit only.  I haven't seen or used a UART that cant be set
into 8 bits per byte since I started using them (late 80's).  Its 2006,
cant we deprecate the requirement for everything to be 7 bit clean, and
just assume 8 bits is the way?  Architectures get obsoleted faster than
the requirement for everything to be 7 bit clean.  Hex encoding stuff
just adds work and makes life harder for the stub.

As a minimum, I would say these new features be 8 bit only, and then 7
bit hobbled targets (if any actually exist) cant use them.

Steven J


Daniel Jacobowitz wrote:

>Now that we've shaken the branches a little and found that there are at
>least a couple users of the remote protocol on this list...
>
>Are any of you using links to targets which are not 8-bit clean?  The remote
>protocol, as currently defined, is strictly 7-bit with the exception of the
>optional 'X' packet.  I have two projects which I'll be submitting in the
>near future which involve transmission of large amounts of data:
>
>1.  Self-describing targets return hefty XML blobs.
>
>2.  Remote file upload/download transfer, well, files.
>
>And I don't really want to hex encode all of this stuff if I don't have to.
>A lot of remote protocol users use TCP or UDP, which obviously can handle
>8-bit data.  Many also use serial devices; all the ones I've used (over the
>last ~ six years) have been eight bit clean, even when terminal servers were
>involved.
>
>If this is going to be a problem, I could implement binary and non-binary
>variants, or use some other mechanism to switch between.  But I think that
>eight bits per byte and a clean link layer which won't get too upset by
>NULs are reasonable things to assume in the 21st century.  And even in the
>previous decade; any terminal server that can't handle eight bits can't
>handle PPP...
>
>I'm not suggesting to change the format of any existing packet, and the new
>packets I'll be adding are optional.  So this wouldn't impact simplistic
>stubs that don't need the new functionality (and even most descriptions for
>the self-describing targets won't have 8-bit data in them).  But 8-bit
>support would be necessary if you wanted to support the new features.
>
>Any opinions, or counterexamples?
>
>  
>

Re: Remote protocol and 7-bit links

[Daniel Jacobowitz]

On Sat, May 27, 2006 at 11:02:18AM +1100, Steven Johnson wrote:
> As a minimum, I would say these new features be 8 bit only, and then 7
> bit hobbled targets (if any actually exist) cant use them.

Yes, that's my plan.  The only possible lossage would be targets which
fraudulently set the high bit on 7-bit data; I have to disable the
stripping of that byte in order to pass binary data through.  But I
really don't expect anything to break.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Remote protocol and 7-bit links

[Steven Johnson]

Daniel Jacobowitz wrote:

>On Sat, May 27, 2006 at 11:02:18AM +1100, Steven Johnson wrote:
>  
>
>>As a minimum, I would say these new features be 8 bit only, and then 7
>>bit hobbled targets (if any actually exist) cant use them.
>>    
>>
>
>Yes, that's my plan.  The only possible lossage would be targets which
>fraudulently set the high bit on 7-bit data; I have to disable the
>stripping of that byte in order to pass binary data through.  But I
>really don't expect anything to break.
>  
>
Surely that would only be the debug host doing that?  That would be a
faulty host in my books.

Re: Remote protocol and 7-bit links

[Mark Kettenis]

> Date: Fri, 26 May 2006 18:10:03 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Now that we've shaken the branches a little and found that there are at
> least a couple users of the remote protocol on this list...
> 
> Are any of you using links to targets which are not 8-bit clean?  The remote
> protocol, as currently defined, is strictly 7-bit with the exception of the
> optional 'X' packet.  I have two projects which I'll be submitting in the
> near future which involve transmission of large amounts of data:
> 
> 1.  Self-describing targets return hefty XML blobs.

Isn't XML supposed to be 7-bit clean?

Mark

Re: Remote protocol and 7-bit links

[Aaron S. Kurland]

On Sat, 2006-06-17 at 23:15 +0200, Mark Kettenis wrote:
> Isn't XML supposed to be 7-bit clean?

Nope.
http://www.w3.org/TR/REC-xml/#charsets

--
Aaron S. Kurland
Founder and CTO, Boston Circuits, Inc.
http://www.bostoncircuits.com/