Spelling and grammar corrections, minor content additions

README.md

@@ -97,33 +97,39 @@ Alternatively, the schema could be loaded using the reference library function `
 
 #### Update
 
-A schema DID is implicitly updated by updating the corresponding file in the underlying storage network. It is assumed, though, that the schema hash provides a reference to an immutable set of data. This is the case in the IPFS networks where any change in a schema file would result in a new hash and thus a new DID.
+A schema DID is implicitly updated by updating the corresponding file in the underlying storage network. It is assumed, though, that the schema hash provides a reference to an immutable set of data. This is the case in the IPFS networks where any change in a schema file would result in a new hash and thus a new DID. That's why the reference library currently does not offer a distinct update operation and it is required to call the `registerSchema` operation again if the content of a schema is updated.
 
 #### Delete
 
-A schema DID is implicitly deleted by deleting the corresponding file from the underlying storage network. On most IPFS networks the content is immutable and even an explicit deleting procedure is not granted to success.
+A schema DID is implicitly deleted by deleting the corresponding file from the underlying storage network. On IPFS networks, there is however no guaranteed way that a resource is actually deleted, since it may still be stored on some of the distributed nodes.
+
+Since the explicit deletion of a schema is not considered a mandatory requirement, the delete operation is currently not supported in the reference library.
 
 ## Security Considerations
 
 The basic purpose of this DID method is to store, identify and resolve schema definitions in a decentralized way. This is not considered to be a security critical mechanism. However, along the process of storing and accessing data, users of this DID method must take the usual common sense precautions to protect their accounts (e.g. to be used for pinning in IPFS networks) and do not expose any credentials or other security sensitive information in schema content.
 
-Each Storage network has its own security aspects:
+In addition, each Storage network has its own security aspects:
 ### Public IPFS 
-One of the security considerations is Evading. A Node can easily generate a completely new [Node Identity](https://medium.com/textileio/how-ipfs-peer-nodes-identify-each-other-on-the-distributed-web-8b5b6476aa5e) which make it impossible to exclude dishonest nodes, which could serve contents for users that does not match the requested [CID](https://docs.ipfs.io/concepts/content-addressing/), from the network.
-Another consideration is using public or private [Gateway](https://docs.ipfs.io/concepts/ipfs-gateway/#overview), those gatways could be malicious or has some vulnerabilities that would make possible for a [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) to intercept a message, change it and send it back on its way. Therefore, recipients should extra verify that the received content match the requested CID and in case of writeables Gateway the added content should also be verified with the resulted CID.
-A [DDos attack](https://de.wikipedia.org/wiki/Denial_of_Service) on the public IPFS network is significantly more difficult because its distributed and peer-to-peer architecture. The content is spreaded out on severals nodes and can be accessed through the distributed storage network.
+One of the security considerations is evading. A node can easily generate a completely new [node identity](https://medium.com/textileio/how-ipfs-peer-nodes-identify-each-other-on-the-distributed-web-8b5b6476aa5e) making it impossible to exclude dishonest nodes, which could serve content that does not match the requested [CID](https://docs.ipfs.io/concepts/content-addressing/).
+
+Another consideration is using public or private [IPFS gateways](https://docs.ipfs.io/concepts/ipfs-gateway/#overview). A gateway can be malicious or have vulnerabilities that would allow a [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) to intercept and manipulate communication between the client and the gateway.
+
+Therefore, recipients should verify that the received content matches the requested CID. In case of adding a new schema to IPFS through a gateway, the resulting CID should also be verified to match the added content.
+
+A [DDoS attack](https://de.wikipedia.org/wiki/Denial_of_Service) on the public IPFS network is difficult because of its distributed and peer-to-peer architecture. The content is spread over several nodes and can be accessed through the distributed storage network.
 
 ### evan.network IPFS
-Since the IPFS of evan.network is a permissioned IPFS network Evading is not a security considereation. However, the premissioned Network is currenty small and a DDos attack on the network is relativly possible but still hard to success. Also, the [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) still possible if the gateway is malicious or has some vulnerabilities.
+Since the IPFS of evan.network is a permissioned IPFS cluster accessed through a centrally managed endpoint, evading or man-in-the-middle-attacks should not be a security concern. However, the permissioned network is currently small and a DDos attack on the network is possible.
 
 ## Privacy Considerations
 
 Due to the fact that schemas are technical definitions of data structures that should never involve any personal information, privacy should not be much of a concern. In all supported storage networks, the data is stored anonymously and can not be traced back to any specific individual. It is the responsibility of the party providing the schema to make sure that no privacy sensitive data is contained in the schema content.
 
-Similar Storage network has its own Privacy Considerations:
+Each storage network also has its own privacy considerations:
 ### Public IPFS
-With a slight modification to the IPFS node users requesting content can be tracked and information about them like ip-address, node id, region could be collected. That happenes because when a user running a node requests content from the network, each node they are connected to receives a message asking for that content. Even if the user is not running his own node and using a [Gateway]((https://docs.ipfs.io/concepts/ipfs-gateway/#overview)), the provider of the public Gateway could also track the users request and content.
+With a slight modification to the IPFS node, clients requesting content can be tracked and information like the IP address, node id or region could be collected and correlated. That happens because when a user running a node requests content from the network, each connected node receives a message asking for that content. Even if the user is not running an own node but uses a gateway, the provider of the gateway could also track the user's request and content.
 
 ### evan.Network IPFS
-Because evan.network IPFS is permissioned, accessing the content for non particpante users is only possible through gateways which are provided by evan.network or known node operators. Therefore, the privacy of user requests data is the responsibility of the gateway provider.
+Because evan.network IPFS is permissioned, accessing the content for non participating users is only possible through gateways which are provided by evan.network or known node operators. Therefore, the privacy of user request data is the responsibility of the gateway provider.