--- JSON-XS/XS.pm	2014/03/02 22:09:38	1.154
+++ JSON-XS/XS.pm	2014/11/24 18:42:51	1.155
@@ -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])
@@ -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