Ignore unknown metadata fields

[Ekleog]

For forwards-compatibility reasons, request that programs ignore unknown metadata fields. The alternative is for old programs to completely ignore new reviews… that's possible too, I don't have any strong opinions. Will make things harder for #6, though.

[oxij]

By default, I vote for ignoring and producing warning for reviews with unknown fields, see e.g. `result-otherwise` field semantics. However, we can add some mechanism that could say either "you MAY ignore _this field_ if you don't know what it means" (kinda like "X-" fields of RFC822) and "you MUST ignore _this review_ if you don't know what this field means". E.g. ``` Unknown fields with names starting with `x-` MAY be ignored, other unknown fields SHOULD cause a warning and MUST cause the review to be ignored. ``` ?

[Ekleog]

Good catch about the x- identifier, thanks! I've pushed a new version, in addition this wording should solve #6.

[Ekleog]

@oxij Ping review :)

[oxij]

I would remove " or processed in an implementation-dependent way". It is IMHO obvious that you can process them with "MAY ignore" without that phrase, but the whole sentence gets confusing with "MAY ignore or ". I feel like it needs parentheses there

Unknown metadata fields with names starting with x- MAY be {ignored or processed in an implementation-dependent way}, while other unknown metadata fields SHOULD trigger a warning and MUST cause the review to be ignored.

to show what that "or" binds. Which would be possible to express if this was written in lojban, but not in English.

[Ekleog]

Hmm, I fear that without the “or”, it could be interpreted as “MAY either be ignored or MUST cause the review to be ignored”. I've pushed a rewording with either/or balancing to make the parenthesis clear, hopefully in plain english too :)

[oxij]

See #4 (comment).

[oxij]

Current phrasing LGTM, btw.

[Ekleog]

IMO x- headers avoid the need for standardizing content-type: tools could just set x-git-appraise yes. This would help making the spec as minimal as possible, while staying open to extension.

[Ekleog]

This is blocked on #4

[Ekleog]

Closing as the git-wotr idea is pretty much dead and I'd like to clean up my "open PR" list so it only has actionable stuff