Re: Questions about RFCs 1494, 1495.

Ned Freed <> Tue, 07 June 1994 16:24 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa14243; 7 Jun 94 12:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14239; 7 Jun 94 12:24 EDT
Received: from by CNRI.Reston.VA.US id aa29598; 7 Jun 94 12:24 EDT
Received: from SIGURD.INNOSOFT.COM by with SMTP (PP) id <>; Tue, 7 Jun 1994 18:12:45 +0200
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HD8T9YUZHS96W8QW@SIGURD.INNOSOFT.COM>; ) id <Tue, 7 Jun 1994 09:12:13 PDT
Date: Tue, 07 Jun 1994 08:58:56 -0700 (PDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <>
Subject: Re: Questions about RFCs 1494, 1495.
In-reply-to: Your message dated "Tue, 07 Jun 1994 08:29:21 -0700" <>
Cc: Ned Freed <>,,
MIME-version: 1.0
Content-type: text/plain; CHARSET=ISO-8859-1
Content-transfer-encoding: 7BIT

> >(4) I tried it using the second form first in my original draft. It was truly
> >    horrible!

> To me, this is the most persausive argument of all.

> The only reasonable counter-argument is that, for User Agents, filtering out a
> small number of headers is easier than filtering a large number of headers.  I
> remember when the first X.400 gateways joined the net, and there was much fuss
> in the Usenet comp.mail.* groups from Admins that were having to run all over
> and help their users add 40 lines of filters to their .mailrc files.

This is a point I hadn't considered at all -- very tacky. However,
consideration of it leads me to the opposite conclusion!

I suffered for years without a user agent on VMS that could properly deal with
controlled header display. I always saw every single header, regardless. It was
just the way the software (VMS MAIL) worked.

Eventually we wrote our own user agent from scratch (PMDF MAIL) to fix this as
well as many other problems. In doing so we added support for selective display
of headers. I now have very precise control of all sorts of things, including
how many of a given header I see by default, how they are ordered, use of
various sorts of emphasis for selected headers, and so on. I can do this on a
personal basis, system-wide, or for selected groups of users. It is all very
flexible. (We may have gone overboard a bit after so many years of
deprivation... You know how it is...)

However, this control is all on a per-header basis. The handling of the actual
data inside of a header is fairly generic (RFC1522 support). Adding control of
the display of individual fields within a header would be difficult. Not
impossible, since I'd have access to a parser in any case, but difficult.

Now, I see some of the Content- headers that I'd want to have displayed by
default, like Content-Pathname. Others I could care less about, such as all the
access control stuff. (I have no idea what such access control information
would mean in any case. Its form isn't suitable for establishing defaults on
any system I've ever seen. But I digress.) File dates, well, maybe, maybe not.

The point is I'd like to be able to use the existing features we worked so
hard to implement to control how this information is displayed. In addition,
I'm sure customers will be after us to support such selective displays.

> The difficulty would be finding a useful grouping for the complex headers, so
> that users could filter out the noise while preserving things they want.
> Filtering out a bunch of new headers may be tedious, but in most user agents
> extracting one argument from a complex stream is impossible.

Exactly my point.