home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / smtpext / smtpext-minutes-91june.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  5.2 KB  |  163 lines
  1.  
  2.  
  3.                     Minutes of the June 21
  4.                       SMTP extensions working group.
  5.  
  6. Attendees
  7. ---------
  8.  
  9. Phill Gross              pgross@nis.ans.net
  10. Peter Svanberg           psu@nada.kth.se
  11. Byungnam Chung           bnchung.sokri.etra.re.kr
  12. Bob Kummerfeld           bob@ca.pn.oz.au
  13. Jonny Eriksson           bygg@sunet.se
  14. Jan Michael Rynning      jmr@nada.kth.se
  15. Keld Simonsen            keld.simonsen@dkuug.dk
  16. Greg Vaudreuil           gvaudre@nri.reston.va.us
  17.  
  18. Agenda
  19. ------
  20.  
  21. 1) 8 Bit Transport
  22.  
  23.    - Overview of current status
  24.  
  25.    - Review of current proposals
  26.      o Negotiated 8 bit support
  27.      o Unnegotiated 8 bit support
  28.      o Use of 7 bit transport with encoding
  29.  
  30.    - Discussion: Which is the preferred proposal?
  31.  
  32. 2) Mail Enclave Issues
  33.  
  34.    - Local use of non-standard practices: Real problem or not?
  35.      o Non-standard or non-support of transfer encodings
  36.      o Local use of non-standard character sets
  37.  
  38.    - Define Enclaves
  39.      o Administratively limited?
  40.      o Universal mesh of capabilities?
  41.  
  42. Minutes
  43. -------
  44.  
  45. 1) 8 Bit Transport Issues
  46.  
  47.    Much discussion has occured both on the mailing list and in private
  48. with the chairman calling into queston the conclusions the smtpext
  49. working group reached during the St. Louis IETF in March 91. This
  50. issue was raised at this Copenhagen meeting to reconsider or reaffirm
  51. the conclusions the working group at that earlier meeting.  There
  52. continue to be two credible proposals for transition to 8 bit
  53. transport.  Th first is a proposal to redefine the SMTP protocol to
  54. standardize the existing practice sending 8 bit mail over standard
  55. SMTP channels.  The second is a proposal send 8 bit textual data after
  56. negotiating that capability.
  57.  
  58.      The working group review the two proposals and came to the
  59. following understandings about the proposals.  A third "proposal", do
  60. nothing, was evaluated as well.
  61.  
  62. a) Redefine SMTP to pass 8 bit data.
  63.  
  64. The proposal stems from the existing practice of sending 8 bit data
  65. between SMTP implementations without negotiation or confirmation of
  66. the capabilities of the receiver.
  67.  
  68. Benefits
  69. --------
  70.  
  71.      - It works (Mostly)
  72.      - Easy modification to existing code to gain functionality
  73.      - Currently deployed by several vendors, and tested  extensively in
  74.     current mail environments.
  75.  
  76. Costs
  77. -----
  78.  
  79.    - There is no assurance that the message was delivered as intended.
  80.    - Use of C1 codespace may be compromised.
  81.    - Not functionally compatible with many current SMTP          
  82.      implementations.
  83.      
  84. Discussion
  85. ----------
  86.    - The extensions have been extensively tested in a "friendly"environment
  87.      where character sets sent have not used C1 codespace for graphic
  88.      characters, nor have multi-byte characters been sent.
  89.    - Some unpredictable behavior has been noted.
  90.    - The costs are continuing, they never go away.
  91.  
  92.  
  93.  b) Negotiate the sending of 8 bit data
  94.  
  95. Benefits
  96. --------
  97.  
  98.    - Backwards compatible with current conforment implementations.
  99.    - Failure is detectable, and recovery by encoding and resending is
  100.      possible
  101.    
  102. Costs
  103. -----
  104.  
  105.    - Not compatible with some (much?) current deployed software
  106.    - Failure recovery after negative negotiation potentially complex
  107.    - Code changes are more complex
  108.  
  109. Discussion
  110. ----------
  111.  
  112.    - The costs of the transition are one time, and will fade away with time.
  113.  
  114. c) Send no 8 bit data
  115.  
  116. Benefits
  117. --------
  118.  
  119.    - The hassle of upgrading current transport is unneeded
  120.    - All functionality is supported through encoding
  121.  
  122. Costs
  123. -----
  124.    - Encoding required additional resources including computer time as well
  125.      as communications bandwidth
  126.    - Local users may use 8 bit transport anyway.
  127.  
  128. Discussion
  129. ----------
  130.  
  131.    - The technical analysis of this issue is but a small part in the problem. 
  132.      There is a strong feeling, almost religion,among site administrators and
  133.      many "users" that encoding data that is easily transportable of the
  134.      network infrastructure is wasteful, inelegant, and just plain wrong.
  135.  
  136.  
  137. d) Conclusions
  138.  
  139.    The attendees of this meeting reaffirmed the working group
  140. consensus that standard for the transmission of 8 bit characters
  141. without negotiation has costs which were too in terms of expected mail
  142. performance to be acceptable.  The main points underscoring this
  143. conclusion was the inability to "know" the transaction was successful,
  144. and the effective loss of the ability to use C1 codespace in future
  145. character sets intended to be transportable over SMTP.  While it was
  146. noted that much experience has been gathered with current
  147. implementations using un-negotiated 8 bit mail, it was understood that
  148. this experience was gathered in a relatively homogeneous environment
  149. with friendly character sets.  Problems were expected by the working
  150. groups in general application in the Internet and in sending
  151. characters sets like IBM PC codepages which use C1 codespace.
  152.  
  153. 2) Enclave Issues
  154.  
  155.  
  156. The working group felt that the concept of enclaves was not something
  157. that had to be defined.  Specifically, the idea that enhanced
  158. capabilities should be confined to a administrative or geographical
  159. region was seen as being too restrictive.  The attendees preferred to
  160. maintain the end to end model of electronic mail, rather than
  161. formalize the concept of autonomous mail domains.
  162.  
  163.