added version 2 and cddl

CIP-0025/README.md

@@ -38,7 +38,7 @@ This is the registered `transaction_metadatum_label` value
 | --------------------------- | ------------ |
 | 721                         | NFT Metadata |
 
-### Structure
+### General structure
 
 The structure allows for multiple token mints, also with different policies, in a single transaction.
 
@@ -50,7 +50,7 @@ The structure allows for multiple token mints, also with different policies, in
         "name": <string>,
 
         "image": <uri | array>,
-        "mediaType": "image/<mime_sub_type>",
+        "mediaType": image/<mime_sub_type>,
 
         "description": <string | array>,
 
@@ -64,27 +64,89 @@ The structure allows for multiple token mints, also with different policies, in
         <other properties>
       }
     },
-    "version": "1.0"
+    "version": <version_id>
   }
 }
 ```
 
-The **`asset_name`** must be `UTF-8` encoded for the key in the metadata map and the actual NFT. This is true for version `1.0`, future versions will use the `hex` encoding for **`asset_name`**.
+### CDDL
+
+#### Version 1
+
+```cddl
+
+policy_id = text
+asset_name = text ; utf-8
+
+files_details = 
+  {
+    name: text,
+    mediaType: text,
+    src: text / [* text]
+  }
+
+metadata_details = 
+  {
+    name : text,
+    image : text, 
+    ? mediaType: text,
+    ? description: text / [* text]
+    ? files: [* files_details]
+  }
+
+label_metadata = { * policy_id => { * asset_name => metadata_details } }
+
+metadata = { 721 : uint => label_metadata }
+```
+
+#### Version 2
+
+```cddl
+
+policy_id = bytes ; no longer in text
+asset_name = bytes ; no longer in text and utf-8
+
+files_details = 
+  {
+    name : text,
+    mediaType : text,
+    src : text / [* text]
+  }
+
+metadata_details = 
+  {
+    name : text,
+    image : text, 
+    ? mediaType : text,
+    ? description : text / [* text]
+    ? files : [* files_details]
+  }
+
+label_metadata = { * policy_id => { * asset_name => metadata_details }, version: 2 } ; version 2
+
+metadata = { 721 : uint => label_metadata }
+```
+
+In version `1` the **`asset_name`** must be `utf-8` encoded and in text format for the key in the metadata map. In version `2` the the raw bytes of the **`asset_name`** are used.
+In version `1` the **`policy_id`** is used in text format for the key in the metadata map. In version `2` the the raw bytes of the **`policy_id`** are used.
+
 
 The **`image`** and **`name`** property are marked as required. **`image`** should be an URI pointing to a resource with mime type `image/*` used as thumbnail or as actual link if the NFT is an image (ideally <= 1MB).
 
 The **`description`** property is optional.
 
 The **`mediaType`** and **`files`** properties are optional.<br /> **`mediaType`** is however required inside **`files`**. The **`src`** property inside **`files`** is an URI pointing to a resource of this mime type. If the mime type is `image/*`, **`mediaType`** points to the same image, like the on in the **`image`** property, but in an higher resolution.
 
-The **`version`** property is also optional. If not specified the version is `1.0`. It will become mandatory in future versions if needed.
+The **`version`** property is also optional. If not specified the version is `1`. It will become mandatory in future versions if needed.
 
 This structure really just defines the basis. New properties and standards can be defined later on for varies uses cases. That's why there is an "other properties" tag.
 
 The retrieval of the metadata should be the same for all however.
 
 Optional fields allow to save space in the blockchain. Consequently the minimal structure for a single token is:
 
+#### Version 1
+
 ```
 {
   "721": {
@@ -98,6 +160,22 @@ Optional fields allow to save space in the blockchain. Consequently the minimal
 }
 ```
 
+#### Version 2
+
+```
+{
+  "721": {
+    "<policy_id>": {
+      "<asset_name>": {
+        "name": <string>,
+        "image": <uri | array>
+      }
+    },
+    "version": 2
+  }
+}
+```
+
 ### Retrieve valid metadata for a specific token
 
 As mentioned above this metadata structure allows to have either one token or multiple tokens with also different policies in a single mint transaction. A third party tool can then fetch the token metadata seamlessly. It doesn't matter if the metadata includes just one token or multiple. The proceedure for the third party is always the same:
@@ -114,8 +192,8 @@ Using the latest mint transaction with the label 721 as valid metadata for a tok
 
 ## Backward Compatibility
 
-To keep NFT metadata compatible with changes coming up in the future, we use the **`version`** property. Version `1.0` is used in the current metadata structure of this CIP.
-Version `2.0` will introduce [schema.org](https://schema.org).
+To keep NFT metadata compatible with changes coming up in the future, we use the **`version`** property.
+A future version will introduce [schema.org](https://schema.org).
 
 ## References