mini update 2: new table of contents

spec.md

@@ -13,49 +13,23 @@ The goal of this specification is to standardize container image distribution ba
 
 ### Table of Contents
 
-- [Introduction](spec.md)
-- [Notational Conventions](#notational-conventions)
-- [Historical Context](#historical-context)
-- [Scope](#scope)
-  - [Future](#future)
-- [Use Cases](#use-cases)
-  - [Image Verification](#image-verification)
-  - [Resumable Push](#resumable-push)
-  - [Resumable Pull](#resumable-pull)
-  - [Layer Upload De-duplication](#layer-upload-de-duplication)
-- [Changes](#changes)
 - [Overview](#overview)
-  - [Errors](#errors)
-  - [API Version Check](#api-version-check)
-  - [Content Digests](#content-digests)
-  - [Pulling An Image](#pulling-an-image)
-  - [Pushing An Image](#pushing-an-image)
-  - [Listing Repositories](#listing-repositories)
-  - [Listing Image Tags](#listing-image-tags)
-  - [Deleting an Image](#deleting-an-image)
-- [Detail](#detail)
-  - [Errors](#errors-2)
-  - [Base](#base)
-  - [Tags](#tags)
-  - [Manifest](#manifest)
-    - [GET Manifest](#get-manifest)
-    - [PUT Manifest](#put-manifest)
-    - [DELETE Manifest](#delete-manifest)
-  - [Blob](#blob)
-    - [GET Blob](#get-blob)
-      - [Fetch Blob](#fetch-blob)
-      - [Fetch Blob Part](#fetch-blob-part)
-    - [DELETE Blob](#delete-blob)
-  - [Initiate Blob Upload](#initiate-blob-upload)
-    - [POST Initiate Blob Upload](#post-initiate-blob-upload)
-      - [Initiate Monolithic Blob Upload](#initiate-monolithic-blob-upload)
-      - [Initiate Resumable Blob Upload](#initiate-resumable-blob-upload)
-      - [Mount Blob](#mount-blob)
-  - [Blob Upload](#blob-upload)
-    - [GET Blob Upload](#get-blob-upload)
-    - [PATCH Blob Upload](#patch-blob-upload)
-    - [PUT Blob Upload](#put-blob-upload)
-    - [DELETE Blob Upload](#delete-blob-upload)
+	- [Introduction](#introduction)
+	- [Historical Context](#historical-context)
+- [Definitions](#defintions)
+	- [Common Terms](#introduction)
+	- [Document Language](#document-language)
+- [Conformance](#conformance)
+	- [Minimum Requirements](#minimum-requirements)
+	- [Official Certification](#official-certification)
+	- [Workflow Categories](#workflow-categories)
+		1. [Pull](#pull)
+		2. [Push](#push)
+		3. [Content Discovery](#content-discovery)
+		4. [Content Management](#content-management)
+- [HTTP API](#http-api)
+	- [Endpoints](#endpoints)
+	- [Error Codes](#error-codes)
 
 ## Notational Conventions
 
@@ -4601,124 +4575,3 @@ The error codes that MAY be included in the response body are enumerated below:
 | Code              | Message           | Description                                                         |
 |-------------------|-------------------|---------------------------------------------------------------------|
 | `TOOMANYREQUESTS` | too many requests | Returned when a client attempts to contact a service too many times |
-
-
-<!--
-
-NOTE: The section below is a workspace for the new spec layout.
-      For more info please see https://github.com/opencontainers/distribution-spec/issues/126
-
----
-title: "HTTP API V2"
-description: "Specification for the Registry API."
-keywords: registry, on-prem, images, tags, repository, distribution, api, advanced
----
-# Open Container Initiative Distribution Specification
-
-
-## Table of Contents
-
-- [Overview](#overview)
-	- [Introduction](#introduction)
-	- [Historical Context](#historical-context)
-- [Definitions](#defintions)
-	- [Common Terms](#introduction)
-	- [Document Language](#document-language)
-- [Conformance](#conformance)
-	- [Minimum Requirements](#minimum-requirements)
-	- [Official Certification](#official-certification)
-	- [Workflow Categories](#workflow-categories)
-		1. [Pull](#pull)
-		2. [Push](#push)
-		3. [Content Discovery](#content-discovery)
-		4. [Content Management](#content-management)
-- [HTTP API](#http-api)
-	- [Endpoints](#endpoints)
-	- [Error Codes](#error-codes)
-
-## Overview
-
-### Introduction
-
-The Open Container Initiative Distribution Specification defines an API protocol to facilitate and standardize the distribution of content, especially related to container images and associated artifacts.
-
-### Historical Context
-
-The spec is based on the specification for the [Docker Registry HTTP API V2 protocol](https://github.com/docker/distribution/blob/5cb406d511b7b9163bff9b6439072e4892e5ae3b/docs/spec/api.md).
-
-For relevant details and a history leading up to this specification, please see the following issues:
-
-- [moby/moby#8093](https://github.com/moby/moby/issues/8093)
-- [moby/moby#9015](https://github.com/moby/moby/issues/9015)
-- [docker/docker-registry#612](https://github.com/docker/docker-registry/issues/612)
-
-## Definitions
-
-### Common Terms
-
-Several terms are used frequently in this document and warrant basic definitions:
-
-- **Registry**: a HTTP service which implements this spec
-- **Client**: a tool that communicates with registries over HTTP
-- **Push**: the act of uploading content to a registry
-- **Pull**: the act of downloading content from a registry
-- **Artifact**: a single piece of content, made up of a manifest and one or more layers
-- **Manifest**: a JSON document which defines an artifact
-- **Layer**: a single part of all the parts which comprise an artifact
-- **Config**: a special layer defined at the top of a manifest containing artifact metadata
-- **Blob**: a single binary content stored in a registry
-- **Digest**: a unique blob identifier
-- **Content**: a general term for content that can be downloaded from a registry (manifest or blob)
-
-### Document Language
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997).
-
-## Conformance
-
-### Minimum Requirements
-
-For a registry to be considered fully conformant against this specification, it must implement the HTTP endpoints required by each of the four (4) major workflow categories:
-
-1. **Pull** (REQUIRED) - Ability to fetch content from a registry
-2. **Push** - Ability to publish content to a registry
-3. **Content Discovery** - Ability to list or otherwise query the content stored in a registry
-4. **Content Management** - Ability to delete (or otherwise manipulate) content stored in a registry
-
-At a bare minimum, registries claiming to be "OCI-Compliant" MUST support all facets of the pull workflow.
-
-In order to test a registry's conformance against these workflows, please use the [conformance testing tool](./conformance/).
-
-### Official Certification
-
-Registry providers can self-cetify by submitting conformance results to [opencontainers/oci-conformance](https://github.com/opencontainers/oci-conformance).
-
-### Workflow Categories
-
-#### Pull
-
-TODO: describe the Pull category and the high-level details
-
-#### Push
-
-TODO: describe the Push category and the high-level details
-
-#### Content Discovery
-
-TODO: describe the Content Discovery category and the high-level details
-
-#### Content Management
-
-TODO: describe the Content Management category and the high-level details
-
-## HTTP API
-
-### Endpoints
-
-TODO: table of API endpoints
-
-### Error Codes
-
-TODO: table of error codes
-
--->