That's good to hear.  Is this error consistent with the rfc3920 sec 11.1 requirement that an xmpp implementation ignore restricted xml? <div>On 8/14/06, Peter Saint-Andre <<a href="mailto:stpeter@jabber.org">stpeter@jabber.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Yes, returning that error seems preferable to ignoring the invalid XML. Joe Hildebrand wrote: > Sorry, I should have looked that up, and included it in my response.  We > have a well-defined error for that: > > <stream:error> >   <invalid-xml xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> >   <text xmlns='urn:ietf:params:xml:ns:xmpp-streams' xml:lang='en-us'> >      DTDs are not supported on this stream. >   </text> > </stream:error> > > or some such.  See RFC 3920, section 4.7.3. > > On Aug 13, 2006, at 2:11 PM, Scott Cotton wrote: > >> On 8/13/06, Joe Hildebrand < <a href="mailto:hildjj@gmail.com">hildjj@gmail.com</a>> wrote: >>> >>> >>> On Aug 11, 2006, at 7:24 PM, Scott Cotton wrote: >>> > I'm still unclear on what "treat as if does not exist" means. >>> > First and foremost, I don't know whether ignoring is >>> > passing through untouched  and uninterpreted or >>> > removing it. >>> >>> Another option, which resolves this ambiguity is to say that the >>> receiving entity MUST disconnect from the sending entity, the same as >>> if non-well-formed XML had been sent. >> >> >> >> I like this option, so long as the receiving entity also sends a >> descriptive >> error >> message to the sending entity. >> --scott >> >> PS I am developing an xml parser in java which works on byte buffers >> instead >> of streams, but uses the java 1.6 / java EE  javax.xml.stream XMLEvent >> interface so that it can more easily interoperate with other xml tools. >> This >> makes it easier to work with non-blocking io for a server, but also >> unfortunately seemed >> to require a dedicated xml parser.  Minimizing the required work for that >> parser >> is what originally triggered the question, but I'm more concerned about >> being >> very clear with respect to what  happens to message  content. >> >> -- >>> Joe Hildebrand >>> >>> >>> > </blockquote> </div> -- scott