Server Description
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 563
- Forks
- 108
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 3
Description
Background: there are a wide-range of use cases that needs to get a hold of authoritative information about the server. To date, there is no uniform way for agents and applications to find all information about a server.
General use case:
Find authoritative information about a server.
Use cases:
- Guinan wants to read the description of the server and understand its purpose.
- Janeway wants to find the server's policies to review its data privacy and pledge for resource persistence.
- Uhura wants to check the server's communication options in order to use a preferred notification protocol.
- Seven of Nine wants to determine a suitable location to keep astrometric data from the server's available storages.
- Picard wants to find the server's contact information to request a diplomatic meeting about security audits.
- Torres wants her devices to use server's URI templates when naming particular kinds of resources.
There are many others.. which may be low-priority or already have existing standards, but could be captured in this data nevertheless, e.g., sitemap, Web syndication, robots control.
General requirement:
Discovery mechanism and data model to express authoritative information about the server.
Specific requirement:
- Server advertises the location of the authoritative information.
- Server generates the authoritative information.
- Server controls the authoritative information.
Considerations:
- Accommodating various use cases that needs to get a hold of authoritative information about the server.
- Should the authoritative information about the server be publicly discoverable?
- Should the authoritative information about the server be publicly readable or access controlled?
- Can specific class of agents (e.g., owners) claim/update authoritative information about the server?
- Should the authoritative information about the server be discoverable from root path, storage, any resource, and/or somewhere else?
- Caching.
Related issues (sample):
- https://github.com/solid/specification/issues/61
- https://github.com/solid/specification/issues/65
- https://github.com/solid/specification/issues/66
- https://github.com/solid/specification/issues/151#issuecomment-596192613
- https://github.com/solid/specification/issues/152
- https://github.com/solid/specification/issues/180
- https://github.com/solid/specification/issues/206
- https://github.com/solid/specification/issues/222
- https://github.com/solid/specification/issues/227
- https://github.com/solid/specification/issues/266
- https://github.com/solid/specification/issues/286
- https://github.com/solid/specification/issues/310
- https://github.com/solid/notifications/issues/14
Notes:
The authoritative information about the server would be a specialisation of #authoritative-information in https://github.com/solid/specification/pull/352 .
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the authoritative-information proposal in specification#352 and the related issues listed in this issue. Define the discovery mechanism and data model for server descriptions, including how servers advertise, generate, and control the information. Done means the open questions and use cases have an agreed, implementable specification.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100