[Standards] <[CDATA[ in XMPP

Mickaël Rémond mickael.remond at process-one.net
Tue Jul 31 10:47:40 UTC 2007


Hello,

Le 30 juil. 07 à 21:35, Peter Saint-Andre a écrit :

> Sergei Golovan wrote:
>> Hi!
>>
>> Today I've found some interesting commits in ejabberd SVN. It became
>> using <[CDATA[ in XML output generation.
>>
>> Is this acceptable according to RFC or no? I can't find any reference
>> in RFC-3920 except the phrase that character data containing any
>> predefined entity must be escaped.
>
> RFC 3920 does not forbid CDATA sections. Neither does rfc3920bis. I
> don't know whether that's good or bad. Probably it's not especially  
> good...

What about RFC3923 ?
RFC3923 is "End-to-End Signing and Object Encryption for the  
Extensible Messaging and Presence Protocol (XMPP)".
Reading this document carefully, I think CDATA must have at least  
been implicitely part of XMPP:

 From section 3.1 of RFC3923:
    In order to sign and/or encrypt a message, a sending agent MUST use
    the following procedure:
      [snip]
        3. Provide the resulting signed and/or encrypted object  
within an
        XML CDATA section (see Section 2.7 of [XML]) contained in an
        <e2e/> child of a <message/> stanza, where the <e2e/> element is
        qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as
        specified more fully in Section 9 below.

In example 3:
     Example 3: Sender generates XMPP message stanza:

    |   <message to='romeo at example.net/orchard' type='chat'>
    |     <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
    |   <![CDATA[
    |   Content-Type: multipart/signed; boundary=next;
    |                 micalg=sha1;
    |                 protocol=application/pkcs7-signature

It seems to me that it implies and requires CDATA to be part of XMPP.

You can check by yourself:
http://www.xmpp.org/rfcs/rfc3923.html

-- 
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/eba77a39/attachment.html>


More information about the Standards mailing list