diff --git a/Communication.md b/Communication.md
index 6befdef..434e322 100644
--- a/Communication.md
+++ b/Communication.md
@@ -13,7 +13,7 @@ Communication between the two worker threads is split into two separate parts,
 each one holding dedicated connection line. These internal lines are realized by 
 ZeroMQ inproc PAIR sockets. In this section we assume that the thread of the 
 worker which communicates with broker is called _listening thread_ and the other 
-one, which is evaluating incoming jobs is called _job thread_. _Listening 
+one, which is evaluating incoming jobs is called _execution thread_. _Listening 
 thread_ is a server in both cases (the one who calls the `bind()` method), but 
 because of how ZeroMQ works, it's not very important (`connect()` call in 
 clients can precede server `bind()` call with no issue).
@@ -22,9 +22,9 @@ clients can precede server `bind()` call with no issue).
 
 Main communication is on `inproc://jobs` sockets. _Listening thread_ is waiting 
 for any messages (from broker, jobs and progress sockets) and passes incoming 
-requests to the _job thread_, which handles them properly.
+requests to the _execution thread_, which handles them properly.
 
-Commands from _listening thread_ to _job thread_:
+Commands from _listening thread_ to _execution thread_:
 
 - **eval** - evaluate a job. Requires 3 message frames:
     - `job_id` - identifier of this job (in ASCII representation -- we avoid endianness issues and also 
@@ -32,7 +32,7 @@ Commands from _listening thread_ to _job thread_:
     - `job_url` - URI location of archive with job configuration and submitted source code
     - `result_url` - remote URI where results will be pushed to
 
-Commands from _job thread_ to _listening thread_:
+Commands from _execution thread_ to _listening thread_:
 
 - **done** - notifying of finished job. Requires 2 message frames:
     - `job_id` - identifier of finished job
@@ -46,7 +46,7 @@ path. The configuration could be linked there under some well-known name.
 
 ### Progress callback
 
-Progress messages are sent through `inproc://progress` sockets. This is only one way communication from _job thread_ to the _listening thread_.
+Progress messages are sent through `inproc://progress` sockets. This is only one way communication from _execution thread_ to the _listening thread_.
 
 Commands:
 
@@ -69,7 +69,7 @@ Commands from broker to worker:
 
 Commands from worker to broker:
 
-- **init** - introduce yourself to the broker. Useful on startup or after reestablishing lost connection. Requires at least two arguments:
+- **init** - introduce yourself to the broker. Useful on startup or after reestablishing lost connection. Requires at least 2 arguments:
     - `hwgroup` - hardware group of this worker
     - `header` - additional header describing worker capabilities. Format must be `header_name=value`, every header shall be in a separate message frame. There is no maximum limit on number of headers.
 - **done** - job evaluation finished, see **done** command in [[Communication#main-communication]].
@@ -116,10 +116,10 @@ server, its IP address and port is configurable in frontend.
 
 Commands from frontend to broker:
 
-- **eval** - evaluate a job. Requires 4 frames:
+- **eval** - evaluate a job. Requires at least 4 frames:
     - `job_id` - identifier of this job (in ASCII representation -- we avoid endianness issues and also 
   support alphabetic ids)
-    - `header` - additional header describing worker capabilities. Format must be `header_name=value`, every header shall be in a separate message frame. There is no maximum limit on number of headers.
+    - `header` - additional header describing worker capabilities. Format must be `header_name=value`, every header shall be in a separate message frame. There is no maximum limit on number of headers. There may be also no headers at all.
     - empty frame (with empty string)
     - `job_url` - URI location of archive with job configuration and submitted source code
     - `result_url` - remote URI where results will be pushed to