[I reply to a bunch of different people in this message]
I think this is important to make clear:
Implementing the headers does not mean we can't also use the MIME idea.
(or any other idea that might come up)
Brad Knowles <brad@his.com>wrote
> Ken does have one inescapable point -- all this automation and
> improvement of interaction with MLMs should be done through a new
> MIME bodypart type, and not through headers
As I said in some other messages, MIME is not a deployable solution at this
time. Far too few clients support MIME at all - and those that do would
require upgrading to properly recognize and handle a specialized MIME
object. Not to mention the difficulties in upgrading listservers to
generate the new MIME parts.
> I recommend you get the Internet Mail Consortium involved in
> these efforts, since Paul Hoffman and Dave Crocker have been down a
> lot of the same roads in the past on other projects,
I've already been corresponding with Paul who has been providing me with
some useful recommendations. Hopefully I can talk him into adding this list
to his no-doubt overflowing in box...
> MUAs that don't support
> new MIME bodypart types are *precisely* the same ones that are least
> likely to support different user-added headers.
But headers don't cause the problems for those clients that specialized
MIME parts do. Headers also don't wind up as an unwanted clutter of
separate files in download folders (which is what happens with some of the
MIME enabled clients).
> Given that, you're better off not hobbling all MUA and MTA
> implementations world-wide with a backwards-looking solution that
> will be, at very best, only partially successful. Instead, you're
> better off pointing to a forward-looking solution that may have some
> problems in the short term, but which will give you infinitely more
> flexibility in the future.
The point of this proposal is to reduce existing problems - not create new
ones. Using MIME parts now will add problems.
Certainly we need to be designing for the future, but we also need to solve
the problems that we have today. The headers will reduce the problems we
have today. As software improves, MIME objects (or whatever else emerges)
may be able to eliminate these problems in the future.
> And there's nothing stopping you from implementing a new type of
> message (either manual or machine-generated) using the same syntax as
> is used in the new MIME bodypart type, but which is left all by
> itself without MIME encapsulation/encoding.
That is something we should definitly be looking at. What we define in the
more advanced syntax should not be defined by it's transport mechanism
(MIME encapsulation, ASCII message, etc.) but should instead be structured
so that it can be deployed through multiple mechanisms depending on the
circumstance.
It may make sense to have the protocol communicated through a MIME object,
or a plaintext message, or a web page, or even a telephathic uplink (who
knows what the future brings... ;-)
The URLs we're presently using can be deployed anywhere. All the headers do
is provide meta-data about what the specific function of the URL is. A MIME
part could take the same URLs and present them as:
Help: <help url>
Unsubscribe: <unsubscribe url>
etc...
> In fact, you're better of specifying this first, and then saying
> "okay, you take a message of type Slarty Bartfast and you encapsulate
> it in MIME by making the Content-type "application/SMMP, etc...".
Personally, I'd like to see the mime-type be something like
"meta/list-control" since it's metadata we're presenting. But that's
jumping ahead a bit...
Joshua D. Baer wrote:
> Are you suggesting that we move this info to a standard footer added to the
> body? That might not be such a bad idea, since mail clients could parse it
> or it could be left for people to read. It's a less restricted text area,
> as well.
Not a bad spot for initial deployment. As MIME gets adopted, the protocol
data could then be MIME deployed.
> However don't many people find footers on mailing list mail
> offensive/annoying? They never bothered me much, but I've heard others
> complain.
People will complain no matter what is done. If you have the extra protocol
info in your list messages, they'll complain about the 'extra' info. If you
don't, they'll complain about not being able to find the unsubscribe
command (or use the wrong syntax which gets posted to the list resulting in
complaints from other subscribers).
With this whole protocol being prescribed as optional, we can use the key
statement of the internet: "If you don't like what I'm offering, give me
useful suggestions or try somewhere else (or roll your own!)"
James Berriman wrote:
> >One of the biggest reasons, IMHO. This is actually implementable in the
> >short term.
...
> Unless, as Stan (I believe) pointed out, you are using listserv. Actually, I
> suspect the number of list admins who can easily add custom headers is in a
> minority.
Perhaps, but if list software authors come on board (as some already are),
things may become very easy for admins to implement the headers.
> On the other hand, some will find it easy to add a mime attachment (perhaps
> simply as a message footer - a common feature on lists I subscribe to).
Again, it will be up to the individual list admins - but I recommend
deployment of such MIME objects at this time. They will generate new
problems for end users who we're trying to make things easier for.
Since the core headers are pretty much resolved (there doesn't seem to
remain any debate on the syntax - just whether headers are a good idea or
not), I think we can move on to working on defining the more comprehensive
syntax as well as deployment mechanisms.
Currently, I see the following deployment mechanisms:
MIME object (whether as part of a mail message or retrieved via http, etc.
maybe a header could point to the http retrieval?)
ASCII footer (on mail messages)
ASCII message (requested by the client when needed, or delivered by the
list server at subscribe time or when updated)
James Berriman wrote:
> I suspect that the
> most flexible long-term approach is a minimal set of standard list headers,
> combined with a new MIME type.
Bang on. I think this is what we need to do.
> perhaps the
> Ultimate Question to Life, the Universe and Everything is: "How many
> headers were included in God's final message to his creation?".
!!! We can all die fulfilled now. The universe has figured itself out :-)
Jason L Tibbitts III wrote:
> That would be reserved for the extreme
> bogosity of having to make every message a MIME multipart thing and incur
> all of the baggage that goes along with that. A message that was plain
> text with no MIME crud should stay that way unless a gateway has to encode
> it. A message that is a single part should stay a single part if at all
> possible.
To me, this is all leading to the need for more intelligence on the part of
server and client apps.
List servers should be able to determine, on an individual basis, whether
users accept certain mail features (MIME, UUencode, HQX encode, PGP MIME,
etc.), and send mail with the best set of features for that user.
Of course, that raises issues of no longer sending identical messages to
all members of a list, costing more bandwidth.
--
gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*>
"I'm an extremist for tolerance." - jms (creator/producer/writer of Babylon 5)
Follow-Ups:
|
|
