Well, there are in fact a lot of quirks in the spec. In the past it
stated that string data had to be ASCII and could be used to encode
binary stuff, and this led to an infinity of discussion. Date format and
the possibility to omit some stuff have also been discussed at length.

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. And any updates that are not official just lead to more
fragmentation/confusion.

As far as I know, the best approach for any implementation is: be
liberal in what you accept, strict in what you give.
This means:
- do not add newlines in outgoing base64data
- strip newlines from received base64 data if there are any

Thus, in my pov, both the libs are wrong ;)

Bye
Gaetano

> Is it correct, or at least permissible, for implementations to embed
> newlines in the wire representation of base64 data?
>
> The xmlrpc spec doesn't say. It just says "base64-encoded binary" and
> the example data is very short.
>
> >From looking at the dates of the various specs, I infer that rfc2045
> was the current defacto spec for base64 encoders, therefore, xmlrpc
> implementations should expect to see newlines in the encoded data.
>
> RFC 3548 and RFC 4648 say NOT to use newlines, but they had not been
> written yet.
>
> This came up for me because Python's xmlrpclib adds newlines every 76
> characters, as per RFC 2045, but Redstone's parser blows up on them,
> apparently expecting the data to conform to RFC 3548 or 4648.
>
> It would be really, really nice if the xmlrpc spec could be updated to
> clarify this so implementers don't have to know the entire history of
> base64 ... and so we could have an authoritive source to say whether
> Python or Redstone is wrong :)
>
> -PW
>
>