JSON-RPC 2.0 - Isn`t encoding specification needed?

[Denis Vlaznev]

I think it would be nice to specify UTF-8 as the only encoding to use
in JSON-RPC 2.0.
I don`t found anything about encoding in JSON-RPC 1.0 and I don`t know
how I must interpret received bytes (TCP stream connection).

[Lorenzo Pastrana]

On Tue, 2010-02-09 at 12:52 -0800, Denis Vlaznev wrote:

I think it would be nice to specify UTF-8 as the only encoding to use
in JSON-RPC 2.0.

+1

[Erik Nedwidek aka Raycaster]

 I +1 that too. An encoding attribute would be a real PITA to handle.

[Burak Yiğit KAYA]

One more +1 from here.

Burak Yiğit "BYK" Kaya - http://card.ly/BYK
GROU.PS - JavaScript Lead - http://grou.ps
aVJSlib - Lead Developer - http://code.google.com/p/av-jslib
Sent from Izmir, 35, Turkey

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

[Matt (MPCM)]

I am not sure I would give a +1 just yet, but it seems the trend if
not the rule. Is anyone using UTF-16/UTF-32 with JSON/JSON-RPC?

Here is some context from other json technologies:

"This function only works with UTF-8 encoded data."
- http://php.net/manual/en/function.json-encode.php

"The character encoding of JSON text is always Unicode. UTF-8 is the
only encoding that makes sense on the wire, but UTF-16 and UTF-32 are
also permitted."
- http://www.json.org/fatfree.html

The character encoding for JSONRequest is UTF-8.
- http://www.json.org/JSONRequest.html

"The application/json Media Type for JavaScript Object Notation
(JSON)"
- http://www.ietf.org/rfc/rfc4627.txt says
"3. Encoding

JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.

Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.

00 00 00 xx UTF-32BE
00 xx 00 xx UTF-16BE
xx 00 00 00 UTF-32LE
xx 00 xx 00 UTF-16LE
xx xx xx xx UTF-8
"

--
Matt (MPCM)

[Erik Nedwidek aka Raycaster]

Since JSON limits it to unicode, I wouldn't be opposed to it. I was concerned about having to handle the same encodings that web browsers do. As stated you can figure out from the null orders which encoding is being used so the server can figure it out without needing an encoding attribute. I would still prefer to see UTF-8 as the default and the client needs to specify otherwise. The server should reply in the same encoding or send back a UTF-8 message indicating it can't and perhaps which encodings it supports.

Makes sense?

[Robert Goldman]

On 2/10/10 Feb 10 -10:03 AM, Erik Nedwidek aka Raycaster wrote:
> Since JSON limits it to unicode, I wouldn't be opposed to it. I was
> concerned about having to handle the same encodings that web browsers
> do. As stated you can figure out from the null orders which encoding is
> being used so the server can figure it out without needing an encoding
> attribute. I would still prefer to see UTF-8 as the default and the
> client needs to specify otherwise. The server should reply in the same
> encoding or send back a UTF-8 message indicating it can't and perhaps
> which encodings it supports.
>
> Makes sense?

Yes.

Further suggestion: add some predefined encoding error class to the set
of JSON-RPC 2.0 errors and allow the server to fill in the information
about supported encodings in the error object.

Best,
r

[Lorenzo Pastrana]

IIRC Utf8 is the internal ecma encoding (spidermonkey is in native Utf8) ...
To be verified but that would be 'iso' ..

Lo.

[Rasjid Wilcox]

(Reviving an old thread - but I'm not sure it came to any resolution.)

My interpretation would be that the actual encoding used is really
part of the *transport* layer, not the json-rpc protocol layer, and so
falls out side the scope of the spec.

As long as the transport knows how to convert a given set of bytes
into valid Unicode characters, that is all the json-rpc protocol layer
requires.

Actual implementations of course require the transport to be defined,
and if we want seamless interoperability between implementations then
we need to have documents that spec out the transport layer too. As
far as I know, the only transport for which such a document exists is
HTTP (http://groups.google.com/group/json-rpc/web/json-rpc-over-http),
although it doesn't look like it has been updated to the current spec.

A similar document for json-rpc over tcp would be useful, and in my
view is the 'right' layer to specify the unicode encoding(s) to use.
I would be happy to take on writing up a draft 'json-rpc over tpc'
spec, although progress would likely be slow since my partner is due
to have a child within the next few weeks.

Cheers,

Rasjid.

[Beorn]

On May 4, 1:57 am, Rasjid Wilcox <rasj...@gmail.com> wrote:

> On 10 February 2010 06:52, Denis Vlaznev <denis.vlaz...@gmail.com> wrote:
>
> My interpretation would be that the actual encoding used is really
> part of the *transport* layer, not the json-rpc protocol layer, and so
> falls out side the scope of the spec.

Agree.

Using JSON-RPC over HTTP, the Content-Type and Content-Transfer-
Encoding should be followed by the client.
Allowing the use of other encoding if needed.

Using JSON-RPC over TCP, a standard like UTF8 is preferred.

Personally I'd really appreciate an updated "JSON-RPC over HTTP" if
You can find the time.
I really don't see the use for plain TCP.
Using HTTP, both encoding and security can be resolved.
Not to mention firewall troubles.


First post so.. My name is Björn Lundberg.
At Kabona we ONLY use JSON-RPC over HTTP.
Growing number of applications in Building Control.

Cheers
B

[Rasjid Wilcox]

On 5 May 2010 01:15, Beorn <lundb...@gmail.com> wrote:
> I really don't see the use for (json-rpc over) plain TCP.

That's funny. Since my main interest is bi-directional
implementations of json-rpc, I'm very interested in json-rpc over
plain tcp and other stream-based connections, but have a lot less
interest in json-rpc over http.

I can also see plenty of uses for json-rpc over stream-based
connections. For example:

json-rpc over stdin/stdout could be used when you have child processes
that you want to communicate with in a complex manner, without the
overhead of having to make up your own protocol. This is particularly
relevant when the parent and child processes are written in different
languages where there is no standard serialisation method common to
both languages.

json-rpc over unix sockets or windows named pipes could allow for
interprocess communication without the complexity of COM or XPCOM, and
in a relatively cross-platform way.

json-rpc over tcp can give all of the above, but of course also with
processes on different hosts. It does however come with the drawback
of requiring a known port to be listing on, or some discovery system
in place.

And all of the above can run bi-directional implementations of
json-rpc, which can allow for (for example) clean publish /
subscribe-to event methods and a clean MVC style design, across hosts,
or across languages, or both. [ Actually some of this is still
conjecture on my part, but so far seems to be working out pretty well.
]

> Not to mention firewall troubles.

I'm hoping that http://orbited.org/ will magically make that problem
largely disappear if I need it to. But currently all my use cases
are within a LAN or across a VPN that I control, so it has not been an
issue for me yet.

(Moved from the top of the original message)

> Personally I'd really appreciate an updated "JSON-RPC over HTTP" if
> You can find the time.

In case you have not guessed, not something that I'm personally likely
to take on at this point in time. You could always tidy it up
yourself and upload (as a file) your revised version for comments. If
nothing else it is likely to restart discussion. (I assume that you
have already read the comments on the page in question.)

However, if you did want to work on it yourself, you might want to
check with the list admins about the best way to go about it, since
only the list admins can actually create and edit pages. [ Evidence
suggests that Matt, Roland, Jeffrey, Kris, Lorenzo and Weston are or
have been list admins. There may be others. ]

Cheers,

Rasjid.

[Денис Влазнев]

My interpretation would be that the actual encoding used is really
part of the *transport* layer, not the json-rpc protocol layer, and so
falls out side the scope of the spec.

As long as the transport knows how to convert a given set of bytes
into valid Unicode characters, that is all the json-rpc protocol layer
requires.

Actual implementations of course require the transport to be defined,
and if we want seamless interoperability between implementations then
we need to have documents that spec out the transport layer too. As
far as I know, the only transport for which such a document exists is
HTTP (http://groups.google.com/group/json-rpc/web/json-rpc-over-http),
although it doesn't look like it has been updated to the current spec.

A similar document for json-rpc over tcp would be useful, and in my
view is the 'right' layer to specify the unicode encoding(s) to use.
I would be happy to take on writing up a draft 'json-rpc over tpc'
spec, although progress would likely be slow since my partner is due
to have a child within the next few weeks.

Agreed, this document will be very useful.

[Steve]

> > A similar document for json-rpc over tcp would be useful, and in my
> > view is the 'right' layer to specify the unicode encoding(s) to use.
> > I would be happy to take on writing up a draft 'json-rpc over tpc'
> > spec, although progress would likely be slow since my partner is due
> > to have a child within the next few weeks.
>
> Agreed, this document will be very useful.

I agree that for JSON-RPC over TCP, mandating UTF8 is a good idea.

I have a problem with JSON-RPC over TCP though. The descriptions I
have seen
simply refer to sending a JSON object.
For structured transports like HTTP, it is well known when you have
received the entire object - the header tells you the content size in
advance.

TCP is an unstructured byte stream though.
A TCP stream can arrive in variable sized chunks, not necessarily
related to the
size of the chunks the sender sent. In order to know when a complete
JSON
object has been received over the stream, either some explicit marker
must be
included in the stream, or the recipient will be obliged to re-parse
the buffer for
every byte in the stream checking to see if a complete object has
arrived yet.

I would suggest that a byte that cannot be part of a UTF8 JSON string
be sent
immediately after the JSON string, to act as an end-of-object marker.
It seems
that UTF8 encoded strings can contain any byte except 0xfe and 0xff,
so I
would suggest requiring an 0xff byte immediately after a complete JSON
string.

Such an encoding scheme would allow one TCP stream to stream multiple
JSON
objects in a full-duplex fashion, mixing procedure calls and replies
if required.

Does anyone else have thoughts on this?

[Rasjid Wilcox]

On 14 May 2010 21:16, Steve <steve....@gmail.com> wrote:
> I have a problem with JSON-RPC over TCP though. The descriptions I
> have seen simply refer to sending a JSON object.
> For structured transports like HTTP, it is well known when you have
> received the entire object - the header tells you the content size in
> advance.
>
> TCP is an unstructured byte stream though.
> A TCP stream can arrive in variable sized chunks, not necessarily
> related to the
> size of the chunks the sender sent. In order to know when a complete
> JSON
> object has been received over the stream, either some explicit marker
> must be
> included in the stream, or the recipient will be obliged to re-parse
> the buffer for
> every byte in the stream checking to see if a complete object has
> arrived yet.

Actually, it is pretty simple to 'split' a json-stream without full
parsing. See http://groups.google.com/group/json-rpc/msg/2a7c5b9d53e77b9e
for Roland's initial solution to the problem. That is the approach I
ended up adopting in my version at
http://www.openminddev.net/projects/projects/show/python-rpcbd -
although I ended up completely re-writing the splitting code to fit my
needs.

> I would suggest that a byte that cannot be part of a UTF8 JSON string
> be sent
> immediately after the JSON string, to act as an end-of-object marker.
> It seems
> that UTF8 encoded strings can contain any byte except 0xfe and 0xff,
> so I
> would suggest requiring an 0xff byte immediately after a complete JSON
> string.
>
> Such an encoding scheme would allow one TCP stream to stream multiple
> JSON
> objects in a full-duplex fashion, mixing procedure calls and replies
> if required.
>
> Does anyone else have thoughts on this?

Not so sure about the 0xff marker myself. One of my goals is to write
a bi-directional jsonrpc client in javascript using
http://orbited.org/, and sticking to plain 'strings' makes life easier
and I suspect much more efficient. My preferred alternative to the
splitting approach would be to use netstrings
(http://cr.yp.to/proto/netstrings.txt), which in addition to keeping
with the plain 'strings' also has an json-rpc implementation which
already uses it - https://launchpad.net/txjsonrpc.

In thinking about json-rpc over TPC/IP, it is worth keeping in mind
that there are at least three different modes of operation:
a) uni-directional single shot (one request per connection)
b) uni-directional pipelined (multiple requests over single
connection, requests only flow one way)
c) bi-directional pipelined (multiple requests over single connection,
requests can flow either way)

Splitting has the advantage that the 'obvious' way of writing an a)
style client (just send the request - no headers or markers, and await
for a response) still works with a c) style server. There are still
issues of course - for example, an 'a' style client needs to close the
connection once it has received a response and not wait for the server
to do it.

To get true interoperability between json-rpc over tcp clients and
server, the equivalent of smtp's 'ehlo' command or imap's 'capability'
command is needed, but figuring out the lower level stuff first is
probably a good idea.

Cheers,

Rasjid.

[Steve]

> sticking to plain 'strings' makes life easier
> and I suspect much more efficient. My preferred alternative to the
> splitting approach would be to use netstrings
> (http://cr.yp.to/proto/netstrings.txt), which in addition to keeping
> with the plain 'strings' also has an json-rpc implementation which
> already uses it - https://launchpad.net/txjsonrpc.
>

Separating the strings by inserting headers or separators is much the
same thing. It still provides a low-level structure for delimiting
payload messages. I wasn't aware of the netstrings implementation. I
wouldn't mind using netstrings headers instead of FF delimiters.

I am very much against needing to parse the entire json object to find
the end though. I don't think the parser you posted is reliable even
if you only stick to character codes below 255, and I don't think the
transport layer should have to understand the payload layers anyway.
And a single wayward "{" or similar error would pollute the rest of
the stream forever.

> In thinking about json-rpc over TPC/IP, it is worth keeping in mind
> that there are at least three different modes of operation:
> a) uni-directional single shot (one request per connection)
> b) uni-directional pipelined (multiple requests over single
> connection, requests only flow one way)
> c) bi-directional pipelined (multiple requests over single connection,
> requests can flow either way)
> Splitting has the advantage that the 'obvious' way of writing an a)
> style client (just send the request - no headers or markers, and await
> for a response) still works with a c) style server. There are still
> issues of course - for example, an 'a' style client needs to close the
> connection once it has received a response and not wait for the server
> to do it.
>
> To get true interoperability between json-rpc over tcp clients and
> server, the equivalent of smtp's 'ehlo' command or imap's 'capability'
> command is needed, but figuring out the lower level stuff first is
> probably a good idea.
>

I would be wary of adding too many options to the protocol. One of the
delights of jsonrpc is its simplicity. Given that there needs to be
some prior agreement between the devices anyway (knowing port numbers,
method names and arguments), I think adding a capability negotiation
just to decide if the connection should be client-server or
bidirectional peer-peer is over the top. I would rather keep the
protocol lightweight.

[Lorenzo Pastrana]

I would suggest that a byte that cannot be part of a UTF8 JSON string
be sent
immediately after the JSON string, to act as an end-of-object marker.
It seems
that UTF8 encoded strings can contain any byte except 0xfe and 0xff,
so I
would suggest requiring an 0xff byte immediately after a complete JSON
string.

Such an encoding scheme would allow one TCP stream to stream multiple
JSON
objects in a full-duplex fashion, mixing procedure calls and replies
if required.

Does anyone else have thoughts on this?

My main though on this is : json is ecma-script based, ecma-script is utf8 encoded globally, json-rpc is json based thus utf8 encoded globally ...

Correct me if I'm wrong (I'm a little rusty on plain tcp) but the issue here sounds to me like a transport issue ..

I'd wrap-up json-rpc utf8 encoded commands in an ultra-thin pascal-like string protocol ...

Lorenzo

[Beorn]

With the risk of being semi flamed again...

>>>
POST /cgi-bin/json.cgi HTTP/1.1
Connection: keep-alive
Content-Length: 69
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,sv;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: sessionid=1E7Mo5H1lJMPg

{"jsonrpc": "2.0", "method":"alarm.getactive", "params":[[]], "id":1}

<<<<
HTTP/1.1 200 OK
Date: Mon, 17 May 2010 09:04:17 GMT
Connection: close
Content-Length: 372
Content-type: application/json; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

{"jsonrpc": "2.0", "result": {"devid": "Dfors/Storg.94", "list":
[{"id": "ack.heatpump.rt.al","desc": "Larm, Drifttidsmätning Värmepump
ACK-VP1","timet": 1270895256000,"times": "2010-04-10
12:27:36","status": "ACK","priority": "NOT","domain":
"HEAT,VENT","url": "ack_dyn.html","note": "Test 6
89012345678901234567890;blu","action": null}]}, "error": null, "id":1}

----
Maybe an existing wheel fits?

[Rasjid Wilcox]

On 17 May 2010 22:08, Lorenzo Pastrana <past...@ultraflat.net> wrote:
> I'd wrap-up json-rpc utf8 encoded commands in an ultra-thin pascal-like
> string protocol ...

That is almost exactly what NetStrings are. The length of the
contents/data (in this case json-rpc utf8 encoded command) is passed
in plain ascii at the start of the 'packet', with a single colon
separating the 'packet' header from the actual 'packet' data, and a
comma terminates the packet.

While slightly inefficient, the use of a plain ascii representation of
the data length (in 8-bit bytes) keeps the protocol purely 'string'
based, and also avoids any endian issues.

Cheers,

Rasjid.

[Rasjid Wilcox]

On 17 May 2010 22:42, Beorn <lundb...@gmail.com> wrote:
> With the risk of being semi flamed again...

<jsonrpc over http example>

> Maybe an existing wheel fits?

Hi Beorn,

I'm sorry if you thought of my response to your earlier post as a
flame. It was not meant that way. In case there was any confusion,
the use of the word 'funny' was meant in the sense of 'that is
curious', not 'that is something to laugh at'.

Mainly I was trying to show that at least in some cases, the 'existing
wheel' you are referring to (namely json-rpc over http) does not fit.
To me one of the beautiful things about the json-rpc spec (unlike the
xlmrpc spec for example) is that is does not specify the transport. So
I'm free to use something other than (or in addition to) http. Not
because I have anything against http, just that it does not suit my
purposes in all situations.

Cheers,

Rasjid.

[Rasjid Wilcox]

On 17 May 2010 01:43, Steve <steve....@gmail.com> wrote:
> I am very much against needing to parse the entire json object to find
> the end though. I don't think the parser you posted is reliable even
> if you only stick to character codes below 255, and I don't think the
> transport layer should have to understand the payload layers anyway.
> And a  single wayward "{" or similar error would pollute the rest of
> the stream forever.

Very good point. In my original post at the time
(http://groups.google.com/group/json-rpc/msg/d35ebd5be5f04fe6) I was
leaning towards a NetString like approach, but Roland's post swayed me
towards the splitter idea. I'm now leaning back towards a NetStrings
(or similar) approach.

>> To get true interoperability between json-rpc over tcp clients and
>> server, the equivalent of smtp's 'ehlo' command or imap's 'capability'
>> command is needed, but figuring out the lower level stuff first is
>> probably a good idea.
>>
> I would be wary of adding too many options to the protocol. One of the
> delights of jsonrpc is its simplicity. Given that there needs to be
> some prior agreement between the devices anyway (knowing port numbers,
> method names and arguments), I think adding a capability negotiation
> just to decide if the connection should be client-server or
> bidirectional peer-peer is over the top. I would rather keep the
> protocol lightweight.

Fair enough. One of my thoughts here was also to distinguish between
servers that can handle multiple requests on a single connection, and
those that can't. But I've realised that the server that I was
looking at is using a small request size and a tcp-close as a proxy
for either splitting the stream or knowing the packet size ahead of
time. I think the use of a NetStrings (or similar) approach probably
makes that point moot.

So despite the fact that my current implementation uses the splitter
approach, I'm now +1 on a NetStrings or similar approach.

The other question in my mind is should we mark at the transport layer
whether a 'packet' is a request or a response? This is really only an
issue in bi-directional implementations. Mostly it is obvious from the
contents of the json received, but in the case of a parse error it
*is* an issue. A parse error on a request should receive a response
(an error message), but a parse error on a response should not
(clients don't send responses).

Example without marker:
--> 69:{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1},
<-- 41:{"jsonrpc": "2.0", "result": 19, "id": 1},

Example with marker (using C = client = request, S = Server = response):
--> 71:C:{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1},
<-- 43:S:{"jsonrpc": "2.0", "result": 19, "id": 1},

What are others thoughts on this?

Cheers,

Rasjid.

[Sean Kinsey]

Why not do the obvious and just use a line feed, 0x0A to mark the end
of each message? According to the JSON spec this should never occur in
a valid JSON message as it should be escaped into '\n'.

[Rasjid Wilcox]

On 18 May 2010 05:32, Sean Kinsey <oki...@gmail.com> wrote:
> Why not do the obvious and just use a line feed, 0x0A to mark the end
> of each message? According to the JSON spec this should never occur in
> a valid JSON message as it should be escaped into '\n'.

That would appear to be true for strings within a JSON message.

However, from the spec: "Whitespace can be inserted between any pair of tokens".

In many contexts a line feed would be counted as whitespace, and so I
would not want to assume that there are no line feeds within the JSON
message itself.

Cheers,

Rasjid.

[Sean Kinsey]

On May 19, 2:02 am, Rasjid Wilcox <rasj...@gmail.com> wrote:

> On 18 May 2010 05:32, Sean Kinsey <okin...@gmail.com> wrote:
>
> > Why not do the obvious and just use a line feed, 0x0A to mark the end
> > of each message? According to the JSON spec this should never occur in
> > a valid JSON message as it should be escaped into '\n'.
>
> That would appear to be true for strings within a JSON message.
>
> However, from the spec: "Whitespace can be inserted between any pair of tokens".
>
> In many contexts a line feed would be counted as whitespace, and so I
> would not want to assume that there are no line feeds within the JSON
> message itself.

What you say is contradictory - you choose to follow the spec on

"Whitespace can be inserted between any pair of tokens"

but you ignore that it also states 'String: Any UNICODE character
except " or \ or control character', and that it also specifies that
these has to be escaped.

Backspace is mentioned specifically (\n, 0x0A) as a control character
and so is not allowed inside valid JSON.

[Lorenzo Pastrana]

On Mon, 2010-05-17 at 12:32 -0700, Sean Kinsey wrote:

Why not do the obvious and just use a line feed, 0x0A to mark the end
of each message? According to the JSON spec this should never occur in
a valid JSON message as it should be escaped into '\n'.

For every problem there is always a solution that is simple obvious and wrong.

On Wed, 2010-05-19 at 10:02 +1000, Rasjid Wilcox wrote: 
> In many contexts a line feed would be counted as whitespace, and so I
> would not want to assume that there are no line feeds within the JSON
> message itself.

What you say is contradictory - you choose to follow the spec on
"Whitespace can be inserted between any pair of tokens"
but you ignore that it also states 'String: Any UNICODE character
except " or \ or control character', and that it also specifies that
these has to be escaped.

JSON Specs are not contradictory : the String you are talking about, witch is delimited by double quotes, is the one mentioned above in the Value part of the spec.

Outside the given string and between any tokens any of \n \r \t or space is to be considered as 'whitespace', if not you wouldn't be allowed to write valid json on multiples lines ... :/

The string mentioned about in this thread is actually a whole (valid) json rpc request and the question of it's length was asked for transport matters ...

Cheers.

[Sean Kinsey]

On May 19, 2:20 pm, Lorenzo Pastrana <pastr...@ultraflat.net> wrote:
> On Mon, 2010-05-17 at 12:32 -0700, Sean Kinsey wrote:

...

> > What you say is contradictory - you choose to follow the spec on
> > "Whitespace can be inserted between any pair of tokens"
> > but you ignore that it also states 'String: Any UNICODE character
> > except " or \ or control character', and that it also specifies that
> > these has to be escaped.
>
> JSON Specs are not contradictory : the String you are talking about,
> witch is delimited by double quotes, is the one mentioned above in the
> Value part of the spec.
>
> Outside the given string and between any tokens any of \n \r \t or space
> is to be considered as 'whitespace', if not you wouldn't be allowed to
> write valid json on multiples lines ... :/

Indeed, I 'missed' that part.

>
> The string mentioned about in this thread is actually a whole (valid)
> json rpc request and the question of it's length was asked for transport
> matters ...

Ok, so lets use some other control character, like the ETX (End Of
Text), 0x03 or EOT (End Of Transmission) 0x04.
They fit semantically..

[Lorenzo Pastrana]

Sean Kinsey wrote:
> Ok, so lets use some other control character, like the ETX (End Of
> Text), 0x03 or EOT (End Of Transmission) 0x04.
> They fit semantically..

My preference would go to EOT (End Of Transmission) 0x04, totally cute,
for a transport layer.

Lo.