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