[jdev] xml processing question

Scott Cotton wsc at mindowl.com
Wed Aug 9 14:28:03 CDT 2006

On 8/9/06, Michal vorner Vaner <michal.vaner at kdemail.net> wrote:
> On Wed, Aug 09, 2006 at 08:34:28PM +0200, Scott  Cotton wrote:
> >    Hi all,
> >
> >    I've come across something which seem like a possible issue w.r.t.
> xml
> >    processing
> >    for xmpp implementations.
> >
> >    The first is that rfc1390, sec 11.1 (restrictions on xml) states that
> >
> >    1) With regard to XML generation, an XMPP implementation MUST NOT
> inject
> >    into an XML stream any of the following
> >    [ dtds and stuff]
> >
> >    2) With regard to XML processing, if an XMPP implementation receives
> such
> >    restricted XML data, it MUST ignore the data
> >
> >    My question is what happens when a server receives xml with craziness
> like
> >    embedded dtds but, having
> >    ignored such restricted data, it decides it must pass the message on
> to
> >    another server.  How can a server fullfill both
> >    1 and 2 above?  What is generally done in these cases?
> >
> I understand it this way:
> the resending of message consists of reading it and then sending it.
> While reading it, I meet the dtd, but I ignore it, like it was not
> there. I do not even read it. Therefore, as I ignored it, I will not
> send it, as it was not there.

I wouldn't equate removing text with ignoring it, but this is certainly
sensible for embedded
dtds.  Removing all such restricted content might lead to confusion, if say
a message contains non-default entity references which are standard in in
some common format like xhtml.  These may even be crucial to the
communication (like dollar sign vs. euro) Should those be silently removed
too?  If it were up to me,  I'd either  pass it all through, reject
it all, or return a warning to the initiator to all restricted content.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20060809/038dbf20/attachment-0002.htm>

More information about the JDev mailing list