Subject: Re: draft-vaudreuil-esmtp-binary2-03.txt
From: [email-masked]
To: Dan Kohn <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 23 Oct 2000 09:15:23 -0700 (PDT)
List-Id: <ietf-822.imc.org>

> First, nice effort on this I-D.  One question:

>      Note that at the time of this writing there are no mechanisms for
>      converting a binary MIME object into an 8-bit MIME object. Such a
>      transformation will require the specification of a new MIME content-
>      transfer-encoding.

> Why can't the gateway descend the nested MIME tree, converting each binary
> body part to 7bit base64, except for text entities, which can be confirmed
> to be valid 8bit entities, unless they have more than 1000 characters per
> line, in which case they can be base64 encoded?

It can, but this is beside the point. The point here is that if you have binary
material there is at present no encoding that turns true binary material into
true 8bit material. Both quoted-printable and base64 output materal in the 7bit
range, not in the 8bit range.

There is some potential that encoding(s) which output 8bit will be defined
eventially so keeping the option open seems like a good idea.

It is of course possible to convert a message that contains a mixture of binary
and 8bit parts into one that at most contains 8bit parts. But there's no path
from real binary to real 8bit.

> This is probably a lot more
> trouble than it's worth, but doesn't it constitute a valid binary->8bit
> gateway?

Yes, but the note doesn't say that there aren't valid binary->8bit gateways, it
says that there's no encoding that has a binary input domain and an 8bit output
range. I really don't think this is at all unclear.

> As it stands, the paragraph seems at odds with this note from RFC 2048:

>    IMPORTANT:  The standardization of a large numbers of different
>    transfer encodings is seen as a significant barrier to widespread
>    interoperability and is expressely discouraged.  Nevertheless, the
>    following procedure has been defined to provide a means of defining
>    additional transfer encodings, should standardization actually be
>    justified.

I see no conflict here. Definition of additional encodings is discouraged but
it isn't prohibited. Indeed, there's a procedure in place for doing it. If
we didn't want new encodings we would not have defined such a procedure.

The point of the section was that there needs to be a really good reason
for new encodings. In the case of binary->8bit, the potential size
savings may be worth it.

> Am I correct in supposing that folks are unlikely to support any new
> transfer encodings at this point?

Not necessarily. The big issue with new encodings is how you can tell whether
or not a given destination can handle them. Work such as RESCAP has the
potential to provide this sort of information in a standardized way. And
it is also possible to use out of band information for this sort of thing.

See draft-freed-newenc-00.txt for some examples of at least two encodings
that may get standardized at some point.

				Ned

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Dan Kohn <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: draft-vaudreuil-esmtp-binary2-03.txt
Date: Mon, 23 Oct 2000 10:20:17 -0500
Sender: [email-masked]

The textual contents should not have been encoded in Binary. They should
labled as either 7-bit or 8-bit as appropriate.  If the textual component
could have been represtended as 8-bit, it should have been.  If it was
labeled as 8-bit textual data, there is no need to downconvert it when
transversing the nexted multipart.  BDAT binary transport can be used to
transport all transport encodings, not just binary.

As for new content-transfer-encodings, I agree no new encodings are likely
for applications where there are existing if less effecient alternatives.
If a net-new application is pioneered for which there is not an installed
base, there would be little barrier to using a new content-transfer-encoding
with it.  If I packaged MIME content-type: Smell/stinky into
content-transfer-encoding: compressedbinhex, there would be no net-loss of
interoperability. 

Greg V.

-----Original Message-----
From: Dan Kohn [mailto:[email-masked]]
Sent: Monday, October 23, 2000 9:42 AM
To: [email-masked]
Cc: [email-masked]
Subject: draft-vaudreuil-esmtp-binary2-03.txt

First, nice effort on this I-D.  One question:

     Note that at the time of this writing there are no mechanisms for
     converting a binary MIME object into an 8-bit MIME object. Such a
     transformation will require the specification of a new MIME content-
     transfer-encoding.

Why can't the gateway descend the nested MIME tree, converting each binary
body part to 7bit base64, except for text entities, which can be confirmed
to be valid 8bit entities, unless they have more than 1000 characters per
line, in which case they can be base64 encoded?  This is probably a lot more
trouble than it's worth, but doesn't it constitute a valid binary->8bit
gateway?

As it stands, the paragraph seems at odds with this note from RFC 2048:

   IMPORTANT:  The standardization of a large numbers of different
   transfer encodings is seen as a significant barrier to widespread
   interoperability and is expressely discouraged.  Nevertheless, the
   following procedure has been defined to provide a means of defining
   additional transfer encodings, should standardization actually be
   justified.

Am I correct in supposing that folks are unlikely to support any new
transfer encodings at this point?

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

From: Dan Kohn <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: draft-vaudreuil-esmtp-binary2-03.txt
Date: Mon, 23 Oct 2000 07:42:07 -0700
Sender: [email-masked]

First, nice effort on this I-D.  One question:

     Note that at the time of this writing there are no mechanisms for
     converting a binary MIME object into an 8-bit MIME object. Such a
     transformation will require the specification of a new MIME content-
     transfer-encoding.

Why can't the gateway descend the nested MIME tree, converting each binary
body part to 7bit base64, except for text entities, which can be confirmed
to be valid 8bit entities, unless they have more than 1000 characters per
line, in which case they can be base64 encoded?  This is probably a lot more
trouble than it's worth, but doesn't it constitute a valid binary->8bit
gateway?

As it stands, the paragraph seems at odds with this note from RFC 2048:

   IMPORTANT:  The standardization of a large numbers of different
   transfer encodings is seen as a significant barrier to widespread
   interoperability and is expressely discouraged.  Nevertheless, the
   following procedure has been defined to provide a means of defining
   additional transfer encodings, should standardization actually be
   justified.

Am I correct in supposing that folks are unlikely to support any new
transfer encodings at this point?

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

To: [email-masked]
Xref: clerew local.mime:460
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mail header registry?
Date: Thu, 19 Oct 2000 09:20:22 GMT
Lines: 43
Sender: [email-masked]

In <p05001900b613064073f9@[130.237.150.139]> Jacob Palme <[email-masked]> writes:

>Very strong requirements   ^  Only headers from published IETF standards.
>                            |
>                            +  Only headers approved by a thorough vetting
>                            |  procedure.
>                            |
>                            +  Only headers accepted by a vetting procedure
>                            |  similar to that for new Content-Types.
>                            |
>Very lenient requirements  v  All reasonable proposals accepted.

>Arguments for strong requirements: Avoid badly defined headers
>to get into the registry.

>Arguments against strong requirements: New headers would not get
>into the registry, because of the difficulty in getting them
>registered. And no large harm is done by adding a header which
>never succeeds, there are lots of synonyms to use. For example,
>suppose the registry register a badly defined "Obsoletes", IETF
>can then define a better defined header, and call it "Replaces"
>or "Supersedes". The badly designed header can stay in the
>registry, possibly with a note saying that its use is not
>recommended.

I think you just follow existing IANA practice. You get them to set up a
"booking" mechanism that reserves the name of some header on a temporary
basis while an RFC is being prepared. I believe you can already get
provisional port number allocations in this way.

But the main and permanent registry should only hold headers than have
appeard in standards-track or experimental protocol published RFCs.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

Date: Wed, 18 Oct 2000 10:00:39 +0200
To: Graham Klyne <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Mail header registry?
Cc: [email-masked]
Sender: [email-masked]

At 08.04 +0100 0-10-14, Graham Klyne wrote:
>Specifically, I would like there to be an XML namespace URI 
>associated with an IANA registry for RFC822 headers.  From this, 
>according to RDF URI-construction rules, would follow a URI for each 
>header in the registry.
>
>So, yes:  I think Jacob's 1998 draft would form a good starting 
>point for such a registry.  I think I'd focus more on simply 
>creating a single registry of header field names and references to 
>definitions, and slightly less on trying to categorize different 
>flavours of header field.  If there's a consensus that this is a 
>Good Thing, I'll undertake to review and comment on Jacob's draft 
>with a view to moving it towards a registry BCP.
>
>I also think that Jacob's mail header summary draft would be a good 
>starting point for initially populating the registry.  The 
>registration template might be tuned with an eye to information that 
>is readily available in this draft, so that the initial 
>registrations are easily constructed.

The controversy when this was discussed years ago was what
requirements one should put to include a header field name
in the registry.

Very strong requirements   ^  Only headers from published IETF standards.
                            |
                            +  Only headers approved by a thorough vetting
                            |  procedure.
                            |
                            +  Only headers accepted by a vetting procedure
                            |  similar to that for new Content-Types.
                            |
Very lenient requirements  v  All reasonable proposals accepted.

Arguments for strong requirements: Avoid badly defined headers
to get into the registry.

Arguments against strong requirements: New headers would not get
into the registry, because of the difficulty in getting them
registered. And no large harm is done by adding a header which
never succeeds, there are lots of synonyms to use. For example,
suppose the registry register a badly defined "Obsoletes", IETF
can then define a better defined header, and call it "Replaces"
or "Supersedes". The badly designed header can stay in the
registry, possibly with a note saying that its use is not
recommended.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked]
Xref: clerew local.mime:458
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Mail header registry?
Date: Mon, 16 Oct 2000 09:01:14 GMT
Lines: 36
Sender: [email-masked]

In <[email-masked]> Graham Klyne <[email-masked]> writes:

>I just surfed to the IANA site expecting to find of registry of mail 
>message headers (per rfc822, etc), only to find none.

>FWIW, I think:

>(a) such a registry would be a Good Thing

>(b) MIME headers should be in the same registry, as they occupy the same 
>collision domain in mail messages

Yes, tbis is an excellent idea, except that it should include News and
even HTTP headers as well.

Essentially, for any given header, one needs to know
	a) Which RFC(s) define it
	b) Whether that RFC is a standard (proposed/draft/full) or an
	   experimental protocol
	c) Which protocols is is used with (mail, news, etc).

Note that (c) may not be hard and fast, since there is a general
expectation that news headers can appear in mail and vice versa, and
should be ignored when they turn up in the "wrong" environment, unless the
RFCs make specific provision for a meaning in both.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: Jacob Palme <[email-masked]>, [email-masked]
Subject: Re: Mail header registry? 
Date: Sun, 15 Oct 2000 20:38:07 -0400
Sender: [email-masked]

> There is a proposal being kicked around to create a URN namespace for IANA
> registries and values.

this strikes me as the most bizarre misuse of URNs that I've ever heard of
(and  I've seen several bizarre proposals)

Keith

Date: Sat, 14 Oct 2000 08:04:17 +0100
To: Jacob Palme <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Mail header registry?
Cc: [email-masked]
Sender: [email-masked]

Jacob, and all,

Maybe I should be a little clearer about why I ask.

There is a proposal being kicked around to create a URN namespace for IANA 
registries and values.  I am also working on a proposal for RCC822-in-XML, 
which leverages a putative IANA registry URN for RFC822 headers.  I was 
somewhat surprised to not find an existing IANA registry when I looked.

Specifically, I would like there to be an XML namespace URI associated with 
an IANA registry for RFC822 headers.  From this, according to RDF 
URI-construction rules, would follow a URI for each header in the registry.

So, yes:  I think Jacob's 1998 draft would form a good starting point for 
such a registry.  I think I'd focus more on simply creating a single 
registry of header field names and references to definitions, and slightly 
less on trying to categorize different flavours of header field.  If 
there's a consensus that this is a Good Thing, I'll undertake to review and 
comment on Jacob's draft with a view to moving it towards a registry BCP.

I also think that Jacob's mail header summary draft would be a good 
starting point for initially populating the registry.  The registration 
template might be tuned with an eye to information that is readily 
available in this draft, so that the initial registrations are easily 
constructed.

#g
--

At 09:20 PM 10/13/00 +0200, Jacob Palme wrote:
>I wrote an ietf draft on a mail header registry some years'
>ago. The interest was rather lukewarm, but if I could
>send it in again and ask the area managers to evaluate it.
>
>You can find links to the proposal I wrote at
>http://dsv.su.se/jpalme/ietf/jp-ietf-home.html#registry
>
>The closest thing which exists to such a registry is
>the document you can find links to at
>http://www.dsv.su.se/jpalme/ietf/mail-headers/
>
>It was published as an RFC many years ago,
>the page above has links to a much updated version,
>which I should send in for publication as a new
>RFC.

------------
Graham Klyne
([email-masked])

Date: Fri, 13 Oct 2000 21:20:09 +0200
To: Graham Klyne <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Mail header registry?
Cc: [email-masked]
Sender: [email-masked]

At 12.36 +0100 0-10-13, Graham Klyne wrote:
>Hi all,
>
>I just surfed to the IANA site expecting to find of registry of mail 
>message headers (per rfc822, etc), only to find none.
>
>Is there such a registry?  Should there be?
>
>If there is/was such a registry, should MIME headers be in the same 
>registry, or a different one?
>
>FWIW, I think:
>
>(a) such a registry would be a Good Thing
>
>(b) MIME headers should be in the same registry, as they occupy the 
>same collision domain in mail messages
>

I wrote an ietf draft on a mail header registry some years'
ago. The interest was rather lukewarm, but if I could
send it in again and ask the area managers to evaluate it.

You can find links to the proposal I wrote at
http://dsv.su.se/jpalme/ietf/jp-ietf-home.html#registry

The closest thing which exists to such a registry is
the document you can find links to at
http://www.dsv.su.se/jpalme/ietf/mail-headers/

It was published as an RFC many years ago,
the page above has links to a much updated version,
which I should send in for publication as a new
RFC.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: Graham Klyne <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Mail header registry? 
Date: Fri, 13 Oct 2000 14:28:27 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]

See RFC 2076 and draft-palme-mailext-headers-03.txt.  Although there
is no such on-line registry, IANA believes (or did believe based on
mail with Jon Postel a few years ago) that it was its job to register
such headers.

Donald

PS: Consider also news and http headers...

PPS: I assume that by MIME headers you mean new values for * in
content-*.  There certainly are IANA on-line registries for
content-types, etc., values.

From:  Graham Klyne <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Fri, 13 Oct 2000 12:36:25 +0100
To:  [email-masked]
Content-Type:  text/plain; charset="us-ascii"; format=flowed
Sender:  [email-masked]

>Hi all,
>
>I just surfed to the IANA site expecting to find of registry of mail 
>message headers (per rfc822, etc), only to find none.
>
>Is there such a registry?  Should there be?
>
>If there is/was such a registry, should MIME headers be in the same 
>registry, or a different one?
>
>FWIW, I think:
>
>(a) such a registry would be a Good Thing
>
>(b) MIME headers should be in the same registry, as they occupy the same 
>collision domain in mail messages
>
>#g
>--
>
>------------
>Graham Klyne
>([email-masked])
>

Date: Fri, 13 Oct 100 17:04:47 WET DST
From: Johnny Eriksson <[email-masked]>
To: [email-masked]
Subject: Re: Mail header registry?
Sender: [email-masked]

> Hi all,
> 
> I just surfed to the IANA site expecting to find of registry of mail 
> message headers (per rfc822, etc), only to find none.
> 
> Is there such a registry?  Should there be?

Might be a good idea.  I have previously toyed with the following:

$ORIGIN mailheader.arpa.
Received	IN	TXT	"RFC822"
>From		IN	TXT	"RFC822"

;etc.

Unless it is totally unthinkable to store non-trademark stuff in
the DNS...

> Graham Klyne
> ([email-masked])

--Johnny

Date: Fri, 13 Oct 2000 12:36:25 +0100
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Mail header registry?
Sender: [email-masked]

Hi all,

I just surfed to the IANA site expecting to find of registry of mail 
message headers (per rfc822, etc), only to find none.

Is there such a registry?  Should there be?

If there is/was such a registry, should MIME headers be in the same 
registry, or a different one?

FWIW, I think:

(a) such a registry would be a Good Thing

(b) MIME headers should be in the same registry, as they occupy the same 
collision domain in mail messages

#g
--

------------
Graham Klyne
([email-masked])

From: [email-masked]
Date: Thu, 05 Oct 2000 18:12:14 -0700 (PDT)
Subject: Re: draft-khanna-smtp-mail-transfer-reliability-00.txt
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 	On Thu, 05 Oct 2000 10:07:31 -0400
> 	Keith Moore <[email-masked]> said...

> >
> > SMTP does have problems over slow links - mostly due to the large number
> > of round-trips.  PIPELINING helps a lot for those who implement it.

> It does if the modem drops the link after 900K of a 1M message :-( .

Then by all means use the checkpoint/restart extension defined in RFC 1845.
It already exists and addresses exactly this problem.

				Ned

Date: Thu, 5 Oct 2000 19:34:44 +0100 (BST)
From: Charles Lindsey <[email-masked]>
Reply-To: Charles Lindsey <[email-masked]>
Subject: Re: draft-khanna-smtp-mail-transfer-reliability-00.txt 
To: [email-masked]
Content-MD5: IcsxTXWPlmT1m7QqAUY20Q==
Sender: [email-masked]

	On Thu, 05 Oct 2000 10:07:31 -0400
	Keith Moore <[email-masked]> said...

> 
> SMTP does have problems over slow links - mostly due to the large number
> of round-trips.  PIPELINING helps a lot for those who implement it.

It does if the modem drops the link after 900K of a 1M message :-( .

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: draft-khanna-smtp-mail-transfer-reliability-00.txt 
Date: Thu, 05 Oct 2000 10:07:31 -0400
Sender: [email-masked]

SMTP does have problems over slow links - mostly due to the large number
of round-trips.  PIPELINING helps a lot for those who implement it.

Note however that this is really only significant for short messages -
for long messages the amount of time consumed in DATA (for which the
SMTP overhead is negligible) outweighs any time consumed by EHLO/MAIL/RCPT
round-trips.

Keith

To: [email-masked]
Xref: clerew local.mime:448
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-khanna-smtp-mail-transfer-reliability-00.txt
Date: Thu, 5 Oct 2000 10:17:08 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> Graham Klyne <[email-masked]> writes:

>But I wonder if there isn't a real problem out there in parts of the world 
>where Internet bandwidth is considerably less plentiful and reliable than 
>most of us have come to expect.  Mobile devices would be another case in point.

People who dial up on slow telephone lines is another case in point
(though such people tend not to use SMTP directly).

>I think the interesting nugget in this draft is the idea that an SMTP 
>client may request retransmission of a partially transmitted message in a 
>new SMTP session, and if the server is prepared to continue a previous 
>transaction it provides information about the point from which 
>retransmission should continue.

The HTTP Protocol (RFC2616) has a feature (the Range: header) for handling
transmission of parts of files, though browsers (well certainly Netscape)
do not seem to use it. I am currently hacking some Perl to use this
feature in downloading large documents

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

Date: Wed, 04 Oct 2000 09:41:11 -0700
To: Graham Klyne <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: draft-khanna-smtp-mail-transfer-reliability-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 12:55 PM 10/4/00 +0100, Graham Klyne wrote:
>But I wonder if there isn't a real problem out there in parts of the world 
>where Internet bandwidth is considerably less plentiful and reliable than 
>most of us have come to expect.  Mobile devices would be another case in point.
>
>I think the interesting nugget in this draft is the idea that an SMTP 
>client may request retransmission of a partially transmitted message in a 
>new SMTP session, and if the server is prepared to continue a previous 
>transaction it provides information about the point from which 
>retransmission should continue.

Indeed.  But I thought that RFC 1845, SMTP Service Extension for 
Checkpoint/Restart, attacked that problem, though it is not used widely.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Date: Wed, 04 Oct 2000 12:55:55 +0100
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: draft-khanna-smtp-mail-transfer-reliability-00.txt
Cc: [email-masked]
Sender: [email-masked]

Folks,

re: draft-khanna-smtp-mail-transfer-reliability-00.txt

My first thought was to dismiss this draft as simply ignoring existing work 
(RFC 1830), and tackling a marginal problem (bandwidth saving for large 
messages).

But I wonder if there isn't a real problem out there in parts of the world 
where Internet bandwidth is considerably less plentiful and reliable than 
most of us have come to expect.  Mobile devices would be another case in point.

I think the interesting nugget in this draft is the idea that an SMTP 
client may request retransmission of a partially transmitted message in a 
new SMTP session, and if the server is prepared to continue a previous 
transaction it provides information about the point from which 
retransmission should continue.

The final point I note is that an extension along these lines does not need 
to be widely deployed to be useful.  Logically, it would be used between 
servers in areas of poor quality bandwidth, with messages routed 
appropriately using MX records.

#g
------------
Graham Klyne
([email-masked])