Fix doc build errors

There were some parts that had invalid RST in their docstrings
which caused warnings and errors to be generated.

Related-Bug: #1278662
Change-Id: Ibb53e6f49b5fa100fa6ecfe47331f9a70729d03b

1 files changed, 29 insertions, 22 deletions

diff --git a/keystoneclient/common/cms.py b/keystoneclient/common/cms.py
index 6a491e8..a56fe27 100644
--- a/keystoneclient/common/cms.py
+++ b/keystoneclient/common/cms.py
@@ -171,38 +171,45 @@ def is_ans1_token(token):
 
     thx to ayoung for sorting this out.
 
-    base64 decoded hex representation of MII is 3082
-    In [3]: binascii.hexlify(base64.b64decode('MII='))
-    Out[3]: '3082'
+    base64 decoded hex representation of MII is 3082::
+
+      In [3]: binascii.hexlify(base64.b64decode('MII='))
+      Out[3]: '3082'
 
     re: http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
 
-    pg4:  For tags from 0 to 30 the first octet is the identfier
-    pg10: Hex 30 means sequence, followed by the length of that sequence.
-    pg5:  Second octet is the length octet
-          first bit indicates short or long form, next 7 bits encode the number
-          of subsequent octets that make up the content length octets as an
-          unsigned binary int
+    ::
+
+      pg4:  For tags from 0 to 30 the first octet is the identfier
+      pg10: Hex 30 means sequence, followed by the length of that sequence.
+      pg5:  Second octet is the length octet
+            first bit indicates short or long form, next 7 bits encode the
+            number of subsequent octets that make up the content length octets
+            as an unsigned binary int
 
-          82 = 10000010 (first bit indicates long form)
-          0000010 = 2 octets of content length
-          so read the next 2 octets to get the length of the content.
+            82 = 10000010 (first bit indicates long form)
+            0000010 = 2 octets of content length
+            so read the next 2 octets to get the length of the content.
 
     In the case of a very large content length there could be a requirement to
     have more than 2 octets to designate the content length, therefore
     requiring us to check for MIM, MIQ, etc.
-    In [4]: base64.b64encode(binascii.a2b_hex('3083'))
-    Out[4]: 'MIM='
-    In [5]: base64.b64encode(binascii.a2b_hex('3084'))
-    Out[5]: 'MIQ='
-    Checking for MI would become invalid at 16 octets of content length
-    10010000 = 90
-    In [6]: base64.b64encode(binascii.a2b_hex('3090'))
-    Out[6]: 'MJA='
-    Checking for just M is insufficient
+
+    ::
+
+      In [4]: base64.b64encode(binascii.a2b_hex('3083'))
+      Out[4]: 'MIM='
+      In [5]: base64.b64encode(binascii.a2b_hex('3084'))
+      Out[5]: 'MIQ='
+      Checking for MI would become invalid at 16 octets of content length
+      10010000 = 90
+      In [6]: base64.b64encode(binascii.a2b_hex('3090'))
+      Out[6]: 'MJA='
+      Checking for just M is insufficient
 
     But we will only check for MII:
-    Max length of the content using 2 octets is 7FFF or 32767
+    Max length of the content using 2 octets is 7FFF or 32767.
+
     It's not practical to support a token of this length or greater in http
     therefore, we will check for MII only and ignore the case of larger tokens
     """