headers
Keld J|rn Simonsen | 4 Jan 1993 03:04
Picon

Re: Last Call: SMTP Extensions to Proposed Standard

Dear IESG, (this is a repost...)

I have some comments to the informational "transition" I-D,
that I would like to be honoured before it becomes an RFC.

IESG Secretary writes:

> 
> The IESG has received a request from the Internet Mail Extensions
> Working Group to consider the following Internet Drafts as a Proposed
> Standard. These documents are replacements for the Internet Draft "SMTP
> Extensions for Transport of Enhanced Messages" previously submitted to
> the IESG.

...
> 
> A companion document is intended to be published as an Informational RFC.
> 
>  o "Transition of Internet Mail from Just-Send-8 to 8Bit-SMTP/MIME"
>    <draft-ietf-smtpext-transition-01.txt>
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg <at> cnri.reston.va.us, or ietf <at> cnri.reston.va.us mailing lists by
> January 4th, 1993.
> 
> Greg Vaudreuil
> IESG Secretary

I posted the following comments (extract):
(Continue reading)

Permalink | Reply | 1 comment |
headers
Olle Jarnefors | 4 Jan 1993 23:11
Picon
Picon

Comments on draft-ietf-smtpext-transition-01.txt

Here are some comments, most of them editorial, on the Internet 
Draft "Transition of Internet Mail from Just-Send-8 to 
8Bit-SMTP/MIME" (December 16, 1992).

> Abstract
> 
>     Protocols for extending SMTP to pass 8 bit characters have been
>     defined. [3] [4] The messages transported by the extended SMTP are
>     required to be encoded in MIME. [1] [2]  Several SMTP implementations
                                +++++++++++++
Actually "MIME" is what is described in [1] only.  How to handle 
8bit characters in the RFC 822 header of an incoming message is 
an important problem, but it is not treated in this Internet 
Draft.  See also my last comment.  (The 8-bit extension 
document [4] has document [2] included in its list of 
references, but doesn't refer to it in the main text, which 
is somewhat peculiar.)

Consequently I think the reference to [2] in this abstract is 
misleading and should be removed.  Item [2] should be retained 
in the list of references though, since the discussion of trace 
information refers to it.

>     adopted an ad-hoc mechanism for sending 8 bit data prior to these
              +++++++++++++++++++
Change to "ad-hoc mechanisms".  There are more than one.  In 
Sweden for example an SMTP extension with negotiated 8-bit 
transport is in use since a couple of years, besides the 
"just-send-8bit" implementations from some vendors.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Vaudreuil | 4 Jan 1993 23:54
Picon
Picon

Re: Comments on draft-ietf-smtpext-transition-01.txt


Wow, Four pages of comments on a three page document!  Thanks for
taking the time to conduct such a solid review.  I will make an attempt to
get a new Internet Draft posted soon, and provided there is no
objections to the resulting edits I will ask the chair to ask the IESG
to consider the newer version for RFCdome.  If this looks like it will
take a while I will ask that it be un-bundled from the other SMTP
extensions documents.

>>     required to be encoded in MIME. [1] [2]  Several SMTP implementations
                                +++++++++++++
>Actually "MIME" is what is described in [1] only. 

Technically MIME is a single standard defined in two documents.  The
Header extensions are logically part of the same protocol.  They were
split early on because it was not clear that convergence on a headers
proposal was likely and there was pressure to finish MIME with or
without it.  Thanks to Keith Moore, it was finished with it.

>Finally I want to say that it's a pity that the handling of 
>8-bit data in message header fields isn't treated in this 
>document.

Hmmm, I did not realize that people were just-sending-8 bit text in
headers.  This is a notable shortcoming of this document that I will
attempt to address.

I will make an additional editing pass and run it by the Working Group.

Greg V.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 5 Jan 1993 02:57
Picon

Re: Last Call: SMTP Extensions to Proposed Standard

Keld,
   I've tried to review your comments, and, while I have looked at
Ran's comments, don't have quite as strong a reaction.  However, either
I'm missing an important technical point here, or I'm confused and 
need some clarification.
   Greg's document is oriented primarily to the situation in which
unannounced and undocumented 8bit arrives at an MTA (typically a relay)
that needs to do "something" with it.  Since sending unannounced 8bit is
an invalid case, this is behavior we are trying to stamp out, hence the
identification of this as a "transition" document.   It is not intended
as a general specification of how to intra-MIME gateways, e.g., how to
downgrade from 8bit MIME to 7bit MIME.  That material belongs in an
as-yet-unwritten gateway requirements document, or possibly in one or
more (also unwritten and un-signed-up-for) folklore or implementer
recommendations documents.
    In a very real sense, the cases labelled (5) in Greg's table really
fall outside the scope of this document, which talks (review the
"Problem" section) about non-compliant senders.   A sender that is
producing ESMTP/MIME is a compliant sender.  The problems that arise do
so only when mail in transit hits something non-compliant (or RFC821
compliant only).  We've dealt with that situation elsewhere: either the
mail is going to bounce or the sender is going to perform a valid
conversion to a different (MIME-valid) form.   Again, the range of
alternatives is known, and is part of the MIME domain (as is your RFC):
this document has nothing to add.
    In the transition area--the other cases--the applicability of
mnemonic is fairly restricted.  If I've got an intermediary with
sufficient out-of-band information to exactly identify the character
set, then most of the discussion above applies: there is adequate
information to make complete and stable MIME, MIME considerations apply,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keld J|rn Simonsen | 6 Jan 1993 00:52
Picon

Re: Last Call: SMTP Extensions to Proposed Standard

Hi John!

You write:
>    I've tried to review your comments, and, while I have looked at
> Ran's comments, don't have quite as strong a reaction.  However, either
> I'm missing an important technical point here, or I'm confused and 
> need some clarification.

I have not seen any comments from RAN, where did he post them to?
Could you mail me a copy?

Keld
Permalink | Reply | 0 comments |
headers
Keld J|rn Simonsen | 6 Jan 1993 02:58
Picon

Re: Last Call: SMTP Extensions to Proposed Standard

John C Klensin writes:

>    Greg's document is oriented primarily to the situation in which
> unannounced and undocumented 8bit arrives at an MTA (typically a relay)
> that needs to do "something" with it.  Since sending unannounced 8bit is
> an invalid case, this is behavior we are trying to stamp out, hence the
> identification of this as a "transition" document.  

>     In a very real sense, the cases labelled (5) in Greg's table really
> fall outside the scope of this document, which talks (review the
> "Problem" section) about non-compliant senders.   

The document as I read it talks about "transition" and that includes
both sending and recieving at non-MIME sites. It talks about 8-bit
transparant as well as RFC822 conforming sites, and indeed in (6)
also about fully MIME conformant sites. In essence it talks about
the process of transition from todays situation to an Internet world
of MIME compliant systems (MUAs/MTAs). And that is a very valid scope,
my customers would really like such advice.

> The problems that arise do
> so only when mail in transit hits something non-compliant (or RFC821
> compliant only).  We've dealt with that situation elsewhere: either the
> mail is going to bounce or the sender is going to perform a valid
> conversion to a different (MIME-valid) form.   Again, the range of
> alternatives is known, and is part of the MIME domain (as is your RFC):
> this document has nothing to add.

Well, I do not remember good recommendations of how to send mime-
compliant mail to non-mime sites. So this document does have advice
(Continue reading)

Permalink | Reply | 3 comments |
headers
John C Klensin | 6 Jan 1993 05:24
Picon

Inclusion of MNEM in the transition document

WG members (and Keld),
   My purpose in writing my earlier over-long note in response to Keld's
note was to try to identify the issues and one possible position that
neither ignored MNEN nor gave it strong endorsement.  My feeling that it
should not be strongly endorsed (Keld's original suggested text appeared
to me to constitute strong endorsement) rests on several factors:
  -- a desire to avoid anything that would require relay MTAs to have
deep MIME knowledge, consistent with my interpretation of the last sets
of conclusions reached in Washington and the general desire to minimize
complexity.  It is my belief (possibly incorrect) that the level of
knowledge required to recognize specific character sets, to ensure that
only appropriate character sets are converted that way, and to avoid
conversion of non-character material represents fairly deep MIME
knowledge, deeper than, e.g., knowing enough about the structures to
avoid creating nested encodings.
   -- the fairly explicit decisions by the 822 WG and IESG to separate
MNEM from the standards-track at that stage in its development
   -- a desire to leave the focus of the transition document as narrow
as possible, rather than beginning to slide material into it that
belongs in more general "mail gateway requirements" or "advice to
implementors of mail gateways" documents (anyone wishing to write those
should get in touch with Russ Hobby: they aren't "SMTP extensions").
    -- a personal bias that we don't to recommend techniques for
transitional/ conversion MTAs that include character conversion tables
whose nature requires that they be periodically updated to be fully
effective.  I don't have any particular objections to such things if
they are appropriate in some circumstance, but I do object to
recommending them.  The size of the tables and the number of cycles it
takes to look something up are not at issue here.  What is at issue is
an architectural preference for MTAs that need an absolute minimum of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Vaudreuil | 6 Jan 1993 20:41
Picon
Picon

Revised Transition Document


I have made many editorial changes to the transition document thanks
to the high quality editorial review provided by Olle Jarnefors.
Thanks!  I have also added a bit of wording to clarify the scope of
this document as being limited to gateway transformations of
just-send-8 to MIME.  General transition to MIME issues seem to be
more than can be addressed in the timeframe the WG seems to have for
this document (get-it-done-by-yesterday!)  

I have read the mail sent by Keld. This document makes no statement
about what is the preferred character set to use when the character
set in the untagged document is known out of band.  Comments to the
Working Group mailing list suggest that his useful suggestions are
part of a more general character set transition issue that are beyond
the limited scope of this document as are 7bit ISO-646 to MIME issues.

The only substantive change is the addition of header transformations
to RFC1342.  I did not realize while writing the earlier versions that
people were actually sending 8859-n characters in headers currently
and so did not consider the gateway implications.  The addition of
headers was strait forward and I do not expect this will be
controversial.

Please comment in the next 24-48 hours on this document if you really
have a problem with the changes.  I will re-post this to the Internet
Draft and send it to the IESG.  Because this is only information this
will not delay the consideration of the SMTP Extensions work.

Greg Vaudreuil
(Continue reading)

Permalink | Reply | 2 comments |
headers
Einar Stefferud | 7 Jan 1993 07:01

Re: Revised Transition Document

Good job Greg!  Here are some nitty suggestions...\Stef

was:     implementations adopted an ad-hoc mechanisms for sending 8bit data
propose: implementations have adopted ad-hoc mechanisms for sending 8bit data
                         ^^^^^^^^^^^^
was:      US-ASCII [5] characters.  At the Internet has grown to include
propse:   US-ASCII [5] characters.  As the Internet has grown to include
                                     ^

was:      octets.  It can represent any character set from any language, using
propose:  octets.  It can be used as a label for any character set from any
          language, using ^^^^^^^^^^^^^^^^^^^^^^

was:       any encoding.  It may not be further defined.
propose:   any encoding.  It must not be further defined.
			     ^^^^

was:       The use of the "unknown-8bit" is intended only by gateway agents
propose:   The use of the "unknown-8bit" label is intended only by gateway
           agents                        ^^^^^
Permalink | Reply | 0 comments |
headers
John C Klensin | 7 Jan 1993 12:07
Picon

Re: Revised Transition Document

Greg,
   The concepts are fine as far as I can tell.  Some sections are worded
a little awkwardly and would read better (I think) with a bit of
rearranging.  Specific suggestions appear below (anyone not interested
in editorial tedium can stop reading right here--there is very little
substantive in the rest of this note)...
   --john

Abstract:
    defined. [3] [4] The messages transported by the extended SMTP are
    required to be encoded in MIME. [1] [2]  Several SMTP
"The messages..." -> "These protocols require that the messages..." 
"are required to" -> ""
"Several" -> "Before work began on these protocols, several"

    implementations adopted an ad-hoc mechanisms for sending 8bit data
    prior to these standards and with which the extended SMTP mail
    system should interoperate.  This document outlines the problems in

"8bit data...interoperate." -> "8bit data.  It is desirable for the
extended SMTP environment and these ad hoc mechanisms interoperate."

2. The Problem
    private agreement on the use of a specific character set, without
    benefit of tagging, basic mail service can be provided.
"character set, without" -> "character set without"
and, maybe, delete "benefit of"

    In the transition to the negotiated 8bit system with MIME messages,
    it is important that mail sent by a currently non-conforming user
(Continue reading)

Permalink | Reply | 0 comments |

Gmane