diff --git a/xep-0078.xml b/xep-0078.xml
index 199b3b28..e58e3915 100644
--- a/xep-0078.xml
+++ b/xep-0078.xml
@@ -181,17 +181,6 @@
 <section1 topic='Use Cases' anchor='usecases'>
   <section2 topic='User Authenticates with Server' anchor='usecases-auth'>
     <p>In order to determine which fields are required for authentication with a server, a client SHOULD first send an IQ get to the server. A client SHOULD NOT attempt to guess at the required fields, since the nature of the required data is subject to service provisioning.</p>
-    <example caption='Client Opens Stream to Server'><![CDATA[
-<stream:stream to='shakespeare.lit'
-               xmlns='jabber:client'
-               xmlns:stream='http://etherx.jabber.org/streams'>
-    ]]></example>
-    <example caption='Server Opens Streams to Client'><![CDATA[
-<stream:stream from='shakespeare.lit'
-               xmlns='jabber:client'
-               xmlns:stream='http://etherx.jabber.org/streams'
-               id='3EE948B0'>
-    ]]></example>
     <example caption='Client Requests Authentication Fields from Server'><![CDATA[
 <iq type='get' to='shakespeare.lit' id='auth1'>
   <query xmlns='jabber:iq:auth'/>
@@ -275,19 +264,12 @@
 <section1 topic='Stream Feature' anchor='streamfeature'>
   <p><cite>RFC 3920</cite> defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within &lt;stream:features/&gt; is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).</p>
   <example caption='Advertising non-SASL authentication as a stream feature'><![CDATA[
-<?xml version='1.0' encoding='utf-8'?>
-<stream:stream xmlns:stream='http://etherx.jabber.org/streams/'
-    xmlns='jabber:client'
-    from='somedomain'
-    version='1.0'>
   <stream:features>
-    ...
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>PLAIN</mechanism>
     </mechanisms>
     <auth xmlns='http://jabber.org/features/iq-auth'/>
-    ...
   </stream:features>
   ]]></example>
   <p>A server SHOULD NOT advertise non-SASL authentication to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p>