diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4071d4d..debd498 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -2,13 +2,11 @@
 
 ## Breaking for servers as well as clients:
 * The version string in the WebFinger announcement was updated from -03 to -04
-
-## Breaking for clients:
-* The properties in the WebFinger announcement were made optional:
-  https://github.com/remotestorage/spec/blob/master/draft-dejong-remotestorage-04.txt#L461
+* Implicit auth is now indicated with a `null` <auth-dialog> property instead of `false`.
+* The way to announce support for query parameter bearer tokens and range requests has changed, both for servers that do support it, and servers that don't.
 
 ## Non-breaking:
-* Support for web-authoring was added as an optional feature.
+* Servers may now offer any extension features they want.
 * Several mistakes in the text and wire examples were fixed.
 * Several confusing formulations in the text were improved.
 
diff --git a/draft-dejong-remotestorage-04.txt b/draft-dejong-remotestorage-04.txt
index cd8b2d9..e4ff754 100644
--- a/draft-dejong-remotestorage-04.txt
+++ b/draft-dejong-remotestorage-04.txt
@@ -473,16 +473,16 @@ Internet-Draft              remoteStorage                  December 2014
     }
 
     Here <storage_root> and <storage_api> are as per "Session
-    description" above, and <auth-dialog> SHOULD be eihter the boolean
-    value false or a URL where an OAuth 2.0 implicit-grant flow dialog
-    [OAUTH] is presented.
+    description" above, and <auth-dialog> SHOULD be either null or a
+    URL where an OAuth 2.0 implicit-grant flow dialog [OAUTH] is
+    presented.
 
     If <auth-dialog> is a URL, the user can supply their credentials
     there (how, is out of scope), and allow or reject a request by the
     connecting application to obtain a bearer token for a certain list
     of access scopes.
 
-    If <auth-dialog> is false, the client will not have a way to obtain
+    If <auth-dialog> is null, the client will not have a way to obtain
     an access token, and SHOULD send all requests without Authorization
     header, and rely on Kerberos [KERBEROS] instead for requests that
     would normally be sent with a bearer token, but servers SHOULD NOT
@@ -492,7 +492,7 @@ Internet-Draft              remoteStorage                  December 2014
     The '...' ellipses indicate that more properties may be present.
     Non-breaking examples that have been proposed so far, include a
     "http://tools.ietf.org/html/rfc6750#section-2.3" property, set to
-    the boolean value true if the server supports passing the bearer
+    the string value "true" if the server supports passing the bearer
     token in the URI query parameter as per section 2.3 of [BEARER],
     instead of in the request header.
 
diff --git a/source.txt b/source.txt
index adae688..3d31856 100644
--- a/source.txt
+++ b/source.txt
@@ -410,16 +410,16 @@ Table of Contents
     }
 
     Here <storage_root> and <storage_api> are as per "Session
-    description" above, and <auth-dialog> SHOULD be eihter the boolean
-    value false or a URL where an OAuth 2.0 implicit-grant flow dialog
-    [OAUTH] is presented.
+    description" above, and <auth-dialog> SHOULD be either null or a
+    URL where an OAuth 2.0 implicit-grant flow dialog [OAUTH] is
+    presented.
 
     If <auth-dialog> is a URL, the user can supply their credentials
     there (how, is out of scope), and allow or reject a request by the
     connecting application to obtain a bearer token for a certain list
     of access scopes.
 
-    If <auth-dialog> is false, the client will not have a way to obtain
+    If <auth-dialog> is null, the client will not have a way to obtain
     an access token, and SHOULD send all requests without Authorization
     header, and rely on Kerberos [KERBEROS] instead for requests that
     would normally be sent with a bearer token, but servers SHOULD NOT
@@ -429,7 +429,7 @@ Table of Contents
     The '...' ellipses indicate that more properties may be present.
     Non-breaking examples that have been proposed so far, include a
     "http://tools.ietf.org/html/rfc6750#section-2.3" property, set to
-    the boolean value true if the server supports passing the bearer
+    the string value "true" if the server supports passing the bearer
     token in the URI query parameter as per section 2.3 of [BEARER],
     instead of in the request header.