CIP-0017 | Adjust preamble and structure w.r.t CIP-0001 (cardano-foundation#662)

* first draft remediation of CIP-0017

* Update CIP-0017/README.md

* set status Inactive by author decision

Co-authored-by: Matthias Benkort <[email protected]>

---------

Co-authored-by: Matthias Benkort <[email protected]>

Author: rphair

CIP-0017/README.md

@@ -1,24 +1,26 @@
 ---
 CIP: 17
 Title: Cardano Delegation Portfolio
-Authors: Matthias Benkort <[email protected]>
-Comments-Summary: A Common format for sharing Cardano delegation portfolios
-Comments-URI: https://github.com/cardano-foundation/CIPs/wiki/Comments:CIP-0017
-Status: Active
-Type: Standards
+Status: Inactive (abandoned for lack of interest)
+Category: Tools
+Authors:
+  - Matthias Benkort <[email protected]>
+Implementors: []
+Discussions:
+  - https://github.com/cardano-foundation/CIPs/pull/82
 Created: 2020-04-02
 License: CC-BY-4.0
 ---
 
-# Abstract
+## Abstract
 
 This document details a common format for sharing Cardano delegation portfolio across various tools and wallets. 
 
-# Motivation
+## Motivation: why is this CIP necessary?
 
 Stakeholders have indicated the desire to split their stake in various sizes and delegate to n pools from a single wallet/mnemonic. Albeit there are no monetary incentive for users to do this, the desire to drive decentralisation is sufficiently prevalent to justify it. Furthermore, stakeholders want to introduce a certain social element to this activity by sharing their delegation portfolio with other stakeholders. This specification should help to standardize the representation of portfolios across tools for more interoperability. 
 
-# Specification
+## Specification
 
 ### Overview
 
@@ -32,29 +34,7 @@ For each pool, we demand a `weight` which can capture a certain stake proportion
 
 Portfolios which treat all stake pools equally should use the same weight (e.g. `1`) for each pool. 
 
-# Rationale
-
-1. JSON is widely used, widely supported and quite lightweight. Makes for a reasonable choice of data format.
-
-2. Using JSON schema for validation is quite common when dealing with JSON and it's usually sufficiently precise to enable good interoperability. 
-
-3. The portfolio should only capture information that are not subject to radical change. That is, stake pools parameters like pledge or fees are excluded since they can be changed fairly easily using on-chain certificate updates. 
-
-4. The JSON schema doesn't enforce any `additionalProperties: false` for neither the top-level object definition nor each stake pool objects. This allows for open extension of the objects with custom fields at the discretion of applications implementing this standard. The semantic of well-known properties specified in this document is however fixed.
-
-5. Since the portfolio format isn't _immediately user-facing_, we favor base16 over bech32 for the pool id's encoding for there's better support and tooling for the former.
-
-# Backwards Compatibility
-
-## Adafolio (https://adafolio.com)
-
-The format used by Adafolio share a lot of similarities with the proposed format in this CIP. In order to power its frontend user interface, Adafolio contains however several fields which we consider _too volatile_ and unnecessary to the definition of a portfolio. This doesn't preclude the format used by Adafolio as a valid portfolio format (see also point (4). in the rationale above).
-
-The only point of incompatibility regards the `pool_id` field (in Adafolio) vs the `id` field (in this proposal) which we deem more consistent with regards to other field. 
-
-# Reference Implementation(s)
-
-##  Examples
+### Example
 
 ```json
 { "name": "Metal 🤘"
@@ -81,6 +61,38 @@ The only point of incompatibility regards the `pool_id` field (in Adafolio) vs t
 }
 ```
 
+## Rationale: how does this CIP achieve its goals?
+
+1. JSON is widely used, widely supported and quite lightweight. Makes for a reasonable choice of data format.
+
+2. Using JSON schema for validation is quite common when dealing with JSON and it's usually sufficiently precise to enable good interoperability. 
+
+3. The portfolio should only capture information that are not subject to radical change. That is, stake pools parameters like pledge or fees are excluded since they can be changed fairly easily using on-chain certificate updates. 
+
+4. The JSON schema doesn't enforce any `additionalProperties: false` for neither the top-level object definition nor each stake pool objects. This allows for open extension of the objects with custom fields at the discretion of applications implementing this standard. The semantic of well-known properties specified in this document is however fixed.
+
+5. Since the portfolio format isn't _immediately user-facing_, we favor base16 over bech32 for the pool id's encoding for there's better support and tooling for the former.
+
+### Backwards Compatibility
+
+#### Adafolio
+
+The format used by [Adafolio](https://adafolio.com) share a lot of similarities with the proposed format in this CIP. In order to power its frontend user interface, Adafolio contains however several fields which we consider _too volatile_ and unnecessary to the definition of a portfolio. This doesn't preclude the format used by Adafolio as a valid portfolio format (see also point (4). in the rationale above).
+
+The only point of incompatibility regards the `pool_id` field (in Adafolio) vs the `id` field (in this proposal) which we deem more consistent with regards to other field. 
+
+## Path to Active
+
+### Acceptance Criteria
+
+- [ ] At least one pair of applications (wallets, explorers or other tools) together support the following:
+  - [ ] generation of the specified portfolio file format
+  - [ ] interpretation and use of the specified portfolio file format
+
+### Implementation Plan
+
+- [ ] Provide a reference implementation and/or parsing library to read and/or write files in this schema.
+
 # Copyright
 
-CC-BY-4.0
+This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).