Ignore invalid Push-Dont-Notify values

Author: rfc2822

content.mkd

@@ -306,11 +306,11 @@ HTTP/1.1 204 Unregistered
 
 ## Expiration
 
-When a client registers a subscription, it can request a specific expiration date-time. A server SHOULD take the requested expiration time into consideration, but MAY impose its own (often stricter) expiration rules. A server SHOULD allow subscriptions to be valid at least three days. When the expiration is too far in the future, it becomes more probable that the subscription will become invalid or stale at some time.
+When a client registers or updates a subscription, it can request a specific expiration date-time. A server SHOULD take the requested expiration time into consideration, but MAY impose its own (often stricter) expiration rules. A server SHOULD allow subscriptions to be valid at least three days. When the expiration is too far in the future, it becomes more probable that the subscription will become invalid or stale at some time.
 
 A client has to refresh its registrations regularly and before the expiration to keep them working. It can expect that subscriptions usually stay valid until their expiration, although there may be special circumstances that cause all subscriptions to be reset, like when the server software is changed.
 
-A server MUST NOT send notifications to expired subscriptions as chances are high that doing so would cause errors.
+A server MUST NOT send a notification to an expired subscription.
 
 
 
@@ -365,6 +365,8 @@ Because URLs are not per se canonical, registration URLs MUST be provided in the
 
 Multiple values can be provided as a list and/or using multiple lines as described in {{Section 5.2 of RFC9110}}. If the asterisk is used, other values MUST NOT be sent.
 
+A server MUST ignore invalid values.
+
 Example 1:
 
 ~~~http-message