Re: Issue 5.1) SSH End of message directive

[Phil Shafer <phil@juniper.net>]

Ted Goddard writes:
>That seems too harsh for the human-pasting-into-ssh case-- isn't it
>acceptable for both operations to fail together with one error?
>(Unfortunately, it might no longer be clear to the client which
>operation the error is associated with.)

How will the client know whether to expect one or two rpc-reply
elements?  Assumably it will expect two, thinking that it has
sent two and will hand waiting for the second one.  Or it will
expect one (having bailed early during the generation of the
first rpc and stumbled blindly into the generation of the
second one) and will be confused over getting the second one.

This ambiguity-with-the-possibility-of-a-hand is exactly
the sort of fuzziness we need to avoid in order to define
a clean, clear, usable API.

>>> 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.
>> How would it be detected in your CDATA case?
>When the <?eom?> is embedded in the CDATA section, the XML parser
>ignores it, because it's CDATA.  It's only seen as a processing
>instruction outside the CDATA section.

It can only be ignored it there's a preprocessor that's
parsing enough of the xml to see that it's inside a CDATA
section and can then ignore the <?eom?>.

Thanks,
 Phil

--
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/>