Re: New Internet Draft: draft-duerst-archived-at-00.txt

Bruce Lilly <blilly@erols.com> Fri, 29 October 2004 14:25 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEPuBe083892; Fri, 29 Oct 2004 07:25:56 -0700 (PDT) (envelope-from owner-ietf-822@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TEPu8W083891; Fri, 29 Oct 2004 07:25:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-822@mail.imc.org using -f
Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEPt8T083882 for <ietf-822@imc.org>; Fri, 29 Oct 2004 07:25:56 -0700 (PDT) (envelope-from blilly@erols.com)
X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication
X-Trace: lwTzEcYOAduNdUuN4XTn3Dz9PaHeWFIEVOAjtOp4nBI=
Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CNXhV-0004kh-00; Fri, 29 Oct 2004 10:25:57 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i9TEPoq9026959(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Fri, 29 Oct 2004 10:25:51 -0400
Received: from localhost (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i9TEPnFY026958(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Fri, 29 Oct 2004 10:25:50 -0400
From: Bruce Lilly <blilly@erols.com>
Reply-To: ietf-822 <ietf-822@imc.org>, Martin Duerst <duerst@w3.org>
Organization: Bruce Lilly
To: ietf-822 <ietf-822@imc.org>
Subject: Re: New Internet Draft: draft-duerst-archived-at-00.txt
Date: Thu, 28 Oct 2004 22:46:04 -0400
User-Agent: KMail/1.7.1
Cc: Martin Duerst <duerst@w3.org>
References: <5.1.0.14.2.20040223213340.031150a8@127.0.0.1> <20041027203430.780c6c4f.moore@cs.utk.edu> <6.0.0.20.2.20041028151627.0527c288@localhost>
In-Reply-To: <6.0.0.20.2.20041028151627.0527c288@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200410282246.05068.blilly@erols.com>
Sender: owner-ietf-822@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:ietf-822-request@imc.org?body=unsubscribe>

On Thu October 28 2004 02:39, Martin Duerst wrote:
 
> It's probably only partially useful for email clients. Indeed Bruce
> Lilly makes a rather good point that it is not useful at all for
> email clients (he however makes the mistake of thinking that
> email clients are everything that counts).

To be precise, I pointed out some limited use for MUAs.  Focus on
MUAs was based on the fact that the field is defined as a structured
field and has no defined uses for other agents and/or protocols
(MSAs, MTAs, MDAs, filters, access protocols).

> It's very useful for 
> humans. Is there a rule that email headers have to be used by
> email clients?

Structured fields (as far as RFC 2822's definition of structured
vs. unstructured fields is concerned) are primarily used by
message handling programs (not only clients, but e.g. IMAP
servers, MTAs, Sieve filtering language (RFC 3028), etc.).
Fields intended to be used only by humans are generally
unstructured (again, in the RFC 2822 sense), e.g. Subject,
Comments, Content-Description.  So if it had been clear back
in February that the intent was solely for human use, we
could have avoided a lot of syntax discussion and the field
could have been defined as unstructured; or we could have
arrived then where we are today, with the suggestion that
any existing mechanism for conveying human-readable
non-protocol content could be used, without having to
invent "Yet Another Header Field".

> As an example, how much is the X-Mailer: header 
> used my email clients?

Well, it's not a standardized field... as such it has no
specified uses, semantics, or syntax.  As a user-specified
field (RFC 822, fields beginning with "x-"), any use is
subject to and dependent upon agreement between
cooperating parties.
 
>  >and at least some
>  >email clients are already able to download files using http and/or
>  >ftp.
> 
> But that's just files in general, yes? Or is is message/rfc882 in
> particular? And if the later, what clients would that be?

MIME is used with the HTTP protocol as well as with RFC [2]822
message format.  As such, HTTP can be used to transfer content
of any MIME media type, including message/rfc822.  Although
it has been elided from the current version of the FTP specification,
the FTP protocol did have specific commands (MAIL and MLFL)
for message transfer; these have been superseded by message-
specific transfer protocols, viz. MTP, SMTP (introduction of
which predated dropping of the message-specific FTP commands
by several years) and more recent variations such as POP,
IMAP, and NNTP.