intertwingly

It’s just data

Pulling on a string


Mark Nottingham: In a nutshell, XOP is an alternate serialisation of XML that just happens to look like a MIME multipart/related package, with an XML document as the root part. That root part is very similar to the XML serialisation of the document, except that base64-encoded data is replaced by a reference to one of the MIME parts, which isn’t base64 encoded.

I guess I am supposed to take comfort in the assertions that the serializations look like and are very similar to XML and MIME respectively.  Hopefully, I'll find more rigor in the working draft.

Looking at the examples in the working draft, it appears that the crux of the issue is the use of a Content-Transfer-Encoding: binary header.  Unfortunately this header isn't defined — or even mentioned! — in any of the normative text of this working draft.

Or in any of the nine documents referenced by this draft.

However, in the ninth document, there are five documents referenced.  And in the fifth reference, is the explaination:

 encoding := "Content-Transfer-Encoding" ":" mechanism
 
 mechanism := "7bit" / "8bit" / "binary" /
              "quoted-printable" / "base64" /
              ietf-token / x-token
 
 ietf-token := <An extension token defined by a
                standards-track RFC and registered
                with IANA.>
 
 x-token := <The two characters "X-" or "x-" followed, with
             no intervening white space, by any token>

Checking IANA, it seems that no more have been officially registered, though realistically, there may be some experimental ones in popular use that need to be supported.  Figuring that others may have been down this road before, I check the Python libraries (as they happen to be handy and open source), and I find that they support the following:

Can you spot the one that is missing?  You guessed it, binary.

Exhausting.  After all of this, I am left with a few questions.

The more time I spend with specs, the more appreciation I get for Test-Driven Development.