#37 further to address Paul Wouters' comment

Author: sdatspun2

draft-ietf-httpapi-deprecation-header.md

@@ -168,7 +168,7 @@ The `deprecation` link relation type should be added to the permanent registry o
 
 The Deprecation header field should be treated as a hint, meaning that the resource is indicating (and not guaranteeing with certainty) that it will be or is deprecated. Deprecated resources function as they would have without sending the deprecation header field, even though one might consider non-functional details such as making them progressively less efficient with longer response time for example.
 
-Resource documentation should provide additional information about the deprecation, such as including recommendation(s) for replacement. Developers of client applications consuming the resource SHOULD always check the referred resource documentation to verify authenticity and accuracy. In cases where a `Link` header field is used to provide documentation, one should assume (unless served over HTTPS) that the content of the `Link` header field may not be secure, private or integrity-guaranteed, and due caution should be exercised when using it. In cases where the Deprecation header field value is in the past, the client application developers MUST no longer assume that the behavior of the resource would remain the same as before the deprecation date. In cases where the Deprecation header field value is a date in the future, it can lead to information that otherwise might not be available. Therefore, client application developers consuming the resource SHOULD, if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to a recommended resource(s).
+Resource documentation should provide additional information about the deprecation, such as including recommendation(s) for replacement. Developers of client applications consuming the resource SHOULD always check the referred resource documentation to verify authenticity and accuracy. In cases where a `Link` header field is used to provide documentation, one should assume (unless served over HTTPS) that the content of the `Link` header field may not be secure, private or integrity-guaranteed, and due caution should be exercised when using it, see {{Section 5 of LINK}} for more details. In cases where the Deprecation header field value is in the past, the client application developers MUST no longer assume that the behavior of the resource would remain the same as before the deprecation date. In cases where the Deprecation header field value is a date in the future, it can lead to information that otherwise might not be available. Therefore, client application developers consuming the resource SHOULD, if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to a recommended resource(s).
 
 
 --- back