--- a/Symbian3/SDK/Source/GUID-EDC16636-B24E-598B-9084-EAE782A4A213.dita	Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-EDC16636-B24E-598B-9084-EAE782A4A213.dita	Fri Jun 11 12:39:03 2010 +0100
@@ -1,76 +1,76 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License 
-"Eclipse Public License v1.0" which accompanies this distribution, 
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
-    Nokia Corporation - initial contribution.
-Contributors: 
--->
-<!DOCTYPE concept
-  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-EDC16636-B24E-598B-9084-EAE782A4A213" xml:lang="en"><title>What
-is Bearer Mobility</title><shortdesc>This topic describes the concept of <i>Bearer Mobility</i> in the
-Communications Framework. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>Bearer Mobility is a feature that allows a device to change bearers without
-interruption to the user's data sessions. An example of a bearer change is
-if a device moves into the range of a Wi-Fi hot spot and the device moves
-the GPRS connections over to Wi-Fi. Example data sessions include: streaming
-videos; surfing the internet; and downloading emails. Example bearers include:
-Wireless LAN (eg Wi-Fi); 3G (including HSUPA and HSDPA); Circuit Switched
-Data (CSD); and GPRS. </p>
-<fig id="GUID-64CF6B77-F451-56F2-9223-4DB0AE835E56">
-<title>           Example of a bearer change          </title>
-<desc><p>A device is connected to a mobile network using GPRS. The device
-comes into range of a Wi-Fi network. The device decides to change to the Wi-Fi
-network and creates a bearer to access the Wi-Fi network. The device then
-moves all the existing connections across to the Wi-Fi bearer. In the final
-step the device disconnects from the GPRS network. </p> </desc>
-<image href="GUID-65A4BA91-579F-5B9B-ACC1-D3D9B1F233B7_d0e84262_href.png" placement="inline"/>
-</fig>
-<p>Bearer Mobility operates in response to changes in the environment of the
-device. A bearer is known as <i>available</i> when the device is in range
-of the bearer and the device can potentially use the bearer. </p>
-<p> <b>NOTE:</b> The bearer can be available but unusable because of the security
-requirements of the bearer. </p>
-<p>Symbian platform uses <i>non-seamless</i> Bearer Mobility. Non-seamless
-indicates that clients of the Socket Server must reconnect all sockets after
-the bearer has changed. The local IP address of the link changes if the bearer
-changes. </p>
-<section id="GUID-0C818D67-819E-417B-9DBE-53E439555E57"><title>Bearer Mobility APIs</title> <p>Two Socket Server Bearer Mobility
-APIs are available: <xref href="GUID-D5F43DFB-5143-3563-8655-16E245A9735F.dita"><apiname>RCommsMobilityApiExt</apiname></xref> and <xref href="GUID-6CA83252-4D0C-3B72-83ED-B5152B666C83.dita"><apiname>CActiveCommsMobilityApiExt</apiname></xref>.
-A client of the Socket Server cannot change bearer if the client does not
-use at least one Bearer Mobility API. A device can have clients that support
-Bearer Mobility and clients that do not support Bearer Mobility. If clients
-that support Bearer Mobility change bearer, the device does not disconnect
-a client that does not support Bearer Mobility unless that client's bearer
-is no longer available. </p> <p>A client of the socket server can ask the
-user to accept or deny the change of bearer. For example, the client can display
-a dialog box to ask the user to accept or deny the change. The decision to
-ask the user remains with the client. </p> <p>A client of the socket server
-can ask to use the default bearer. The default bearer is the highest priority
-bearer that is available. The device manufacturer or network operator creates
-the list of bearer priorities. </p> </section>
-<section id="GUID-717F07AE-6C85-5051-9CCB-9B23FC40DADD"><title>Bearer Mobility
-Blacklists</title> <p>The Bearer Mobility components in the Communications
-Architecture implement a <i>blacklist</i> feature. The Socket Server implements
-the blacklist feature on the server side. The blacklist feature affects the
-notifications that a Socket Server client receives. The blacklist feature
-stops notifications for bearer changes that have previously been rejected.
-The device keeps a blacklist for each client. </p> <p>For example: </p> <ol id="GUID-8B1E6BD1-AE7B-5BDB-A73E-A4D0FC194AF9">
-<li id="GUID-683FD641-5E1A-58D7-B171-2B6E28FACF0D"><p>A client receives a
-notification for a bearer change </p> </li>
-<li id="GUID-5AE721C6-10ED-5E48-9C03-451CAD47B474"><p>The client sends a response
-to reject the bearer change </p> </li>
-<li id="GUID-4AEE582D-C6E4-534E-999E-BFDC1F7C4237"><p>The device adds the
-rejected bearer to the blacklist for that client </p> </li>
-<li id="GUID-9AAD65F6-94A2-5704-B224-47A93EA9F7B6"><p>The device does not
-notify the client of any further opportunities to change to that bearer </p> </li>
-</ol> <p>There can be variations in the operation of the blacklist. For example,
-there can be a limit on the lifetime of the blacklist. </p> <p> <b>NOTE:</b> The
-blacklist scheme is dependent on the plug-ins and settings used for the Communications
-Architecture for the particular device. </p> </section>
-</conbody><related-links>
-<link href="GUID-CB1E1921-9CF7-55B7-9F70-6AD61A961208.dita"><linktext>Using the
-                Bearer Mobility APIs</linktext></link>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-EDC16636-B24E-598B-9084-EAE782A4A213" xml:lang="en"><title>What
+is Bearer Mobility</title><shortdesc>This topic describes the concept of <i>Bearer Mobility</i> in the
+Communications Framework. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>Bearer Mobility is a feature that allows a device to change bearers without
+interruption to the user's data sessions. An example of a bearer change is
+if a device moves into the range of a Wi-Fi hot spot and the device moves
+the GPRS connections over to Wi-Fi. Example data sessions include: streaming
+videos; surfing the internet; and downloading emails. Example bearers include:
+Wireless LAN (eg Wi-Fi); 3G (including HSUPA and HSDPA); Circuit Switched
+Data (CSD); and GPRS. </p>
+<fig id="GUID-64CF6B77-F451-56F2-9223-4DB0AE835E56">
+<title>           Example of a bearer change          </title>
+<desc><p>A device is connected to a mobile network using GPRS. The device
+comes into range of a Wi-Fi network. The device decides to change to the Wi-Fi
+network and creates a bearer to access the Wi-Fi network. The device then
+moves all the existing connections across to the Wi-Fi bearer. In the final
+step the device disconnects from the GPRS network. </p> </desc>
+<image href="GUID-65A4BA91-579F-5B9B-ACC1-D3D9B1F233B7_d0e77550_href.png" placement="inline"/>
+</fig>
+<p>Bearer Mobility operates in response to changes in the environment of the
+device. A bearer is known as <i>available</i> when the device is in range
+of the bearer and the device can potentially use the bearer. </p>
+<p> <b>NOTE:</b> The bearer can be available but unusable because of the security
+requirements of the bearer. </p>
+<p>Symbian platform uses <i>non-seamless</i> Bearer Mobility. Non-seamless
+indicates that clients of the Socket Server must reconnect all sockets after
+the bearer has changed. The local IP address of the link changes if the bearer
+changes. </p>
+<section id="GUID-0C818D67-819E-417B-9DBE-53E439555E57"><title>Bearer Mobility APIs</title> <p>Two Socket Server Bearer Mobility
+APIs are available: <xref href="GUID-D5F43DFB-5143-3563-8655-16E245A9735F.dita"><apiname>RCommsMobilityApiExt</apiname></xref> and <xref href="GUID-6CA83252-4D0C-3B72-83ED-B5152B666C83.dita"><apiname>CActiveCommsMobilityApiExt</apiname></xref>.
+A client of the Socket Server cannot change bearer if the client does not
+use at least one Bearer Mobility API. A device can have clients that support
+Bearer Mobility and clients that do not support Bearer Mobility. If clients
+that support Bearer Mobility change bearer, the device does not disconnect
+a client that does not support Bearer Mobility unless that client's bearer
+is no longer available. </p> <p>A client of the socket server can ask the
+user to accept or deny the change of bearer. For example, the client can display
+a dialog box to ask the user to accept or deny the change. The decision to
+ask the user remains with the client. </p> <p>A client of the socket server
+can ask to use the default bearer. The default bearer is the highest priority
+bearer that is available. The device manufacturer or network operator creates
+the list of bearer priorities. </p> </section>
+<section id="GUID-717F07AE-6C85-5051-9CCB-9B23FC40DADD"><title>Bearer Mobility
+Blacklists</title> <p>The Bearer Mobility components in the Communications
+Architecture implement a <i>blacklist</i> feature. The Socket Server implements
+the blacklist feature on the server side. The blacklist feature affects the
+notifications that a Socket Server client receives. The blacklist feature
+stops notifications for bearer changes that have previously been rejected.
+The device keeps a blacklist for each client. </p> <p>For example: </p> <ol id="GUID-8B1E6BD1-AE7B-5BDB-A73E-A4D0FC194AF9">
+<li id="GUID-683FD641-5E1A-58D7-B171-2B6E28FACF0D"><p>A client receives a
+notification for a bearer change </p> </li>
+<li id="GUID-5AE721C6-10ED-5E48-9C03-451CAD47B474"><p>The client sends a response
+to reject the bearer change </p> </li>
+<li id="GUID-4AEE582D-C6E4-534E-999E-BFDC1F7C4237"><p>The device adds the
+rejected bearer to the blacklist for that client </p> </li>
+<li id="GUID-9AAD65F6-94A2-5704-B224-47A93EA9F7B6"><p>The device does not
+notify the client of any further opportunities to change to that bearer </p> </li>
+</ol> <p>There can be variations in the operation of the blacklist. For example,
+there can be a limit on the lifetime of the blacklist. </p> <p> <b>NOTE:</b> The
+blacklist scheme is dependent on the plug-ins and settings used for the Communications
+Architecture for the particular device. </p> </section>
+</conbody><related-links>
+<link href="GUID-CB1E1921-9CF7-55B7-9F70-6AD61A961208.dita"><linktext>Using the
+                Bearer Mobility APIs</linktext></link>
 </related-links></concept>
\ No newline at end of file