Add rights-transparency discovery members#3
Merged
Conversation
An independent ORSP-compatible reader (Open Reading) already ships operatorName, contactUrl, contentLicense, and rightsStatement as optional discovery-document fields, letting a source identify its operator and content authorization basis for client-side transparency display. They were never upstreamed here, so this spec has no normative definition for fields a real implementation already relies on. This adds them as optional discovery members (purely additive, no existing field or endpoint behavior changes), documents them in both SPECIFICATION.md and SPECIFICATION.zh-CN.md, types them in schemas/discovery.schema.json, and has the reference server declare them with conformance checks covering their presence and shape. Left protocolVersion / spec version headers untouched — bumping those is a release decision for maintainers, not something this PR assumes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
operatorName,contactUrl,contentLicense, andrightsStatementas optional discovery-document members (SPECIFICATION.md §3, mirrored in SPECIFICATION.zh-CN.md).schemas/discovery.schema.json.examples/dart_server.dart) now declares all four;tool/conformance_test.dartasserts they're present with the right shape.protocolVersion/spec version is left to maintainers per GOVERNANCE.md's release process.Why
An independent ORSP-compatible reader (Open Reading, github.com/miloquinn/open-reading) already ships these four fields and has for a while, using them purely for client-side transparency display (who operates a source, how to reach them, what license/authorization basis the content is served under). They were never upstreamed, so this spec currently has no normative definition for fields a real-world implementation depends on — anyone else implementing ORSP has no spec to read for this.
Compatibility
Security / privacy / accessibility / copyright
contactUrlis constrained to absolute HTTP(S), consistent withiconUrl/websiteUrl.Test plan
dart format --output=none --set-exit-if-changed examples/dart_server.dart tool/conformance_test.dartdart analyze examples/dart_server.dart tool/conformance_test.dart— no issuesdart run tool/conformance_test.dart— 67 checks passedpython scripts/validate_contracts.py/registry_tool.py— could not run locally, no Python interpreter available in this environment. Only touchedschemas/discovery.schema.jsonwith straightforward additive JSON Schema draft 2020-12 properties, but please let CI confirm.🤖 Generated with Claude Code