On 2007-09-28 at 10:39 +1000, Daniel Pittman wrote: > Why, yes, EPP, I /am/ looking at you. Felching miserable half-caste > screwed up abortion of a protocol.
> Well, then, what should we do? Why, add a 32bit binary number before > each XML message to give the length, adding binary framing to an > otherwise text only protocol. Bah, that's nothing. Read the protocol spec for BEEP: RFC 3080 The Blocks Extensible Exchange Protocol Core RFC 3081 Mapping the BEEP Core onto TCP BEEP is the foundation for things like the inter-registrar protocols for DNS domains. Then there are RFCs to nest SOAP and XML-RPC in BEEP. Oh, and NETCONF for managing network devices (using XML)? They couldn't agree on a standard transport, so you get to pick between the equally standards-blessed SSH, SOAP and BEEP. So, multiplexed command-response with multiple channels within a connection, independent messages within channels, with a header line containing those numbers and a length and a trailer line of END. Within that, you have MIME headers followed by the content, which is technically arbitrary 8-bit data, except that all of the BEEP maintenance protocol stuff puts XML in there. The channels are independent, except when they're not (activating TLS turns it on for all channels, which fit within TLS, thus immediately breaking the IO channel abstraction). Authentication is provided via SASL. Again, encoded inside XML, with things like CRAM-MD5 challenges encoded inside <![CDATA[...]]>, _and_ first wrapped with an XML 'blob' element. To quote a reply from the RFC: S: RPY 0 1 . 221 185 S: Content-Type: application/beep+xml S: S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'> S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+</blob>]]> S: </profile> S: END And yes, it's BEEP which mandates (via a SASL profile) that the binary data of the challenge must be encoded as a base64 string. I've never had to write to BEEP. I'm grateful. The fact that this protocol exists bothers me. -Phil
