Carsten, I understand why option #2 may put less burden on the producer, but in contrast it may make it more difficult to _debug_ the producer. Option #2 means that the markup produced by the producer is not "valid", e.g. the links cannot be "followed" by a browser. This means that if behind the producer is a real HTTP application, it cannot be debugged "offline", or even checked with HTML validators that check links. Option #4, on the other hand, always creates valid HTML and links, which means that the "underlying application" can be tested by sending a "dummy" Proxy URL. In any case, the difference in the difficulty for the producer between #2 and #4 are minor. In both cases, URL-s in the underlying applications will need to be changed by the producer - it's just a question of the change algorithm (although in the case of "static" HTML pages I do agree that option #2 is easier). What I would propose is to enable both. Option #4 is enabled by one simple argument in the getFragments/performAction - the "Proxy URL" below (which in the original draft was named "controllerUrl" and which Thomas and Rich omitted when moving from the original draft specification to the new draft specification). The producer metadata (or return value from those operations) will specify whether URL rewriting was done or not. Gil