Not yet. We would change 11.1 in rfc3920bis. Peter
Scott Cotton wrote: > > 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* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 > >>> > >>> > >>> > >
smime.p7s
Description: S/MIME Cryptographic Signature
