If one or both of the Type Indexes are missing, an app
needing to write to them that doesn't have Write and Control
access to the root storage MAY warn the user that their indexes are
missing and that they should use a storage management App to fix
their profile.
Split this into smaller parts. It seems like advisory rather than a requirement. Consider approaching from another way, e.g.:
"
When an application cannot discover a public or private type index, applications are encouraged to inform the user that their indexes are missing and consider using a storage management application (aside: or WebID Profile management application?) to include this information.
"
Information about access permissions can expressed in a similar way for both when they have access to Write or not. I wouldn't bother mentioning Control unless there is something special about it because it is an indirection - the goal is to have Write, so don't need to complicate here.
Take care with wording around "informing" or "warning" or "alerting" or something else with each of these scenarios.
The Public Type Index document SHOULD be publicly readable, writable
by the user (or a group delegated by the user),
This kind of requirement "SHOULD be publicly readable" is part of the definition of the concept. It is intended to be "public". Ditto, "private" type index is intended to be protected. There is no strong need to say this as a requirement. There is always the possibility access permissions on these resource can change, and I don't see what SHOULD does here. What would a test assertion reveal about such test criterion? In all likelihood, it would just a "passed" outcome whether it is readable or not. Same goes for writeable. The intention that's part of the definition is important. So, either make a hard requirement with a MUST or role the expectation into the definition and then talk about the writing aspect under the Security Considerations section, e.g.:
It is strongly encouraged that Public Type Indexes are only writeable by the users..
Ditto Private Type Index "only readable and writeable.."
and a pointer to
it MUST be placed in the WebID Profile Document.
If the Type Index files are created but the pointer to
them are not stored, the risk is that new resource get created, leading to
confusion and possible loss of data.
Confusing who or what?
Frame it another way perhaps under (Security or Privacy) Considerations section instead of a Note:
To prevent potential loss of data or its discovery, applications are strongly encouraged to treat the creation of Type Indexes and their discovery as an atomic operation.
Re #supplying-missing-type-index-documents
Split this into smaller parts. It seems like advisory rather than a requirement. Consider approaching from another way, e.g.:
" When an application cannot discover a public or private type index, applications are encouraged to inform the user that their indexes are missing and consider using a storage management application (aside: or WebID Profile management application?) to include this information. "
Information about access permissions can expressed in a similar way for both when they have access to Write or not. I wouldn't bother mentioning Control unless there is something special about it because it is an indirection - the goal is to have Write, so don't need to complicate here.
Take care with wording around "informing" or "warning" or "alerting" or something else with each of these scenarios.
Also some care with advisement level language - see e.g. https://solidproject.org/TR/protocol#advisement-levels and see how that language is used in e.g., https://solidproject.org/TR/protocol#security-considerations .
This is part of https://github.com/solid/type-indexes/issues/15
This kind of requirement "SHOULD be publicly readable" is part of the definition of the concept. It is intended to be "public". Ditto, "private" type index is intended to be protected. There is no strong need to say this as a requirement. There is always the possibility access permissions on these resource can change, and I don't see what SHOULD does here. What would a test assertion reveal about such test criterion? In all likelihood, it would just a "passed" outcome whether it is readable or not. Same goes for writeable. The intention that's part of the definition is important. So, either make a hard requirement with a MUST or role the expectation into the definition and then talk about the writing aspect under the Security Considerations section, e.g.:
It is strongly encouraged that Public Type Indexes are only writeable by the users..
Ditto Private Type Index "only readable and writeable.."
I think this is redundant - covered earlier in the document re Discovery (see https://github.com/solid/type-indexes/issues/16 )
Confusing who or what?
Frame it another way perhaps under (Security or Privacy) Considerations section instead of a Note:
To prevent potential loss of data or its discovery, applications are strongly encouraged to treat the creation of Type Indexes and their discovery as an atomic operation.