diff --git a/xep-0198.xml b/xep-0198.xml
index 72a6cbb4..acbcd32b 100644
--- a/xep-0198.xml
+++ b/xep-0198.xml
@@ -30,8 +30,8 @@
&dcridland;
&mwild;
Simplification based on implementation experience: removed acking per number of stanzas exchanged because either entity can request an ack at any time; moved throttling feature to a separate specification; removed 'stanzas' attribute from <enable/> element; added 'location' attribute to <enabled/> element; clarified several implementation issues in the text; fixed several examples; versioned the XML namespace from urn:xmpp:sm:2 to urn:xmpp:sm:3.
The <enabled/> element MAY include a 'max' attribute to specify the receiving entity's preferred maximum resumption time.
-The <enabled/> element MAY include a 'location' attribute to specify the receiving entity's preferred IP address or hostname (optionally with a port) for reconnection; if reconnection to that location fails, the standard XMPP connection algorithm specified in &xmppcore; applies.
+The <enabled/> element MAY include a 'location' attribute to specify the receiving entity's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of &rfc3920bis; (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in &xmppcore; applies.
The initiating entity MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an <enable/> element until after authentication (such as SASL, &xep0078; or &xep0220;) has been completed successfully.
For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding unless it is resuming a previous session (see Resumption).
The server SHALL enforce this order and return a <failed/> element in response if the order is violated (see Error Handling).
@@ -248,14 +248,15 @@ C:Definition: The 'id' attribute defines a unique identifier for purposes of stream management (an "SM-ID"). The SM-ID MUST be generated by the receiving entity (server). The initiating entity MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The receiving entity MAY encode any information it deems useful into the SM-ID, such as the full JID &LOCALFULL; of a connected client (e.g., the full JID plus a nonce value). Any characters allowed in an XML attribute are allowed. The SM-ID MUST NOT be reused for simultaneous or subsequent sessions (but the server need not ensure that SM-IDs are unique for all time, only for as long as the server is continuously running). The SM-ID SHOULD NOT be longer than 4000 bytes.
+As noted, the <enabled/> element MAY include a 'location' attribute that specifies the server's preferred location for reconnecting (e.g., a particular connection manager that hold session state for the connected client).
+If the stream is terminated unexpectedly, the initiating entity would then open a TCP connection to the receiving entity. The order of events is as follows: