[ python-Bugs-1753732 ] xmlrpclib.Binary doesn't say which base64 spec it implements

[SourceForge.net]

Bugs item #1753732, was opened at 2007-07-13 20:36
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753732&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Winkler (slinkp)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib.Binary doesn't say which base64 spec it implements

Initial Comment:
xmlrpclib.Binary.encode() does base64 encoding.
But there are actually two conflicting specs: RFC 2045 says add newlines every 76 characters, RFC 3548 says do NOT add newlines.

The xmlrpc spec characteristically doesn't mention an RFC, so it's not clear which spec they mean by "base64".
By looking at the dates on the various specs, it can be inferred that they must mean MIME-style with newlines, as per RFC 2045.  That's xmlrpclib does.

But for those of us implementing stuff in the trenches and struggling with interoperability issues, it would be nice if the python docs were more informative so we don't have to go spiraling off into reading multiple specs and figuring out which came first :)

So I'd suggest changing the Binary.encode docstring to something like:

"""Write the XML-RPC base 64 encoding of this binary item to the out stream object.

Note that the encoded data will have newlines every 76 characters as per RFC 2045, which was the de facto standard base64 specification when the xmlrpc spec was written."""

Arguably, the behavior could be changed instead - due to the xmlrpc spec's silence on the subject, not all clients may tolerate newlines (Redstone doesn't)... but that's a separate argument :)


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2007-07-16 23:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

More documentation is always a good idea. Can you provide a patch (as a
context or unified patch) against the sources of the documentation?

----------------------------------------------------------------------

Comment By: Paul Winkler (slinkp)
Date: 2007-07-16 17:36

Message:
Logged In: YES 
user_id=38329
Originator: YES

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

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-07-14 14:51

Message:
Logged In: YES 
user_id=21627
Originator: NO

Note that RFC 3548 is informational, so it is not a specification (at
least not of an internet protocol).

Also notice that Python's xmlrpclib library is not the specification or
de-facto implementation of XML-RPC, either. The official XML-RPC
specification is at

http://www.xmlrpc.com/spec

According to that specification, the only possibilities are that Python's
implementation is either conforming or not conforming. If it is not
conforming, it should be changed; if it is conforming, it should stay, and
Redstone should be changed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753732&group_id=5470