- 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
> 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