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

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

For servers that stream the replies instead of buffering, knowing the reply length at the start of the message is not possible.

Andy

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

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

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Aug 2010 11:24:00 -0400

"=?utf-8?B?QW5keSBCaWVybWFu?=" writes:
>For servers that stream the replies instead of buffering, knowing the reply
>length at the start of the message is not possible.

If you could reread my proposal, you'll notice that one can use
multiple "Frame-length" headers in a single message, allowing what
HTTP affectionately calls "chunking".  The server reads a chunk,
writes that chunk, and repeats until it's ready to send the
"#End-of-frame" message.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Aug 2010 09:18:09 -0700

> writes that chunk, and repeats until it's ready to send the

I don't think is worth changing.
This is a major non-backward compatible change.
NETCONF 1.1 is a minor bugfix, something you remind us of quite often.

Making a major change like this because in theory there could be
lots of buggy manager applications blindly injecting XML into NETCONF messages
is not very compelling to me.  I don't believe there are any such NETCONF manager
applications out there to worry about.

The issue we are resolving is whether the server should follow
specific error handling procedures in base:1.1, because in base:1.0 they
are unspecified and left to the server implementor to decide.

IMO, we do not have any consensus to make a change
so we should leave 4741bis unspecified (up to the server).

Andy