[jdev] xml processing question

Scott Cotton wsc at mindowl.com
Mon Aug 14 19:24:32 CDT 2006


That's good to hear.

Is this error consistent with the rfc3920 sec 11.1 requirement that
an xmpp implementation ignore restricted xml?


On 8/14/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
>
> 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 <hildjj at gmail.com> 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
> >>>
> >>>
> >>>
> >
>
>
>


-- 
scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20060814/21b5c3f5/attachment-0002.htm>


More information about the JDev mailing list