datatracker.ietf.org
Sign in
Version 5.6.3.p2, 2014-09-29
Report a bug

Email Address Internationalization
charter-ietf-eai-06

Versions: 06
Charter for "Email Address Internationalization" (eai) WG
WG State: Concluded
Charter State:
Responsible AD: none

Send notices to: none
Last updated: 2006-03-02

Other versions: plain text

Charter charter-ietf-eai-06

The email address has two parts, local part and domain part.
  Email address internationalization must deal with both. This
  working group's previous experimental efforts investigated the
  use of UTF-8 as a general approach to email
  internationalization.  That approach is based on the use of an
  SMTP extension to enable the use of UTF-8 in envelope address
  local-parts, optionally in address domain-parts, and in mail
  headers.  The mail header contexts can include both addresses
  and wherever existing protocols (e.g., RFC 2231) permit the use
  of encoded-words.
  
  All WG deliverables specified under the original charter,
  particularly the experimental protocol specifications, have
  been completed.  The core specifications have been implemented
  and interoperability tests performed.  The WG is now being
  rechartered to permit advancing revised versions of those
  specifications and supporting documents into the standards
  track.
  
  As a result of implementation and testing experience, the WG
  has concluded to drop the model of in-transit
  downgrading that was a key part of the original effort.
  In-transit downgrading approaches simply do not work well
  enough and predictably enough to be worth the considerable
  additional complexity that accompanies them.  In particular,
  dropping in-transit downgrading eliminates the need for the
  first significant change to the syntax of an email address
  since RFC 821 and 822 were published in 1982.
  
  Work will therefore reflect a "no fallback" approach.  That
  approach provides a very minimal transition mechanism, but is
  consistent with the long-term view that email with invalid
  addresses or syntax should be rejected, rather than fixed up in
  transit between submission servers and delivery servers.
  Discoverable fallback addresses that could be applied before or
  during message submission or after SMTP "final delivery" may be
  investigated.  The WG may also develop other materials to give
  advice to implementers or operators.  Those efforts may lead to
  informational documents or best practices recommendations, but
  are considered independent of the core documents.  Work on them
  will progress only under the condition that it not delay the
  primary standards track specifications.
  
  The WG believes that the lessons learned from implementation
  and testing and removal of in-transit downgrading as a goal
  eliminates all major areas of controversy about the core
  specifications and should permit very rapid progress.  Such
  rapid progress is an explicit goal for the WG; issues resolved
  in the past will not be revisited unless those who wish to do
  so can demonstrate data, reasoning, or consequences that were
  not considered earlier.  At the same time, any attempt to
  significantly extend an established and widely deployed set of
  protocols may uncover new consequences or side effects that
  need consideration and evaluation.  If faced with a choice
  between spending time on such new considerations, the WG will
  favor getting things right over accelerating the schedule.
  
  Deliverables
  
  The following deliverables are foreseen in this charter. The WG
  chairs may (re)structure the deliverables into specific
  documents or document sets as needed. Adding or removing
  documents other than those listed below as "Required" or
  "Additional" will require a charter update.
  
  Required Documents (these are the "core specifications"
  referred to elsewhere)
  
  * Overview and Framework for Internationalized
    Email, replacing RFC 4952 (Informational or Proposed
    Standard at IESG discretion once complete)
  
  * UTF-8 SMTP extension specification, replacing RFC 5336
   (Proposed Standard)
  
  * Header format specification, replacing RFC 5335 (Proposed
   Standard)
  
  * Internationalized DSN specification, replacing RFC 5337
   (Proposed Standard)
  
  * UTF-8 POP specification, replacing RFC 5721 (Proposed
   Standard)
  
  * UTF-8 IMAP specification, replacing RFC 5738 (Proposed
   Standard)
  
  Additional possible documents suggested.  While milestones are
  listed for most of these documents, they may be dropped by the
  WG with the consent of the Responsible AD.
  
  * Advice for MUA implementors (Informational or BCP)
  
  * Advice for EAI deployment (Informational or BCP)
  
  * Advice for non-ASCII and ASCII addresses for the same mailbox
   (Informational or BCP)
  
  * Mailinglist (Informational or Standards Track, replacing
   draft-eai-mailinglist)
  
  * Mailto (Proposed Standard, updating draft-duerst-mailto-bis
   to reflect internationalized addresses)
  
  * Protocol extensions for RFC 4409 Submission Servers or
   configuration advice for the MUA->Submission server interface.