From 6a40cbbcbcd7e75a9a6ff3a8464c93eae7fdb107 Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre <stpeter@jabber.org>
Date: Mon, 22 Feb 2010 05:01:51 +0000
Subject: [PATCH] corrected examples

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3981 4b5297f7-1745-476d-ba37-a9c6900126ab
---
 xep-0077.xml | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/xep-0077.xml b/xep-0077.xml
index e2b7886a..c0f2fdbe 100644
--- a/xep-0077.xml
+++ b/xep-0077.xml
@@ -595,15 +595,8 @@
 <section1 topic='Stream Feature' anchor='streamfeature'>
   <p><cite>RFC 3920</cite> defines methods for advertising feature support during stream negotiation. For the sake of efficiency, it may be desirable for a server to advertise support for in-band registration as a stream feature. The namespace for reporting support within &lt;stream:features/&gt; is "http://jabber.org/features/iq-register". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server returns a stream header to the client and MAY announce support for in-band registration by including the relevant stream feature:</p>
   <example caption='Advertising registration 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>
-    ...
     <register xmlns='http://jabber.org/features/iq-register'/>
-    ...
   </stream:features>
   ]]></example>
   <p>A server SHOULD NOT advertise in-band registration to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p>