home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
smtpext
/
smtpext-minutes-91june.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
5KB
|
163 lines
Minutes of the June 21
SMTP extensions working group.
Attendees
---------
Phill Gross pgross@nis.ans.net
Peter Svanberg psu@nada.kth.se
Byungnam Chung bnchung.sokri.etra.re.kr
Bob Kummerfeld bob@ca.pn.oz.au
Jonny Eriksson bygg@sunet.se
Jan Michael Rynning jmr@nada.kth.se
Keld Simonsen keld.simonsen@dkuug.dk
Greg Vaudreuil gvaudre@nri.reston.va.us
Agenda
------
1) 8 Bit Transport
- Overview of current status
- Review of current proposals
o Negotiated 8 bit support
o Unnegotiated 8 bit support
o Use of 7 bit transport with encoding
- Discussion: Which is the preferred proposal?
2) Mail Enclave Issues
- Local use of non-standard practices: Real problem or not?
o Non-standard or non-support of transfer encodings
o Local use of non-standard character sets
- Define Enclaves
o Administratively limited?
o Universal mesh of capabilities?
Minutes
-------
1) 8 Bit Transport Issues
Much discussion has occured both on the mailing list and in private
with the chairman calling into queston the conclusions the smtpext
working group reached during the St. Louis IETF in March 91. This
issue was raised at this Copenhagen meeting to reconsider or reaffirm
the conclusions the working group at that earlier meeting. There
continue to be two credible proposals for transition to 8 bit
transport. Th first is a proposal to redefine the SMTP protocol to
standardize the existing practice sending 8 bit mail over standard
SMTP channels. The second is a proposal send 8 bit textual data after
negotiating that capability.
The working group review the two proposals and came to the
following understandings about the proposals. A third "proposal", do
nothing, was evaluated as well.
a) Redefine SMTP to pass 8 bit data.
The proposal stems from the existing practice of sending 8 bit data
between SMTP implementations without negotiation or confirmation of
the capabilities of the receiver.
Benefits
--------
- It works (Mostly)
- Easy modification to existing code to gain functionality
- Currently deployed by several vendors, and tested extensively in
current mail environments.
Costs
-----
- There is no assurance that the message was delivered as intended.
- Use of C1 codespace may be compromised.
- Not functionally compatible with many current SMTP
implementations.
Discussion
----------
- The extensions have been extensively tested in a "friendly"environment
where character sets sent have not used C1 codespace for graphic
characters, nor have multi-byte characters been sent.
- Some unpredictable behavior has been noted.
- The costs are continuing, they never go away.
b) Negotiate the sending of 8 bit data
Benefits
--------
- Backwards compatible with current conforment implementations.
- Failure is detectable, and recovery by encoding and resending is
possible
Costs
-----
- Not compatible with some (much?) current deployed software
- Failure recovery after negative negotiation potentially complex
- Code changes are more complex
Discussion
----------
- The costs of the transition are one time, and will fade away with time.
c) Send no 8 bit data
Benefits
--------
- The hassle of upgrading current transport is unneeded
- All functionality is supported through encoding
Costs
-----
- Encoding required additional resources including computer time as well
as communications bandwidth
- Local users may use 8 bit transport anyway.
Discussion
----------
- The technical analysis of this issue is but a small part in the problem.
There is a strong feeling, almost religion,among site administrators and
many "users" that encoding data that is easily transportable of the
network infrastructure is wasteful, inelegant, and just plain wrong.
d) Conclusions
The attendees of this meeting reaffirmed the working group
consensus that standard for the transmission of 8 bit characters
without negotiation has costs which were too in terms of expected mail
performance to be acceptable. The main points underscoring this
conclusion was the inability to "know" the transaction was successful,
and the effective loss of the ability to use C1 codespace in future
character sets intended to be transportable over SMTP. While it was
noted that much experience has been gathered with current
implementations using un-negotiated 8 bit mail, it was understood that
this experience was gathered in a relatively homogeneous environment
with friendly character sets. Problems were expected by the working
groups in general application in the Internet and in sending
characters sets like IBM PC codepages which use C1 codespace.
2) Enclave Issues
The working group felt that the concept of enclaves was not something
that had to be defined. Specifically, the idea that enhanced
capabilities should be confined to a administrative or geographical
region was seen as being too restrictive. The attendees preferred to
maintain the end to end model of electronic mail, rather than
formalize the concept of autonomous mail domains.