diff --git a/content-negotiation.md b/content-negotiation.md
new file mode 100644
index 00000000..7b2b6ce7
--- /dev/null
+++ b/content-negotiation.md
@@ -0,0 +1,4 @@
+## Content Negotiation
+
+TODO - Please see
+[issue #212](https://github.com/opencontainers/distribution-spec/issues/212).
\ No newline at end of file
diff --git a/spec.md b/spec.md
index a4e02aa3..7289d341 100644
--- a/spec.md
+++ b/spec.md
@@ -122,6 +122,7 @@ In order to test a registry's conformance against these workflow categories, ple
 ### Workflow Categories
 
 #### Pull
+
 The process of pulling an artifact centers around retrieving two components: the manifest and one or more blobs.
 
 Typically, the first step in pulling an artifact is to retrieve the manifest. However, you MAY retrieve content from the registry in any order.
@@ -136,6 +137,10 @@ The `<reference>` MUST NOT be in any other format. Throughout this document, `<n
 
 `[a-z0-9]+([._-][a-z0-9]+)*(/[a-z0-9]+([._-][a-z0-9]+)*)*`
 
+The client SHOULD include an `Accept` header indicating which manifest content types it supports.
+In a successful response, the `Content-Type` header will indicate the type of the returned manifest.
+For more information on the use of `Accept` headers and content negotiation, please see [Content Negotiation](./content-negortiation.md)
+
 A GET request to an existing manifest URL MUST provide the expected manifest, with a response code that MUST be `200 OK`.
 
 The `OCI-Content-Digest` header (or, as a fallback, `Docker-Content-Digest` header), if present on the response, returns the canonical