[SPEC] Backwards-compatible metadata in Gemini
oliversimmo at gmail.com
Tue Feb 23 15:31:56 GMT 2021
On Tue, 23 Feb 2021 at 09:16, Lars Noodén <lars.nooden at gmx.com> wrote:
> Some of this depends on what kind of metadata we are talking about.
> Gemini is about transmission of information and
> metadata is information. By document metadata I mean information
> /about/ the document content.
Only data about the document should be allowed, and it should not
modify the document (i.e. no stylistic info).
> which could look like this in the body, but would be up to the client as
> to how it is dealt with. Left unprocessed, it would degrade gracefully
> and be quite readable.
This syntax would allow for it to be placed anywhere in the document,
which could enable it to be used to extend Gemini in unwanted ways,
=: text-colour red
=: text-colour blue
I'm red >:)
(this is a lame example, there are probably worse things it could do)
Placing it at the end of the file, which my format would enforce,
makes this impossible.
If it did change the file (which wouldn't be allowed) it would have to
be the entire file, making this harder.
Also, using space as the delimiter causes some issues, for example:
=: author Oliver Simmons
A simple client might try to split on the spaces, which would split
the name into two, using a colon or equals is more conventional for
key/value things, and avoid this problem (wanting to use : or = in a
key or value isn't likely).
> Again, by being included anywhere inside the body, there would be no
> extra network calls.
Just pointing out that none of the three proposed formats do this,
extension of the protocol is entirely out of the question.
This is NOT like HTTP headers, it is strictly document metadata.
> There should be no requirement as to what is in the metadata, which
> terms are allowed, or what the terms mean. Any extension should say
> only how terms may be included and leave the rest up to the capsule and
> the client software.
More information about the Gemini