idnits 2.17.1 draft-dorfner-core-simplemetadata-00.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 16, 2018) is 2202 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 110, but not defined == Unused Reference: 'Internet-Draft' is defined on line 236, 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 (~~), 5 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: October 18, 2018 April 16, 2018 6 SimpleMetadata: An interoperable format for sharing metadata 7 draft-dorfner-core-simplemetadata-00 9 Abstract 11 This document describes a container format for storing serializable 12 metadata. It shall provide the possibility to store and share any 13 kind of metadata, including encryption support. The idea is to create 14 an open, universal and interoperable standard for storing and 15 distributing every kind of metadata independent from media type or 16 file format. 18 Status of This Memo 20 This is an Internet Standards Track document. 22 This document is a product of the Internet Engineering Task Force 23 (IETF). It represents the consensus of the IETF community. It has 24 received public review and has been approved for publication by the 25 Internet Engineering Steering Group (IESG). Further information on 26 Internet Standards is available in Section 2 of RFC 7841. 28 Information about the current status of this document, any errata, 29 and how to provide feedback on it may be obtained at https://www.rfc- 30 editor.org/info/rfc8335. 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 Copyright and License Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1 Header Definition . . . . . . . . . . . . . . . . . . . . . 4 72 2.2 Identifier . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.3 Serialization . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.4 Crypto . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.5 Major Version . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.6 Minor Version . . . . . . . . . . . . . . . . . . . . . . . 5 77 2.6 Schema URI length . . . . . . . . . . . . . . . . . . . . . 5 78 2.5 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 metadata payload shall be created, stored and shared with an open 98 standard, like JavaScript Object Notation (JSON) [RFC7159] in 99 combination with schema validation . Every data structure of metadata can be 101 defined and distributed within schema definitions. Furthermore, 102 SimpleMetadata can be extended by additional formatters or crypto 103 standards. 105 1.1 Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Structure 113 The SimpleMetadata format consists of the three parts, Header, Schema 114 URI and Metadata payload. 115 +-------------------------------------------------------------------+ 116 | Header (14 bytes) (fixed length) | 117 +-------------------------------------------------------------------+ 118 | Schema URI (variable length, optional) | 119 +-------------------------------------------------------------------+ 120 | Serialized Metadata (variable length) | 121 +-------------------------------------------------------------------+ 123 2.1 Header Definition 125 The header must be stored at the beginning of a file. 126 +----------------------------------------------------------------+ 127 | Identifier "SMD@" 4 Bytes / string | 128 +----------------------------------------------------------------+ 129 | Serialization 1 Byte / number | 130 +----------------------------------------------------------------+ 131 | Crypto 1 Byte / number | 132 +----------------------------------------------------------------+ 133 | Major version 1 Byte / number | 134 +----------------------------------------------------------------+ 135 | Minor version 1 Byte / number | 136 +----------------------------------------------------------------+ 137 | Schema URI Length 2 Bytes / number | 138 +----------------------------------------------------------------+ 139 | Content Length 4 Bytes / number | 140 +----------------------------------------------------------------+ 142 2.2 Identifier 144 The first four bytes of the header are always "SMD@" to check if 145 SimpleMetadata is present. 147 2.3 Serialization 149 Defines the used formatter for the metadata. A formatter serializes 150 or deserializes the metadata with the corresponding procedure. The 151 standard formatter uses Binary JSON (BSON) 152 with the JavaScript Object Notation (JSON) [RFC7159]. 154 0 = BSON 156 2.4 Crypto 158 Defines the used crypto standard for en/decrypting metadata. 160 0 = None encryption 161 1 = Advanced Encryption Standard (AES) 163 2.5 Major Version 165 Defines the used major version of the SimpleMetadata format. 166 1 = Current major version 168 2.6 Minor Version 170 Defines the used minor version of the SimpleMetadata format. 171 0 = Current minor version 173 2.6 Schema URI length 175 Defines the string length of a schema or type. If no schema is 176 defined the schema length is 0. The schema information is described 177 in chapter 3. 179 2.5 Content Length 181 Defines the length of the serialized metadata, based on the selected 182 formatter (Chapter 2.3). If the content is encrypted, the length is 183 calculated over the encrypted string. 185 3 Schema information 187 The schema information can be used to validate the metadata against a 188 schema or type. A schema information is an optional string with 189 variable length encoded with UTF-8. It is recommended to use an URI , 190 e.g. "http://exampleschemas.org/Person". Moreover a local file path 191 or even a type definition (AssemblyQualifiedName) can be used. For 192 interoperability, metadata should be based on public schema. 194 The length of the schema is stored in the header (See chapter 2.6). 196 4 Metadata Content 198 Basically every serializable content can be stored as metadata. It is 199 highly recommended to use for interoperability and compatibility the 200 JavaScript Object Notation (JSON) [RFC7159] for metadata and the 201 according schema definition. 203 5 Notes 205 Adding SimpleMetadata to a file will damage it under circumstances, 206 unless there is a suitable parser to handle the format! 208 6 Security Considerations 210 Sensitive metadata can be encrypted within a supported crypto 211 standard (Chapter 2.4). 213 7 IANA Considerations 215 All data must be stored in UTF-8 [RFC2044]. 217 8 References 219 8.1 Informative References 221 [RFC7159] Bray , Tim 222 The JavaScript Object Notation (JSON) Data 223 Interchange Format, March 2014, 224 . 226 [RFC5013] Kunze J., Baker T. 227 The Dublin Core Metadata Element Set, 228 August 2007 229 231 [RFC2044] Francois, Yergeau 232 UTF-8, a transformation format of Unicode 233 and ISO 10646, October 1996 234 . 236 [Internet-Draft] Wright, A. 237 JSON Schema: A Media Type for Describing 238 JSON Documents, November 19, 2017 239 242 Authors' Addresses 244 Ralf Dorfner 245 Muensterplatz 8 246 88250 Weingarten 247 Germany 249 EMail: smd@simplemetadata.org