• Channel encryption via TLS during stream negotiation

  • client-to-server
  • server-to-server
  • TLS negotiation first (before SASL)
  • minimum is TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • certificate may be presented containing auth credentials

• Authenticiation via SASL

  • client-to-server
  • server-to-server
  • minimum is DIGEST-MD5

• Clarified Unicode usage and character encodings.

• New stringprep profiles (nodeprep and resourceprep) as separate I-Ds.

• Optional 'xml:lang' attribute on child elements that may contain natural-language CDATA:

  • message: body and subject
  • presence: status
  • multiple instances of each if distinct 'xml:lang'

• New extensible protocol supersedes CDATA error messages

• Syntax:

  <stream:error class='error-class'>
    <stream-condition 
        xmlns='urn:ietf:rfc:xmppcore-rfc-number:streams'>
      <descriptive-element-name/>
    </stream-condition>
  </stream:error>
      

• Error classes: address, format, redirect, server

• New extensible protocol supersedes HTTP-style error codes

• Syntax:

  <stanza-name to='sender' type='error'>
    [include sender XML here]
    <error class='error-class'>
      <stanza-condition 
          xmlns='urn:ietf:rfc:xmppcore-rfc-number:stanzas'>
        <descriptive-element-name/>
      </stanza-condition>
    </error>
  </stanza-name>
      

• Error classes: access, address, app, format, recipient, server

• Negotiation of xml:lang?

• SASL mechanism for dialback?

• Other?

• Specified roster / subscription interaction (lots of details, refer to I-D)

• Updated error handling to track XMPP Core

• Modified pricacy list protocol to address RFC2779 requirements regarding communications blocking...

<iq>
  <query xmlns='jabber:iq:privacy'>
    <list name='foo'>
      <item
          type='[jid|group|subscription]'
          value='bar'
          action='[accept|deny]'
          order='nonNegativeInteger'>
        <stanza-type/>
      </item>
    </list>
  </query>
</iq>

Valid <stanza-type/>'s:

• message
• presence-in
• presence-out
• iq

• Clarification being sought regarding several RFC2779 requirements

  • 5.1.3 -- unauthenticated subscriptions
  • 5.1.4 -- verifying accurate receipt by subscriber

• Other?

END