--- a/paq/prov-aq.html	Wed Feb 27 12:26:02 2013 +0000
+++ b/paq/prov-aq.html	Wed Feb 27 13:02:19 2013 +0000
@@ -1021,26 +1021,23 @@
 </pre>
 
       <p class="TODO">
-        Details to change with Stian's proposal
+        Review.  
+        Stian's original example returns additional link information - I've removed it for now to focus the example on the essential features, but it could be re-introduced (currently present as comments in HTML source of this document)
         <br/>
-        Stian suggests also returning the following information - I agree it's an option for the server, but I'm not sure if this should be included here:
-        <br/>
-        <code><pre>
+        <!--
   S: Link: &lt;http://wile-e.example.org/contraption/provenance&gt;;
            rel=http://www.w3.org/ns/prov#has_provenance;
            anchor=http://acme.example.org/super-widget
   S: Link: &lt;http://wile-e.example.org/another/provenance&gt;;
            rel=http://www.w3.org/ns/prov#has_provenance;
            anchor=http://acme.example.org/super-widget
-        </pre></code>
-      </p>
-      <p class="TODO">
-        <br/>
+        -->
       </p>
       <p>
-        The pingback requests contains a list of <a class="internalDFN">provenance-URI</a>s from which forward provenance may be retrieved.  The pingback service may do as it chooses with these URIs; e.g., it may choose to save them for later use, to retrieve the associated provenance and save that, or to publish the URIs along with other provenance information about the original entity to which they relate.
+        The pingback request supplies a list of <a class="internalDFN">provenance-URI</a>s from which forward provenance may be retrieved.  The pingback service may do as it chooses with these URIs; e.g., it may choose to save them for later use, to retrieve the associated provenance and save that, to publish the URIs along with other provenance information about the original entity to which they relate, or even to ignore them.
       </p>
-      <p>The client MAY supply <code>#has_query_service</code> <code>Link:</code> headers that indicate services which can describe the target-URI. The anchor MUST be included, and SHOULD be the target-URI of the resource which this pingback service belongs to, unless the submitted query service would expect a different target-URI to describe the given resource.
+      <p>
+        The client MAY further supply <code>#has_query_service</code> <code>Link:</code> headers indicating provenance query services that can describe the target-URI. The anchor MUST be included, and SHOULD be the entity-URI of the resource to which this pingback service belongs, or some related resource with relevant provenance.
       </p>
       <pre class="example code">
   C: POST http://acme.example.org/pingback/super-widget HTTP/1.1
@@ -1062,7 +1059,7 @@
       <p>The client MAY similarly include <code>#has_provenance</code> <code>Link:</code> headers to specify a different anchor. The provenance-URIs of those headers SHOULD also be included in the content if the POSTed Content-Type is <code>text/uri-list</code>.
       </p>
       <p class="TODO">
-        I've downplayed MUST to SHOULD in the last.  If the content is empty, should the Content-type be omitted?  (see example above).  I would be inclined to makje it optional, and omit it from the example.
+        I've downplayed MUST to SHOULD in the last.  If the content is empty, should the Content-type be omitted?  (see example above).  I would be inclined to make it optional, and omit it from the example.
       </p>
       <p>
         There is no required information in the server response to a pingback POST request.
@@ -1171,7 +1168,7 @@
       <h2 id="prov-namespace">Terms added to prov: namespace</h2>
 
       <p class="TODO">
-        Possible renaming of all relations to lowercase-only forms.
+        Possible renaming of service description relations to lowercase-only forms?
       </p>
 
       <p>