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

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

This is deep into implementation details.  In the yuma code, the process listening for input uses the eom marker to decide what to give to xmlTextReader.  Do not assume the ssh code understands XML.

AFAIK, there is no way to put chars in the XML stream for framing, so there is no point in changing 4742.

Andy

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

Phil Shafer writes:
> Any chance we can address the framing issue?  It would be nice to
> have something real, workable, and robust here.

Isn't framing fundamentally supported by matching XML tags?  ]]>]]> is only there to support recovery, it's not intended to support framing - right?   

4742 says the ]]>]]> is to only to allow "resynchronization of the NETCONF exchange in the event of an XML syntax or parsing error."  My reading of that is that the parsing error has to happen first, then the agent resynchronizes on the next ]]>]]>.  While the parsing error may be caused due to an unexpected ]]>]]>, that seems like a very special case.  

Given this shift in emphasis, I'm comfortable in closing the session if and only if the parsing error is due to an unexpected ]]>]]>.

This text should go into 4742bis, not 4741bis

Thanks,
Kent

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Wed, 18 Aug 2010 13:11:46 -0400

>no point in changing 4742.

The transport encoding can insert whatever is needed.  For example, I
could define a framing protocol that inserts "#Frame-length" messages
into the text, and "#End-of-frame" at the end of a message.  There
would be no confusion about when a message ends and no overlap between
content and framing.

#Frame-length: 1024
... 1024 bytes of content
#Frame-length: 1024
... 1024 bytes of content
#Frame-length: 56
... 56 bytes of content
#End-of-frame

The "write" code is simple:

    fprintf(fp, "#Frame-length: %u\n%s", strlen(msg), msg);

and the reading code is similarly simple.  End-of-frame detection
is simple and robust.

If I want to manually construct data, I can calculate the length and add the
it statically to the top of my file, and if I want to cut-n-parse, I can
make a perl function to do this framing for me.

Yeah, I know; none of this is news and I've begged for this before,
but somehow I just couldn't stop myself.

Thanks,
 Phil