From a822379476139376ebdbff23afedbfe5b687b155 Mon Sep 17 00:00:00 2001 From: John-Mark Gurney Date: Mon, 26 Jul 2021 14:52:33 -0700 Subject: [PATCH] various cleanups and clarifications... --- README.md | 54 +++++++++++++++++++++++++++++++++++------------------- 1 file changed, 35 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index 088fbd9..008faa9 100644 --- a/README.md +++ b/README.md @@ -4,12 +4,14 @@ The idea for medashare is both a standard, but also an implementation of defining and sharing meta data about files. Some media contains the ability to embed meta data, e.g. mp3, some documents, video files, but not all files are able to convey the complete and rich information that -may be desired. This will allow you to identify files, and have -external associated meta data with various files. - -The idea is also to be able to classify parts of the meta data as -private (aka TLP:Red), such that the information will not be shared, so -that you can mark files w/ your own tags and/or ratings, which will not +may be desired. Even if the file format has embedded data, it may not +be modifiable, or even be desirable to modify the file to include the +metadata. This will allow you to identify files, and have external +associated meta data with various files. + +It should be possible to classify parts of the meta data as private +(aka TLP:Red), such that the information will not be shared, so that +a person can mark files w/ your own tags and/or ratings, which will not be automatically shared. There will also be able to define derivative works by the standard. @@ -29,7 +31,7 @@ associate general picture information w/ the raw image data (but none of the associated processing data that files like CR2 contains) so that the meta data is not lost. -This work is inspired by my work on STIX, a Cyber Threat Intelligence +This work is inspired by my work on [STIX], a Cyber Threat Intelligence standard, that has many similar requirements as meta data sharing. ## Goals / Use Cases @@ -74,6 +76,16 @@ standard, that has many similar requirements as meta data sharing. Each object has a URN which uniquely describes it. XXX copy from STIX URN proposal, which is simlar to the magnet proposal. +Something similar to: +``` +urn:medashare:uuid[--modifieddate] +``` + +And the URI version: +``` +medashare:?xt= +``` + ## Types Everything must have a type. Not having well defined types can lead to @@ -139,9 +151,10 @@ parent_refs List of UUIDv4s of MetaData Object that overlay. Any passed through to the parent for resolution. The first/earliest object that has a property is used in that objects later in the list are "hidden" by the - earlier objects. + earlier objects. The modified date must be included + in this property. mimetype The mime-type. If the set of bytes is polymorphic, - there should be one for each "type". + there should be an object for each "type". uri List of URI's where the file may be located. child_files A dictionary where the keys are the file names and the values are hash strings. (One issue w/ using hashes is @@ -160,25 +173,27 @@ specification, as it provides a nice starting point, and will provide a good mapping to other systems out there. There may be a link to another MetaData object from which this one is -derived. If there is, all the meta data from the derived object (and -the ones it derives from) must be included, except for the ones that -have been marked deleted, or were overridden. When a property is -marked as opinion, it should not be inherited. If the new author -agrees with the opinion, then they have to restate the opinion in their -object. +derived (via parent_refs). If there is, all the meta data from the +derived object (and the ones it derives from) must be included, except +for the ones that have been marked deleted, or were overridden. When +a property is marked as opinion, it should not be inherited. If the +new author agrees with the opinion, then they have to restate the +opinion in their object. Custom properties must be preceded w/ a namespace. The name space is name followed by colon, as is demonstrated above w/ dc for [Dublin -Core]. +Core]. For existing standards, please submit them for inclusion, +otherwise a reverse dns name should be used, e.g. +com.funkthat:property. The link to the meta data object must include the version referenced, as the referenced object may change. A three way merge may be needed when updating an object where the derived object has also been updated if the new information is wished to be used. -If a property is imported from the blog itself, it is recommended to -mark it as such via the granular marking, see X for more info on how to -do this. +If a property is imported from the file/object itself, it is +recommended to mark it as such via the granular marking, see X for more +info on how to do this. Open Questions: When meta data is "declassified", how do you maintain a link to the classified version? @@ -266,6 +281,7 @@ local only (unless on a shared, e.g. work, system). The [Dublin Core] standard is also noted by [RFC5013]. +[STIX] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti [Dublin Core]: http://dublincore.org/documents/dces/ [RFC5013]: https://tools.ietf.org/html/rfc5013 [STIX v2.0 Part 1]: http://docs.oasis-open.org/cti/stix/v2.0/cs01/part1-stix-core/stix-v2.0-cs01-part1-stix-core.html