I tried twice to respond to Omri's post on ref props vs params but I got errors both times, so here's my response.
I think that in the example you've given, most software, like browers, caches, security, etc. will interpret the RefParam as part of the identifier for the service. I agree that a service may internally use the param1 as a RefParam but the external world probably won't ignore the param1 for URI identity comparison purposes.
I think a closer comparison for RefParams from an identity perspective is fragment ids, ie
http://foo/bar#param1=value1. The frag-id isn't sent to the service as part of the request, but is retained and then used by the client for the response. Kind of the way RefProps/Params aren't "used" by the service but by the receiver of the EPR.
This is why I like Ref Params as incarnated in WS-Addr, that the author can choose to make information either part of the identifier or not, and they can choose to either use the URI (Web infrastructure) only or URI + Ref Props/Params structure. There's 3 different extensibility points for them to choose for their application.
