Thanks Loewis, but I am well aware of the xmlrpc spec. As I said in my original bug report:
The spec alone is too vague to tell us which base64 specification xmlrpclib should conform *to*, and thus we can't say whether xmlrpclib does or does not conform. Your yes/no question is thus unanswerable.  In my opinion this means the spec is broken, but there's apparently no chance of an official update.

I brought this up on the xmlrpc yahoo list. 
http://tech.groups.yahoo.com/group/xml-rpc/message/6650

Some excerpts from relevant responses:
"The fact is, the spec has been frozen - "cast in stone" in the words of
the author - since 1999, and there is absolutely 0% chance of an
official update." - http://tech.groups.yahoo.com/group/xml-rpc/message/6651

"It would be nice to have a document that describes what "everyone does,"
but ... http://effbot.org/zone/xmlrpc-errata.htm
does a good job too. Note that the latter clearly says you can split
base64 lines if you want. ... I believe that essentially all XML-RPC implementations use MIME-style
(RFC 2045) base64 encoding -- i.e. with line breaks." - http://tech.groups.yahoo.com/group/xml-rpc/message/6653

Finally, about the Redstone problem that led me to post this report:
"I have just looked at the Redstone Bas64 decoder and it's obviously
broken. The code correctly ignores whitespace characters but then
complains that the data is too short."

I have filed a bug report against Redstone:
http://sourceforge.net/tracker/index.php?func=detail&aid=1753822&group_id=25164&atid=383547

From the responses so far, I don't think a change to Python's behavior is warranted.
I *do* still think it would be useful to clarify the xmlrpclib documentation as I've suggested in this bug report, so users know what to expect. Is there any good reason NOT to do this?

A link to the official spec at http://www.xmlrpc.com/spec should also be added to the "See also" links, possibly along with a link to Fred's unofficial errata at 
http://effbot.org/zone/xmlrpc-errata.htm