Subject: Re: [Netconf] how to handle XML parse errors

From: "Andy Bierman" <[email-masked]>
Date: Wed, 18 Aug 2010 12:23:18 -0700

I don't think this major change to the ssh transport is worth the effort.
I don't think it is a good idea to start a session using the old framing,
then switch to new framing if both peers agree to use base:1.1.

Starting over with a new port number is not an option for 4741bis.

Andy

----- Reply message -----
From: "Phil Shafer" <[email-masked]>
Date: Wed, Aug 18, 2010 11:17
Subject: [Netconf] how to handle XML parse errors
To: "Andy Bierman" <[email-masked]>
Cc: "Kent Watsen" <[email-masked]>, "Juergen Schoenwaelder" <[email-masked]>, "[email-masked]" <[email-masked]>

"=?utf-8?B?QW5keSBCaWVybWFu?=" writes:
>I disagree.  This is valid XML content, so the server cannot ignore the XML and
>just look for some string.  This could be leaf content instead of the frame
>start msg.

I think you've missed my content completely.  Most likely a
framing error.  ;^)

In my code, when I go to write data to an ssh connection, I can
easily find the length of the data and prepend that data with
"#Frame-length: ", the number of bytes of data, and a newline.  When
I'm at the end of the data, I can easily send the string "#End-of-frame"
and a newline.

When I'm ready to read data, I can read a line of inline, inspect
that line and see if it begins with "#Frame-length: ".  If it does,
then I can learn the number of bytes that follow, and then proceed
to read that number of bytes.  This data can then be passed to an
upper layer as XML data (without the "#Frame.*" line). If the line
is "#End-of-frame", then I can tell the upper layer and I've seen
the end of the frame, which will translate into something similar
to EOF.

There's no escaping of data, no relying on the data to provide
the framing, and no interaction between the framing and the
content.

Thanks,
 Phil