Tweak RFC in response to PR comments

docs/rfcs/016-asset-metadata.md

@@ -20,7 +20,7 @@ This RFC suggests at an alternative approach to storing the thumbnail sizes for
 
 The proposal is to store the generated thumbnail sizes in the database, in a separate table from `Images`. Proposed name for this table is `AssetApplicationMetadata` - a table designed to store metadata about an Asset for internal use by the application only; the values would never be expose via API.
 
-This table will initially store the available thumbnail sizes, replicating/duplicating what is stored in `s.json`, but can easily be read as part of a database query. These can be read in bulk alongside the corresponding `Asset` record.
+This table will initially store the available thumbnail sizes, duplicating what is stored in `s.json`, but can easily be read as part of a database query. These can be read in bulk alongside the corresponding `Asset` record. We should continue to write `s.json` to S3 as it allows thumb-serving to remain self-contained, without a need to read database to handle requests.
 
 The handling of a NamedQuery is fairly complex to allow for query building reuse. Currently reading metadata is only required for manifest projection so we will need to add a hook in the processing to add the required `.Include()` where appropriate.
 
@@ -84,12 +84,4 @@ Objects could be included where required via filtered include statement to filte
 var assetWithThumbs = dbContext.Images
                 .Include(i => i.AssetApplicationMetadata.Where(m => m.MetadataType == "ThumbSizes"))
                 .Single(i => i.Id == assetId);
-```
-
-## Outstanding Questions
-
-* For `Asset` object - would we use polymorphic deserialisation? How complex would that be? Would storing on object as a `string` be okay, deserialisation as required (rather than on way out of DB)
-* Should we store sizes in s3 as well as db?
-  * I think this could still be useful,  at least in short term it would mean less code changes.
-* If we store sizes in s3 and DB, where would Orchestrator read from? Orchestrator uses Dapper - would that cause issues?
-* Would we want `on delete cascade` for `AssetApplicationMetadata`? If we store all possible derivative keys in this the `CleanupHandler` could use that to do more targeted cleanup and invalidation, rather than always using prefixes.
+```