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