Fix some wording and make recommendations stricter

source/chapter1-about.rst

@@ -59,8 +59,10 @@ Assumptions
 - Update capsules are designed and deployed to target systems using a mechanism outside the
   scope of this document.  [#UEFICapsuleUpdateNote]_
 - We assume that the masked ROM can load TF-A from a dual image.  In case the masked ROM can not
-  boot with an alternative location, similar functionality can be added to BL2.  In that case
-  updpating BL2 will not be protected against bricking
+  boot with an alternative location, similar functionality can be added to BL2.
+  In that case updating of BL2 should be disallowed from OTA
+  update.  In person update of BL2 may be possible and may require extra
+  tools or procedures but that is out of the scope of this document.
 - Update process can target a single firmware component or multiple components.  Updating multiple
   components and multiplexing boot combinations can be very challenging.  In this document we treat
   the firmware as a single entity regardless of the components it comprises.

source/chapter2-uefi.rst

@@ -52,7 +52,7 @@ explicitly accept the image by installing an acceptance capsule as described in
 .. [#provisional] Presenting the image acceptance status in the LastAttemptedStatus field is a provisional arrangement. A more permanet solution is under discussion.
 
 A UEFI implementation can opt to implicitly accept any FW image. It is
-advisable that the FW image acceptance is treated as an OS responsibility.
+strongly recommended that the FW image acceptance is treated as an OS responsibility.
 
 OS requested FW revert
 ----------------------