remove normative language from Security Considerations

addresses #183

Author: pchampin

spec/index.html

@@ -1972,7 +1972,7 @@ <h2>Security Considerations</h2>
   <p>The RDF Abstract Syntax is not used directly for conveying information,
     although concrete serialization forms are specifically intended to do so.</p>
 
-  <p>Applications MAY evaluate given data to infer more assertions or to dereference <a>IRIs</a>,
+  <p>Applications can evaluate given data to infer more assertions or to dereference <a>IRIs</a>,
     invoking the security considerations of the scheme for that IRI.
     Note in particular, the privacy issues in [[RFC3023]] section 10 for HTTP IRIs.
     Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions,
@@ -1986,26 +1986,26 @@ <h2>Security Considerations</h2>
     security considerations will vary by domain of use.
     Security tools and protocols applicable to text
     (for example, PGP encryption, checksum validation, password-protected compression)
-    may also be used on RDF documents.
-    Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information.</p>
+    can also be used on RDF documents.
+    Security/privacy protocols ought to be imposed which reflect the sensitivity of the embedded information.</p>
 
   <p>RDF can express data which is presented to the user, such as RDF Schema labels.
     Applications rendering <a>strings</a> retrieved from untrusted RDF documents,
     or using unescaped characters,
-    SHOULD use warnings and other appropriate means to limit the possibility
+    are encouraged to use warnings and other appropriate means to limit the possibility
     that malignant strings might be used to mislead the reader.
     The security considerations in the media type registration for XML ([[RFC3023]] section 10)
     provide additional guidance around the expression of arbitrary data and markup.</p>
 
   <p>RDF uses <a>IRIs</a> as term identifiers.
-    Applications interpreting data expressed in RDF SHOULD address the security issues of
+    Applications interpreting data expressed in RDF ought to address the security issues of
     [[[RFC3987]]] [[RFC3987]] Section 8, as well as
     [[[RFC3986]]] [[RFC3986]] Section 7.</p>
 
-  <p>Multiple <a>IRIs</a> may have the same appearance.
-     Characters in different scripts may look similar (for instance,
-     a Cyrillic &quot;&#1086;&quot; may appear similar to a Latin &quot;o&quot;).
-     A character followed by combining characters may have the same visual representation
+  <p>Multiple <a>IRIs</a> can have the same appearance.
+     Characters in different scripts can look similar (for instance,
+     a Cyrillic &quot;&#1086;&quot; can appear similar to a Latin &quot;o&quot;).
+     A character followed by combining characters can have the same visual representation
      as another character (for example, LATIN SMALL LETTER "E" followed by COMBINING ACUTE
      ACCENT has the same visual representation as LATIN SMALL LETTER "E" WITH ACUTE).
      Any person or application that is writing or interpreting data in RDF