Let me try to back-up a bit on this issue. I see it as being composed of the following points:

1.) We need to make clear to Subscribers / Event Sinks that the Event Source MAY take into account additional information that appears in the SOAP Headers of the request that carries the wse:Subscribe message when it creates a subscription. This information may affect the contents, structure, and delivery of the Notifications in that subscription. For example, if the Subscriber sends this:
 
<s12:Envelope . . .>
  <s12:Header>
    <wsa:Action>http://www.w3c.org/2009/02/Subscribe</wsa:Action>
    <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://www.example.com/MyEventSink</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To>http://webservice.bea.com/PO/EventSource</wsa:To>
    <sc009:OrderID>PJ-73f250</sc009:OrderID>
  </s12:Header>
  <s12:Body>
    <wse:Subscribe>
      <wse:Delivery>
        <wse:NotifyTo>
          <wsa:Address>
            http://www.example.com/MyEventSink/POUpdates
          </wsa:Address>
        </wse:NotifyTo>
      </wse:Delivery>
    </wse:Subscribe>
  </s12:Body>
</s12:Envelope>
it may result in the Event Sink receiving different information than if the Subscriber had sent this:
<s12:Envelope . . .>
  <s12:Header>
    <wsa:Action>http://www.w3c.org/2009/02/Subscribe</wsa:Action>
    <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://www.example.com/MyEventSink</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To>http://webservice.bea.com/PO/EventSource</wsa:To>
    <sc009:OrderID>DR-2a673c</sc009:OrderID>
  </s12:Header>
  <s12:Body>
    <wse:Subscribe>
      <wse:Delivery>
        <wse:NotifyTo>
          <wsa:Address>
            http://www.example.com/MyEventSink/POUPdates
          </wsa:Address>
        </wse:NotifyTo>
      </wse:Delivery>
    </wse:Subscribe>
  </s12:Body>
</s12:Envelope>
2.) When Event Sources do this sort of thing they SHOULD include this "additional information" in the form of EPRs. For example, a purchase order response type might be defined as follows:

<xs:complexType name="OrderRespType">
  <xs:sequence>
    <!-- Info about the newly created purchase order. -->
    <xs:element name="OrderInfo" type="tns:OrderInfoType"/>

    <!-- EPR to which the consumer may send a WS-Eventing Subcribe message in order to
         receive notifications about the ongoing status of the newly created purchase order.
      -->
    <xs:element name="SubscriptionEPR" type="wsa:EndpointReferenceType"/>

    <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>

The semantic of the purchase order system are such that, when it creates an order with an ID of "DR-2a673c" it will mint a SubscriptionEPR like so:

<sc009:SubscriptionEPR>
  <wsa:Address>http://webservice.bea.com/PO/EventSource</wsa:Address>
  <wsa:ReferenceParameters>
    <sc009:OrderID>DR-2a673c</sc009:OrderID>
  </wsa:ReferenceParameters>
</scc09:SubscriptionEPR>

3.) We should advise developers of Event Sources that using additional elements in the headers is not meant to replace the filter facility built into the WS-Eventing protocol. In this case, the semantics of including the OrderID in the header of a Subscribe message are "I want to receive Notifications about this purchase order until such time as the process has completed, at which point I want the subscription to be terminated." The reason we are using a header instead of defining a filter is that we want to tie the lifetime of the subscription to the lifetime of the purchase order; as far as I know there is no way of specifying this using the current filter semantics. The point is: if what you are doing can be done using a filter, you should use a filter.

4.) Implementations should note that (2) contradicts the Architecture of the World Wide Web, Volume One [1] by using reference properties to identify resources (in our example case the subscription service for a PO). This use of reference properties to identify resources may lead to situations in which your resources are not readily accessible via HTTP.*

If people agree on these points, I'll write up a concrete proposal that embodies them.

- gp

[1] http://www.w3.org/TR/webarch/

* Would should just sprinkle statements like this throughout the WS-RA specs everywhere we talk about the use of reference parameters.