RFC: Content-Encoding and Serialization

[email protected] (Stephen Adkins)
Newsgroups perl.p5ee
Message-ID <[email protected]>
Hi,

This is an informal request for comments.

One can imagine any number of possible serialization
algorithms and subsequent scalar transformations to
convert an arbitrary Perl data structure into a scalar
for storing and/or sending across the network.

  i.e. Storable + Digest::HMAC_MD5 + Crypt::CBC + 
       Compress::Zlib + MIME::Base64

However, if this blob is transmitted across a network,
must the recipient know what serialization to expect?
Or is it reasonable to encode at the front of the
serialized data what algorithms were used to serialize
it? (retorical question... the answer is yes)

Although this is not HTTP, I propose the following
scheme (which I will be implementing in the
P5EEx::Blue::Serializer set of classes).

If a serialized blob of data is to be tagged with
its encoding schemes, prepend the blob with the
following text line like an HTTP header.

   Content-Encoding: x-storable, x-digest-hmac_md5(mktg),
x-crypt-cbc(2002-01-01), x-gzip, base64

 1. This scheme is familiar to people who know HTTP and could potentially
    be paired with "Accept-Encoding" functionality.
 2. Use standard strings ("x-gzip" and "base64") already defined in the
    HTTP spec where they exist.  Otherwise, use a modification of
    the perl package name to indicate the encoding step.
 3. Allow for options to the encoding scheme in parentheses
    (Both Digest::HMAC_MD5 and Crypt::CBC require that a secret
    key be supplied.  An arbitrary string such as "mktg" or
    "2002-01-01" can indicate which secret key to use.
    It is *not* the secret key itself, of course.)

Any comments?

Stephen
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.