--- JSON-XS/XS.pm	2014/03/02 20:41:14	1.153
+++ JSON-XS/XS.pm	2016/02/21 15:37:53	1.156
@@ -406,6 +406,16 @@
         # neither this one...
   ]
 
+=item * literal ASCII TAB characters in strings
+
+Literal ASCII TAB characters are now allowed in strings (and treated as
+C<\t>).
+
+  [
+     "Hello\tWorld",
+     "Hello<TAB>World", # literal <TAB> would not normally be allowed
+  ]
+
 =back
 
 =item $json = $json->canonical ([$enable])
@@ -689,7 +699,7 @@
 and you need to know where the JSON text ends.
 
    JSON::XS->new->decode_prefix ("[1] the tail")
-   => ([], 3)
+   => ([1], 3)
 
 =back
 
@@ -1614,7 +1624,7 @@
 structure looking for arrays with a first element of
 C<XU1peReLzT4ggEllLanBYq4G9VzliwKF>.
 
-The same approach cna be used to create the tagged format with another
+The same approach can be used to create the tagged format with another
 encoder. First, you create an array with the magic string as first member,
 the classname as second, and constructor arguments last, encode it as part
 of your JSON structure, and then:
@@ -1625,19 +1635,22 @@
 with character escapes, and the constructor arguments must be non-empty.
 
 
-=head1 RFC7158
+=head1 RFC7159
 
-Since this module was written, Google has written a new JSON RFC, RFC
-7158. Unfortunately, this RFC breaks compatibility with both the original
-JSON specification on www.json.org and RFC4627.
+Since this module was written, Google has written a new JSON RFC, RFC 7159
+(and RFC7158). Unfortunately, this RFC breaks compatibility with both the
+original JSON specification on www.json.org and RFC4627.
 
 As far as I can see, you can get partial compatibility when parsing by
 using C<< ->allow_nonref >>. However, consider thew security implications
 of doing so.
 
-I haven't decided yet whether to break compatibility with RFC4627 by
-default (and potentially leave applications insecure), or change the
-default to follow RFC7158.
+I haven't decided yet when to break compatibility with RFC4627 by default
+(and potentially leave applications insecure) and change the default to
+follow RFC7159, but application authors are well advised to call C<<
+->allow_nonref(0) >> even if this is the current default, if they cannot
+handle non-reference values, in preparation for the day when the4 default
+will change.
 
 
 =head1 THREADS