idnits 2.17.1 draft-dorfner-core-simplemetadata-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 147 has weird spacing: '...he used versi...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 24, 2019) is 1832 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 111, but not defined == Unused Reference: 'Internet-Draft' is defined on line 228, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 2044 (Obsoleted by RFC 2279) == Outdated reference: A later version (-02) exists of draft-handrews-json-schema-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Ralf Dorfner 3 Intended Status: Proposed Standard 4 Expires: September 25, 2019 March 24, 2019 6 SimpleMetadata: An interoperable format for sharing metadata 7 draft-dorfner-core-simplemetadata-01 9 Abstract 11 This document describes a standardized container format for storing 12 serializable metadata. It does not describe any additional new 13 format, but provides a shell for the exchange of arbitrary, 14 structured data. It shall provide the possibility to store and share 15 any kind of metadata, including encryption support. The idea is to 16 create an open, universal and interoperable standard for storing and 17 distributing every kind of metadata independent from media type or 18 file format. 20 Status of This Memo 22 This is an Internet Standards Track document. 24 This document is a product of the Internet Engineering Task Force 25 (IETF). It represents the consensus of the IETF community. It has 26 received public review and has been approved for publication by the 27 Internet Engineering Steering Group (IESG). Further information on 28 Internet Standards is available in Section 2 of RFC 7841. 30 Information about the current status of this document, any errata, 31 and how to provide feedback on it may be obtained at https://www.rfc- 32 editor.org/info/rfc8335. 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2019 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (https://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1 Header Definition . . . . . . . . . . . . . . . . . . . . . 4 73 2.2 Identifier . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.3 Version . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.4 Serialization . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.5 Crypto . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2.6 Schema URI length . . . . . . . . . . . . . . . . . . . . . 5 78 2.6 Content Length . . . . . . . . . . . . . . . . . . . . . . . 5 79 3 Schema information . . . . . . . . . . . . . . . . . . . . . . 5 80 4 Metadata Content . . . . . . . . . . . . . . . . . . . . . . . . 5 81 5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 83 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 84 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 8.1 Informative References . . . . . . . . . . . . . . . . . . 6 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 88 1 Introduction 90 Nowadays a variety of media file are shared and published all over 91 the world. Information about the origin, purpose or copyright of 92 these files getting more and more important. There are already 93 different standards which enhance files with metadata, like ID3 94 , Exif or Dublin Core 95 [RFC5013]. SimpleMetadata shall create the foundation to unite these 96 standards and provide an universal and open container format. The 97 idea is not to describe any additional new format, but provides a 98 shell for the exchange of arbitrary, structured data. Any metadata 99 payload shall be created, stored and shared with an open standard, 100 like JavaScript Object Notation (JSON) [RFC7159] in combination with 101 schema validation . Every data structure of metadata can be defined and 103 distributed within schema definitions. Furthermore, SimpleMetadata 104 can be extended by additional formatters or crypto standards. 106 1.1 Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Structure 114 The SimpleMetadata format consists of the three parts, Header, Schema 115 URI and Metadata payload. 116 +-------------------------------------------------------------------+ 117 | Header (12 bytes) (fixed length) | 118 +-------------------------------------------------------------------+ 119 | Schema URI (variable length, optional) | 120 +-------------------------------------------------------------------+ 121 | Serialized Metadata (variable length) | 122 +-------------------------------------------------------------------+ 124 2.1 Header Definition 126 +----------------------------------------------------------------+ 127 | Identifier "SMD" 3 Bytes / string | 128 +----------------------------------------------------------------+ 129 | Version 1 Byte / number | 130 +----------------------------------------------------------------+ 131 | Serialization 1 Byte / number | 132 +----------------------------------------------------------------+ 133 | Crypto 1 Byte / number | 134 +----------------------------------------------------------------+ 135 | Schema URI Length 2 Bytes / number | 136 +----------------------------------------------------------------+ 137 | Content Length 4 Bytes / number | 138 +----------------------------------------------------------------+ 140 2.2 Identifier 142 The first three bytes of the header are always "SMD" to check if 143 SimpleMetadata is present. 145 2.3 Version 147 Defines the used version of the SimpleMetadata format. 148 1 = Current version 150 2.4 Serialization 152 Defines the used formatter for the metadata. A formatter serializes 153 or deserializes the metadata with the corresponding procedure. The 154 standard formatter uses Binary JSON (BSON) 155 with the JavaScript Object Notation (JSON) [RFC7159]. 157 0 = BSON 159 2.5 Crypto 160 Defines the used crypto standard for en/decrypting metadata. 162 0 = None encryption 163 1 = Advanced Encryption Standard (AES) 165 2.6 Schema URI length 167 Defines the string length of a schema or type. If no schema is 168 defined the schema length is 0. The schema information is described 169 in chapter 3. 171 2.6 Content Length 173 Defines the length of the serialized metadata, based on the selected 174 formatter (Chapter 2.3). If the content is encrypted, the length is 175 calculated over the encrypted string. 177 3 Schema information 179 The schema information can be used to validate the metadata against a 180 schema or type. A schema information is an optional string with 181 variable length encoded with UTF-8. It is recommended to use an URI , 182 e.g. "http://exampleschemas.org/Person". Moreover a local file path 183 or even a type definition (AssemblyQualifiedName) can be used. For 184 interoperability, metadata should be based on public schema. 186 The length of the schema is stored in the header (See chapter 2.6). 188 4 Metadata Content 190 Basically every serializable content can be stored as metadata. It is 191 highly recommended to use for interoperability and compatibility the 192 JavaScript Object Notation (JSON) [RFC7159] for metadata and the 193 according schema definition. 195 5 Notes 197 Adding SimpleMetadata to a file will damage it under circumstances, 198 unless there is a suitable parser to handle the format! 200 6 Security Considerations 202 Sensitive metadata can be encrypted within a supported crypto 203 standard (Chapter 2.4). 205 7 IANA Considerations 207 All data must be stored in UTF-8 [RFC2044]. 209 8 References 211 8.1 Informative References 213 [RFC7159] Bray , Tim 214 The JavaScript Object Notation (JSON) Data 215 Interchange Format, March 2014, 216 . 218 [RFC5013] Kunze J., Baker T. 219 The Dublin Core Metadata Element Set, 220 August 2007 221 223 [RFC2044] Francois, Yergeau 224 UTF-8, a transformation format of Unicode 225 and ISO 10646, October 1996 226 . 228 [Internet-Draft] Wright, A. 229 JSON Schema: A Media Type for Describing 230 JSON Documents, November 19, 2017 231 234 Authors' Addresses 236 Ralf Dorfner 237 Muensterplatz 8 238 88250 Weingarten 239 Germany 241 EMail: smd@simplemetadata.org