[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

more side-grist for the mill



------- Forwarded Message

Return-Path: kankkune@cs.Helsinki.FI
Received: by nsl.pa.dec.com; id AA15747; Wed, 20 Feb 91 18:55:27 -0800
Received: by decpa.pa.dec.com; id AA03404; Wed, 20 Feb 91 12:08:24 -0800
Received: by keos.Helsinki.FI (4.1/SMI-4.1/34-keos)
	id AA11755; Wed, 20 Feb 91 14:03:44 +0200
Date: Wed, 20 Feb 91 14:03:44 +0200
From: kankkune@cs.Helsinki.FI (Risto Kankkunen)
Message-Id: <9102201203.AA11755@keos.Helsinki.FI>
In-Reply-To: Dave Crocker's message as of Feb 19, 10:20
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: Dave Crocker <dcrocker>
Subject: Re: Need for successive encodings

> What is the purpose of allowing nested encodings?

I think it would be more reasonable to register a set of nestable
conversions instead of a set of combinations of those.

Sometimes you want to compress your data, sometimes to encode, sometimes
do the both. It would seem simpler to register identifiers for say
uuencode, compress, wp-documents, ws-documents and gif-pictures rather
than register an identifier for uuencoded-compressed-wp-document,
uuencoded-wp-document, uuencoded-compressed-ws-document,
uuencoded-ws-document and uuencoded-gif-picture. (Not probably a good
example, but I think you get the point.)

Also, it isn't any easier for the receiver's program to parse a header
like

   Content-type: uuencoded-compressed-wp-document

than a header like

   Content-type: uuencode, compress, wp-document

I would say the latter would be easier for the reader to parse and
execute the relevant programs to unpack the message.

Risto

- -- 
 Risto Kankkunen                   kankkune@cs.Helsinki.FI (Internet)
 Department of Computer Science    kankkunen@finuh          (Bitnet)
 University of Helsinki, Finland   ..!mcsun!uhecs!kankkune   (UUCP)

------- End of Forwarded Message