EAI Next Steps: moving forward with POP, IMAP, and associated downgrade models

WG participants,

My last note covered the status of the documents we have
approved but that are not yet published.    This one is an
attempt to summarize where we are --and, more important, what
people should be doing-- going forward (starting now).

With the core documents out of the WG's hands, people should
turn their attention to the POP, IMAP, and downgrade sets,
including examining the current documents.  The WG and authors
of the IMAP and POP documents should think about how to modify
those documents to accommodate multiple downgrade models, some
of which might still be unspecified when the POP and IMAP
documents are published.

We are also looking for an I-D on the stripped-down downgrade
option suggested by Arnt, John Leslie, and others and for
author(s) for an I-D on the pseudo-DSN for "you don't get this
message until you upgrade" option.   As I indicated in an
earlier note, I think those two, plus an updated version of
pop-imap-downgrade, would form the core of the new strategy.
That strategy is a hypothesis, not a conclusion: those with
other ideas should speak up.

Anyone who believes the WG needs a formal consensus call on
moving in the direction of multiple downgrade options should say
so (private notes to Joseph and/or myself would be sufficient;
if it is desired, I'd prefer to just do a consensus call rather
than spend time debating whether or not it is necessary).

Question about AUTH48 text for 5336bis/ proto-RFC 6531

Hi.

We have encountered a small problem at AUTH48 with some text in
5336bis (RFC-to-be 6531).  The text in Section 3.2 of
draft-ietf-eai-rfc5336bis-16 (just before the numbered list)
reads:

	"Instead, if a UTF8SMTPbis-aware SMTP client
	"(UTF8SMTPbis-aware SMTP sender) attempts to transfer an
	internationalized message and encounters an SMTP server
	that does not support the extension, it MUST make one of
	the following three choices and the priority order is 1, 2
	and 3." 

The last part of that sentence was added in response to a Last
Call comment.  If there is a moral here, it is that folks
should be really careful with changes in response to even
seemingly-editorial comments made during Last Call.  In any
event, "the priority order is 1, 2 and 3" is ambiguous as to
whether the WG thinks choice 1 or choice 3 should come first.

But it is a little worse than that because, in trying to fix
this, we discovered that the phrasing of those three choices
may not have been quite right.  In particular, the third case
seemed to contradict a very carefully-worded exception case in
RFC 5321.

To be clear what we are talking about before I outline what I
think are the options and ask for a decision, the current
AUTH48 working text reads (please don't worry about spacing):

Determine for EAI to meet at IETF83 or not

All,

I made a session request for EAI at upcoming IETF (see attached).  However, it's likely that John and I would
not be in Paris.  I would like to ask who will go to Paris, and what issues are the WG facing that we need a face to
face meeting to resolve.  Having a meeting or not will be determined by attendance and issues at hand.  If
there will be meeting in Paris, then I will ask for volunteers to help hosting the session.

Regards,
Joseph, co-chair EAI

From: IETF Meeting Session Request Tool <session_request_developers <at> ietf.org>
Subject: eai - New Meeting Session Request for IETF 83
Date: 2012-01-30 21:52:45 GMT

A new meeting session request has just been submitted
by Joseph Yee, a working group chair of eai.

---------------------------------------------------------
Working Group Name: eai
Area Name: Applications Area
Session Requester: Joseph Yee

Number of Sessions: 1

keyword announcement for 'UTF8SMTPbis'

All,

The chairs reviewed possible new keywords with the WG Secretary and AD.  We explored several possibilities
and came to conclusion that the new keyword should be 'SMTPUTF8'.

This keyword shares the similar (or the same) characteristics from the keyword chosen with WG consensus in
experimental phase.  It's specific on the character encoding and the protocol.  Other possible choice of
words (and keywords) have issues of either being too generalized or too specific which could mean
something else.

Should you have a substantive objection, i.e., one that you considered to be a show stopper rather than just
a preference, please reply to this email **no later than Thursday 9:00am US Eastern and describe your
concerns**.  Unless there are such objections, the new keyword notification will be forwarded to the RFC
Editor and IANA.

Best Regards,
Joseph Yee and John Klensin, EAI Co-chairs

Protocol Action: 'Overview and Framework for Internationalized Email' to Proposed Standard (draft-ietf-eai-frmwrk-4952bis-12.txt)

The IESG has approved the following document:
- 'Overview and Framework for Internationalized Email'
  (draft-ietf-eai-frmwrk-4952bis-12.txt) as a Proposed Standard

This document is the product of the Email Address Internationalization
Working Group.

Please note that an earlier revision of this document was already
approved by the IESG for publication as Informational. As a result of
IESG comments during IESG Evaluation of two other EAI documents, the WG
felt that they needed to make changes to this document and change its
status to Standards Track from Informational. It has now been approved
as a Propsed Standard.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/

Technical Summary

   Full use of electronic mail throughout the world requires that
   (subject to other constraints) people be able to use close
   variations on their own names (written correctly in their own
   languages and scripts) as mailbox names in email addresses.
   This document introduces a series of specifications that define
   mechanisms and protocol extensions needed to fully support
   internationalized email addresses.  These changes include an
   SMTP extension and extension of email header syntax to
   accommodate UTF-8 data.  The document set also includes

IETF 82 EAI Minutes uploaded

All,

Minutes for IETF82 uploaded.  Available at URL below:
http://www.ietf.org/proceedings/82/minutes/eai.txt

Text also available below

Joseph

-----------

Minutes of the EAI working group
IETF82, Taipei, TW
2011-11-15 13:00 

The chairs called the meeting to order, reminded everyone about the
IPR rules and displayed the Note Well notice.  

They then started an overview of the status of the working group.

John Klensin explained some normative-reference problems in the WG
set, and the Area Director clarified.  It appears these issues are
getting sorted out.  Assuming this does proceed as expected, the core
protocol documents are complete.

The room accepted the agenda as posted, and substantive issues were
undertaken.

The WG turned to the POP3 document (5721bis-02).  The editor claimed
that it was ready for WGLC.  The Chair initiated WGLC in the meeting,

UTF8SMTPbis

_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima

draft-klensin-encoded-word-type-u-00

Hi.

One of John Levine's comments about the mailinglist document and
some issues with pop-imap-downgrade have convinced me that there
is a problem with the use of encoded words in strings that users
are expected to see and work with that we might actually know
how to fix.   

Historically, encoded words have been used in contexts where we
expected MUAs to turn them back into their original (native
character) forms, with display of those encoded forms to users
being a (hopefully infrequent) last resort.   That decoding is
less likely in the pop-imap-downgrade and mailing list
situations: in both, if the relevant clients could handle native
UTF-8 addresses, the encoded word forms would not be necessary.

The problem with encoded words in those contexts is that
encoding form "Q" is pretty useless except for mostly-ASCII text
and of somewhat dubious value then and encoding form "B" pretty
much requires a computer to decode.  %-encoded UTF-8 octets are
even worse: one needs a computer or a subtle calculation to turn
them into a Unicode code point reference which then must be
looked up in a table and one actually has to understand how
UTF-8 works to be able to tell whether %NN%MM%OO is one
character, two characters, or three characters.

One possible solution is to mix the encoded word strategy will
direct encoding of Unicode characters by code point.  I've just
posted draft-klensin-encoded-word-type-u-00 as a strawman for
doing just that.  It is not a WG document.  It is not even a
serious proposal at this stage.  But it provides a relatively
concrete proposal about "something else" that we might do to get
at least slightly dug out of the present hole that some of you
might consider worth thinking about.

I have deliberately not added normalization considerations to
that draft, but it could easily be done and I suspect it would
be necessary if the proposal was to be as useful as it might be.

    john

Protocol Action: 'Internationalized Delivery Status and Disposition Notifications' to Proposed Standard (draft-ietf-eai-rfc5337bis-dsn-06.txt)

The IESG has approved the following document:
- 'Internationalized Delivery Status and Disposition Notifications'
  (draft-ietf-eai-rfc5337bis-dsn-06.txt) as a Proposed Standard

This document is the product of the Email Address Internationalization
Working Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5337bis-dsn/

Technical Summary

   Delivery status notifications (DSNs) are critical to the correct
   operation of an email system.  However, the existing Draft Standards
   (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
   in the machine-readable portions of the protocol.  This specification
   adds a new address type for international email addresses so an
   original recipient address with non-US-ASCII characters can be
   correctly preserved even after downgrading.  This also provides
   updated content return media types for delivery status notifications
   and message disposition notifications to support use of the new
   address type.

 
 Working Group Summary 

   There were nothing controversial nor rough for this document.

Document Quality 
	
   This document was reviewed by many in WG with expertise in mail.
   Many thanks to Elliot Lear for external review.  And big thanks to Tony
   Hansen for his effort to make this document ready for publication.

Personnel

   Joseph Yee <jyee <at> afilias.info> is the document shepherd.
   Pete Resnick <presnick <at> qualcomm.com> is the cognizant AD.

The EAI Working Group would like these three documents, along with
draft-ietf-eai-frmwrk-4952bis-12 (to which all three have a normative
reference and is still under IESG review) released as a set. We would
greatly appreciate that they get consecutive RFC numbers in the
following (non-obvious) order:

draft-ietf-eai-frmwrk-4952bis-12
draft-ietf-eai-rfc5336bis-16
draft-ietf-eai-rfc5335bis-13
draft-ietf-eai-rfc5337bis-dsn-06

The reason that 5336bis should have a lower number than 5335bis is
because the current ordering of 5335 (the international email format
document) and 5336 (the international email transport document) has
caused some amount of confusion because the base specifications are in
the other order: First is RFC 5321 (the email transport document) and
second is 5322 (the email format document). And if it works out, having
the RFC numbers end in 0, 1, 2, and 3 respectively might be salient to
readers.

Thanks for your consideration.

Protocol Action: 'SMTP Extension for Internationalized Email' to Proposed Standard (draft-ietf-eai-rfc5336bis-16.txt)

The IESG has approved the following document:
- 'SMTP Extension for Internationalized Email'
  (draft-ietf-eai-rfc5336bis-16.txt) as a Proposed Standard

This document is the product of the Email Address Internationalization
Working Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5336bis/

Technical Summary

   This document specifies an SMTP extension for transport and delivery
   of email messages with internationalized email addresses or header
   information.

 Working Group Summary 

	There were many discussions but none of the consensuses were
	tough to reach nor had tough resistance from the consensus. 

Document Quality 

	This document received lots of attentions and reviews since
	Nov/Dec 2010 and is in very good shape.  As mentioned in
	Acknowledgement section, many thanks to Dave Crocker's suggestions
	that led to refinements in the ABNF.   

Personnel

   Joseph Yee <jyee <at> afilias.info> is the document shepherd.
   Pete Resnick <presnick <at> qualcomm.com> is the cognizant AD.

The EAI Working Group would like these three documents, along with
draft-ietf-eai-frmwrk-4952bis-12 (to which all three have a normative
reference and is still under IESG review) released as a set. We would
greatly appreciate that they get consecutive RFC numbers in the
following (non-obvious) order:

draft-ietf-eai-frmwrk-4952bis-12
draft-ietf-eai-rfc5336bis-16
draft-ietf-eai-rfc5335bis-13
draft-ietf-eai-rfc5337bis-dsn-06

The reason that 5336bis should have a lower number than 5335bis is
because the current ordering of 5335 (the international email format
document) and 5336 (the international email transport document) has
caused some amount of confusion because the base specifications are in
the other order: First is RFC 5321 (the email transport document) and
second is 5322 (the email format document). And if it works out, having
the RFC numbers end in 0, 1, 2, and 3 respectively might be salient to
readers.

Thanks for your consideration.

Protocol Action: 'Internationalized Email Headers' to Proposed Standard (draft-ietf-eai-rfc5335bis-13.txt)

The IESG has approved the following document:
- 'Internationalized Email Headers'
  (draft-ietf-eai-rfc5335bis-13.txt) as a Proposed Standard

This document is the product of the Email Address Internationalization
Working Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5335bis/

Technical Summary

This document specifies an enhancement to the Internet Message Format
that allows use of Unicode in mail addresses and most header field
content.

     Working Group Summary 

This document has been discussed in EAI WG for a very long time. 
The WG came to consensus on this document.

     Document Quality 

The documents have been extensively reviewed by people with mail
expertise. It is in very good shape.

Personnel

Jiankang YAO <yaojk <at> cnnic.cn> is the document shepherd.
Pete Resnick <presnick <at> qualcomm.com> is the cognizant AD.

The EAI Working Group would like these three documents, along with
draft-ietf-eai-frmwrk-4952bis-12 (to which all three have a normative
reference and is still under IESG review) released as a set. We would
greatly appreciate that they get consecutive RFC numbers in the
following (non-obvious) order:

draft-ietf-eai-frmwrk-4952bis-12
draft-ietf-eai-rfc5336bis-16
draft-ietf-eai-rfc5335bis-13
draft-ietf-eai-rfc5337bis-dsn-06

The reason that 5336bis should have a lower number than 5335bis is
because the current ordering of 5335 (the international email format
document) and 5336 (the international email transport document) has
caused some amount of confusion because the base specifications are in
the other order: First is RFC 5321 (the email transport document) and
second is 5322 (the email format document). And if it works out, having
the RFC numbers end in 0, 1, 2, and 3 respectively might be salient to
readers.

Thanks for your consideration.