[jdev] xml processing question
stpeter at jabber.org
Thu Aug 10 11:15:31 CDT 2006
Scott Cotton wrote:
> On 8/9/06, *Michal vorner Vaner* <michal.vaner at kdemail.net
> <mailto: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.
In RFC 3920, ignore means "treat it as if it did not exist". Probably we
can make this clearer in rfc3921bis -- i.e., what this means both for
XML routers (servers) and for the stanza recipient.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev