removed remaining issues now resolved or closed

conneg-by-ap/index.html

@@ -512,50 +512,6 @@ <h3>Profile Identification</h3>
         MUST identify the <a>resource</a> by a Uniform Resource Identifier (URI) [[RFC3986]] and MUST
         identify the <a>profile</a> either by a URI or a <a>token</a>.
       </p>
-      <div class="issue" data-number="290">
-	<p>The use of tokens for profile identification
-		was a controversially discussed topic within the working group
-		(cf. discussion in <a href="https://github.com/w3c/dxwg/issues/290">#290</a>).</p>
-	<p>The proponents of tokens stressed the value of short mnemonic identifiers
-		for human actors using web browsers.
-		Since browsers usually do not easily allow request headers to be set or modified
-		the easiest way for human actors to negotiate for profiles
-		(or any other content dimension)
-		is to use Query String Arguments (QSAs).
-		When using QSAs, the profile identifier is put in the query part of the request URI
-		and since all content in the query part needs to be URL-encoded
-		this requires that several characters that are common in URIs
-		(e. g. '<code>:</code>' and '<code>/</code>')
-		be percent-encoded which is an error-prone process if done manually.
-		Since tokens are usually restricted to the character group <code>[A-Za-z0-9]</code>,
-		they have not only the advantage of being shorter than most URIs,
-		but also that they can be used in the query part of the request URI
-		without the need to percent-encode any of its characters.
-		Further, there are several systems already deployed
-		that build on standards that use tokens for profile identification.</p>
-	<p>The opponents of tokens questioned the use of tokens from two main angles.
-		One argument was that while URIs are universally unique,
-		tokens will introduce non-uniqueness challenges
-		since there is no universal registry for token/URI mappings
-		(nor is it likely that there will be one).
-		The proposed approach that servers publish token/URI mappings for the resources they serve
-		was seen as unsatisfactory since the scope of that mapping would not be clear:
-		Would it be valid for a domain, a sub-domain or only for the requested resource?
-		Following on that, the benefits of such a mapping was generally questioned
-		on the grounds that machine-driven clients would likely use
-		http content negotiation with the Accept-Profile and Content-Profile headers
-		and full profile URIs instead of tokens.
-		Also, since tokens are not unique,
-		a client would either need to know a server’s URI/token mappings <em>before</em> using the token
-		(in which case it could use the URI instead)
-		or it would need to look it up through the URI/token mapping
-		(in which case it would need to know the profile URI).
-		In each case, the client would need to know the profile URI,
-		which means that tokens do not make client and/or server implementation easier
-		since in order to conform to the specification
-		they need to support not only profile URIs but profile tokens, too.</p>
-	<p>[When this #290 has been resolved, this issue should be turned into a note also saying what the resolution was]</p>
-      </div>
       <p>
         If a URI is used for profile identification, it SHOULD be an HTTP
         URI that dereferences to a description of the profile. Other kinds or URIs, e. g. URNs MAY also be used and these may no be capable of dereferencing.
@@ -883,21 +839,14 @@ <h3>Hypertext Transfer Protocol Headers</h3>
 	      <code>Accept-Profile</code> and <code>Content-Profile</code> that are to be defined in an upcoming
         Internet-Draft [[PROF-IETF]].
       </p>
-      <div class="note" title="Feature at risk">
-        <p>
-	  The use of HTTP headers to transport information
-	  about which profiles the response message's content conforms to
-	  is <strong>at risk</strong> pending the IETF standardisation work.
-        </p>
-      </div><div class="issue" data-number="678"></div>
-      <div class="note" title="Issue 678: POST/PUT out of scope">
+      <div class="note" title="POST/PUT out of scope">
         <p>
           POST &amp; PUT methods are considered out-of-scope for this Functional Profile. It is not clear what functions of
         the proposed Abstract Model these HTTP methods would implement.
         </p>
         <p>
-          <code>Content-Profile</code> headers may be specified in POST &amp; PUT request to communicate the conformance of a
-          request message's content but the Working Group has no specified requirements for this.
+          <code>Content-Profile</code> headers may be specified in POST &amp; PUT requests to communicate the conformance of
+          a request message's content.
         </p>
       </div>
       <p>
@@ -2106,7 +2055,6 @@ <h3>Alternate Representations Data Model - Details</h3>
       </p>
       <section id="altr-implementations">
         <h4>Implementations</h4>
-        <div class="issue" data-number="1041"></div>
         <p>
           A Web Ontology Language [[OWL2-OVERVIEW]] implementation of the data model in <a href="#altr"></a> is given
           below in <a href="#altr-owl">Code Listing 3</a>. It is also available in the file