Editorial pass through second 1/2 of Bluetooth chapter.

Protocols section is still a bit dense.

Sponsored by: iXsystems

en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml

@@ -2488,8 +2488,8 @@ hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:
     <sect2>
       <title>Bluetooth Protocols</title>
       
-      <para>This section describes the various Bluetooth utilities,
-	their function, and available utilities.</para>
+      <para>This section provides an overview of the various Bluetooth protocols,
+	their function, and associated utilities.</para>
    
     <sect3>
       <title>Logical Link Control and Adaptation Protocol
@@ -2501,16 +2501,15 @@ hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:
 
       <para>The Logical Link Control and Adaptation Protocol
 	(<acronym>L2CAP</acronym>) provides connection-oriented and
-	connectionless data services to upper layer protocols with
-	protocol multiplexing capability and segmentation and
-	reassembly operation.  <acronym>L2CAP</acronym> permits
+	connectionless data services to upper layer protocols.
+	<acronym>L2CAP</acronym> permits
 	higher level protocols and applications to transmit and
 	receive <acronym>L2CAP</acronym> data packets up to 64
 	kilobytes in length.</para>
 
       <para><acronym>L2CAP</acronym> is based around the concept of
 	<emphasis>channels</emphasis>.  A channel is a logical
-	connection on top of a baseband connection.  Each channel is
+	connection on top of a baseband connection, where each channel is
 	bound to a single protocol in a many-to-one fashion.  Multiple
 	channels can be bound to the same protocol, but a channel
 	cannot be bound to multiple protocols.  Each
@@ -2518,9 +2517,9 @@ hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:
 	directed to the appropriate higher level protocol.  Multiple
 	channels can share the same baseband connection.</para>
 
-      <para>A single netgraph node of type <emphasis>l2cap</emphasis>
-	is created for a single Bluetooth device.  The
-	<acronym>L2CAP</acronym> node is normally connected to the
+      <para>In &os;, a netgraph <acronym>L2CAP</acronym> node
+	is created for each Bluetooth device.  This
+	node is normally connected to the
 	downstream Bluetooth <acronym>HCI</acronym> node and upstream
 	Bluetooth socket nodes.  The default name for the
 	<acronym>L2CAP</acronym> node is <quote>devicel2cap</quote>.
@@ -2574,10 +2573,9 @@ c2e8bc80      0    250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3    6    OPEN</scree
 
       <para>The <acronym>RFCOMM</acronym> protocol provides emulation
 	of serial ports over the <acronym>L2CAP</acronym> protocol.
-	The protocol is based on the ETSI standard TS 07.10.
 	<acronym>RFCOMM</acronym> is a simple transport protocol,
 	with additional provisions for emulating the 9 circuits of
-	RS-232 (EIATIA-232-E) serial ports.  <acronym>RFCOMM</acronym>
+	RS-232 (EIATIA-232-E) serial ports.  It
 	supports up to 60 simultaneous connections
 	(<acronym>RFCOMM</acronym> channels) between two Bluetooth
 	devices.</para>
@@ -2693,8 +2691,8 @@ Bluetooth Profile Descriptor List:
 
       <screen>&prompt.root; <userinput>service sdpd start</userinput></screen>
 
-      <para>The local server application that wants to provide
-	Bluetooth service to the remote clients will register service
+      <para>The local server application that wants to provide a
+	Bluetooth service to remote clients will register the service
 	with the local <acronym>SDP</acronym> daemon.  An example of
 	such an application is &man.rfcomm.pppd.8;.  Once started,
 	it will register the Bluetooth LAN service with the local
@@ -2710,36 +2708,36 @@ Bluetooth Profile Descriptor List:
 
     <sect3>
       <title><acronym>OBEX</acronym> Object Push
-	(<acronym>OPUSH</acronym>) Profile</title>
+	(<acronym>OPUSH</acronym>)</title>
 
       <indexterm>
 	<primary>OBEX</primary>
       </indexterm>
 
-      <para><acronym>OBEX</acronym> is a widely used protocol for
+      <para>Object Exchange (<acronym>OBEX</acronym>) is a widely used protocol for
 	simple file transfers between mobile devices.  Its main use
 	is in infrared communication, where it is used for generic
 	file transfers between notebooks or <acronym>PDA</acronym>s,
 	and for sending business cards or calendar entries between
-	cellular phones and other devices with <acronym>PIM</acronym>
+	cellular phones and other devices with Personal Information Manager (<acronym>PIM</acronym>)
 	applications.</para>
 
       <para>The <acronym>OBEX</acronym> server and client are
-	implemented as a third-party package,
-	<application>obexapp</application>, which is available as
+	implemented by
+	<application>obexapp</application>, which can be installed using the
 	<package>comms/obexapp</package> package or
 	port.</para>
 
       <para>The <acronym>OBEX</acronym> client is used to push and/or
-	pull objects from the <acronym>OBEX</acronym> server.  An
-	object can, for example, be a business card or an appointment.
+	pull objects from the <acronym>OBEX</acronym> server.  An example
+	object is a business card or an appointment.
 	The <acronym>OBEX</acronym> client can obtain the
 	<acronym>RFCOMM</acronym> channel number from the remote
 	device via <acronym>SDP</acronym>.  This can be done by
 	specifying the service name instead of the
 	<acronym>RFCOMM</acronym> channel number.  Supported service
-	names are: <acronym>IrMC</acronym>, <acronym>FTRN</acronym>,
-	and <acronym>OPUSH</acronym>.  It is also possible to specify
+	names are: <literal>IrMC</literal>, <literal>FTRN</literal>,
+	and <literal>OPUSH</literal>.  It is also possible to specify
 	the <acronym>RFCOMM</acronym> channel as a number.  Below is
 	an example of an <acronym>OBEX</acronym> session where the
 	device information object is pulled from the cellular phone,
@@ -2781,7 +2779,7 @@ Success, response: OK, Success (0x20)</screen>
       <para>In &os;, &man.rfcomm.sppd.1; implements
 	<acronym>SPP</acronym> and a pseudo tty is used as a virtual
 	serial port abstraction.  The example below shows how to
-	connect to a remote device serial port service.  A
+	connect to a remote device's serial port service.  A
 	<acronym>RFCOMM</acronym> channel does not have to be
 	specified as &man.rfcomm.sppd.1; can obtain it from the
 	remote device via <acronym>SDP</acronym>.  To override this,
@@ -2801,20 +2799,20 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
     <sect2>
       <title>Troubleshooting</title>
 
-	<para>Some older Bluetooth devices do not support role
-	  switching.  By default, when &os; is accepting a new
+	<para>By default, when &os; is accepting a new
 	  connection, it tries to perform a role switch and become
-	  master.  Devices, which do not support this will not be able
+	  master.  Some older Bluetooth devices which do not support role
+	  switching will not be able
 	  to connect.  Since role switching is performed when a
 	  new connection is being established, it is not possible
 	  to ask the remote device if it supports role switching.
-	  There is a <acronym>HCI</acronym> option to disable role
+	  However, there is a <acronym>HCI</acronym> option to disable role
 	  switching on the local side:</para>
 
 	<screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_role_switch 0</userinput></screen>
 
 	<para>To display Bluetooth packets, use the third-party package
-	  <application>hcidump</application>, which is available as a
+	  <application>hcidump</application>, which can be installed using the
 	  <package>comms/hcidump</package> package or
 	  port.  This utility is similar to &man.tcpdump.1; and can
 	  be used to display the contents of Bluetooth packets on