[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 5.1) SSH End of message directive
The need to handle error cases well is certainly more persuasive
than optimizing the protocol for current Java APIs. Aborting
the connection due to malformed XML seems inappropriate due
to the fact that a very important purpose of the SSH binding
is for learning NETCONF through experimentation; so, I think
that leads us back to having each operation as a standalone
The following malformed session raises the importance of the
<!-- missing rpc tag will corrupt the next operation -->
However, there is a pathological edge case that a simple pre-parser
would not detect; perhaps the CDATA below is used to insert text into a
NETCONF help facility:
Note, however, that this argues against the use of a simple
not against the use of <?eom?>. <?eom?> could still be correctly
an XML parser.
On Dec 11, 2003, at 12:16 PM, David T. Perkins wrote:
In protocol design, it can be difficult to figure out where
to draw the line in reporting problems in the messages. In
general, you need to make sure that reporting doesn't create
a cascading situation, but you also want to provide enough
information to determine the situation. The most important
is to return information that a user can determine that
the two ends are misconfigured, but you don't want to
return information that is only useful for the protocol
coders. For "bugs" in coding, this needs to be noted
in instrumentation for the protocol that can be retrieved
locally and by a management protocol, but not reported
if this will lead to a cascade of reports.
So, I agree with that approach that Phil recommends below.
On Thu, 11 Dec 2003, Phil Shafer wrote:
Mark Stahl writes:
If the whole session is one document, a syntax error in one message
require abandoning the session to reset the parser.
How does the NetConf spec address syntax errors in the message
An error in the content should cause an error message to be generated.
The client and server should be able to recover. An error in the
protocol or the framing should cause the connection to be dropped,
since you can't guarantee recovery.
/david t. perkins
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.