Scott Cotton wrote: > > > On 8/9/06, *Michal vorner Vaner* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
