Add a header with manifest tag to pull and push

spec.md

@@ -157,6 +157,10 @@ The `Content-Type` header SHOULD match what the client [pushed as the manifest's
 If the manifest has a `mediaType` field, clients SHOULD reject unless the `mediaType` field's value matches the type specified by the `Content-Type` header.
 For more information on the use of `Accept` headers and content negotiation, please see [Content Negotiation](./content-negotiation.md).
 
+The client SHOULD include a `Docker-Manifest-Tag` header indicating which manifest tag is being pulled.
+This header SHOULD be added to all requests throughout the pull process.
+Registries MAY use this value as a hint when handling the pulled manifests and blobs.
+
 A GET request to an existing manifest URL MUST provide the expected manifest, with a response code that MUST be `200 OK`.
 A successful response SHOULD contain the digest of the uploaded blob in the header `Docker-Content-Digest`.
 
@@ -201,6 +205,10 @@ A useful diagram is provided [here](https://github.com/google/go-containerregist
 A registry MAY reject a manifest of any type uploaded to the manifest endpoint if it references manifests or blobs that do not exist in the registry.
 When a manifest is rejected for this reason, it must result in one or more `MANIFEST_BLOB_UNKNOWN` errors <sup>[code-1](#error-codes)</sup>.
 
+The client SHOULD include a `Docker-Manifest-Tag` header indicating which manifest tag is being pushed.
+This header SHOULD be added to all requests throughout the push process.
+Registries MAY use this value as a hint when handling the pushed manifests and blobs.
+
 ##### Pushing blobs
 
 There are two ways to push blobs: chunked or monolithic.