--- a/RFC.html
+++ b/RFC.html
@@ -37,15 +37,11 @@
 <div class="toc4">6.1. &nbsp;<a href="#toc12">In General</a></div>
 <div class="toc4">6.2. &nbsp;<a href="#toc13">Discovery and Startup</a></div>
 <div class="toc4">6.3. &nbsp;<a href="#toc14">Paths and Methods</a></div>
-<div class="toc3">7. &nbsp;<a href="#toc15">LADSPA Compatibility and Miscellaneous Notes</a></div>
-<div class="toc4">7.1. &nbsp;<a href="#toc16">Port Rewriting</a></div>
-<div class="toc4">7.2. &nbsp;<a href="#toc17">Reset on activate()</a></div>
-<div class="toc4">7.3. &nbsp;<a href="#toc18">"Unique" IDs</a></div>
 
 
 
 <p>An API for soft synth plugins with custom user interfaces.
- Version 1.0.
+ Version 0.9.
 </p>
 <div class="oddcontent"><a name="toc1"></a><h3>1. &nbsp;Summary</h3>
 
@@ -254,6 +250,7 @@
 </p><pre>
    -- activate()
    -- cleanup()
+   -- connect_port()
    -- deactivate()
    -- instantiate()
 </pre>
@@ -272,7 +269,6 @@
 
 <p>The remaining functions belong to the audio class:
 </p><pre>
-   -- connect_port()
    -- run()
    -- run_adding()
    -- run_synth()
@@ -305,7 +301,7 @@
 
 <br/><br/></li><li>While a function of the instantiation class is being run, the
      host may not call any functions of the other two classes, and
-     vice versa. Thus, a plugin is assured that e.g. instantiate() or
+     vice versa. Thus, a plugin is assured that e.g. connect_port() or
      deactivate() will not be called for any instance in the instance
      group until all previous control and audio function invocations
      for the instance group have finished.
@@ -369,23 +365,18 @@
  uses an implementation by Steve Harris called liblo ("Lite OSC") which
  can be obtained from
 </p><pre>
-  <A HREF="http://liblo.sourceforge.net/">http://liblo.sourceforge.net/</A>
+  <A HREF="http://www.plugin.org.uk/liblo/">http://www.plugin.org.uk/liblo/</A>
 </pre>
 <p>Note that liblo is distributed under a different licence from DSSI and
  so might not be a legal option for certain DSSI implementations.
 </p>
-<p>DSSI uses OSC in both directions between the host and UI.  When a user
- changes a configure, program, or port value in the UI, it sends an
- OSC request to the host, which informs the plugin of the change;
- when an automated change occurs in the host, or a plugin's output
- control port changes, the host sends an update to the UI.
-</p>
-<p>(The host does not send updates to the UI for configure, program,
- or port changes that the UI itself initiated; likewise the UI must
- not send changes back to the host that the host itself initiated.
- A host that supports multiple UIs per plugin instance should send
- each change to all UIs for the instance other than the UI that
- initiated it.)
+<p>DSSI uses OSC in both directions between the host and UI.  When a
+ user changes a port value in the UI, it sends an OSC request to the
+ host, which informs the plugin of the change; when an automated port
+ change occurs in the host, it sends an update to the UI.  (The host
+ does not send updates to the UI for port changes that the UI itself
+ initiated; likewise the UI must not send port changes back to the
+ host that the host itself initiated.)
 </p>
 <p>Communications between the host and UI are deliberately as limited as
  possible.  There is, for example, no way for a UI to query the
@@ -403,7 +394,7 @@
  labelled PLUGIN found in a dll named MYPLUGINS.so in directory
  DIRECTORY, we would recommend as follows.
 </p>
-<p>The host looks for a directory DIRECTORY/MYPLUGINS/.  If found, it looks
+<p>The host looks for a directory DIRECTORY/PLUGINS/.  If found, it looks
  for executable files or symbolic links in that directory beginning
  with the string PLUGIN or MYPLUGINS and ending with a suffix separated
  by an underscore, e.g. PLUGIN_gui, MYPLUGINS_qt.  If nothing so named
@@ -429,15 +420,12 @@
 <p>Once the host has found a suitable executable, it then starts it with
  a command line consisting of:
 </p><ul>
-<li>the executable name in argv<CODE>0</CODE> as normal (including
- the full path, so that the UI may locate either the MYPLUGINS.so or
- supporting files in the MYPLUGINS subdirectory, if need be.)
+<li>the executable name in argv<CODE>0</CODE> as normal
 
 <br/><br/></li><li>the OSC URL for the host, identifying the host and the base path
      for the correct plugin instance (see Paths and Methods below)
 
-<br/><br/></li><li>the name of the .so in which the plugin was found
- (here MYPLUGINS.so)
+<br/><br/></li><li>the name of the .so in which the plugin was found (here PLUGINS.so)
 
 <br/><br/></li><li>the label of the plugin (here PLUGIN).
 
@@ -449,7 +437,7 @@
 <p>If the UI supports the show/hide mechanism (which any graphical UI
  should), then it should initially be in hidden state.  The UI then
  requests an update, passing its own OSC URL and base path to the host;
- the host responds by sending the sample rate and current configure, program and
+ the host responds by sending the current configure, program and
  control values (in that order).  The host must then call show() on the
  UI and startup is complete.
 </p>
@@ -461,8 +449,8 @@
 <p>The DSSI host and UI are each expected to think of an arbitrary path
  to associate with each plugin instance, known as the "base path".
  This will presumably have some internal and/or diagnostic meaning:
- e.g. a host might use "/dssi/MYPLUGINS/PLUGIN.1" for the path to the
- first instance of plugin labelled PLUGIN in MYPLUGINS.so.  Individual
+ e.g. a host might use "/dssi/PLUGINS/PLUGIN.1" for the path to the
+ first instance of plugin labelled PLUGIN in PLUGINS.so.  Individual
  method calls are always made to a subpath of the base path, as
  detailed below.
 </p>
@@ -472,7 +460,7 @@
 </p>
 <p>These are the methods the host may support:
 </p><ul>
-<li>&lt;base path&gt;/control  (e.g. "/dssi/MYPLUGINS/PLUGIN.1/control")
+<li>&lt;base path&gt;/control  (e.g. "/dssi/PLUGINS/PLUGIN.1/control")
 
 <br/><br/>   Set a control port value on the plugin at &lt;base path&gt;.  Takes an int
     argument for port number and a float for value.  (required method)
@@ -486,7 +474,7 @@
 
 <br/><br/>   Request an update on the UI.  Takes one string argument, the UI's
     own OSC URL with base path.  The host should respond by sending the
-    current state of the plugin to the UI in a series of sample-rate, configure,
+    current state of the plugin to the UI in a series of configure,
     program, and control OSC calls.  (required method, and the UI is
     required to use it)
 
@@ -538,12 +526,6 @@
     update() request, e.g. on startup.  Takes two string arguments for
     key and value.  (required method)
 
-<br/><br/></li><li>&lt;base path&gt;/sample-rate
-
-<br/><br/>   Inform the UI of the sample rate at which the plugin is
-    being run. Takes an int argument for the rate, in frames per
-    second. (optional method)
-
 <br/><br/></li><li>&lt;base path&gt;/show
 
 <br/><br/>   Show the UI, if it's a graphical interface in a window or some
@@ -567,65 +549,6 @@
     that may be necessary for the host to restore the plugin instance
     correctly.  (required method)
 </ul>
-</div><div class="oddcontent"><a name="toc15"></a><h3>7. &nbsp;LADSPA Compatibility and Miscellaneous Notes</h3>
-
-</div><div class="evencontent"><a name="toc16"></a><h4>7.1. &nbsp;Port Rewriting</h4>
-
-<p>A LADSPA plugin must never change the values of its own input ports.
-</p>
-<p>A DSSI plugin is allowed to do so when select_program is called.  The
- host must re-read the input port values after calling select_program,
- if it wishes to keep an accurate record of them.  (The host should
- <I>not</I> notify any extant UI of the new values -- the UI is notified of
- the program change, and that should be enough.)
-</p>
-</div><div class="oddcontent"><a name="toc17"></a><h4>7.2. &nbsp;Reset on activate()</h4>
-
-<p>LADSPA says "hosts can reinitialise a plugin instance by calling
- deactivate() and then activate(). In this case the plugin instance
- must reset all state information dependent on the history of the
- plugin instance except for any data locations provided by
- connect_port() and any gain set by set_run_adding_gain()."
-</p>
-<p>This is slightly ambiguous when applied to DSSI plugins that have
- internal state that does not change as a matter of course through
- time, but that is based on settings made via port and program changes
- or MIDI controller data.
-</p>
-<p>On activate(), a DSSI plugin should reset any internal state that
- changes over time and is not controlled by the host.  Anything that is
- set by the host (configure data, program data, port data, or any
- internal values derived from these) should be left alone, or, in the
- case of data that change over time from host-provided values, reset
- to the values that were most recently set by the host.
-</p>
-<p>(The intention is that a host should be able to silence a plugin by
- calling deactivate followed by activate, and should know that after
- the activate call, the plugin has been reset to a state that is
- entirely defined by its host-visible configuration.)
-</p>
-</div><div class="evencontent"><a name="toc18"></a><h4>7.3. &nbsp;"Unique" IDs</h4>
-
-<p>LADSPA defines a "Unique ID" value within a plugin descriptor, which
- is intended to provide a globally unique identifier for the plugin
- type.  Plugin authors are expected to liaise with an unnamed central
- body to ensure that their plugin IDs are in fact unique.
-</p>
-<p>This is a problematic concept.  Without an official LADSPA
- organisation, it's not obvious how an author actually obtains a unique
- ID range.  Some authors may wish to write plugins that may vary in
- number, either by automatically generating them or by providing
- wrappers for other sorts of plugin.  For such plugins, it is
- impossible to guarantee that the "unique" ID is in fact unique.
-</p>
-<p>DSSI host authors are strongly recommended to ignore the LADSPA
- "Unique ID" when handling DSSI plugins.  Instead, they should identify
- a DSSI plugin by the DLL's .so name and the LADSPA "Label" (which
- should be unique within a single .so file).  Hosts that do otherwise
- will inevitably experience subtle but disastrous failures for some
- existing and yet-to-be-written plugins, because of the practical
- impossibility of making the "Unique ID" actually unique.
-</p>
 <p></p>
 
 </div>