Skip to content
This repository was archived by the owner on Jul 7, 2025. It is now read-only.

Commit ddfe4ac

Browse files
committed
addressed issues #21, #14, #6
1 parent bdd4276 commit ddfe4ac

File tree

1 file changed

+18
-28
lines changed

1 file changed

+18
-28
lines changed

draft-ietf-httpapi-deprecation-header.md

Lines changed: 18 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -131,6 +131,14 @@ The following example uses the same link header field, but also announces a depr
131131

132132
Given that the deprecation date is in the past, the linked information resource may have been updated to include information about the deprecation, allowing consumers to discover information about the deprecation and how to best manage it.
133133

134+
### Security Considerations
135+
136+
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. Applications consuming the resource SHOULD check the resource documentation to verify authenticity and accuracy. Resource documentation SHOULD provide additional information about the deprecation, potentially including recommendation(s) for replacement.
137+
138+
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, applications consuming the resource SHOULD verify the resource documentation and if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to recommended resource.
139+
140+
In cases where a `Link` header field is used to provide documentation, one should assume 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. Applications consuming the resource SHOULD check the referred resource documentation to verify authenticity and accuracy.
141+
134142

135143
# Sunset
136144

@@ -151,7 +159,7 @@ The act of deprecation does not change any behavior of the resource. Deprecated
151159

152160
## The Deprecation HTTP Response Header Field
153161

154-
The `Deprecation` response header field should be added to the permanent registry of message header fields (see {{!RFC3864}}).
162+
The `Deprecation` response header field should be added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry ({{Section 16.3.1 of HTTP}})
155163

156164
Header Field Name: Deprecation
157165

@@ -188,6 +196,15 @@ The `deprecation` link relation type should be added to the permanent registry o
188196
Section 3 "The Deprecation Link Relation Type"
189197

190198

199+
# Examples
200+
201+
The following example does not show complete HTTP interaction. It only shows those HTTP header fields in a response that are relevant for resource deprecation.
202+
203+
Deprecation: @1688169599
204+
Link: <https://developer.example.com/deprecation>; rel="deprecation"
205+
206+
207+
--- back
191208

192209
# Implementation Status
193210

@@ -269,33 +286,6 @@ Organization: PayPal
269286
- Reference: https://github.com/paypal/api-standards/blob/master/api-style-guide.md#runtime
270287

271288

272-
# Security Considerations
273-
274-
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. Applications consuming the resource SHOULD check the resource documentation to verify authenticity and accuracy. Resource documentation SHOULD provide additional information about the deprecation, potentially including recommendation(s) for replacement.
275-
276-
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, applications consuming the resource SHOULD verify the resource documentation and if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to recommended resource.
277-
278-
In cases where a `Link` header field is used to provide documentation, one should assume 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. Applications consuming the resource SHOULD check the referred resource documentation to verify authenticity and accuracy.
279-
280-
281-
# Examples
282-
283-
The following examples do not show complete HTTP interactions. They only show those HTTP header fields in a response that are relevant for resource deprecation.
284-
285-
The first example shows a deprecation header field with date information:
286-
287-
Deprecation: @1688169599
288-
289-
The second example shows a deprecation header field with a link for the resource's deprecation policy. In addition, it shows the sunset date for the deprecated resource:
290-
291-
Deprecation: @1688169599
292-
Sunset: Sun, 30 Jun 2024 23:59:59 GMT
293-
Link: <https://developer.example.com/deprecation>; rel="deprecation"
294-
295-
296-
297-
--- back
298-
299289
# Changes from Draft-03 {#changes}
300290

301291
This revision has made the following changes:

0 commit comments

Comments
 (0)