Can an URL shortener pass parameters?

URL shortening associates a unique key based on a full URL (parameters and all), so it is not possible to pass parameters to a shortening service.

Typically

http://iphone.pp-p.net/default.aspx?param=10

must produce a different key to

http://iphone.pp-p.net/default.aspx?param=22

'Parameter forwarding' is simply not possible in these kinds of redirects, as parameters are not valid parts of a shortened URL is most (if not all) services.

As mentioned in comments by rinogo and Jurgen

In Clickmeter

Destination URL : www.yoursite.com?myparam1={id1}&myparam2={id2} 
Tracking link   : www.go.clickmeter.com/38w2?id1=123&id2=abc 
After click     : www.yoursite.com?myparam1=123&myparam2=abc

In TinyUrl

Destination URL     : http://x.com?a=1
Shorten URL         : https://tiny url.com/y6gh7ovk
Shorten URL + param : https://tiny url.com/y6gh7ovk?a=2
Resultant URL       : http://x.com/?a=1&a=2

Added space to post tinyurl

There's no technical reason why it couldn't be done. The service would simply have to look at what parameters it is being sent, and then rewrite the target URL accordingly.

The problem is that it's not necessarily well defined how to do that.

Suppose you have the url http://example.com/default.aspx?foo=bar, and it has the short url http://foo.com/ABCD. What should happen if you try to access http://foo.com/ABCD?foo=baz? Should it replace the value, so you get foo=baz? Should it append it to make foo=bar&foo=baz? If we include both, which order should they be in?

The system cannot know which parameters are safe to override and which are not, because sometimes, you DO want both of them in the URL, and it may matter what order things are added in.

You could argue "Well, just don't allow this for URLs where parameters are already present", but there's also the issue that it's going to complicate the process a lot more. Without this, you just lookup a key in a database and send a redirect header. Now, you need to also analyze the URL to check for parameters, and append part of the URL you were called by. That requires more system resources per redirect, which may become a big problem if your service is used very frequently - you'll need more server power to handle the same amount of redirects. I don't think that tradeoff is considered to be "worth it".