more fixes

diff --git a/doc/txt/tep119.txt b/doc/txt/tep119.txt
index b7157e90eb3f779f21a2e72cad5e3fec264e0ef5..53a3cf6a5172835b29328efe1e80c0d90c6ac01f 100644 (file)
--- a/doc/txt/tep119.txt
+++ b/doc/txt/tep119.txt
@@ -23,15 +23,15 @@ Abstract
 ====================================================================
 
 The memo documents the interfaces, components, and semantics used by
 ====================================================================
 
 The memo documents the interfaces, components, and semantics used by

-collection protocol in TinyOS 2.x. Collection provides best-effort,
-multihop delivery of packets to one of a set of collection points.
-There may be multiple collection points in a network, and in this
-case the semantics are *anycast* delivery to at least one of the
-collection points. A node sending a packet does not specify which of
-the collection points the packet is destined to.  The union of the
-paths from each node to one or more of the collection points forms a
-set of trees, and in this document assume that collection points are
-the roots of these trees.
+the collection protocols in TinyOS 2.x. Collection provides
+best-effort, multihop delivery of packets to one of a set of
+collection points.  There may be multiple collection points in a
+network, and in this case the semantics are *anycast* delivery to at
+least one of the collection points. A node sending a packet does not
+specify which of the collection points the packet is destined to.  The
+union of the paths from each node to one or more of the collection
+points forms a set of trees, and in this document we assume that
+collection points are the roots of these trees.

  
 
 1. Introduction
  
 
 1. Introduction


@@ -90,9 +90,11 @@ root). Depending on their role, the nodes use different interfaces to
 interact with the collection component.
 
 The collection infrastructure can be multiplexed among independent
 interact with the collection component.
 
 The collection infrastructure can be multiplexed among independent

-applications, by means of a collection identifier. While data traffic
-in the protocol is multiplexed through these identifiers, control
-traffic is not: all data traffic uses the same routing topology.
+applications, by means of a collection identifier. The collection
+identifier is used to identify different data traffic at the sender,
+intermediate-nodes, or the receiver, much like port number in TCP. All
+data traffic, regardless of the collection identifier, use the same
+routing topology.

 
 The nodes that generate data to be sent to the root are *senders*.
 Senders use the Send interface [1_] to send data to the root of
 
 The nodes that generate data to be sent to the root are *senders*.
 Senders use the Send interface [1_] to send data to the root of


@@ -130,11 +132,11 @@ use the Receive interface [1_] to receive a message delivered by
 collection. The collection identifier is specified as a parameter to
 Receive during instantiation.
 
 collection. The collection identifier is specified as a parameter to
 Receive during instantiation.
 

-The set of all roots and the paths that
-lead to them form the collection routing infrastructure in the network.
-For any connected set of nodes implementing the collection protocol 
-there is only one collection infrastructure, *i.e.*, all roots in this 
-set active at the same time are part of the same infrastructure.
+The set of all roots and the paths that lead to them form the
+collection routing infrastructure in the network.  For any connected
+set of nodes implementing the collection protocol there is only one
+collection infrastructure, *i.e.*, all roots in this set active at the
+same time are part of the same infrastructure.

 
 The RootControl interface configures whether a node is a
 root::
 
 The RootControl interface configures whether a node is a
 root::


@@ -175,10 +177,10 @@ which has the following signature::
   }
 
 
   }
 
 

-CollectionC MAY have additional interfaces. These additional
-interfaces MUST have default functions on all outgoing invocations
-(commands for uses, events for provides) of those interfaces so that
-it can operate properly if they are not wired.
+CollectionC MAY have additional interfaces. All outgoing invocations
+(commands for uses, events for provides) of those interfaces MUST have
+default functions. Those default functions enable CollectionC to
+operate properly even when the additional interfaces are not wired.

 
 Components SHOULD NOT wire to CollectionC.Send. The generic
 component CollectionSenderC (described in section 3.1) provides
 
 Components SHOULD NOT wire to CollectionC.Send. The generic
 component CollectionSenderC (described in section 3.1) provides


@@ -189,7 +191,7 @@ collection_id_t. Each collection_id_t corresponds to a different
 protocol operating on top of collection, in the same way that
 different am_id_t values represent different protocols operating on
 top of active messages. All packets sent with a particular
 protocol operating on top of collection, in the same way that
 different am_id_t values represent different protocols operating on
 top of active messages. All packets sent with a particular

-collection_id_t generally have the same payload format, so that
+collection_id_t generally SHOULD have the same payload format, so that

 snoopers, intercepters, and receivers can parse them properly.
 
 ColletionC MUST NOT signal Receive.receive on non-root
 snoopers, intercepters, and receivers can parse them properly.
 
 ColletionC MUST NOT signal Receive.receive on non-root