[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: multiple xml documents on an input stream



Title: RE: multiple xml documents on an input stream

Hello,

There is another aspect here that should be taken into consideration when looking at SSH and SSL. Both SSH and SSL have built-in security which is likely to be needed in some customer deployments. However we will see customers not necessarily needing secure communication to devices in other deployments where both the devices and the application are on a trusted network. Hence, SSH or SSL transport would consume resources both from the device side and the application side when not really necessary for the purpose of security. In cases where an application needs to communicate with a number of devices concurrently (say for the purpose of mass deployment of configuration), we may encounter exhaustion of resources and/or significant performance hit on the application side.

Thoughts?

- Shmulik...



-----Original Message-----
From: Rob Enns [mailto:rpe@juniper.net]
Sent: Friday, July 25, 2003 2:30 PM
To: jtsillas
Cc: netconf@ops.ietf.org
Subject: Re: multiple xml documents on an input stream


Good question.

While I really like the (relative) ease of deployment of SSH (or SSL), dealing with the lack of a framing protocol is a pain, as is hooking

the stream up to a std parser. I find myself repeatedly coming down
in favor of BEEP, because inventing yet another framing protocol on top of SSH or SSL would be kind of silly.

I'm interested to hear what others think about this issue.

thanks,
 Rob

On Fri, Jul 25, 2003 at 04:00:41PM -0400, jtsillas wrote:
> The old draft specified using BEEP as the session protocol which has a
> handy feature of delivering delimited objects so that each XML
> document can be handled independently. Without this feature commonly
> available parsers (like SAX) don't work (see this discussion on the
> xerces-j-user mailing list:
> http://marc.theaimsgroup.com/?l=xerces-j-user&m=102405097214693&w=2 )
> If the standard does go with SSL, are we planning on adopting some
> kind of delimiting scheme? Trying to recover the end of the document
> by hunting for angle brackets seems risky (especially with the rpc
> format specified is "text").
>
> Any thoughts?
>
> --
> jtsillas@appledor.net
>
> JWebMail WebMail/Java v0.7.10, built with JDK 1.4.1 WWW to Mail
> Gateway

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