Hot topic = SAQ A vs SAQ A-EP. Visa Europe's paper strongly leans toward SAQ-A. The council has issued guidance on the topic from Jan 2014 to last week. It strongly leaned toward SAQ A-EP at the start. May 2014 was still SAQ A-EP. And it has shifted steadily to SAQ A ever since. The community meeting had a presentation with a slide that leaves little open to interpretation. The SAQ Guidance from November 2014 (SAQ Aish) was changed in April 2015 (SAQ A-EPish).
There is very little remaining to support the SAQ A-EP for merchants who redirect or use an I-frame from a validated service provider. (very little, but still some!)

All the guidance I have accumulated on the topic (SAQ guidance excerpts, community meeting presentation, the Visa Europe links and more) is at my site:
http://thepciportal.com/2015/05/04/new-saqs-and-guidance-pci-v3-1/

BUT....
No PCI requirements that apply to the webserver are included in SAQ A subset. These controls can reduce the risk of a website redirection attack . This type of attack may point to an attacker controlled web page that appears to be the intended payment processor web site. For example a user is redirected to www.paypaul.ca instead of www.paypal.ca and prompted for their payment information.
SAQ A is among the simplest of assessment reporting forms with only 17 controls required to be reported upon. It is important to note that regardless of the assessment reporting method, a merchant must comply with all applicable PCI DSS requirements.
Excerpt from SAQ forms:
…”This shortened version of the SAQ includes questions that apply to a specific type of small merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to your environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for your environment. Additionally, you must still comply with all applicable PCI DSS requirements in order to be PCI DSS compliant.”