W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Content-Transfer-Encoding

From: Marc VanHeyningen <marcvh@spry.com>
Date: Wed, 26 Jul 1995 15:12:14 -0700
To: "Phillip M. Hallam-Baker" <hallam@w3.org>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <2181.806796734@pellet.spry.com>
> I prefer that a protocol be faithful unto itself. Either be human
> readable or let us lose with ASN.1 BER or something like it. There is
> no point in half measures one way or the other.

Yes, this makes sense.  Inventing YApacketization scheme seems silly unless
we really feel all existing ones are clearly unsuitable.

> There are a number of binarry encodings with worse overhead, ASN.1 DER
> for example.

?  Not sure what you're hinting at here...

> 3) Encryption
> Please remeber that people will want to encode streams using block
> ciphers. This requires provision for specifying the number of padding
> octets. Note that PEM style padding cannot be used since is creates a
> security problem when used for repeated numbers of small packets. It
> is essential that this padding be random bytes.

I see this as a problem unrelated to packetizing data so you can tell where
the end is.

> 4) On a fixed upper limit on the packet size.
> This is not an acceptable proposal.

I'd like to see arbitrary limits removed to the extent that it's possible;
that's one of the things I dislike most about SSL's record layer
(particularly since SSL adds so much per-record overhead) and I'd like to
see that mistake not get repeated.

- Marc
Received on Wednesday, 26 July 1995 15:15:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC