Merge pull request #57 from Flowdalic/xep174

Add '<?xml ...>' to XEP-0174 examples

xep-0174.xml

@@ -197,6 +197,7 @@ ver=QgayPKawpkPSDYmwT/WM94uAlu0=
     <p>Other people at the hotspot can also advertise similar DNS records for use on the local link. Essentially, the mDNS daemons running on all of the machines at the hotspot collectively manage the ".local." domain, which has meaning only at the hotspot (not across the broader Internet). Queries and responses for services on the local link occur via multicast DNS over UDP port 5353 instead of via normal DNS unicast over UDP port 53. When a new machine joins the local link, it can send out queries for any number of service types, to which the other machines will reply. For the purpose of serverless messaging we are interested only in the "presence" service, but many other services could exist on the local link (see <link url='http://www.dns-sd.org/'>dns-sd.org</link> for a complete list).</p>
     <p>Now let us imagine that a fine young gentleman named Romeo joins the hotspot and that his chat client (actually his mDNS daemon) sends out multicast DNS queries for services of type "presence". To do this, his client essentially reverses the order of DNS record publication (explained above) by asking for pointers to presence services (i.e., PTR records that match "_presence._tcp.local."), querying each service for its service instance and port (i.e., SRV record), mapping each service instance to an IP address (i.e., A record), and finding out additional information about the entity using the service (i.e., TXT record parameters). <note>As explained in the DNS-SD specification, these queries might all be returned in the same answer.</note> As a result, Romeo's client will discover any number of local presence services, among them a service named "juliet@pronto" (with some intriguing TXT record parameters) at IP address 10.2.1.187 and port 5562. Being a romantic fellow, he then initiates a chat with you by opening an XML stream to the advertised IP address and port.</p>
     <code><![CDATA[
+<?xml version='1.0'?>
 <stream:stream 
         xmlns='jabber:client' 
         xmlns:stream='http://etherx.jabber.org/streams'
@@ -206,6 +207,7 @@ ver=QgayPKawpkPSDYmwT/WM94uAlu0=
     ]]></code>
     <p>Your client then responds with a response stream header.</p>
     <code><![CDATA[
+<?xml version='1.0'?>
 <stream:stream 
         xmlns='jabber:client' 
         xmlns:stream='http://etherx.jabber.org/streams'
@@ -362,7 +364,8 @@ juliet@pronto._presence._tcp.local. IN TXT
   <p>In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from <cite>RFC 6120</cite>.</p>
   <p>First, the initiator opens a TCP connection at the IP address and port discovered via the DNS lookup for an entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:</p>
   <example caption="Initiator Opens a Stream"><![CDATA[
-I: <stream:stream 
+I: <?xml version='1.0'?>
+   <stream:stream 
            xmlns='jabber:client' 
            xmlns:stream='http://etherx.jabber.org/streams'
            from='romeo@forza'
@@ -372,7 +375,8 @@ I: <stream:stream
   <p>Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in <cite>RFC 6120</cite>, then it SHOULD include the version='1.0' flag as shown in the previous example.</p>
   <p>The recipient then responds with a stream header as well:</p>
   <example caption="Recipient Sends Stream Header Response"><![CDATA[
-R: <stream:stream 
+R: <?xml version='1.0'?>
+   <stream:stream 
            xmlns='jabber:client' 
            xmlns:stream='http://etherx.jabber.org/streams'
            from='juliet@pronto'
@@ -426,7 +430,8 @@ I: </stream:stream>
   <p>As with Entity Capabilities over native XMPP networks, a client might not know the &xep0030; features associated with the 'ver' value advertised by another entity. However, in the case of serverless messaging there is no way for the client to discover the entity's supported features without initiating an XML stream to that entity and then sending a Service Discovery information ("disco#info") request over the negotiated stream.</p>
   <p>Unfortunately, full stream negotiation (including TLS and SASL if appropriate) can require a large number of packets. Therefore, as an optimization, it is RECOMMENDED for the receiving entity in a serverless XML stream negotiation to include its disco#info data (including node) as a stream feature, as shown in the following examples.</p>
   <example caption="Initiator Opens a Stream"><![CDATA[
-I: <stream:stream 
+I: <?xml version='1.0'?>
+   <stream:stream 
            xmlns='jabber:client' 
            xmlns:stream='http://etherx.jabber.org/streams'
            from='romeo@forza'
@@ -434,7 +439,8 @@ I: <stream:stream
            version='1.0'>
   ]]></example>
   <example caption="Recipient Sends Stream Header Response"><![CDATA[
-R: <stream:stream 
+R: <?xml version='1.0'?>
+   <stream:stream 
            xmlns='jabber:client' 
            xmlns:stream='http://etherx.jabber.org/streams'
            from='juliet@pronto'