Revert "Add some statement to Locking."

This reverts commit e2bedb70

Documentation-develop/PROTOCOL.md

@@ -484,9 +484,6 @@ Server Response
 ### Record lock
 
 Request, extend or release a lock for a record, identified by the SIP. The SIP contain a SIP_FORM and a SIP_R (record id).
-
-See `Documentation-develop/diagram` for a state diagram.
-
 To detect record change at time of 'record lock' or 'record save', a MD5 hash is provided from the server
 and needs to pass back to dirty.php as well.
 
@@ -500,7 +497,6 @@ URL Parameters
 :  `s=<SIP>`   (form, r)
 :  `action=lock`, `action=extend`, `action=release>`
 :  `recordHashMd5=<value of hidden form element 'recordHashMd5'>`
-:  `tabUniqId=<unique id>`
 
 Server Response
 :	The response contains an [Lock Response].
@@ -513,7 +509,7 @@ JSON Response from the server (extended [Minimal Response]) containing:
 :	{
 :		"status": "success"|"error"|"conflict"|"conflict_allow_force",
 :		"message": "<message>"e5
-:   }
+:    }
    
 `status` indicates how the request has been fulfilled by the server. 
 On`"success"`, the Client display nothing to the user. 
@@ -524,18 +520,11 @@ On `"conflict_allow_force"` the Client opens the alert non-modal (default).
 
 ### tabUniqId
 
-* Client: Every browser tab get's a `tabUniqId` (timestamp) as soon as the first time a lock is requested (acquire). 
-  This `tabUniqId` remains, until the tab is close. It is saved in window.name.
-  
-* Server: On lock request, the `tabUniqId` is saved in dirty record.
- 
-  * The `tabUniqId` helps to implement 'optimistic locking': if there is no argument against 'grant lock' - grant it.
-    Example: In browser tab 'A' a lock is requested. For unknown reason, there is a stale lock for the
-    user session and the given tab id: grant the log. 
-     
-  * Unexpected async behaviour in client: On page reload (F5), the 'lock release' might come after 'lock acquire'. 
-    The form goes in 'read only' mode - an additional page reload (F5) solves the situation - but this is boring.   
-  
+Every tab get's a uniq id (timestamp) on page load: window.name.
+This 'tabUniqId' is saved in dirty record on lock acquire. 
+On page reload, when the 'release' comes after 'acquire' (unwished async behaviour), the locking is skipped (if same user 
+session) - on reload there is no variable 'tabUniqId'. On real lock acquire, the tab ID is compared and will be denied 
+if not matching. The 'tabUniqId' might not work in IE - doesn't matter: it's a seldom special situation.
 
 ### Drag And Drop (sort)