[standards-jig] No Subject....
mikelin at MIT.EDU
Tue Feb 5 17:06:45 UTC 2002
On Mon, 2002-02-04 at 19:37, Dave Smith wrote:
> On Mon, Feb 04, 2002 at 04:49:03PM -0500, Mike Lin wrote:
> > > Yes. Hence, I have moved the discussion of JNG to another thread. With
> > > regard to JEP 0017, I think our original discussion still stands: there are
> > > difficult problems here and it may just not be worth addressing without a
> > > willingness to consider alternatives to Jabber's "pure XML" approach...
> > > Will a stopgap XML framing effort pay off and be adopted?
> > There are real benefits to new implementations (such as Jabber.NET and
> > Jabber for embedded devices) from having JEP-0017-style framing
> > information available, since it makes XML Stream interpretation much
> > easier.
> I concur that there could be speed benefits, but (as Dave Waite has
> noted), there are significant issues with malformed XML compromising the
> system at a level other than jpoll/c2s component. In other words, by
> doing this framing you provide the ability for malformed XML to make it
> farther into the routing system and could cause jabberd to drop a
> connection to components (due to the bad XML), as opposed to having the
> c2s/jpoll drop the client connection. This would be very bad, and IMHO,
> sufficient reason to not pursue this further -- unless you want to also
> address the component protocol to deal with malformed XML on trusted
> connections in such a way that those trusted connections don't have to
> reset on every bad packet.
As we discussed in detail already, all nodes are still required to
verify well-formedness of XML payloads before retransmitting them. We
have already discussed performance implications and the remaining
benefits that still make backwards-compatible framing desirable.
More information about the Standards