Great Circle Associates List-Managers
(February 1997)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: MailList Specification Headers Proposal 0.0.9
From: Grant Neufeld <gneufeld @ ccs . carleton . ca>
Date: Tue, 18 Feb 1997 00:48:48 -0500
To: list-managers @ GreatCircle . COM, list-header @ arpp . carleton . ca
In-reply-to: <199702180229 . VAA07457 @ Thinkage . On . CA>

Ken Dykes wrote:
> more i think about the more the friendly letters MIME pop infront of my eyes.

Very interesting idea - I like it.

However, I don't think the client software is sufficiently equipped to
handle MIME objects like that yet (soon I hope). Consider the negative
reaction to the deployment of the PGP MIME objects (a good idea in my
opinion, unfortunately the software isn't equipped to handle it)

> this ill conceived (imho) proposal will only be made even more ill if
> implemented as simple headers in the mail message.

Well, I won't take that personally - especially since you are adding some
useful points like this MIME suggestion (which has a LOT of potential in
the future when MIME is properly supported).

>   a) body parts are much more amenable to authentication and perhaps even
>      encryption (hey, why rule out the concept of a 'secure' MLM?)

Hmmm, sounds good to me. But, again, we're not there yet in terms of MIME

>   b) body parts are much more likely to pass unscathed through legacy-code
>      (and vendor-obstinate) mail gateways

But not through mail clients which either don't understand MIME, or end up
dumping unrecognized mime types into files somewhere in the user's file
system (which can lead to a lot of meaningless files as in the PGP MIME

>   c) presentation control information and rich text stuff does not belong
>      in the general headers.
>      this proposal is nothing more than a richtext language specific
>      to mailing list administration functions.

I disagree. It's about communicating command structures to client software
in a clear and specific syntax.

It is also being designed to be at least partially human readable (in as
much as URLs are human readable) for users who do not have list header
aware clients (everybody at the moment, but hopefully soon a lot fewer

>    d) while claiming to try an not do so, this proposal is simply BULKING UP
>       the headers.

"An important consideration in this discussion is avoiding adding a tonne
of new headers..." The proposal does add some headers, but we're trying to
minimize the number added. You may keep it down to zero on your lists, if
that's what you think is appropriate.

>       and no matter how 'unbulky' you start with, this stuff is bound to
>       be extended in the future.  keep bulk in the body.

Not a usable option at this time. When it is we can implement it.

As to future extensions, (as I've said too many times already in this
message) they will hopefully lead to MIME (or whatever is the most useful
choice at the time) when that becomes usable.

> keep it out of the headers.

Nope. At least not my headers.

> encapsulate it.
> make the encapsulation the last MIME body part for friendliness to
> older email client programs. (or rather, dont insist it be the first part).

Makes sense to me. I look forward to being able to actually implement it.

Oh, yeah. The other big reason for using headers is that they're easy for
the majority of list managers to implement where as something like MIME
objects will require changes to the list server applications.

gneufeld @
 ccs .
 carleton .
 ca  grant @
 kagi .
 com  O-  <*>

Indexed By Date Previous: Re: MailList Specification Headers Proposal 0.0.9
From: Brad Knowles <brad @ his . com>
Next: Re: MailList Specification Headers Proposal 0.0.9
From: Brad Knowles <brad @ his . com>
Indexed By Thread Previous: Re: MailList Specification Headers Proposal 0.0.9
From: Ken Dykes <kgdykes @ Thinkage . On . CA>
Next: Re: MailList Specification Headers Proposal 0.0.9
From: Brad Knowles <brad @ his . com>

Search Internet Search