clarify behaviour of 'limit'

closes #368
closes #640

core/standard/clause_7_core.adoc

@@ -833,6 +833,7 @@ For string-valued properties, servers could support wildcard searches. The examp
 
 Any combination of `bbox`, `datetime` and parameters for filtering on feature properties is allowed. Note that the requirements on these parameters imply that only features matching all the predicates are in the result set; i.e., the logical operator between the predicates is 'AND.'
 
+[[fc-response]]
 ==== Response
 
 include::requirements/core/REQ_fc-response.adoc[]

core/standard/requirements/core/REQ_fc-limit-response-1.adoc

@@ -2,6 +2,10 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Requirement {counter:req-id}* |*/req/core/fc-limit-response-1* 
-^|A |The response SHALL not contain more features than specified by the optional `limit` parameter. If the API definition specifies a maximum value for `limit` parameter, the response SHALL not contain more features than this maximum value.
-^|B |Only items are counted that are on the first level of the collection. Any nested objects contained within the explicitly requested items  SHALL not be counted.
+^|A |The response SHALL not contain more features than specified by the optional `limit` parameter. 
+^|B |If the API definition specifies a maximum value for `limit` parameter, the response SHALL not contain more features than this maximum value.
+^|C |If the value of the `limit` parameter is larger than the maximum value, this SHALL NOT result in an error (instead se the maximum as the parameter value).
+^|D |Only items are counted that are on the first level of the collection. Any nested objects contained within the explicitly requested items  SHALL not be counted.
 |===
+
+See <<fc-response>> for more discussion about the `limit` parameter.