Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/smtpext/smtpext-minutes-91nov.txt

Text File | 1993-02-17 | 23KB | 554 lines

CURRENT_MEETING_REPORT_



Reported by John Klensin/MIT

Minutes of the Internet Mail Extensions Working Group (SMTPEXT)

The meeting on the 19th was long, and very intense.  The result was a
narrowing of the focus on the transport extensions.  The meeting began
with Greg Vaudreuil introducing John Klensin and handing over the chair.
Klensin then announced that the Meta-Agenda for the day was to either
focus sufficiently that a clean plan and schedule could emerge or to be
able to report that the Working Group was going nowhere and should be
abandoned.


Klensin then introduced a decision model for the major options facing
the Working Group.  That model was refined somewhat in group discussion
and appeared as follows:



           Negotiate
      _____________________________________________________
      |               |                     |             |
     Yes             No              Can't decide     Decide not to
      |           ____|___________      _____|             |
    __|____      ?*    Prime     |      |                  |
    |      |         ___|__      |      |             ?    |
 RFCZZZZ  ?*       Prime   |     |      |<-----------------|
   bis               bis   |     |______|                  |
                     |    |         |                     |
                     v    v    Let 1k flowers             v
                     @    @       bloom            New protocol ?*
                                    @



Notation:



  ?* -> Need to make a plan

  @  -> Need to consider--or abdicate--damage control for ``old'' systems,
        especially wrt blowups  and  information loss.

  ``Prime'' refers both to the specific proposal from them and to the class
        of proposals who share the concept that existing ``8 bit clean/8 bit
        transmitting'' implementations are acceptable, should be encouraged,
        and should be joined by others.


                                   1





Considerable discussion ensued.  There was no sympathy expressed for the
sending of unnegotiated 8bit data as a long term strategy, but a general
understanding that it was undesirable to leave existing implementations
that do that without plausible transition paths.


The Working Group concluded that the receipt of data with the 8th bit
set but without negotiation was an error, and proceeded to analyse the
error states.  The conclusion was that an originating SMTP client was
non-conforming if it transmitted any data with the 8th bit set without
prior negotiation and agreement.  A destination server receiving such a
message could respond in one of three ways and be conforming:

         i. Reject the message as an invalid transport case, presumably
            using a 520 error code.

        ii. Deliver the message in 8bit form.  This option requires that
            the MTA ``know'' that such delivery can be accomplished
            accurately (i.e., without loss of information).  This would
            normally be the case when both delivery MTA and UA were in a
            ``8bit clean'' environment.

        iii.If sufficient information is available, downgrade the
            message to 7bit RFC-XXXX. Since the Working Group did not
            consider it acceptable to ``guess'' at what the character
            set might be, or to make an assumption based on, e.g., the
            sending or receiving country, the ``sufficient information''
            condition will in general be met only if the incoming
            message is already in valid RFC-XXXX format.



If a message with leading bits set arrives at a relay host without prior
negotiation, the relay has the additional option of transparently
forwarding that message.  The destination host is no worse off in this
case than it would be had the message been sent without the relay.  In
other words, the Working Group agreed that there was no significant
benefit in imposing additional requirements on relays for policing
protocol conformance.  Relays would, of course, retain the options of
rejecting or downgrading, as provided in (i) and (iii) above.


There was then general agreement that ``doing nothing'' was undesirable.
For some people, the above analysis was acceptable only if the Working
Group proceeded to define and agree upon a negotiation model; others
were convinced that the analysis and agreement was useful in itself.


The various large scale options of RFC-ZZZZ (6 Nov draft) were then
reviewed, with backward references to the pre-St.  Louis version of that
document.  The options of ``new protocol'' and ``move more rapidly
toward X.400'' were raised as alternatives, but quickly dismissed in the

                                   2





context of the current charge of the Working Group, since they do not
address the very real issues of existing 8bit transport over existing
ports and protocols.


The session on 21 November began with a review of an intermediate draft
of RFC-ZZZZ which Klensin had prepared to incorporate the changes agreed
to on the 19th.  The meeting then went through an interim ``outstanding
issues'' list (see Appendix A), eliminating many of the issues and
deferring others.  As one might expect, some issues were controversial,
others were not.  A review of the interactions between SIZE and the
capabilities concept introduced on Tuesday led to the partial
restoration of the former while retaining the latter.


The morning's greatest controversy was about exactly what requirement to
impose for the capability for conversion from 8bit to 7bit transport
forms in mail relays.  The issue is complex because it is seen by some
as an issue of keeping mail relays simple and, in particular, not
requiring that each one have gateway capability, and by others as an
issue of increased mail interoperability (or of avoiding decreased
interoperabiliy).  After lengthy and sometimes heated discussion, it was
agreed to adopt a rule designed to reduce as much as possible the chance
of deferred rejection of 8bit mail as a result of encountering an 8->7
boundary.  A host accepting 8bit mail is not permitted to have the mail
later rejected as a result of a conversion requirement.  This means, in
essence, that any host accepting 8bit mail must either be able to
guarantee (through out-of-band information) that it can make final 8bit
delivery to the addresses in the message, or must be prepared to arrange
for conversion to seven-bit form.  The Working Group understands that
the conditions for guaranteeing an unobstructed 8bit path can rarely be
met in practice and that this requirement means that a mechanism for
conversion to 7bit forms is therefore essentially a requirement of a
host that is implementing server support for EMAL. Probably the only
exception that does not depend on considerable out of band information
and very early verification of addresses would be for a server that
supported only local delivery, with no capability for relaying,
automatic forwarding, or providing mail exchanger services for other
hosts.


There was then a discussion of newly-written ``packetized data stream''
and ``binary'' proposals by Neil Katin.  The discussion of the former
was carried far enough to reach general agreement on a model:  sending
and acknowledgement (in a request-and-wait mode, paralleling DATA) of a
``packet mode'' command.  If that command is accepted, the sender can
send packetized streams of data using an introducing ``packet N''
command followed by N octet of data without regard to line lengths or
delimiters.  Each packet would be acknowledged by the server, but the
model is designed so that these acknowledgements can be handled
asynchronously by the client (permitting batching).  After each such
packet, the server would expect to receive either another ``packet N''
command; the ``packet 0'' command, indicating end-of-data; or RSET or

                                   3





QUIT. Lengths of packets would be as chosen by the sender.  The question
of need for a receiver-imposed maximum packet length was discussed.  It
was finally concluded that such sizes were not an issue given TCP
buffering capability; the issue will be revisited if anyone can identify
a case in which server-imposed restrictions are actually needed.


Agreement was reached in principle on incorporating packetized data
stream (as described above) and binary mail.  Joint work with the
822-extensions group to provide additional specifications for the
handling of error messages that must be mailed back to the sender
(rather than reported as part of the SMTP transaction).  These efforts
will be incorporated into RFC-ZZZZ if they converge rapidly enough and
are appropriate; otherwise they will be handled as separate documents.


Specific conclusions about RFC-ZZZZ were:



  1. There is, at present, no real demand for transport forms wider than
     8 bits or for addressing the issues such transport would cause.
     The question will be revisited when and if there is a requirement
     for such transport.

  2. It is important to clarify and establish an extension model for
     RFC821 now, even if no substantive changes were incorporated into
     that extension model.

  3. There is no demand for 8-bit versions of SOML and SAML, since it is
     unlikely that anyone would really want RFC-XXXX messages delivered
     directly to their screens.  An 8-bit version of SEND FROM is
     problematic, since such messages are typically transported without
     headers, leaving ambiguitites about the character set in use as
     soon as the characters are not clearly ASCII. If and when there is
     demand and a definition for an enhanced SEND, an extension can be
     proposed and considered.

  4. As a result of (1) and (3), the marginal ``cost'' of a new
     transport variation (e.g., binary or ESND) becomes one verb, not
     four verbs.  And, since there is willingness to defer
     extended-width (past 8) entirely and predict that it will not be
     needed, the complexities and additional states associated with the
     TYPE verb can be eliminated by getting rid of that verb.  This, of
     course, implies that EMAL limits the message being transported to
     being one in which ASCII (with a leading zero bit) can be
     successfully used in trace fields.  That does not appear to be a
     severe restriction in practice, regardless of the theoretical
     possibilities.

  5. While the concept of a SIZE inquiry is desirable, it was felt that
     several other inquiries may be useful also and that it was not

                                   4





    desirable to worsen the query-and-wait transaction model.
    Consequently SIZE (as an inquiry) is to be removed and replaced by
    a capability inquiry to which a server would return such
    information as what size messages were normally acceptable and what
    other options were supported in a canonical way.  The format of the
    canonical response awaits further definition, although there was
    sympathy for something of the attribute=value character.  There was
    also discussion about the implications of denial of the
    availability of a service without general agreement other than a
    client should not ``try anyway'' if some capability were explicitly
    denied.  There was also a discussion of the fact that some hosts
    might wish to avoid giving out `capability information as a
    security measure in order to avoid disclosing operating system or
    similar information.  This may imply that hosts should be able to
    respond to a capability request by explicitly asserting certain
    services, by explicitly denying them, or by providing no
    information (in which case the client would normally behave as if
    the inquiry had not been made).

 6. The SIZE verb, used to alert the server of the approximate size of
    a file that is about to be transmitted, is retained.  This verb
    serves two main purposes:  early rejection of large messages,
    rather than having to transmit them first and providing receivers
    some ability to prepare for large messages.  The latter may
    actually permit larger messages to be delivered.

 7. Additional text should be put into the document that explicitly
    identifies the results of experiments with existing servers
    relative to handling of unknown verbs and recommending behavior if
    commands are refused with syntax errors.

 8. The explanatory/discussion sections should be retained, although we
    may wish to start identifying those that are intended for a final
    document separately from those which are to be retained only during
    discussion.

 9. Support of EVFY is required of any server that supports EMAL and
    support of CPBL is required of any server that supports any
    enhanced capability (beyond those of SMTP). For the latter,
    ``support'' is defined as the ability to return useful information
    on which the client is expected to take action.  Mechanisms for
    CPBL responses that do not reveal information will be considered
    only if an explicit request or requirement is received from the
    security area.

10. While enhanced trace field capabilities and requirements are needed
    if enhanced mail features are not going to make it appreciably
    harder to identify and fix problems (it is already bad enough),
    that material will be removed to a separate document if agreement
    cannot be reached quickly enough.  The Working Group identified one
    specific concern, which is the need to bind conversion-tracing
    fields to RFC-XXXX body parts, not whole messages, since some
    conversions will be performed one body part at a time.  The

                                  5





     requirement for this body part header has been brought to the
     attention of the RFC-XXXX authors.

 11. The material on RSET and defining new FROM verbs is useful and
     should be retained.  Some textual improvements are needed.

 12. CPBL does not accept an argument; the use of one is a syntax error.


     The following issue is considered resolved unless new issues and
     alternatives are raised.  It differs from the above because, rather
     than being discussed at length, there has apparently been no
     interest in taking issue with it since the first version appeared
     in the first Internet Draft version of RFC-ZZZZ.

 13. The model for which error/response codes are used in various
     situations.  The placeholder for this has been changed to a
     ``tentative agreement'' paragraph.


Summary, Schedule, and Plan.


After discussion with the Applications Area Director and the IETF Chair,
we should plan on requesting that RFC-ZZZZ be promoted to proposed
standard status not later than the end of the March IETF meeting.  It
appears after the November 1991 Working Group meetings that there are no
show stopper issues remaining (if this is not the case, people should
identify them as soon as possible).  There are several issues for which
options, details, or explicit text still need to be worked out.  Any of
those that cannot be worked out and agreed upon by March will be removed
from RFC-ZZZZ and handled separately.


A new version of RFC-ZZZZ has been prepared and is being submitted for
publication as an internet draft.  Note that this version supercedes the
one announced on the list and circulated to the 21 November Working
Group meeting.


John C. Klensin Chair, SMTP Extensions Working Group
[e-mail]


APPENDIX A


Outstanding issues, RFC-ZZZZ-02.  20 November 1991

The list that follows was used as the Agenda for the 21 November Working
Group session.


                                   6





Note:  Most of the issues below have been resolved.  The resolutions are
discussed in the main body of the Minutes.  Those that have not been
resolved appear, in one form or another, as ``open issues'' in the
working draft document and/or in the ``action item list'' that appears
as Appendix B. The list below is included with the Minutes because it
documents the progress, direction, and process of the Working Group
during the Santa Fe meeting.



  1. Should the remaining discussion paragraphs be retained somewhat
     longer or removed at this time?  (general)

  2. Fixing error codes (end of section 1A, 11.2).


  3. Should EVFY be required of systems that support this protocol?  Is
     it adequately specified?  (3ii and 6)

  4. Should support for CPBL be required of servers that support this
     protocol?  Is that a reasonable name?  Is refusal to supply
     information an error or just a special case of a ``1yz'' message?
     (3iii and 7).

  5. Should the material on trace fields be retained?  Is it ok?  In
     particular, is it desirable to identify the gateway or other
     processor that is making changes but to explicitly try to avoid
     specifying the nature of the transformation?  Are special
     considerations introduced when multiple body parts are converted
     separately?  (3iv, 3v, and 9).

  6. Is the material on RSET necessary and/or useful?  (3vi, 10).

  7. Mechanism for defining and registering new FROM verbs (5.2).

  8. Is there any possible reason to prohibit any possible ``conversion
     prohibited always'' cases?  Should this be called out?  (5.2).

  9. BINARY (5.1)

 10. CPBL/SIZE (7).  Eliminating SIZE as an inquiry prevents a server
     from setting up special buffers, allocation sizes, or space to
     receive a message of a particular large-ish size.  That forecloses
     the ``I can accept larger messages if I know they are coming''
     cases.  Is this what we intend?

 11. CPBL (7).  Prohibited argument?

 12. CPBL (7.1) Format of reply.

 13. CPBL - client behavior (7.2).  Is this what we want?  In

                                   7





     particular, is the model of behavior when the server indicates that
     a particular option is not available the one intended?

 14. Trace fields:  Needs to be checked against and updated to current
     RFC-XXXX (9).

 15. ``With smtp''.  Use for both 7 and 8 bit forms?  (end of 9).

 16. Is the restriction rule on servers accepting EMAL FROM and then
     rejecting an address correctly stated (11.1)?

 17. Return of error messages over irreversible path.  Do we need a
     ``Content-type:  bogus'' in RFC-XXXX, or is returning without the
     original message text acceptable?  (11.1)

 18. Is the requirement for support of downgrading in relays correctly
     stated (11.4.2)?  I think we do not want to discourage people from
     implementating relays on small machines or constrained
     environments.



APPENDIX B


Remaining outstanding issues and action items as of 22 November 1991.


Note that some additional issues are flagged in the draft as ``tentative
decision'' or ``open issue''.  The difference between these two
categories is that the former will be considered resolved unless someone
objects prior to the third Internet-Draft version of RFC-ZZZZ.


Some issues below are labelled ``default decision''.  This identifies
the approach that will be taken if timely agreement cannot be reached.



  1. Syntax for CPBL responses, especially for size information (section
     7, volunteer sought)

  2. Extensions to RFC-XXXX to support per-body-part trace/conversion
     information (Freed).

  3. Text and description for ``packet mode'' (Katin) Default decision:
     Defer

  4. Text and description for ``binary'' (Katin) Default decision:
     Defer


                                   8





  5. Mechanism and model for IANA registrations of things that must meet
     complex definitional criteria as a prerequisite for registration.
     Procedure for getting approval for IANA to assume this role.  (IESG
     problem:  Vaudreuil)

  6. Open Issue:  The CPBL functionality gives us a way to explicitly
     specify how further extensions beyond those of this document
     (including ``private'' ones) might be tested.  In addition to
     possibly the usual words about ``X''s, we could *require* that the
     attempted use of any verb not specified in a standard or
     near-standard RFC must be preceeded by the use of CPBL to verify
     that the server supports it.  My bias that being explicit reduces
     later problems makes a small argument for including some text to
     this effect.  Anyone who feels strongly one way or the other should
     speak up.  Default decision:  Defer (punt)

  7. Extensions/Mechanisms for formatted error messages when such
     messages are mailed back.  There are really two separate problems
     here:  an encapsulation model (RFC-XXXX extension) for returning
     the content of 8bit messages over 7bit channels and a canonical
     representation and taxonomy for mailed error responses.  Note that
     these are primarily RFC-XXXX problems; RFC-ZZZZ mostly just needs
     to point to the solution.  (Freed, Klensin, others sought).  Also
     note that not solving the encapsulation problem implies non-return
     of content in some cases.  Default decision:  If agreement cannot
     be reached, the language in RFC-ZZZZ that permits non-return of
     content in some cases will be strengthened.  The canonical mesage
     form problem is one we have been living with since before RFC 821
     and is not on the critical path for RFC-ZZZZ.

  8. Tentative decision:  People should review the new SIZE, rewritten
     to reflect the presence of CPBL, and complain if they don't like it
     and want to propose specific changes.



Attendees

Mary Artibee             [e-mail]
Nathaniel Borenstein     [e-mail]
James Conklin            [e-mail]
Mark Crispin             [e-mail]
Peter DiCamillo          [e-mail]
Erik Fair                [e-mail]
Ned Freed                [e-mail]
Olafur Gudmundsson       [e-mail]
Russ Hobby               [e-mail]
Christian Huitema        [e-mail]
Neil Katin               [e-mail]
John Klensin             [e-mail]
Jim Knowles              [e-mail]
Vincent Lau              [e-mail]
Eliot Lear               [e-mail]

                                   9





Gordon Lee               [e-mail]
Jack Liu                 [e-mail]
Paul Milazzo             [e-mail]
Keith Moore              [e-mail]
Robert Morgan            [e-mail]
Chris Myers              [e-mail]
Mark Needleman           [e-mail]
Michael Newell           [e-mail]
Daniel Newman            [e-mail]
Michael Patton           [e-mail]
Robert Purvy             [e-mail]
Robert Shirey            [e-mail]
Keld Simonsen            [e-mail]
Ursula Sinkewicz         [e-mail]
Gregory Vaudreuil        [e-mail]



                                  10