Re: Issue 5.1) SSH End of message directive

[Rob Enns <rpe@juniper.net>]

Phil's posted a couple of messages on this thread already about
our experience with the single document model. The well-formedness
issue is not the only issue (it's not even the worst one).

I don't see the single document session being easier to implement (why
do you say that?). It's harder to implement with the common SAX
and DOM based XML parsers. Maybe there's a new batch of jabber
aware parsers around the corner, but I'd wager that code base
will be jabber-specific, and not generally applicable to other 
XML parsing needs. I think our goal should be to make things easier
for off the shelf general XML parsers.

Concur that putting all namespaces at the top is a win. I don't
think it outweighs the pain of pulling out protocol messages
while parsing the document, however.

thanks,
 Rob

On Tue, Dec 16, 2003 at 03:46:49PM -0700, Ted Goddard wrote:
> 
> However, if the connection is closed in such failure cases, it makes
> putting each operation in its own XML document less compelling.
> 
> The single-document-session form is easier to implement, and would
> allow NETCONF implementations to borrow "streaming" XML parsing code
> from existing Jabber projects.  The one restriction would be you
> can't use a DOM parser to implement NETCONF/SSH.
> 
> One substantial benefit to the single document form is that a group
> of namespaces could be declared for all operations in the session.
> 
> Ted.
> 
> On Dec 16, 2003, at 3:26 PM, Rob Enns wrote:
> 
> >On Tue, Dec 16, 2003 at 04:38:52PM -0500, Phil Shafer wrote:
> >>Ted Goddard writes:
> >>>Should the connection be closed upon any XML well-formedness errors?
> >>
> >>Yes, since with out a framing protocol, there is no way to reliably
> >>recover the connection.  The two peers cannot agree on what the
> >>state of the connection is, which means that one side could hang
> >>waiting on the other side to send data that will never come.  The
> >>possibility of hanging and the probability of dropping data go
> >>strongly against the sort of exactness one wants in an API.
> >
> >... and I don't think this is too severe for cut'n'paste users,
> >because folks to cut'n'paste to see how the protocol works, and
> >to debug script problems. People that want a forgiving environment
> >for other reasons will use the CLI.
> >
> >thanks,
> > Rob

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