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