Manuel Castelo Branco
From: [EMAIL PROTECTED]
Reply-To: [email protected]
To: [email protected]
Subject: Standards Digest, Vol 44, Issue 85
Date: Mon, 30 Jul 2007 18:46:06 -0500
>Send Standards mailing list submissions to
> [email protected]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.jabber.org/mailman/listinfo/standards
>or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
>You can reach the person managing the list at
> [EMAIL PROTECTED]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Standards digest..."
>
>
>Today's Topics:
>
> 1. Re: <[CDATA[ in XMPP (Robin Redeker)
> 2. Re: <[CDATA[ in XMPP (Micka?l R?mond)
> 3. Re: <[CDATA[ in XMPP (Micka?l R?mond)
> 4. Re: <[CDATA[ in XMPP (Micka?l R?mond)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 31 Jul 2007 01:34:39 +0200
>From: Robin Redeker <[EMAIL PROTECTED]>
>Subject: Re: [Standards] <[CDATA[ in XMPP
>To: [email protected]
>Message-ID: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset=iso-8859-1
>
>On Mon, Jul 30, 2007 at 06:16:24PM -0500, Mickael Remond wrote:
> > Hello,
> >
> > Regarding this discussion, it seems that the topic started about the use
> > of CDATA.
> > So, we are talking about way to escape characters in an XML stream. My
> > view is that all way to escape characters are good, especially when they
> > are defined in XML, cited in XMPP RFC and are simple to implement (and
> > implemented by all parsers I know).
> >
> > I have tested the use of CDATA for example with Psi, Gajim and a few other
> > clients and all of them were fine.
> > As Peter said, it should probably be allowed if not explicitely forbidden.
> >
> > My view is that it should be allowed as, as I understand it, it is just
> > one of the possible way to escape characters (and not the worst one).
>
>I've been reading the XMPP RFC with an eye on exactly CDATA, and it says
>clearly that CDATA is allowed.
>
> An XML stanza exists at the direct child level of the root <stream/>
> element and is said to be well-balanced if it matches the production
> [43] content of [XML].
>
>See in the XML spec:
>
>
> [43] content ::=
> CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*
>
>CDSect is a CDATA Section. And the RFC3920(bis) doesn't say anything
>about excluding it.
>
>
>R
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 31 Jul 2007 01:35:40 +0200
>From: Micka?l R?mond <[EMAIL PROTECTED]>
>Subject: Re: [Standards] <[CDATA[ in XMPP
>To: XMPP Extension Discussion List <[email protected]>
>Message-ID: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hello,
>
>----- Original Message -----
> > On Mon, Jul 30, 2007 at 09:58:34PM +0200, Andreas Monitzer wrote:
>
> > It's said that XMPP is just 'an application' or 'a subset' of XML.
>
>An application and a subset are different things. An application means
>that you support all the standard you rely on. A subset means you
>support
>only a part of it.
>
>
> > And
> > I heard from some people that XMPP's "XML" was even simplified to
> > allow
>
>Supporting CDATA is one of the way for efficiency as it simplify
>escaping.
>
> >> absolutely necessary (e.g. programming for a platform where no XML
> >> parser is available), since these kind of implementations are bound
> >> to contain serious issues
> >
> >> (XML is much more complicated than people think).
> >
> > I very much agree with that observation :-)
>
>So am I, but we are talking here about escaping characters. If one
>part of
>XML is simple, the CDATA section is one of them.
>
>--
>Micka?l R?mond
> http://www.process-one.net/
>
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: http://mail.jabber.org/pipermail/standards/attachments/20070731/ec22becc/attachment-0001.htm
>
>------------------------------
>
>Message: 3
>Date: Tue, 31 Jul 2007 01:36:43 +0200
>From: Micka?l R?mond <[EMAIL PROTECTED]>
>Subject: Re: [Standards] <[CDATA[ in XMPP
>To: XMPP Extension Discussion List <[email protected]>
>Message-ID: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hello,
>
>----- Original Message -----
> > Tobias S. Josefowitz wrote:
> >> On 7/31/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> >>
> >>> Similarly, a complete XMPP session (with start and end stream
> >>> tags) is
> >>> a
> >>> conforming XML document. Just because the session does not include
> >>> comments, processing instructions, DTD subsets, entity references
> >>> other
> >>> than those predefined in the XML spec, other other restricted
> >>> features
> >>> does not mean that the session is not an XML document.
> >>
> >> Unless for example starttls comes into play... exceptions everywhere.
> >> Is that the existence of a rule I am sensing here?
> >
> > How does the inclusion of STARTTLS negotiation cause the complete XML
> > stream to not be an XML document?
>
>If we go further why do server and client accept the "prologue" <?xml
>version="1.0"?>
>If we are not talking about XML (or a close relative, as it seems to
>make
>people nervous ;), it should be forbidden (yes, I am kidding :)
>
>If we go back to the heart of the discussion, what is bad about
>CDATA ? We
>are talking about characters escaping and it does not seems to be a big
>deal. It is defined in XML (and for a good reason: To simplify parsing).
>Is CDATA a controverse part of the XML Spec ? I do not think so.
>We are talking about characters escaping, and I do not see what is
>complicated in this. All the clients I have tried support CDATA, as
>there
>parser is build on a lower level XML parser.
>Yes, you can do parsing optimisation for XMPP, but I think when you say
>that you do not want to mess with tokenisation of the XML stream,
>which is
>the low level stuff you will most probably want to rely on.
>
>For those interested in gory details, why can you optimise the way you
>handle a stream with this ? Because, other means of escaping means
>replacing & with & for example. This is not a one character to one
>character mapping, so you have to do copy of your string to make a
>new one
>which is longer. With CDATA, you can in 99,999% of the time escape
>characters by concatening several strings, without any copy operation
>(your are manipulating references to your data parts, not changing the
>data).
>So my view is that to prevent this kind of optimisation in XMPP
>(which is
>why CDATA is in XML), you need to have a good reason. If it is not
>prevented it should probably be stated somewhere that it is allowed.
>
>--
>Micka?l R?mond
> http://www.process-one.net/
>
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: http://mail.jabber.org/pipermail/standards/attachments/20070731/a86cf63d/attachment-0001.htm
>
>------------------------------
>
>Message: 4
>Date: Tue, 31 Jul 2007 01:39:34 +0200
>From: Micka?l R?mond <[EMAIL PROTECTED]>
>Subject: Re: [Standards] <[CDATA[ in XMPP
>To: XMPP Extension Discussion List <[email protected]>
>Message-ID: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset="utf-8"
>
>Hello,
>
>Le 31 juil. 07 ? 01:18, Rachel Blackman a ?crit :
>
> > Not that I disagree that XMPP should be defined as a rational
> > subset of XML, rather than including the whole spec, but... this
> > seems to be needlessly splitting hairs, to me.
> >
> > Correct me if I'm wrong, but the definition of XMPP is that you /
> > restart the stream/ when you get an opening <stream> element (such
> > as after starttls or whatever). Given that the stream starts over
> > with the new <stream>, the complete XML stream is indeed still a
> > complete and valid document.
> >
> > (I assume that for the sake of sanity -- and given that at that
> > point the /entire stream/ is encrypted -- we can assume that a
> > stream would be decrypted before being validated.)
>
>I completly agree. XMPP define a logical wrapper that makes the
>manipulated XML apparently correct.
>We are on the same page, Rachel :)
>
>--
>Micka?l R?mond
> http://www.process-one.net/
>
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: http://mail.jabber.org/pipermail/standards/attachments/20070731/eb337236/attachment.htm
>
>------------------------------
>
>_______________________________________________
>Standards mailing list
>[email protected]
>http://mail.jabber.org/mailman/listinfo/standards
>
>
>End of Standards Digest, Vol 44, Issue 85
>*****************************************
Chegou o Windows Live Spaces:você divide seu blog, suas fotos, sua lista de música e agora encontra seus amigos! É só entrar no:
