[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
document.

The following malformed session raises the importance of the
end-of-message marker:

    <rpc>
      <set-config/>
    <!-- missing rpc tag will corrupt the next operation -->
    <rpc>
      <validate/>
    </rpc>

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:

<![CDATA[
    <rpc>
      <set-config/>
   </rpc>
<?eom?>
   <rpc>
      <validate/>
    </rpc>
<?eom?>
]]>

Note, however, that this argues against the use of a simple pre-processor,
not against the use of <?eom?>. <?eom?> could still be correctly detected by
an XML parser.

Ted.

On Dec 11, 2003, at 12:16 PM, David T. Perkins wrote:

HI,

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 would
require abandoning the session to reset the parser.

Yup.

How does the NetConf spec address syntax errors in the message stream? 

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.

Thanks,
 Phil


Regards,
/david t. perkins



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>