Specify resource naming constraints unambiguously

Currently, there is no section unambiguously defining naming constraints for solid resources. Few can be inferred, and others have ambiguity. It would be great if that little ambiguity is resolved.

1. Solid resources are http resources, and de-referencable information resources. Hence their names must be Http URIs. (Thus no IRIS allowed, as http allows only uris for resource names at protocol level, also this issue), And #fragments are not allowed for they are request targets. This much seems inferable. Are these inferences correct?
2. Does http uris in origin-form allowed as request name? or only those in absolute-form? Origin-form of request target allows query-params in them. Is that barred for resource names? They will give issues with slash semantics, as rfc3986 allows / in query params, whilst sharing same absolute-form. And they thus also complicates relative-urls. As of now ESS uses uris in origin-form for their ACP auxilliary resource names. like https://pod.inrupt.com/damodara/?ext=acr.
   etc.

Start by reviewing the issue body, the linked issue 347, and the referenced RFC 7230 request-target forms and RFC 3986 URI rules. Done means the Solid specification explicitly and unambiguously states which URI forms, fragments, and query parameters are permitted for resource names.