docs: update negotiation docs

Mention that the acceptcaps query does not have to be recursive

diff --git a/docs/design/part-negotiation.txt b/docs/design/part-negotiation.txt
index 89ae38b..f01b9b1 100644 (file)
--- a/docs/design/part-negotiation.txt
+++ b/docs/design/part-negotiation.txt
@@ -31,6 +31,8 @@ Queries
 A pad can ask the peer pad for its supported GstCaps. It does this with
 the CAPS query. The list of supported caps can be used to choose an
 appropriate GstCaps for the data transfer.
+The CAPS query works recursively, elements should take their peers into
+consideration when constructing the possible caps.
 
  (in) "filter", GST_TYPE_CAPS (default NULL)
        - a GstCaps to filter the results against
@@ -39,11 +41,15 @@ appropriate GstCaps for the data transfer.
        - the result caps
 
 
+
 A pad can ask the peer pad if it supports a given caps. It does this with
-the ACCEPT_CAPS query.
+the ACCEPT_CAPS query. The caps must be fixed.
+The ACCEPT_CAPS query is not required to work recursively, it can simply
+return TRUE if a subsequent CAPS event with those caps would return
+success.
 
  (in) "caps", GST_TYPE_CAPS
-       - a GstCaps to check
+       - a GstCaps to check, must be fixed
 
  (out) "result", G_TYPE_BOOLEAN (default FALSE)
        - TRUE if the caps are accepted
@@ -56,7 +62,7 @@ When a media format is negotiated, peer elements are notified of the GstCaps
 with the CAPS event. The caps must be fixed.
 
     "caps", GST_TYPE_CAPS
-       - the negotiated GstCaps
+       - the negotiated GstCaps, must be fixed
 
 
 Operation